[yocto] yocto-bsp create

Bruce Ashfield bruce.ashfield at windriver.com
Thu Aug 16 16:48:24 PDT 2012


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 at keylevel.com
> www.keylevel.com
>
>
>




More information about the yocto mailing list