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.
Yeah, this is a definitely weird aspect of the Pi4, it's like it's magic. I suspect that what is going on is the realtek driver is somehow batching the IRQs, like it just wakes up every 1ms and handles all the packets all at once. By doing this, or something like that, it avoids a huge amount of overhead, and therefore can handle crazy high packet counts.
I wonder if someone puts USB3 NICs on an x86 if it does the same thing? or is it somehow ARM/broadcom CPU specific?
Not sure it would make a lot of difference but you might as well try that too
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.
I'd be more inclined to believe the reporting of some metrics is just broken and the number you see is wrong. But this is just a feeling, no proof.
I can try, but I only have USB dongles with ASIX chipsets, no Realtek USB dongles in this house as you probably remember from other discussions.
No need. As I mentioned, the IRQs are distributed amongst the cores on both platforms; as far as possible I like to compare apples with apples. On the Pi it's done with my own script, but as of 21.02.0 on the Intel box I didn't have to do anything: at boot the interrupts land by default on both cores; RX and TX for each queue on same core, the queue pairs on separate cores. This was not the case in 19.07. I haven't looked at the code, this seems to be a kernel thing. It is not done through affinities: the smp affinity remains the all-cores mask (in this case "3").
