[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Status of Debian on QNAP

On Thu, Nov 26, 2020 at 4:34 AM Paul Wise <pabs@debian.org> wrote:
> On Fri, Nov 20, 2020 at 1:36 PM Arnd Bergmann wrote:
> > The main question for what would happen with the armel port
> > I think is what kernel to ship. When the marvell kernel gets
> > retired, the only kernel package left would be the raspberrypi
> > variant, and that is a bit silly given that it has its own raspbian
> > armhf port that is much more suitable for that specific
> > hardware.
> Is installing a bootloader into the kernel partition and then loading
> the kernel from the rootfs an option to avoid having to drop kernel
> support for armel devices?

This is technically a possibility, but it does require a boot loader
with drivers for that platform and someone to package it.

On an individual machine, I would probably pick a simpler
option, either building a custom kernel with fewer features
enabled to fit it into the normal kernel partition of the flash,
or rearranging the partitions on the device. E.g. in the
ts219.dtsi, I see this layout:

                        m25p128@0 {
                                #address-cells = <1>;
                                #size-cells = <1>;
                                compatible = "m25p128", "jedec,spi-nor";
                                reg = <0>;
                                spi-max-frequency = <20000000>;
                                mode = <0>;

                                partition@0 {
                                        reg = <0x00000000 0x00080000>;
                                        label = "U-Boot";
                                partition@40000 {
                                        reg = <0x00080000 0x00040000>;
                                        label = "U-Boot Config";
                                partition@c0000 {
                                        reg = <0x000c0000 0x00140000>;
                                        label = "NAS Config";
                               partition@200000 {
                                        reg = <0x00200000 0x00200000>;
                                        label = "Kernel";
                                partition@400000 {
                                        reg = <0x00400000 0x00900000>;
                                        label = "RootFS1";
                                partition@d00000 {
                                        reg = <0x00d00000 0x00300000>;
                                        label = "RootFS2";

This is 2MB for Kernel, 9MB for RootFS1 and 3MB for RootFS2.

As Martin describes on
the RootFS1 partition is used for initramfs, not sure what the third
one is for (device tree?). Possibly the three partitions could be
combined into one partition for kernel+initramfs with a combined
14MB, or maybe the system can be made to boot without an


Reply to: