Hwpack config changes between debian and ubuntu

Products Support DragonBoard410c
#1

Hi,
I was taking a look at the differences in ci.linaro.org after the migration to debian. I had a couple of questions about the current configuration, as I am still wrapping my head around (portions of) all the underlying tools involved.

https://ci.linaro.org/view/engineering-builds/job/lt-qcom-debian-images-arm64/configure

Questions:

  1. linaro-lt-qcom append is missing libdrm*, lib*mesa* + mesa-utils, and libaxtracker2 - why were they removed? My guess is the original intention was to include mesa/freedreno related packages.. are they satisfied in some other way?
  2. For any additional packages I might want to populate (by default), I would simply add them at this append, correct?
  3. It looks like linaro-hwpack-{create,replace} takes as input the above and outputs a set of deb packages and headers - any other gotchas here?
  4. Is the main difference between the linaro*.sd.img which linaro-media-create outputs, and the rootfs: linaro*.img from the upstream build the linaro overlay? - I was hoping for a quick answer, otherwise I can just read the python scripts.. I think I see a partition table and ext(x) partition.. but would like to confirm that it might be the populated version of the rootfs I'm expecting (with linaro overlay) and nothing more.
  5. Are there any headers or anything that fastboot might detect (to verify the partition)? If so, are these created with linaro-media-create somewhere?
  6. If I wanted to change the sources for hwpack from 'jessie' to say 'stretch', any big gotchas there that I might run into?

Thanks in advance for your reply.

#2

Hi @hhony,

Your questions are detail and good. :slight_smile:

I am asking internally for your questions.

#3

@ldts-atsuka
I have answered question 1) by simply running ‘tar tvf hwpack_linaro-lt-qcom_*_arm64_supported.tar.gz’. I can see that drm2, mesa, etc are there.

still curious about the other questions.

#4

Hi @hhony

This is the information I received.

  1. linaro-lt-qcom append is missing libdrm*, libmesa + mesa-utils,
    and libaxtracker2 – why were they removed? My guess is the original
    intention was to include mesa/freedreno related packages… are they
    satisfied in some other way?

these packages used to live in the qcom overlay on repo.linaro.org.
However they are now available in the official Debian backports repo.
Since they are now in the Debian repos, they are automatically pulled
in the generic rootfs images, so it is no longer needed to add them in
the hwpack.

  1. For any additional packages I might want to populate (by default),
    I would simply add them at this append, correct?

Yes, it should work. Another option would be to create your own base
rootfs, that might be a better approach, see
https://ci.linaro.org/view/engineering-builds/job/debian-arm64-rootfs/.

  1. It looks like linaro-hwpack-{create,replace} takes as input the
    above and outputs a set of deb packages and headers – any other
    gotchas here?

right, it creates the ‘hwpack’ file that contains deb files. this
hwpack is later combined with the rootfs to create an image, where all
the deb from the hwpack are installed/upgraded in the resulting image.

  1. Is the main difference between the linaro*.sd.img which
    linaro-media-create outputs, and the rootfs: linaro*.img from the
    upstream build the linaro overlay? – I was hoping for a quick answer,
    otherwise I can just read the python scripts… I think I see a
    partition table and ext(x) partition… but would like to confirm that
    it might be the populated version of the rootfs I’m expecting (with
    linaro overlay) and nothing more.

the rootfs is built with live-build tools, so it essentially pulls
packages from Debian archives and Linaro overy and create a cross
rootfs.

the hwpack contains the ‘board’ specific changes (kernel, additional
packages, … )

linaro-media-create creates a ‘pseudo’ SD card with a boot and rootfs
partition. The rootfs is the ‘merge’ of the initial rootfs and the
hwpack deb files. Then we only use the SD image ‘rootfs’ partition,
which we convert into something that can be used with fastboot.

  1. Are there any headers or anything that fastboot might detect (to
    verify the partition)? If so, are these created with
    linaro-media-create somewhere?

no, linaro-media-create doesn’t know anything about fastboot. In fact
we should probably add support for ‘fastboot’ images in
linaro-media-create so that we don’t have to do it with 2 steps as we
do it today… the fastboot ‘ready’ image is created mkfs.ext4 , and we
simply copy the content of the rootfs there. then we use ext2simg to
create the corresponding ‘fastboot sparse’ image that can be flashed.

  1. If I wanted to change the sources for hwpack from ‘jessie’ to say
    ‘stretch’, any big gotchas there that I might run into?

you would need to rebuild the generic rootfs against stretch first. so
of the Linaro packages might not be available for stretch yet, so you
would have to rebuild them too.

I hope it helps you.

#5

@ldts-atsuka
Yes, this helps thank you. Crystal clear on 1-5.

Still have a question about 6 - I have already looked at the ubuntu-build-service, and I can understand how this is done for stretch vs. jessie. I’m able to build and customize there, however… with regard to rebuilding the ‘linaro-overlay-minimal’, where would the source for that be? (I assume these are the packages you’re unsure about - as am I)

Is there a jenkins job for that too? How is that released?

Thanks again,
Hans

#6

hi,

about #6, there is no Jenkins job, we push our packages in the overlay whenever it’s needed (a package has change, or the underlying debian release has changed).

the source of the package is in the overlay itself, e.g. you would get them with apt-get source. You can get the sources directly from the overlay too, e.g.

http://repo.linaro.org/ubuntu/linaro-overlay/pool/main/l/linaro-overlay/

Also note that we are looking at stretch ourselves. we don’t know for sure if we will upgrade our images to stretch yet (at least we don’t know when we will do that). But it’s likely that within the next 2 to 3 weeks our packages will be built in our overlay for stretch.

#7

@ndec
Gotcha. Thanks again!