You don't need an append-console, you can just override the cmdline completely via dts and use the patch as-us, all what matters at that point is the "rootfs=/dev/mtdblock[68]" setting (the rest is static) so the correct rootfs for the (already loaded/ running) kernel gets mounted (I saw your questions on IRC about 6h later, but you never returned).
2 Likes
Good point. Appreciate your steering me in the right direction.
Yes I’m a bit flakey with IRC.
cp target/linux/ipq806x/patches-4.14/0067-generic-Mangle-bootloader-s-kernel-arguments.patch target/linux/mvebu/patches-4.14/
and
--- a/target/linux/mvebu/files-4.14/arch/arm/boot/dts/armada-385-linksys-venom.dts
+++ b/target/linux/mvebu/files-4.14/arch/arm/boot/dts/armada-385-linksys-venom.dts
@@ -48,6 +48,12 @@
"marvell,armada380";
};
+ chosen {
+ bootargs = "console=ttyS0,115200";
+ stdout-path = "serial0:115200n8";
+ append-rootblock = "root=/dev/mtdblock";
+ };
+
&expander0 {
wan_amber@0 {
label = "venom:amber:wan";
should be literally everything needed (disclaimer, I'm not a DTS expert and don't know anything about mvebu, but it should work).
Compiling image with similar patch now.
I'm not sure how CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_MANGLE will interact with CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER. I don't think it will be favourable.
This is what we like to see:
[ 0.000000] Kernel command line: console=ttyS0,115200 root=/dev/mtdblock8
[ 0.000000] Bootloader command line (ignored): console= root=/dev/mtdblock8
Will be submitting a patch shortly.
EDIT: http://lists.infradead.org/pipermail/openwrt-devel/2018-May/012523.html
1 Like
Thank you!
Thanks. When will the changes hit the snapshot? I assume I just need to wait for the right upgrade file and it just work.
When someone reviews it and approves/merges it.
Last time it took 48 hours. Then the build bots pick it up 24 hours later.
Sysupgrade being broken on the original you’ll need to revert to OEM and reflash to the new factory.
Or boot the system using serial/u-boot, you can then sysupgrade straight away.
@lantis1008, just a note that on r7046-5857088c5e, with patch applied, appears to fail on flash of a rango, same build with patch backed out worked. I do not have a serial connected to this device so a little difficult to discern what is transpiring. Not much in the patch that should cause any grief on this front, will take another look, just a heads up.
I’ll unbox my rango and take a look
So this is now clearing the bootargs on devices that aren't venom.
It appears that i was right:
I'm currently trying to test a different method, but i'm pretty much out of ideas.
Anyone else got any? @slh any more inspirations?
@slh - what we know the differences between rango and venom are:
- different mtd layout
- zimage vs uimage kernel
how much is hardcoded in uboot and how much in eboot-env?
i woke up today wondering -are other differences deliberate or a by-product/mistake?
i will try to dig around today. i used to have a wrt3200, now and wrt32xb, and saved most logs, but unfortunately can't test side by side.
i can upload what you might need too.
edit -
it seems the nandboot argument is seriously forshortened in the uboot209/wrt32x environment compared to original uboot and uboot1.00 in wrt3200acm. i am wondering if this makes parsing that line erroneous:
wrt3200acm original uboot:
nandboot=setenv bootargs console=ttyS0,115200 root=/dev/mtdblock6 ro rootdelay=1 rootfstype=jffs2 earlyprintk $mtdparts;nand read $defaultLoadAddr $priKernAddr $priKernSize; bootm $defaultLoadAddr
wrt3200acm uboot v100:
nandboot=setenv bootargs console=ttyS0,115200 root=/dev/mtdblock6 ro rootdelay=1 rootfstype=jffs2 earlyprintk $mtdparts;nand read $defaultLoadAddr $priKernAddr $priKernSize; bootm $defaultLoadAddr
wrt32xb:
nandboot=setenv bootargs console=ttyS0,115200 root=/dev/mtdblock6;nand read $defaultLoadAddr $priKernAddr $priKernSize; bootz $defaultLoadAddr
I have both units (WRT32X and WRT3200ACM) and would be willing to running stuff for you.
I'm not completely understanding the status, but it looks like the wrt32x patch isn't quite ready?
The current version of the patch fixes venom but breaks all other devices.
I’ve had one more idea which I compiled overnight but won’t be able to test until this evening.
https://patchwork.ozlabs.org/patch/921907/
Could you please try this one? I've tested locally on WRT3200ACM and WRT32X and it works ok.
@lantis -do you have binaries built for those of us who don't have that capability right now?
is the missing 'earlyprintk' argument the cause of the console error?
Flashed and running fine on target rango.
@ghoffman, there are images with the @lantis1008 patch applied to be found on my drop (obvious qualifier on directory name); link is off my avatar.
Kabuli –
Do you have a build for wrt32x? that is my current hardware.
wrt3200acm == wrt32x, they are the same; as in the image is the same, with the mods as addressed by @lantis1008 patch.
Actually, they are not the same.
Wrt32x has different image layout (zimage, not uimage) and codename has ‘venom’ not ‘rango’. I don’t think these will work. I might play around a little. Thanks again.