On Thu, 20 Apr 2023 at 11:28, Roger Shimizu <r...@debian.org> wrote: > > On Wed, Apr 19, 2023 at 2:47 AM Dmitry Baryshkov > <dmitry.barysh...@linaro.org> wrote: > > > > On Wed, 19 Apr 2023 at 10:06, Roger Shimizu <r...@debian.org> wrote: > > > > > > On Tue, Apr 18, 2023 at 11:47 AM Dmitry Baryshkov > > > <dmitry.barysh...@linaro.org> wrote: > > > > > > > > On Tue, 18 Apr 2023 at 21:36, Roger Shimizu <r...@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
