Bug#1034495: ITP: linux-board-support-package-dragonboard845c -- Firmware for dragonboard845c / RB3
Dear Dmitry, On Tue, Jun 20, 2023 at 9:50 AM Dmitry Baryshkov wrote: > > Hi Roger, > > Just to note, we have updated linux-firmware with the files from > http://releases.linaro.org/96boards/dragonboard845c/qualcomm/firmware/RB3_firmware_2022112100-v5.zip Thanks for your info! My previous upload got rejected by ftpmaster. I think there was some misunderstanding, and I provided valid explanation, then uploaded again just now. Hope this time we can pass NEW queue. After that I will update to the latest version you provided. Cheers, Roger
Bug#1034495: ITP: linux-board-support-package-dragonboard845c -- Firmware for dragonboard845c / RB3
Hi Roger, Just to note, we have updated linux-firmware with the files from http://releases.linaro.org/96boards/dragonboard845c/qualcomm/firmware/RB3_firmware_2022112100-v5.zip Please consider following this change. -- With best wishes Dmitry
Bug#1034495: ITP: linux-board-support-package-dragonboard845c -- Firmware for dragonboard845c / RB3
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 wrote: > On Mon, Apr 24, 2023 at 4:33 AM Dmitry Baryshkov > wrote: > > > > On 24/04/2023 11:18, Roger Shimizu wrote: > > > On Thu, Apr 20, 2023 at 6:31 AM Dmitry Baryshkov > > > wrote: > > >> > > >> On Thu, 20 Apr 2023 at 11:28, Roger Shimizu wrote: > > >>> > > >>> On Wed, Apr 19, 2023 at 2:47 AM Dmitry Baryshkov > > >>> wrote: > > > > On Wed, 19 Apr 2023 at 10:06, Roger Shimizu > wrote: > > > > > > On Tue, Apr 18, 2023 at 11:47 AM Dmitry Baryshkov > > > wrote: > > >> > > >> On Tue, 18 Apr 2023 at 21:36, Roger Shimizu > 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
Bug#1034495: ITP: linux-board-support-package-dragonboard845c -- Firmware for dragonboard845c / RB3
On Mon, Apr 24, 2023 at 4:33 AM Dmitry Baryshkov wrote: > > On 24/04/2023 11:18, Roger Shimizu wrote: > > On Thu, Apr 20, 2023 at 6:31 AM Dmitry Baryshkov > > wrote: > >> > >> On Thu, 20 Apr 2023 at 11:28, Roger Shimizu wrote: > >>> > >>> On Wed, Apr 19, 2023 at 2:47 AM Dmitry Baryshkov > >>> wrote: > > On Wed, 19 Apr 2023 at 10:06, Roger Shimizu wrote: > > > > On Tue, Apr 18, 2023 at 11:47 AM Dmitry Baryshkov > > wrote: > >> > >> On Tue, 18 Apr 2023 at 21:36, Roger Shimizu 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
Bug#1034495: ITP: linux-board-support-package-dragonboard845c -- Firmware for dragonboard845c / RB3
On 24/04/2023 11:18, Roger Shimizu wrote: On Thu, Apr 20, 2023 at 6:31 AM Dmitry Baryshkov wrote: On Thu, 20 Apr 2023 at 11:28, Roger Shimizu wrote: On Wed, Apr 19, 2023 at 2:47 AM Dmitry Baryshkov wrote: On Wed, 19 Apr 2023 at 10:06, Roger Shimizu wrote: On Tue, Apr 18, 2023 at 11:47 AM Dmitry Baryshkov wrote: On Tue, 18 Apr 2023 at 21:36, Roger Shimizu 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. 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
Bug#1034495: ITP: linux-board-support-package-dragonboard845c -- Firmware for dragonboard845c / RB3
On Thu, Apr 20, 2023 at 6:31 AM Dmitry Baryshkov wrote: > > On Thu, 20 Apr 2023 at 11:28, Roger Shimizu wrote: > > > > On Wed, Apr 19, 2023 at 2:47 AM Dmitry Baryshkov > > wrote: > > > > > > On Wed, 19 Apr 2023 at 10:06, Roger Shimizu wrote: > > > > > > > > On Tue, Apr 18, 2023 at 11:47 AM Dmitry Baryshkov > > > > wrote: > > > > > > > > > > On Tue, 18 Apr 2023 at 21:36, Roger Shimizu 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
Bug#1034495: ITP: linux-board-support-package-dragonboard845c -- Firmware for dragonboard845c / RB3
On Thu, 20 Apr 2023 at 11:28, Roger Shimizu wrote: > > On Wed, Apr 19, 2023 at 2:47 AM Dmitry Baryshkov > wrote: > > > > On Wed, 19 Apr 2023 at 10:06, Roger Shimizu wrote: > > > > > > On Tue, Apr 18, 2023 at 11:47 AM Dmitry Baryshkov > > > wrote: > > > > > > > > On Tue, 18 Apr 2023 at 21:36, Roger Shimizu 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
Bug#1034495: ITP: linux-board-support-package-dragonboard845c -- Firmware for dragonboard845c / RB3
On Wed, Apr 19, 2023 at 2:47 AM Dmitry Baryshkov wrote: > > On Wed, 19 Apr 2023 at 10:06, Roger Shimizu wrote: > > > > On Tue, Apr 18, 2023 at 11:47 AM Dmitry Baryshkov > > wrote: > > > > > > On Tue, 18 Apr 2023 at 21:36, Roger Shimizu 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. And even Linaro provided two different system, with different partition layouts, aosp and linux: - https://releases.linaro.org/96boards/dragonboard845c/linaro/rescue/21.12/ I'm not sure why you suppose the bootloader has to be original. 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. > > > 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. 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
Bug#1034495: ITP: linux-board-support-package-dragonboard845c -- Firmware for dragonboard845c / RB3
On Wed, 19 Apr 2023 at 10:06, Roger Shimizu wrote: > > On Tue, Apr 18, 2023 at 11:47 AM Dmitry Baryshkov > wrote: > > > > On Tue, 18 Apr 2023 at 21:36, Roger Shimizu 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? 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? > > > 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. > 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
Bug#1034495: ITP: linux-board-support-package-dragonboard845c -- Firmware for dragonboard845c / RB3
On Tue, Apr 18, 2023 at 11:47 AM Dmitry Baryshkov wrote: > > On Tue, 18 Apr 2023 at 21:36, Roger Shimizu 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.* > 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. > 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. 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. > > -- > With best wishes > Dmitry Cheers, Roger
Bug#1034495: ITP: linux-board-support-package-dragonboard845c -- Firmware for dragonboard845c / RB3
On Tue, 18 Apr 2023 at 21:36, Roger Shimizu 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. More importantly I'm not sure that this package should be a part of Debian at all. 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. -- With best wishes Dmitry
Bug#1034495: ITP: linux-board-support-package-dragonboard845c -- Firmware for dragonboard845c / RB3
> 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.
Bug#1034495: ITP: linux-board-support-package-dragonboard845c -- Firmware for dragonboard845c / RB3
18 апреля 2023 г. 05:35:00 GMT+03:00, Roger Shimizu пишет: >Dear Dmitry, > >Thanks for your response! >Very informative. > >And the ultimate goal is to have a debian-installer image. >So this firmware upload is just the first step. Thanks for the information. Short answer: please do not touch the partitions you don't have to. > >Let me reply to you inline below. > >On Mon, Apr 17, 2023 at 3:15 AM Dmitry Baryshkov > wrote: >> >> On Mon, 17 Apr 2023 at 03:09, Roger Shimizu wrote: >> > >> > Package: wnpp >> > Severity: wishlist >> > Owner: Roger Shimizu >> > X-Debbugs-Cc: debian-de...@lists.debian.org >> > >> > * Package name: linux-board-support-package-dragonboard845c >> > Version : 20190529180356-v4 >> > Upstream Author : Linaro >> > * URL : >> > https://releases.linaro.org/96boards/dragonboard845c/qualcomm/firmware >> > * License : non-free >> > Description : Firmware for dragonboard845c / RB3 >> > >> > This package contains the binary firmware for GPU, USB, DSP hardware >> > coprocessors found on SDM845, which is the main SoC on the >> > Dragonboard 845c / RB3. >> >> Generally, I think there is some misunderstanding here. Most of the >> firmware has been pushed to linux-firmware already (where possible). >> You probably have some other intentions here. If so, please describe them. > >Thanks for the upstreaming work! >I checked package firmware-qcom-soc [1], and found GPU / Audio DSP / >Modem firmware is already there. > >[1] https://packages.debian.org/unstable/firmware-qcom-soc > >> I took a glance at the package sources on salsa. So, let's go at this >> one by one. >> >> firmware-qcom-dragonboard845c.install: >> >> [0-9]*/prog_firehose_ddr.elf lib/firmware/qcom/sdm845 >> >> This is the file that is only used by the _host_ when programming the >> device. As such, it should not be a part of the en-device firmware. It >> has no use for the RB3 itself. >> >> [0-9]*/aop.mbn lib/firmware/qcom/sdm845 >> >> Bootloader. It should not be a part of /lib/firmware/ > >Since my ultimate goal is to make an installer image, the bootloader >part is necessary. >Because we don't have the source code for this, and we have to flash >this file to one >partition of the UFS on the board in order to boot the system, we have >to treat it as >firmware. Does Debian installer update the BIOS of your PC during installation? No. Is RB3 (or RB5) somehow different from your PC in this area? No. Please don't touch the system partitions. User might have some custom code there. They might have a customized bootloader. Last, but not least, updating the bootloader might brick the board, if power gets turned off at the improper time, leaving the user with the hardware requiring one to perform additional rescue process through QDL. > >If you have a better idea for the path name, rather than /lib/firmware/, >please let me know. > >> [0-9]*/BTFM.bin lib/firmware/qcom/sdm845 >> >> This is the filesystem image with bluetooth firmware files. Relevant >> files are already part of the /lib/firmware/qca. If anything important >> is missing there, it should directly into > >Good to know it's already upstreamed, and it's under qca folder. > >> [0-9]*/cmnlib.mbn lib/firmware/qcom/sdm845 >> [0-9]*/cmnlib64.mbn lib/firmware/qcom/sdm845 >> [0-9]*/devcfg.mbn lib/firmware/qcom/sdm845 >> >> These three files are also used by the bootloader process, and as such >> they should not be a part of /lib/firmware. >> >> [0-9]*/dspso.bin lib/firmware/qcom/sdm845 >> >> This is probably the only important file for now. This is the >> filesystem image with the shared libraries and executable code for the >> DSPs when executing compute applications there. >> We were putting it to /lib/firmware/qcom/sdm845 and mounting it later, >> because it was easier to do so (if the image is not present in >> /lib/firmware, the rootfs can try mounting dspso parition). For proper >> Debian packaging the image should be unpacked to some agreed location. >> fastrpc daemons then should be taught about this location. > >Yes, we need to integrate this into the installer. No. This needs to be integrated into the system runtime, not into the installer. > >> [0-9]*/hyp.mbn lib/firmware/qcom/sdm845 >> [0-9]*/imagefv.elf lib/firmware/qcom/sdm845 >> [0-9]*/keymaster64.mbn lib/firmware/qcom/sdm845 >> [0-9]*/sec.dat lib/firmware/qcom/sdm845 >> [0-9]*/storsec.mbn lib/firmware/qcom/sdm845 >> [0-9]*/tz.mbn lib/firmware/qcom/sdm845 >> [0-9]*/xbl.elf lib/firmware/qcom/sdm845 >> [0-9]*/xbl_config.elf lib/firmware/qcom/sdm845 >> [0-9]*/qupv3fw.elf lib/firmware/qcom/sdm845 >> >> Again, mostly bootloader stuff. I highly doubt that /lib/firmware >> should be polluted with these files. >> >> renesas_usb_fw.mem lib/firmware >> >> So, this is the Renesas firmware, which gets copyrighted by Qualcomm. >> We noticed this some time ago (and the fact that the supplier of the >> firmware, Thundercomm, also pulled the file without having a clear >>
Bug#1034495: ITP: linux-board-support-package-dragonboard845c -- Firmware for dragonboard845c / RB3
Dear Dmitry, Thanks for your response! Very informative. And the ultimate goal is to have a debian-installer image. So this firmware upload is just the first step. Let me reply to you inline below. On Mon, Apr 17, 2023 at 3:15 AM Dmitry Baryshkov wrote: > > On Mon, 17 Apr 2023 at 03:09, Roger Shimizu wrote: > > > > Package: wnpp > > Severity: wishlist > > Owner: Roger Shimizu > > X-Debbugs-Cc: debian-de...@lists.debian.org > > > > * Package name: linux-board-support-package-dragonboard845c > > Version : 20190529180356-v4 > > Upstream Author : Linaro > > * URL : > > https://releases.linaro.org/96boards/dragonboard845c/qualcomm/firmware > > * License : non-free > > Description : Firmware for dragonboard845c / RB3 > > > > This package contains the binary firmware for GPU, USB, DSP hardware > > coprocessors found on SDM845, which is the main SoC on the > > Dragonboard 845c / RB3. > > Generally, I think there is some misunderstanding here. Most of the > firmware has been pushed to linux-firmware already (where possible). > You probably have some other intentions here. If so, please describe them. Thanks for the upstreaming work! I checked package firmware-qcom-soc [1], and found GPU / Audio DSP / Modem firmware is already there. [1] https://packages.debian.org/unstable/firmware-qcom-soc > I took a glance at the package sources on salsa. So, let's go at this > one by one. > > firmware-qcom-dragonboard845c.install: > > [0-9]*/prog_firehose_ddr.elf lib/firmware/qcom/sdm845 > > This is the file that is only used by the _host_ when programming the > device. As such, it should not be a part of the en-device firmware. It > has no use for the RB3 itself. > > [0-9]*/aop.mbn lib/firmware/qcom/sdm845 > > Bootloader. It should not be a part of /lib/firmware/ Since my ultimate goal is to make an installer image, the bootloader part is necessary. Because we don't have the source code for this, and we have to flash this file to one partition of the UFS on the board in order to boot the system, we have to treat it as firmware. If you have a better idea for the path name, rather than /lib/firmware/, please let me know. > [0-9]*/BTFM.bin lib/firmware/qcom/sdm845 > > This is the filesystem image with bluetooth firmware files. Relevant > files are already part of the /lib/firmware/qca. If anything important > is missing there, it should directly into Good to know it's already upstreamed, and it's under qca folder. > [0-9]*/cmnlib.mbn lib/firmware/qcom/sdm845 > [0-9]*/cmnlib64.mbn lib/firmware/qcom/sdm845 > [0-9]*/devcfg.mbn lib/firmware/qcom/sdm845 > > These three files are also used by the bootloader process, and as such > they should not be a part of /lib/firmware. > > [0-9]*/dspso.bin lib/firmware/qcom/sdm845 > > This is probably the only important file for now. This is the > filesystem image with the shared libraries and executable code for the > DSPs when executing compute applications there. > We were putting it to /lib/firmware/qcom/sdm845 and mounting it later, > because it was easier to do so (if the image is not present in > /lib/firmware, the rootfs can try mounting dspso parition). For proper > Debian packaging the image should be unpacked to some agreed location. > fastrpc daemons then should be taught about this location. Yes, we need to integrate this into the installer. > [0-9]*/hyp.mbn lib/firmware/qcom/sdm845 > [0-9]*/imagefv.elf lib/firmware/qcom/sdm845 > [0-9]*/keymaster64.mbn lib/firmware/qcom/sdm845 > [0-9]*/sec.dat lib/firmware/qcom/sdm845 > [0-9]*/storsec.mbn lib/firmware/qcom/sdm845 > [0-9]*/tz.mbn lib/firmware/qcom/sdm845 > [0-9]*/xbl.elf lib/firmware/qcom/sdm845 > [0-9]*/xbl_config.elf lib/firmware/qcom/sdm845 > [0-9]*/qupv3fw.elf lib/firmware/qcom/sdm845 > > Again, mostly bootloader stuff. I highly doubt that /lib/firmware > should be polluted with these files. > > renesas_usb_fw.mem lib/firmware > > So, this is the Renesas firmware, which gets copyrighted by Qualcomm. > We noticed this some time ago (and the fact that the supplier of the > firmware, Thundercomm, also pulled the file without having a clear > origin). We have been trying to clear licensing terms for this file, > however Renesas is unresponsive. Originally this file came from the > author (Renesas) without proper license. Thus I do not believe it > passes required checks by ftpmasters. If this is the issue, we can remove this blob. But basically, this is a non-free package, and if we can redistribute the file it should not be a problem. The file is on linaro archive for years for free download to anymore. And you informed Renesas about this, so if they don't agree with the redistribution, they will ask you to pull it off long time ago. > linaro-abl/aosp/* lib/firmware/qcom/sdm845/abl-aosp > linaro-abl/linux/* lib/firmware/qcom/sdm845/abl-linux > > I don't know what this is, but judging from the name (ABL) it also > should not be part of /lib/firmware. Especially the AOSP
Bug#1034495: ITP: linux-board-support-package-dragonboard845c -- Firmware for dragonboard845c / RB3
On Mon, 17 Apr 2023 at 03:09, Roger Shimizu wrote: > > Package: wnpp > Severity: wishlist > Owner: Roger Shimizu > X-Debbugs-Cc: debian-de...@lists.debian.org > > * Package name: linux-board-support-package-dragonboard845c > Version : 20190529180356-v4 > Upstream Author : Linaro > * URL : > https://releases.linaro.org/96boards/dragonboard845c/qualcomm/firmware > * License : non-free > Description : Firmware for dragonboard845c / RB3 > > This package contains the binary firmware for GPU, USB, DSP hardware > coprocessors found on SDM845, which is the main SoC on the > Dragonboard 845c / RB3. Generally, I think there is some misunderstanding here. Most of the firmware has been pushed to linux-firmware already (where possible). You probably have some other intentions here. If so, please describe them. I took a glance at the package sources on salsa. So, let's go at this one by one. firmware-qcom-dragonboard845c.install: [0-9]*/prog_firehose_ddr.elf lib/firmware/qcom/sdm845 This is the file that is only used by the _host_ when programming the device. As such, it should not be a part of the en-device firmware. It has no use for the RB3 itself. [0-9]*/aop.mbn lib/firmware/qcom/sdm845 Bootloader. It should not be a part of /lib/firmware/ [0-9]*/BTFM.bin lib/firmware/qcom/sdm845 This is the filesystem image with bluetooth firmware files. Relevant files are already part of the /lib/firmware/qca. If anything important is missing there, it should directly into [0-9]*/cmnlib.mbn lib/firmware/qcom/sdm845 [0-9]*/cmnlib64.mbn lib/firmware/qcom/sdm845 [0-9]*/devcfg.mbn lib/firmware/qcom/sdm845 These three files are also used by the bootloader process, and as such they should not be a part of /lib/firmware. [0-9]*/dspso.bin lib/firmware/qcom/sdm845 This is probably the only important file for now. This is the filesystem image with the shared libraries and executable code for the DSPs when executing compute applications there. We were putting it to /lib/firmware/qcom/sdm845 and mounting it later, because it was easier to do so (if the image is not present in /lib/firmware, the rootfs can try mounting dspso parition). For proper Debian packaging the image should be unpacked to some agreed location. fastrpc daemons then should be taught about this location. [0-9]*/hyp.mbn lib/firmware/qcom/sdm845 [0-9]*/imagefv.elf lib/firmware/qcom/sdm845 [0-9]*/keymaster64.mbn lib/firmware/qcom/sdm845 [0-9]*/sec.dat lib/firmware/qcom/sdm845 [0-9]*/storsec.mbn lib/firmware/qcom/sdm845 [0-9]*/tz.mbn lib/firmware/qcom/sdm845 [0-9]*/xbl.elf lib/firmware/qcom/sdm845 [0-9]*/xbl_config.elf lib/firmware/qcom/sdm845 [0-9]*/qupv3fw.elf lib/firmware/qcom/sdm845 Again, mostly bootloader stuff. I highly doubt that /lib/firmware should be polluted with these files. renesas_usb_fw.mem lib/firmware So, this is the Renesas firmware, which gets copyrighted by Qualcomm. We noticed this some time ago (and the fact that the supplier of the firmware, Thundercomm, also pulled the file without having a clear origin). We have been trying to clear licensing terms for this file, however Renesas is unresponsive. Originally this file came from the author (Renesas) without proper license. Thus I do not believe it passes required checks by ftpmasters. linaro-abl/aosp/* lib/firmware/qcom/sdm845/abl-aosp linaro-abl/linux/* lib/firmware/qcom/sdm845/abl-linux I don't know what this is, but judging from the name (ABL) it also should not be part of /lib/firmware. Especially the AOSP file. Next package: network-manager-config-dragonboard845c.install debian/eth-mac-addr.conf usr/lib/NetworkManager/conf.d/ I do not think this should be a part of the firmware-qcom-dragonboard845c source package. It is not a firmware. > If you have any concerns, or you can offer co-maintenance of the package in > Debian, please let me know. Well, I'd like to understand your intentions with this package. Please feel free to ask any questions regarding these files or about packaging them. -- With best wishes Dmitry
Bug#1034495: ITP: linux-board-support-package-dragonboard845c -- Firmware for dragonboard845c / RB3
Package: wnpp Severity: wishlist Owner: Roger Shimizu X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: linux-board-support-package-dragonboard845c Version : 20190529180356-v4 Upstream Author : Linaro * URL : https://releases.linaro.org/96boards/dragonboard845c/qualcomm/firmware * License : non-free Description : Firmware for dragonboard845c / RB3 This package contains the binary firmware for GPU, USB, DSP hardware coprocessors found on SDM845, which is the main SoC on the Dragonboard 845c / RB3.
