On Mon, 2020-07-20 at 18:21 +0100, Usama Arif wrote: > On 20/07/2020 08:41, Richard Purdie via lists.openembedded.org wrote: > > On Fri, 2020-07-17 at 15:19 +0100, Usama Arif wrote: > > > This patch adds support for adding default config node even > > > when dtb is not part of the FIT image. The conf options are > > > therefore changed to point to kernel ID rather than dtb > > > ID when dtb does not exist. > > > > > > Signed-off-by: Usama Arif <usama.a...@arm.com> > > > --- > > > meta/classes/kernel-fitimage.bbclass | 14 ++++++++++++-- > > > 1 file changed, 12 insertions(+), 2 deletions(-) > > > > I keep asking someone to start providing tests for kernel-fitimage > > but nobody does. Its near impossible to tell whether this is a good > > change or one that could cause someone else problems as we have > > little documented behaviour and no tests. > > > > Could someone please start looking at adding some (and > > documentation)? > > There are different components that can be added to a FIT image. > This include kernel, ramdisk, dtb, etc. However, it is not necessary > for any individual component to be part of the FIT image. In reality, > you can have 0-N (0 to N) kernels and/or 0-N ramdisks and/or 0-N > dtbs. > > However, kernel-fitimage.bbclass currently only supports limited > usescases: adding 1 (no more or less) kernel with 1-N dtbs and 0-1 > ramdisks. > > Before support was added for multiple dtbs, the configuration of FIT > image without any dtbs was supported. > > This patchset adds back the original support to kernel- > fitimage.bbclass > for building a FIT image when no dtbs are present. i.e. adds support > for > 1 kernel with 0-N dtbs. It doesnot affect the existing usecases, but > adds back support for a usecase (0 dtb) that originally existed and > was > removed as a mistake. > > I have submitted a v2 of this patch which better documents the code I > have submitted so that hopefully its not blocked on the testing and > documentation of the entire kernel-fitimage. It also always creates a > configuration for FIT image. > > I guess i have spent some time debugging kernel-fitimage so am happy > to help with the documentation. I guess you would like a high level > description of kernel-fitimage at the top of this file as a seperate > patch? > > I havent worked with the test framework for oe-core so not sure how > helpful i could be on that. I tried to look for example test cases > that > would test any of the existing meta/classes/kernel*.bbclass but > couldnt > find any. > > Hopefully the extra documentation in v2 and the explanation would be > useful in understanding and progressing this patch.
Sorry for the delayed reply. Thanks for adding the extra info, it does help. By documentation, I mean that kernel-fitimage.bbclass has no information in the reference manual: https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#ref-classes-kernel-fitimage generated from: http://git.yoctoproject.org/cgit.cgi/yocto-docs/tree/documentation/ref-manual/ref-classes.xml and also there is also no header at the start of the class saying what it does or how to use it. Could we add something to these locations to give more information about the class? For testing, have a look at meta/lib/oeqa/selftest/cases/imagefeatures.py. Its testing target image rootfs settings but I believe the concept is similar to how you'd test something like the kernel-fitimage class. You can run these tests individually with "oe-selftest -r imagefeatures" to run that file or "oe-selftest -r imagefeatures.ImageFeatures.test_bmap" as an example of a specific test. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#140979): https://lists.openembedded.org/g/openembedded-core/message/140979 Mute This Topic: https://lists.openembedded.org/mt/75612723/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
