On Thu, Apr 20, 2023 at 6:31 AM Dmitry Baryshkov <dmitry.barysh...@linaro.org> wrote: > > 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.
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
