I've tried both the x86 and arm versions I found on the arch-linux wiki and they both gave me an error saying I do not have the correct architecture.  Where can I find a postgres that will work on PBP Manjaro?

Still confused about relationship btw Arch and Manjaro.

For the past week I've been trying to get this board to actually boot off a usb attached drive. Here's where I am:

- compiled my own u-boot following instructions here: https://forum.pine64.org/showthread.php?...9#pid55839
- tried so many ayufan and other u-boot (like https://forum.pine64.org/showthread.php?...+usb+3+3.0) I can't keep track anymore
- I have a seagate backup drive + usb 3.0 to sata interface, a JMS578/567 (sold officially by pine too?), and another weird Toshiba (Bus 002 Device 015: ID 0480:a00c Toshiba America Inc) usb 3.0 to sata interface
- upgraded firmware on the JMS578/567 from another SBC forum

There is no common theme among u-boot versions:
- some will power-cycle the usb 2.0 drive to death, some will only do it 2-3 times.
- Some will detect my seagate (external power) usb to sata interface, some won't.
- USB 2.0 is more likely to detect something connected to it, but it doesn't boot. It's just stuck before the point where it should say "Starting kernel...". While using Toshiba interface, the hard drive powers off after the kernel selection prompt.

Now here's the nut-kicker:
- I have a sandisk extreme usb 3.0 thumbdrive which *DOES* boot off of usb 3.0 with *some* u-boot versions. So that confirms usb 3.0 port is fine, and the image I'm trying to boot is also fine.

What I believe I ruled out:
- damaged HDD/SSD
- non-working usb to sata interfaces
- inadequate power supply to rockpro64: I can duplicate all of the above with a 12V 1.5A as well as a 12V 3.5A brick. I'm sure I can rig up a 12V 25A from a desktop power supply if that's going to make some of you obsessed people happy (IRC people kept pestering me about this being power related). On top of that, on a fully booted system (from sd card), anything I throw in the usb ports gets adequate power and works
- shit linux images; I'm able to boot the same image(s) off of the usb thumbdrive connected to usb 3.0
- usb port damage (I can see all devices connected to usb 3.0 A, both usb 2.0 ports, cannot test usb-c, no dongle/device)

I also tried a sata_sil24 compatible card; u-boot sees it but it doesn't go any further than that. Drives connected to the PCIe eSATA (Sonnet Tempo SATA E2P) do not power on while in u-boot, but they will power on and get discovered once a linux kernel is booted. I'm guessing u-boot inadequate sata_sil24 drivers?

I don't know much about grub, or uboot, or compiling my own kernels but I can follow directions.

I've been struggling with getting this window tiler to work https://github.com/kwin-scripts/kwin-tiling and thought maybe it's the meta-key? Maybe I'm hitting the wrong key? 

On mac (on my mac at least) it's esc. I've also tried alt, ctrl. What's the meta key here? Manjaro with Plasma

I don't know your country but in the US you get scam phones almost every day. On many phones you can block certain numbers or even block all unknown phone numbers. Is this possible in any distro? thanks

I noted that there's a call to action for people to develop things for the SOEdge, but I also noted that it's hard to determine where its niche is felt to be. That might make it difficult for chickens to provide eggs that others can consume. 

However, I was looking at the upstream Github for the BSP and wasn't immediately finding licensing information or what the difference between the full and Neural AI Stick BSPs is. Does anyone have this information readily available? Downloading 25 GB of BSP SDKs to compare them, for a board I don't have, isn't high on the "this is a fun way to get started" list.

But, more than anything, what do you (both PINE64 and the community) see as the most likely use cases and software to be run on them? That will help interested developers decide if it's a project where their $50-60 + time is going to be well spent by producing output that is going to continue to be useful to a community.

It's obvious that it is positionable for AI, but that's still a very wide range of uses (machine learning, speech, vision, language processing, robotics, expert systems, and more...) and associated software. I see a viable approach in bootstrapping a JeOS baseline image to validate functionality and performance, and then building images based on that for specific tasks.

I know that most buying the board will want to use Acuity with the Vivante NPUIP, but what sorts of things will people be doing with the NPU? What sorts of non-NPU things are people wanting to do?

I'm interested in hearing from the buyers and potential buyers of the SOEdge,of course. What do you want to see this become? Are you planning on basing a business model on using these boards? What do you need to be successful? As a hobbyist, what will make your life easier and save you time by already having common stuff in place?

I'm not explicitly volunteering to start putting some images together, partially because I don't have the hardware to test on right now, and partially because I don't know what would be useful to others. But I expect that anyone else who might want to build images for wider consumption than themselves will also want to know how to make them as useful as possible.

This is probably not the normal way to do it, but I installed the mrfixit image to an SD, updated it to Buster, seems to work fine.  Now I'm trying to copy it to my 1 TB Intel SSD.
I made a 1 GB (generous) FAT32 partition and a 200 GB ext4 with gparted on the SSD.  Then following piclone's example I used cp -ar to copy the files in the partitions on the SD to the SSD.  Then edited the root= specification in extlinux.conf on it to the nvme path.

But it doesn't boot, it boots the eMMC instead.  My notes:

I tried different OS (Mobian, pmos, UT) and UI, but everytime Pinephone doesn't wake up from suspend when it gets a call or sms. Reading this thread I understand it is a modem issue which seems very difficult to fix. But is there any workaround ?
For me it is the only reason why I don't use the PinePhone as an ordinary daily phone.

I have installed openSUSE Tumbleweed onto a couple of my Rock64 boards, with 16GB MicroSD cards. (Basically) everything seems to work fine for my needs, but there are some things I noticed. I'm not entirely sure why the distro is not currently on the Rock64 wiki, and there hasn't been much on the forum about it, so I thought I'd toss my thoughts out there for anyone else who's grumbling at pointlessly needing yet another distro for yet another SBC.

The Rock64 HCL notes the availability of Leap, though it is not available at the time of this writing. Further, only JeOS is available at this time, though there are (broken) links on the HCL page for E20, XFCE, LXQT, KDE, and X11. I can think of no reason one might reasonably want any of those though, especially with the caveats below.

The HCL lists instructions for writing the xz file to SD card using an existing Linux install. But I can confirm that the usual Windows tools, including Rufus, will write the xz file fine. 

Also, HDMI video output works for initial boot, so you do not need a serial port for initial configuration (I cannot confirm how useful a serial connection, so the HCL might be right that you want one). As it's likely to be running headless long-term, it might be easiest to do your initial boot (it might take a couple minutes) and configuration over SSH, by finding the DHCP lease in your DHCP server's database (probably the most recent entry, of course) and SSHing in with the credentials on the HCL page (don't forget to change them immediately!). Why bother hooking it up to a keyboard and monitor for a one-time thing that can be done with your usual tools?

Anyhow, the caveats:

1. Booting takes a while sometimes. I'm not sure why just yet, but there's a 100 second gap in dmesg each cold boot for me (10 seconds on warm boot, which I think are due to installing rng-tools as they need to gather entropy). But ideally you're not rebooting often.
   
2. The default btrfs partition at /dev/mmcblk0p3 is only 1.7GB and starts off 1.2GB full with a bit over 400MB free. You can either create a new partition, or you can extend the one that's there (exercise for the reader, but you could probably do worse than yast2 disk). I opted for the latter and btrfs filesystem resize max / once I fixed the partition size was all I needed, myself.
   
3. SPIDF/I2S audio doesn't work. This generates some kernel spew and a mostly harmless set of traces. As I'm not using sound, I've done zero investigation. I've also not bothered to blacklist the modules, so I can't help you reduce boot-spew. I do not know if HDMI audio works, though the drivers seem to load without incident.
   
4. There is a lot of screen tearing in the console, even if there's no scrolling or other activity, especially if you have more than just VT1 in use. I have not tried X11, but I can't imagine it having useful performance if it can't even draw the text console error-free. This may be related to the following kernel message: rockchip-drm display-subsystem: [drm] Cannot find any crtc or sizes
   
5. If you're used to using DTBOs with this SBC, you're going to have a bit more challenge than with some of the more widely-used distros. I do not recommend the task for those not extremely comfortable with the idea of a distro which doesn't have /sys/kernel/config/device-tree/overlays available without you having to do your own legwork and doesn't seem to have a way to take the Raspberry Pi approach.
   
6. I do not see evidence of eth1 in either dmesg or YaST. As I do not currently have plans to multihome any of my Rock64s running openSUSE, I have not investigated further (including the whole magjack situation which doesn't look like anyone has documented properly, in general).
   
7. Blinking the NIC LED doesn't seem to visibly do anything, but it also doesn't generate errors. This is mostly just a note since it's pretty common behavior on ARM SBCs, and since there's only one port, there's no reason to blink it anyhow.
   
8. It does not seem that there is yet TrustZone support. For most users, this is probably a non-issue.
   
9. Some things seem to perform much worse than I'd expect, quite notably YaST2. Since performance hasn't shown itself to be an issue with my workload, I've not investigated. It may just be due to the fact that I'm not using an eMMC.
   
10. Again, this is a JeOS image. Lots of things are going to be missing compared to even a minimal standard install. Be prepared to use zypper a bit, or to hit the Install button in YaST when you set up things like NTP sync.
    
11. openSUSE's aarch64 support isn't quite first class in my opinion. Be aware you're gonna probably need to add some stuff from openSUSE:Factory:ARM
    

• openSUSE HCL: Rock64
  
• devel:ARM:Factory:Contrib:Rockchip images - You'll want the one with a filename like openSUSE-Tumbleweed-ARM-JeOS-rock64.aarch64-XXXX.XX.XX-BuildX.X.raw.xz (where the X values change, depending on date/build)
  (Note that the download repository has images for other SBCs, as well. Currently the list is fireflyrk3288, rock64, rockpi, and tinker. I have not used any of the other images. I cannot likely assist with issues related to SBCs that I do not own.)
  
• openSUSE:ARM distribution howto - This page has how to use osc on ARM (I did mention you'll probably want to already be familiar with OBS right?)
  
• Portal:ARM - The jumping off point for openSUSE-on-ARM documentation
  

As previously mentioned here: https://forum.pine64.org/showthread.php?...ght=soedge

It seems like USB3 will not be available on older but otherwise compatible (?) hardware like the clusterboard.

Any chance there could also be an undated clusterboard to more fully utilize this module and or maybe also prepare for a sopine2 module?

Armbian install by way of Diet Pi.

I was really looking forward to moving our self-hosted services to a more capable SBC.  I need a solid ethernet connection that the H64b doesn't seem to want to provide.  I'm going to check with Manjaro build, but arch isn't my flavour and I'm not looking to manage a single non-debian based distro.

Am I sending this thing back to Pine?  What was the purpose of the h64 if it's barely supported by anything?