Now that the subject came up, maybe it's good to exchange some ideas here.
Building the DTB is one thing. But we have to get it on the target as well.
Currently, a bitbake virtual/kernel will also build one or more dtb
files, and put them in the directory where the images will end up. It's
up to the user to make it so that the blobs actually get programmed onto
the target. Nothing wrong with that.
At some point, I thought it would be a good idea to be able to upgrade
boards "in the field". So I added a postinstall script to the kernel to
deploy in "/tmp/boot" instead of "/boot" and then make it write itself
into the flash device or onto the FAT partition on the SD card, or
whatever other method I came up with to load the kernel.
Now for the devicetree, I thought I could just include the
"kernel-devicetree" package onto my system, add a bit of script, and
that would allow me to have devices upgrade themselves.
The "kernel-devicetree" package contains multiple DTB files. I would
expect a target to actually use only one, and that the various dtb files
are intended for different targets. I think it would make sense to split
that single package into a package for each DTB file. Then you can pick
and choose which dtb you want on your target.
Another issue is that the kernel-devicetree package postinstall script
calls "awk" and "update-alternatives". Those must therefore be present
on the target, if you expect to be able to install or upgrade it. As far
as I can see, the only reason for using these tools is to create a
symbolic link. As far as I know, no other package provides a dtb file.
So why is it registering itself as an alternative?
And I was just wondering, how do you guys handle upgrading kernel,
bootloader and devicetree files?
Met vriendelijke groet / kind regards,
Mike Looijmans
TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) – (0)499 - 33.69.79
Telefax: (+31) - (0)499 - 33.69.70
E-mail: [email protected]
Website: www.topic.nl
Dit e-mail bericht en de eventueel daarbij behorende bijlagen zijn uitsluitend
bestemd voor de geadresseerde, zoals die blijkt uit het e-mail bericht en/of de
bijlagen. Er kunnen gegevens met betrekking tot een derde instaan. Indien u als
niet-geadresseerde dit bericht en de bijlagen ontvangt, terwijl u niet bevoegd
of gemachtigd bent om dit bericht namens de geadresseerde te ontvangen, wordt u
verzocht de afzender hierover direct te informeren en het e-mail bericht met de
bijlagen te vernietigen. Ieder gebruik van de inhoud van het e-mail bericht,
waaronder de daarbij behorende bijlagen, door een ander dan de geadresseerde is
onrechtmatig jegens ons dan wel de eventueel in het e-mail bericht of de
bijlagen voorkomende andere personen. TOPIC Embedded Systems is niet
aansprakelijk voor enigerlei schade voortvloeiend uit het gebruik en/of
acceptatie van dit e-mail bericht of de daarbij behorende bijlagen.
The contents of this message, as well as any enclosures, are addressed
personally to, and thus solely intended for the addressee. They may contain
information regarding a third party. A recipient who is neither the addressee,
nor empowered to receive this message on behalf of the addressee, is kindly
requested to immediately inform the sender of receipt, and to destroy the
message and the enclosures. Any use of the contents of this message and/or the
enclosures by any other person than the addressee or person who is empowered to
receive this message, is illegal towards the sender and/or the aforementioned
third party. TOPIC Embedded Systems is not liable for any damage as a result
of the use and/or acceptance of this message and as well as any enclosures.
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
