Debian on Ionics Nimbus 100

I am trying to update an Ionics Nimbus 100 SoC from Debian 6 (UBIFS flash rootfs) to Debian "stable". (The Ionics Nimbus 100 is a repackaged version of the Marvell SheevaPlug.) I am stuck at the point where my UBIFS rootfs fails to mount because none of the Linux Kirkwood kernel packages I have tried support UBIFS in the kernel, which is required to boot a UBIFS rootfs.

From "How do I mount UBIFS?" in "UBIFS FAQ and HOWTO":

"In order to mount UBIFS as the root file system, you have to compile UBIFS into the kernel (instead of compiling it as a kernel module) and specify proper kernel boot arguments and make the kernel mount UBIFS on boot. You have to provide the boot arguments to attach the UBI device (using the ubi.mtd= argument, see here). Then you should tell the kernel the file system type by providing the rootfstype= argument. And finally, you should specify which UBI volume has to be mounted on boot using the root= argument. The volume is specified the same way as described above (ubiX_Y or ubiX:NAME)."

Here's what I have tried:

Debian uses the Kirkwood ARMEL SheevaPlug installer for the Nimbus 100. Unfortunately, the Kirkwood ARMEL installer for Debian 12 fails to enumerate USB drives on my Nimbus 100 (yet, it does enumerate USB drives on my Marvell SheevaPlug). Debian 11 does not have this problem, which allowed me to install Debian 11 to a USB ext4 rootfs (LEXAR JD FIREFLY).

I found the USB drive enumeration failure is actually a bug in the Linux kernel. I built a micro rootfs using debootstrap and debuerreotype and wrote it to a UBIFS rootfs on the internal flash. I have booted both the Debian 11 Linux 5.10.0-32-marvell kernel and the Debian 12 Linux 6.1.0-25-marvell kernel. Neither kernel has built-in UBIFS support, so I get stuck in both cases at the point where they fail to mount the flash ubi0:rootfs. However, at that point I am able to see that Linux 6.1.0-25-marvell does not enumerate my USB drive, whereas Linux 5.10.0-32-marvell does.

I found the article Linux Kerne 6.10.11 Kirkwood package and Debian rootfs and went through the steps to unpack and install the linux-image-6.10.11-kirkwood-tld-1_1_armel.deb kernel package. I was hoping it would allow me to make progress to boot my UBIFS rootfs. I was also hoping it would be a more recent version of Linux 6 than the Debian Linux 6.1.0-25-marvell that fixes the problem enumerating a USB drive on a Nimbus 100.

I can report that the Linux 6.10.11-kirkwood-tld-1 kernel solves the problem of enumerating my Lexar USB drive:

[    6.409884][    T8] usb 1-1: New USB device found, idVendor=05dc, idProduct=a701, bcdDevice=11.00
[    6.418850][    T8] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    6.439428][    T8] usb 1-1: Product: JD FIREFLY
[    6.444099][    T8] usb 1-1: Manufacturer: LEXAR
[    6.448750][    T8] usb 1-1: SerialNumber: 1069A704000328051007
[    6.470773][    T8] usb-storage 1-1:1.0: USB Mass Storage device detected
[    6.490204][    T8] scsi host0: usb-storage 1-1:1.0
[    7.530971][   T32] scsi 0:0:0:0: Direct-Access     LEXAR    JD FIREFLY       1100 PQ: 0 ANSI: 0 CCS
[    7.554415][   T32] sd 0:0:0:0: [sda] 7864320 512-byte logical blocks: (4.03 GB/3.75 GiB)
[    7.570165][   T32] sd 0:0:0:0: [sda] Write Protect is off
[    7.579783][   T32] sd 0:0:0:0: [sda] No Caching mode page found
[    7.585872][   T32] sd 0:0:0:0: [sda] Assuming drive cache: write through
[    7.617530][   T32]  sda: sda1
[    7.621207][   T32] sd 0:0:0:0: [sda] Attached SCSI removable disk

That is very good news. Unfortunately, the Linux 6.10.11-kirkwood-tld-1 kernel was built with UBIFS=m, which causes the failure to mount the flash ubi0:rootfs shown at the end of this post. You will see there that the list of all bdev filesystems built into the kernel is missing ubifs:

[   19.716242][    T1] VFS: Cannot open root device "ubi0:rootfs" or unknown-block(0,253): error -19
[   19.725257][    T1] Please append a correct "root=" boot option; here are the available partitions:
[   19.734421][    T1] List of all bdev filesystems:
[   19.739153][    T1]  ext3
[   19.739161][    T1]  ext4
[   19.741840][    T1]  exfat
[   19.744482][    T1]  fuseblk
[   19.747200][    T1]  xfs

This is an unfortunate omission for a kernel built for a small SoC that is designed to boot from flash. Please add (restore?) the ability of the Kirkwood kernels to boot from an flash UBIFS rootfs.

If that will take a while, please point me to the instructions I can follow to rebuild the Linux 6.10.11-kirkwood-tld-1 kernel with UBIFS support enabled (see "3. Kernel configuration" in How to support UBIFS through MTD) and I'll give that a try in the mean time.

Thank you,

Larry Baker
US Geological Survey (Ret.)

My stock Nimbus 100 U-Boot 2011.03-rc1 (Jun 23 2011 - 14:26:27) setup:

Marvell>> setenv bootcmd_ubi 'ubi part rootfs; ubifsmount rootfs; ubifsload 0x00800000 /boot/uImage'
Marvell>> setenv ubi_boot 'init_ionics mode bootup; run bootcmd_ubi; run set_ubi_bootargs; bootm 0x00800000'
Marvell>> setenv ubi_bootargs console=ttyS0,115200 cmdlinepart.$(mtdparts)
Marvell>> setenv set_ubi_bootargs 'setenv bootargs $(ubi_bootargs) ubi.mtd=rootfs rootfstype=ubifs root=ubi0:rootfs rw rootdelay=10 noswap earlyprintk=serial'
Marvell>> setenv ubi_bootcmd 'setenv bootcmd $(ubi_boot); saveenv'
Marvell>> run ubi_bootcmd
Saving Environment to NAND...
Erasing Nand...
Erasing at 0x60000 -- 100% complete.
Writing to Nand... done

The U-Boot boot of the Linux 6.10.11-kirkwood-tld-1 kernel from the UBI rootfs /boot/uImage, to the point where the booted Linux kernel cannot mount the ubi0:rootfs rootfs and panics:

Marvell>> reset
resetting ...


U-Boot 2011.03-rc1 (Jun 23 2011 - 14:26:27)
IONICS-PlugComputer NIMBUS E0

SoC:   Kirkwood 88F6281_A0
DRAM:  512 MiB
NAND:  512 MiB
In:    serial
Out:   serial
Err:   serial
Net:   egiga0
88E1116 Initialized on egiga0
Hit any key to stop autoboot:  0 
Creating 1 MTD partitions on "nand0":
0x000000a00000-0x000020000000 : "mtd=3"
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size:   131072 bytes (128 KiB)
UBI: logical eraseblock size:    129024 bytes
UBI: smallest flash I/O unit:    2048
UBI: sub-page size:              512
UBI: VID header offset:          512 (aligned 512)
UBI: data offset:                2048
UBI: attached mtd1 to ubi0
UBI: MTD device name:            "mtd=3"
UBI: MTD device size:            502 MiB
UBI: number of good PEBs:        4015
UBI: number of bad PEBs:         1
UBI: max. allowed volumes:       128
UBI: wear-leveling threshold:    4096
UBI: number of internal volumes: 1
UBI: number of user volumes:     1
UBI: available PEBs:             39
UBI: total number of reserved PEBs: 3976
UBI: number of PEBs reserved for bad PEB handling: 40
UBI: max/mean erase counter: 29/20
UBIFS: mounted UBI device 0, volume 0, name "rootfs"
UBIFS: mounted read-only
UBIFS: file system size:   505257984 bytes (493416 KiB, 481 MiB, 3916 LEBs)
UBIFS: journal size:       25288704 bytes (24696 KiB, 24 MiB, 196 LEBs)
UBIFS: media format:       w5/r0 (latest is w4/r0)
UBIFS: default compressor: LZO
UBIFS: reserved for root:  5182151 bytes (5060 KiB)
Loading file '/boot/uImage' to addr 0x00800000 with size 6185336 (0x005e6178)...
Done
## Booting kernel from Legacy Image at 00800000 ...
   Image Name:   kernel 6.10.11-kirkwood-tld-1
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    6185272 Bytes = 5.9 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

[    0.000000][    T0] Booting Linux on physical CPU 0x0
[    0.000000][    T0] Linux version 6.10.11-kirkwood-tld-1 (root@tldDebian) (gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils f4
[    0.000000][    T0] CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=0005397f
[    0.000000][    T0] CPU: VIVT data cache, VIVT instruction cache
[    0.000000][    T0] OF: fdt: Machine model: Globalscale Technologies SheevaPlug
[    0.000000][    T0] printk: legacy bootconsole [earlycon0] enabled
<snip>
[    0.000000][    T0] Kernel command line: console=ttyS0,115200 cmdlinepart.mtdparts=orion_nand:1m@0m(u-boot),4m@1m(kernel),5m@5m(l
[    0.000000][    T0] Unknown kernel command line parameters "noswap", will be passed to user space.
<snip>
[    4.954833][    T1] 4 cmdlinepart partitions found on MTD device orion_nand
[    4.961861][    T1] Creating 4 MTD partitions on "orion_nand":
[    4.967739][    T1] 0x000000000000-0x000000100000 : "u-boot"
[    4.974284][    T1] 0x000000100000-0x000000500000 : "kernel"
[    4.980842][    T1] 0x000000500000-0x000000a00000 : "pluginfo"
[    4.987568][    T1] 0x000000a00000-0x000020000000 : "rootfs"
<snip>
[    8.649097][    T1] ubi0: attaching mtd3
[    9.278672][    T1] ubi0: scanning is finished
[    9.302685][    T1] ubi0: attached mtd3 (name "rootfs", size 502 MiB)
[    9.309199][    T1] ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes
[    9.316862][    T1] ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 512
[    9.324325][    T1] ubi0: VID header offset: 512 (aligned 512), data offset: 2048
[    9.331869][    T1] ubi0: good PEBs: 4015, bad PEBs: 1, corrupted PEBs: 0
[    9.338704][    T1] ubi0: user volume: 1, internal volumes: 1, max. volumes count: 128
[    9.346696][    T1] ubi0: max/mean erase counter: 29/20, WL threshold: 4096, image sequence number: 1245509428
[    9.356775][    T1] ubi0: available PEBs: 0, total reserved PEBs: 4015, PEBs reserved for bad PEB handling: 79
[    9.366870][  T129] ubi0: background thread "ubi_bgt0d" started, PID 129
<snip>
[   19.716242][    T1] VFS: Cannot open root device "ubi0:rootfs" or unknown-block(0,253): error -19
[   19.725257][    T1] Please append a correct "root=" boot option; here are the available partitions:
[   19.734421][    T1] List of all bdev filesystems:
[   19.739153][    T1]  ext3
[   19.739161][    T1]  ext4
[   19.741840][    T1]  exfat
[   19.744482][    T1]  fuseblk
[   19.747200][    T1]  xfs
[   19.750148][    T1] 
[   19.754895][    T1] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,253)
[   19.764077][    T1] CPU: 0 PID: 1 Comm: swapper Not tainted 6.10.11-kirkwood-tld-1 #1 211932710076a3f6d6304997ca04b9111b47c9c4
[   19.775533][    T1] Hardware name: Marvell Kirkwood (Flattened Device Tree)
[   19.782537][    T1] Call trace: 
[   19.782552][    T1]  unwind_backtrace from show_stack+0x10/0x14
[   19.791781][    T1]  show_stack from panic+0xf0/0x334
[   19.796882][    T1]  panic from mount_root_generic+0x1d0/0x2a8
[   19.802768][    T1]  mount_root_generic from prepare_namespace+0x1b8/0x244
[   19.809700][    T1]  prepare_namespace from kernel_init_freeable+0x1bc/0x20c
[   19.816806][    T1]  kernel_init_freeable from kernel_init+0x10/0x138
[   19.823312][    T1]  kernel_init from ret_from_fork+0x14/0x28
[   19.829108][    T1] Exception stack(0xa0819fb0 to 0xa0819ff8)
[   19.834895][    T1] 9fa0:                                     00000000 00000000 00000000 00000000
[   19.843817][    T1] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[   19.852744][    T1] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[   19.860099][    T1] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,253) ]---]http://www.linux-mtd.infradead.org/faq/ubifs.html[/url]:

=====================
Edits
Changed title from "Please add built-in kernel UBIFS support for Kirkwood and any other boards with on-board eMMC flash" to "Debian on Ionics Nimbus 100",
Changed references to "eMMC" to "flash" (Nimbus has NAND flash, not eMMC)



Edited 2 time(s). Last edit at 10/25/2024 03:32PM by mossbeachlarry.

Hi Larry,

Please use kernel linux-6.9.6-kirkwood-tld-1 for now.

Quote
https://forum.doozan.com/read.php?2,12096

Updated 26 Jun 2024:

Kernel linux-6.9.6-kirkwood-tld-1 package has been uploaded. The following features were added/updated:

UBIFS as a loadable module should work for most cases. All of Kirkwood boxes that I support here run Ext3/Ext4 on USB or HDD/SDD rootfs. Yours is the first that run UBIFS rootfs.

The reason I moved it out to loadable module was because the kernel got too big. There are some Kirkwood boxes that still run stock u-boot and there was at least one box that could not handle kernel image > 6MB.

But I do agree with you about UBIFS should be built into kernel if possible. That's how I configured UBIFS in the Kirkwood kernels for many years here.

I'll look into this issue and hopefully will reconfigure it back to builtin kernel in 6.11.x (if I can).

=========
bodhi's edit: the Nimbus 100 does not have eMMC

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



Edited 1 time(s). Last edit at 10/06/2024 01:54PM by bodhi.

bodhi,

I may have misspoken about the Nimbus having eMMC. I think I was thinking of the BeagleBone Black. The internal flash on the Nimbus is an MTD device, which is a NAND or NOR device, I can't remember which. It should be identical to the Marvell SheevaPlug (it uses the SheevaPlug DTB file).

I have no trouble reading and writing to the UBIFS rootfs I am targeting to run Debian 12 from the Debian 11 I installed on a USB drive. It has loadable ubi and ubifs modules. I do have to force the kernel to load the ubi module manually in /etc/modules for the UBIFS utilities (e.g., ubiattach) to work.

I am working on setting up a kernel build to run overnight using the latest Linux 6.x kernel source (6.11.2) and your 6.10.11-kirkwood-tld-1 kernel config file, modified to change UBIFS to "y". I'll let you know how it goes. Like, whether the kernel gets too big to fit in the rootfs MTD flash partition. That really doesn't matter to me, though, because the stock Nimbus U-Boot can load uImage from a UBIFS rootfs, exactly as it does for a USB uImage.

I will have a look at your linux-6.9.6-kirkwood-tld-1 kernel as well. I have to be a bit careful about going too far back with the Linux 6.x kernel version because I know the Debian 12 Linux Kirkwood 6.x kernel fails to enumerate USB drives on my Nimbus, but does not have that problem on my SheevaPlug. That bug in the Linux kernel is fixed in your 6.10.11-kirkwood-tld-1 kernel.

Thank you for your prompt reply.

Larry Baker

bodhi,

Feel free to edit what I wrote to remove "eMMC" from the title and the text so it won't cause any confusion.

Thanks,

Larry Baker

Larry,

> I may have misspoken about the Nimbus having eMMC.
> I think I was thinking of the BeagleBone Black.
> The internal flash on the Nimbus is an MTD device,
> which is a NAND or NOR device, I can't remember
> which.

> It should be identical to the Marvell
> SheevaPlug (it uses the SheevaPlug DTB file).

OK. Then the kernel and rootfs should be on USB drive.

> I have no trouble reading and writing to the UBIFS
> rootfs I am targeting to run Debian 12 from the
> Debian 11 I installed on a USB drive. It has
> loadable ubi and ubifs modules. I do have to
> force the kernel to load the ubi module manually
> in /etc/modules for the UBIFS utilities (e.g.,
> ubiattach) to work.
>
> I am working on setting up a kernel build to run
> overnight using the latest Linux 6.x kernel source
> (6.11.2) and your 6.10.11-kirkwood-tld-1 kernel
> config file, modified to change UBIFS to "y".

Why would you want to use UBIFS on a USB drive? the "best" file system for storage device is Ext3/Ext4.

For a Sheevaplug clone like this Nimbus, best to use Ext3 (or Ext4 if you install the new u-boot) for rootfs. And load the kernel directly from the Ext3/Ext4 rootfs.

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



Edited 1 time(s). Last edit at 10/05/2024 12:59PM by bodhi.

bodhi,

I am sorry to have confused things.

> OK. Then the kernel and rootfs should be on USB drive.

No, not on the USB drive. The kernel uImage and its optional initramfs uInitrd are in the /boot directory of the UBIFS flash rootfs, the same way a kernel uImage and its optional initramfs uInitrd are in the /boot directory on a USB ext2/3/4 rootfs. The factory U-Boot on a Nimbus supports loading the kernel uImage and its optional uInitrd initramfs from flash UBIFS, USB FAT, and USB ext2 drives.

> Why would you want to use UBIFS on a USB drive? the "best" file system for storage device is Ext3/Ext4.

I am not booting a USB drive; I am booting the internal UBIFS flash rootfs. UBIFS is only for MTD flash partitions, not block devices, such as USB drive partitions.

> For a Sheevaplug clone like this Nimbus, best to use Ext3 (or Ext4 if you install the new u-boot) for rootfs. And load the kernel directly from the Ext3/Ext4 rootfs.

Not if you want to run entirely self contained. UBIFS is a very reliable file system; it is designed to map around bad flash eraseblocks, something the JFFS2 flash file system does not do. And a UBIFS MTD flash is faster than a USB ext2/3/4 flash drive on a SheevaPlug/Nimbus because of the slow USB 2.0.

I have created a ~500 MB Debian "stable" UBIFS rootfs using debootstrap that leaves about half the space available. This is exactly what I wanted. However, none of the Linux kernels I have run (your versions 5.15.5, 5.18.6, 6.9.6, and 6.10.11, and my version of your 6.10.11 with UBIFS support) work with a USB drive. They either fail to enumerate the USB drive at all (version 5.15.5), or they have this strange behavior of disconnecting the drive right after enumerating the partitions (version 5.18.6 and later), so it does not get added to /dev and is not shown by lsusb:

[    6.159535][    T8] usb 1-1: new high-speed USB device number 2 using orion-ehci
[    6.382035][    T8] usb 1-1: New USB device found, idVendor=05dc, idProduct=a701, bcdDevice=11.00
[    6.399384][    T8] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    6.407270][    T8] usb 1-1: Product: JD FIREFLY
[    6.429394][    T8] usb 1-1: Manufacturer: LEXAR
[    6.434061][    T8] usb 1-1: SerialNumber: 1069A704000328051007
[    6.450718][    T8] usb-storage 1-1:1.0: USB Mass Storage device detected
[    6.470156][    T8] scsi host0: usb-storage 1-1:1.0
[    7.530997][   T20] scsi 0:0:0:0: Direct-Access     LEXAR    JD FIREFLY       1100 PQ: 0 ANSI: 0 CCS
[    7.554439][   T20] sd 0:0:0:0: [sda] 7864320 512-byte logical blocks: (4.03 GB/3.75 GiB)
[    7.570067][   T20] sd 0:0:0:0: [sda] Write Protect is off
[    7.579684][   T20] sd 0:0:0:0: [sda] No Caching mode page found
[    7.585767][   T20] sd 0:0:0:0: [sda] Assuming drive cache: write through
[    7.620052][   T20]  sda: sda1
[    7.623781][   T20] sd 0:0:0:0: [sda] Attached SCSI removable disk
[    8.621843][    T8] usb 1-1: USB disconnect, device number 2

The only kernel that works with a USB drive on my Nimbus is the Debian 11 5.10.0-32-marvell kernel. But I have to run that from a USB drive because it does not have UBIFS support built into the kernel, which is a requirement to boot a UBIFS rootfs (the zstd compressor cannot be initialized).

Note: I can send you the config files for your linux-6.10.11-kirkwood-tld-1 package with UBIFS support and other changes that reduce the size of the kernel and compress the modules. For example, here are the changes I made first to support UBIFS, to remove deprecated file systems, and to compress the kernel modules:

$ cd ~/armel-kernel/linux-6.10.11
$ ARCH=arm CROSS_COMPILE=arm-none-eabi- make mrproper
$ cp ../bodhi/config-6.10.11-kirkwood-tld-1 .config
$ ARCH=arm CROSS_COMPILE=arm-none-eabi- make menuconfig

Make the following changes:

   General setup  --->
      (-kirkwood-UBIFS) Local version - append to kernel release
      [*] Automatically append version information to the version string

[*] Enable loadable module support  --->
      Module compression mode (XZ)  --->

    Device Drivers  --->
    <*> Memory Technology Device (MTD) support  --->
        <*>   Enable UBI - Unsorted block images  --->
              --- Enable UBI - Unsorted block images
              *** LEAVE OPTIONS AS-IS ***

    File systems  --->
    < > Second extended fs support (DEPRECATED)   <=== WAS <M>
    < > Reiserfs support (deprecated)             <=== WAS <M>
    [*] Miscellaneous filesystems  --->
    <*>   UBIFS file system support               <=== WAS <M>

< Exit >
$ echo "=== `date` ===" ; \
  ARCH=arm CROSS_COMPILE=arm-none-eabi- make -j `nproc` ; \
  echo "=== `date` ==="

The module compression option made a huge difference: the uncompressed kernel modules occupy over 90MB, the compressed kernel modules occupy only about 30 MB! And, FYI, you can compress the installed modules yourself without having to rebuild them. I did that for your linux-6.10.11-kirkwood-tld-1 kernel modules.

The next version I made removed most of the CONFIG_DEBUG options in linux-6.10.11-kirkwood-tld-1.

I would like to try your older kernels, back to the same 5.10.x kernels that should be close to the Debian 11 5.10.0-32-marvell kernel. Do you still have your Kirkwood Linux 5.10.x kernel packages available?

Thank you,

Larry Baker

Larry,


> No, not on the USB drive. The kernel uImage and
> its optional initramfs uInitrd are in the /boot
> directory of the UBIFS flash rootfs, the same way
> a kernel uImage and its optional initramfs uInitrd
> are in the /boot directory on a USB ext2/3/4
> rootfs. The factory U-Boot on a Nimbus supports
> loading the kernel uImage and its optional uInitrd
> initramfs from flash UBIFS, USB FAT, and USB ext2
> drives.

OK. Now it makes more sense.

>
> They either fail
> to enumerate the USB drive at all (version
> 5.15.5), or they have this strange behavior of
> disconnecting the drive right after enumerating
> the partitions (version 5.18.6 and later), so it
> does not get added to /dev and is not shown by
> lsusb:

Please post the serial boot log for running one of the latest of my kernel releases (perferably linux-6.9.6-kirkwood-tld-1). When you post the serial boot log, I like to see the entire boot log (from the u-boot banner, until the command lsusb).

> The only kernel that works with a USB drive on my
> Nimbus is the Debian 11 5.10.0-32-marvell kernel.

> I would like to try your older kernels, back to
> the same 5.10.x kernels that should be close to
> the Debian 11 5.10.0-32-marvell kernel. Do you
> still have your Kirkwood Linux 5.10.x kernel
> packages available?

I don't think it will make any difference. The Sheevaplug DTS has not been changed significantly for many years (probably 10). And the current DTS has all that take to enumerate and power the USB drive. And I have not seen report about problem with USB drives here for as many years.

But after I see the boot log, I could look for it in my archive and re-upload kernel 5.10.x for you, if necessary.

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



Edited 1 time(s). Last edit at 10/15/2024 09:54PM by bodhi.

bodhi,

Here's some information about my setup. I issued the commands below from the console, so they include console messages as well as command output.

I do all my configuration of the internal flash UBIFS rootfs from a Debian 11 system running on USB:

# uname -a
Linux comlogger 5.10.0-32-marvell #1 Debian 5.10.223-1 (2024-08-10) armv5tel GNU/Linux

I always pass the cmdlinepart.mtdparts needed to access the MTD partitions in the U-Boot kernel command line. Here's what the Debian 11 USB system sees:

# cat /proc/cmdline
console=ttyS0,115200 cmdlinepart.mtdparts=orion_nand:1m@0m(u-boot),4m@1m(kernel),5m@5m(pluginfo),-(rootfs)

# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00100000 00020000 "u-boot"
mtd1: 00400000 00020000 "kernel"
mtd2: 00500000 00020000 "pluginfo"
mtd3: 1f600000 00020000 "rootfs"

On the Debian 11 USB system, I can mount the internal flash UBIFS rootfs file system (on mtd3) to access it like any other file system:

# ubiattach /dev/ubi_ctrl -m 3
[13527.035886] ubi0: attaching mtd3
[13527.672791] ubi0: scanning is finished
[13527.698014] ubi0: attached mtd3 (name "rootfs", size 502 MiB)
[13527.703897] ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes
[13527.710849] ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 512
[13527.717607] ubi0: VID header offset: 512 (aligned 512), data offset: 2048
[13527.724452] ubi0: good PEBs: 4015, bad PEBs: 1, corrupted PEBs: 0
[13527.730591] ubi0: user volume: 1, internal volumes: 1, max. volumes count: 128
[13527.737872] ubi0: max/mean erase counter: 33/23, WL threshold: 4096, image sequence number: 1245509428
[13527.747235] ubi0: available PEBs: 0, total reserved PEBs: 4015, PEBs reserved for bad PEB handling: 79
[13527.758435] ubi0: background thread "ubi_bgt0d" started, PID 738
UBI device number 0, total 4015 LEBs (518031360 bytes, 494.0 MiB), available 0 LEBs (0 bytes), LEB size 129024 bytes (126.0 KiB)

# mount -t ubifs ubi0:rootfs /mnt/ubi
[13535.137146] UBIFS (ubi0:0): Mounting in unauthenticated mode
[13535.172813] UBIFS (ubi0:0): background thread "ubifs_bgt0_0" started, PID 758
[13535.261591] UBIFS (ubi0:0): UBIFS: mounted UBI device 0, volume 0, name "rootfs"
[13535.269074] UBIFS (ubi0:0): LEB size: 129024 bytes (126 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
[13535.279084] UBIFS (ubi0:0): FS size: 505257984 bytes (481 MiB, 3916 LEBs), journal size 25288704 bytes (24 MiB, 196 LEBs)
[13535.290115] UBIFS (ubi0:0): reserved for root: 4952683 bytes (4836 KiB)
[13535.296781] UBIFS (ubi0:0): media format: w5/r0 (latest is w5/r0), UUID 61DD0181-325A-4973-8CC9-B622774C16AE, small LPT model

I have collected or built (cross-compiled on a Linux x86_64 PC) several kernels and their modules:

# ls -lh ~/armel-kernels/boot
total 88M
-rw-r--r--. 1 root  root   38K Nov 28  2021 bodhi-config-5.15.5-kirkwood-tld-1.xz
-rw-r--r--. 1 root  root   38K Jun 24  2022 bodhi-config-5.18.6-kirkwood-tld-1.xz
-rw-r--r--. 1 root  root   40K Jun 21 14:33 bodhi-config-6.9.6-kirkwood-tld-1.xz
-rw-r--r--. 1 root  root  783K Nov 28  2021 bodhi-System.map-5.15.5-kirkwood-tld-1.xz
-rw-r--r--. 1 root  root  773K Jun 24  2022 bodhi-System.map-5.18.6-kirkwood-tld-1.xz
-rw-r--r--. 1 root  root  748K Jun 21 14:33 bodhi-System.map-6.9.6-kirkwood-tld-1.xz
-rw-r--r--. 1 root  root  5.5M Oct 14 15:32 bodhi-uImage-5.15.5-kirkwood-tld-1
-rw-r--r--. 1 root  root  5.5M Oct 14 14:54 bodhi-uImage-5.18.6-kirkwood-tld-1
-rw-r--r--. 1 root  root  6.0M Oct 13 12:46 bodhi-uImage-6.9.6-kirkwood-tld-1
-rwxr-xr-x. 1 root  root  5.4M Nov 28  2021 bodhi-zImage-5.15.5-kirkwood-tld-1
-rwxr-xr-x. 1 root  root  5.5M Jun 24  2022 bodhi-zImage-5.18.6-kirkwood-tld-1
-rwxr-xr-x. 1 root  root  6.0M Jun 21 16:48 bodhi-zImage-6.9.6-kirkwood-tld-1
-rw-r--r--  1 root  root   39K Oct 16 12:48 config-5.10.223-marvell-UBIFS.xz
-rw-r--r--  1 root  root   39K Oct 16 12:48 config-5.10.223-marvell.xz
-rw-rw-r--. 1 baker baker  40K Oct  9 22:25 config-6.10.11-kirkwood-tld-1.xz
-rw-rw-r--. 1 baker baker  40K Oct 10 13:43 config-6.10.11-kirkwood-UBIFS-2.xz
-rw-rw-r--. 1 baker baker  40K Oct  9 18:35 config-6.10.11-kirkwood-UBIFS.xz
-rw-r--r--  1 root  root  412K Oct 16 12:48 System.map-5.10.223-marvell-UBIFS.xz
-rw-r--r--  1 root  root  394K Oct 16 12:48 System.map-5.10.223-marvell.xz
-rw-rw-r--. 1 baker baker 749K Oct  9 22:25 System.map-6.10.11-kirkwood-tld-1.xz
-rw-rw-r--. 1 baker baker 734K Oct 10 13:43 System.map-6.10.11-kirkwood-UBIFS-2.xz
-rw-rw-r--. 1 baker baker 754K Oct  9 18:35 System.map-6.10.11-kirkwood-UBIFS.xz
-rw-r--r--  1 root  root  2.4M Oct 16 13:13 uImage-5.10.223-marvell
-rw-r--r--  1 root  root  2.6M Oct 16 13:14 uImage-5.10.223-marvell-UBIFS
-rw-r--r--. 1 root  root  5.9M Oct 12 13:28 uImage-6.10.11-kirkwood-tld-1
-rw-r--r--. 1 root  root  6.0M Oct 12 13:28 uImage-6.10.11-kirkwood-UBIFS
-rw-r--r--. 1 root  root  5.9M Oct 12 13:28 uImage-6.10.11-kirkwood-UBIFS-2
-rwxr-xr-x  1 root  root  2.4M Oct 16 12:49 zImage-5.10.223-marvell
-rwxr-xr-x  1 root  root  2.6M Oct 16 12:49 zImage-5.10.223-marvell-UBIFS
-rwxrwxr-x. 1 baker baker 5.9M Oct  9 22:25 zImage-6.10.11-kirkwood-tld-1
-rwxrwxr-x. 1 baker baker 6.0M Oct  9 18:35 zImage-6.10.11-kirkwood-UBIFS
-rwxrwxr-x. 1 baker baker 5.9M Oct 10 13:43 zImage-6.10.11-kirkwood-UBIFS-2
-rwxr-xr-x  1 root  root  2.6M Oct 16 13:14 zImage.fdt

# du -sh ~/armel-kernels/lib/modules/*
111M	/root/armel-kernels/lib/modules/5.10.223-marvell
109M	/root/armel-kernels/lib/modules/5.10.223-marvell-UBIFS
87M	/root/armel-kernels/lib/modules/5.15.5-kirkwood-tld-1
87M	/root/armel-kernels/lib/modules/5.18.6-kirkwood-tld-1
33M	/root/armel-kernels/lib/modules/6.10.11-kirkwood-tld-1
33M	/root/armel-kernels/lib/modules/6.10.11-kirkwood-UBIFS
32M	/root/armel-kernels/lib/modules/6.10.11-kirkwood-UBIFS-2
33M	/root/armel-kernels/lib/modules/6.9.6-kirkwood-tld-1

The kernels with the "bodhi-" prefix are yours. I cross-compiled the others. The 6.10.11 kernels are based on your 6.10.11-kirkwood-tld-1 release: the tld-1 suffix is unchanged from your configuration; the UBIFS suffix adds kernel UBIFS support, compresses the kernel modules, and removes two deprecated file systems; the UBIFS-2 suffix removes most of the DEBUG options from the UBIFS version. The 5.10.223 kernels are based on the Debian 11 5.10.223 Marvell ARM kernel.

I have already installed several kernels and their modules to the flash UBIFS rootfs:

# ls -lh /mnt/ubi/boot                                                                                              
total 26M
-rw-r--r-- 1 root root 5.5M Oct 14 15:37 bodhi-uImage-5.15.5-kirkwood-tld-1
-rw-r--r-- 1 root root 5.5M Oct 14 15:01 bodhi-uImage-5.18.6-kirkwood-tld-1
-rw-r--r-- 1 root root  11K Oct 13 03:00 kirkwood-sheevaplug.dtb
lrwxrwxrwx 1 root root   31 Oct 15 16:13 uImage -> uImage-6.10.11-kirkwood-UBIFS-2
-rw-r--r-- 1 root root 2.6M Oct 16 13:21 uImage-5.10.223-marvell-UBIFS
-rw-r--r-- 1 root root 5.9M Oct 13 02:56 uImage-6.10.11-kirkwood-UBIFS-2
-rw-r--r-- 1 root root 6.0M Oct 13 12:30 uImage-6.9.6-kirkwood-tld-1

# du -sh /mnt/ubi/lib/modules/*
105M	/mnt/ubi/lib/modules/5.10.223-marvell-UBIFS
84M	/mnt/ubi/lib/modules/5.15.5-kirkwood-tld-1
84M	/mnt/ubi/lib/modules/5.18.6-kirkwood-tld-1
30M	/mnt/ubi/lib/modules/6.10.11-kirkwood-UBIFS-2
30M	/mnt/ubi/lib/modules/6.9.6-kirkwood-tld-1

My little flash UBIFS rootfs is just about full!:

# df -h /mnt/ubi
Filesystem      Size  Used Avail Use% Mounted on
ubi0:rootfs     453M  372M   77M  83% /mnt/ubi

U-Boot loads the kernel from /boot/uImage. All I have to do is soft link /boot/uImage to the kernel I want to boot.

For example, you can see the flash UBIFS rootfs is currently configured to boot the 6.10.11-kirkwood-UBIFS-2 kernel. To switch to a different kernel, 6.9.6-kirkwood-tld-1, for example, I type:

# ( cd /mnt/ubi/boot ; rm -f uImage ; ln -s uImage-6.9.6-kirkwood-tld-1 uImage )

And then I reboot and stop the USB boot by interrupting U-Boot:

# reboot
<snip>
[76073.736985] reboot: Restarting system


U-Boot 2011.03-rc1 (Jun 23 2011 - 14:26:27)
IONICS-PlugComputer NIMBUS E0

SoC:   Kirkwood 88F6281_A0
DRAM:  512 MiB
NAND:  512 MiB
In:    serial
Out:   serial
Err:   serial
Net:   egiga0
88E1116 Initialized on egiga0
Hit any key to stop autoboot:  0 
Marvell>>

Here's the Nimbus 100 U-Boot 2011.03-rc1 (Jun 23 2011 - 14:26:27) environment variables:

Marvell>> printenv
baudrate=115200
bootargs=console=ttyS0,115200 cmdlinepart.mtdparts=orion_nand:1m@0m(u-boot),4m@1m(kernel),5m@5m(pluginfo),-(rootfs)
bootargs_console=console=ttyS0,115200 cmdlinepart.mtdparts=orion_nand:1m@0m(u-boot),4m@1m(kernel),5m@5m(pluginfo),-(rootfs)
bootcmd=init_ionics mode bootup; run bootcmd_usb; setenv bootargs $(bootargs_console); bootm 0x00800000 0x01100000
bootcmd_ubi=ubi part rootfs; ubifsmount rootfs; ubifsload 0x00800000 /boot/uImage
bootcmd_usb=usb start; ext2load usb 0:1 0x00800000 /boot/uImage; ext2load usb 0:1 0x01100000 /boot/uInitrd
bootdelay=3
ethact=egiga0
ethaddr=00:26:db:00:00:00
ionicsplug_board=xxxxxxxxxx
ionicsplug_firmware=xxxxxxxxxx
ionicsplug_model=xxxxxxxxxx
ionicsplug_part=xxxxxxxxxx
ionicsplug_serial=xxxxxxxxxx
load_initrd_mfg=usb start; fatload usb 0 0x800000 uImage; fatload usb 0 0x1200000 initrd.mfg
load_initrd_usr=usb start; fatload usb 0 0x800000 uImage; run ubi_initrd
mtddevname=u-boot
mtddevnum=0
mtdids=nand0=orion_nand
mtdparts=mtdparts=orion_nand:1m@0m(u-boot),4m@1m(kernel),5m@5m(pluginfo),-(rootfs)
nand_kernel=nand read 0x800000 0x100000 0x400000
partition=nand0,0
reflash_mfg=init_ionics mode flashing ; run load_initrd_mfg ; setenv bootargs console=ttyS0,115200 $(mtdparts); bootm 0x800000 0x120
reflash_usr=init_ionics mode flashing ; run load_initrd_usr ; setenv bootargs console=ttyS0,115200 $(mtdparts); bootm 0x800000 0x120
set_ubi_bootargs=setenv bootargs $(ubi_bootargs) ubi.mtd=rootfs rootfstype=ubifs root=ubi0:rootfs rw earlyprintk=serial
stderr=serial
stdin=serial
stdout=serial
ubi_boot=init_ionics mode bootup; run bootcmd_ubi; run set_ubi_bootargs; bootm 0x00800000
ubi_bootargs=console=ttyS0,115200 cmdlinepart.mtdparts=orion_nand:1m@0m(u-boot),4m@1m(kernel),5m@5m(pluginfo),-(rootfs)
ubi_bootcmd=setenv bootcmd $(ubi_boot); saveenv
ubi_initrd=ubi part pluginfo; ubifsmount pluginfo; ubifsload 0x1200000 initrd.usr
usb_boot=init_ionics mode bootup; run bootcmd_usb; setenv bootargs $(bootargs_console); bootm 0x00800000 0x01100000
usb_bootcmd=setenv bootcmd $(usb_boot); saveenv

Environment size: 2133/131068 bytes

I built the flash UBIFS rootfs (using debootstrap) without an initramfs, so U-Boot loads only the kernel uImage, no uInitrd. Unlike booting Debian 11 from the USB rootfs, which has both a uImage and a uInitrd.

I leave the Debian 11 USB drive plugged in and boot the flash UBIFS roots using "run ubi_boot" so it does not disturb the default USB bootcmd:

Marvell>> run ubi_boot
Creating 1 MTD partitions on "nand0":
0x000000a00000-0x000020000000 : "mtd=3"
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size:   131072 bytes (128 KiB)
UBI: logical eraseblock size:    129024 bytes
UBI: smallest flash I/O unit:    2048
UBI: sub-page size:              512
UBI: VID header offset:          512 (aligned 512)
UBI: data offset:                2048
UBI: attached mtd1 to ubi0
UBI: MTD device name:            "mtd=3"
UBI: MTD device size:            502 MiB
UBI: number of good PEBs:        4015
UBI: number of bad PEBs:         1
UBI: max. allowed volumes:       128
UBI: wear-leveling threshold:    4096
UBI: number of internal volumes: 1
UBI: number of user volumes:     1
UBI: available PEBs:             39
UBI: total number of reserved PEBs: 3976
UBI: number of PEBs reserved for bad PEB handling: 40
UBI: max/mean erase counter: 33/23
UBIFS: mounted UBI device 0, volume 0, name "rootfs"
UBIFS: mounted read-only
UBIFS: file system size:   505257984 bytes (493416 KiB, 481 MiB, 3916 LEBs)
UBIFS: journal size:       25288704 bytes (24696 KiB, 24 MiB, 196 LEBs)
UBIFS: media format:       w5/r0 (latest is w4/r0)
UBIFS: default compressor: LZO
UBIFS: reserved for root:  5182151 bytes (5060 KiB)
Loading file '/boot/uImage' to addr 0x00800000 with size 6126192 (0x005d7a70)...
Done
## Booting kernel from Legacy Image at 00800000 ...
   Image Name:   kernel 6.10.11-kirkwood-UBIFS-2
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    6126128 Bytes = 5.8 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

When Linux comes up, lsusb usually does not show any USB drives:

root@comlogger:~# uname -a
Linux comlogger 6.10.11-kirkwood-UBIFS-2 #1 PREEMPT Thu Oct 10 13:31:58 PDT 2024 armv5tel GNU/Linux

root@comlogger:~# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

I have not yet tried my cross-compiled Debian 11 5.10.223-marvell-UBIFS with UBIFS kernel support. I'll run through several kernel boots and attach the console output and kernel config files for you.

More to come.

Larry Baker

Hi Larry,

It's always harder to help people who are advanced Linux users/developers :) This box has a different u-boot. And stock kernel is also not Sheevaplug kernel. So I'm peeling the onion to get to the issue. Please feel free to ask questions after you done the following.

What I'd like you to do is (no more, no less).

Quote
bodhi
Please post the serial boot log for running one of the latest of my kernel releases (perferably linux-6.9.6-kirkwood-tld-1). When you post the serial boot log, I like to see the entire boot log (from the u-boot banner, until the command lsusb).

So,

1. Log in to the current system and install kernel linux-6.9.6-kirkwood-tld-1. Using the downloaded deb files in the tarball (not your compiled kernel). See the installation instruction at

Quote
https://forum.doozan.com/read.php?2,12096
Updated 26 Jun 2024:

Kernel linux-6.9.6-kirkwood-tld-1 package has been uploaded. The following features were added/updated:

2. Reboot with serial console connected and interrupt serial console, and start the USB drive, and then run your boot command. While we are here, also get some info, too.

md.l 0xF1010000 8
md.l 0xF1010100 1
md.l 0xF1010140 1
usb start
md.l 0xF1010100 1
md.l 0xF1010140 1
run ubi_boot

Log in and do

lsusb

And then capture the entire serial console log (from u-boot banner until the command lsub). Please don't post snipets, I'd like to see the whole boot log.

=======

As I mentioned above, eventhough this is a Sheevaplug clone, but there are differences in u-boot and kernel. For example, the USB power GPIO might be different. So first, I like to see the boot with my released Kirkwood kernel, to see where it failed. And then the next step is to do some more digging in u-boot, comparing it with the Sheevaplug u-boot. As usual, stock u-boot configuration will confirm if the current Sheevaplug DTS can be used as is, or some modification is needed.

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



Edited 1 time(s). Last edit at 10/16/2024 06:43PM by bodhi.

bodhi,

(I just noticed you replied to my previous post while I was composing this. I'll read what you wrote as soon as I post this.)

(I also just found out I can only attach three files. I will attach the remaining files in subsequent posts.)

Attached are the minicom capture log files and their assiciated kernel configuration files from four boots of my Nimbus 100:

Trials:

1. Boot stock Debian 11 5.10.223-1-marvell on a USB rootfs
2. Boot your vanilla 6.9.6-kirkwood-tld-1 on a flash UBIFS rootfs
3. Boot "your" 6.10.11-kirkwood-UBIFS-2 (your 6.10.11-kirkwood-tld-1, modified to add UBIFS support) on a flash UBIFS rootfs
4. Boot Debian 11 5.10.223-1-marvell-UBIFS (Debian 11 5.10.223-1-marvell, modified to add UBIFS support) on a flash UBIFS rootfs

minicom capture log files:

1. debian-11-5.10.223-1-marvell-USB-rootfs.log
2. bodhi-6.9.6-kirkwood-tld-1-UBIFS-rootfs.log
3. my-6.10.11-kirkwood-UBIFS-2-UBIFS-rootfs.log
4. my-5.10.223-marvell-UBIFS-UBIFS-rootfs.log

Kernel configuration files:

1. debian-11-config-5.10.0-32-marvell
2. bodhi-config-6.9.6-kirkwood-tld-1
3. my-config-6.10.11-kirkwood-UBIFS-2
4. my-config-5.10.223-marvell-UBIFS

Only the Debian 11 5.10.223-marvell kernels successfully enumerate the USB drive. Your 6.9.6-kirkwood and 6.10.11-kirkwood-UBIFS-2 (built by me to add UBIFS support) kernels enumerate the USB drive and its partitions, then, mysteriously, disconnect the drive right after enumerating the partitions:

$ grep -A 2 -w lsusb *.log
bodhi-6.9.6-kirkwood-tld-1-UBIFS-rootfs.log:root@comlogger:~# lsusb
bodhi-6.9.6-kirkwood-tld-1-UBIFS-rootfs.log-Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
bodhi-6.9.6-kirkwood-tld-1-UBIFS-rootfs.log-root@comlogger:~# ls /dev/sd*
--
debian-11-5.10.223-1-marvell-USB-rootfs.log:root@comlogger:~# lsusb
debian-11-5.10.223-1-marvell-USB-rootfs.log-Bus 001 Device 002: ID 05dc:a701 Lexar Media, Inc. JumpDrive FireFly
debian-11-5.10.223-1-marvell-USB-rootfs.log-Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
--
my-5.10.223-marvell-UBIFS-UBIFS-rootfs.log:root@comlogger:~# lsusb
my-5.10.223-marvell-UBIFS-UBIFS-rootfs.log-Bus 001 Device 002: ID 05dc:a701 Lexar Media, Inc. JumpDrive FireFly
my-5.10.223-marvell-UBIFS-UBIFS-rootfs.log-Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
--
my-6.10.11-kirkwood-UBIFS-2-UBIFS-rootfs.log:root@comlogger:~# lsusb
my-6.10.11-kirkwood-UBIFS-2-UBIFS-rootfs.log-Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
my-6.10.11-kirkwood-UBIFS-2-UBIFS-rootfs.log-root@comlogger:~# ls /dev/sd*

I am actually in pretty good shape now. I can run Debian 12 off a flash UBIFS rootfs using the Debian 11 kernel, modified to add UBIFS support. (The Debian 12 kernel suffers from the same failure to enumerate the USB drive, which is why I had to install Debian 11 on my USB drive in the first place.)

Larry Baker

Continuation of my previous post to add three more files.

Continuation of my previous post to add the last two files.

bodhi,

Before I carefully follow your most recent request, here is a copy of the dtb file from the Debian 11 5.10.0-32-marvell kernel. It is different than the one in your 6.10.11 package. I will decompile it and compare it to the dtb files in your 6.9.6 and 6.10.11 packages.

As far as the old Nimbus U-Boot, I do not think that is an issue. When I tried to install Debian 12 on a USB drive, it would not enumerate the drive. Debian 12 uses a Linux 6 kernel. I updated U-Boot to a much more recent version, which made no difference. So, I restored the original configuration of my Nimbus to a known working state. For one thing, I do not know what the U-Boot "init_ionics mode" command does. I thought it best to include whatever that does, in case it is important. (I actually don't think it matters.)

Larry Baker

bodhi,

I did a fresh install of linux-6.9.6-kirkwood-tld-1-bodhi.tar.bz2 on the flash UBIFS rootfs. Attached is the minicom capture log file following your instructions.

> This box has a different u-boot. And stock kernel is also not Sheevaplug kernel.

I don't understand how either of these matter.

I tried the new U-Boot from http://ftp.debian.org/debian/dists/bookworm/main/installer-armel/current/images/kirkwood/u-boot/sheevaplug/u-boot.kwb, but went back to the OEM U-Boot. The OEM U-Boot seems to work fine for me, because I have no trouble using a USB drive with a Debian 11 5.10.223-marvell kernel, both their original, and the one I built with UBIFS support added. And the Debian 12 installer fails to find a USB drive for the installation using either one.

The Debian 11 5.10.223-marvell kernel is a "Marvell" kernel, whatever that means. The installer is specifically for a SheevaPlug:

# mkdir -p /opt/nimbus/bullseye
# cd /opt/nimbus/bullseye
# wget http://ftp.debian.org/debian/dists/bullseye/main/installer-armel/current/images/kirkwood/netboot/marvell/sheevaplug/uImage
# wget http://ftp.debian.org/debian/dists/bullseye/main/installer-armel/current/images/kirkwood/netboot/marvell/sheevaplug/uInitrd

Those seem to me to indicate the Debian 11 kernel is not a stock kernel. It only comes with 87 DTB files, 77 named kirkwood-*.dtb and 10 named orion-*.dtb. I could compare the kernel config files to see what machine configs they used compared to yours. But, Debian 12 with a Linux 6.x kernel has the exact same problem, which is why I suspect a Linux bug. And, why I would like to give your Linux 5.10 kernel a try.

P.S. I tried your 6.9.6-kirkwood-tld-1 kernel with the Debian 11 kirkwood-sheevaplug.dtb (see below). Linux boots fine, but the USB drive is still unusable.

Here are the steps I followed.

Fresh install of linux-6.9.6-kirkwood-tld-1-bodhi.tar.bz2

Download linux-6.9.6-kirkwood-tld-1-bodhi.tar.bz2 to ~/bodhi:

# mkdir -p ~/bodhi
# cd ~/bodhi
# wget -O linux-6.9.6-kirkwood-tld-1-bodhi.tar.bz2 https://bit.ly/3RIwpfo
# chmod -w linux-6.9.6-kirkwood-tld-1-bodhi.tar.bz2
# md5sum linux-6.9.6-kirkwood-tld-1-bodhi.tar.bz2
32396c3dec0a0786587134980291072a  linux-6.9.6-kirkwood-tld-1-bodhi.tar.bz2

Extract zImage-6.9.6-kirkwood-tld-1 to ~/bodhi/boot:

# mkdir boot
# cd boot
# tar -xjf ../linux-6.9.6-kirkwood-tld-1-bodhi.tar.bz2 zImage-6.9.6-kirkwood-tld-1

Extract dts/kirkwood-sheevaplug.dtb to ~/bodhi/boot:

# tar -O -xjf ../linux-6.9.6-kirkwood-tld-1-bodhi.tar.bz2 \
  linux-dtb-6.9.6-kirkwood-tld-1.tar | tar -xf -

Make uImage-6.9.6-kirkwood-tld-1 by appending the dtb file to the zImage:

# KERNEL=`ls zImage-* | tail -1 | sed -e "s/^zImage-//"`
# echo $KERNEL
6.9.6-kirkwood-tld-1
# IMAGE="zImage-$KERNEL"
# NAME="kernel $KERNEL"
# rm -f zImage.fdt
# cp $IMAGE zImage.fdt
# cat dts/kirkwood-sheevaplug.dtb >> zImage.fdt
# mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n "$NAME" -d zImage.fdt uImage-$KERNEL
Image Name:   kernel 6.9.6-kirkwood-tld-1
Created:      Wed Oct 16 17:44:24 2024
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:    6230456 Bytes = 6084.43 KiB = 5.94 MiB
Load Address: 00008000
Entry Point:  00008000
# rm zImage.fdt

Extract the kernel modules to ~/bodhi/lib/modules:

# cd ~/bodhi
# mkdir lib
# cd lib
# tar -xjf ../linux-6.9.6-kirkwood-tld-1-bodhi.tar.bz2 \
  linux-image-6.9.6-kirkwood-tld-1_1_armel.deb
# ar -x linux-image-6.9.6-kirkwood-tld-1_1_armel.deb data.tar.xz
# rm linux-image-6.9.6-kirkwood-tld-1_1_armel.deb
# tar -xJf data.tar.xz --wildcards --anchored --strip-components=2 ./lib/modules/*
# rm data.tar.xz

Mount the flash UBIFS rootfs:

# ubiattach /dev/ubi_ctrl -m 3
# mount -t ubifs ubi0:rootfs /mnt/ubi

Copy uImage-6.9.6-kirkwood-tld-1 to /mnt/ubi/boot and make a uImage soft link to it:

# echo $KERNEL
6.9.6-kirkwood-tld-1   <=== MAKE SURE KERNEL IS DEFINED!!!

# cd ~/bodhi
# du -sh boot/*$KERNEL* lib/modules/$KERNEL boot/dts/kirkwood-sheevaplug.dtb
6.0M	boot/uImage-6.9.6-kirkwood-tld-1
6.0M	boot/zImage-6.9.6-kirkwood-tld-1
93M	lib/modules/6.9.6-kirkwood-tld-1
12K	boot/dts/kirkwood-sheevaplug.dtb

# cp boot/uImage-$KERNEL /mnt/ubi/boot/
# ( cd /mnt/ubi/boot ; rm -f uImage ; ln -s uImage-$KERNEL uImage )

Copy the kernel modules to /mnt/ubi/usr/lib/modules/6.9.6-kirkwood-tld-1:

# rm -rf /mnt/ubi/lib/modules/$KERNEL
# ( cd lib ; tar -cf - modules/$KERNEL ) | ( cd /mnt/ubi/usr/lib ; tar -xf - )

Copy the linux-6.9.6-kirkwood-tld-1-bodhi kirkwood-sheevaplug.dtb to /mnt/ubi/boot/dtbs/6.9.6-kirkwood-tld-1:

# mkdir -p /mnt/ubi/boot/dtbs/$KERNEL
# cp boot/dts/kirkwood-sheevaplug.dtb /mnt/ubi/boot/dtbs/$KERNEL/

# ls -lh /mnt/ubi/boot
total 26M
-rw-r--r-- 1 root root 5.5M Oct 14 15:37 bodhi-uImage-5.15.5-kirkwood-tld-1
-rw-r--r-- 1 root root 5.5M Oct 14 15:01 bodhi-uImage-5.18.6-kirkwood-tld-1
drwxr-xr-x 3 root root  240 Oct 16 18:23 dtbs
lrwxrwxrwx 1 root root   27 Oct 16 18:25 uImage -> uImage-6.9.6-kirkwood-tld-1
-rw-r--r-- 1 root root 2.6M Oct 16 13:21 uImage-5.10.223-marvell-UBIFS
-rw-r--r-- 1 root root 5.9M Oct 13 02:56 uImage-6.10.11-kirkwood-UBIFS-2
-rw-r--r-- 1 root root 6.0M Oct 16 18:21 uImage-6.9.6-kirkwood-tld-1

Boot the 6.9.6-kirkwood-tld-1 kernel on the flash UBIFS rootfs:

# reboot

Marvell>> run ubi_boot

See the results in the attached fresh-install-on-bodhi-6.9.6-kirkwood-tld-1-on-UBIFS-rootfs.log file.

Try using the Debian 11 5.10.0-32-marvell sheevaplug.dtb

# cd ~/bodhi/boot
# KERNEL=`ls zImage-* | tail -1 | sed -e "s/^zImage-//"`
# echo $KERNEL
6.9.6-kirkwood-tld-1
# IMAGE="zImage-$KERNEL"
# NAME="kernel $KERNEL with Debian dtb"
# rm -f zImage.fdt
# cp $IMAGE zImage.fdt
# cat /boot/dtb-5.10.0-32-marvell >> zImage.fdt
# mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n "$NAME" -d zImage.fdt uImage-$KERNEL-with-debian-dtb
Image Name:   kernel 6.9.6-kirkwood-tld-1 with
Created:      Wed Oct 16 19:56:13 2024
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:    6230240 Bytes = 6084.22 KiB = 5.94 MiB
Load Address: 00008000
Entry Point:  00008000
# rm zImage.fdt
# ubiattach /dev/ubi_ctrl -m 3
# mount -t ubifs ubi0:rootfs /mnt/ubi
# cp uImage-$KERNEL-with-debian-dtb /mnt/ubi/boot/
# ( cd /mnt/ubi/boot ; rm -f uImage ; ln -s uImage-$KERNEL-with-debian-dtb uImage )
# ls -lh /mnt/ubi/boot
total 32M
-rw-r--r-- 1 root root 5.5M Oct 14 15:37 bodhi-uImage-5.15.5-kirkwood-tld-1
-rw-r--r-- 1 root root 5.5M Oct 14 15:01 bodhi-uImage-5.18.6-kirkwood-tld-1
drwxr-xr-x 3 root root  240 Oct 16 18:23 dtbs
lrwxrwxrwx 1 root root   43 Oct 16 19:59 uImage -> uImage-6.9.6-kirkwood-tld-1-with-debian-dtb
-rw-r--r-- 1 root root 2.6M Oct 16 13:21 uImage-5.10.223-marvell-UBIFS
-rw-r--r-- 1 root root 5.9M Oct 13 02:56 uImage-6.10.11-kirkwood-UBIFS-2
-rw-r--r-- 1 root root 6.0M Oct 16 18:21 uImage-6.9.6-kirkwood-tld-1
-rw-r--r-- 1 root root 6.0M Oct 16 19:59 uImage-6.9.6-kirkwood-tld-1-with-debian-dtb

# reboot

Marvell>> run ubi_boot

Linux boots fine, but the same thing occurs that prevents recognition of the USB drive:

[    6.380104][    T8] usb 1-1: New USB device found, idVendor=1a40, idProduct=0101, bcdDevice= 1.11
[    6.389063][    T8] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[    6.419405][    T8] usb 1-1: Product: USB 2.0 Hub
[    6.425443][    T8] hub 1-1:1.0: USB hub found
[    6.439609][    T8] hub 1-1:1.0: 4 ports detected
[    6.869401][    T8] usb 1-1.4: new high-speed USB device number 3 using orion-ehci
[    7.141226][    T8] usb 1-1.4: New USB device found, idVendor=05dc, idProduct=a81d, bcdDevice=11.00
[    7.159387][    T8] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    7.167445][    T8] usb 1-1.4: Product: USB Flash Drive
[    7.189390][    T8] usb 1-1.4: Manufacturer: Lexar
[    7.194214][    T8] usb 1-1.4: SerialNumber: AA3A00269M0I2I73
[    7.210490][    T8] usb-storage 1-1.4:1.0: USB Mass Storage device detected
[    7.223080][    T8] scsi host0: usb-storage 1-1.4:1.0

But later...

[   10.873613][    T8] usb 1-1: USB disconnect, device number 2
[   10.879454][    T8] usb 1-1.4: USB disconnect, device number 3

Hi Larry,

Quote

> This box has a different u-boot. And stock kernel is also not Sheevaplug kernel.

I don't understand how either of these matter.

In the old days, the kernel (ARM) board files do all of the devices initialization. Modern kernels use DT to initialize devices. Stock kernel is old,and might have patches on top (we cannot see what changed on top of mainline without GPL source).

Old u-boots do all of the initialization explicitlly. And each board does have patches on top of that old mainline u-boot.

In modern u-boots, the board DT is used to initialize devices. Most older u-boots (circa 2017 and earlier) do not use DT, its board files handle all device initialization.

===

Can you try these 2 sanity tests:

1. Boot into Debian and remove the Lexar drive and reinsert.

2. Plug in a different USB thumb drive.

===

I'll re-upload the kernel 5.10.7-kirkwood-tld-1 tomorrow. I did compare the DTB from this kernel, it is identical to the one you've posted (debian-11-kirkwood-sheevaplug.dtb) up a few posts above.

I also didn't see significant difference between debian-11-kirkwood-sheevaplug.dtb and the DTB from kernel 6.9.6. But possibly the kernel USB drivers had differences.

I doubt it's a kernel bug, because I did boot up my Sheevaplug a few months ago with USB rootfs (Sandisk brand).

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

bodhi,

> Stock kernel is old,and might have patches on top (we cannot see what changed on top of mainline without GPL source).

I have patched kernel sources from Debian for their linux-5.10.226 and I can make them for your releases using your patch files. But, those are different kernel versions, so I can't easily compare the source trees looking for differences.

> Old u-boots do all of the initialization explicitlly. And each board does have patches on top of that old mainline u-boot.

Understood. This is also why I went back to the OEM U-Boot, since it seems to make no difference in testing the different Debian installs, which is how I got started on this journey.

> Can you try these 2 sanity tests:
>
> 1. Boot into Debian and remove the Lexar drive and reinsert.
>
> 2. Plug in a different USB thumb drive.

Do you mean when booted from the UBIFS rootfs? I have tried different USB thumb drives with the Debian 12 installer. They all failed. Yesterday I bought a powered USB hub, in case the Nimbus cannot supply enough power. One drive I've tried says it draws 100 mA, the other says it draws 200 mA. That didn't help. As I recall, the Nimbus does not support hot-plugging the USB drive. But, I can't remember for sure. Until yesterday when I bought the USB hub, I've never been able to test hot-plugging a second USB drive because I have been running off the USB drive plugged into the Nimbus USB port.

> I'll re-upload the kernel 5.10.7-kirkwood-tld-1 tomorrow.

Thank you. I have a symposium all day tomorrow, so I likely won't try that version until Friday.

> I doubt it's a kernel bug, because I did boot up my Sheevaplug a few months ago with USB rootfs (Sandisk brand).

This problem does not exist on my SheevaPlugs, only on my Nimbus 100. That is, the Debian 12 SheevaPlug installer does find the installation USB drive on my SheevaPlug. It fails only on my Nimbus. (My two SheevaPlugs are in use, so I can't switch to use one of those.) Yet the Debian 11 SheevaPlug installer does not have this problem. Debian 12 is a Linux 6.1 kernel, Debian 11 is a Linux 5.10 kernel. There seems to be some subtle difference between a real SheevaPlug and a Nimbus pretending to be one. I hope your 5.10.7 release does not have the problem. That would help narrow down the mainline kernel release when this problem appeared.

Thank you, and good night,

Larry Baker

Here you go.

Older rootfs and kernel releases.

Scroll down to section

Quote

Updated 17 Jan 2021:

Kernel linux-5.10.7-kirkwood-tld-1 package has been uploaded

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

bodhi,

Your linux-5.10.7-kirkwood-tld-1-bodhi.tar.bz2 package works!

Attached are the minicom capture logs running my cross-compiled Debian 11 kernel, 5.10.223-marvell-UBIFS, and your 5.10.7-kirkwood-tld-1, both booted from the internal flash UBIFS rootfs on my Nimbus 100.

My Debian 11 USB rootfs is plugged into one port of a 4-port powered USB hub. I ran lsusb, removed the Debian 11 USB drive, ran lsusb, reinserted it, ran lsusb, plugged in another USB drive in a different port on the hub, and ran lsusb. In all cases I see the expected results, and the console messages correctly show the hot-plug removal and insertion of both USB drives.

What do you think we should do about this? Should I try your 5.10.7 patches on a mainline Linux 5.11 kernel, and so on, until I find the first release that has the problem?

Thank you,

Larry Baker

Larry,

> What do you think we should do about this? Should
> I try your 5.10.7 patches on a mainline Linux 5.11
> kernel, and so on, until I find the first release
> that has the problem?

Yes. We know Kernel linux-5.15.5-kirkwood-tld-1 does not work for the Nimbus USB. So it is rather quick to try 5.11.x to 5.14.x stable with my patch.

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

Larry,

Quote
bodhi
> Yes. We know Kernel linux-5.15.5-kirkwood-tld-1
> does not work for the Nimbus USB. So it is rather
> quick to try 5.11.x to 5.14.x stable with my
> patch.

It's best to go in reverse from 5.14.x back to 5.11.x. The only commit during 2021 for orion-ehci driver was in August 2021.

https://github.com/torvalds/linux/commit/4720f1bf4ee4a784d9ece05420ba33c9222a3004

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



Edited 2 time(s). Last edit at 10/18/2024 03:16PM by bodhi.

bodhi,

I'll do a methodical bisection between the 5.10.7 and the 5.10.15 kernels. I'll build my own 5.10.7 from your config that should work, and I'll build my own 5.10.15 from your config that should fail. Then I'll try the mainline 5.10.11 source with your 5.10.7 patches, and keep splitting the interval one direction or the other until I find what kernel version the problem first appears. Actually, first I better compare your 5.10.7 patches with your 5.10.15 patches to see what I might encounter in the intervening mainline kernel versions.

I'll work on that this afternoon.

Thank you,

Larry Baker

Larry,

> I'll do a methodical bisection between the 5.10.7
> and the 5.10.15 kernels.

Agreed. It would be best to do a bisect. And you meant 5.10.7 <--> 5.15.5?

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

> And you meant 5.10.7 <--> 5.15.5?

Yes.

bodhi,

I am slowly making progress on the Linux mainline kernel bisection to find when the USB drive enumeration problem began. I have to figure out what patches to apply and then configure each kernel, which takes a long time.

I am puzzled by your 5.15.5 patch for drivers/net/dsa/mv88e6xxx/chip.c:

diff -Naur --no-dereference a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
--- a/drivers/net/dsa/mv88e6xxx/chip.c	2021-11-25 00:49:08.000000000 -0800
+++ b/drivers/net/dsa/mv88e6xxx/chip.c	2021-11-28 17:36:56.279842778 -0800
@@ -3763,7 +3763,6 @@
 	.port_set_ucast_flood = mv88e6352_port_set_ucast_flood,
 	.port_set_mcast_flood = mv88e6352_port_set_mcast_flood,
 	.port_set_ether_type = mv88e6351_port_set_ether_type,
-	.port_set_jumbo_size = mv88e6165_port_set_jumbo_size,
 	.port_egress_rate_limiting = mv88e6097_port_egress_rate_limiting,
 	.port_pause_limit = mv88e6097_port_pause_limit,
 	.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
@@ -3924,6 +3923,7 @@
 	.vtu_getnext = mv88e6352_g1_vtu_getnext,
 	.vtu_loadpurge = mv88e6352_g1_vtu_loadpurge,
 	.phylink_validate = mv88e6185_phylink_validate,
+	.set_max_frame_size = mv88e6185_g1_set_max_frame_size,
 };

I found that hunk #1 in the patch applies to

static const struct mv88e6xxx_ops mv88e6141_ops = {
        /* MV88E6XXX_FAMILY_6341 */

while hunk #2 applies to

static const struct mv88e6xxx_ops mv88e6171_ops = {
        /* MV88E6XXX_FAMILY_6351 */

I assume you intended to patch only one of the "ops" tables.

Is this a bug? If so, which "ops" table did you intend to modify?

Thank you,

Larry Baker

Larry,

> I am puzzled by your 5.15.5 patch for
> drivers/net/dsa/mv88e6xxx/chip.c:

> I assume you intended to patch only one of the "ops" tables.
> Is this a bug? If so, which "ops" table did you
> intend to modify?

IIRC, it actually was both ops tables. Each has a separated mod.

===

A further thought.

You probably don't need to apply my patch at all to do bisect (my patch does not touch the USB or block device code, except for SATA LEDs). I think just using my config for 5.10.7 is enough to go forward or backward from 5.15.5.

The Sheevaplug is in mainline for quite a while, so the kirkwood-sheevaplug.dts and the ./dts/Makefile in the mainline already provides the DTB when you build a mainline kernel version.

If you have problem with a specific version from 5.10.7+ to 5.15.5, please let me know and I post the config.

===

It seems there were many significant changes in the drivers/scsi during 2021.

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



Edited 1 time(s). Last edit at 10/20/2024 08:44PM by bodhi.

bodhi,

> IIRC, it actually was both ops tables. Each has a separated mod.

Good to know.

> You probably don't need to apply my patch at all to do bisect

Updating the patch is relatively easy. Getting the config file straightened out as kernel options came and went takes more time.

I have tested Linux 5.12.19. It does not have the USB drive problem. I am working on 5.13.19 now.

Thank you,

Larry Baker

bodhi,

The failure first appears for Linux version 5.15.

I don't know how much help that is to know the precise cause. I suppose now it is time to learn how to use git bisect. That will require finding out what the commit IDs are for Linux versions 5.14.21 and 5.15. I think that should be straightforward.

For another day. It is 2:00 am here. :)

Good night,

Larry Baker

Larry,

> I don't know how much help that is to know the
> precise cause.

I think it might help a lot if it turns out to be something like a minor coding error. If it is a result of some design change (e.g. driver sense) in usb/scsi area then it's harder to fix.

> I suppose now it is time to learn
> how to use git bisect. That will require
> finding out what the commit IDs are for Linux
> versions 5.14.21 and 5.15. I think that should be
> straightforward.

Yes. And git bisect is quite easy to use when you deal with mainline source only. Don't know how cumbersome it is when we do bisect carrying a patch.

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

bodhi,

I am going to test the v5.15-rc1 candidate next to find out whether the USB drive enumeration problem was in the very first v5.15 "release". That will help narrow where to set the git bisect good and bad versions. v5.15-rc1 should compile and run properly. I'll apply all your patches to v5.15-rc1. When I start using git bisect, I might not do that until git bisect finds the commit ID that caused the problem, to save time.

I'll keep you posted.

Larry Baker

bodhi,

The v5.15-rc1 candidate fails to find the USB drive. That is the same behavior as your v5.15.5 kernel. But, your v5.18.6 (and later) finds the drive, enumerates the partitions, then immediately disconnects the USB bus (including the powered USB hub I bought) like I showed you in these message in a previous post:

[    6.380104][    T8] usb 1-1: New USB device found, idVendor=1a40, idProduct=0101, bcdDevice= 1.11
[    6.389063][    T8] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[    6.419405][    T8] usb 1-1: Product: USB 2.0 Hub
[    6.425443][    T8] hub 1-1:1.0: USB hub found
[    6.439609][    T8] hub 1-1:1.0: 4 ports detected
[    6.869401][    T8] usb 1-1.4: new high-speed USB device number 3 using orion-ehci
[    7.141226][    T8] usb 1-1.4: New USB device found, idVendor=05dc, idProduct=a81d, bcdDevice=11.00
[    7.159387][    T8] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    7.167445][    T8] usb 1-1.4: Product: USB Flash Drive
[    7.189390][    T8] usb 1-1.4: Manufacturer: Lexar
[    7.194214][    T8] usb 1-1.4: SerialNumber: AA3A00269M0I2I73
[    7.210490][    T8] usb-storage 1-1.4:1.0: USB Mass Storage device detected
[    7.223080][    T8] scsi host0: usb-storage 1-1.4:1.0

[   10.873613][    T8] usb 1-1: USB disconnect, device number 2
[   10.879454][    T8] usb 1-1.4: USB disconnect, device number 3

I think I've been wasting my time trying to fix a bug at the beginning of the v5.15.x kernels, which is only the start of the USB problems. I would be better off finding out why the disconnect is occurring in the v6.10.x and later kernels. That is the show stopper in the more recent kernels.

Your most recent release was v6.10.11. Even though it did not include UBIFS support, I rebuilt it with UBIFS support enabled. I have also built a small rootfs using debootstrap that fits nicely in the ~500 MB onboard rootfs flash partition. Tonight I installed that small rootfs on a USB stick along with my version of your v6.10.11 kernel with UBIFS support. It boots fine from the USB stick and runs on my real SheevaPlug. However, on my Nimbus, the same USB stick boots and the rootfs is mounted, but the USB disconnects immediately occur and systemd panics while bringing up the system because the rootfs is gone.

I think I'll try to find the location in the kernel where the USB disconnect messages originate and print out a traceback to find out where the USB disconnect request originates. Hopefully I will find some condition that I can alter in the code, or maybe alter a setting in the dtb file.

Thank you,

Larry Baker