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:
>> 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
>>> 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:
>>> 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
>>> Index: uboot-image-setup.in
>>> --- uboot-image-setup.in (revision 554bb233fa71baf7fee2c9a136072b7f)
>>> +++ uboot-image-setup.in (working copy)
>>> @@ -204,8 +204,8 @@
>>> - 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.
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.
> 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
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
> 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
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
The default for boards that use rd & fdt today is that they provide
do you mean they provide kerneladdr, or kerneladdr_r, or both?
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org