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

H. Nikolaus Schaller hns at goldelico.com
Sun Apr 16 21:06:54 CEST 2017


Hi,

> Am 16.04.2017 um 20:55 schrieb Josua Mayer <josua.mayer at jm0.eu>:
> 
> 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...

should have been "Not 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!

Wow! Sometimes others have almost solved issues for us...

> So I will try to cherry-pick the relevant patches and see if that gets
> me any further.

I will keep fingers crossed. Sometimes cherry-picking doesn't work out well.

Hm. is it already done in v2017.03? Then we could try to rebase our stuff (hoping that we will not get too many regressions elsewhere). But again this may introduce more problems than it solves...

>> 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.

Yes, it is nicer, but sometimes it is wiser to resist touching running systems :)

BR,
Nikolaus

>> 
>>> 
>>> 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
> 
> _______________________________________________
> 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/1ba7b703/attachment-0001.asc>


More information about the Letux-kernel mailing list