Debian on Ionics Nimbus 100

Larry,

Nimbus 100 is not supported in mainline. So I would think archdetect will not find its architecture.

Whatever you do in the installer, I think you'd need to force the arch Kirwood on it. Basically it is the Sheevaplug installation, but use the DTB for Nimbus 100.

There might be more info in flash-kernel. Since you are running mainline Debian kernel. When you upgrade, it will have to go through flash-kernel database. This is something you need to customize in flash-kernel db text file.

For my custom kernel, the installation is manual so I don't care about flash-kernel.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bodhi,

> Nimbus 100 is not supported in mainline. So I would think archdetect will not find its architecture.

Right. I'm just having a devil of a time finding the source to it. Once I see what it's doing, I'll know how to fix it. For one thing, it is not inside that massive installer shell script web, but it is an executable. If nothing else, I can break out of the installer and replace it with a one-line shell script that echoes "kirkwood". :)

There are lots of "kirkwood" boards, any of which will probably use the Debian -marvell kernel. I can't imagine why archdetect is being so picky. It could look at the CPU model for a match.

> For my custom kernel, the installation is manual so I don't care about flash-kernel.

I recall being warned about flash-kernel. My preference in the future is going to be to use the Debian installer to create the rootfs and use your newer kernels, without an initramfs, if possible.

Thank you,

Larry Baker



Edited 3 time(s). Last edit at 10/29/2024 11:46PM by mossbeachlarry.

Hi Larry,

Have you tested the LEDs yet?

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bodhi,

> Have you tested the LEDs yet?

No, but that is a good idea.

I have been working on hacking the Debian installer itself to work with the Nimbus 100 DTB. I am finishing the edit of my own documentation and then I am going to edit the post I made earlier with the complete details. After that I'll test the LEDs from Linux.

More later.

Larry Baker

Larry,

Here is the updated DTB. I've missed the compatible property "ionics,imbus-100". It's cosmetic, but it's a good idea for completeness.

compatible = "ionics,nimbus-100", "globalscale,sheevaplug", "marvell,kirkwood-88f6281", "marvell,kirkwood";

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bodhi,

> Here is the updated DTB.

I'll update my notes with the new download URL.

I will post my notes here then repeat my installation using your updated Nimbus DTB. I'm kind of compulsive that way. I like my documentation to be fully tested so there are no surprises either if I ever have to return to it or I give it to someone else. If I have to change anything, I'll edit my post again. :)

Thank you,

Larry Baker

bodhi,

FYI, attached are the Debian installer's archdetect C code. Because it is a C program, it was possible to break out of the Debian 12 installation to replace it while the installer's huge shell script was still running. (The installer shell script sources its "libraries" of functions. Because of that, I could not patch any part of that to add Nimbus 100 support while it was running.)

Instead of reading from a database at run-time (which I could have pached, like I did for the flash-kernel script), archdetect hard-codes the table of recognized DTB models, map_hardware[], in subarch-arm-linux.c. An entry would have to be added for Nimbus 100:

    { "Ionics Nimbus 100", "kirkwood" },

similar to the one for SheevaPlug:

    { "Globalscale Technologies SheevaPlug", "kirkwood" },

For the Debian installer maintainers to accept such a change, the Nimbus 100 DTS file would probably have to be in the mainline Linux kernel sources as well. Martin Michlmayer says Debian is going to drop ARMEL support in release 13, so I don't know how receptive they are likely to be. If you have the persuasive power to get your Nimbus 100 DTS into the Linux mainline sources, then I think I would have an easier time making the case to add Nimbus 100 support to archdetect.

I think archdetect takes too literal an approach to determine the architecture. They use the model from the DTB when they should be using the compatible list. I decoded every DTB file in their Linux 6.1.0-26-marvell installation (they are in /usr/lib/linux-image-6.1.0-26-marvell) and every one has a DTB compatible list with a marvell-<subarch> item whose <subarch> matches the value in the archdetect table. Ergo, there is no need for a table of DTB models. Instead all they need to do is look for matches that they support in a DTB compatible list item.

I mounted the Debian 12 USB drive on my Linux PC because it is so much faster.

# pwd
/mnt/sdc1/usr/lib/linux-image-6.1.0-26-marvell

I extracted one line for each of the DTB files containing the name of the file, the compatible list and the model for the board:

# ls -1 *.dtb | while (( 1 )) ; do read || break ; echo "${REPLY} :" `dtc -I dtb -O dts -s ${REPLY} 2>/dev/null | sed -n -e '/compatible/{s/$/ :/;p}' -e '/model/{p;q}'` ; done > all_dtbs.txt

# more all_dtbs.txt
kirkwood-b3.dtb : compatible = "excito,b3", "marvell,kirkwood-88f6281", "marvell,kirkwood"; : model = "Excito B3";
kirkwood-blackarmor-nas220.dtb : compatible = "seagate,blackarmor-nas220", "marvell,kirkwood-88f6192", "marvell,kirkwood"; : model = "Seagate Blackarmor NAS220";
kirkwood-c200-v1.dtb : compatible = "ctera,c200-v1", "marvell,kirkwood-88f6281", "marvell,kirkwood"; : model = "Ctera C200 V1";
<snip>

Then I cut-and-pasted the map_hardware[] table and massaged it into lines of "model" "<subarch>" pairs:

# cat > struct_map_hardware.txt << 'EOF'
static struct map map_hardware[] = {
    /* armel */
    { "Acorn-RiscPC" , "rpc" },
    { "EBSA285" , "netwinder" },
    { "Rebel-NetWinder" , "netwinder" },
<snip>
    { "ARM-Versatile PB", "versatile" },

    /* armhf
     *
     * These flavours were removed in Jessie (replaced by the generic armmp
     * flavour). These are kept solely to allow the Jessie installer to be able
     * to install Wheezy.
     *
     * Do not add new flavours here -- new platforms should use the armmp
     * kernel, which is the default if nothing is found here.
     */
    { "Genesi Efika MX (Smartbook)", "mx5" },
    { "Genesi Efika MX (Smarttop)", "mx5" },
    { "Nokia RX-51 Board", "omap" },
    { "OMAP3 Beagle Board", "omap" },
    { "OMAP4 Panda Board", "omap" },
    { "ARM-Versatile Express", "vexpress" },
    { NULL, NULL }
};
EOF

# sed -n -e '/^[[:blank:]]*{[[:blank:]]*NULL[[:blank:]]*,[[:blank:]]*NULL[[:blank:]]*}.*$/d' \
         -e '/^[[:blank:]]*\({[^}]*}\).*$/{s//\1/;s/^{[[:blank:]]*//;s/[[:blank:]]*}$//;s/,//;p}' \
     struct_map_hardware.txt > map_hardware.txt

# more map_hardware.txt
"Acorn-RiscPC"  "rpc"
"EBSA285"  "netwinder"
"Rebel-NetWinder"  "netwinder"
<snip>

I looked for a DTB file with a model that matched every one of the rows in the map_hardware[] table with a "marvell,<subarch>" compatible list item:

# while (( 1 )) ; do read || break ; eval "DTB=(${REPLY})" ; echo "Find \"${DTB[0]}\" with \"marvell,${DTB[1]}\":" ; grep "${DTB[0]}" all_dtbs.txt | grep "\"marvell,${DTB[1]}\"" ; done < map_hardware.txt
<snip>
Find "Marvell SheevaPlug Reference Board" with "marvell,kirkwood":
Find "Globalscale Technologies SheevaPlug" with "marvell,kirkwood":
kirkwood-sheevaplug.dtb : compatible = "globalscale,sheevaplug", "marvell,kirkwood-88f6281", "marvell,kirkwood"; : model = "Globalscale Technologies SheevaPlug";
Find "Marvell eSATA SheevaPlug Reference Board" with "marvell,kirkwood":
Find "Globalscale Technologies eSATA SheevaPlug" with "marvell,kirkwood":
kirkwood-sheevaplug-esata.dtb : compatible = "globalscale,sheevaplug-esata-rev13", "globalscale,sheevaplug-esata", "globalscale,sheevaplug", "marvell,kirkwood-88f6281", "marvell,kirkwood"; : model = "Globalscale Technologies eSATA SheevaPlug";
Find "Globalscale Technologies Dreamplug" with "marvell,kirkwood":
kirkwood-dreamplug.dtb : compatible = "globalscale,dreamplug-003-ds2001", "globalscale,dreamplug", "marvell,kirkwood-88f6281", "marvell,kirkwood"; : model = "Globalscale Technologies Dreamplug";
<snip>

Every model entry in the map_hardware[] table with <subarch> "kirkwood" or "orion5x" had a matching "marvell,<subarch>" item in the DTB compatible list, for DTB files that exist. (There are no DTB files with a model containing "Reference Board", for example, but there are several model entries in the map_hardware[] table that do.)

Furthermore, there were no model entries in the map_hardware[] table with <subarch> "kirkwood" or "orion5x" that did not have a matching "marvell,<subarch>" item in the DTB compatible list, for DTB files that exist:

# while (( 1 )) ; do read || break ; eval "DTB=(${REPLY})" ; echo "Find \"${DTB[0]}\" without \"marvell,${DTB[1]}\":" ; grep "${DTB[0]}" all_dtbs.txt | grep -v "\"marvell,${DTB[1]}\"" ; done < map_hardware.txt
<snip>
Find "Marvell SheevaPlug Reference Board" without "marvell,kirkwood":
Find "Globalscale Technologies SheevaPlug" without "marvell,kirkwood":
Find "Marvell eSATA SheevaPlug Reference Board" without "marvell,kirkwood":
Find "Globalscale Technologies eSATA SheevaPlug" without "marvell,kirkwood":
Find "Globalscale Technologies Dreamplug" without "marvell,kirkwood":
<snip>

Their code could be substantially simplified. They could still have their map_hardware[] table as, say, an exceptions list, when the DTB compatible list was incorrect. But, for most (all?) other cases, the model is irrelevant (it is a marketing term). It is the architecture compatibility that matters when selecting the Linux kernel flavour.

And, when the installer can't find a suitable match, it should present options to the user that would work. Users aren't stupid. They likely had good reason to think the installer should work on their board.

Larry Baker

Larry,

> For the Debian installer maintainers to accept
> such a change, the Nimbus 100 DTS file would
> probably have to be in the mainline Linux kernel
> sources as well. Martin Michlmayer says Debian is
> going to drop ARMEL support in release 13,

I've been monitoring this from time to time. I think at the moment, very good chance that Debian 13 will keep armel. Because we have a significant armel installation base with one of older rPi boards (armv6), and it's still shipping. As long as that rPi is still shipping and selling, Debian would want to keep armel. That was my impression from reading the last discussion on this subject on Debian ML.

> so I
> don't know how receptive they are likely to be.
> If you have the persuasive power to get your
> Nimbus 100 DTS into the Linux mainline sources,

> then I think I would have an easier time making
> the case to add Nimbus 100 support to
> archdetect.

I'd rather not going through the process of adding support for Nimbus-100 DTS to mainline.

> I think archdetect takes too literal an
> approach to determine the architecture. They use
> the model from the DTB when they should be
> using the compatible list.

Agreed. And yes, the code is a bit old and I suspect that it was implemented that way since the pre-FDT time. The DT parsing probably was added after FDT became the standard.

By DT convention, the last compatible string is the sub-arch (i.e. the lowest common denominator). If they are already parsing /proc/device-tree, then why relying on a harcoded array of models?

> I decoded every
> DTB file in their Linux 6.1.0-26-marvell
> installation (they are in
> /usr/lib/linux-image-6.1.0-26-marvell) and every
> one has a DTB compatible list with a
> marvell-<subarch> item whose
> <subarch> matches the value in the
> archdetect table. Ergo, there is no need
> for a table of DTB models. Instead all
> they need to do is look for matches that they
> support in a DTB compatible list item.

Yes.

> But, for
> most (all?) other cases, the model is
> irrelevant (it is a marketing term). It is the
> architecture compatibility that matters when
> selecting the Linux kernel flavour.

Yes. It's only good for visual confirmation purpose when someone look at the system log. But the rule in device tree world is that "ionics" and "nimbus-100" must be added to vendor list, too. The DTS alone is not enough to submit patches.

We don't care about that problem here, since we are running a custom kernel and the extra boards DTBs work (various compatible lists in the DTS are quite important to get them right). So I just go on and carry the patch out-of-tree.

> And, when the installer can't find a suitable
> match, it should present options to the user that
> would work. Users aren't stupid. They likely had
> good reason to think the installer should work on
> their board.

+1

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Bodhi,

> Here is the updated DTB.

I followed my notes to install Debian 12 on Nimbus using your latest kirkwood-nimbus-100.dtb. Everything went well. I can verify I was using the new DTB:

# tr '\0' '\n' < /sys/firmware/devicetree/base/compatible
ionics,nimbus-100
globalscale,sheevaplug
marvell,kirkwood-88f6281
marvell,kirkwood

> Have you tested the LEDs yet?

Use GPIO pin numbers and follow the instructions at setting the GPIO in Linux userspace? Or, is there a way to use the names in the DTB?

Thank you,

Larry Baker

Larry,

> I followed my notes to install Debian 12 on Nimbus
> using your latest kirkwood-nimbus-100.dtb.
> Everything went well. I can verify I was using
> the new DTB:
>

> # tr '\0' '\n' <
> /sys/firmware/devicetree/base/compatible
> ionics,nimbus-100
> globalscale,sheevaplug
> marvell,kirkwood-88f6281
> marvell,kirkwood
>

Cool!

> > Have you tested the LEDs yet?
>
> Use GPIO pin numbers and follow the instructions
> at
> setting
> the GPIO in Linux userspace?

The above is when a GPIO is not defined in the DTS.

> Or, is there a
> way to use the names in the DTB?

When the GPIO is defined in the DTS, then use the example in the rootfs /etc/rc.local (as said in the release notes)

Basically

Turn on

echo defaul-on > /sys/class/leds/sheevaplug:blue:health/trigger

Turn off

echo none > /sys/class/leds/sheevaplug:blue:health/trigger

Turn on heartbeat

echo heartbeat > /sys/class/leds/sheevaplug:blue:health/trigger

See registered LED :

ll  /sys/class/leds/

See possible triggers for a specific LED:

cat /sys/class/leds/sheevaplug:blue:health/trigger

====

All that said, I just relealized the labels in the DTS still use sheevaplug, not nimbus-100! will fix these in the kernel 6.11.x release.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bodhi,

The Nimbus 100 has only one LED (see the attached photos). However, it is a chameleon. :) It is either green, red, or orange/yellow!

Page 31 in the attached SOFTWARE DEVELOPMENT KIT v6.1 - NIMBUS says this about the "LEDs" (I have no idea how to preserve spaces in this markup language, sigh):

Quote
Page 31
VIII. Software Features
1. LEDS Indicators
1.1 Controlling LED’S
o Options
 nand-disk
 mmc0
 timer
 ide-disk
 heartbeat
 default-on
o LED’s assignment
 led1 - green
 led2 - red

To control LEDS issue in the Plugcomputers console:
Syntax:
# echo <options> > /sys/class/leds/<LED’s assignment>/trigger
Sample:
# echo heartbeat > /sys/class/leds/led1/trigger
o You should be able to see the green LED blinking

When I turn on only the green LED (it's a separate blue LED on SheevaPlug), it is green.

When I turn on only the red LED (it's a separate red LED on SheevaPlug), it is red.

When I turn them both on, it is orange/yellow.

If I turn the green LED on and set the red LED to heartbeat, the LED is green, and blinks orange/yellow twice about once per second.

If I set both LEDs to heartbeat, they are synchronized, but you can definitely see the green color before the orange/yellow color when they blink.

So, the controls work according to the specs in your DTS file. :)

Besides changing sheevaplug to numbus-100 in the path, I would change the names to green:led1 and red:led2 to match the docs.

Cute.

Larry Baker

Larry,

> The Nimbus 100 has only one LED (see the attached
> photos). However, it is a chameleon. :) It is
> either green, red, or orange/yellow!

Yes. That's the LED behavior for most Kirkwood plugs (eg. Sheevaplug, GoFlex Home/Net, Pogoplug E02/Mobile/V4, iConnect, Dockstar,...), and the larger Kirkwood NAS (eg. NSA320, NSA320S, NSA325, NSA310S, NSA310, Topkick, Netgear Stora,...).

Basic principle of color goes something like this: green+red = yellow. But I think one intensity is greater than the other so it looks orange.

> Page 31 in the attached SOFTWARE DEVELOPMENT KIT
> v6.1 - NIMBUS

> Besides changing sheevaplug to
> numbus-100 in the path, I would change the
> names to green:led1 and red:led2 to
> match the docs.

These docs are old and the DTS naming convention has changed over the year. The acceptable LED label, if there is a label defined, was model:color:function

label = "sheevaplug:blue:health"

But this has changed again. I don't bother to go back to the existing DTS and update the LEDs anymore.

> Cute.

Glad you like it :)

I recall this fun script now (I forgot to add it to the Wiki). It relies on the value of none and default-on are 0 and 1.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 2 time(s). Last edit at 11/03/2024 01:20PM by bodhi.

bodhi,

Whatever you think best is fine by me.

Thank you so much for all your help. You have been more than generous with all the time you have spent on this.

Sincerely,

Larry Baker