Re: [yocto] Fetch private gitlab repo using ssh with Yocto recipe #bitbake

2022-01-28 Thread Erik Boto 
On Fri, Jan 28, 2022 at 11:50 AM Nicolas Jeker  wrote:
>
> On Fri, 2022-01-28 at 10:27 +, VIVAVIS AG wrote:
> > Hi,
> >
> > > Von: yocto@lists.yoctoproject.org  Im
> > > Auftrag von Sourabh Hegde
> > > Gesendet: Freitag, 28. Januar 2022 10:47
> > >
> > > Can you please let me know how to "forward SSH_AGENT into it to be
> > > able
> > > to fetch from internal projects without the need to mount the key
> > > into the container."? I never did that before.
> >
> > I use the following options within the Docker run command:
> >   -v $SSH_AUTH_SOCK:/ssh.socket \
> >   -e SSH_AUTH_SOCK=/ssh.socket \
> >
>
> That's pretty much what I use.
>
> > Furthermore, I had to mount the .ssh folder into the container to
> > make it working (be aware of security risk).
> > Additionally, you should check that uid, gid of the user in the
> > container is the same on the host.
>
> I do something similar, my "problem" was that ssh needs the
> .ssh/known_hosts file with a matching entry in addition to your
> key/agent, but mounting the .ssh folder was not possible for me because
> of permissions. Currently, I just created a little script that wraps
> "oe-init-build-env" and populates the known_hosts file accordingly.
>
> mkdir -p ~/.ssh
>
> cat <> ~/.ssh/known_hosts
> git.example.com ssh-ed25519 
> EOF
>

I use my own Dockerfile based on crops/poky where I do the following,
which might be helpful if you also use this. It sets up the config
changes in /etc/skel/ since it creates users "on the fly" with
matching uid.

# Remove strict host key checking for ssh
# This is needed since the build will pull source over git-ssh
RUN mkdir -p /etc/skel/.ssh/
COPY ci-scripts/docker-stuff/config /etc/skel/.ssh/
RUN echo 'export GIT_SSH_COMMAND="ssh -o UserKnownHostsFile=/dev/null
-o StrictHostKeyChecking=no"' >> /etc/skel/.bashrc


The ci-scripts/docker-stuff/config file contains:
Host *
   StrictHostKeyChecking no
   UserKnownHostsFile=/dev/null

Now it was ages ago I set this up, and right now I can't really
understand why I basically do the same thing twice. So you'd have to
check which of the two things that actually solves the issue :-)

Cheers,
Erik


> > Regards,
> >
> > Carsten
> >
>
>
> 
>

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

Re: [yocto] Would COMPATIBLE_IMAGE make sense?

2021-06-29 Thread Erik Boto 
On Tue, Jun 29, 2021 at 8: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 agree with everything Josef said, but just wanted to add that if
it's just different
configurations needed for different images it might be easier to just
put the configs
into separate packages and install the right package in the respective image.

So configuration for first-project-image goes into -foo, and the
config for second-project-image goes into -bar. Then the image
would add the correct configuration package.

This only works for the simple cases, and if you really need to change the way
a package is built the DISTRO way is better.

Erik

>
> Greetz
>
> > 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 (#54005): https://lists.yoctoproject.org/g/yocto/message/54005
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]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Points to consider while moving to new yocto versions

2021-01-25 Thread Erik Boto 
Hi,

I'd start by looking at the relevant documentation section,
https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#general-migration-considerations.
There you can also find a per-release summary of changes that are
worth knowing when moving to that release.

Moving from krogoth to e.g. gatesgarth is quite a jump, so I'd expect
that it might require some effort. If you don't intend to follow along
new version, you might want to consider using dunfell which is the
current LTS version.

Cheers,
Erik

On Mon, Jan 25, 2021 at 9:07 AM amaya jindal  wrote:
>
> Hi All,
>
> We are planning to move to New yocto from current one that is krogoth yocto 
> to some updated one. We are not thinking to move to gates-garth or some other 
> major release but the releases than can have easily support for arm.
>
> Please support and help.
>
> Points need to take care to port to new yocto version.
>
> Regards,
> Rohit
>
> 
>

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

Re: [yocto] Raspberry PI enabling MMC1

2020-11-20 Thread Erik Boto 
On Thu, Nov 19, 2020 at 7:21 PM chuck kamas via lists.yoctoproject.org
 wrote:
>
> Making some progress here!
>
>
> I added a compiled version of the attached device tree and now the mmc1 shows 
> up in my yocto image! Yes! Now I need to find out the secret magic in that 
> tree that I need to add...

If I'm not mistaken that should be done by appending
RPI_KERNEL_DEVICETREE_OVERLAYS. If you don't have your own custom
machine configuration where this could be added, try adding the
following to local.conf:

RPI_KERNEL_DEVICETREE_OVERLAYS_append = " overlays/sdio.dtbo "

Cheers,
Erik
>
>
> Chuck
>
>
> On 11/18/20 7:59 PM, chuck kamas via lists.yoctoproject.org wrote:
>
> Raj,
>
>
> I found out how to debug the boot process of the PI from:
>
> https://github.com/raspberrypi/documentation/blob/master/hardware/raspberrypi/bootmodes/README.md
>
> by turning on the boot code debug.
>
> sed -i -e "s/BOOT_UART=0/BOOT_UART=1/" bootcode.bin
>
>
> I found out that the sdio overlay does not exist!
>
> MESS:00:00:07.868162:0: dtdebug: Failed to open overlay file 
> 'overlays/sdio.dtbo'
> MESS:00:00:07.874093:0: Failed to load overlay 'sdio'
> MESS:00:00:07.878881:0: brfs: File read: /mfs/sd/overlays/sdio.dtbo
> MESS:00:00:07.891322:0: brfs: File read: /mfs/sd/cmdline.txt
>
>
> So what am I missing on how to turn on the sdio on GPIO22-27? Is it not an 
> overlay and instead a driver/other code/linux config that needs to be set?
>
>
> Chuck
>
>
> On 11/17/20 4:29 PM, chuck kamas via lists.yoctoproject.org wrote:
>
> Raj,
>
>
> Thanks for taking the time to respond. I thought of that too. My custom Yocto 
> build has the line to turn on the sdio in it:
>
> dtoverlay=sdio,poll_once=off
>
>
> I have attached the entire file: config.txt.yocto
>
> However, the Rasbian image does not have any mention of the dtoverlay for the 
> sdio.  Curious. See config.txt attached.
>
>
> Thanks for the help!
>
> Chuck
>
>
> On 11/17/20 12:08 AM, Khem Raj wrote:
>
> On Mon, Nov 16, 2020 at 11:43 PM chuck kamas via
> lists.yoctoproject.org 
> wrote:
>
> Hi all,
>
>
> I have been spinning my wheels for two days trying to discover how to
> enable MMC1 on a CM3. This is the one on GPIO22-27. I can boot Rasbian
> on the CM3 and it inits the MMC1 and its pins just fine. I can
> read/write to my SD card from it etc. However, when I build yocto it
> leaves the GPIOS22-27 in gpio mode and does not set them to MMC1 mode.
> I have tried changing the device tree as described here:
>
> https://stackoverflow.com/questions/44702426/how-to-setup-an-own-device-tree-for-a-raspberrypi-in-yocto
>
> That compiles and add the .dtbo to my build, but still the GPIOS are not
> set to MMC1 mode.
>
> cat /sys/kernel/debug/pinctrl/*gpio*/pinmux-pins
> Pinmux settings per pin
> Format: pin (name): mux_owner gpio_owner hog?
> 
>
> pin 22 (gpio22): (MUX UNCLAIMED) (GPIO UNCLAIMED)
> pin 23 (gpio23): (MUX UNCLAIMED) (GPIO UNCLAIMED)
> pin 24 (gpio24): (MUX UNCLAIMED) (GPIO UNCLAIMED)
> pin 25 (gpio25): (MUX UNCLAIMED) (GPIO UNCLAIMED)
> pin 26 (gpio26): (MUX UNCLAIMED) (GPIO UNCLAIMED)
> pin 27 (gpio27): (MUX UNCLAIMED) (GPIO UNCLAIMED)
>
> .
>
> I have looked at:
>
> https://ralimtek.com/raspberry%20pi/electronics/software/raspberry_pi_secondary_sd_card/
>
>
> Any ideas of where to look next to turn on the sdio would be appreciated!
>
>
> what does /boot/config.txt look like on raspbian and yocto built images
>
> Chuck
>
>
>
>
>
>
>
>
>
>
>
>
>
> 
>

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