After struggling to DD an image for over an hour I found Etcher, Bada Bing, Bada Boom! up and running with 19.07.08.
Device booted right up. It reports 2GB. BIOS appears to be 2.7 form 3/7/16 (from the logs).
I installed a random old 2GB (Sandisk Ultra II Class 4) SD card. The card it came with is a class 10 4gb. There is a note in the device wiki if the device does not boot to use a new 32Gb. Do you have any comments about SD cards.
Is there any non-RS232 serial, pin serial access like with the cheapo USB to serial adapters? Is there any way to update the bios from one of the images you mentioned without serial access?
Afaik no. I'd like to point out that a USB-RS-232 adapter is like 10$ and a null modem adapter is another 5$ at most.
If you are worried about getting locked out just buy that.
EDIT: technically yes there is UART pins you can use with the "usb serial adapter" you use with routers but to enable them you must change default BIOS settings, and this can only be done through serial port. So it's a chicken-and-egg problem.
You can just use cat (silent like dd) or pv (shows completion bar and writing speed). cat /path/to/image.img > /dev/sdX pv /path/to/image.img > /dev/sdX
No need to muck around with dd if you are just writing the whole file.
I think it's ridicolous to use a 120Mb Electron application (it is a web application running on its own bundled Chrome browser instance) like Balena Etcher to write a file to an external drive. But that's what gets the most press for Raspberry images for some reason.
Afaik older BIOS versions had issues with booting from some cards.
Newer BIOS has an option to enable "Sdcard 3.0" which is enable SD controller in 3.0 mode to allow achieving full speeds with UHS-I SD cards
according to their docs https://github.com/pcengines/sortbootorder
To change this option you can only use serial port, because that's the only way to see BIOS interface
yes
No, the efi image is for devices that have UEFI boot only (or you want to boot them in UEFI mode for other reasons, like in a VM with PCIe passthrough). More modern industrial boards lack BIOS boot, and Intel has been discouraging OEMs to include the legacy bios boot functionality for a while https://www.anandtech.com/show/12068/intel-to-remove-bios-support-from-uefi-by-2020
APUs have BIOS boot so the "efi" image does not work.
I did all my work yesterday on the only PC I own with an SD card, my work laptop, booted to Ubuntu 20.
FWIW: sudo dd status=progress bs=8M if=/dev/sdc1/openwrt-19.07.8-x86-64-combined-squashfs.img of=/dev/mmcblk0p1
This yielded a Not a Directory error IIRC. Moving on.
Rufus works (mostly, see below). I use it all the time, it ever occurred tome to try this.. duh!
Spent a good chunk of time trying to get IPFire to boot on the device. I assumed it was an image problem, but I found links and this on the IPFire site that indicates that it's a serial cable fix. Moving on.
Today I found your post on the /dev/mem and tried 19.07. First, one needs to load packages wget and flashrom (there are 4 flashrom packages, I just used the first) but /dev/mem's not there.
So 2 items:
The site with the ROM file uses SSL and there are missing files for wget that could not be found. Instead I used [--no-check-certificate] wget https://3mdeb.com/open-source-firmware/pcengines/apu2/apu2_v4.14.0.3.rom --no-check-certificate
At this point I have downloaded the ROM file and also figured out that I can just copy the file to the APU2's /root/ folder with WINSCP.
Flashrom would fail indicating errors regarding /dev/mem
Critical error: open(/dev/mem): No such file or directory and more
Same results for Lede-17.01
I found this forum post that idicates CC15 should work. Unfortuantly I am unable to get a CC15 image working on the same SD card as I had 17 and 19 on. I tried both Rufus and WinImage32. Guessing I need to use the serial cable and fix something in BIOS.......
It's probably for the better that you went with a very user-friendly tool like Balena Etcher, you are doing some wonky things here.
Is the openwrt-19.07.8-x86-64-combined-squashfs.img really in a folder called /dev/sdc1 (which is a device name aka a special file that represents a whole block device because it starts with /dev)? The error "not a directory" is correct, that is a block device file, not a valid directory tree.
In reality the file should have been in /home/rangerz/downloads if you downloaded it to the download folder or /run/media/rangerz/usbdrive for a mounted usb drive
Also afaik /dev/mmcblk0p1 is first partition of SDcard and you want to flash it raw on the sdcard, which is /dev/mmcblk0.
But it's ok, you probably aren't into hardcore Linux internals all that much and to just flash a file both tools I mentioned (and Balena too) are fine.
Ah great, it's a clusterfakk.
I underestimated how easy it would be for people without a serial console. Sorry about that.
Gimme a sec I'll recompile a modern OpenWrt x86 image with /dev/mem enabled (+ flashrom, wget and the ssl certificate packages) so you guys can use that
The Openwrt Image was in the root of a USB Drive on the first partition which I determined to be SDC1. I had previously downloaded it on Windows.
So, if I had downloaded if from the Ubuntu OS (Firefox) to the default location, would that have been the default location the wiki string (ie no params) would have used?
If I am following, would this have been the value I was seeing in the file manager tool. I was not understanding why I was seeing the file "in 2 different places". I'm thinking windows, which I guess does not apply.
Yeah, I see your point about the target, and now understand I should specify a drive, not a partition.
As for Linux, not much. I can get by with following good instructions. I tried to freshen up the string from the wiki and struck out.
ATM, I am flashing OpnSense nano, and was going to see if that would boot and I could run flashrom. On course anything called nano is probably shy a feature that I will need.
So I made the image and tested it on one of the APU2 that are still in "stock" condition (I didn't yet update their BIOS) and it all went well, so I'm reasonably confident that the image is working as intended. After you confirm it's ok I'll probably copy these instructions (and the image file) on the wiki in the device page of the APU2 (and APU1 since it's mostly the same process, just use a different BIOS image file)
Uncompress and flash it to a USB drive or SD card, insert and power on the device.
Connect a cable from the WAN port (the ethernet port closest to the Serial port) to the LAN port of your current router, and a cable from one of the other two ports to your PC, disconnect your PC from any wifi or internet connections. It should reach the internet through the APU2 device now.
Go to 192.168.1.1, click Login (don't set a password, we don't need it here).
If your current main router also has an IP in the same 192.168.1.x network, please change the IP of the APU from the Network --> Interfaces and click on Edit button of the LAN interface. Then change the IP, click Save, then click on the small arrow on the right side of the "Save and Apply" button, and select "Apply Unchecked", the button changes to red and becomes "Apply Unchecked", click on it and confirm the action. After it has started doing it, pull the ethernet cable from the PC, wait 10 seconds, connect it again and go to the new address you set.
Another option is just connecting the WAN port of the APU to the cable modem, disconnecting the router. This process isn't long.
Now we can start the actual flashing instructions.
Click on Services --> Terminal
It will open a page with a terminal screen (this is luci-app-ttyd package)
write "root" as login and press Return/Enter key
It will show console screen.
You can also connect with ssh as normal, or through serial console, the following commands are the same.
check that internet is accessible with ping -c 5 8.8.8.8
then wget the latest firmware image from the repo https://pcengines.github.io/
(you can copy the link and then rightclick on the terminal window to paste it) wget https://3mdeb.com/open-source-firmware/pcengines/apu2/apu2_v4.14.0.3.rom
You can check the current installed firmware version with dmidecode
It will dump a big amount of text, we care about the first few lines where you see BIOS Information and the Version string.
now we can give the flashing command flashrom -w apu2_v4.* -p internal:boardmismatch=force
This command may or may not print a bunch of errors about flash chips not recognized, but it will eventually find a chip it likes and start the flashing process.
it has finished when it says verifying flash VERIFIED
and gives you back the console.
Now you can reboot and see if all is still good or you cooked the device. reboot
In 20-25 seconds or so it should be accessible again.
/dev/sdxx is a special internal name, not a real folder path. It's used internally to do stuff and when you give commands that operate on RAW storage device space, like dd. Linux has a few special folders where it shows "files" that are not real files but internal file-like interfaces to do stuff, like /dev, /sys and /proc.
When you insert the USB drive that /dev/sdc1 got probably auto-mounted as a folder so you can go inside and see the contents from the file manager.
When you are inside the folder where you can see the file, press Ctrl + L keys on the keyboard and at the top of the window should appear the folder path instead of navigation buttons you can click to go back between folders. It should be already selected so if you also do Ctrl + C you can copy it to use in the terminal.
A GUI application on Linux that can help you see disks, partitions, mount/unmount them and see where they are mounted is gnome-disk-utility, I've been using it for ages. It can format drives/partitions and also make a disk/partition image to a file and restore a an image to a raw disk, which can also be used to flash images raw to a disk, just select the disk you want to overwrite, click on the three vertical buttons on top, and select "restore disk image" then you can go and select your image file, and ask it to start flashing.
(FYI for anyone interested: tested the Sophos SG-105 with OPNsense, and the PPPoE performance was, as reported for all FreeBSD-based OSs, completely unacceptable. Max'd out the CPU at <400mbps down and <600mbps up; and tweaking the various recommended tweakables did not really improve that. I'm back on my RPi4. Based on the specs I still expect the SG-105 will be a good performer with OpenWRT, I'll install that next.)
(Edit: the difference between Linux and FreeBSD driver/PPPoE support is insane. Ran the same tests again on my Pi 4, which is a quad core but only benchmarks about 20% better per-core than the SG-105, and get less than 5% cpu usage at >900mbps. There's a lot to be said for the sheer magnitude of community and corporate development support for Linux.)
I think it is padding (free space filled with "0" so when put in a compressed archive like gz it just disappears), older releases were generating squashfs images and not padding them to the full partition size, just assuming that when flashing the image on a physical drive it would have enough space to make the partition work. Which worked fine for physical devices since it's been kind of hard to even find storage smaller than 1GB for a while.
This was a problem for VMs that just tried to use the image file as virtual drive directly, they would simply not have any space to put the read-write filesystem. For example this thread X86_64 combined-squashfs.img.gz missing 230MB data partition?
This was fixed by these two commits that added padding of the squashfs images to become as large as the default partsize. https://github.com/openwrt/openwrt/commit/97d86426e2ec4e6a875f82aa6e0ffdb802fbde22 https://github.com/openwrt/openwrt/commit/a17d9482f5e218da2c0bcaa41662f355ee32be07
In practical terms, this is a fix for people using OpenWrt in virtual machines, which apparently has been increasing significantly, for people using OpenWrt on physical storage devices this change is just cosmetic
Is there any procedure to get OpenWRT base images to include the hardware specific enablement packages for x86 hardware(not just being provided generic images)?
You can always build you own image for yourself with imagebuilder. First of you need to create your config with make menuconfig & make kernel_menuconfig
Here is the list of recommended packages for APU2.
in addition to that, I'm using github's actions feature for building images in remote. It's pretty neat feature! I can recommend it. This is a good template to start with.
Here's a fun one: a lot of 11 for $32/ea. Well, $37 with shipping. And while you can't see the back, "Advanced 2" does appear to be what simplewan calls their SW302DA, or APU2.
Strangely appealing, but maybe not quite cheap enough to be worth buying the lot and trying to get more for them individually over time; median "good" price for these is $40 to 55 and that's going to keep falling.
Meanwhile, my Sophos SG105 is working well with OpenWRT 21.02.0 and is good enough at routing gigabit PPPoE/NAT; but maxed out it's hitting 70-90% sirq on both cores. (Edit: on retest with HW flow offloading [is this even supported in the igb driver?] I'm seeing lower numbers: 30-60%% per core, much better. Clearly I need to do more sampling.) Routing over plain ethernet between two local VLANs with iperf3 with very few rules uses up to 20%, and no, I'm not running iperf3 on the device itself.
For reference it's an Intel e3826, 2 cores @ 1.47GHz, 2GB DDR3 @ 1067MHz, 4x Intel i211 NICs. The cpu benchmarks perhaps 30% higher per-core than the APU2's GX-412TC (geekbench 4; 5 is a bit low-res at this level), and about the same as the APU2 in multicore tests which is not bad given it's got half as many.
It's good enough to keep in service, but to be honest I expected more. By comparison the Pi 4 just destroys it performance-wise, even with a Broadcom and dual Realtek USB3 NICs. In the same tests Pi's CPU barely wakes up at all: perhaps 5% sirq flat out on PPPoE/NAT at 941mpbs, and iperf3 tests routed between LANs you can't even tell it's doing anything. Yes, it Geekbenches a further 20% above the e3826 per-core, and it has twice as many, but that doesn't seem enough to account for the profound difference. In both cases IRQs are suitably distributed, and the Pi's drivers don't create TX and RX queues per-core like the Intel driver does. Still, it's an industrial-quality build (ahem, no scary dongles!) and just about equal to the job so I'll keep it in service a while.
Yes, it's a v2, I should have mentioned. If you can get a v3 at a decent price it's got a better CPU with more and faster RAM. I've seen good deals on the higher-spec SG-115s as well.
As for ECC, according to the specs the processor supports it, but that doesn't seem to be what's installed. It's a single SODIMM slot (no dual-channel then) so you'd have quite a hunt for the right spec memory, probably have to use 1333MHz which presumably would work fine.
Edit: dmidecode seems to think it's got two DIMM slots. Not on top it doesn't , and I can't see underneath without unscrewing the board. I'm guessing the mobo has chipset support for two slots -- cheaper to build out your product line if you just do this once for a given platform -- irrespective of whether it has the traces for one of them.