Re: [yocto] Would COMPATIBLE_IMAGE make sense?

[Jonas Vautherin]

Thanks a lot for the answers, that's really helpful!

Seems like I should have a closer look at the distros.
I'll need some time to test it, I'll update here when that is done!

On Tue, Jun 29, 2021 at 1:52 PM Bruce Ashfield 
wrote:

> On Tue, Jun 29, 2021 at 2:41 AM Josef Holzmayr
>  wrote:
> >
> > Howdy!
> >
> > Am 29.06.2021 um 01:28 schrieb Jonas Vautherin:
> > > I was thinking about my issue described here [1], and discovered the
> > > variables called COMPATIBLE_MACHINE and COMPATIBLE_HOST, which "you can
> > > use to stop recipes from being built for machines (/hosts) with which
> > > the recipes are not compatible". And so I wondered if it would make
> > > sense to add COMPATIBLE_IMAGE, for a similar purpose.
> > >
> > > Let me explain my issue: I define different images in different layers
> > > (say `first-project-image` and `second-project-image`), and in each of
> > > those layers I create `.bbappends` to configure some packages.
> Typically
> > > `hostapd` is used by both images, but with a different config file.
> > >
> > > The thing is that when I run `bitbake first-project-image`, because
> > > `second-project-image` is part of my bblayers.conf, then the
> > > hostapd_%.bbappend from `second-project-image` is used and may have an
> > > impact on `first-project-image`, which I don't want. I really want this
> > > bbappend to only affect the image `second-project-image`.
> > >
> > > One way I can see to deal with that is to realize that
> > > `first-project-image` and `second-project-image` are two different
> > > projects, and build them from two different BUILDDIRs. The thing I
> don't
> > > like here is that all the packages are therefore downloaded and built
> > > twice, which seems like a loss of time and space.
> > >
> > > That's where I thought about COMPATIBLE_IMAGE. In the
> hostapd_%.bbappend
> > > of `first-project-image`, I would set "COMPATIBLE_IMAGE =
> > > 'first-project-image'", and similarly for "COMPATIBLE_IMAGE =
> > > 'second-project-image'". So that I could still share a BUILDDIR between
> > > different projects.
> >
> > Yocto chant #1 applies: "Recipe data is local, configuration data is
> > global." Means: the recipe does not see at all which image it is being
> > built for. So it also can't react to it - you can't check a variable
> > against something you do not even see.
> >
> > > How bad of an idea is that?
> >
> > It just doesn't work. If that counts as "bad" is left for you to decide
> :)
> >
> > What you actually might use is using different DISTROs for the images,
> > because that actually what they mean to do: you change the ABI/API of
> > the image. And you can also define a base DISTRO and COMPATIBLE_DISTRO
> > derivatives, so its all there already. It just cannot be triggered from
> > the image, because, well.. see first pragraph of the answer.
>
> I was also going to suggest distros.
>
> And also, if the concern really is about builds reusing downloads,
> etc, then by all means configure those different distro builds to
> share download and sstate directories.
>
> Bruce
>
> >
> > Greetz
> >
> > > Thanks in advance,
> > > Jonas
> > >
> > > [1]:
> https://stackoverflow.com/questions/68167244/image-specific-layers
> > > <https://stackoverflow.com/questions/68167244/image-specific-layers>
> > >
> > >
> > >
> > >
> >
> >
> >
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54027): https://lists.yoctoproject.org/g/yocto/message/54027
Mute This Topic: https://lists.yoctoproject.org/mt/83858212/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Would COMPATIBLE_IMAGE make sense?

[Jonas Vautherin]

I was thinking about my issue described here [1], and discovered the
variables called COMPATIBLE_MACHINE and COMPATIBLE_HOST, which "you can use
to stop recipes from being built for machines (/hosts) with which the
recipes are not compatible". And so I wondered if it would make sense to
add COMPATIBLE_IMAGE, for a similar purpose.

Let me explain my issue: I define different images in different layers (say
`first-project-image` and `second-project-image`), and in each of those
layers I create `.bbappends` to configure some packages. Typically
`hostapd` is used by both images, but with a different config file.

The thing is that when I run `bitbake first-project-image`, because
`second-project-image` is part of my bblayers.conf, then the
hostapd_%.bbappend from `second-project-image` is used and may have an
impact on `first-project-image`, which I don't want. I really want this
bbappend to only affect the image `second-project-image`.

One way I can see to deal with that is to realize that
`first-project-image` and `second-project-image` are two different
projects, and build them from two different BUILDDIRs. The thing I don't
like here is that all the packages are therefore downloaded and built
twice, which seems like a loss of time and space.

That's where I thought about COMPATIBLE_IMAGE. In the hostapd_%.bbappend of
`first-project-image`, I would set "COMPATIBLE_IMAGE =
'first-project-image'", and similarly for "COMPATIBLE_IMAGE =
'second-project-image'". So that I could still share a BUILDDIR between
different projects.

How bad of an idea is that?

Thanks in advance,
Jonas

[1]: https://stackoverflow.com/questions/68167244/image-specific-layers

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53996): https://lists.yoctoproject.org/g/yocto/message/53996
Mute This Topic: https://lists.yoctoproject.org/mt/83858212/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] GPT instead of MBR in my WKS file

[Jonas Vautherin]

Hello :-),

Learning Yocto with my Pocketbeagle, I have been looking at the WKS file
recently. Starting with the default beaglebone-yocto.wks, it is working
fine for an MBR partition table:

```
part /boot --source bootimg-partition --ondisk mmcblk0 --fstype=vfat
--label boot --active --align 4 --size 16 --sourceparams="loader=u-boot"
--use-uuid
part / --source rootfs --ondisk mmcblk --fstype=ext4 --label root --align 4
--use-uuid
bootloader --append="console=ttyS0,115200"
```

Looking at the documentation and some examples online, I wanted to try
moving that to a GPT partition table. But whatever I do, I always end up
with an image that just does not boot at all (and my FTDI connection does
not give me any serial output at all, not even an error). For instance I
tried something like this:

```
part /boot --source bootimg-efi --ondisk mmcblk0 --fstype=vfat --label boot
--part-name boot --active --align 1024 --sourceparams="loader=grub-efi"
--use-uuid
part / --source rootfs --ondisk mmcblk --fstype=ext4 --label root
--part-name system --align 1024 --use-uuid
bootloader --ptable gpt --append="console=ttyS0,115200"
```

So I obviously started with `--ptable gpt`, and then gradually tried to
change other things (like `bootimg-efi` instead of `bootimg-partition`,
changing the `--align` value, etc. Honestly I don't really know what I am
doing, but I have not found references that helped me online (probably
because I'm a beginner and I do not know what to search for).

I would love to get some insights about this. Like how could I verify if my
pocketbeagle can run from GPT at all (I have read that some ROMs do not
support it because it is too big)? And does GPT require EFI and/or grub at
all, or is that independent?

After all, I would just like to have a GPT partition table that looks very
similar to my MBR table, except that with GPT I could benefit from the
`--part-name` for fastboot. I don't think I want grub at all, for instance.

Best Regards,
Jonas

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52721): https://lists.yoctoproject.org/g/yocto/message/52721
Mute This Topic: https://lists.yoctoproject.org/mt/81364927/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Failing to patch u-boot .dts

[Jonas Vautherin]

Finally understood how to do it properly, and hence explaining here for the
record.

In my machine configuration, I have this line (that I overlooked):

```
IMAGE_BOOT_FILES ?= "u-boot.${UBOOT_SUFFIX} MLO zImage
am335x-pocketbeagle.dtb"
```

Which says that it should use the `am335x-pocketbeagle` device tree. I
assume that it infers that it should compile `am335x-pocketbeagle.dts` into
`am335x-pocketbeagle.dtb`. Because `am335x-evm` is listed as the default in
the defconfig, I thought it was the one being used. But I was wrong.

I patched `am335x-pocketbeagle.dts` this time and it just worked.

On Thu, Mar 11, 2021 at 11:28 AM Jonas Vautherin 
wrote:

> Hello!
>
> I am using u-boot on a pocketbeagle which, according to "Default Device
> Tree for DT control" in `bitbake -c menuconfig u-boot`, uses am335x-evm,
> which I understand is the file
> in 
> ./build/tmp/work/pocketbeagle-poky-linux-gnueabi/u-boot/1_2020.07-r0/git/arch/arm/dts/am335x-evm.dts.
>
> My issue is that this file ends up setting usb1 as `dr_mode = "host"` and
> usb0 as `dr_mode = "otg"`. I would like to use fastboot on my pocketbeagle,
> and therefore set them to `dr_mode = "peripheral"`.
>
> In order to do that, I wrote a .bbappend that does the following:
>
> ```
> FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
>
> SRC_URI += "file://am335x-evm.dts.patch"
> SRC_URI += "file://logging.cfg"
> ```
>
> The patch sets both usb0 and usb1 to `dr_mode = "peripheral"`, while the
> cfg enables logging in u-boot. Because logging is effectively enabled, I
> get that my .bbappend is used. And I can confirm
> that 
> ./build/tmp/work/pocketbeagle-poky-linux-gnueabi/u-boot/1_2020.07-r0/git/arch/arm/dts/am335x-evm.dts
> is patched indeed.
>
> However, whatever I do, I can't seem to get that modification in my u-boot
> device tree at runtime, as usb0 always ends up as "otg" and usb1 as "host".
> I have even tried a full clean build where I removed build/tmp and
> cache_sstate.
>
> I cannot really tell if my patched file is actually used or not. For
> instance, if I `bitbake -c cleansstate u-boot`, then `bitbake -c do_patch
> u-boot`, then `rm
> -rf 
> ./build/tmp/work/pocketbeagle-poky-linux-gnueabi/u-boot/1_2020.07-r0/git/arch/arm/dts`
> and finally `bitbake u-boot`, it does not complain at all about a missing
> dts file.
>
> What am I missing, and how could I make sure that my patched
> am335x-evm.dts is the device tree being used by my u-boot install?
>
> Best Regards,
> Jonas
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52688): https://lists.yoctoproject.org/g/yocto/message/52688
Mute This Topic: https://lists.yoctoproject.org/mt/8125/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Failing to patch u-boot .dts

[Jonas Vautherin]

Hello!

I am using u-boot on a pocketbeagle which, according to "Default Device
Tree for DT control" in `bitbake -c menuconfig u-boot`, uses am335x-evm,
which I understand is the file
in 
./build/tmp/work/pocketbeagle-poky-linux-gnueabi/u-boot/1_2020.07-r0/git/arch/arm/dts/am335x-evm.dts.

My issue is that this file ends up setting usb1 as `dr_mode = "host"` and
usb0 as `dr_mode = "otg"`. I would like to use fastboot on my pocketbeagle,
and therefore set them to `dr_mode = "peripheral"`.

In order to do that, I wrote a .bbappend that does the following:

```
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"

SRC_URI += "file://am335x-evm.dts.patch"
SRC_URI += "file://logging.cfg"
```

The patch sets both usb0 and usb1 to `dr_mode = "peripheral"`, while the
cfg enables logging in u-boot. Because logging is effectively enabled, I
get that my .bbappend is used. And I can confirm
that 
./build/tmp/work/pocketbeagle-poky-linux-gnueabi/u-boot/1_2020.07-r0/git/arch/arm/dts/am335x-evm.dts
is patched indeed.

However, whatever I do, I can't seem to get that modification in my u-boot
device tree at runtime, as usb0 always ends up as "otg" and usb1 as "host".
I have even tried a full clean build where I removed build/tmp and
cache_sstate.

I cannot really tell if my patched file is actually used or not. For
instance, if I `bitbake -c cleansstate u-boot`, then `bitbake -c do_patch
u-boot`, then `rm
-rf 
./build/tmp/work/pocketbeagle-poky-linux-gnueabi/u-boot/1_2020.07-r0/git/arch/arm/dts`
and finally `bitbake u-boot`, it does not complain at all about a missing
dts file.

What am I missing, and how could I make sure that my patched am335x-evm.dts
is the device tree being used by my u-boot install?

Best Regards,
Jonas

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52663): https://lists.yoctoproject.org/g/yocto/message/52663
Mute This Topic: https://lists.yoctoproject.org/mt/8125/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Keep .bbappend for older Yocto version

[Jonas Vautherin]

It does help, yes!
Thanks a lot!

On Thu, 18 Feb 2021, 12:24 ,  wrote:

> Hi,
>
> On Wed, Feb 17, 2021 at 12:02:26AM +0100, Jonas Vautherin wrote:
> > Good evening,
> >
> > I am using Yocto Gatesgarth, and I was just updating a layer that was
> > written for Dunfell. In the `conf/layer.conf`, I can simply add
> > "gatesgarth" to `LAYERSERIES_COMPAT_pocketbeagle`, like so:
> >
> > ```
> > LAYERSERIES_COMPAT_pocketbeagle = "dunfell gatesgarth"
> > ```
> >
> > However, this does not seem to work for a `.bbappend`. Let me use this
> > particular layer as an example: it is a BSP that defines
> > `linux-yocto_4.19.bbappend` for Dunfell. In my case, I want to define
> > `linux-yocto_5.4.bbappend` for Gatesgarth. When building with Dunfell, I
> > would like it to use the former, and when building with Gatesgarth, I
> would
> > like it to use the latter.
> >
> > However, if I keep both `linux-yocto_4.19.bbappend`
> > and `linux-yocto_5.4.bbappend` and try to build with Gatesgarth, it fails
> > with:
> >
> > ```
> > ERROR: No recipes in default available for:
> >   /path/to/recipes-kernel/linux/linux-yocto_4.19.bbappend
> > ```
> >
> > Which makes sense: Gatesgarth does not provide `linux-yocto_4.19`.
> >
> > Is there a way to keep both `*.bbappend` and have Yocto ignore the ones
> > that do not correspond to its version? Or would that be bad practice
> anyway?
>
> What I do in cases like this:
>
>  * check and decide if BSP layer can be update to be fully compatible with
> new yocto
>version, by asking from maintainers of the BSP layer and HW vendors
>(usual answer is 'not this year, maybe next' or 'if you pay?', if you
> are lucky
> they will say 'just use the correct branch')
>
>  * check if simple patches can update BSP layer to be compatible with new
> yocto
>version, if this involves Linux kernel, libdrm etc major version
> changes it
>might not work
>
> Quite often, I keep using the BSP SW stack from old yocto release with
> only minimal
> changes. For this to work, I make the minimal modifications needed to
> support building
> with new yocto version like modify LAYERSERIES_COMPAT and adapt bbclasses,
> then copy
> the needed old recipes from previous yocto version over the the BSP layer
> to be
> maintained there by the BSP SW maintainers. What helps a lot, is that you
> have
> reviewed what SW components you need to use from BSP SW meta layer and you
> have
> BBMASK'ed away all recipes and bbappends which your product and its distro
> configuration does not need.
>
> Often BSP layers are full of examples, prototypes, or just plain weird
> changes
> to high level SW components like gstreamer, systemd, openssl or openssh
> which your
> product might not need (e.g. is prefectly fine with the poky version of
> the recipe).
> These BSP side changes make yocto updates much more difficult and
> versioned dependencies
> from BSP to poky are too complex and difficult to resolve easily. Thus look
> for minimizing the impact of the BSP SW stack, keep it unchanged apart
> from minimal
> bitbake and bbclass fixes, and update the rest.
>
> For security and other updates, the BSP SW stack needs to be handled
> separately.
>
> Hope this helps,
>
> -Mikko

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52381): https://lists.yoctoproject.org/g/yocto/message/52381
Mute This Topic: https://lists.yoctoproject.org/mt/80691824/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Keep .bbappend for older Yocto version

[Jonas Vautherin]

Thank you for the answer :-). Yes, that works, and it seems like it is
commonly used already. But because there is a way to define which versions
are supported in the machine configuration, I thought there may be a way
without branches, i.e. having a layer that actually is compatible with
multiple versions.

Otherwise what's the point of LAYERSERIES_COMPAT, if the way to move to
another version is to branch away? Is that a legacy option?

Best,

On Wed, 17 Feb 2021, 00:32 Khem Raj,  wrote:

> perhaps you should create a new branch for this layer which will be
> compatible with gatesgarth, you can seed it with dunfell branch
> and then make needed changes
>
> On Tue, Feb 16, 2021 at 3:02 PM Jonas Vautherin
>  wrote:
> >
> > Good evening,
> >
> > I am using Yocto Gatesgarth, and I was just updating a layer that was
> written for Dunfell. In the `conf/layer.conf`, I can simply add
> "gatesgarth" to `LAYERSERIES_COMPAT_pocketbeagle`, like so:
> >
> > ```
> > LAYERSERIES_COMPAT_pocketbeagle = "dunfell gatesgarth"
> > ```
> >
> > However, this does not seem to work for a `.bbappend`. Let me use this
> particular layer as an example: it is a BSP that defines
> `linux-yocto_4.19.bbappend` for Dunfell. In my case, I want to define
> `linux-yocto_5.4.bbappend` for Gatesgarth. When building with Dunfell, I
> would like it to use the former, and when building with Gatesgarth, I would
> like it to use the latter.
> >
> > However, if I keep both `linux-yocto_4.19.bbappend` and
> `linux-yocto_5.4.bbappend` and try to build with Gatesgarth, it fails with:
> >
> > ```
> > ERROR: No recipes in default available for:
> >   /path/to/recipes-kernel/linux/linux-yocto_4.19.bbappend
> > ```
> >
> > Which makes sense: Gatesgarth does not provide `linux-yocto_4.19`.
> >
> > Is there a way to keep both `*.bbappend` and have Yocto ignore the ones
> that do not correspond to its version? Or would that be bad practice anyway?
> >
> > Best Regards,
> > Jonas
> >
> > 
> >
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52357): https://lists.yoctoproject.org/g/yocto/message/52357
Mute This Topic: https://lists.yoctoproject.org/mt/80691824/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Keep .bbappend for older Yocto version

[Jonas Vautherin]

Good evening,

I am using Yocto Gatesgarth, and I was just updating a layer that was
written for Dunfell. In the `conf/layer.conf`, I can simply add
"gatesgarth" to `LAYERSERIES_COMPAT_pocketbeagle`, like so:

```
LAYERSERIES_COMPAT_pocketbeagle = "dunfell gatesgarth"
```

However, this does not seem to work for a `.bbappend`. Let me use this
particular layer as an example: it is a BSP that defines
`linux-yocto_4.19.bbappend` for Dunfell. In my case, I want to define
`linux-yocto_5.4.bbappend` for Gatesgarth. When building with Dunfell, I
would like it to use the former, and when building with Gatesgarth, I would
like it to use the latter.

However, if I keep both `linux-yocto_4.19.bbappend`
and `linux-yocto_5.4.bbappend` and try to build with Gatesgarth, it fails
with:

```
ERROR: No recipes in default available for:
  /path/to/recipes-kernel/linux/linux-yocto_4.19.bbappend
```

Which makes sense: Gatesgarth does not provide `linux-yocto_4.19`.

Is there a way to keep both `*.bbappend` and have Yocto ignore the ones
that do not correspond to its version? Or would that be bad practice anyway?

Best Regards,
Jonas

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52354): https://lists.yoctoproject.org/g/yocto/message/52354
Mute This Topic: https://lists.yoctoproject.org/mt/80691824/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Need to manually create device-tree directory during build

[Jonas Vautherin]

As a learning experience, I am trying to build a downstream kernel from
source. It works, but it requires that I manually make a directory in the
yocto `tmp/` folder, and I am trying to understand why :-).

I created a BSP layer, and I want to use one of the downstream dts files
[1]. Because that file is in
`arch/arm/boot/dts/qcom/msm8909-pm8916-mpp3-hw00.dts`, my machine
configuration sets:

```
KERNEL_DEVICETREE += "qcom/msm8909-pm8916-mpp3-hw00.dtb"
```

I `inherit kernel` in my linux recipe, which I believe will build the dtb
from the corresponding dts in the downstream sources. However, somewhere
during the build process, I get the following error:

```
|   DTC arch/arm/boot/dts/qcom/msm8909-pm8916-mpp3-hw00.dtb
| cc1: fatal error: opening output file
arch/arm/boot/dts/qcom/.msm8909-pm8916-mpp3-hw00.dtb.dts.tmp: No such file
or directory
```

If I create the following `qcom` directory manually and re-run `bitbake
virtual/kernel`, then it works:

```
mkdir
tmp/work/skycontroller3-poky-linux-gnueabi/linux-skycontroller3/3.18.31-r0/linux-skycontroller3-standard-build/arch/arm/boot/dts/qcom
```

So it feels like this `qcom/` subdirectory poses problems. I am not sure if
I am missing a configuration somewhere, or if that could be a bug (or maybe
the dts should be in `boot/dts` and never in a subdir like
`boot/dts/qcom`?).

I read through `classes/devicetree.bbclass` and
`classes/kernel-devicetree.bbclass`, but I don't think that the
`*.dts.dtb.tmp` file is created there.

Looking for insights on what may be going wrong here :-).

Best,
Jonas

[1]:
https://github.com/parrot-opensource/skycontroller3-opensource/blob/master/sources/linux-3.18.31/linux-3.18.31/arch/arm/boot/dts/qcom/msm8909-pm8916-mpp3-hw00.dts

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52231): https://lists.yoctoproject.org/g/yocto/message/52231
Mute This Topic: https://lists.yoctoproject.org/mt/80395512/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Writing a BSP from downstream kernel sources

[Jonas Vautherin]

Thanks a lot everybody, I managed to go further with Diego's idea! I
removed the `const` in two other places, though I'm not sure if it was
necessary (I'll check that later). But the `.err encountered` errors
disappeared!

@Herman: checking your sources, too :-)

Best Regards,

On Mon, Feb 1, 2021 at 9:21 AM Herman van Hazendonk  wrote:

> Hi,
>
> We've been using 3.18 (Android) kernels on our LuneOS project with Yocto,
> so we carry the various patches to get it to build with newer GCC's.
>
> See:
> https://github.com/shr-distribution/linux/commits/tissot/3.18/halium-7.1
> for some inspiration :)
>
> For older 3.4 kernels you would need more patches obviously:
>
> https://github.com/shr-distribution/linux/commits/hammerhead/3.4/halium-5.1
>
>
> Best regards,
> Herman
>
> On 2021-02-01 08:04, Diego Santa Cruz via lists.yoctoproject.org wrote:
>
> *From:* Jonas Vautherin 
> *Sent:* 31 January 2021 22:23
> *To:* Aaron Cohen 
> *Cc:* Diego Santa Cruz ; Paul Barker <
> pbar...@konsulko.com>; Yocto-mailing-list 
> *Subject:* Re: [yocto] Writing a BSP from downstream kernel sources
>
>
>
> Thanks Aaron!
>
>
>
> That seems to remove the log2 warnings, but it seems like they were not
> related to those "Assembler" errors, e.g.:
>
>
>
> ```
>
> | /tmp/ccbtfgo7.s: Assembler messages:
> | /tmp/ccbtfgo7.s:2011: Error: .err encountered
>
> ```
>
>
>
> I think I need to fix them like Diego was suggesting, but I have trouble
> relating the error to a source file...
>
> *[Diego Santa Cruz] It may be easier to build the SDK with a dummy kernel
> (i.e. no kernel, setting PREFERRED_PROVIDER_virtual/kernel ?= "linux-dummy"
> in conf/local.conf) and use that SDK to get the kernel building outside of
> Yocto. If you run the make with V=1 you will see the full compiler command
> and you can re-run it manually. The use the -S (and eventually -E) line and
> you can inspect the faulty assembly file or source and track the original
> location. At least that is the route I took and worked well for me.*
>
> *I think you are using kernel 3.18.31, in that version it is the
> __put_user_check macro you need to fix,
> https://elixir.bootlin.com/linux/v3.18.31/source/arch/arm/include/asm/uaccess.h#L219
> <https://elixir.bootlin.com/linux/v3.18.31/source/arch/arm/include/asm/uaccess.h#L219>*
>
>
>
> *A hand written patch (not tested at all!) that should solve your problem
> is*
>
> --- arch/arm/include/asm/uaccess.h
>
> +++ arch/arm/include/asm/uaccess.h
>
> #define
> __put_user_check(x,p)
> \
>
>
> ({
> \
>
>   unsigned long __limit =
> current_thread_info()->addr_limit - 1; \
>
>   const typeof(*(p)) __user *__tmp_p =
> (p);\
>
> -  register const typeof(*(p)) __r2 asm("r2") =
> (x); \
>
> + register typeof(*(p)) __r2 asm("r2") =
> (x); \
>
>   register const typeof(*(p)) __user *__p
> asm("r0") = __tmp_p; \
>
>   register unsigned long __l asm("r1") =
> __limit;\
>
>   register int __e
> asm("r0");   \
>
>  switch (sizeof(*(__p)))
> {\
>
>
>
> On Sat, Jan 30, 2021 at 8:29 AM Aaron Cohen  wrote:
>
> Actually, I found the upstream patch I backported, which you're probably
> better off using (same diff though).
>
>
>
> https://lore.kernel.org/patchwork/patch/773330/
>
>
>
> On Sat, Jan 30, 2021 at 2:26 AM Joel A Cohen via lists.yoctoproject.org
>  wrote:
>
> I'm not sure if this is your issue, but I had a similar issue ilog2 and
> the disassembler and fixed it by backporting this patch.
>
>
>
> No guarantees, but perhaps it will help.
>
>
>
> --Aaron
>
>
>
>
>
> On Fri, Jan 29, 2021 at 9:51 PM Jonas Vautherin 
> wrote:
>
> Thanks a lot for the advice! However, I can't seem to find a `const` that
> I can simply remove. To give more context, here is the log output around
> such an error (it seems like it is often surrounded by this log2.h warning,
> by the way):
>
>
>
> | In file included from
> /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/kernel.h:11,
> |  from
> /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/kallsyms.h:9,
> | 

Re: [yocto] Writing a BSP from downstream kernel sources

[Jonas Vautherin]

Thanks Aaron!

That seems to remove the log2 warnings, but it seems like they were not
related to those "Assembler" errors, e.g.:

```
| /tmp/ccbtfgo7.s: Assembler messages:
| /tmp/ccbtfgo7.s:2011: Error: .err encountered
```

I think I need to fix them like Diego was suggesting, but I have trouble
relating the error to a source file...

On Sat, Jan 30, 2021 at 8:29 AM Aaron Cohen  wrote:

> Actually, I found the upstream patch I backported, which you're probably
> better off using (same diff though).
>
> https://lore.kernel.org/patchwork/patch/773330/
>
> On Sat, Jan 30, 2021 at 2:26 AM Joel A Cohen via lists.yoctoproject.org
>  wrote:
>
>> I'm not sure if this is your issue, but I had a similar issue ilog2 and
>> the disassembler and fixed it by backporting this patch.
>>
>> No guarantees, but perhaps it will help.
>>
>> --Aaron
>>
>>
>> On Fri, Jan 29, 2021 at 9:51 PM Jonas Vautherin <
>> jonas.vauthe...@gmail.com> wrote:
>>
>>> Thanks a lot for the advice! However, I can't seem to find a `const`
>>> that I can simply remove. To give more context, here is the log output
>>> around such an error (it seems like it is often surrounded by this log2.h
>>> warning, by the way):
>>>
>>> | In file included from
>>>> /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/kernel.h:11,
>>>> |  from
>>>> /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/kallsyms.h:9,
>>>> |  from
>>>> /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/ftrace.h:10,
>>>> |  from
>>>> /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/kernel/extable.c:18:
>>>> |
>>>> /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/log2.h:22:1:
>>>> warning: ignoring attribute 'noreturn' because it conflicts with attribute
>>>> 'const' [-Wattributes]
>>>> |22 | int ilog2_NaN(void);
>>>> |   | ^~~
>>>> |   CC  fs/fat/dir.o
>>>> | In file included from
>>>> /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/kernel.h:11,
>>>> |  from
>>>> /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/list.h:8,
>>>> |  from
>>>> /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/module.h:9,
>>>> |  from
>>>> /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/fs/fat/dir.c:16:
>>>> |
>>>> /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/log2.h:22:1:
>>>> warning: ignoring attribute 'noreturn' because it conflicts with attribute
>>>> 'const' [-Wattributes]
>>>> |22 | int ilog2_NaN(void);
>>>> |   | ^~~
>>>> |   CC  block/deadline-iosched.o
>>>> | In file included from
>>>> /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/kernel.h:11,
>>>> |  from
>>>> /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/block/deadline-iosched.c:6:
>>>> |
>>>> /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/log2.h:22:1:
>>>> warning: ignoring attribute 'noreturn' because it conflicts with attribute
>>>> 'const' [-Wattributes]
>>>> |22 | int ilog2_NaN(void);
>>>> |   | ^~~
>>>> | /tmp/cc52vFrQ.s: Assembler messages:
>>>> | /tmp/cc52vFrQ.s:2683: Error: .err encountered
>>>> | /tmp/cc52vFrQ.s:2927: Error: .err encountered
>>>> |   LD  sound/sparc/built-in.o
>>>> |   LD  sound/spi/built-in.o
>>>> | make[3]: ***
>>>> [/home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/scripts/Makefile.build:257:
>>>> block/scsi_ioctl.o] Error 1
>>>>
>>>
>>> I pasted the full output here, if that can help:
>>> https://paste.ubuntu.com/p/KqN8nVWmvv/. The lines that seem to get the
>>> log2 warning are:
>>>
>>> ```
>>> extern __attribute__((const, noreturn))
>>&

Re: [yocto] Writing a BSP from downstream kernel sources

[Jonas Vautherin]

Thanks a lot for the advice! However, I can't seem to find a `const` that I
can simply remove. To give more context, here is the log output around such
an error (it seems like it is often surrounded by this log2.h warning, by
the way):

| In file included from
> /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/kernel.h:11,
> |  from
> /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/kallsyms.h:9,
> |  from
> /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/ftrace.h:10,
> |  from
> /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/kernel/extable.c:18:
> |
> /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/log2.h:22:1:
> warning: ignoring attribute 'noreturn' because it conflicts with attribute
> 'const' [-Wattributes]
> |22 | int ilog2_NaN(void);
> |   | ^~~
> |   CC  fs/fat/dir.o
> | In file included from
> /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/kernel.h:11,
> |  from
> /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/list.h:8,
> |  from
> /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/module.h:9,
> |  from
> /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/fs/fat/dir.c:16:
> |
> /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/log2.h:22:1:
> warning: ignoring attribute 'noreturn' because it conflicts with attribute
> 'const' [-Wattributes]
> |22 | int ilog2_NaN(void);
> |   | ^~~
> |   CC  block/deadline-iosched.o
> | In file included from
> /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/kernel.h:11,
> |  from
> /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/block/deadline-iosched.c:6:
> |
> /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/log2.h:22:1:
> warning: ignoring attribute 'noreturn' because it conflicts with attribute
> 'const' [-Wattributes]
> |22 | int ilog2_NaN(void);
> |   | ^~~
> | /tmp/cc52vFrQ.s: Assembler messages:
> | /tmp/cc52vFrQ.s:2683: Error: .err encountered
> | /tmp/cc52vFrQ.s:2927: Error: .err encountered
> |   LD  sound/sparc/built-in.o
> |   LD  sound/spi/built-in.o
> | make[3]: ***
> [/home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/scripts/Makefile.build:257:
> block/scsi_ioctl.o] Error 1
>

I pasted the full output here, if that can help:
https://paste.ubuntu.com/p/KqN8nVWmvv/. The lines that seem to get the log2
warning are:

```
extern __attribute__((const, noreturn))
int ilog2_NaN(void);
 ```

So there is a const there, but well... not sure what to do with it :-).

Best,

On Mon, Jan 25, 2021 at 9:00 AM Diego Santa Cruz <
diego.santac...@spinetix.com> wrote:

> *From:* yocto@lists.yoctoproject.org  *On
> Behalf Of *Jonas Vautherin via lists.yoctoproject.org
> *Sent:* 24 January 2021 14:30
> *To:* Jonas Vautherin 
> *Cc:* Paul Barker ; Yocto-mailing-list <
> yocto@lists.yoctoproject.org>
> *Subject:* Re: [yocto] Writing a BSP from downstream kernel sources
>
>
>
> Just to close this: it seems like the gcc-cross-arm used by yocto
> gatesgarth is too new for that specific downstream kernel (3.18.31).
>
>
>
> The goal was to get a proper BSP package for this device for a modern
> yocto, so I don't think I will try with an older version of Yocto. If I
> compile an old gcc as part of a custom Yocto layer (on gatesgarth), I am
> guessing that I will have issues creating a distro that runs both on RPi
> and on that older device (because RPi will have a newer kernel and gcc, and
> the skycontroller will use older ones). I also guess that the downstream
> dts won't work with a modern kernel, and I would not know how to write one
> myself for that apq8009 chip.
>
>
>
> Hence, I'm giving up. Thanks a lot for the help :-).
>
> *[Diego Santa Cruz] Wait! **You may be able to get it working, see below.*
>
>
>
> On Sat, Jan 23, 2021 at 2:07 PM Jonas Vautherin via lists.yoctoproject.org
>  wrote:
>
> Thanks a lot for the answer!
>
>
>
> It seems like using `KCONFIG_MODE = "--alldefconfig"` with
> `KBUILD_DEFCONFIG = "msm8909_defconfig"` now ends up with the same kind of
> errors as 

Re: [yocto] Writing a BSP from downstream kernel sources

[Jonas Vautherin]

Just to close this: it seems like the gcc-cross-arm used by yocto
gatesgarth is too new for that specific downstream kernel (3.18.31).

The goal was to get a proper BSP package for this device for a modern
yocto, so I don't think I will try with an older version of Yocto. If I
compile an old gcc as part of a custom Yocto layer (on gatesgarth), I am
guessing that I will have issues creating a distro that runs both on RPi
and on that older device (because RPi will have a newer kernel and gcc, and
the skycontroller will use older ones). I also guess that the downstream
dts won't work with a modern kernel, and I would not know how to write one
myself for that apq8009 chip.

Hence, I'm giving up. Thanks a lot for the help :-).

On Sat, Jan 23, 2021 at 2:07 PM Jonas Vautherin via lists.yoctoproject.org
 wrote:

> Thanks a lot for the answer!
>
> It seems like using `KCONFIG_MODE = "--alldefconfig"` with
> `KBUILD_DEFCONFIG = "msm8909_defconfig"` now ends up with the same kind of
> errors as when I use the defconfig from the downstream kernel [1], i.e.:
>
> ```
> | /tmp/ccz8jKgm.s: Assembler messages:
> | /tmp/ccz8jKgm.s:985: Error: .err encountered
> ```
>
> Could it be related to the tuning, e.g. I'm somehow defining a wrong
> toolchain in my machine configuration [2] and it fails to build? I was
> thinking about the tune-cortexa7.inc include, though it seems to me that
> the apq8009 is a cortexa7 [3]:
>
> > The Qualcomm Snapdragon 212 APQ8009 is an entry level SoC for Android
> based tablets and smartphones. It contains four ARM Cortex-A7 CPU cores
> (quad core)
>
> [1]:
> https://github.com/parrot-opensource/skycontroller3-opensource/blob/master/sources/linux-3.18.31/linux.config
> [2]:
> https://github.com/JonasVautherin/meta-skycontroller3/blob/main/conf/machine/skycontroller3.conf#L32
> [3]:
> https://www.notebookcheck.net/Qualcomm-Snapdragon-212-APQ8009-SoC-Benchmarks-and-Specs.169859.0.html
>
> Best,
>
> On Sat, Jan 23, 2021 at 11:06 AM Paul Barker  wrote:
>
>> On Sat, 23 Jan 2021 at 02:29, Jonas Vautherin 
>> wrote:
>> >
>> > As a learning experience, I am trying to create a BSP for a device I
>> own and whose downstream kernel is published. The device in question is the
>> Parrot Skycontroller3, and the sources are available here.
>> >
>> > Let me start by sharing my issue. When I build the kernel with `bitbake
>> virtual/kernel`, it fails with errors like:
>> >
>> > ```
>> > |   AS  arch/arm/lib/backtrace.o
>> > |   AS  arch/arm/lib/bswapsdi2.o
>> > |   AS  arch/arm/lib/call_with_stack.o
>> > | /tmp/ccz8jKgm.s: Assembler messages:
>> > | /tmp/ccz8jKgm.s:985: Error: .err encountered
>> > | /tmp/ccz8jKgm.s:1033: Error: .err encountered
>> > | /tmp/ccz8jKgm.s:6812: Error: .err encountered
>> > ```
>> >
>> > My layer is available here.
>> >
>> > I created it getting inspiration from meta-raspberrypi and
>> meta-qti-bsp, which seems to have the same CPU: apq8009. According to the
>> Parrot sources, my device runs a Qualcomm apq8009/msm89090 cpu. In my repo,
>> I use as a defconfig file the linux.config that is available in the Parrot
>> sources (I copied it in my kernel recipe under `files/defconfig` and added
>> it to SRC_URI).
>> >
>> > The Parrot sources also refer to `LINUX_DEFAULT_CONFIG_TARGET :=
>> msm8909_defconfig`, so I tried to set `KBUILD_DEFCONFIG =
>> "msm8909_defconfig"`, but that is failing with different errors, such as:
>> >
>> > ```
>> > error: 'VM_ARM_DMA_CONSISTENT' undeclared (first use in this function);
>> did you mean 'DMA_ATTR_NON_CONSISTENT'?
>> > ```
>> >
>> > or
>> >
>> > ```
>> > error: 'L_PTE_YOUNG' undeclared
>> > ```
>> >
>> > As a side note, their `drivers/Kconfig` seemed invalid, so I patched it.
>> >
>> > I am a bit lost now, not completely sure where my issues come from. I
>> realize that changing the defconfig has quite some impact (I get different
>> errors), and also that my machine configuration may be completely wrong (I
>> am essentially guessing from the fact that it is an apq8009/msm8909, but
>> for instance the tuning I just copied from meta-qti-bsp, which may be
>> invalid).
>> >
>> > I would be glad if I could get hints about debugging this. Again, it is
>> really a learning project: I would like to learn how to create a BSP from a
>> downstream kernel.
>>
>> I think setting `KBUILD_DEFCONFIG = "msm8909_defconfig"` is likely the
>> correct approach here. Wha

Re: [yocto] Writing a BSP from downstream kernel sources

[Jonas Vautherin]

Thanks a lot for the answer!

It seems like using `KCONFIG_MODE = "--alldefconfig"` with
`KBUILD_DEFCONFIG = "msm8909_defconfig"` now ends up with the same kind of
errors as when I use the defconfig from the downstream kernel [1], i.e.:

```
| /tmp/ccz8jKgm.s: Assembler messages:
| /tmp/ccz8jKgm.s:985: Error: .err encountered
```

Could it be related to the tuning, e.g. I'm somehow defining a wrong
toolchain in my machine configuration [2] and it fails to build? I was
thinking about the tune-cortexa7.inc include, though it seems to me that
the apq8009 is a cortexa7 [3]:

> The Qualcomm Snapdragon 212 APQ8009 is an entry level SoC for Android
based tablets and smartphones. It contains four ARM Cortex-A7 CPU cores
(quad core)

[1]:
https://github.com/parrot-opensource/skycontroller3-opensource/blob/master/sources/linux-3.18.31/linux.config
[2]:
https://github.com/JonasVautherin/meta-skycontroller3/blob/main/conf/machine/skycontroller3.conf#L32
[3]:
https://www.notebookcheck.net/Qualcomm-Snapdragon-212-APQ8009-SoC-Benchmarks-and-Specs.169859.0.html

Best,

On Sat, Jan 23, 2021 at 11:06 AM Paul Barker  wrote:

> On Sat, 23 Jan 2021 at 02:29, Jonas Vautherin 
> wrote:
> >
> > As a learning experience, I am trying to create a BSP for a device I own
> and whose downstream kernel is published. The device in question is the
> Parrot Skycontroller3, and the sources are available here.
> >
> > Let me start by sharing my issue. When I build the kernel with `bitbake
> virtual/kernel`, it fails with errors like:
> >
> > ```
> > |   AS  arch/arm/lib/backtrace.o
> > |   AS  arch/arm/lib/bswapsdi2.o
> > |   AS  arch/arm/lib/call_with_stack.o
> > | /tmp/ccz8jKgm.s: Assembler messages:
> > | /tmp/ccz8jKgm.s:985: Error: .err encountered
> > | /tmp/ccz8jKgm.s:1033: Error: .err encountered
> > | /tmp/ccz8jKgm.s:6812: Error: .err encountered
> > ```
> >
> > My layer is available here.
> >
> > I created it getting inspiration from meta-raspberrypi and meta-qti-bsp,
> which seems to have the same CPU: apq8009. According to the Parrot sources,
> my device runs a Qualcomm apq8009/msm89090 cpu. In my repo, I use as a
> defconfig file the linux.config that is available in the Parrot sources (I
> copied it in my kernel recipe under `files/defconfig` and added it to
> SRC_URI).
> >
> > The Parrot sources also refer to `LINUX_DEFAULT_CONFIG_TARGET :=
> msm8909_defconfig`, so I tried to set `KBUILD_DEFCONFIG =
> "msm8909_defconfig"`, but that is failing with different errors, such as:
> >
> > ```
> > error: 'VM_ARM_DMA_CONSISTENT' undeclared (first use in this function);
> did you mean 'DMA_ATTR_NON_CONSISTENT'?
> > ```
> >
> > or
> >
> > ```
> > error: 'L_PTE_YOUNG' undeclared
> > ```
> >
> > As a side note, their `drivers/Kconfig` seemed invalid, so I patched it.
> >
> > I am a bit lost now, not completely sure where my issues come from. I
> realize that changing the defconfig has quite some impact (I get different
> errors), and also that my machine configuration may be completely wrong (I
> am essentially guessing from the fact that it is an apq8009/msm8909, but
> for instance the tuning I just copied from meta-qti-bsp, which may be
> invalid).
> >
> > I would be glad if I could get hints about debugging this. Again, it is
> really a learning project: I would like to learn how to create a BSP from a
> downstream kernel.
>
> I think setting `KBUILD_DEFCONFIG = "msm8909_defconfig"` is likely the
> correct approach here. What you may be missing though is the correct
> value for KCONFIG_MODE. By default, the supplied defconfig file is
> copied to .config but dependencies between config options aren't
> resolved. You need to set `KCONFIG_MODE = "--alldefconfig"` to get the
> equivalent of `make msm8909_defconfig` to occur. See
>
> https://github.com/agherzan/meta-raspberrypi/blob/master/recipes-kernel/linux/linux-raspberrypi.inc#L19
> for an idea of how this is done for Raspberry Pi.
>
> Thanks,
>
> --
> Paul Barker
> Konsulko Group
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52071): https://lists.yoctoproject.org/g/yocto/message/52071
Mute This Topic: https://lists.yoctoproject.org/mt/80047657/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Writing a BSP from downstream kernel sources

[Jonas Vautherin]

As a learning experience, I am trying to create a BSP for a device I own
and whose downstream kernel is published. The device in question is the
Parrot Skycontroller3, and the sources are available here
.

Let me start by sharing my issue. When I build the kernel with `bitbake
virtual/kernel`, it fails with errors like:

```
|   AS  arch/arm/lib/backtrace.o
|   AS  arch/arm/lib/bswapsdi2.o
|   AS  arch/arm/lib/call_with_stack.o
| /tmp/ccz8jKgm.s: Assembler messages:
| /tmp/ccz8jKgm.s:985: Error: .err encountered
| /tmp/ccz8jKgm.s:1033: Error: .err encountered
| /tmp/ccz8jKgm.s:6812: Error: .err encountered
```

My layer is available here.


I created it getting inspiration from meta-raspberrypi and meta-qti-bsp
,
which seems to have the same CPU: apq8009. According to the Parrot sources
,
my device runs a Qualcomm apq8009/msm89090 cpu. In my repo, I use as a
defconfig file the linux.config

that is available in the Parrot sources (I copied it in my kernel recipe
under `files/defconfig` and added it to SRC_URI).

The Parrot sources

also refer to `LINUX_DEFAULT_CONFIG_TARGET := msm8909_defconfig`, so I
tried to set `KBUILD_DEFCONFIG = "msm8909_defconfig"`, but that is failing
with different errors, such as:

```
error: 'VM_ARM_DMA_CONSISTENT' undeclared (first use in this function); did
you mean 'DMA_ATTR_NON_CONSISTENT'?
```

or

```
error: 'L_PTE_YOUNG' undeclared
```

As a side note, their `drivers/Kconfig` seemed invalid, so I patched it

.

I am a bit lost now, not completely sure where my issues come from. I
realize that changing the defconfig has quite some impact (I get different
errors), and also that my machine configuration

may be completely wrong (I am essentially guessing from the fact that it is
an apq8009/msm8909, but for instance the tuning I just copied from
meta-qti-bsp, which may be invalid).

I would be glad if I could get hints about debugging this. Again, it is
really a learning project: I would like to learn how to create a BSP from a
downstream kernel.

Best,

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52069): https://lists.yoctoproject.org/g/yocto/message/52069
Mute This Topic: https://lists.yoctoproject.org/mt/80047657/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Using U-boot in Yocto

[Jonas Vautherin]

Oh, for some reason I had not found the docs. Thanks a lot, that looks
really good!

On Sun, Dec 20, 2020 at 2:13 PM Paul Barker  wrote:

> On Sun, 20 Dec 2020 at 09:02, Jonas Vautherin 
> wrote:
> >
> > Hello!
> >
> > I am new to Yocto, and hope that this is the right way to ask for help
> :-).
> >
> > I would like to have a way to flash my RPi over USB using `fastboot`,
> and it seems to me that one way to do that is to enable a "fastboot mode"
> in U-boot. Therefore, I am trying to use U-boot in my Yocto image.
> >
> > There seems to be a recipe for it, hence I just added the package to my
> `-image.bb` file:
> >
> > ```
> > IMAGE_INSTALL += "u-boot"
> > ```
> >
> > However, I am not really used to bootloaders, and I am not sure it is
> booting with it. How can I check if my system is booting with U-boot? It
> does not seem like it's appearing in `dmesg` (which I presume is only
> starting with the kernel). Do I need to observe that with a serial
> connection to my RPi, or is there a log saved somewhere on the system?
> >
> > Note that my image uses `meta-raspberrypi` for MACHINE "raspberrypi4-64"
> (Raspberry Pi 4 Model B).
>
> The IMAGE_INSTALL variable is used for packages to install into the
> rootfs. Typically bootloaders need some special handling and simply
> adding them to IMAGE_INSTALL either doesn't work or isn't sufficient
> to enable booting via the chosen bootloader.
>
> For Raspberry Pi we made this simple by adding the RPI_USE_U_BOOT
> variable which you can set in your distro config or in local.conf. See
>
> https://meta-raspberrypi.readthedocs.io/en/latest/extra-build-config.html#boot-to-u-boot
> for more details.
>
> The layer documentation for meta-raspberrypi is actually pretty good,
> you can find it at
> https://meta-raspberrypi.readthedocs.io/en/latest/index.html.
>
> Thanks,
>
> --
> Paul Barker
> Konsulko Group
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#51815): https://lists.yoctoproject.org/g/yocto/message/51815
Mute This Topic: https://lists.yoctoproject.org/mt/79100324/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Using U-boot in Yocto

[Jonas Vautherin]

Hello!

I am new to Yocto, and hope that this is the right way to ask for help :-).

I would like to have a way to flash my RPi over USB using `fastboot`, and
it seems to me that one way to do that is to enable a "fastboot mode" in
U-boot. Therefore, I am trying to use U-boot in my Yocto image.

There seems to be a recipe for it, hence I just added the package to my `-
image.bb` file:

```
IMAGE_INSTALL += "u-boot"
```

However, I am not really used to bootloaders, and I am not sure it is
booting with it. How can I check if my system is booting with U-boot? It
does not seem like it's appearing in `dmesg` (which I presume is only
starting with the kernel). Do I need to observe that with a serial
connection to my RPi, or is there a log saved somewhere on the system?

Note that my image uses `meta-raspberrypi` for MACHINE "raspberrypi4-64"
(Raspberry Pi 4 Model B).

Cheers,

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#51812): https://lists.yoctoproject.org/g/yocto/message/51812
Mute This Topic: https://lists.yoctoproject.org/mt/79100324/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-