[U-Boot] FDT retrived varaibles appear to have different properties fom other u-boot variables - and are corrupted on get, set, get sequence
Cédric I move the fdt to 0x100 fdt move ${fdt_addr} 100 fdt addr 100
then fdt get value bootargs /chosen bootargs printenv bootargs bootargs=........all the boot args.......but setenv abc $bootargs fails...as does printenv $bootargs
fdt set bootargs /chosen bootargsfdt get value bootargs /chosen bootargsbootargs=bootargs The variable name bootargs replaces the values contained in the variable bootargs in the fdt. Something is not right in the world of fdt code. Duncan Hare
714 931 7952
From: Cédric Schieli cschieli@gmail.com To: dh@synoia.com Sent: Sunday, November 13, 2016 2:21 AM Subject: Re: Fw: [U-Boot] Fw: FDT pointer value, passed by the PI firmware, is not set in u-boot
Hello Duncan,
2016-11-13 3:04 GMT+01:00 dh@synoia.com:
If appending to "/chosen bootargs" (making it longer), does the fdt command automatically relocate the fdt, or does the u-boot script have to do that itself?
The fdt doc at http://www.denx.de/wiki/view/ DULG/UBootCmdFDT Is quite unclear on how the fdt size is managed, especially when the fdt is located close to the end of memory.
I'm not an expert here, but looking at cmd/fdt.c I didn't find any kind of relocation code. So I guess the safe bet is to move the blob before making any (growing) change to the tree:
# load the blob from the firmware provided address (at the end of memory) fdt addr ${fdt_addr}
# move the blob to the (previously) default location (0x100) fdt move ${fdt_addr_r}
# make needed changes setenv bootargs "......."
# boot from the new location bootz ${kernel_addr_r} - ${fdt_addr_r}
Another solution is to force the firmware to load the blob at a fixed location (as before) by updating config.txt: device_tree_address=0x100
Regards, Cédric
Duncan Hare
714 931 7952
----- Forwarded Message ----- From: "dh@synoia.com" dh@synoia.com To: "u-boot@lists.denx.de" u-boot@lists.denx.de Cc: Cédric Schieli cschieli@gmail.com Sent: Sunday, November 13, 2016 4:08 PM Subject: FDT retrived varaibles appear to have different properties fom other u-boot variables - and are corrupted on get, set, get sequence
Cédric I move the fdt to 0x100 fdt move ${fdt_addr} 100 fdt addr 100
then fdt get value bootargs /chosen bootargs printenv bootargs bootargs=8250.nr_uarts=1 dma.dmachans=........all the boot args....... (note the space after "uarts=1)
setenv abc $bootargs fails...as does printenv $bootargs
They I tried
fdt set bootargs /chosen bootargsfdt get value bootargs /chosen bootargsbootargs=8250.nr_uarts=1 The bootargs parameter list is truncated after the first blank.
Something is not right in the world of fdt code. Duncan Hare
714 931 7952
From: Cédric Schieli cschieli@gmail.com To: dh@synoia.com Sent: Sunday, November 13, 2016 2:21 AM Subject: Re: Fw: [U-Boot] Fw: FDT pointer value, passed by the PI firmware, is not set in u-boot
Hello Duncan,
2016-11-13 3:04 GMT+01:00 dh@synoia.com:
If appending to "/chosen bootargs" (making it longer), does the fdt command automatically relocate the fdt, or does the u-boot script have to do that itself?
The fdt doc at http://www.denx.de/wiki/view/ DULG/UBootCmdFDT Is quite unclear on how the fdt size is managed, especially when the fdt is located close to the end of memory.
I'm not an expert here, but looking at cmd/fdt.c I didn't find any kind of relocation code. So I guess the safe bet is to move the blob before making any (growing) change to the tree:
# load the blob from the firmware provided address (at the end of memory) fdt addr ${fdt_addr}
# move the blob to the (previously) default location (0x100) fdt move ${fdt_addr_r}
# make needed changes setenv bootargs "......."
# boot from the new location bootz ${kernel_addr_r} - ${fdt_addr_r}
Another solution is to force the firmware to load the blob at a fixed location (as before) by updating config.txt: device_tree_address=0x100
Regards, Cédric
On Mon, Nov 14, 2016 at 12:08:23AM +0000, dh@synoia.com wrote:
Cédric I move the fdt to 0x100 fdt move ${fdt_addr} 100 fdt addr 100
then fdt get value bootargs /chosen bootargs printenv bootargs bootargs=........all the boot args.......but setenv abc $bootargs fails...as does printenv $bootargs
fdt set bootargs /chosen bootargsfdt get value bootargs /chosen bootargsbootargs=bootargs The variable name bootargs replaces the values contained in the variable bootargs in the fdt. Something is not right in the world of fdt code. Duncan Hare
I just tried this on a random platform that I have around, and do not see this problem. But also, what exactly is your end-goal here? While one can modify the fdt in memory and even modify the bootargs passed via this method, normally one will just set bootargs in the environment and let the fdt be updated by the normal mechanism (which will I suspect blow away your modifications unless bootargs is _not_ set in the environment).
participants (2)
-
dh＠synoia.com -
Tom Rini