EA7300, Flash to "Wrong" Partition

slh · January 20, 2021, 3:42am

These patches (as referenced earlier) are derived from a common ancestor, they patch deeply ARM specific early boot code and won't help you on mips (aside from being a reference implementation):

github.com

openwrt/openwrt/blob/master/target/linux/mvebu/patches-5.4/300-mvebu-Mangle-bootloader-s-kernel-arguments.patch

From 71270226b14733a4b1f2cde58ea9265caa50b38d Mon Sep 17 00:00:00 2001
From: Adrian Panella <ianchi74@outlook.com>
Date: Thu, 9 Mar 2017 09:37:17 +0100
Subject: [PATCH 67/69] generic: Mangle bootloader's kernel arguments

The command-line arguments provided by the boot loader will be
appended to a new device tree property: bootloader-args.
If there is a property "append-rootblock" in DT under /chosen
and a root= option in bootloaders command line it will be parsed
and added to DT bootargs with the form: <append-rootblock>XX.
Only command line ATAG will be processed, the rest of the ATAGs
sent by bootloader will be ignored.
This is usefull in dual boot systems, to get the current root partition
without afecting the rest of the system.

Signed-off-by: Adrian Panella <ianchi74@outlook.com>

This patch has been modified to be mvebu specific. The original patch 
did not pass the bootloader cmdline on if no append-rootblock stanza 
was found, resulting in blank cmdline and failure to boot.

This file has been truncated. show original

github.com

openwrt/openwrt/blob/master/target/linux/ipq806x/patches-5.4/0067-generic-Mangle-bootloader-s-kernel-arguments.patch

From 71270226b14733a4b1f2cde58ea9265caa50b38d Mon Sep 17 00:00:00 2001
From: Adrian Panella <ianchi74@outlook.com>
Date: Thu, 9 Mar 2017 09:37:17 +0100
Subject: [PATCH 67/69] generic: Mangle bootloader's kernel arguments

The command-line arguments provided by the boot loader will be
appended to a new device tree property: bootloader-args.
If there is a property "append-rootblock" in DT under /chosen
and a root= option in bootloaders command line it will be parsed
and added to DT bootargs with the form: <append-rootblock>XX.
Only command line ATAG will be processed, the rest of the ATAGs
sent by bootloader will be ignored.
This is usefull in dual boot systems, to get the current root partition
without afecting the rest of the system.

Signed-off-by: Adrian Panella <ianchi74@outlook.com>
---
 arch/arm/Kconfig                        | 11 +++++
 arch/arm/boot/compressed/atags_to_fdt.c | 72 ++++++++++++++++++++++++++++++++-
 init/main.c                             | 16 ++++++++

This file has been truncated. show original

github.com

openwrt/openwrt/blob/master/target/linux/oxnas/patches-5.4/996-generic-Mangle-bootloader-s-kernel-arguments.patch

From 71270226b14733a4b1f2cde58ea9265caa50b38d Mon Sep 17 00:00:00 2001
From: Adrian Panella <ianchi74@outlook.com>
Date: Thu, 9 Mar 2017 09:37:17 +0100
Subject: [PATCH 67/69] generic: Mangle bootloader's kernel arguments

The command-line arguments provided by the boot loader will be
appended to a new device tree property: bootloader-args.
If there is a property "append-rootblock" in DT under /chosen
and a root= option in bootloaders command line it will be parsed
and added to DT bootargs with the form: <append-rootblock>XX.
Only command line ATAG will be processed, the rest of the ATAGs
sent by bootloader will be ignored.
This is usefull in dual boot systems, to get the current root partition
without afecting the rest of the system.

Signed-off-by: Adrian Panella <ianchi74@outlook.com>
---
 arch/arm/Kconfig                        | 11 +++++
 arch/arm/boot/compressed/atags_to_fdt.c | 72 ++++++++++++++++++++++++++++++++-
 init/main.c                             | 16 ++++++++

This file has been truncated. show original

This is a slightly different implementation for ipq40xx:

github.com

openwrt/openwrt/blob/master/target/linux/ipq40xx/patches-5.4/997-device_tree_cmdline.patch

--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -1059,6 +1059,9 @@ int __init early_init_dt_scan_chosen(uns
 	p = of_get_flat_dt_prop(node, "bootargs", &l);
 	if (p != NULL && l > 0)
 		strlcpy(data, p, min(l, COMMAND_LINE_SIZE));
+	p = of_get_flat_dt_prop(node, "bootargs-append", &l);
+	if (p != NULL && l > 0)
+		strlcat(data, p, min_t(int, strlen(data) + (int)l, COMMAND_LINE_SIZE));
 
 	/*
 	 * CONFIG_CMDLINE is meant to be a default in case nothing else

arrmo · January 20, 2021, 3:45am

OK, understand now - thanks!! Hmmm, wondering why boot_args is working on the EA3500, but not EA7300. Odd. Will dig, appreciate it!

stangri · January 20, 2021, 6:04am

Wait, so when you sent this PR: https://github.com/openwrt/luci/pull/4502 -- did you test if it worked on your device?

numero53 · January 20, 2021, 10:30am

I don't think that this is a real problem... If the OpenWrt flash is not working, you have simply to wait 3 reboots, then flash the OEM FW and finally flash the OpenWrt factory image... You have to do this just the first time. I know that this is not an usual flashing procedure neither the quickest one, but it's definitely not hard to do.

In an ideal world, I would probably just edit the current boot partition to use the first one at boot time so that the flash from OEM would work always. However I don't know if it's doable or can introduce other problems.

Yes, it's true that usually you can't overwrite the OEM firmware using the standard upgrade procedure, but it's also true that if something goes wrong (e.g. a hypothetical commit that breaks the rootfs partition detection) or an user that wipes the wrong partition by accident would soft-brick the router.

Just for clarification:

I am writing these posts because I think that this change would give little to no benefit for the end user (save few minutes just for the first install) introducing a chance to brick (very remote, but still possible)
Obviously I am not against your commit , but the dual boot router management in general. I don't know if there is an official OpenWrt position about this... If not, I think that we should start a separate thread about this.

arrmo · January 20, 2021, 7:23pm

Yes, I did - tested a couple of things (and was a bit surprised actually!). I checked that both partitions were shown and identified (correctly) - and to my surprise even the LinkSys partition (name) was shown. Nice! I also rebooted from OpenWrt to LinkSys, and that worked (more on that below). Of course, I couldn't use this to go from LinkSys to OpenWrt.

On the reboot, OpenWrt to LinkSys, there is the possibility that,

This didn't really work, but U-Boot was unhappy and just defaulted back to LinkSys. To be honest here .
My u_env partition was already messed up, and that caused this to "work". That said ... anyone have a clean u_env partition they can share? I think that may be part of my grief here (lots "missing" when I compare vs. my EA3500).
I'm just going crazy.

While 3) is a definite front runner (LOL!), it would be good to clean up that partition, and try to retest now that I can put OpenWrt in both partitions (so I can fully test either direction, LinkSys blocked one direction). It could also be the issue that @slh is highlighting, but I need a clean u_env to test that as well.

Clear as mud?

Thanks!

arrmo · January 20, 2021, 7:26pm

Completely understand. I admit, I like the path OpenWrt has taken on this (and it aligns with my L2 managed switches) ... but that's just an opinion. I agree, I think a separate thread would make sense - create that?

I'll continue to try to get this working, as it aligns with the other HW / builds ... of course, it can be undone later if the overall OpenWrt approach changes. Agreed?

BTW, even with this, you never have to "destroy" the OEM partition - that can be kept as well. Just a user preference.

Thanks!

mpratt14 · January 20, 2021, 11:21pm

an "official" position depends on exactly how the device handles failure to boot, and how easy it is to recover, and possibly how easy it is to flash OEM image (being the last priority).

In general, there is no priority whatsoever for preserving OEM firmware on the other slot. As long as the board has perfect support and all functions are working on Openwrt, then OEM firmware is considered trash

I would say sysupgrade to the inactive slot is superior, because if something goes wrong you simply boot to the one you were using, which remains unchanged.

(however I do not know this device in detail and that idea depends heavily on the bootloader's functionality).

arrmo · January 21, 2021, 12:01am

Not so sure this is about append ... U-boot bootargs is not getting through at all it seems. I see,

U-boot (printenv)

console=ttyS1,115200n8 root=/dev/mtdblock8 ro rootfstype=jffs2 init=/sbin/init

dmesg, kernel command line

console=ttyS0,115200 rootfstype=squashfs,jffs2

OK, that's very odd. Think I need to focus there first!

slh · January 21, 2021, 1:46am

There is absolutely nothing odd about that, the bootloader cmdline line is ignored, in favour of the hardcoded cmdline provided by the DTS - that's exactly what the previously mentioned patches take care of, parsing the original setting from the bootloader and re-inserting it into the DTS provided cmdline as needed.

github.com

openwrt/openwrt/blob/master/target/linux/ramips/dts/mt7621_linksys_ea7xxx.dtsi#L16


#include <dt-bindings/input/input.h>
/ {
	aliases {
		led-boot = &led_power;
		led-failsafe = &led_power;
		led-running = &led_power;
		led-upgrade = &led_power;
	};
	chosen {
		bootargs = "console=ttyS0,115200";
	};
	keys {
		compatible = "gpio-keys";
		wps {
			label = "wps";
			gpios = <&gpio 17 GPIO_ACTIVE_LOW>;
			linux,code = <KEY_WPS_BUTTON>;

arrmo · January 21, 2021, 1:58am

Agreed! But it's acting differently on my EA3500 ... LOL. There the info gets passed, and switches partitions as a result. Actually, if that isn't taken into account, I'm not quite sure how Advanced Reboot works (but it may just be me!).

I have found the setting for CONFIG_MIPS_CMDLINE_DTB_EXTEND => but changing it to "Extend dtb kernel arguments with bootloader arguments" doesn't seem to do anything ... but I would think it's what I need, no? I'll dig more.

FYI, the good news ... I have flashed both partitions, on purpose a different kernel version in the two. And just setting boot_part (1 or 2) does in fact boot the correct kernel (partition). Great! The only issue is that the command line is not getting appended (as above), to allow run time update (from the bootloader / environment). But I'll dig into it - your comments make sense, and I just need to find the right place for it. Again, I would have thought the noted variable would be the trigger, but seems not

Thanks!

arrmo · January 21, 2021, 9:00pm

OK, digging in to the code, still WiP . But it seems that this is perhaps already incorporated for MIPS? So not needing more substantial changes, just some CONFIG's set right?
http://mail.spinics.net/lists/stable/msg369096.html

I checked, and the code does seem to exist in build_dir/target-mipsel_24kc_musl/linux-ramips_mt7621/linux-5.4.91/arch/mips/kernel/setup.c. Just a bit confused though, as I don't seem to see (receive) the bootargs from U-Boot. I added some early printk statements, and they do output to dmesg ... but boot_command_line seems to be empty?

May just be me, still digging!

arrmo · January 22, 2021, 1:37am

Well, dang it! . Pulling my hair out trying to get bootargs added to the kernel command line (i.e. U-boot bootargs to OpenWrt). I found the right place in the code (manually changed it to confirm, and it does in fact work - pretty straightforward), but I tried the following, none of them return the U-Boot command line ... that's really all I need (I think ),

arcs_cmdline, this the value that is in the code currently. But seems to just be console=ttyS0,115200
boot_command_line, seems to be empty
builtin_cmdline, OK this is rootfstype=squashfs,jffs2. Kinda makes sense, but not the U-boot info.
cmdline_p[0], is (null)
fw_getenv("bootargs"), also (null)

Any suggestions would be appreciated! I understand that u_env won't really be available this early (not mounted), but where the heck is the U-Boot command line. Needle in a haystack.

Thanks!

mpratt14 · January 22, 2021, 2:17am

Openwrt is not designed to accept any boot arguments from uboot
this was decided a long time ago
and the suggestion to change this in master will be shot down most likely

like slh posted, if you want specific kernel command line for a specific device you use the chosen DTS node

uboot-envtools is used to pass variables to base-files scripts

also...fw_getenv is not an available command (?)
you use fw_printenv and filter the output

arrmo · January 22, 2021, 2:32am

Well, that explains it (not finding it) ... LOL! And no issue, except - DTS hard-codes the partition, and for dual partition I need to be able to switch them. I'm guessing chosen is what you mean here => 2 DTS's needed, and somehow select one or the other? I guess that's the step I'm missing . It makes sense about DTS's, just not sure how to make them run time adapting.

Thanks!

BTW, I do also see in the code how to append the dts info (so this seems to be built in, just need to figure out the dynamic thingy ). Still digging in to it though.

mpratt14 · January 22, 2021, 3:10am

2 DTS is a bad idea...

all the power is in the upgrade script and uboot-env
other than that I don't know any details here

keep in mind that for ea3500 the sets are partitions are numbered
Slot A: kernel1 / rootfs1
Slot B: kernel2 / rootfs2

first identify the logic used for ea3500 that cannot apply to ea7300
and that's the actual hurdle you need to get over
maybe you described this already but I'm not paying that close attention

arrmo · January 22, 2021, 3:21am

LOL - no worries, appreciate all the comments! Will take more of a look, compare the two.

Thanks!

arrmo · January 22, 2021, 3:54am

BTW, agree with this! But I can't get the uboot-env variables into use for the command line => doesn't load the correct rootfs . Thinking the secret may have been in my (now messed up?) u_env partition. Dang it!

mpratt14 · January 22, 2021, 4:19am

probably look into how the kernel decides which rootfs to use

these set of patches will be in master soon, they might help this somehow
but there is nothing in DTS right now to suggest that mtdsplit parser is used...

https://patchwork.ozlabs.org/project/openwrt/list/?series=225499

arrmo · January 22, 2021, 1:51pm

Will look at these in more details - thanks!

I did check out the EA3500 ... it seems to rely on setting environment variables => on the EA7300 this works for boot_part (executes correct kernel), but then the kernel starting is the issue, it doesn't access the correct rootfs (which is set in env variables, but not used like it is in the EA3500 ... that's why I was looking at the U-Boot to kernel command line).

Thanks again.

arrmo · January 23, 2021, 1:56am

OK, I'm pretty convinced of where the issue is - that's not a fix yet, but at least I know where to hunt more now. Let me try to explain, and yell if I'm messed up!

I went and looked at the EA3500. No serial port, but from OpenWrt here is what I find,

fw_printenv -n bootcmd
"run nandboot" OK, check that,
fw_printenv -n nandboot
nand read.e 0x2000000 0x200000 0x300000; setenv bootargs $(console) $(mtdparts) $(fs_bootargs_root) serial_number=$(sn) uuid=$(uuid) hw_version=$(hw) device_mac=$(mac) factory_date=$(date) wps_pin=$(wps); bootm 0x2000000; ... wow, that's pretty darn specific. So then,
dmesg | grep Kernel
[ 0.000000] Kernel command line: console=ttyS0,115200 mtdparts=nand_mtd:512k(uboot)ro,16k@512k(u_env),16k@528k(s_env),20m@2m(kernel),20m@2m(rootfs)fs,20m@22m(alt_kernel),20m@22m(alt_rootfs)fs,22m@42m(syscfg) root=/dev/mtdblock4 ro rootfstype=jffs2 serial_number=12...25 uuid=6E...8B hw_version=RGWM-C5_0GA device_mac=94:...:8C factory_date=2014/11/27 wps_pin=2...2.

OK, that's not a concidence, and no way those values are stored in the OpenWrt source code. I checked, all the values do match fw_printenv outputs. So it seems that the EA3500 (OpenWrt code) must be pulling in the environment variables (somehow), and applying those to the command line - agreed? I sort of said that above, but my bad - I said it wrong. It's not the command line that is being passed, rather bootargs (the variable) is being used. I just termed it incorrectly, sorry!

So now, I need to figure out how to get those bootargs (variable) - applying it to the command line is easy, I have that figured out already. That will take care of adapting the rootfs, as it's already being set correctly in the environment variables (also have that part working).

Now to hunt for where the environment variables are at (at the start of the boot).

Thanks!