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

Josua Mayer josua.mayer at jm0.eu
Sun Apr 16 20:55:09 CEST 2017


Hi Nikolaus,

Am 16.04.2017 um 16:06 schrieb H. Nikolaus Schaller:
> 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.
Guess what: It has been done.
I just checked mainline u-boot, and omap3_beagle now uses it!
So I will try to cherry-pick the relevant patches and see if that gets
me any further.
> 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 :)
I really like the yes part, but it is a lot of work.
>
>>
>> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 512 bytes
Desc: OpenPGP digital signature
URL: <http://lists.goldelico.com/pipermail/letux-kernel/attachments/20170416/00842182/attachment.asc>


More information about the Letux-kernel mailing list