[Letux-kernel] Letux U-Boot 2016.11 for GTA04
H. Nikolaus Schaller
hns at goldelico.com
Sat Feb 18 17:18:42 CET 2017
> Am 18.02.2017 um 17:06 schrieb Josua Mayer <josua.mayer at jm0.eu>:
> Am 18.02.2017 um 16:06 schrieb H. Nikolaus Schaller:
>> Hi Josua,
>>> Am 18.02.2017 um 14:05 schrieb Josua Mayer <josua.mayer at jm0.eu>
>>> Hi everybody,
>>> during my latest attempts at booting standard debian, I was hit by
>>> fdtaddr just like Andreas was previously.
>> What is the problem with fdtaddr?
> It is set to some value that does not work.
> In your boot.scr you actually initialize loadaddrfdt to something else, and then use this.
Yes. Most likely this fdtaddr didn't exist in the old u.boot 2011.03 we used earlier.
>>> I believe it would be very beneficial if we implemented standard
>>> variable names for the most important addresses such as DeviceTree,
>>> Kernel and Ramdisk.
>>> U-Boot has a standard for this which is documented as part of their
>>> Distro Boot Script.
>>> Please see doc/README.distro: section U-Boot Implementation
>> I have looked into it a little and I understand that there is ftd_addr
>> but that should be a ROM address where the fdt is located. We have no
>> ROM. And there is fdt_addr_r where it should be loaded to. This is probably
>> what we use the fdtaddr for.
> Yes, the _r addresses are the one I refer to. Distros that provide a boot.scr for loading their kernel, dtb and initrd rely on having these well-known names available. They should be:
> fdt_addr_r, kernel_addr_r, ramdisk_addr_r, scriptaddr
> We do not need to set pxefile_addr_r as we do not have meaningful networking within u-boot.
Ok. Who should set them? boot.scr?
> As to fdt_addr, you are right tehre is no such rom. Thus do not set.
>> But I also understand that this is only relevant when using the U-Boot
>> "syslinux" and "pxe boot" commands. We use neither one.
> that readme suggests its all about syslinux. But the distro boot script actually does much more. In order it looks for boot.scr, syslinux.cfg and idkwhat else, on all availabel storage mediums.
> The search order is specified in code using some macro I can dig out if necessary.
>>> Perhaps we should also review any other environment variables that are
>>> set as part of u-boot code, and see what is strictly required.
>> AFAIK not much.
>> Anyways I assume things will improve with future U-Boot releases upstream,
> The distro support is one of those improvements.
> For one a boot.scr is still searched, so that after migrating to this everything still works as expected.
> On the other hand, we could potentially boot any distro without messing with the way it decided to implement their images. Be it syslinux.cfg or a boot.scr utilizing above variables.
Ok, I see.
>> but for the moment we don't have enough manpower to work on all construction
>> sites in parallel...
>> So I'd like to understand the problem first.
> Common names for variables on all platform, and only *one* variable for each magic number.
Needs a little time to update. Let's make a note in the Issues tracker:
Oh, I see we have not fixed the backlight issue for 7 years... I think we can close it :)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the Letux-kernel