[U-Boot] FDT retrived raspberry pi bootargs length > 350 characters cause setenv errors, sequemce fdt get/ set/ get truncates at the first blank in the string.

[U-Boot] FDT retrived raspberry pi bootargs length > 350 characters cause setenv errors, sequemce fdt get/ set/ get truncates at the first blank in the string.

[Anatolij Gustschin]

On Wed, 23 Nov 2016 20:46:22 +0000 (UTC)
dh at synoia.com dh at synoia.com wrote:

>On Wed, 23 Nov 2016 01:26:22 +0000 (UTC)
>dh at synoia.com dh at synoia.com wrote:
>...
>> 8250.nr_uarts=0 dma.dmachans=0x7f35 bcm2708_fb.fbwidth=3840 bcm2708_fb.fbheight=2160 bcm2709.boardrev=0xa02082 bcm2709.serial=0x998f552d smsc95xx.macaddr=B8:27:EB:8F:55:2D bcm2708_fb.fbswap=1 bcm2709.uart_clock=48000000 vc_mem.mem_base=0x3dc00000 vc_mem.mem_size=0x3f000000? dwc_otg.lpm_enable=0 console=ttyS0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
>> 1 ) Note: bootargs is over 480 characters long
>>
>> setenv abc $bootargs fails...when bootargs is over 350 (approx) characters long.?
>> fdt set bootargs /chosen bootargs
>> fdt get value bootargs /chosen bootargsbootargs=8250.nr_uarts=0Bootargs is truncated
>> The PI firmware generated bootargs parameters have blanks in the bootargs line.?
>> nvalue.c implements setenv in the _do_env_set()? routine, but I cannot find a length limit in that routine.
>> I'm willing to make the changes and test them.  
>
>please check CONFIG_SYS_MAXARGS and CONFIG_SYS_BARGSIZE and increase
>them in your board config file (include/configs/rpi.h ?). See README
>for description of these macros.
>If CONFIG_SYS_BARGSIZE is not defined, the default value 512 is used.
>Define a bigger value and test if it works.
>
>Also if you set long environment strings manually with console
>commands, the console input buffer might be to small. In that
>case check CONFIG_SYS_CBSIZE in your board config file.
>
>
>Set:
>CONFIG_SYS_MAXARGS ????32
>CONFIG_SYS_BARGSIZE???? 1024
>
>Success! This works.
>
>Console is not a problem, I cannot type that many characters without
>an error or two.

okay, I just wanted to mention CONFIG_SYS_CBSIZE for the sake
of completeness.

>Issue possibly remaining:
>sequence fdt get/ set/ get truncates bootargs at the first blank
>in the string of bootargs.
>This is only a problem if bootargs is passed to the kernel through
>the fdt, and not as separate character string. I do not know which
>is the mechanism used.
>Further testing on this remains.

In your description above I see the command:

 fdt set bootargs /chosen bootargs

This is wrong and could not work. You probably used:

 fdt set /chosen bootargs $bootargs

It will insert multiple tokens separated by comma, e.g.:

=> setenv bootargs 'arg1 arg2 arg3'
=> fdt set /chosen bootargs $bootargs
=> fdt pri /chosen                   
chosen {
	bootargs = "arg1", "arg2", "arg3";
};
=> fdt get value bootargs /chosen bootargs
=> pri bootargs
bootargs=arg1

This is the behaviour you observe.

To avoid tokenizing the bootargs property in the blob you have
to use an intermediate step, e.g.:

=> seten args "\"$bootargs\""
=> pri args
args="arg1 arg2 arg3"

=> fdt set /chosen bootargs $args
=> fdt pri /chosen
chosen {
	bootargs = "arg1 arg2 arg3";
};

=> fdt get value bootargs /chosen bootargs
=> pri bootargs
bootargs=arg1 arg2 arg3

--
Anatolij

[U-Boot] FDT retrived raspberry pi bootargs length > 350 characters cause setenv errors, sequemce fdt get/ set/ get truncates at the first blank in the string.

[dh at synoia.com]

From: Anatolij Gustschin <agust@denx.de>
 To: dh at synoia.com 
Cc: Tom Rini <trini@konsulko.com>; u-boot <u-boot@lists.denx.de>
 Sent: Thursday, November 24, 2016 1:12 AM
 Subject: Re: [U-Boot] FDT retrived raspberry pi bootargs length > 350 characters cause setenv errors, sequemce fdt get/ set/ get truncates at the first blank in the string.
   
On Wed, 23 Nov 2016 20:46:22 +0000 (UTC)
dh at synoia.com dh at synoia.com wrote:

>On Wed, 23 Nov 2016 01:26:22 +0000 (UTC)
>dh at synoia.com dh at synoia.com wrote:
>...
>> 8250.nr_uarts=0 dma.dmachans=0x7f35 bcm2708_fb.fbwidth=3840 bcm2708_fb.fbheight=2160 bcm2709.boardrev=0xa02082 bcm2709.serial=0x998f552d smsc95xx.macaddr=B8:27:EB:8F:55:2D bcm2708_fb.fbswap=1 bcm2709.uart_clock=48000000 vc_mem.mem_base=0x3dc00000 vc_mem.mem_size=0x3f000000? dwc_otg.lpm_enable=0 console=ttyS0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
>> 1 ) Note: bootargs is over 480 characters long
>>
>> setenv abc $bootargs fails...when bootargs is over 350 (approx) characters long.?
>> fdt set bootargs /chosen bootargs
>> fdt get value bootargs /chosen bootargsbootargs=8250.nr_uarts=0Bootargs is truncated
>> The PI firmware generated bootargs parameters have blanks in the bootargs line.?
>> nvalue.c implements setenv in the _do_env_set()? routine, but I cannot find a length limit in that routine.
>> I'm willing to make the changes and test them.? 
>
>please check CONFIG_SYS_MAXARGS and CONFIG_SYS_BARGSIZE and increase
>them in your board config file (include/configs/rpi.h ?). See README
>for description of these macros.
>If CONFIG_SYS_BARGSIZE is not defined, the default value 512 is used.
>Define a bigger value and test if it works.
>
>Also if you set long environment strings manually with console
>commands, the console input buffer might be to small. In that
>case check CONFIG_SYS_CBSIZE in your board config file.
>
>
>Set:
>CONFIG_SYS_MAXARGS ????32
>CONFIG_SYS_BARGSIZE???? 1024
>
>Success! This works.
>
>Console is not a problem, I cannot type that many characters without
>an error or two.

okay, I just wanted to mention CONFIG_SYS_CBSIZE for the sake
of completeness.

>Issue possibly remaining:
>sequence fdt get/ set/ get truncates bootargs at the first blank
>in the string of bootargs.
>This is only a problem if bootargs is passed to the kernel through
>the fdt, and not as separate character string. I do not know which
>is the mechanism used.
>Further testing on this remains.

In your description above I see the command:

 fdt set bootargs /chosen bootargs

This is wrong and could not work. You probably used:

 fdt set /chosen bootargs $bootargs

It will insert multiple tokens separated by comma, e.g.:

=> setenv bootargs 'arg1 arg2 arg3'
=> fdt set /chosen bootargs $bootargs
=> fdt pri /chosen? ? ? ? ? ? ? ? ? 
chosen {
??? bootargs = "arg1", "arg2", "arg3";
};
=> fdt get value bootargs /chosen bootargs
=> pri bootargs
bootargs=arg1

This is the behaviour you observe.

To avoid tokenizing the bootargs property in the blob you have
to use an intermediate step, e.g.:

=> seten args "\"$bootargs\""
=> pri args
args="arg1 arg2 arg3"

=> fdt set /chosen bootargs $args
=> fdt pri /chosen
chosen {
??? bootargs = "arg1 arg2 arg3";
};

=> fdt get value bootargs /chosen bootargs
=> pri bootargs
bootargs=arg1 arg2 arg3

--
Anatolij
That works well. Thank you for you help.
Duncan Hare


   

[U-Boot] 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]

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 at 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


   

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

[Tom Rini]

On Mon, Nov 14, 2016 at 12:08:23AM +0000, dh at 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).

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161117/ddf7b7a9/attachment.sig>

[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 


   

   

[U-Boot] FDT retrived raspberry pi bootargs length > 350 characters cause setenv errors, sequemce fdt get/ set/ get truncates at the first blank in the string.

[dh at synoia.com]

?

Imove the fdt to 0x100
fdt move ${fdt_addr}? 100
fdt addr 100
?
then
fdt get value bootargs /chosen bootargs
printenv bootargs 

8250.nr_uarts=0 dma.dmachans=0x7f35 bcm2708_fb.fbwidth=3840 bcm2708_fb.fbheight=2160 bcm2709.boardrev=0xa02082 bcm2709.serial=0x998f552d smsc95xx.macaddr=B8:27:EB:8F:55:2D bcm2708_fb.fbswap=1 bcm2709.uart_clock=48000000 vc_mem.mem_base=0x3dc00000 vc_mem.mem_size=0x3f000000? dwc_otg.lpm_enable=0 console=ttyS0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
1 ) Note: bootargs is over 480 characters long

setenv abc $bootargs fails...when bootargs is over 350 (approx) characters long.?
fdt set bootargs /chosen bootargs 
fdt get value bootargs /chosen bootargsbootargs=8250.nr_uarts=0Bootargs is truncated
The PI firmware generated bootargs parameters have blanks in the bootargs line.?
nvalue.c implements setenv in the _do_env_set()? routine, but I cannot find a length limit in that routine.
I'm willing to make the changes and test them.

Thanks?Duncan 


   

   

 

  

[U-Boot] FDT retrived raspberry pi bootargs length > 350 characters cause setenv errors, sequemce fdt get/ set/ get truncates at the first blank in the string.

[Anatolij Gustschin]

On Wed, 23 Nov 2016 01:26:22 +0000 (UTC)
dh at synoia.com dh at synoia.com wrote:
...
> 8250.nr_uarts=0 dma.dmachans=0x7f35 bcm2708_fb.fbwidth=3840 bcm2708_fb.fbheight=2160 bcm2709.boardrev=0xa02082 bcm2709.serial=0x998f552d smsc95xx.macaddr=B8:27:EB:8F:55:2D bcm2708_fb.fbswap=1 bcm2709.uart_clock=48000000 vc_mem.mem_base=0x3dc00000 vc_mem.mem_size=0x3f000000? dwc_otg.lpm_enable=0 console=ttyS0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
> 1 ) Note: bootargs is over 480 characters long
> 
> setenv abc $bootargs fails...when bootargs is over 350 (approx) characters long.?
> fdt set bootargs /chosen bootargs 
> fdt get value bootargs /chosen bootargsbootargs=8250.nr_uarts=0Bootargs is truncated
> The PI firmware generated bootargs parameters have blanks in the bootargs line.?
> nvalue.c implements setenv in the _do_env_set()? routine, but I cannot find a length limit in that routine.
> I'm willing to make the changes and test them.

please check CONFIG_SYS_MAXARGS and CONFIG_SYS_BARGSIZE and increase
them in your board config file (include/configs/rpi.h ?). See README
for description of these macros.

If CONFIG_SYS_BARGSIZE is not defined, the default value 512 is used.
Define a bigger value and test if it works.

Also if you set long environment strings manually with console
commands, the console input buffer might be to small. In that
case check CONFIG_SYS_CBSIZE in your board config file.

--
Anatolij