[U-Boot] Fw: FDT retrived varaibles appear to have different properties fom other u-boot variables - and are corrupted on get, set, get sequence

[dh at synoia.com]

> 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).

-- 
Tom
Thank you for you interest.
We have enterprise IT backgrounds. Change management, security and cost management are our focus.


In the raspberry p (or other soc devices) for the desktop we want to load the kernel and optionally a dtb from a file server, based, change status (build, test, trial, production, and other yet undefined rules), board and OS type (e.g. 32 bit or 54 bit) and pass the DHCP information to the kernel on OS start up.
We want only firmware, u-boot and u-boot script files on the sd card. All the Linux kernel and filesystem on a server. This is because we want to mange a large number of devices form an image server, and centralized image control is the most cost effective and secure mechanism to achieve this. The concept of changing hundreds or thousands of sd cards in an enterprise is difficult.
The Pi uses firmware to process two files, config.txt (for bootargs video parameters) and cmdline.txt (bootargs other than video parameters), which are build into an fdt for the kernel's use.

Two points of discussion:

1) I retrieved the bootargs from the fdt with the recommended set of 3 u-boot commands, but could not append ip address or other information from u-boot's DHCP command, or the boot environment, to the bootargs variable. 

2) When I save the retrieved pi bootargs back to the fdt, and then retrieve it again, the set/get mechanism truncated the bootargs line at the first blank.
The PI firmware generated bootargs parameters have blanks in the bootargs line. 

Thanks Duncan