Bug#1034495: ITP: linux-board-support-package-dragonboard845c -- Firmware for dragonboard845c / RB3
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.
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.
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
Reply to: