[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1034495: ITP: linux-board-support-package-dragonboard845c -- Firmware for dragonboard845c / RB3



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.

> 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.

>
> 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.

>
> > > > 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.

>
> 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: