[Letux-kernel] Letux U-Boot 2016.11 for GTA04

Sun Apr 16 16:06:15 CEST 2017

Hi Josua,

> Am 16.04.2017 um 15:18 schrieb Josua Mayer <josua.mayer at jm0.eu>:
> 
> Hi Nikolaus,
> 
> It's been a while, and I finally got around to looking at this subject once more:

yes, holidays with not so nice weather gives a good opportunity to look at things... I am currently taking another look into the camera driver...

> So the variables in question are usually set in the include/configs/<board>.h file. We should be doing the same thing for the GTA04 / letux devices.
> 
> However right now there is an onion-chain involved:
> letux_gta04bY.h -> letux_gta04.h -> letux_beagle.h -> omap3_beagle.h
> 
> So the most natural place to implement distro support is omap3_beagle.h.
> Now why is this a problem? omap3_beagle.h does *not* implement distro support. Furthermore it has a huge set of predefined environment variables where there is great danger of breaking stuff, and much care has to be taken.
> Furthermore this huge number of preexisting environment variables are confusing to newcomers.

No only for newcomers...

> 
> I believe include/configs/mx6cuboxi.h is a good example for minimum set of variables.
> 1)
> I would much more prefer a minimal clean-room implementation. Is there a good reason to carry all the magic that has been done for the beagleboard? Or would it be reasonably easy coming up with a self-contained letux_gta04.h?

Well, the problem is that I did not want to touch it too much. I simply assume(d) that they know what they do in omap3_beagle.h and every variable must have reason to be there (even if I don't understand it). And a big team has tested it (at least I hope).

So the philosophy is: if the BeagleBoard stuff is "good enough" and does not harm, let's keep it. Never touch a running system... Considering the scarce resources we have, such a philosophy saves us time...

Therefore I prefer to focus on kernel and rootfs. IMHO U-Boot just must be hacked to work and then be left alone for the next years :)

So the "must be hacked and be left alone" strategy would mean that we just add code to set the _r variables as needed.
Maybe you can propose a patch?

The alternative would be that we ask BeagleBoard U-Boot maintainers if there is some distro support planned in omap3_beagle.h. Then we could simply rebase on newer U-Boot and get their changes into our code as well.

So it boils down to:
- yes, a clean self-contained letux_beagle.h (not letux_gta04.h because the same U-Boot should run on a BeagleBoard) would be a nice thing
- no, because it is additional work that does not improve kernel and user-space

Let's throw dice :)

> 
> 
> 2)
> most boards seem to implement findfdt as a set of u-boot commands that parse variables such as board_name, board_rev provided by the boardfile, to set the fdtfile variable.
> Why is this logic currently in the boardfile?

Because it was before in our old 2011 based U-Boot and omap boards don't do it that way. And it is quite simple... And does not depend on u-boot commands or specific boot scripts. And can't be disturbed by the user. So it should be more reliable.

The real reason is that it was easier to hack into the board file than into the boot variables.

> 
> I don't think it makes a big difference, but its name should definitely be changed from devicetree to fdtfile.

The "mux" and "devicetree" variables are outdated and are there only for compatibility reasons to older kernels (e.g. if you want to boot our 3.12) and boot systems. I think they are not used any more but also should not harm if they exist.

BR,
Nikolaus

> 
> 
> br
> Josua Mayer
> 
> Below snippet for history reasons, feel free to drop in replies
> Am 18.02.2017 um 17:18 schrieb H. Nikolaus Schaller:
>> ...
>> 
>> 
>>> 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?
> the board config file in include/configs/
>> 
>>> 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:
>> 
>> 
>> http://projects.goldelico.com/p/gta04-uboot/issues/
> So
>> 
>> BR,
>> Nikolaus
>> 
>> 
>> 
>> 
>> _______________________________________________
>> 
>> http://projects.goldelico.com/p/gta04-kernel/
>> 
>> Letux-kernel mailing list
>> 
>> Letux-kernel at openphoenux.org
>> http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel
> 
> _______________________________________________
> http://projects.goldelico.com/p/gta04-kernel/
> Letux-kernel mailing list
> Letux-kernel at openphoenux.org
> http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.goldelico.com/pipermail/letux-kernel/attachments/20170416/d1a2bdb0/attachment.asc>