Bug#1034495: ITP: linux-board-support-package-dragonboard845c -- Firmware for dragonboard845c / RB3
On Mon, Apr 24, 2023 at 4:33 AM Dmitry Baryshkov
<dmitry.baryshkov@linaro.org> wrote:
>
> On 24/04/2023 11:18, Roger Shimizu wrote:
> > On Thu, Apr 20, 2023 at 6:31 AM Dmitry Baryshkov
> > <dmitry.baryshkov@linaro.org> wrote:
> >>
> >> On Thu, 20 Apr 2023 at 11:28, Roger Shimizu <rosh@debian.org> wrote:
> >>>
> >>> On Wed, Apr 19, 2023 at 2:47 AM Dmitry Baryshkov
> >>> <dmitry.baryshkov@linaro.org> wrote:
> >>>>
> >>>> On Wed, 19 Apr 2023 at 10:06, Roger Shimizu <rosh@debian.org> wrote:
> >>>>>
> >>>>> On Tue, Apr 18, 2023 at 11:47 AM Dmitry Baryshkov
> >>>>> <dmitry.baryshkov@linaro.org> wrote:
> >>>>>>
> >>>>>> On Tue, 18 Apr 2023 at 21:36, Roger Shimizu <rosh@debian.org> wrote:
> >>>>>>>
> >>>>>>>> Hello Roger, FTP masters,
> >>>>>>>> Short story: the uploaded linux-board-support-package-dragonboard845c package (currently in NEW) contains a file with unclear license background and as such it should not be allowed into the archive.
> >>>>>>>> The orig.tar.gz file needs to be repackaged before uploading.
> >>>>>>>
> >>>>>>> I tried to repack the orig, and re-upload, but got REJECTED by:
> >>>>>>>
> >>>>>>> linux-board-support-package-dragonboard845c_0~20190529180356-v4-1.dsc:
> >>>>>>> Does not match file already existing in the pool.
> >>>>>>
> >>>>>> Usually one would use suffix like -dfsg to mark the repacked package.
> >>>>>> The -dfsg doesn't make sense in the case of a non-free package, so you
> >>>>>> can probably use -repack.
> >>>>>
> >>>>> Yes, but upstream uses .zip archive anyhow.
> >>>>> So we have to repack to .orig.tar.*
> >>>>
> >>>> To notify possible users that it's not just a repack of zip, but also
> >>>>
> >>>>>
> >>>>>> More importantly I'm not sure that this package should be a part of
> >>>>>> Debian at all.
> >>>>>
> >>>>> Why?
> >>>>> Without bootloader part, we cannot support installer in Debian.
> >>>>
> >>>> This bootloader is already installed by the manufacturer. Please
> >>>> consider these partitions as a firmware. One does not modify the
> >>>> device firmware during Debian installation.
> >>>>
> >>>> Maybe I misunderstand something about the usecase you are facing.
> >>>> Could you please describe it?
> >>>
> >>> RB3 is an open platform.
> >>> You do not know what system user previously installed.
> >>
> >> Yes, that's the point. It could have been customized by the user.
> >>
> >> I always hated some W operating system rewriting the MBR
> >> unconditionally and really liked the way Debian asks user if this is a
> >> desired theing.
> >
> > With prompting user, your concern can be resolved.
> >
> >>> And even Linaro provided two different system, with different
> >>> partition layouts, aosp and linux:
> >>> - https://releases.linaro.org/96boards/dragonboard845c/linaro/rescue/21.12/
> >>
> >> And usually they differ only in the partitioning scheme, in GPT data.
> >> So. Repartitioning the UFS sounds correct to me. Reflashing the
> >> bootloader doesn't sound good.
> >>
> >>> I'm not sure why you suppose the bootloader has to be original.
> >>
> >> I suppose that it's not a task of the DI to update the bootloader.
> >
> > For linaro's image, if user want to switch between AOSP (Android) and
> > Debian, the bootloader has to be flashed.
>
> This was done this way, because there is no easy way to repartition the
> device from the host side. From the installer, that is running on the
> device, it is pretty easy to do. One just uses fdisk, parted, or any
> other GPT partitioning tool.
Thanks for confirmation that Linaro also changes partition layout when
flashing between
different images (e.g. Android and Debian).
We can discuss more in details how to integrate to D-I.
> > So I think the logic for D-I should be the same.
> > Any way, it's out of scope of this ticket. Let's discuss more when
> > integrating to D-I.
> >
> >>> Linaro's rescue image also rewrite those partitions.
> >>> I think Debian should do the same.
> >>>
> >>>> My current understanding:
> >>>> - The device comes from the factory with the bootloaders flashed
> >>>> - DI repartitions one of UFS LUNs to replace vendor+system+userdata
> >>>> with the rootfs/home/etc
> >>>> - DI installs all the packages to the target rootfs, including the
> >>>> package with custom kernel hooks
> >>>> - the kernel hooks write the generated android boot img to the boot partition
> >>>>
> >>>> Is there anything else?
> >>>
> >>> Anyway, this is not for this ITP ticket. We can discuss when porting
> >>> to installer.
> >>
> >> Sure. Please ping either me directly or the linux-arm-msm mailing list
> >> when you'd like to discuss it. Getting DI to work on these boards
> >> would be a very welcomed and appreciated both by our group and by the
> >> overall community.
> >
> > Thanks for your understanding!
> >
> >>>>>> I doubt that DI should touch these partitions. Firstly, because of the
> >>>>>> reasons I expressed in my previous email (risk of bricking the board,
> >>>>>> custom bootloaders being used on these devboards, etc).
> >>>>>> Secondly, I'd like to point out that RB3/RB5 (and other dragonboards)
> >>>>>> are in a pretty unique position. Other development boards (QRD, HDK,
> >>>>>> Open-Q, etc.) do not have public redistributable bootloader archives.
> >>>>>
> >>>>> No worries about the brick issue.
> >>>>
> >>>> Actually, no. Bricking the device during installer is a very bad thing.
> >>>
> >>> I said no worries, because we need to fix those issue when porting to installer.
> >>> This is ITP ticket, and we need to be focus on packaging firmware first.
> >>
> >> I checked other bootloaders (lilo, syslinux, grub, etc). All of them
> >> push data to /usr/lib/something. I think this approach should be
> >> adopted by your packages.
> >
> > Other bootloaders are not non-free, and can be built by debian infrastructure.
> > For non-free bootloader, I think we need to treat them as firmware.
>
> Please don't clobber the /lib/firmware/qcom/sdm845. This folder contains
> firmware that can be used on any unfused sdm845/sda845 board.
> Corresponding vendor-signed firmware goes to
> /lib/firmware/qcom/sdm845/Vendor/Device.
>
> Moreover /lib/firmware contains files that are loaded by the Linux
> kernel/userspace into the devices/cores at runtime.
>
> On the other hand, the RB3 bootloader package is pretty much specific to
> the RB3 and should not probably be used for other sdm845 devices (even
> if they are unfused). And, these files are not to be loaded into the
> cores at runtime.
>
> What I can suggest:
> - Establish the new location, e.g. /usr/lib/qcom-bsp
> - Put each BSP into the subdir of that location
Thanks for the advice!
I referred to another similar package: raspi-firmware
Basically it installs kernel non-free blob to /lib/firmware/brcm/
and other non-free stuff, such as bootloader, to /usr/lib/raspi-firmware/
I think I'll adopt similar approach.
> - Add some description file. At the very least, you should manage the
> partition <-> file correspondence list. Also I'd suggest adding a way to
> specify the board name to be matched against /sys/firmware/device-tree.
> Then any of the vendors/developers/whoever can extend the DI with the
> bootloader package specific to that device (e.g. X13s, Yoga C630,
> IFC6640 or Open-Q something).
Yes, it's good idea to have description file. I'll include one on next upload.
For the device-tree part, I'm not quite understand now.
I'll dive deeper when integrating to D-I.
Cheers,
Roger
> > Cheers,
> > Roger
> >
> >>>>> We should consider this before releasing it to installer.
> >>>>> Currently, we just take the 1st step to get everything necessary to
> >>>>> hit the debian archive.
> >>>>
> >>>> Ok, it's up to you, once the archive is free of the Renesas firmware,
> >>>> but I'd not consider it 'necessary'. The user has to perfectly know
> >>>> what he is flushing and why. I'd strongly advice to point to the
> >>>> rescue packages or to the Thundercomm SDK manager instead of packaging
> >>>> everything into the installer.
> >>>>
> >>>> --
> >>>> With best wishes
> >>>> Dmitry
> >>
> >>
> >>
> >> --
> >> With best wishes
> >> Dmitry
>
> --
> With best wishes
> Dmitry
>
Reply to: