[U-Boot] FDT pointer value, passed by the PI firmware, is not set in u-boot

[U-Boot] FDT pointer value, passed by the PI firmware, is not set in u-boot

[dh at synoia.com]

I'm willing to make this change to set the FDT address and test this. Where in the u-boot code should the change be made?

per this thread: https://www.raspberrypi.org/forums/viewtopic.php?t=134018
The DTB start address is size dependent. The aim is to copy the DTB as high as possible. Once the kernel starts it will "unflatten" the DTB into allocated memory and then re-use the space.

ARM memory starts at 0 in the VPU physical address space. The GPU memory sits at the top. This is how it works:Code: Select all
 ARMMEM_END = MEM_SIZE - GPU_MEM// Leave 64KB for GRUB
free_end = ALIGN_DOWN(ARMMEM_END - 0x10000, 0x1000)

// Leave space for initramfs, if there is one
free_end = ALIGN_DOWN(free_end - initramfs_size, 0x1000)

device_tree_address = ALIGN_DOWN(free_end - device_tree_size, 0x100)
Don't forget that the address of the DTB is passed in register r2 to the kernel/U-boot entry point, with r0 holding 0 and r1 being 3138 (the BCM2708 machine id).?Duncan Hare

714 931 7952

[U-Boot] Fw: FDT pointer value, passed by the PI firmware, is not set in u-boot

[dh at synoia.com]

I modified the current u-boot code to store r2 in rpi.c board_init, but only get a zero value from the register.

It could be one of three issues:
1. My use of the c asm statement? to store r2 is wrong (I've never done this before), assembler yes, c assembler no.
2. The compiler has consumed the value of r2 before getting to board_init
3. The pi firmware does not put the fdt value in r2.

asm statement to store r2 is asm("mov %%r2, %0" : "=r" (gd->bd->bpi_boot_parms) ); 

In order to use up Marco's ATAG and FDT code.

What the earliest place where I can store the input r2 value?
Hopefully, I'm putting the r2 value into gd->bd->bpi_boot_parms in board_init, but it appear it is zero at that point.

Should I restrict the compiler's use of r2? (I'm reluctant to limit the compiler in that manner)?

Suggestion would be welcome.

Thanks?Duncan Hare

714 931 7952

   

   

   

[U-Boot] Fw: FDT pointer value, passed by the PI firmware, is not set in u-boot

[Simon Glass]

Hi,

On 19 September 2016 at 21:50,  <dh@synoia.com> wrote:
>
> I modified the current u-boot code to store r2 in rpi.c board_init, but only get a zero value from the register.
>
> It could be one of three issues:
> 1. My use of the c asm statement  to store r2 is wrong (I've never done this before), assembler yes, c assembler no.
> 2. The compiler has consumed the value of r2 before getting to board_init
> 3. The pi firmware does not put the fdt value in r2.
>
> asm statement to store r2 is asm("mov %%r2, %0" : "=r" (gd->bd->bpi_boot_parms) );
>
> In order to use up Marco's ATAG and FDT code.
>
> What the earliest place where I can store the input r2 value?

You could try save_boot_params(). Some boards use that. But gd is not
available then - perhaps you could put it in a variable in the data
segment?

> Hopefully, I'm putting the r2 value into gd->bd->bpi_boot_parms in board_init, but it appear it is zero at that point.
>
> Should I restrict the compiler's use of r2? (I'm reluctant to limit the compiler in that manner)?
>
> Suggestion would be welcome.
>
> Thanks Duncan Hare
>
> 714 931 7952

Regards,
Simon

>
>
>
>
>
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] FDT retrived varaibles appear to have different properties fom other u-boot variables

[dh at synoia.com]

I have retrieved a string? "fdt get value bootargs /chosen bootargs" 

But, when I try "setenv a $bootargs" I get the error message:
setenv [-f] name value...
Is appears the variable set by the "fdt get" command hasdifferent properties from a u-boot variable where the content are available with $ operator.
The string variables retrieved with the fdt command appear to have different properties then strings in the u-boot variables. 

I can printenv bootargs, I cannot append to it by 
setenv ip ip=102.168.1.97
"setenv a $bootargs $ip"

Is this by design or is it a bug?

Duncan Hare

714 931 7952

     

   

[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 correction

[dh at synoia.com]

?Duncan Hare

714 931 7952

     
----- Forwarded Message -----
 From: "dh at synoia.com" <dh@synoia.com>
 To: "u-boot at 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 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