On 9/10/23 04:55, Paul Wise wrote:

On Sat, 2023-09-09 at 11:42 +0200, Bastian Blank wrote:

The first one is the one with included size limitations, because those
load the kernel from a pre-defined flash partition, whose size can't be
easily changed by the user.  This one is now overflowing for the second
to last documented one in the kernel package config.

Seems like this would be solvable by writing a bootloader to the flash partition that would be able to load Linux from a normal filesystem?

I think any modern (at least more than 10 years of lifespan) bootloader (u-boot, redboot, barebox, etc.,...) can read from any supported
filesystem (at least ext2, ext3 and ext4 and maybe nand-related
filesystems like yaffs, yaffs2, ubifs), so having the {z|u}Image kernel
stored on those filesystems should be not an issue...

The biggest problem will be the update procedures for those hardware.
All scripts must be changed to reflect the new partition scheme. This is
*not* an easy fix.

Just my $0.02

Regards

Gianluca

--
Eurek s.r.l. |
Electronic Engineering | http://www.eurek.it
via Celletta 8/B, 40026 Imola, Italy | Phone: +39-(0)542-609120
p.iva 00690621206 - c.f. 04020030377 | Fax: +39-(0)542-609212

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

For what it's worth, if it helps I can pitch in and test.

I have a QNAP HS-210 and a TS-212P that I've retired since the first
time I read that Debian would drop armel arch. I know there have been workarounds the limitations, and I keep having plans to implement at
least one. But! Good intentions and all! :-)

...
Philippe

------
The trouble with common sense is that it is so uncommon.
(Anonymous)

On 9/11/23 17:06, bodhi wrote:

On Monday, September 11, 2023 at 12:10:04 AM UTC-7, Gianluca Renzi wrote:

On 9/10/23 04:55, Paul Wise wrote:

On Sat, 2023-09-09 at 11:42 +0200, Bastian Blank wrote:

The first one is the one with included size limitations, because those >>>> load the kernel from a pre-defined flash partition, whose size can't be >>>> easily changed by the user. This one is now overflowing for the second >>>> to last documented one in the kernel package config.

Seems like this would be solvable by writing a bootloader to the flash
partition that would be able to load Linux from a normal filesystem?

I think any modern (at least more than 10 years of lifespan) bootloader
(u-boot, redboot, barebox, etc.,...) can read from any supported
filesystem (at least ext2, ext3 and ext4 and maybe nand-related
filesystems like yaffs, yaffs2, ubifs), so having the {z|u}Image kernel
stored on those filesystems should be not an issue...

The biggest problem will be the update procedures for those hardware.
All scripts must be changed to reflect the new partition scheme. This is
*not* an easy fix.

I agreed with Paul and also Gianluca. I'm the u-boot maintainer for many Marvell Kirkwood SoC boards. All these boards are actively maintained and up to modern standard, i.e. can boot with file systems on SATA, USB, MMC... We can ignore what's

currently in flash partitions and boot with kernels on disk rootfs.

What can I do to help in upgrading the update procedure to boot Debian 12 on Marvell Kirkwood SoCs? can somebody give me some pointer where to start looking for these scripts?

All the best,
Tony

Just my $0.02

Regards

Gianluca

--
Eurek s.r.l. |
Electronic Engineering | http://www.eurek.it
via Celletta 8/B, 40026 Imola, Italy | Phone: +39-(0)542-609120
p.iva 00690621206 - c.f. 04020030377 | Fax: +39-(0)542-609212

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, September 11, 2023 at 12:10:04 AM UTC-7, Gianluca Renzi wrote:

On 9/10/23 04:55, Paul Wise wrote:

On Sat, 2023-09-09 at 11:42 +0200, Bastian Blank wrote:

The first one is the one with included size limitations, because those
load the kernel from a pre-defined flash partition, whose size can't be >> easily changed by the user. This one is now overflowing for the second >> to last documented one in the kernel package config.

Seems like this would be solvable by writing a bootloader to the flash partition that would be able to load Linux from a normal filesystem?

I think any modern (at least more than 10 years of lifespan) bootloader (u-boot, redboot, barebox, etc.,...) can read from any supported
filesystem (at least ext2, ext3 and ext4 and maybe nand-related
filesystems like yaffs, yaffs2, ubifs), so having the {z|u}Image kernel stored on those filesystems should be not an issue...

The biggest problem will be the update procedures for those hardware.
All scripts must be changed to reflect the new partition scheme. This is *not* an easy fix.

I agreed with Paul and also Gianluca. I'm the u-boot maintainer for many Marvell Kirkwood SoC boards. All these boards are actively maintained and up to modern standard, i.e. can boot with file systems on SATA, USB, MMC... We can ignore what's currently
in flash partitions and boot with kernels on disk rootfs.

What can I do to help in upgrading the update procedure to boot Debian 12 on Marvell Kirkwood SoCs? can somebody give me some pointer where to start looking for these scripts?

All the best,
Tony

Just my $0.02

Regards

Gianluca

--
Eurek s.r.l. |
Electronic Engineering | http://www.eurek.it
via Celletta 8/B, 40026 Imola, Italy | Phone: +39-(0)542-609120
p.iva 00690621206 - c.f. 04020030377 | Fax: +39-(0)542-609212

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)