yocto-bsp create

yocto-bsp create

[Chris Tapp]

I've been looking at using yocto-bsp to create a BSP. Good job! Looks like it's going to be much easier to do it this way :-)

I've got a few questions/comments:

1) The documentation (7.0.1) says that the machine branch defaults to standard/default, but that is not an option that gets presented when I created a BSP. Should that be standard/base, standard/default/base, or something else? Master shows this as standard/default/common-pc, but that still isn't one of the listed options (standard/default/common-pc/base ?).

2) What are these machine branches anyway? As in, how do I decide which one I should choose? For an ALIX 3D3 system I used standard/default/common-pc/base. Is that reasonable?

3) I selected core2 as the tune option and then had to change this in the created meta-data as I needed i586 tuning and this was not given as a tune option. Should all available tunes be offered?

4) Is there any way to select the kernel CPU (I got MATOM but needed MGEODE_LX - easily changed in the <mybsp>.cfg file)?

5) The created BSP refers to various feature/x/y.scc files. Are these documented somewhere so that they can be easily re-used, or am I better off simply producing a complete defconfig? A pointer to the documentation for the whole kernel meta data structure would also be helpful.

Chris Tapp

opensource@keylevel.com
www.keylevel.com

Re: yocto-bsp create

[Bruce Ashfield]

On 12-08-15 04:06 PM, Chris Tapp wrote:
> I've been looking at using yocto-bsp to create a BSP. Good job! Looks like it's going to be much easier to do it this way :-)

You really want TomZ to answer, but I'll throw in a few comments
here, since I'm currently reviewing a batch of code from Tom.

>
> I've got a few questions/comments:
>
> 1) The documentation (7.0.1) says that the machine branch defaults to standard/default, but that is not an option that gets presented when I created a BSP. Should that be standard/base, standard/default/base, or something else? Master shows this as standard/default/common-pc, but that still isn't one of the listed options (standard/default/common-pc/base ?).

For the 3.2 tree, it is standard/default/base, which is a name that we
quickly determined was not optimal, and in the 3.4 kernel tree it is 
standard/base.
So the answer is, it depends on the kernel you are using, but the tools
know and have the right defaults.

>
> 2) What are these machine branches anyway? As in, how do I decide which one I should choose? For an ALIX 3D3 system I used standard/default/common-pc/base. Is that reasonable?

They are collections of functionality and configuration. So if you are
working on a new machine that is close to something that is already
in tree, you'd start from the existing machine branch. If you want to
do something new, standard/base, if you want the preempt-rt kernel,
standard/preempt-rt/base, etc.

>
> 3) I selected core2 as the tune option and then had to change this in the created meta-data as I needed i586 tuning and this was not given as a tune option. Should all available tunes be offered?
>
> 4) Is there any way to select the kernel CPU (I got MATOM but needed MGEODE_LX - easily changed in the<mybsp>.cfg file)?

AFAIK, no. Since that would imply that all the kernel tunings were parsed
and made available. Adding it to your .cfg is the right thing. If
there is a BSP that already falls into your class, and you inherit
it, you'd get the right tuning by default.

>
> 5) The created BSP refers to various feature/x/y.scc files. Are these documented somewhere so that they can be easily re-used, or am I better off simply producing a complete defconfig? A pointer to the documentation for the whole kernel meta data structure would also be helpful.

Tom and I were working on a way to dump these, I'm not sure if that
ever completed. The meta branch of the kernel repo has all the details,
with short descriptions in the .scc files.

As with anything, documenting a moving source code target is hard, so
I suggest looking at the branch.

Have a look at the 3.4 kernel tree, meta branch, there's a README with
details about the categories, and contents.

Cheers,

Bruce

>
> Chris Tapp
>
> opensource@keylevel.com
> www.keylevel.com
>
>
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: yocto-bsp create

[Chris Tapp]

On 15 Aug 2012, at 21:14, Bruce Ashfield wrote:

> On 12-08-15 04:06 PM, Chris Tapp wrote:
>> I've been looking at using yocto-bsp to create a BSP. Good job! Looks like it's going to be much easier to do it this way :-)
> 
> You really want TomZ to answer, but I'll throw in a few comments
> here, since I'm currently reviewing a batch of code from Tom.
> 
>> 
>> I've got a few questions/comments:
>> 
>> 1) The documentation (7.0.1) says that the machine branch defaults to standard/default, but that is not an option that gets presented when I created a BSP. Should that be standard/base, standard/default/base, or something else? Master shows this as standard/default/common-pc, but that still isn't one of the listed options (standard/default/common-pc/base ?).
> 
> For the 3.2 tree, it is standard/default/base, which is a name that we
> quickly determined was not optimal, and in the 3.4 kernel tree it is standard/base.
> So the answer is, it depends on the kernel you are using, but the tools
> know and have the right defaults.
> 
>> 
>> 2) What are these machine branches anyway? As in, how do I decide which one I should choose? For an ALIX 3D3 system I used standard/default/common-pc/base. Is that reasonable?
> 
> They are collections of functionality and configuration. So if you are
> working on a new machine that is close to something that is already
> in tree, you'd start from the existing machine branch. If you want to
> do something new, standard/base, if you want the preempt-rt kernel,
> standard/preempt-rt/base, etc.
> 
>> 
>> 3) I selected core2 as the tune option and then had to change this in the created meta-data as I needed i586 tuning and this was not given as a tune option. Should all available tunes be offered?
>> 
>> 4) Is there any way to select the kernel CPU (I got MATOM but needed MGEODE_LX - easily changed in the<mybsp>.cfg file)?
> 
> AFAIK, no. Since that would imply that all the kernel tunings were parsed
> and made available. Adding it to your .cfg is the right thing. If
> there is a BSP that already falls into your class, and you inherit
> it, you'd get the right tuning by default.
> 
>> 
>> 5) The created BSP refers to various feature/x/y.scc files. Are these documented somewhere so that they can be easily re-used, or am I better off simply producing a complete defconfig? A pointer to the documentation for the whole kernel meta data structure would also be helpful.
> 
> Tom and I were working on a way to dump these, I'm not sure if that
> ever completed. The meta branch of the kernel repo has all the details,
> with short descriptions in the .scc files.
> 
> As with anything, documenting a moving source code target is hard, so
> I suggest looking at the branch.
> 
> Have a look at the 3.4 kernel tree, meta branch, there's a README with
> details about the categories, and contents.


Thanks, that's got me going in the right direction.

However, I've just recreated the BSP (to use standard/default/base) and I'm now getting an error when I build the kernel:

ERROR: Function failed: do_patch (see... /log.do_patch.31458 for further information)
ERROR: Logfile of failure stored in: ... /log.do_patch.31458
Log data follows:
| ERROR: Function failed: do_patch (see ... /log.do_patch.31458 for further information)
| checkpoint is already restored, nothing to do
| error: 'refs/heads/standard/default/base' exists; cannot create 'refs/heads/standard/default/base/LX800'
| fatal: Failed to lock ref for update: Not a directory
| warning: could not find (or was already included): features/dmaengine/dmaengine.scc
| warning: could not find (or was already included): features/framebuffer/vesafb.scc
| warning: could not find (or was already included): features/intel-e1xxxx/intel-e100.scc
| warning: could not find (or was already included): features/intel-e1xxxx/intel-e1xxxx.scc
| warning: could not find (or was already included): features/dmaengine/dmaengine.scc
| warning: could not find (or was already included): features/serial/8250.scc
| warning: could not find (or was already included): features/hpet/hpet.scc
| warning: could not find (or was already included): features/ericsson-3g/f5521gw.scc
| warning: could not find (or was already included): features/framebuffer/vesafb.scc
| warning: could not find (or was already included): cfg/usb-mass-storage.scc
| warning: could not find (or was already included): cfg/boot-live.scc
| warning: could not find (or was already included): features/power/intel.scc
| warning: could not find (or was already included): features/logbuf/size-normal.scc
| warning: could not find (or was already included): features/latencytop/latencytop.scc
| warning: could not find (or was already included): features/profiling/profiling.scc
| warning: could not find (or was already included): user-patches.scc
| ./2-LX800-9dbd5e3915bb4ed4d3809d315087c405.sco: line 21: dmaengine_68b329da9893e34099c7d8ad5cb9c940: command not found
| ./2-LX800-9dbd5e3915bb4ed4d3809d315087c405.sco: line 33: vesafb_68b329da9893e34099c7d8ad5cb9c940: command not found
| ./2-LX800-9dbd5e3915bb4ed4d3809d315087c405.sco: line 21: dmaengine_68b329da9893e34099c7d8ad5cb9c940: command not found
| ./2-LX800-9dbd5e3915bb4ed4d3809d315087c405.sco: line 33: vesafb_68b329da9893e34099c7d8ad5cb9c940: command not found
| [INFO] validating against known patches  (LX800-base-meta)
| error: Your local changes to the following files would be overwritten by checkout:
| 	Makefile
| 	drivers/tty/serial/pch_uart.c
| 	drivers/usb/host/pci-quirks.c
| 	fs/namei.c
| 	fs/nfs/super.c
| 	fs/splice.c
| 	include/linux/nfs_xdr.h
| 	kernel/time/ntp.c
| 	net/ipv4/arp.c
| 	scripts/mod/modpost.c
| Please, commit your changes or stash them before you can switch branches.
| Aborting
| ERROR: could not checkout branch base
| ERROR. could not update git tree
| ERROR. Could not modify standard/default/base/LX800
NOTE: package linux-yocto-3.2.18+git1+49f931bc294d5b6be60502bbd448cff5aa766235_1+8b8cfaaab2b8d79ac56e8c9a85bad9ae7bca399c-r1.1: task do_patch: Failed

I'm guessing this is related to using the same BSP name when I recreated it? What do I need to do to get back to something that builds (which it did before)?

Chris Tapp

opensource@keylevel.com
www.keylevel.com

Re: yocto-bsp create

[Bruce Ashfield]

On 12-08-16 4:26 PM, Chris Tapp wrote:
> On 15 Aug 2012, at 21:14, Bruce Ashfield wrote:
>
>> On 12-08-15 04:06 PM, Chris Tapp wrote:
>>> I've been looking at using yocto-bsp to create a BSP. Good job! Looks like it's going to be much easier to do it this way :-)
>>
>> You really want TomZ to answer, but I'll throw in a few comments
>> here, since I'm currently reviewing a batch of code from Tom.
>>
>>>
>>> I've got a few questions/comments:
>>>
>>> 1) The documentation (7.0.1) says that the machine branch defaults to standard/default, but that is not an option that gets presented when I created a BSP. Should that be standard/base, standard/default/base, or something else? Master shows this as standard/default/common-pc, but that still isn't one of the listed options (standard/default/common-pc/base ?).
>>
>> For the 3.2 tree, it is standard/default/base, which is a name that we
>> quickly determined was not optimal, and in the 3.4 kernel tree it is standard/base.
>> So the answer is, it depends on the kernel you are using, but the tools
>> know and have the right defaults.
>>
>>>
>>> 2) What are these machine branches anyway? As in, how do I decide which one I should choose? For an ALIX 3D3 system I used standard/default/common-pc/base. Is that reasonable?
>>
>> They are collections of functionality and configuration. So if you are
>> working on a new machine that is close to something that is already
>> in tree, you'd start from the existing machine branch. If you want to
>> do something new, standard/base, if you want the preempt-rt kernel,
>> standard/preempt-rt/base, etc.
>>
>>>
>>> 3) I selected core2 as the tune option and then had to change this in the created meta-data as I needed i586 tuning and this was not given as a tune option. Should all available tunes be offered?
>>>
>>> 4) Is there any way to select the kernel CPU (I got MATOM but needed MGEODE_LX - easily changed in the<mybsp>.cfg file)?
>>
>> AFAIK, no. Since that would imply that all the kernel tunings were parsed
>> and made available. Adding it to your .cfg is the right thing. If
>> there is a BSP that already falls into your class, and you inherit
>> it, you'd get the right tuning by default.
>>
>>>
>>> 5) The created BSP refers to various feature/x/y.scc files. Are these documented somewhere so that they can be easily re-used, or am I better off simply producing a complete defconfig? A pointer to the documentation for the whole kernel meta data structure would also be helpful.
>>
>> Tom and I were working on a way to dump these, I'm not sure if that
>> ever completed. The meta branch of the kernel repo has all the details,
>> with short descriptions in the .scc files.
>>
>> As with anything, documenting a moving source code target is hard, so
>> I suggest looking at the branch.
>>
>> Have a look at the 3.4 kernel tree, meta branch, there's a README with
>> details about the categories, and contents.
>
>
> Thanks, that's got me going in the right direction.
>
> However, I've just recreated the BSP (to use standard/default/base) and I'm now getting an error when I build the kernel:
>
> ERROR: Function failed: do_patch (see... /log.do_patch.31458 for further information)
> ERROR: Logfile of failure stored in: ... /log.do_patch.31458
> Log data follows:
> | ERROR: Function failed: do_patch (see ... /log.do_patch.31458 for further information)
> | checkpoint is already restored, nothing to do
> | error: 'refs/heads/standard/default/base' exists; cannot create 'refs/heads/standard/default/base/LX800'
> | fatal: Failed to lock ref for update: Not a directory
> | warning: could not find (or was already included): features/dmaengine/dmaengine.scc
> | warning: could not find (or was already included): features/framebuffer/vesafb.scc
> | warning: could not find (or was already included): features/intel-e1xxxx/intel-e100.scc
> | warning: could not find (or was already included): features/intel-e1xxxx/intel-e1xxxx.scc
> | warning: could not find (or was already included): features/dmaengine/dmaengine.scc
> | warning: could not find (or was already included): features/serial/8250.scc
> | warning: could not find (or was already included): features/hpet/hpet.scc
> | warning: could not find (or was already included): features/ericsson-3g/f5521gw.scc
> | warning: could not find (or was already included): features/framebuffer/vesafb.scc
> | warning: could not find (or was already included): cfg/usb-mass-storage.scc
> | warning: could not find (or was already included): cfg/boot-live.scc
> | warning: could not find (or was already included): features/power/intel.scc
> | warning: could not find (or was already included): features/logbuf/size-normal.scc
> | warning: could not find (or was already included): features/latencytop/latencytop.scc
> | warning: could not find (or was already included): features/profiling/profiling.scc
> | warning: could not find (or was already included): user-patches.scc
> | ./2-LX800-9dbd5e3915bb4ed4d3809d315087c405.sco: line 21: dmaengine_68b329da9893e34099c7d8ad5cb9c940: command not found
> | ./2-LX800-9dbd5e3915bb4ed4d3809d315087c405.sco: line 33: vesafb_68b329da9893e34099c7d8ad5cb9c940: command not found
> | ./2-LX800-9dbd5e3915bb4ed4d3809d315087c405.sco: line 21: dmaengine_68b329da9893e34099c7d8ad5cb9c940: command not found
> | ./2-LX800-9dbd5e3915bb4ed4d3809d315087c405.sco: line 33: vesafb_68b329da9893e34099c7d8ad5cb9c940: command not found
> | [INFO] validating against known patches  (LX800-base-meta)
> | error: Your local changes to the following files would be overwritten by checkout:
> | 	Makefile
> | 	drivers/tty/serial/pch_uart.c
> | 	drivers/usb/host/pci-quirks.c
> | 	fs/namei.c
> | 	fs/nfs/super.c
> | 	fs/splice.c
> | 	include/linux/nfs_xdr.h
> | 	kernel/time/ntp.c
> | 	net/ipv4/arp.c
> | 	scripts/mod/modpost.c
> | Please, commit your changes or stash them before you can switch branches.
> | Aborting
> | ERROR: could not checkout branch base
> | ERROR. could not update git tree
> | ERROR. Could not modify standard/default/base/LX800
> NOTE: package linux-yocto-3.2.18+git1+49f931bc294d5b6be60502bbd448cff5aa766235_1+8b8cfaaab2b8d79ac56e8c9a85bad9ae7bca399c-r1.1: task do_patch: Failed
>
> I'm guessing this is related to using the same BSP name when I recreated it? What do I need to do to get back to something that builds (which it did before)?

ech. That means that the tree was somehow dirty and branches couldn't
be switched/checked out.

If you have a copy of your BSP layer, I can try a build here and shed
some light on what exactly went wrong.

Bruce


>
> Chris Tapp
>
> opensource@keylevel.com
> www.keylevel.com
>
>
>

Re: yocto-bsp create

[Chris Tapp]

On 17 Aug 2012, at 20:47, Bruce Ashfield wrote:

> On 12-08-17 03:40 PM, Chris Tapp wrote:
>> 
>> On 17 Aug 2012, at 20:33, Bruce Ashfield wrote:
>> 
>>> On 12-08-17 03:32 PM, Chris Tapp wrote:
>>>> On 17 Aug 2012, at 15:59, Bruce Ashfield wrote:
>>>> 
>>>>> On 12-08-17 06:47 AM, Chris Tapp wrote:
>>>>>> 
>>>>>> On 17 Aug 2012, at 00:48, Bruce Ashfield wrote:
>>>>>> 
>>>>>>> ech. That means that the tree was somehow dirty and branches couldn't
>>>>>>> be switched/checked out.
>>>>>>> 
>>>>>>> If you have a copy of your BSP layer, I can try a build here and shed
>>>>>>> some light on what exactly went wrong.
>>>>>> 
>>>>>> 
>>>>>> Thanks Bruce. Meta layer attached.
>>>>> 
>>>>> Fixed here. This was completely generated from the tools ? If so, the
>>>>> branching information was wrong.
>>>>> 
>>>>> KBRANCH_LX800  = "standard/default/LX800"
>>>>> YOCTO_KERNEL_EXTERNAL_BRANCH_LX800  = "standard/default/LX800"
>>>>> 
>>>>> The "base" is always inferred and only exists because of the
>>>>> way that git manages refs on disk. So the branch that you
>>>>> want to build is what I have above, and the tools will
>>>>> automatically make that branch point off the default/base
>>>>> branch.
>>>>> 
>>>>> Let me know if that did come from the tools and I'll follow
>>>>> up to the list.
>>>> 
>>>> I'm 99.99% sure it did, but it runs ok after making the changes you give above, deleting tmp/ and rebuilding.
>>>> 
>>>> I've not g0t any real changes in yet, so I'll go try again and see what I get. It's just possible I didn't do a complete rebuild (i.e. nuke tmp/) which may have caused a problem last time round.
>>> 
>>> ok. cool. no rush. I was just going to do a final update on the mailing
>>> list to not leave it hanging, and if there's a bug in the scripts, we
>>> can let Tom know .. so he can fix it!
>> 
>> 
>> I've just recreated the BSP. I selected option 4 for the kernel branch (standard/default/base), which gives:
>> 
>> KBRANCH_LX800  = "standard/default/base/LX800"
>> YOCTO_KERNEL_EXTERNAL_BRANCH_LX800  = "standard/default/base/LX800"
> 
> ok. Worth firing off a bug report to Tom Zaunussi. .. that
> won't work .. ever.

Just bringing this back on-list.

I'll get something added to the tracker.

Chris Tapp

opensource@keylevel.com
www.keylevel.com

Re: yocto-bsp create

[Tom Zanussi]

On Fri, 2012-08-17 at 20:56 +0100, Chris Tapp wrote:
> On 17 Aug 2012, at 20:47, Bruce Ashfield wrote:
> 
> > On 12-08-17 03:40 PM, Chris Tapp wrote:
> >> 
> >> On 17 Aug 2012, at 20:33, Bruce Ashfield wrote:
> >> 
> >>> On 12-08-17 03:32 PM, Chris Tapp wrote:
> >>>> On 17 Aug 2012, at 15:59, Bruce Ashfield wrote:
> >>>> 
> >>>>> On 12-08-17 06:47 AM, Chris Tapp wrote:
> >>>>>> 
> >>>>>> On 17 Aug 2012, at 00:48, Bruce Ashfield wrote:
> >>>>>> 
> >>>>>>> ech. That means that the tree was somehow dirty and branches couldn't
> >>>>>>> be switched/checked out.
> >>>>>>> 
> >>>>>>> If you have a copy of your BSP layer, I can try a build here and shed
> >>>>>>> some light on what exactly went wrong.
> >>>>>> 
> >>>>>> 
> >>>>>> Thanks Bruce. Meta layer attached.
> >>>>> 
> >>>>> Fixed here. This was completely generated from the tools ? If so, the
> >>>>> branching information was wrong.
> >>>>> 
> >>>>> KBRANCH_LX800  = "standard/default/LX800"
> >>>>> YOCTO_KERNEL_EXTERNAL_BRANCH_LX800  = "standard/default/LX800"
> >>>>> 
> >>>>> The "base" is always inferred and only exists because of the
> >>>>> way that git manages refs on disk. So the branch that you
> >>>>> want to build is what I have above, and the tools will
> >>>>> automatically make that branch point off the default/base
> >>>>> branch.
> >>>>> 
> >>>>> Let me know if that did come from the tools and I'll follow
> >>>>> up to the list.
> >>>> 
> >>>> I'm 99.99% sure it did, but it runs ok after making the changes you give above, deleting tmp/ and rebuilding.
> >>>> 
> >>>> I've not g0t any real changes in yet, so I'll go try again and see what I get. It's just possible I didn't do a complete rebuild (i.e. nuke tmp/) which may have caused a problem last time round.
> >>> 
> >>> ok. cool. no rush. I was just going to do a final update on the mailing
> >>> list to not leave it hanging, and if there's a bug in the scripts, we
> >>> can let Tom know .. so he can fix it!
> >> 
> >> 
> >> I've just recreated the BSP. I selected option 4 for the kernel branch (standard/default/base), which gives:
> >> 
> >> KBRANCH_LX800  = "standard/default/base/LX800"
> >> YOCTO_KERNEL_EXTERNAL_BRANCH_LX800  = "standard/default/base/LX800"
> > 
> > ok. Worth firing off a bug report to Tom Zaunussi. .. that
> > won't work .. ever.
> 
> Just bringing this back on-list.
> 
> I'll get something added to the tracker.
> 

Just back from vacation and getting to this...

Yeah, this is a known bug and was fixed by the yocto-bsp patchsets I
sent out just before I left.  See the last entry in the bug below for
links to the branches that fixed it and a few other issues:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=2693

I see that the denzil branch has been updated with the changes, but have
yet to hit master.

Tom

> Chris Tapp
> 
> opensource@keylevel.com
> www.keylevel.com
> 
> 
> 
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto