tkaiser Posted September 7, 2017 Posted September 7, 2017 I'm struggling with XU4/HC1 and the try to have the rootfs on a connected USB disk. All attempts end up with: Gave up waiting for root file system device. Common problems: - Boot args (cat /proc/cmdline) - Check rootdelay= (did the system wait long enough?) - Missing modules (cat /proc/modules; ls /dev) ALERT! /dev/sda1 does not exist. Dropping to a shell! Rebooting automatically due to panic= boot argument I tried USB disks on USB3 and USB2 ports, according to leds and spin-up sound the SSDs/HDDs get power but device doesn't show up. I remember vaguely that we had such issues on other platforms where it was just a small missing bit in kernel config. But I don't get it even after spending an hour on searching around. 2 times boot log with high verbosity, maybe someone else has a clue: https://pastebin.com/ffnQK2Pm
zador.blood.stained Posted September 7, 2017 Posted September 7, 2017 On 9/7/2017 at 3:44 PM, tkaiser said: I remember vaguely that we had such issues on other platforms where it was just a small missing bit in kernel config. But I don't get it even after spending an hour on searching around. Expand I beleve it was CONFIG_CHR_DEV_SG, and it is set to built-in on xu4-next. And even if it was a module it would be loaded from initrd. You can try investigating it further by replacing "panic=10" with "break=premount" in the build script kernel command line, it should give you a minimal shell.
zador.blood.stained Posted September 7, 2017 Posted September 7, 2017 I just tried to use nand-sata-install (with ext4 target FS) and somewhere it tried to use BTRFS mount options: [ 67.753492] EXT4-fs (sda1): Unrecognized mount option "compress-force=zlib" or missing value
tkaiser Posted September 7, 2017 Author Posted September 7, 2017 On 9/7/2017 at 4:42 PM, zador.blood.stained said: somewhere it tried to use BTRFS mount options Expand Yes, that's due to mount -o compress-force=zlib $2 ${TempDir}/rootfs || mount $2 ${TempDir}/rootfs
zador.blood.stained Posted September 7, 2017 Posted September 7, 2017 Just tested XU4 next, install to USB drive (new board support package but an older boot script) and it worked fine for me.
tkaiser Posted September 15, 2017 Author Posted September 15, 2017 On 9/7/2017 at 4:51 PM, zador.blood.stained said: Just tested XU4 next, install to USB drive (new board support package but an older boot script) and it worked fine for me. Expand Sorry for the late feedback. In the meantime I tested a new build with latest bootscript and it didn't boot at all. Was too lazy to connect serial console (since running a test on HC1 in parallel where the adapter was connected to) and thought 'Seems Zador is preparing whole switch to armbianEnv.txt so let's wait for this happen'. But now I wonder whether you're still preparing stuff or not?
zador.blood.stained Posted September 15, 2017 Posted September 15, 2017 On 9/15/2017 at 1:21 PM, tkaiser said: Sorry for the late feedback. In the meantime I tested a new build with latest bootscript and it didn't boot at all. Expand Didn't boot before nand-sata-install or after? On 9/15/2017 at 1:21 PM, tkaiser said: But now I wonder whether you're still preparing stuff or not? Expand Currently a bit busy, but since I bought a bunch of fresh SD cards for tests several days ago at least I won't be having a problem with finding a good card for the test.
tkaiser Posted September 15, 2017 Author Posted September 15, 2017 On 9/15/2017 at 1:30 PM, zador.blood.stained said: Didn't boot before nand-sata-install or after? Expand Before. And highly frustrated that day since wasted hours already due to stupid mistakes I made and some unfortunate decisions (build host related). Boot failure --> putting XU and HC1 in the drawer waiting for you finalizing armbianEnv.txt vs. boot.ini stuff. Only positive result from this day back then was the finding that symlinking cache/sources and cache/toolchains from a btrfs force-compression=zlib partition doesn't hurt performance wise (while savong over 100% needed storage)
zador.blood.stained Posted September 15, 2017 Posted September 15, 2017 On 9/15/2017 at 1:37 PM, tkaiser said: waiting for you finalizing armbianEnv.txt vs. boot.ini stuff. Expand Unfortunately currently there is a "hack" for all boot.ini based configurations that deletes armbianEnv.txt, and we can either getting rid of it all together (requires tests on Odroid C1/C0 boards which use a very old u-boot) or introducing more hacks on top of existing ones.
tkaiser Posted September 15, 2017 Author Posted September 15, 2017 On 9/15/2017 at 1:41 PM, zador.blood.stained said: Unfortunately currently there is a "hack" for all boot.ini based configurations that deletes armbianEnv.txt, and we can either getting rid of it all together (requires tests on Odroid C1/C0 boards which use a very old u-boot) or introducing more hacks on top of existing ones. Expand Well, I would prefer the least hackish attempt but fear I can't help much since I've no serial cable for my C1+ / C2 (as I understood the serial cable for XU4/HC1 is not compatible to the other boards since 1.8V vs. 3.3V)?
zador.blood.stained Posted September 15, 2017 Posted September 15, 2017 On 9/15/2017 at 1:55 PM, tkaiser said: as I understood the serial cable for XU4/HC1 is not compatible to the other boards since 1.8V vs. 3.3V Expand The wiki suggests that it's compatible (it has a 4th wire for voltage reference) _____UART____ |Pin 4 - GND| |Pin 3 - RXD| |Pin 2 - TXD| |Pin 1 - VCC| \___________| 1.8V LVTTL for ODROID-U3/XU3/XU4/X2/X 3.3V LVTTL for ODROID-C1/C1+/C0/C2/W RxD pin is input and TxD pin is output. The VCC pin is not a power source but a reference voltage input. It is used for detecting the IO voltage like a VIO or a VDDIO. Support for I/O interface voltages down to 1.8 V is provided via a VIO pin.
tkaiser Posted September 15, 2017 Author Posted September 15, 2017 On 9/15/2017 at 2:12 PM, zador.blood.stained said: The wiki suggests that it's compatible (it has a 4th wire for voltage reference) Expand Ok, will try this out soon! Thank you.
zador.blood.stained Posted September 16, 2017 Posted September 16, 2017 On 9/15/2017 at 1:21 PM, tkaiser said: Sorry for the late feedback. In the meantime I tested a new build with latest bootscript and it didn't boot at all. Expand Maybe this has something to do with it Processing file /home/zador/armbian/patch/u-boot/u-boot-odroidxu4-next/cfgload-support-ext4.patch 1 out of 2 hunks FAILED -- saving rejects to file cmd/cfgload.c.rej I'll update the patch and push the fixes a bit later. 1
zador.blood.stained Posted September 16, 2017 Posted September 16, 2017 ... and fixed: http://sprunge.us/HddQ. It was a timer issue (similar one was present for Odroid C2). Arch timer is required for virtualization but is bad for multimedia. And since we enabled KVM in the kernel config this broke the kernel: https://github.com/hardkernel/linux/commit/dfd91685e555e5a79a3b655d8e3703a0984be35d
tkaiser Posted September 16, 2017 Author Posted September 16, 2017 On 9/16/2017 at 3:52 PM, zador.blood.stained said: and fixed: http://sprunge.us/HddQ. Expand 3 attempts with freshly built images, the first two with btrfs (no boot but panic), now with ext4 I've no network. And a f*cked up screen setup so serial console logs are trashed too. Will look into it tomorrow. And thanks for the diagnose/fix!
Recommended Posts