Dear ftpmaster, I found that the previous upload for linux-board-support-package-dragonboard845c was removed from the NEW queue. I guess it's because you don't want to have the 1st upload to hit the archive.
So I reuploaded the 2nd upload again. It should resolve all concerns regarding to ITP this email thread mentioned. Cheers, Roger On Mon, Apr 24, 2023 at 11:23 PM Roger Shimizu <r...@debian.org> wrote: > On Mon, Apr 24, 2023 at 4:33 AM Dmitry Baryshkov > <dmitry.barysh...@linaro.org> wrote: > > > > On 24/04/2023 11:18, Roger Shimizu wrote: > > > 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. > > > > 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 > > >
