[opensuse-arm] JeOS uboot-image-setup - calculate addresses automatically
Hello everyone, A few months ago I had the idea to automatically calculate fdt- and ramdisk load addresses based on their actual sizes. On IRC agraf then suggested to just guess offsets that will always hold true, and that is what I now implemented: The user now only has to specify kerneladdr. dtb and ramdisk will be put somewhere after that address. I assume that a kernel will be smaller than 63MB, and a device tree binary smaller than 1MB. The calculated addresses are then the following: fdtaddr=kerneladdr+63MB ramdiskaddr=fdtaddr+1MB I have created a submit request SR239214 implementing this automatic calculation and using it for the cubox-i. I have also attached the relevant diff so you can look at it easily. If you approve of this automatic calculation I'd encourage you to make use of it in the future! kind regards Josua Mayer
On 01.07.14 20:13, Josua Mayer wrote:
Hello everyone,
A few months ago I had the idea to automatically calculate fdt- and ramdisk load addresses based on their actual sizes. On IRC agraf then suggested to just guess offsets that will always hold true, and that is what I now implemented:
The user now only has to specify kerneladdr. dtb and ramdisk will be put somewhere after that address. I assume that a kernel will be smaller than 63MB, and a device tree binary smaller than 1MB.
The calculated addresses are then the following: fdtaddr=kerneladdr+63MB ramdiskaddr=fdtaddr+1MB
I have created a submit request SR239214 implementing this automatic calculation and using it for the cubox-i. I have also attached the relevant diff so you can look at it easily.
If you approve of this automatic calculation I'd encourage you to make use of it in the future!
kind regards Josua Mayer
addrcalc.patch
Index: uboot-image-setup.in =================================================================== --- uboot-image-setup.in (revision 554bb233fa71baf7fee2c9a136072b7f) +++ uboot-image-setup.in (working copy) @@ -204,8 +204,8 @@ ;; cuboxi) kerneladdr=0x10800100 - fdtaddr=0x18000000 - ramdiskaddr=0x18100000 + fdtaddr=calculate + ramdiskaddr=calculate
How about we make "calculate" the default? We can simply check whether the variable is empty then.
should_load_fdt=0 should_use_fdt=0 fdtfile=call_autodetectfdt @@ -218,6 +218,19 @@ kernel=zImage fi
+# calculate fdt- and ramdiskaddr from kerneladdr +# kernel needs maximum 63MB +# fdt maximum 1MB +# ramdisk can be placed anywhere after that +if [ "x$fdtaddr" = "xcalculate" ]; then
if [ ! "$fdtaddr" ]; then
+ fdtaddr=$(( $kerneladdr + 0x03F00000 )) # kernel + 63M + fdtaddr=`printf '0x%X' $fdtaddr` # convert back to hexadecimal +fi +if [ "x$ramdiskaddr" = "xcalculate" ]; then
same here. Alex
+ ramdiskaddr=$(( $fdtaddr + 0x00100000 )) # fdt + 1M + ramdiskaddr=`printf '0x%X' $ramdiskaddr` # convert back to hexadecimal +fi + initrd_high=0xffffffff fdt_high=0xffffffff
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 03.07.2014 13:48, schrieb Alexander Graf:
On 01.07.14 20:13, Josua Mayer wrote:
A few months ago I had the idea to automatically calculate fdt- and ramdisk load addresses based on their actual sizes. On IRC agraf then suggested to just guess offsets that will always hold true, and that is what I now implemented:
The user now only has to specify kerneladdr. dtb and ramdisk will be put somewhere after that address. I assume that a kernel will be smaller than 63MB, and a device tree binary smaller than 1MB.
The calculated addresses are then the following: fdtaddr=kerneladdr+63MB ramdiskaddr=fdtaddr+1MB
I have created a submit request SR239214 implementing this automatic calculation and using it for the cubox-i. I have also attached the relevant diff so you can look at it easily.
If you approve of this automatic calculation I'd encourage you to make use of it in the future!
kind regards Josua Mayer
addrcalc.patch
Index: uboot-image-setup.in =================================================================== --- uboot-image-setup.in (revision 554bb233fa71baf7fee2c9a136072b7f) +++ uboot-image-setup.in (working copy) @@ -204,8 +204,8 @@ ;; cuboxi) kerneladdr=0x10800100 - fdtaddr=0x18000000 - ramdiskaddr=0x18100000 + fdtaddr=calculate + ramdiskaddr=calculate
How about we make "calculate" the default? We can simply check whether the variable is empty then.
Disagree. We should rather stop using our own values and relying on kernel_addr_r, fdt_addr_r, initrd_addr_r if available. If the environment does not provide any hints, then falling back to our own calculations is fine with me. But us constantly overruling the firmware is not good as it makes results harder to compare. Also, if you change the default and affect existing board definitions, who is going to re-test all those images? Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 03.07.14 16:06, Andreas Färber wrote:
Am 03.07.2014 13:48, schrieb Alexander Graf:
A few months ago I had the idea to automatically calculate fdt- and ramdisk load addresses based on their actual sizes. On IRC agraf then suggested to just guess offsets that will always hold true, and that is what I now implemented:
The user now only has to specify kerneladdr. dtb and ramdisk will be put somewhere after that address. I assume that a kernel will be smaller than 63MB, and a device tree binary smaller than 1MB.
The calculated addresses are then the following: fdtaddr=kerneladdr+63MB ramdiskaddr=fdtaddr+1MB
I have created a submit request SR239214 implementing this automatic calculation and using it for the cubox-i. I have also attached the relevant diff so you can look at it easily.
If you approve of this automatic calculation I'd encourage you to make use of it in the future!
kind regards Josua Mayer
addrcalc.patch
Index: uboot-image-setup.in =================================================================== --- uboot-image-setup.in (revision 554bb233fa71baf7fee2c9a136072b7f) +++ uboot-image-setup.in (working copy) @@ -204,8 +204,8 @@ ;; cuboxi) kerneladdr=0x10800100 - fdtaddr=0x18000000 - ramdiskaddr=0x18100000 + fdtaddr=calculate + ramdiskaddr=calculate How about we make "calculate" the default? We can simply check whether
On 01.07.14 20:13, Josua Mayer wrote: the variable is empty then. Disagree. We should rather stop using our own values and relying on kernel_addr_r, fdt_addr_r, initrd_addr_r if available. If the environment does not provide any hints, then falling back to our own calculations is fine with me. But us constantly overruling the firmware is not good as it makes results harder to compare.
U-boot provided variables always overrule our own calculated ones, no?
Also, if you change the default and affect existing board definitions, who is going to re-test all those images?
The default for boards that use rd & fdt today is that they provide addresses ;). Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 03.07.2014 16:11, schrieb Alexander Graf:
On 03.07.14 16:06, Andreas Färber wrote:
Am 03.07.2014 13:48, schrieb Alexander Graf:
A few months ago I had the idea to automatically calculate fdt- and ramdisk load addresses based on their actual sizes. On IRC agraf then suggested to just guess offsets that will always hold true, and that is what I now implemented:
The user now only has to specify kerneladdr. dtb and ramdisk will be put somewhere after that address. I assume that a kernel will be smaller than 63MB, and a device tree binary smaller than 1MB.
The calculated addresses are then the following: fdtaddr=kerneladdr+63MB ramdiskaddr=fdtaddr+1MB
I have created a submit request SR239214 implementing this automatic calculation and using it for the cubox-i. I have also attached the relevant diff so you can look at it easily.
If you approve of this automatic calculation I'd encourage you to make use of it in the future!
kind regards Josua Mayer
addrcalc.patch
Index: uboot-image-setup.in =================================================================== --- uboot-image-setup.in (revision 554bb233fa71baf7fee2c9a136072b7f) +++ uboot-image-setup.in (working copy) @@ -204,8 +204,8 @@ ;; cuboxi) kerneladdr=0x10800100 - fdtaddr=0x18000000 - ramdiskaddr=0x18100000 + fdtaddr=calculate + ramdiskaddr=calculate How about we make "calculate" the default? We can simply check whether
On 01.07.14 20:13, Josua Mayer wrote: the variable is empty then.
Disagree. We should rather stop using our own values and relying on kernel_addr_r, fdt_addr_r, initrd_addr_r if available. That depends. On one hand its nice if these addresses are available *and* reasonable, e.g. providing enough space for our kernels. The
If the environment does not provide any hints, then falling back to our own calculations is fine with me. But us constantly overruling the firmware is not good as it makes results harder to compare. I agree that using provided defaults is nice, but it probably makes debugging harder instead of easier. Then we have to rely on teh
I personally dont like if(empty) do_something. Thats not verbose enough to me, instead checking for "calculate", or as an alternative "auto" seems appropriate to me since its much more descriptive and less magical. problem I see here is that board vendors dont exactly care about either zImage+dtb or ramdisks. Some use one, some the other, the last prefer uImages ... . I believe the one address that will always be known is kerneladdr. particular bootloader installed to provide the right address, and if you want to know what went wrong you need to check the bootloader configuration. I believe using our own fixed values provides comparable and stable results!
U-boot provided variables always overrule our own calculated ones, no?
Also, if you change the default and affect existing board definitions, who is going to re-test all those images?
If I personally was to change the default I'd make the boards using the current default stick with it. I could imagine setting kerneladdr="use_addr_r".
The default for boards that use rd & fdt today is that they provide addresses ;).
do you mean they provide kerneladdr, or kerneladdr_r, or both?
Alex
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 05.07.14 11:42, Josua Mayer wrote:
Am 03.07.2014 16:11, schrieb Alexander Graf:
On 03.07.14 16:06, Andreas Färber wrote:
Am 03.07.2014 13:48, schrieb Alexander Graf:
A few months ago I had the idea to automatically calculate fdt- and ramdisk load addresses based on their actual sizes. On IRC agraf then suggested to just guess offsets that will always hold true, and that is what I now implemented:
The user now only has to specify kerneladdr. dtb and ramdisk will be put somewhere after that address. I assume that a kernel will be smaller than 63MB, and a device tree binary smaller than 1MB.
The calculated addresses are then the following: fdtaddr=kerneladdr+63MB ramdiskaddr=fdtaddr+1MB
I have created a submit request SR239214 implementing this automatic calculation and using it for the cubox-i. I have also attached the relevant diff so you can look at it easily.
If you approve of this automatic calculation I'd encourage you to make use of it in the future!
kind regards Josua Mayer
addrcalc.patch
Index: uboot-image-setup.in =================================================================== --- uboot-image-setup.in (revision 554bb233fa71baf7fee2c9a136072b7f) +++ uboot-image-setup.in (working copy) @@ -204,8 +204,8 @@ ;; cuboxi) kerneladdr=0x10800100 - fdtaddr=0x18000000 - ramdiskaddr=0x18100000 + fdtaddr=calculate + ramdiskaddr=calculate How about we make "calculate" the default? We can simply check whether
On 01.07.14 20:13, Josua Mayer wrote: the variable is empty then. I personally dont like if(empty) do_something. Thats not verbose enough to me, instead checking for "calculate", or as an alternative "auto" seems appropriate to me since its much more descriptive and less magical.
Fair enough. Either way it's an improvement :). Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
participants (3)
-
Alexander Graf -
Andreas Färber -
Josua Mayer