|
Re: Please add built-in kernel UBIFS support for Kirkwood and any other boards with on-board eMMC flash October 24, 2024 06:07PM |
Admin Registered: 14 years ago Posts: 19,916 |
Larry,
Please try these 3 different flavors of the Sheevaplug DTB.
1. The original DTB
2. kirkwood-sheevaplug_no_regulator.dtb
3. kirkwood-sheevaplug_active_low.dtb
Run each it with kernel 5.10.7 and kernel 6.10.11.
And do not run init_ionics mode bootup before boot.
And then post the complete serial boot log for each test (until the USB is disconnected or remains connected at lsusb command).
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Edited 1 time(s). Last edit at 10/24/2024 07:09PM by bodhi.
Please try these 3 different flavors of the Sheevaplug DTB.
1. The original DTB
2. kirkwood-sheevaplug_no_regulator.dtb
3. kirkwood-sheevaplug_active_low.dtb
Run each it with kernel 5.10.7 and kernel 6.10.11.
And do not run init_ionics mode bootup before boot.
And then post the complete serial boot log for each test (until the USB is disconnected or remains connected at lsusb command).
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Edited 1 time(s). Last edit at 10/24/2024 07:09PM by bodhi.
|
Re: Please add built-in kernel UBIFS support for Kirkwood and any other boards with on-board eMMC flash October 24, 2024 10:26PM |
Registered: 1 year ago Posts: 61 |
bodhi,
You have cracked the code! You are amazing.
> Please try these 3 different flavors of the Sheevaplug DTB.
>
> 1. The original DTB
> 2. kirkwood-sheevaplug_no_regulator.dtb
> 3. kirkwood-sheevaplug_active_low.dtb
>
> Run each it with kernel 5.10.7 and kernel 6.10.11.
>
> And do not run init_ionics mode bootup before boot.
See below.
> And then post the complete serial boot log for each test (until the
> USB is disconnected or remains connected at lsusb command).
I did not receive an email notification of this edit, so I didn't know about it. The response below does not include all those log files. After you read the results, let me know what I should re-run and capture for you.
> And do not run init_ionics mode bootup before boot.
The Nimbus U-Boot ubi_boot environment variable issues an init_ionics mode bootup command before anyting else:
5.10.7-kirkwood-tld-1
1. [UBIFS] /boot/uImage -> uImage-5.10.7-kirkwood-tld-1
6.10.11-kirkwood-UBIFS-2
(My modifications to your 6.10.11-kirkwood-tld-1 to add UBIFS support and compress modules)
1. [UBIFS] /boot/uImage -> uImage-6.10.11-kirkwood-UBIFS-2
This time we boot the UBIFS kernel using run ubi_boot, that is, we do run init_ionics mode bootup before boot.
The init_ionics mode bootup command causes no harm.
3. [UBIFS] /boot/uImage -> uImage-6.10.11-kirkwood-UBIFS-2-active_low
And, finally, we boot the USB drive using the 6.10.11-kirkwood-UBIFS-2-active_low kernel. (I could try your stock 6.10.11-kirkwood-tld-1 kernel with the kirkwood-sheevaplug_active_low.dtb, but I think there's little more to learn about the success you've made.)
3. [UBIFS] /boot/uImage -> uImage-6.10.11-kirkwood-UBIFS-2-active_low with [USB ext2] /boot/uInitrd
Let me know how you want to wrap this up. I am heppy to help you test your upcoming 6.11.x kernel, if you like.
Thank you so much,
Larry Baker
You have cracked the code! You are amazing.
> Please try these 3 different flavors of the Sheevaplug DTB.
>
> 1. The original DTB
> 2. kirkwood-sheevaplug_no_regulator.dtb
> 3. kirkwood-sheevaplug_active_low.dtb
>
> Run each it with kernel 5.10.7 and kernel 6.10.11.
>
> And do not run init_ionics mode bootup before boot.
See below.
> And then post the complete serial boot log for each test (until the
> USB is disconnected or remains connected at lsusb command).
I did not receive an email notification of this edit, so I didn't know about it. The response below does not include all those log files. After you read the results, let me know what I should re-run and capture for you.
> And do not run init_ionics mode bootup before boot.
The Nimbus U-Boot ubi_boot environment variable issues an init_ionics mode bootup command before anyting else:
Marvell>> printenv ubi_boot ubi_boot=init_ionics mode bootup; run bootcmd_ubi; run set_ubi_bootargs; bootm 0x00800000For these trials, instead of entering run ubi_boot, I entered:
Marvell>> run bootcmd_ubi; run set_ubi_bootargs; bootm 0x00800000> Run each it with kernel 5.10.7 and kernel 6.10.11.
5.10.7-kirkwood-tld-1
1. [UBIFS] /boot/uImage -> uImage-5.10.7-kirkwood-tld-1
Marvell>> >>> Remove USB drive <<< Marvell>> reset resetting ... Marvell>> run bootcmd_ubi; run set_ubi_bootargs; bootm 0x00800000 ## Booting kernel from Legacy Image at 00800000 ... Image Name: kernel 5.10.7-kirkwood-tld-1 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 5326624 Bytes = 5.1 MiB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK Loading Kernel Image ... OK root@comlogger:~# lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >>> Insert USB drive <<< [ 201.512905][ T133] usb 1-1: new high-speed USB device number 2 using orion-ehci [ 201.718308][ T133] usb 1-1: New USB device found, idVendor=05dc, idProduct=a701, bcdDevice=11.00 [ 201.727271][ T133] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 201.736674][ T133] usb 1-1: Product: JD FIREFLY [ 201.741328][ T133] usb 1-1: Manufacturer: LEXAR [ 201.747374][ T133] usb 1-1: SerialNumber: 1069A704000328051007 [ 201.764452][ T133] usb-storage 1-1:1.0: USB Mass Storage device detected [ 201.783472][ T133] scsi host0: usb-storage 1-1:1.0 [ 201.833544][ T288] usbcore: registered new interface driver uas [ 202.804662][ T7] scsi 0:0:0:0: Direct-Access LEXAR JD FIREFLY 1100 PQ: 0 ANSI: 0 CCS [ 202.827747][ T57] sd 0:0:0:0: [sda] 7864320 512-byte logical blocks: (4.03 GB/3.75 GiB) [ 202.843860][ T57] sd 0:0:0:0: [sda] Write Protect is off [ 202.861354][ T57] sd 0:0:0:0: [sda] No Caching mode page found [ 202.870186][ T288] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 202.876402][ T57] sd 0:0:0:0: [sda] Assuming drive cache: write through [ 202.924602][ T57] sda: sda1 [ 202.936996][ T57] sd 0:0:0:0: [sda] Attached SCSI removable disk root@comlogger:~# lsusb Bus 001 Device 002: ID 05dc:a701 Lexar Media, Inc. JumpDrive FireFly Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub2. [UBIFS] /boot/uImage -> uImage-5.10.7-kirkwood-no_regulator
Marvell>> >>> Remove USB drive <<< Marvell>> reset resetting ... Marvell>> run bootcmd_ubi; run set_ubi_bootargs; bootm 0x00800000 ## Booting kernel from Legacy Image at 00800000 ... Image Name: kernel 5.10.7-kirkwood-no_regula Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 5326327 Bytes = 5.1 MiB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK Loading Kernel Image ... OK root@comlogger:~# lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >>> Insert USB drive <<< [ 180.513738][ T5] usb 1-1: new high-speed USB device number 2 using orion-ehci [ 180.719262][ T5] usb 1-1: New USB device found, idVendor=05dc, idProduct=a701, bcdDevice=11.00 [ 180.728251][ T5] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 180.737661][ T5] usb 1-1: Product: JD FIREFLY [ 180.742367][ T5] usb 1-1: Manufacturer: LEXAR [ 180.749022][ T5] usb 1-1: SerialNumber: 1069A704000328051007 [ 180.764805][ T5] usb-storage 1-1:1.0: USB Mass Storage device detected [ 180.783354][ T5] scsi host0: usb-storage 1-1:1.0 [ 180.836403][ T284] usbcore: registered new interface driver uas [ 181.845610][ T7] scsi 0:0:0:0: Direct-Access LEXAR JD FIREFLY 1100 PQ: 0 ANSI: 0 CCS [ 181.868322][ T183] sd 0:0:0:0: [sda] 7864320 512-byte logical blocks: (4.03 GB/3.75 GiB) [ 181.883186][ T183] sd 0:0:0:0: [sda] Write Protect is off [ 181.901576][ T183] sd 0:0:0:0: [sda] No Caching mode page found [ 181.914162][ T284] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 181.920282][ T183] sd 0:0:0:0: [sda] Assuming drive cache: write through [ 181.966449][ T183] sda: sda1 [ 181.976081][ T183] sd 0:0:0:0: [sda] Attached SCSI removable disk root@comlogger:~# lsusb Bus 001 Device 002: ID 05dc:a701 Lexar Media, Inc. JumpDrive FireFly Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub3. [UBIFS] /boot/uImage -> uImage-5.10.7-kirkwood-active_low
Marvell>> >>> Remove USB drive <<< Marvell>> reset resetting ... Marvell>> run bootcmd_ubi; run set_ubi_bootargs; bootm 0x00800000 ## Booting kernel from Legacy Image at 00800000 ... Image Name: kernel 5.10.7-kirkwood-active_lo Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 5326817 Bytes = 5.1 MiB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK Loading Kernel Image ... OK root@comlogger:~# lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >>> Insert USB drive <<< [ 229.862063][ T16] usb 1-1: new high-speed USB device number 2 using orion-ehci [ 230.067532][ T16] usb 1-1: New USB device found, idVendor=05dc, idProduct=a701, bcdDevice=11.00 [ 230.076497][ T16] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 230.085911][ T16] usb 1-1: Product: JD FIREFLY [ 230.090562][ T16] usb 1-1: Manufacturer: LEXAR [ 230.096623][ T16] usb 1-1: SerialNumber: 1069A704000328051007 [ 230.113560][ T16] usb-storage 1-1:1.0: USB Mass Storage device detected [ 230.132217][ T16] scsi host0: usb-storage 1-1:1.0 [ 230.184130][ T285] usbcore: registered new interface driver uas [ 231.203883][ T7] scsi 0:0:0:0: Direct-Access LEXAR JD FIREFLY 1100 PQ: 0 ANSI: 0 CCS [ 231.226594][ T265] sd 0:0:0:0: [sda] 7864320 512-byte logical blocks: (4.03 GB/3.75 GiB) [ 231.242956][ T265] sd 0:0:0:0: [sda] Write Protect is off [ 231.258021][ T265] sd 0:0:0:0: [sda] No Caching mode page found [ 231.271626][ T285] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 231.277869][ T265] sd 0:0:0:0: [sda] Assuming drive cache: write through [ 231.324196][ T265] sda: sda1 [ 231.336219][ T265] sd 0:0:0:0: [sda] Attached SCSI removable disk root@comlogger:~# lsusb Bus 001 Device 002: ID 05dc:a701 Lexar Media, Inc. JumpDrive FireFly Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub> Run each it with kernel 5.10.7 and kernel 6.10.11.
6.10.11-kirkwood-UBIFS-2
(My modifications to your 6.10.11-kirkwood-tld-1 to add UBIFS support and compress modules)
1. [UBIFS] /boot/uImage -> uImage-6.10.11-kirkwood-UBIFS-2
Marvell>> >>> Remove USB drive <<< Marvell>> reset resetting ... Marvell>> run bootcmd_ubi; run set_ubi_bootargs; bootm 0x00800000 ## 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 root@comlogger:~# lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >>> Insert USB drive <<< ... nothing root@comlogger:~# lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub2. [UBIFS] /boot/uImage -> uImage-6.10.11-kirkwood-UBIFS-2-no_regulator
Marvell>> >>> Remove USB drive <<< Marvell>> reset resetting ... Marvell>> run bootcmd_ubi; run set_ubi_bootargs; bootm 0x00800000 ## Booting kernel from Legacy Image at 00800000 ... Image Name: kernel 6.10.11-kirkwood-no_regul Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 6125615 Bytes = 5.8 MiB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK Loading Kernel Image ... OK root@comlogger:~# lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >>> Insert USB drive <<< [ 86.039266][ T10] usb 1-1: new high-speed USB device number 2 using orion-ehci [ 86.244679][ T10] usb 1-1: New USB device found, idVendor=05dc, idProduct=a701, bcdDevice=11.00 [ 86.253664][ T10] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 86.263259][ T10] usb 1-1: Product: JD FIREFLY [ 86.267918][ T10] usb 1-1: Manufacturer: LEXAR [ 86.272623][ T10] usb 1-1: SerialNumber: 1069A704000328051007 [ 86.289630][ T10] usb-storage 1-1:1.0: USB Mass Storage device detected [ 86.312673][ T10] scsi host0: usb-storage 1-1:1.0 [ 86.381441][ T309] usbcore: registered new interface driver uas [ 87.361016][ T21] scsi 0:0:0:0: Direct-Access LEXAR JD FIREFLY 1100 PQ: 0 ANSI: 0 CCS [ 87.401486][ T39] sd 0:0:0:0: [sda] 7864320 512-byte logical blocks: (4.03 GB/3.75 GiB) [ 87.415990][ T39] sd 0:0:0:0: [sda] Write Protect is off [ 87.429163][ T39] sd 0:0:0:0: [sda] No Caching mode page found [ 87.435226][ T39] sd 0:0:0:0: [sda] Assuming drive cache: write through [ 87.442896][ T309] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 87.471302][ T39] sda: sda1 [ 87.477379][ T39] sd 0:0:0:0: [sda] Attached SCSI removable disk root@comlogger:~# lsusb Bus 001 Device 002: ID 05dc:a701 Lexar Media, Inc. JumpDrive FireFly Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub3. [UBIFS] /boot/uImage -> uImage-6.10.11-kirkwood-UBIFS-2-active_low
Marvell>> >>> Remove USB drive <<< Marvell>> reset resetting ... Marvell>> run bootcmd_ubi; run set_ubi_bootargs; bootm 0x00800000 ## Booting kernel from Legacy Image at 00800000 ... Image Name: kernel 6.10.11-kirkwood-active_l Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 6126105 Bytes = 5.8 MiB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK Loading Kernel Image ... OK root@comlogger:~# lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >>> Insert USB drive <<< [ 76.994539][ T8] usb 1-1: new high-speed USB device number 2 using orion-ehci [ 77.199953][ T8] usb 1-1: New USB device found, idVendor=05dc, idProduct=a701, bcdDevice=11.00 [ 77.208935][ T8] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 77.218621][ T8] usb 1-1: Product: JD FIREFLY [ 77.223285][ T8] usb 1-1: Manufacturer: LEXAR [ 77.227989][ T8] usb 1-1: SerialNumber: 1069A704000328051007 [ 77.244908][ T8] usb-storage 1-1:1.0: USB Mass Storage device detected [ 77.267988][ T8] scsi host0: usb-storage 1-1:1.0 [ 77.338340][ T310] usbcore: registered new interface driver uas [ 78.326416][ T39] scsi 0:0:0:0: Direct-Access LEXAR JD FIREFLY 1100 PQ: 0 ANSI: 0 CCS [ 78.366768][ T21] sd 0:0:0:0: [sda] 7864320 512-byte logical blocks: (4.03 GB/3.75 GiB) [ 78.379895][ T21] sd 0:0:0:0: [sda] Write Protect is off [ 78.394134][ T21] sd 0:0:0:0: [sda] No Caching mode page found [ 78.400310][ T310] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 78.406454][ T21] sd 0:0:0:0: [sda] Assuming drive cache: write through [ 78.436829][ T21] sda: sda1 [ 78.443050][ T21] sd 0:0:0:0: [sda] Attached SCSI removable disk root@comlogger:~# lsusb Bus 001 Device 002: ID 05dc:a701 Lexar Media, Inc. JumpDrive FireFly Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub> And do not run init_ionics mode bootup before boot.
This time we boot the UBIFS kernel using run ubi_boot, that is, we do run init_ionics mode bootup before boot.
The init_ionics mode bootup command causes no harm.
3. [UBIFS] /boot/uImage -> uImage-6.10.11-kirkwood-UBIFS-2-active_low
Marvell>> >>> Remove USB drive <<< Marvell>> reset resetting ... Marvell>> run ubi_boot ## Booting kernel from Legacy Image at 00800000 ... Image Name: kernel 6.10.11-kirkwood-active_l Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 6126105 Bytes = 5.8 MiB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK Loading Kernel Image ... OK root@comlogger:~# lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >>> Insert USB drive <<< [ 88.724206][ T54] usb 1-1: new high-speed USB device number 2 using orion-ehci [ 88.929682][ T54] usb 1-1: New USB device found, idVendor=05dc, idProduct=a701, bcdDevice=11.00 [ 88.938663][ T54] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 88.948412][ T54] usb 1-1: Product: JD FIREFLY [ 88.953073][ T54] usb 1-1: Manufacturer: LEXAR [ 88.957778][ T54] usb 1-1: SerialNumber: 1069A704000328051007 [ 88.984583][ T54] usb-storage 1-1:1.0: USB Mass Storage device detected [ 88.994295][ T54] scsi host0: usb-storage 1-1:1.0 [ 89.067064][ T309] usbcore: registered new interface driver uas [ 90.006019][ T39] scsi 0:0:0:0: Direct-Access LEXAR JD FIREFLY 1100 PQ: 0 ANSI: 0 CCS [ 90.047745][ T21] sd 0:0:0:0: [sda] 7864320 512-byte logical blocks: (4.03 GB/3.75 GiB) [ 90.059735][ T21] sd 0:0:0:0: [sda] Write Protect is off [ 90.073587][ T309] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 90.082011][ T21] sd 0:0:0:0: [sda] No Caching mode page found [ 90.094337][ T21] sd 0:0:0:0: [sda] Assuming drive cache: write through [ 90.116192][ T21] sda: sda1 [ 90.122331][ T21] sd 0:0:0:0: [sda] Attached SCSI removable disk root@comlogger:~# lsusb Bus 001 Device 002: ID 05dc:a701 Lexar Media, Inc. JumpDrive FireFly Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub> Run each it with kernel 5.10.7 and kernel 6.10.11.
And, finally, we boot the USB drive using the 6.10.11-kirkwood-UBIFS-2-active_low kernel. (I could try your stock 6.10.11-kirkwood-tld-1 kernel with the kirkwood-sheevaplug_active_low.dtb, but I think there's little more to learn about the success you've made.)
3. [UBIFS] /boot/uImage -> uImage-6.10.11-kirkwood-UBIFS-2-active_low with [USB ext2] /boot/uInitrd
Marvell>> Marvell>> reset resetting ... Marvell>> printenv bootargs_console bootargs_console=console=ttyS0,115200 cmdlinepart.mtdparts=orion_nand:1m@0m(u-boot),4m@1m(kernel),5m@5m(pluginfo),-(rootfs) Marvell>> setenv bootargs $(bootargs_console) rootfstype=ext2 root=/dev/sda1 rw Marvell>> ubi part rootfs; ubifsmount rootfs; ubifsload 0x00800000 /boot/uImage Marvell>> usb start; ext2load usb 0:1 0x01100000 /boot/uInitrd Marvell>> bootm 0x00800000 0x01100000 ## Booting kernel from Legacy Image at 00800000 ... Image Name: kernel 6.10.11-kirkwood-active_l Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 6126105 Bytes = 5.8 MiB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 01100000 ... Image Name: ramdisk 5.10.0-32-marvell Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size: 16599803 Bytes = 15.8 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Loading Kernel Image ... OK root@comlogger:~# lsusb Bus 001 Device 002: ID 05dc:a701 Lexar Media, Inc. JumpDrive FireFly Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub root@comlogger:~# df -h Filesystem Size Used Avail Use% Mounted on /dev/root 3.7G 2.9G 667M 82% / devtmpfs 243M 0 243M 0% /dev tmpfs 244M 0 244M 0% /dev/shm tmpfs 98M 320K 98M 1% /run tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 49M 0 49M 0% /run/user/0I am VERY pleased!
Let me know how you want to wrap this up. I am heppy to help you test your upcoming 6.11.x kernel, if you like.
Thank you so much,
Larry Baker
|
Re: Please add built-in kernel UBIFS support for Kirkwood and any other boards with on-board eMMC flash October 25, 2024 01:39PM |
Admin Registered: 14 years ago Posts: 19,916 |
Hi Larry,
Cool!
So looks like my original observation was correct! But've we got side tracked by the wrong assumption that this Nimbus 100 is a Sheevaplug clone. And now having seen the patch, it has confirmed my observation once more. The GPIO 29 bit should be set to Low.
Let me create a proper DTS source for the Nimbus 100 (currently it is patched on top of the Sheevaplug DTB), compile the DTB, and then you can try regression test it once more, and then we declare it's done!
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Cool!
So looks like my original observation was correct! But've we got side tracked by the wrong assumption that this Nimbus 100 is a Sheevaplug clone. And now having seen the patch, it has confirmed my observation once more. The GPIO 29 bit should be set to Low.
Let me create a proper DTS source for the Nimbus 100 (currently it is patched on top of the Sheevaplug DTB), compile the DTB, and then you can try regression test it once more, and then we declare it's done!
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: Please add built-in kernel UBIFS support for Kirkwood boards October 25, 2024 03:16PM |
Admin Registered: 14 years ago Posts: 19,916 |
Larry,
Please test the new kirkwood-nimbus-100.dtb with kernel 6.10.11+.
If it's all working OK, you can copy the other 2 files to your source tree at arch/arm/boot/dts/marvell/. The proper patch will be part of the next kernel release 6.11.x.
kirkwood-nimbus-100.dts
Makefile
=====
Please also rename this thread subject (1st post) to "Debian on Ionics Nimbus 100". That way it's easier for people to find.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Please test the new kirkwood-nimbus-100.dtb with kernel 6.10.11+.
If it's all working OK, you can copy the other 2 files to your source tree at arch/arm/boot/dts/marvell/. The proper patch will be part of the next kernel release 6.11.x.
kirkwood-nimbus-100.dts
Makefile
=====
Please also rename this thread subject (1st post) to "Debian on Ionics Nimbus 100". That way it's easier for people to find.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: Please add built-in kernel UBIFS support for Kirkwood boards October 25, 2024 04:58PM |
Admin Registered: 14 years ago Posts: 19,916 |
Larry,
This is a better version.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
This is a better version.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: Please add built-in kernel UBIFS support for Kirkwood boards October 25, 2024 05:05PM |
Registered: 1 year ago Posts: 61 |
|
Re: Please add built-in kernel UBIFS support for Kirkwood boards October 25, 2024 06:07PM |
Registered: 1 year ago Posts: 61 |
bodhi,
> This is a better version.
Yes, it boots.
This time I left the USB drive plugged in when I booted from the UBIFS. I noticed that the USB disconnect still occurs early in the boot. But, later in the boot, the USB drive is re-enumerated and appears in lsusb when I login. So does a generic SCSI device, /dev/sg0:
When I boot the "nimbus-100" kernel with the Debian 11 USB rootfs there is no /dev/sg0 device:
Perhaps the creation of /dev/sg0 is a difference between the Debian 11 USB rootfs and the Debian 12 UBIFS rootfs. Or, maybe the creation of /dev/sg0 only occurs when devices are enumerated after the rootfs is mounted?
I'll have a look later at what happens booting the UBIFS roots with and without the USB rootfs with your 5.10.7 kernel and the "nimbus-100" DTB file.
I have to leave now.
Thanks again.
Larry Baker
> This is a better version.
Yes, it boots.
This time I left the USB drive plugged in when I booted from the UBIFS. I noticed that the USB disconnect still occurs early in the boot. But, later in the boot, the USB drive is re-enumerated and appears in lsusb when I login. So does a generic SCSI device, /dev/sg0:
Marvell>> run ubi_boot
## Booting kernel from Legacy Image at 00800000 ...
Image Name: kernel 6.10.11-kirkwood-nimbus-1
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 6126089 Bytes = 5.8 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-UBIFS-2 (baker@aqms.wr.usgs.gov) (arm-none-eabi-gcc (Arm GNU Toolchain 11.3.R4
[ 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: Ionics Nimbus 100
[ 0.000000][ T0] Memory policy: Data cache writeback
[ 0.000000][ T0] Zone ranges:
[ 0.000000][ T0] Normal [mem 0x0000000000000000-0x000000001fffffff]
[ 0.000000][ T0] Movable zone start for each node
[ 0.000000][ T0] Early memory node ranges
[ 0.000000][ T0] node 0: [mem 0x0000000000000000-0x000000001fffffff]
[ 0.000000][ T0] Initmem setup node 0 [mem 0x0000000000000000-0x000000001fffffff]
[ 0.000000][ T0] Kernel command line: console=ttyS0,115200 cmdlinepart.mtdparts=orion_nand:1m@0m(u-boot),4m@1m(kernel),5m@5m("
[ 0.000000][ T0] Unknown kernel command line parameters "ftrace_filter=usb_disconnect", will be passed to user space.
[ 0.000000][ T0] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes, linear)
[ 0.000000][ T0] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes, linear)
[ 0.000000][ T0] Built 1 zonelists, mobility grouping on. Total pages: 131072
[ 0.000000][ T0] mem auto-init: stack:off, heap alloc:on, heap free:off
[ 0.000000][ T0] Memory: 497544K/524288K available (12288K kernel code, 1713K rwdata, 5192K rodata, 1024K init, 348K bss, 267)
[ 0.000000][ T0] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[ 0.000000][ T0] trace event string verifier disabled
[ 0.000000][ T0] rcu: Preemptible hierarchical RCU implementation.
[ 0.000000][ T0] Trampoline variant of Tasks RCU enabled.
[ 0.000000][ T0] Tracing variant of Tasks RCU enabled.
[ 0.000000][ T0] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
[ 0.000000][ T0] RCU Tasks: Setting shift to 0 and lim to 1 rcu_task_cb_adjust=1.
[ 0.000000][ T0] RCU Tasks Trace: Setting shift to 0 and lim to 1 rcu_task_cb_adjust=1.
[ 0.000000][ T0] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[ 0.000000][ T0] rcu: srcu_init: Setting srcu_struct sizes based on contention.
[ 0.000000][ T0] clocksource: orion_clocksource: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 9556302233 ns
[ 0.000001][ T0] sched_clock: 32 bits at 200MHz, resolution 5ns, wraps every 10737418237ns
[ 0.000074][ T0] Switching to timer-based delay loop, resolution 5ns
[ 0.000773][ T0] Console: colour dummy device 80x30
[ 0.000829][ T0] Calibrating delay loop (skipped), value calculated using timer frequency.. 400.00 BogoMIPS (lpj=2000000)
[ 0.000852][ T0] CPU: Testing write buffer coherency: ok
[ 0.000949][ T0] pid_max: default: 32768 minimum: 301
[ 0.008947][ T0] LSM: initializing lsm=capability
[ 0.010445][ T0] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[ 0.010471][ T0] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[ 0.021511][ T1] Setting up static identity map for 0x100000 - 0x100058
[ 0.021771][ T1] mvebu-soc-id: MVEBU SoC ID=0x6281, Rev=0x2
[ 0.022031][ T1] rcu: Hierarchical SRCU implementation.
[ 0.022042][ T1] rcu: Max phase no-delay instances is 1000.
[ 0.024210][ T1] devtmpfs: initialized
[ 0.030163][ T1] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[ 0.030199][ T1] futex hash table entries: 256 (order: -1, 3072 bytes, linear)
[ 0.037128][ T1] prandom: seed boundary self test passed
[ 0.041451][ T1] prandom: 100 self tests passed
[ 0.041466][ T1] pinctrl core: initialized pinctrl subsystem
[ 0.044897][ T1] NET: Registered PF_NETLINK/PF_ROUTE protocol family
[ 0.045821][ T1] DMA: preallocated 256 KiB pool for atomic coherent allocations
[ 0.046760][ T1] audit: initializing netlink subsys (disabled)
[ 0.047672][ T22] audit: type=2000 audit(0.040:1): state=initialized audit_enabled=0 res=1
[ 0.048821][ T1] thermal_sys: Registered thermal governor 'step_wise'
[ 0.048907][ T1] cpuidle: using governor ladder
[ 0.048943][ T1] cpuidle: using governor menu
[ 0.049559][ T1] [Firmware Bug]: Feroceon L2: bootloader left the L2 cache on!
[ 0.049571][ T1] Feroceon L2: Cache support initialised.
[ 0.057735][ T1] No ATAGs?
[ 0.420090][ T1] raid6: int32x8 gen() 108 MB/s
[ 0.760092][ T1] raid6: int32x4 gen() 95 MB/s
[ 1.100089][ T1] raid6: int32x2 gen() 135 MB/s
[ 1.440088][ T1] raid6: int32x1 gen() 97 MB/s
[ 1.440104][ T1] raid6: using algorithm int32x2 gen() 135 MB/s
[ 1.780089][ T1] raid6: .... xor() 84 MB/s, rmw enabled
[ 1.780103][ T1] raid6: using intx1 recovery algorithm
[ 1.781823][ T1] SCSI subsystem initialized
[ 1.782591][ T1] usbcore: registered new interface driver usbfs
[ 1.782687][ T1] usbcore: registered new interface driver hub
[ 1.782754][ T1] usbcore: registered new device driver usb
[ 1.783104][ T1] pps_core: LinuxPPS API ver. 1 registered
[ 1.783115][ T1] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[ 1.783146][ T1] PTP clock support registered
[ 1.792831][ T1] vgaarb: loaded
[ 1.793736][ T1] clocksource: Switched to clocksource orion_clocksource
[ 1.815969][ T1] VFS: Disk quotas dquot_6.6.0
[ 1.816412][ T1] VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[ 1.843843][ T1] NET: Registered PF_INET protocol family
[ 1.844152][ T1] IP idents hash table entries: 8192 (order: 4, 65536 bytes, linear)
[ 1.854811][ T1] tcp_listen_portaddr_hash hash table entries: 1024 (order: 0, 4096 bytes, linear)
[ 1.855030][ T1] Table-perturb hash table entries: 65536 (order: 6, 262144 bytes, linear)
[ 1.856025][ T1] TCP established hash table entries: 4096 (order: 2, 16384 bytes, linear)
[ 1.856113][ T1] TCP bind hash table entries: 4096 (order: 3, 32768 bytes, linear)
[ 1.856607][ T1] TCP: Hash tables configured (established 4096 bind 4096)
[ 1.857276][ T1] MPTCP token hash table entries: 512 (order: 0, 6144 bytes, linear)
[ 1.857519][ T1] UDP hash table entries: 256 (order: 0, 4096 bytes, linear)
[ 1.857556][ T1] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes, linear)
[ 1.858532][ T1] NET: Registered PF_UNIX/PF_LOCAL protocol family
[ 1.860041][ T1] RPC: Registered named UNIX socket transport module.
[ 1.860057][ T1] RPC: Registered udp transport module.
[ 1.860064][ T1] RPC: Registered tcp transport module.
[ 1.860070][ T1] RPC: Registered tcp-with-tls transport module.
[ 1.860076][ T1] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 1.860096][ T1] PCI: CLS 0 bytes, default 32
[ 3.195628][ T1] Initialise system trusted keyrings
[ 3.195778][ T1] Key type blacklist registered
[ 3.196124][ T1] workingset: timestamp_bits=14 max_order=17 bucket_order=3
[ 3.196354][ T1] zbud: loaded
[ 3.214491][ T1] NFS: Registering the id_resolver key type
[ 3.214543][ T1] Key type id_resolver registered
[ 3.214554][ T1] Key type id_legacy registered
[ 3.214747][ T1] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[ 3.214769][ T1] nfs4flexfilelayout_init: NFSv4 Flexfile Layout Driver Registering...
[ 3.215946][ T1] fuse: init (API version 7.40)
[ 3.217516][ T1] SGI XFS with ACLs, security attributes, realtime, scrub, quota, no debug enabled
[ 3.497801][ T1] xor: measuring software checksum speed
[ 3.506700][ T1] arm4regs : 1112 MB/sec
[ 3.521458][ T1] 8regs : 667 MB/sec
[ 3.531868][ T1] 32regs : 947 MB/sec
[ 3.531879][ T1] xor: using function: arm4regs (1112 MB/sec)
[ 3.531895][ T1] async_tx: api initialized (async)
[ 3.531927][ T1] Key type asymmetric registered
[ 3.531937][ T1] Asymmetric key parser 'x509' registered
[ 3.540481][ T1] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 247)
[ 3.540959][ T1] io scheduler bfq registered
[ 3.729896][ T1] kirkwood-pinctrl f1010000.pin-controller: registered pinctrl driver
[ 3.731479][ T1] gpio gpiochip0: Static allocation of GPIO base is deprecated, use dynamic allocation.
[ 3.732638][ T1] gpio gpiochip1: Static allocation of GPIO base is deprecated, use dynamic allocation.
[ 3.734068][ T1] mv_xor f1060800.xor: Marvell shared XOR driver
[ 3.795155][ T1] mv_xor f1060800.xor: Marvell XOR (Registers Mode): ( xor cpy intr )
[ 3.799731][ T1] mv_xor f1060900.xor: Marvell shared XOR driver
[ 3.865145][ T1] mv_xor f1060900.xor: Marvell XOR (Registers Mode): ( xor cpy intr )
[ 3.869747][ T1] Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
[ 3.872135][ T1] printk: legacy console [ttyS0] disabled
[ 3.872832][ T1] f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 27, base_baud = 12500000) is a 16550A
[ 3.872907][ T1] printk: legacy console [ttyS0] enabled
[ 4.741900][ T1] loop: module loaded
[ 4.747197][ T1] nand: device found, Manufacturer ID: 0xec, Chip ID: 0xdc
[ 4.754346][ T1] nand: Samsung NAND 512MiB 3,3V 8-bit
[ 4.759691][ T1] nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
[ 4.768120][ T1] Scanning device for bad blocks
[ 4.946673][ T1] Bad eraseblock 2258 at 0x000011a40000
[ 5.093414][ T1] 4 cmdlinepart partitions found on MTD device orion_nand
[ 5.100434][ T1] Creating 4 MTD partitions on "orion_nand":
[ 5.106323][ T1] 0x000000000000-0x000000100000 : "u-boot"
[ 5.112781][ T1] 0x000000100000-0x000000500000 : "kernel"
[ 5.119213][ T1] 0x000000500000-0x000000a00000 : "pluginfo"
[ 5.125839][ T1] 0x000000a00000-0x000020000000 : "rootfs"
[ 5.135620][ T1] wireguard: WireGuard 1.0.0 loaded. See www.wireguard.com for information.
[ 5.144281][ T1] wireguard: Copyright (C) 2015-2019 Jason A. Donenfeld <Jason@zx2c4.com>. All Rights Reserved.
[ 5.160568][ T1] mv643xx_eth: MV-643xx 10/100/1000 ethernet driver version 1.4
[ 5.924914][ T1] mv643xx_eth_port mv643xx_eth_port.0 eth0: port 0 with MAC address 00:26:db:00:00:00
[ 5.935027][ T1] orion-ehci f1050000.ehci: EHCI Host Controller
[ 5.941318][ T1] orion-ehci f1050000.ehci: new USB bus registered, assigned bus number 1
[ 5.950036][ T1] orion-ehci f1050000.ehci: irq 30, io mem 0xf1050000
[ 5.983759][ T1] orion-ehci f1050000.ehci: USB 2.0 started, EHCI 1.00
[ 5.990801][ T1] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.10
[ 5.999842][ T1] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 6.007831][ T1] usb usb1: Product: EHCI Host Controller
[ 6.013437][ T1] usb usb1: Manufacturer: Linux 6.10.11-kirkwood-UBIFS-2 ehci_hcd
[ 6.021154][ T1] usb usb1: SerialNumber: f1050000.ehci
[ 6.027588][ T1] hub 1-0:1.0: USB hub found
[ 6.032126][ T1] hub 1-0:1.0: 1 port detected
[ 6.037752][ T1] usbcore: registered new interface driver usb-storage
[ 6.045204][ T1] mousedev: PS/2 mouse device common for all mice
[ 6.052951][ T1] rtc-mv f1010300.rtc: registered as rtc0
[ 6.058663][ T1] rtc-mv f1010300.rtc: setting system clock to 2024-10-25T22:24:56 UTC (1729895096)
[ 6.068333][ T1] i2c_dev: i2c /dev entries driver
[ 6.074518][ T1] device-mapper: uevent: version 1.0.3
[ 6.080556][ T1] device-mapper: ioctl: 4.48.0-ioctl (2023-03-01) initialised: dm-devel@lists.linux.dev
[ 6.090928][ T1] device-mapper: multipath round-robin: version 1.2.0 loaded
[ 6.098267][ T1] device-mapper: multipath queue-length: version 0.2.0 loaded
[ 6.105655][ T1] device-mapper: multipath service-time: version 0.3.0 loaded
[ 6.113180][ T1] device-mapper: dm-log-userspace: version 1.3.0 loaded
[ 6.120862][ T1] sdhci: Secure Digital Host Controller Interface driver
[ 6.127812][ T1] sdhci: Copyright(c) Pierre Ossman
[ 6.134929][ T1] ledtrig-cpu: registered to indicate activity on CPUs
[ 6.141817][ T1] hid: raw HID events driver (C) Jiri Kosina
[ 6.148242][ T1] drop_monitor: Initializing network drop monitor service
[ 6.157051][ T1] NET: Registered PF_INET6 protocol family
[ 6.166083][ T1] Segment Routing with IPv6
[ 6.170530][ T1] RPL Segment Routing with IPv6
[ 6.175981][ T1] In-situ OAM (IOAM) with IPv6
[ 6.180786][ T1] NET: Registered PF_PACKET protocol family
[ 6.187079][ T1] Key type dns_resolver registered
[ 6.209618][ T1] registered taskstats version 1
[ 6.215509][ T1] Loading compiled-in X.509 certificates
[ 6.262023][ T1] Key type .fscrypt registered
[ 6.266772][ T1] Key type fscrypt-provisioning registered
[ 6.278561][ T1] Key type big_key registered
[ 6.293458][ T1] Key type encrypted registered
[ 6.323859][ T8] usb 1-1: new high-speed USB device number 2 using orion-ehci
[ 6.367439][ T110] "cryptomgr_test" (110) uses obsolete ecb(arc4) skcipher
[ 6.536385][ T8] usb 1-1: New USB device found, idVendor=05dc, idProduct=a701, bcdDevice=11.00
[ 6.553754][ T8] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 6.561638][ T8] usb 1-1: Product: JD FIREFLY
[ 6.573751][ T8] usb 1-1: Manufacturer: LEXAR
[ 6.578406][ T8] usb 1-1: SerialNumber: 1069A704000328051007
[ 6.605001][ T8] usb-storage 1-1:1.0: USB Mass Storage device detected
[ 6.612680][ T8] scsi host0: usb-storage 1-1:1.0
[ 7.685350][ T11] scsi 0:0:0:0: Direct-Access LEXAR JD FIREFLY 1100 PQ: 0 ANSI: 0 CCS
[ 7.699038][ T21] sd 0:0:0:0: [sda] 7864320 512-byte logical blocks: (4.03 GB/3.75 GiB)
[ 7.714417][ T21] sd 0:0:0:0: [sda] Write Protect is off
[ 7.724035][ T21] sd 0:0:0:0: [sda] No Caching mode page found
[ 7.730111][ T21] sd 0:0:0:0: [sda] Assuming drive cache: write through
[ 7.761408][ T21] sda: sda1
[ 7.765029][ T21] sd 0:0:0:0: [sda] Attached SCSI removable disk
[ 8.772777][ T1] ubi0: attaching mtd3
[ 8.777018][ T8] usb 1-1: USB disconnect, device number 2
[ 9.417980][ T1] ubi0: scanning is finished
[ 9.442340][ T1] ubi0: attached mtd3 (name "rootfs", size 502 MiB)
[ 9.448911][ T1] ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes
[ 9.456544][ T1] ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 512
[ 9.463998][ T1] ubi0: VID header offset: 512 (aligned 512), data offset: 2048
[ 9.471524][ T1] ubi0: good PEBs: 4015, bad PEBs: 1, corrupted PEBs: 0
[ 9.478369][ T1] ubi0: user volume: 1, internal volumes: 1, max. volumes count: 128
[ 9.486348][ T1] ubi0: max/mean erase counter: 38/26, WL threshold: 4096, image sequence number: 1245509428
[ 9.496427][ T1] ubi0: available PEBs: 0, total reserved PEBs: 4015, PEBs reserved for bad PEB handling: 79
[ 9.506514][ T129] ubi0: background thread "ubi_bgt0d" started, PID 129
[ 9.513520][ T1] ftrace bootup tracer 'function' not registered.
[ 9.519922][ T1] clk: Disabling unused clocks
[ 9.524931][ T1] md: Waiting for all devices to be available before autodetect
[ 9.532461][ T1] md: If you don't use raid, use raid=noautodetect
[ 9.538923][ T1] md: Autodetecting RAID arrays.
[ 9.543805][ T1] md: autorun ...
[ 9.547320][ T1] md: ... autorun DONE.
[ 9.552883][ T1] UBIFS (ubi0:0): Mounting in unauthenticated mode
[ 9.559632][ T130] UBIFS (ubi0:0): background thread "ubifs_bgt0_0" started, PID 130
[ 9.664372][ T1] UBIFS (ubi0:0): UBIFS: mounted UBI device 0, volume 0, name "rootfs"
[ 9.672533][ T1] UBIFS (ubi0:0): LEB size: 129024 bytes (126 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
[ 9.683231][ T1] UBIFS (ubi0:0): FS size: 505257984 bytes (481 MiB, 3916 LEBs), max 3932 LEBs, journal size 25288704 bytes (2)
[ 9.696284][ T1] UBIFS (ubi0:0): reserved for root: 4952683 bytes (4836 KiB)
[ 9.703633][ T1] UBIFS (ubi0:0): media format: w5/r0 (latest is w5/r0), UUID 2AA5BB18-DC40-415C-9A09-B41569946CBB, small LPT l
[ 9.716828][ T1] VFS: Mounted root (ubifs filesystem) on device 0:18.
[ 9.724166][ T1] devtmpfs: mounted
[ 9.730771][ T1] Freeing unused kernel image (initmem) memory: 1024K
[ 9.737606][ T1] Run /sbin/init as init process
[ 10.430790][ T1] systemd[1]: Inserted module 'autofs4'
[ 10.596998][ T1] systemd[1]: systemd 252.30-1~deb12u2 running in system mode (+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SEC)
[ 10.631368][ T1] systemd[1]: Detected architecture arm.
Welcome to Debian GNU/Linux 12 (bookworm)!
[ 10.678745][ T1] systemd[1]: Hostname set to <comlogger>.
[ 12.779179][ T1] systemd[1]: Queued start job for default target graphical.target.
[ 12.856078][ T1] systemd[1]: Created slice system-getty.slice - Slice /system/getty.
[ OK ] Created slice system-getty.slice - Slice /system/getty.
[ 12.897773][ T1] systemd[1]: Created slice system-modprobe.slice - Slice /system/modprobe.
[ OK ] Created slice system-modpr?…lice - Slice /system/modprobe.
[ 12.947782][ T1] systemd[1]: Created slice system-serial\x2dgetty.slice - Slice /system/serial-getty.
[ OK ] Created slice system-seria?… - Slice /system/serial-getty.
[ 12.996886][ T1] systemd[1]: Created slice user.slice - User and Session Slice.
[ OK ] Created slice user.slice - User and Session Slice.
[ 13.035629][ T1] systemd[1]: Started systemd-ask-password-console.path - Dispatch Password Requests to Console Directory Watc.
[ OK ] Started systemd-ask-passwo?…quests to Console Directory Watch.
[ 13.084640][ T1] systemd[1]: Started systemd-ask-password-wall.path - Forward Password Requests to Wall Directory Watch.
[ OK ] Started systemd-ask-passwo?… Requests to Wall Directory Watch.
[ 13.128471][ T1] systemd[1]: Set up automount proc-sys-fs-binfmt_misc.automount - Arbitrary Executable File Formats File Syst.
[ OK ] Set up automount proc-sys-?…rmats File System Automount Point.
[ 13.174277][ T1] systemd[1]: Expecting device dev-ttyS0.device - /dev/ttyS0...
Expecting device dev-ttyS0.device - /dev/ttyS0...
[ 13.215166][ T1] systemd[1]: Reached target cryptsetup.target - Local Encrypted Volumes.
[ OK ] Reached target cryptsetup.?…get - Local Encrypted Volumes.
[ 13.254428][ T1] systemd[1]: Reached target integritysetup.target - Local Integrity Protected Volumes.
[ OK ] Reached target integrityse?…Local Integrity Protected Volumes.
[ 13.294523][ T1] systemd[1]: Reached target paths.target - Path Units.
[ OK ] Reached target paths.target - Path Units.
[ 13.334280][ T1] systemd[1]: Reached target remote-fs.target - Remote File Systems.
[ OK ] Reached target remote-fs.target - Remote File Systems.
[ 13.374229][ T1] systemd[1]: Reached target slices.target - Slice Units.
[ OK ] Reached target slices.target - Slice Units.
[ 13.414418][ T1] systemd[1]: Reached target swap.target - Swaps.
[ OK ] Reached target swap.target - Swaps.
[ 13.454343][ T1] systemd[1]: Reached target veritysetup.target - Local Verity Protected Volumes.
[ OK ] Reached target veritysetup?… - Local Verity Protected Volumes.
[ 13.501487][ T1] systemd[1]: Listening on systemd-initctl.socket - initctl Compatibility Named Pipe.
[ OK ] Listening on systemd-initc?… initctl Compatibility Named Pipe.
[ 13.549303][ T1] systemd[1]: Listening on systemd-journald-audit.socket - Journal Audit Socket.
[ OK ] Listening on systemd-journ?…socket - Journal Audit Socket.
[ 13.595632][ T1] systemd[1]: Listening on systemd-journald-dev-log.socket - Journal Socket (/dev/log).
[ OK ] Listening on systemd-journ?…t - Journal Socket (/dev/log).
[ 13.635682][ T1] systemd[1]: Listening on systemd-journald.socket - Journal Socket.
[ OK ] Listening on systemd-journald.socket - Journal Socket.
[ 13.677621][ T1] systemd[1]: Listening on systemd-udevd-control.socket - udev Control Socket.
[ OK ] Listening on systemd-udevd?….socket - udev Control Socket.
[ 13.715378][ T1] systemd[1]: Listening on systemd-udevd-kernel.socket - udev Kernel Socket.
[ OK ] Listening on systemd-udevd?…l.socket - udev Kernel Socket.
[ 13.756551][ T1] systemd[1]: dev-hugepages.mount - Huge Pages File System was skipped because of an unmet condition check (Co.
[ 13.814517][ T1] systemd[1]: Mounting dev-mqueue.mount - POSIX Message Queue File System...
Mounting dev-mqueue.mount??POSIX Message Queue File System...
[ 13.851992][ T1] systemd[1]: Mounting sys-kernel-debug.mount - Kernel Debug File System...
Mounting sys-kernel-debug.?… - Kernel Debug File System...
[ 13.916076][ T1] systemd[1]: Mounting sys-kernel-tracing.mount - Kernel Trace File System...
Mounting sys-kernel-tracin?… - Kernel Trace File System...
[ 14.006098][ T1] systemd[1]: Starting kmod-static-nodes.service - Create List of Static Device Nodes...
Starting kmod-static-nodes?…ate List of Static Device Nodes...
[ 14.095139][ T1] systemd[1]: Starting modprobe@configfs.service - Load Kernel Module configfs...
Starting modprobe@configfs?…m - Load Kernel Module configfs...
[ 14.185027][ T1] systemd[1]: Starting modprobe@dm_mod.service - Load Kernel Module dm_mod...
Starting modprobe@dm_mod.s?…[0m - Load Kernel Module dm_mod...
[ 14.254067][ T1] systemd[1]: Starting modprobe@drm.service - Load Kernel Module drm...
Starting modprobe@drm.service - Load Kernel Module drm...
[ 14.283250][ T1] systemd[1]: Starting modprobe@efi_pstore.service - Load Kernel Module efi_pstore...
Starting modprobe@efi_psto?…- Load Kernel Module efi_pstore...
[ 14.365035][ T1] systemd[1]: Starting modprobe@fuse.service - Load Kernel Module fuse...
Starting modprobe@fuse.ser?…e - Load Kernel Module fuse...
[ 14.405974][ T1] systemd[1]: Starting modprobe@loop.service - Load Kernel Module loop...
Starting modprobe@loop.ser?…e - Load Kernel Module loop...
[ 14.505148][ T1] systemd[1]: Starting systemd-journald.service - Journal Service...
Starting systemd-journald.service - Journal Service...
[ 14.547610][ T1] systemd[1]: Starting systemd-modules-load.service - Load Kernel Modules...
Starting systemd-modules-l?…rvice - Load Kernel Modules...
[ 14.665097][ T1] systemd[1]: Starting systemd-remount-fs.service - Remount Root and Kernel File Systems...
Starting systemd-remount-f?…nt Root and Kernel File Systems...
[ 14.765863][ T1] systemd[1]: Starting systemd-udev-trigger.service - Coldplug All udev Devices...
Starting systemd-udev-trig?…[0m - Coldplug All udev Devices...
[ 14.893291][ T1] systemd[1]: Mounted dev-mqueue.mount - POSIX Message Queue File System.
[ OK ] Mounted dev-mqueue.mount??- POSIX Message Queue File System.
[ 14.969486][ T1] systemd[1]: Mounted sys-kernel-debug.mount - Kernel Debug File System.
[ OK ] Mounted sys-kernel-debug.m?…nt - Kernel Debug File System.
[ 15.035318][ T1] systemd[1]: Mounted sys-kernel-tracing.mount - Kernel Trace File System.
[ OK ] Mounted sys-kernel-tracing?…nt - Kernel Trace File System.
[ 15.094772][ T1] systemd[1]: Finished kmod-static-nodes.service - Create List of Static Device Nodes.
[ OK ] Finished kmod-static-nodes?…reate List of Static Device Nodes.
[ 15.184191][ T1] systemd[1]: modprobe@configfs.service: Deactivated successfully.
[ 15.214287][ T1] systemd[1]: Finished modprobe@configfs.service - Load Kernel Module configfs.
[ OK ] Finished modprobe@configfs?…[0m - Load Kernel Module configfs.
[ 15.249242][ T1] systemd[1]: modprobe@dm_mod.service: Deactivated successfully.
[ 15.295564][ T1] systemd[1]: Finished modprobe@dm_mod.service - Load Kernel Module dm_mod.
[ OK ] Finished modprobe@dm_mod.s?…e - Load Kernel Module dm_mod.
[ 15.357437][ T1] systemd[1]: modprobe@drm.service: Deactivated successfully.
[ 15.385506][ T1] systemd[1]: Finished modprobe@drm.service - Load Kernel Module drm.
[ OK ] Finished modprobe@drm.service - Load Kernel Module drm.
[ 15.447373][ T1] systemd[1]: modprobe@efi_pstore.service: Deactivated successfully.
[ 15.475557][ T1] systemd[1]: Finished modprobe@efi_pstore.service - Load Kernel Module efi_pstore.
[ OK ] Finished modprobe@efi_psto?…m - Load Kernel Module efi_pstore.
[ 15.536326][ T1] systemd[1]: Started systemd-journald.service - Journal Service.
[ OK ] Started systemd-journald.service - Journal Service.
[ OK ] Finished modprobe@fuse.service - Load Kernel Module fuse.
[ OK ] Finished modprobe@loop.service - Load Kernel Module loop.
[ OK ] Finished systemd-modules-l?…service - Load Kernel Modules.
[ OK ] Finished systemd-remount-f?…ount Root and Kernel File Systems.
Mounting sys-fs-fuse-conne?… - FUSE Control File System...
Mounting sys-kernel-config?…ernel Configuration File System...
Starting systemd-journal-f?…h Journal to Persistent Storage...
Starting systemd-random-se?…ice - Load/Save Random Seed...
Starting systemd-sysctl.se?…ce - Apply Kernel Variables...
Starting systemd-sysusers.?…rvice - Create System Users...
[ OK ] Mounted sys-fs-fuse-connec?…nt - FUSE Control File System.
[ OK ] Finished systemd-udev-trig?…e - Coldplug All udev Devices.
[ OK ] Mounted 16.378137][ T156] systemd-journald[156]: Received client request to flush runtime journal.
1;39msys-kernel-config.?… Kernel Configuration File System.
Starting ifupdown-pre.serv?…ynchronize boot up for ifupdown...
[ OK ] Finished systemd-sysctl.service - Apply Kernel Variables.
[ OK ] Finished systemd-sysusers.service - Create System Users.
Starting systemd-tmpfiles-?…ate Static Device Nodes in /dev...
[ OK ] Finished systemd-tmpfiles-?…reate Static Device Nodes in /dev.
[ OK ] Reached target local-fs-pr?…reparation for Local File Systems.
[ OK ] Reached target local-fs.target - Local File Systems.
Starting systemd-binfmt.se?…et Up Additional Binary Formats...
Starting systemd-udevd.ser?…ger for Device Events and Files...
Mounting proc-sys-fs-binfm?…utable File Formats File System...
[ OK ] Mounted proc-sys-fs-binfmt?…ecutable File Formats File System.
[ OK ] Finished systemd-binfmt.se?… Set Up Additional Binary Formats.
[ OK ] Finished systemd-journal-f?…ush Journal to Persistent Storage.
Starting systemd-tmpfiles-?…te System Files and Directories...
[ 18.563836][ C0] random: crng init done
[ OK ] Finished systemd-random-se?…rvice - Load/Save Random Seed.
[ OK ] Started systemd-udevd.serv?…nager for Device Events and Files.
[ OK ] Finished systemd-tmpfiles-?…eate System Files and Directories.
Starting systemd-update-ut?…rd System Boot/Shutdown in UTMP...
[ OK ] Finished systemd-update-ut?…cord System Boot/Shutdown in UTMP.
[ OK ] Reached target sysinit.target - System Initialization.
[ OK ] Started apt-daily.timer - Daily apt download activities.
[ OK ] Started apt-daily-upgrade.?… apt upgrade and clean activities.
[ OK ] Started dpkg-db-backup.tim?… Daily dpkg database backup timer.
[ OK ] Started e2scrub_all.timer??etadata Check for All Filesystems.
[ OK ] Started fstrim.timer - Discard unused blocks once a week.
[ OK ] Started logrotate.timer - Daily rotation of log files.
[ OK ] Started ntpsec-rotate-stat?…mer - Rotate ntpd stats daily.
[ OK ] Started systemd-tmpfiles-c?… Cleanup of Temporary Directories.
[ OK ] Reached target timers.target - Timer Units.
[ OK ] Listening on dbus.socket??- D-Bus System Message Bus Socket.
[ OK ] Reached target sockets.target - Socket Units.
[ OK ] Reached target basic.target - Basic System.
[ OK ] Started cron.service -?…kground program processing daemon.
Starting dbus.service - D-Bus System Message Bus...
Starting e2scrub_reap.serv?…e ext4 Metadata Check Snapshots...
Starting systemd-logind.se?…ice - User Login Management...
[ OK ] Found device dev-ttyS0.device - /dev/ttyS0.
[ OK ] Started dbus.service - D-Bus System Message Bus.
[ OK ] Finished e2scrub_reap.serv?…ine ext4 Metadata Check Snapshots.
[ OK ] Started systemd-logind.service - User Login Management.
[ 21.654731][ T186] orion_wdt: Initial timeout 21 sec
[ 22.039765][ T11] regulator@1 enforce active low on GPIO handle
[ 22.483515][ T191] marvell-cesa f1030000.crypto: CESA device successfully registered
[ 22.513839][ T8] usb 1-1: new high-speed USB device number 3 using orion-ehci
Expecting device sys-subsy?…/sys/subsystem/net/devices/eth0...
[ 22.724809][ T8] usb 1-1: New USB device found, idVendor=05dc, idProduct=a701, bcdDevice=11.00
[ 22.743961][ T8] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 22.751883][ T8] usb 1-1: Product: JD FIREFLY
[ 22.784634][ T8] usb 1-1: Manufacturer: LEXAR
[ 22.789307][ T8] usb 1-1: SerialNumber: 1069A704000328051007
[ 22.806954][ T8] usb-storage 1-1:1.0: USB Mass Storage device detected
[ 22.824580][ T8] scsi host0: usb-storage 1-1:1.0
[ 22.912695][ T191] usbcore: registered new interface driver uas
[ OK ] Found device sys-subsystem?…- /sys/subsystem/net/devices/eth0.
[ OK ] Started ifup@eth0.service - ifup for eth0.
[ OK ] Finished ifupdown-pre.serv?… synchronize boot up for ifupdown.
Starting networking.service - Raise network interfaces...
[ 23.845599][ T39] scsi 0:0:0:0: Direct-Access LEXAR JD FIREFLY 1100 PQ: 0 ANSI: 0 CCS
[ 23.885827][ T21] sd 0:0:0:0: [sda] 7864320 512-byte logical blocks: (4.03 GB/3.75 GiB)
[ 23.899942][ T21] sd 0:0:0:0: [sda] Write Protect is off
[ 23.913443][ T187] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 23.920455][ T21] sd 0:0:0:0: [sda] No Caching mode page found
[ 23.928455][ T21] sd 0:0:0:0: [sda] Assuming drive cache: write through
[ 23.953022][ T21] sda: sda1
[ 23.957329][ T21] sd 0:0:0:0: [sda] Attached SCSI removable disk
[*** ] Job networking.service/start running (13s / 5min 10s)
[ OK ] Finished networking.service - Raise network interfaces.
[ OK ] Reached target network.target - Network.
Starting ntpsec.service - Network Time Service...
Starting ssh.service - OpenBSD Secure Shell server...
Starting systemd-user-sess?…vice - Permit User Sessions...
[ OK ] Finished systemd-user-sess?…ervice - Permit User Sessions.
[ OK ] Started ntpsec.service - Network Time Service.
[ OK ] Started getty@tty1.service - Getty on tty1.
[ OK ] Started serial-getty@ttyS0?…rvice - Serial Getty on ttyS0.
[ OK ] Reached target getty.target - Login Prompts.
[ OK ] Started ssh.service - OpenBSD Secure Shell server.
[ OK ] Reached target multi-user.target - Multi-User System.
[ OK ] Reached target graphical.target - Graphical Interface.
Starting systemd-update-ut?… Record Runlevel Change in UTMP...
[ OK ] Finished systemd-update-ut?… - Record Runlevel Change in UTMP.
root@comlogger:~# lsusb Bus 001 Device 003: ID 05dc:a701 Lexar Media, Inc. JumpDrive FireFly Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub root@comlogger:~# ls /dev/sg* /dev/sg0Puzzling. I would have thought the appended DTB would take effect when the kernel was loaded.
When I boot the "nimbus-100" kernel with the Debian 11 USB rootfs there is no /dev/sg0 device:
Marvell>> setenv bootargs $(bootargs_console) rootfstype=ext2 root=/dev/sda1 rw
Marvell>> ubi part rootfs; ubifsmount rootfs; ubifsload 0x00800000 /boot/uImage
Marvell>> usb start; ext2load usb 0:1 0x01100000 /boot/uInitrd
Marvell>> bootm 0x00800000 0x01100000
## Booting kernel from Legacy Image at 00800000 ...
Image Name: kernel 6.10.11-kirkwood-nimbus-1
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 6126089 Bytes = 5.8 MiB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 01100000 ...
Image Name: ramdisk 5.10.0-32-marvell
Image Type: ARM Linux RAMDisk Image (uncompressed)
Data Size: 16599803 Bytes = 15.8 MiB
Load Address: 00000000
Entry Point: 00000000
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-UBIFS-2 (baker@aqms.wr.usgs.gov) (arm-none-eabi-gcc (Arm GNU Toolchain 11.3.R4
[ 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: Ionics Nimbus 100
[ 0.000000][ T0] Memory policy: Data cache writeback
[ 0.000000][ T0] INITRD: 0x01100000+0x00fd5000 overlaps in-use memory region
[ 0.000000][ T0] - disabling initrd
[ 0.000000][ T0] Zone ranges:
[ 0.000000][ T0] Normal [mem 0x0000000000000000-0x000000001fffffff]
[ 0.000000][ T0] Movable zone start for each node
[ 0.000000][ T0] Early memory node ranges
[ 0.000000][ T0] node 0: [mem 0x0000000000000000-0x000000001fffffff]
[ 0.000000][ T0] Initmem setup node 0 [mem 0x0000000000000000-0x000000001fffffff]
[ 0.000000][ T0] Kernel command line: console=ttyS0,115200 cmdlinepart.mtdparts=orion_nand:1m@0m(u-boot),4m@1m(kernel),5m@5m(w
[ 0.000000][ T0] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes, linear)
[ 0.000000][ T0] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes, linear)
[ 0.000000][ T0] Built 1 zonelists, mobility grouping on. Total pages: 131072
[ 0.000000][ T0] mem auto-init: stack:off, heap alloc:on, heap free:off
[ 0.000000][ T0] Memory: 497544K/524288K available (12288K kernel code, 1713K rwdata, 5192K rodata, 1024K init, 348K bss, 267)
[ 0.000000][ T0] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[ 0.000000][ T0] trace event string verifier disabled
[ 0.000000][ T0] rcu: Preemptible hierarchical RCU implementation.
[ 0.000000][ T0] Trampoline variant of Tasks RCU enabled.
[ 0.000000][ T0] Tracing variant of Tasks RCU enabled.
[ 0.000000][ T0] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
[ 0.000000][ T0] RCU Tasks: Setting shift to 0 and lim to 1 rcu_task_cb_adjust=1.
[ 0.000000][ T0] RCU Tasks Trace: Setting shift to 0 and lim to 1 rcu_task_cb_adjust=1.
[ 0.000000][ T0] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[ 0.000000][ T0] rcu: srcu_init: Setting srcu_struct sizes based on contention.
[ 0.000000][ T0] clocksource: orion_clocksource: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 9556302233 ns
[ 0.000001][ T0] sched_clock: 32 bits at 200MHz, resolution 5ns, wraps every 10737418237ns
[ 0.000074][ T0] Switching to timer-based delay loop, resolution 5ns
[ 0.000801][ T0] Console: colour dummy device 80x30
[ 0.000857][ T0] Calibrating delay loop (skipped), value calculated using timer frequency.. 400.00 BogoMIPS (lpj=2000000)
[ 0.000880][ T0] CPU: Testing write buffer coherency: ok
[ 0.000977][ T0] pid_max: default: 32768 minimum: 301
[ 0.008925][ T0] LSM: initializing lsm=capability
[ 0.010461][ T0] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[ 0.010487][ T0] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[ 0.021635][ T1] Setting up static identity map for 0x100000 - 0x100058
[ 0.021894][ T1] mvebu-soc-id: MVEBU SoC ID=0x6281, Rev=0x2
[ 0.022154][ T1] rcu: Hierarchical SRCU implementation.
[ 0.022164][ T1] rcu: Max phase no-delay instances is 1000.
[ 0.024323][ T1] devtmpfs: initialized
[ 0.030006][ T1] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[ 0.030041][ T1] futex hash table entries: 256 (order: -1, 3072 bytes, linear)
[ 0.037117][ T1] prandom: seed boundary self test passed
[ 0.041440][ T1] prandom: 100 self tests passed
[ 0.041454][ T1] pinctrl core: initialized pinctrl subsystem
[ 0.045280][ T1] NET: Registered PF_NETLINK/PF_ROUTE protocol family
[ 0.046113][ T1] DMA: preallocated 256 KiB pool for atomic coherent allocations
[ 0.047085][ T1] audit: initializing netlink subsys (disabled)
[ 0.047493][ T22] audit: type=2000 audit(0.040:1): state=initialized audit_enabled=0 res=1
[ 0.048487][ T1] thermal_sys: Registered thermal governor 'step_wise'
[ 0.048574][ T1] cpuidle: using governor ladder
[ 0.048610][ T1] cpuidle: using governor menu
[ 0.049129][ T1] [Firmware Bug]: Feroceon L2: bootloader left the L2 cache on!
[ 0.049141][ T1] Feroceon L2: Cache support initialised.
[ 0.057317][ T1] No ATAGs?
[ 0.420091][ T1] raid6: int32x8 gen() 108 MB/s
[ 0.760092][ T1] raid6: int32x4 gen() 95 MB/s
[ 1.100089][ T1] raid6: int32x2 gen() 135 MB/s
[ 1.440087][ T1] raid6: int32x1 gen() 96 MB/s
[ 1.440104][ T1] raid6: using algorithm int32x2 gen() 135 MB/s
[ 1.780091][ T1] raid6: .... xor() 83 MB/s, rmw enabled
[ 1.780105][ T1] raid6: using intx1 recovery algorithm
[ 1.781769][ T1] SCSI subsystem initialized
[ 1.790558][ T1] usbcore: registered new interface driver usbfs
[ 1.790656][ T1] usbcore: registered new interface driver hub
[ 1.790723][ T1] usbcore: registered new device driver usb
[ 1.791103][ T1] pps_core: LinuxPPS API ver. 1 registered
[ 1.791115][ T1] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[ 1.791147][ T1] PTP clock support registered
[ 1.793893][ T1] vgaarb: loaded
[ 1.794692][ T1] clocksource: Switched to clocksource orion_clocksource
[ 1.817823][ T1] VFS: Disk quotas dquot_6.6.0
[ 1.818264][ T1] VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[ 1.847797][ T1] NET: Registered PF_INET protocol family
[ 1.854841][ T1] IP idents hash table entries: 8192 (order: 4, 65536 bytes, linear)
[ 1.857502][ T1] tcp_listen_portaddr_hash hash table entries: 1024 (order: 0, 4096 bytes, linear)
[ 1.857720][ T1] Table-perturb hash table entries: 65536 (order: 6, 262144 bytes, linear)
[ 1.858711][ T1] TCP established hash table entries: 4096 (order: 2, 16384 bytes, linear)
[ 1.858795][ T1] TCP bind hash table entries: 4096 (order: 3, 32768 bytes, linear)
[ 1.859290][ T1] TCP: Hash tables configured (established 4096 bind 4096)
[ 1.859957][ T1] MPTCP token hash table entries: 512 (order: 0, 6144 bytes, linear)
[ 1.860197][ T1] UDP hash table entries: 256 (order: 0, 4096 bytes, linear)
[ 1.860233][ T1] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes, linear)
[ 1.861281][ T1] NET: Registered PF_UNIX/PF_LOCAL protocol family
[ 1.865557][ T1] RPC: Registered named UNIX socket transport module.
[ 1.865572][ T1] RPC: Registered udp transport module.
[ 1.865579][ T1] RPC: Registered tcp transport module.
[ 1.865585][ T1] RPC: Registered tcp-with-tls transport module.
[ 1.865591][ T1] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 1.865612][ T1] PCI: CLS 0 bytes, default 32
[ 3.194955][ T1] Initialise system trusted keyrings
[ 3.195106][ T1] Key type blacklist registered
[ 3.195469][ T1] workingset: timestamp_bits=14 max_order=17 bucket_order=3
[ 3.195701][ T1] zbud: loaded
[ 3.213712][ T1] NFS: Registering the id_resolver key type
[ 3.213790][ T1] Key type id_resolver registered
[ 3.213800][ T1] Key type id_legacy registered
[ 3.213994][ T1] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[ 3.214051][ T1] nfs4flexfilelayout_init: NFSv4 Flexfile Layout Driver Registering...
[ 3.215320][ T1] fuse: init (API version 7.40)
[ 3.216893][ T1] SGI XFS with ACLs, security attributes, realtime, scrub, quota, no debug enabled
[ 3.497367][ T1] xor: measuring software checksum speed
[ 3.506266][ T1] arm4regs : 1113 MB/sec
[ 3.521024][ T1] 8regs : 667 MB/sec
[ 3.531434][ T1] 32regs : 947 MB/sec
[ 3.531445][ T1] xor: using function: arm4regs (1113 MB/sec)
[ 3.531460][ T1] async_tx: api initialized (async)
[ 3.531476][ T1] Key type asymmetric registered
[ 3.531485][ T1] Asymmetric key parser 'x509' registered
[ 3.540141][ T1] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 247)
[ 3.540623][ T1] io scheduler bfq registered
[ 3.729701][ T1] kirkwood-pinctrl f1010000.pin-controller: registered pinctrl driver
[ 3.731295][ T1] gpio gpiochip0: Static allocation of GPIO base is deprecated, use dynamic allocation.
[ 3.732458][ T1] gpio gpiochip1: Static allocation of GPIO base is deprecated, use dynamic allocation.
[ 3.733762][ T1] mv_xor f1060800.xor: Marvell shared XOR driver
[ 3.796111][ T1] mv_xor f1060800.xor: Marvell XOR (Registers Mode): ( xor cpy intr )
[ 3.800647][ T1] mv_xor f1060900.xor: Marvell shared XOR driver
[ 3.866126][ T1] mv_xor f1060900.xor: Marvell XOR (Registers Mode): ( xor cpy intr )
[ 3.870701][ T1] Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
[ 3.872998][ T1] printk: legacy console [ttyS0] disabled
[ 3.873692][ T1] f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 27, base_baud = 12500000) is a 16550A
[ 3.873767][ T1] printk: legacy console [ttyS0] enabled
[ 4.737395][ T1] loop: module loaded
[ 4.742462][ T1] nand: device found, Manufacturer ID: 0xec, Chip ID: 0xdc
[ 4.749736][ T1] nand: Samsung NAND 512MiB 3,3V 8-bit
[ 4.755112][ T1] nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
[ 4.763552][ T1] Scanning device for bad blocks
[ 4.942128][ T1] Bad eraseblock 2258 at 0x000011a40000
[ 5.088917][ T1] 4 cmdlinepart partitions found on MTD device orion_nand
[ 5.095943][ T1] Creating 4 MTD partitions on "orion_nand":
[ 5.101817][ T1] 0x000000000000-0x000000100000 : "u-boot"
[ 5.108222][ T1] 0x000000100000-0x000000500000 : "kernel"
[ 5.114645][ T1] 0x000000500000-0x000000a00000 : "pluginfo"
[ 5.121285][ T1] 0x000000a00000-0x000020000000 : "rootfs"
[ 5.131156][ T1] wireguard: WireGuard 1.0.0 loaded. See www.wireguard.com for information.
[ 5.139815][ T1] wireguard: Copyright (C) 2015-2019 Jason A. Donenfeld <Jason@zx2c4.com>. All Rights Reserved.
[ 5.156221][ T1] mv643xx_eth: MV-643xx 10/100/1000 ethernet driver version 1.4
[ 5.925915][ T1] mv643xx_eth_port mv643xx_eth_port.0 eth0: port 0 with MAC address 00:26:db:00:00:00
[ 5.935937][ T1] orion-ehci f1050000.ehci: EHCI Host Controller
[ 5.942188][ T1] orion-ehci f1050000.ehci: new USB bus registered, assigned bus number 1
[ 5.951044][ T1] orion-ehci f1050000.ehci: irq 30, io mem 0xf1050000
[ 5.984716][ T1] orion-ehci f1050000.ehci: USB 2.0 started, EHCI 1.00
[ 5.991875][ T1] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.10
[ 6.000925][ T1] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 6.008913][ T1] usb usb1: Product: EHCI Host Controller
[ 6.014526][ T1] usb usb1: Manufacturer: Linux 6.10.11-kirkwood-UBIFS-2 ehci_hcd
[ 6.022245][ T1] usb usb1: SerialNumber: f1050000.ehci
[ 6.028669][ T1] hub 1-0:1.0: USB hub found
[ 6.033205][ T1] hub 1-0:1.0: 1 port detected
[ 6.038851][ T1] usbcore: registered new interface driver usb-storage
[ 6.046262][ T1] mousedev: PS/2 mouse device common for all mice
[ 6.054036][ T1] rtc-mv f1010300.rtc: registered as rtc0
[ 6.059741][ T1] rtc-mv f1010300.rtc: setting system clock to 2024-10-25T22:34:17 UTC (1729895657)
[ 6.069474][ T1] i2c_dev: i2c /dev entries driver
[ 6.075653][ T1] device-mapper: uevent: version 1.0.3
[ 6.081621][ T1] device-mapper: ioctl: 4.48.0-ioctl (2023-03-01) initialised: dm-devel@lists.linux.dev
[ 6.092040][ T1] device-mapper: multipath round-robin: version 1.2.0 loaded
[ 6.099375][ T1] device-mapper: multipath queue-length: version 0.2.0 loaded
[ 6.106762][ T1] device-mapper: multipath service-time: version 0.3.0 loaded
[ 6.114307][ T1] device-mapper: dm-log-userspace: version 1.3.0 loaded
[ 6.121988][ T1] sdhci: Secure Digital Host Controller Interface driver
[ 6.128936][ T1] sdhci: Copyright(c) Pierre Ossman
[ 6.136094][ T1] ledtrig-cpu: registered to indicate activity on CPUs
[ 6.142975][ T1] hid: raw HID events driver (C) Jiri Kosina
[ 6.149363][ T1] drop_monitor: Initializing network drop monitor service
[ 6.158194][ T1] NET: Registered PF_INET6 protocol family
[ 6.167167][ T1] Segment Routing with IPv6
[ 6.171611][ T1] RPL Segment Routing with IPv6
[ 6.177027][ T1] In-situ OAM (IOAM) with IPv6
[ 6.181833][ T1] NET: Registered PF_PACKET protocol family
[ 6.188139][ T1] Key type dns_resolver registered
[ 6.210752][ T1] registered taskstats version 1
[ 6.215903][ T1] Loading compiled-in X.509 certificates
[ 6.263268][ T1] Key type .fscrypt registered
[ 6.268047][ T1] Key type fscrypt-provisioning registered
[ 6.279884][ T1] Key type big_key registered
[ 6.294838][ T1] Key type encrypted registered
[ 6.324822][ T10] usb 1-1: new high-speed USB device number 2 using orion-ehci
[ 6.368564][ T110] "cryptomgr_test" (110) uses obsolete ecb(arc4) skcipher
[ 6.537393][ T10] usb 1-1: New USB device found, idVendor=05dc, idProduct=a701, bcdDevice=11.00
[ 6.564710][ T10] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 6.572600][ T10] usb 1-1: Product: JD FIREFLY
[ 6.584728][ T10] usb 1-1: Manufacturer: LEXAR
[ 6.589395][ T10] usb 1-1: SerialNumber: 1069A704000328051007
[ 6.605883][ T10] usb-storage 1-1:1.0: USB Mass Storage device detected
[ 6.625382][ T10] scsi host0: usb-storage 1-1:1.0
[ 7.686358][ T21] scsi 0:0:0:0: Direct-Access LEXAR JD FIREFLY 1100 PQ: 0 ANSI: 0 CCS
[ 7.709421][ T11] sd 0:0:0:0: [sda] 7864320 512-byte logical blocks: (4.03 GB/3.75 GiB)
[ 7.725427][ T11] sd 0:0:0:0: [sda] Write Protect is off
[ 7.735042][ T11] sd 0:0:0:0: [sda] No Caching mode page found
[ 7.741117][ T11] sd 0:0:0:0: [sda] Assuming drive cache: write through
[ 7.772415][ T11] sda: sda1
[ 7.776034][ T11] sd 0:0:0:0: [sda] Attached SCSI removable disk
[ 8.774194][ T1] clk: Disabling unused clocks
[ 8.779260][ T1] md: Waiting for all devices to be available before autodetect
[ 8.786881][ T1] md: If you don't use raid, use raid=noautodetect
[ 8.793278][ T1] md: Autodetecting RAID arrays.
[ 8.798227][ T1] md: autorun ...
[ 8.801742][ T1] md: ... autorun DONE.
[ 8.807924][ T1] EXT4-fs (sda1): mounting ext2 file system using the ext4 subsystem
[ 8.827142][ T1] EXT4-fs (sda1): mounted filesystem 5ec942cc-1717-430e-a219-0c51c7f0b047 r/w without journal. Quota mode: non.
[ 8.839090][ T1] VFS: Mounted root (ext2 filesystem) on device 8:1.
[ 8.880403][ T1] devtmpfs: mounted
[ 8.887232][ T1] Freeing unused kernel image (initmem) memory: 1024K
[ 8.894067][ T1] Run /sbin/init as init process
[ 9.739259][ T1] systemd[1]: Failed to look up module alias 'autofs4': Function not implemented
[ 9.827769][ T1] systemd[1]: systemd 247.3-7+deb11u5 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYS)
[ 9.852532][ T1] systemd[1]: Detected architecture arm.
Welcome to Debian GNU/Linux 11 (bullseye)!
[ 9.896699][ T1] systemd[1]: Set hostname to <comlogger>.
[ 11.934442][ T1] systemd[1]: Queued start job for default target Graphical Interface.
[ 13.424753][ C0] random: crng init done
[ 13.461064][ T1] systemd[1]: Created slice system-getty.slice.
[ OK ] Created slice system-getty.slice.
[ 13.497390][ T1] systemd[1]: Created slice system-modprobe.slice.
[ OK ] Created slice system-modprobe.slice.
[ 13.537334][ T1] systemd[1]: Created slice system-serial\x2dgetty.slice.
[ OK ] Created slice system-serial\x2dgetty.slice.
[ 13.576953][ T1] systemd[1]: Created slice User and Session Slice.
[ OK ] Created slice User and Session Slice.
[ 13.615495][ T1] systemd[1]: Started Dispatch Password Requests to Console Directory Watch.
[ OK ] Started Dispatch Password ?…ts to Console Directory Watch.
[ 13.655416][ T1] systemd[1]: Started Forward Password Requests to Wall Directory Watch.
[ OK ] Started Forward Password R?…uests to Wall Directory Watch.
[ 13.695492][ T1] systemd[1]: Starting of Arbitrary Executable File Formats File System Automount Point not supported.
[UNSUPP] Starting of Arbitrary Exec?…Automount Point not supported.
[ 13.745229][ T1] systemd[1]: Reached target Local Encrypted Volumes.
[ OK ] Reached target Local Encrypted Volumes.
[ 13.785533][ T1] systemd[1]: Reached target Paths.
[ OK ] Reached target Paths.
[ 13.825342][ T1] systemd[1]: Reached target Slices.
[ OK ] Reached target Slices.
[ 13.865195][ T1] systemd[1]: Reached target Swap.
[ OK ] Reached target Swap.
[ 13.953448][ T1] systemd[1]: Listening on RPCbind Server Activation Socket.
[ OK ] Listening on RPCbind Server Activation Socket.
[ 13.996255][ T1] systemd[1]: Listening on fsck to fsckd communication Socket.
[ OK ] Listening on fsck to fsckd communication Socket.
[ 14.035630][ T1] systemd[1]: Listening on initctl Compatibility Named Pipe.
[ OK ] Listening on initctl Compatibility Named Pipe.
[ 14.076690][ T1] systemd[1]: Listening on Journal Audit Socket.
[ OK ] Listening on Journal Audit Socket.
[ 14.116217][ T1] systemd[1]: Listening on Journal Socket (/dev/log).
[ OK ] Listening on Journal Socket (/dev/log).
[ 14.156434][ T1] systemd[1]: Listening on Journal Socket.
[ OK ] Listening on Journal Socket.
[ 14.206181][ T1] systemd[1]: Listening on udev Control Socket.
[ OK ] Listening on udev Control Socket.
[ 14.246045][ T1] systemd[1]: Listening on udev Kernel Socket.
[ OK ] Listening on udev Kernel Socket.
[ 14.286326][ T1] systemd[1]: Condition check resulted in Huge Pages File System being skipped.
[ 14.325515][ T1] systemd[1]: Mounting POSIX Message Queue File System...
Mounting POSIX Message Queue File System...
[ 14.373597][ T1] systemd[1]: Mounting RPC Pipe File System...
Mounting RPC Pipe File System...
[ 14.455372][ T1] systemd[1]: Mounting Kernel Debug File System...
Mounting Kernel Debug File System...
[ 14.484562][ T1] systemd[1]: Mounting Kernel Trace File System...
Mounting Kernel Trace File System...
[ 14.535368][ T1] systemd[1]: Condition check resulted in Kernel Module supporting RPCSEC_GSS being skipped.
[ 14.546427][ T1] systemd[1]: Condition check resulted in Create list of static device nodes for the current kernel being skip.
[ 14.585988][ T1] systemd[1]: Starting Load Kernel Module configfs...
Starting Load Kernel Module configfs...
[ 14.643534][ T1] systemd[1]: Starting Load Kernel Module drm...
Starting Load Kernel Module drm...
[ 14.694967][ T1] systemd[1]: Starting Load Kernel Module fuse...
Starting Load Kernel Module fuse...
[ 14.739567][ T1] systemd[1]: Condition check resulted in Set Up Additional Binary Formats being skipped.
[ 14.750178][ T1] systemd[1]: Condition check resulted in File System Check on Root Device being skipped.
[ 14.796173][ T1] systemd[1]: Starting Journal Service...
Starting Journal Service...
[ 14.838323][ T1] systemd[1]: Starting Load Kernel Modules...
Starting Load Kernel Modules...
[ 14.861692][ T1] systemd[1]: Starting Remount Root and Kernel File Systems...
Starting Remount Root and Kernel File Systems...
[ 14.976173][ T1] systemd[1]: Starting Coldplug All udev Devices...
Starting Coldplug All udev Devices...
[ 15.062158][ T1] systemd[1]: Mounted POSIX Message Queue File System.
[ OK ] Mounted POSIX Message Queue File System.
[ 15.146744][ T1] systemd[1]: Mounted RPC Pipe File System.
[ OK ] Mounted RPC Pipe File System.
[ 15.169423][ T1] systemd[1]: Mounted Kernel Debug File System.
[ OK ] Mounted Kernel Debug File System.
[ 15.235505][ T1] systemd[1]: Mounted Kernel Trace File System.
[ OK ] Mounted Kernel Trace File System.
[ 15.269584][ T1] systemd[1]: modprobe@configfs.service: Succeeded.
[ 15.304846][ T1] systemd[1]: Finished Load Kernel Module configfs.
[ OK ] Finished Load Kernel Module configfs.
[ 15.360832][ T1] systemd[1]: modprobe@drm.service: Succeeded.
[ 15.401622][ T1] systemd[1]: Finished Load Kernel Module drm.
[ OK ] Finished Load Kernel Module drm.
[ 15.458088][ T1] systemd[1]: modprobe@fuse.service: Succeeded.
[ 15.484795][ T160] EXT4-fs (sda1): re-mounted 5ec942cc-1717-430e-a219-0c51c7f0b047 r/w. Quota mode: none.
[ 15.496841][ T1] systemd[1]: Finished Load Kernel Module fuse.
[ OK ] Finished Load Kernel Module fuse.
[ 15.533252][ T1] systemd[1]: systemd-modules-load.service: Main process exited, code=exited, status=1/FAILURE
[ 15.586373][ T1] systemd[1]: systemd-modules-load.service: Failed with result 'exit-code'.
[ 15.616843][ T1] systemd[1]: Failed to start Load Kernel Modules.
[FAILED] Failed to start Load Kernel Modules.
See 'systemctl status systemd-modules-load.service' for details.
[ 15.686838][ T1] systemd[1]: Started Journal Service.
[ OK ] Started Journal Service.
[ OK ] Finished Remount Root and Kernel File Systems.
Mounting FUSE Control File System...
Starting Flush Journal to Persistent Storage...
Starting Load/Save Random Seed...
Starting Apply Kernel Variables...
Starting Create System Users...
[ OK ] Mounted FUSE Control File System.
[ 16.175780][ T156] systemd-journald[156]: Received client request to flush runtime journal.
[ OK ] Finished Coldplug All udev Devices.
Starting Helper to synchronize boot up for ifupdown...
[ OK ] Finished Apply Kernel Variables.
[ OK ] Finished Load/Save Random Seed.
[ OK ] Finished Create System Users.
Starting Create Static Device Nodes in /dev...
[ OK ] Finished Create Static Device Nodes in /dev.
[ OK ] Reached target Local File Systems (Pre).
[ OK ] Reached target Local File Systems.
Starting Preprocess NFS configuration...
Starting Rule-based Manage?…for Device Events and Files...
[ OK ] Finished Preprocess NFS configuration.
[ OK ] Reached target NFS client services.
[ OK ] Started Rule-based Manager for Device Events and Files.
[ OK ] Found device /dev/ttyS0.
[ OK ] Found device /sys/subsystem/net/devices/eth0.
[ OK ] Finished Helper to synchronize boot up for ifupdown.
[ OK ] Started ifup for eth0.
Starting Raise network interfaces...
[*** ] (2 of 2) A start job is running for?…ersistent Storage (21s / 1min 33s)
[ OK ] Finished Raise network interfaces.
[ OK ] Reached target Network.
[ OK ] Finished Flush Journal to Persistent Storage.
Starting Create Volatile Files and Directories...
[ OK ] Finished Create Volatile Files and Directories.
Starting RPC bind portmap service...
Starting Update UTMP about System Boot/Shutdown...
[ OK ] Started RPC bind portmap service.
[ OK ] Reached target Remote File Systems (Pre).
[ OK ] Reached target Remote File Systems.
[ OK ] Reached target RPC Port Mapper.
[ OK ] Finished Update UTMP about System Boot/Shutdown.
[ OK ] Reached target System Initialization.
[ OK ] Started Daily apt download activities.
[ OK ] Started Daily apt upgrade and clean activities.
[ OK ] Started Periodic ext4 Onli?…ata Check for All Filesystems.
[ OK ] Started Discard unused blocks once a week.
[ OK ] Started Daily man-db regeneration.
[ OK ] Started Daily Cleanup of Temporary Directories.
[ OK ] Reached target Timers.
[ OK ] Listening on D-Bus System Message Bus Socket.
[ OK ] Reached target Sockets.
[ OK ] Reached target Basic System.
[ OK ] Started Regular background program processing daemon.
[ OK ] Started D-Bus System Message Bus.
Starting Remove Stale Onli?…t4 Metadata Check Snapshots...
Starting Network Time Service...
Starting OpenBSD Secure Shell server...
Starting User Login Management...
Starting Permit User Sessions...
[ OK ] Finished Permit User Sessions.
[ OK ] Started Getty on tty1.
[ OK ] Started Serial Getty on ttyS0.
[ OK ] Reached target Login Prompts.
[ OK ] Started Network Time Service.
[ OK ] Finished Remove Stale Onli?…ext4 Metadata Check Snapshots.
[ OK ] Started OpenBSD Secure Shell server.
[ OK ] Started User Login Management.
[ OK ] Reached target Multi-User System.
[ OK ] Reached target Graphical Interface.
Starting Update UTMP about System Runlevel Changes...
[ OK ] Finished Update UTMP about System Runlevel Changes.
root@comlogger:~# lsusb Bus 001 Device 002: ID 05dc:a701 Lexar Media, Inc. JumpDrive FireFly Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub root@comlogger:~# ls /dev/sg* ls: cannot access '/dev/sg*': No such file or directoryPerhaps the USB disconnect only occurs if the USB drive is not the rootfs.
Perhaps the creation of /dev/sg0 is a difference between the Debian 11 USB rootfs and the Debian 12 UBIFS rootfs. Or, maybe the creation of /dev/sg0 only occurs when devices are enumerated after the rootfs is mounted?
I'll have a look later at what happens booting the UBIFS roots with and without the USB rootfs with your 5.10.7 kernel and the "nimbus-100" DTB file.
I have to leave now.
Thanks again.
Larry Baker
|
Re: Please add built-in kernel UBIFS support for Kirkwood and any other boards with on-board eMMC flash October 25, 2024 07:10PM |
Registered: 10 years ago Posts: 481 |
mossbeachlarry Wrote:
-------------------------------------------------------
> I have something that may save you a whole lot of
> time, assuming you are on the right track: the
> Ionics-EMS Nimbus 101 SDK v6.1-p1.tar.bz2.
> It is very comprehensive, including the upstream
> Marvell U-Boot and Linux kernel source archives
> and the Nimbus patches to those. It is too big I
> think (520 MB) to attach to this message, but I am
Can I ask where you found this? I have 2 different Ionics Kirkwood Devices I'd like to get supported and the source would be very helpful. I have the Ionics Stratus and Ionics Cirrus.
Ray
-------------------------------------------------------
> I have something that may save you a whole lot of
> time, assuming you are on the right track: the
> Ionics-EMS Nimbus 101 SDK v6.1-p1.tar.bz2.
> It is very comprehensive, including the upstream
> Marvell U-Boot and Linux kernel source archives
> and the Nimbus patches to those. It is too big I
> think (520 MB) to attach to this message, but I am
Can I ask where you found this? I have 2 different Ionics Kirkwood Devices I'd like to get supported and the source would be very helpful. I have the Ionics Stratus and Ionics Cirrus.
Ray
|
Re: Please add built-in kernel UBIFS support for Kirkwood boards October 25, 2024 07:39PM |
Admin Registered: 14 years ago Posts: 19,916 |
Larry,
The difference is the first run, ubi_boot also executes "init_ionics mode bootup"
The 2nd run does not execute "init_ionics mode bootup"
The 1st run behavior.
When we run "init_ionics mode bootup", the USB power bit is set and the LED bit is clear. This is a coding error in that command init_ionics. During boot, there is not enough power so the USB storage got disconnected. Later, the DT regulator kicks in, and that's when full power is applied again to the USB port.
The 2nd run behavior.
Since the USB power GPIO is clear (active low logic), the power is kept constantly throughout.
You could run another test with run ubi_boot, but without the init_ionics command
======
I've noticed you have a problem with the kernel loading.
The uInitrd load address should be 0x2100000. Here is the referenced instruction in the Wiki thread
With the fix for initrd load address, you can use the bootarg root=LABEL=rootfs to tell the kernel to find the rootfs automatically. IOW, there is no need to use root=/dev/sda1, which error prone on a multiple USB drives configuration.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
The difference is the first run, ubi_boot also executes "init_ionics mode bootup"
ubi_boot=init_ionics mode bootup; run bootcmd_ubi; run set_ubi_bootargs; bootm 0x00800000 Marvell>> run ubi_boot
The 2nd run does not execute "init_ionics mode bootup"
Marvell>> setenv bootargs $(bootargs_console) rootfstype=ext2 root=/dev/sda1 rw Marvell>> ubi part rootfs; ubifsmount rootfs; ubifsload 0x00800000 /boot/uImage Marvell>> usb start; ext2load usb 0:1 0x01100000 /boot/uInitrd Marvell>> bootm 0x00800000 0x01100000
The 1st run behavior.
When we run "init_ionics mode bootup", the USB power bit is set and the LED bit is clear. This is a coding error in that command init_ionics. During boot, there is not enough power so the USB storage got disconnected. Later, the DT regulator kicks in, and that's when full power is applied again to the USB port.
[ 22.039765][ T11] regulator@1 enforce active low on GPIO handle [ 22.513839][ T8] usb 1-1: new high-speed USB device number 3 using orion-ehci [ 22.724809][ T8] usb 1-1: New USB device found, idVendor=05dc, idProduct=a701, bcdDevice=11.00 [ 22.743961][ T8] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 22.751883][ T8] usb 1-1: Product: JD FIREFLY [ 22.784634][ T8] usb 1-1: Manufacturer: LEXAR [ 22.789307][ T8] usb 1-1: SerialNumber: 1069A704000328051007 [ 22.806954][ T8] usb-storage 1-1:1.0: USB Mass Storage device detected
The 2nd run behavior.
Since the USB power GPIO is clear (active low logic), the power is kept constantly throughout.
You could run another test with run ubi_boot, but without the init_ionics command
ubi_boot=run bootcmd_ubi; run set_ubi_bootargs; bootm 0x00800000
======
I've noticed you have a problem with the kernel loading.
[ 0.000000][ T0] INITRD: 0x01100000+0x00fd5000 overlaps in-use memory region [ 0.000000][ T0] - disabling initrd
The uInitrd load address should be 0x2100000. Here is the referenced instruction in the Wiki thread
Quote
Kirkwood plugs
Boot Kirkwood rootfs with stock u-boot
With the fix for initrd load address, you can use the bootarg root=LABEL=rootfs to tell the kernel to find the rootfs automatically. IOW, there is no need to use root=/dev/sda1, which error prone on a multiple USB drives configuration.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: Please add built-in kernel UBIFS support for Kirkwood and any other boards with on-board eMMC flash October 25, 2024 11:48PM |
Registered: 1 year ago Posts: 61 |
Ray,
> Can I ask where you found this? I have 2 different Ionics Kirkwood Devices
> I'd like to get supported and the source would be very helpful.
> I have the Ionics Stratus and Ionics Cirrus.
I have had the Nimbus SDK since I bought the Nimbus over 10 years ago. I put it on my Google Drive:
Nimbus 101 SDK v6.1-p1.tar.bz2
You can grab it from there. I have no idea whether it will help you with the Stratus and Cirrus boxes.
Larry Baker
> Can I ask where you found this? I have 2 different Ionics Kirkwood Devices
> I'd like to get supported and the source would be very helpful.
> I have the Ionics Stratus and Ionics Cirrus.
I have had the Nimbus SDK since I bought the Nimbus over 10 years ago. I put it on my Google Drive:
Nimbus 101 SDK v6.1-p1.tar.bz2
You can grab it from there. I have no idea whether it will help you with the Stratus and Cirrus boxes.
Larry Baker
|
Re: Please add built-in kernel UBIFS support for Kirkwood boards October 26, 2024 01:20AM |
Registered: 1 year ago Posts: 61 |
bodhi,
> During boot, there is not enough power so the USB storage got disconnected.
> Later, the DT regulator kicks in, and that's when full power is applied again to the USB port.
Yet, what puzzles me is when I run Debian 11 on USB, the 5.10.0-32-marvell kernel comes up just fine with init_ionics mode bootup. The USB drive is enumerated early and there is no disconnect. Should not that have had the power problem you describe since Linux doesn't know from the kirkwood-sheevaplug.dtb appended to that kernel that the USB Power pin is inverted? I don't think Linux 5.10.x actively managed USB power anyway, so it would not have altered the USB Power pin from the init_ionics mode bootup setting. I run Debian 11 off USB that way just fine. It is Debian 12 with its 6.1.0-25-marvell kernel and appended kirkwood-sheevaplug.dtb that disconnects the USB drive after enumerating the partitions.
> The 2nd run behavior.
> Since the USB power GPIO is clear (active low logic), the power is kept constantly throughout.
The just happened to be the way I booted the hybrid UBIFS uImage with the USB uInitrd and USB rootfs. The way it normally boots up the Debian 11 USB rootfs (the default bootcmd), init_ionics mode bootup is the first command given.
> I've noticed you have a problem with the kernel loading.
Good catch. I forgot about how much larger your kernels are than the Debian kernels. It didn't matter anyway, because I don't need anything in the uInitrd to successfully boot up the Debian 11 USB rootfs.
> you can use the bootarg root=LABEL=rootfs
I thought about that before, but I knew the drive was enumerated as sda1, so that's what I used.
I want to compare apples and apples. Over the weekend I will install Debian 12 on a USB stick running on my SheevaPlug. Then I'll peel away the kirkwood-sheevaplug.dtb off their kernel uImage and tack on your kirkwood-nimbus-100.dtb. That USB stick should then be bootable on my Nimbus. Then I can compare the two bootup message streams.
Assuming that looks great, I do want to know what your advice is about flashing a more recent SheevaPlug U-Boot on my Nimbus. We'll discuss that after I see what Debian 12 on USB looks like.
I owe you one.
Larry Baker
> During boot, there is not enough power so the USB storage got disconnected.
> Later, the DT regulator kicks in, and that's when full power is applied again to the USB port.
Yet, what puzzles me is when I run Debian 11 on USB, the 5.10.0-32-marvell kernel comes up just fine with init_ionics mode bootup. The USB drive is enumerated early and there is no disconnect. Should not that have had the power problem you describe since Linux doesn't know from the kirkwood-sheevaplug.dtb appended to that kernel that the USB Power pin is inverted? I don't think Linux 5.10.x actively managed USB power anyway, so it would not have altered the USB Power pin from the init_ionics mode bootup setting. I run Debian 11 off USB that way just fine. It is Debian 12 with its 6.1.0-25-marvell kernel and appended kirkwood-sheevaplug.dtb that disconnects the USB drive after enumerating the partitions.
> The 2nd run behavior.
> Since the USB power GPIO is clear (active low logic), the power is kept constantly throughout.
The just happened to be the way I booted the hybrid UBIFS uImage with the USB uInitrd and USB rootfs. The way it normally boots up the Debian 11 USB rootfs (the default bootcmd), init_ionics mode bootup is the first command given.
> I've noticed you have a problem with the kernel loading.
Good catch. I forgot about how much larger your kernels are than the Debian kernels. It didn't matter anyway, because I don't need anything in the uInitrd to successfully boot up the Debian 11 USB rootfs.
> you can use the bootarg root=LABEL=rootfs
I thought about that before, but I knew the drive was enumerated as sda1, so that's what I used.
I want to compare apples and apples. Over the weekend I will install Debian 12 on a USB stick running on my SheevaPlug. Then I'll peel away the kirkwood-sheevaplug.dtb off their kernel uImage and tack on your kirkwood-nimbus-100.dtb. That USB stick should then be bootable on my Nimbus. Then I can compare the two bootup message streams.
Assuming that looks great, I do want to know what your advice is about flashing a more recent SheevaPlug U-Boot on my Nimbus. We'll discuss that after I see what Debian 12 on USB looks like.
I owe you one.
Larry Baker
|
Re: Please add built-in kernel UBIFS support for Kirkwood and any other boards with on-board eMMC flash October 26, 2024 12:59PM |
Registered: 1 year ago Posts: 61 |
Ray,
In case your Ionics Kirkwood devices are bricked, attached are my notes to backup and restore my Ionics Nimbus. Instead of overwriting the rootfs on the recovery USB, you can leave the original factory rootfs alone and restore the system the way it came from the factory. Of course, it will be the Nimbus rootfs. I have no idea how that may work on your boxes.
Regards,
Larry Baker
In case your Ionics Kirkwood devices are bricked, attached are my notes to backup and restore my Ionics Nimbus. Instead of overwriting the rootfs on the recovery USB, you can leave the original factory rootfs alone and restore the system the way it came from the factory. Of course, it will be the Nimbus rootfs. I have no idea how that may work on your boxes.
Regards,
Larry Baker
|
Re: Please add built-in kernel UBIFS support for Kirkwood and any other boards with on-board eMMC flash October 26, 2024 01:19PM |
Registered: 10 years ago Posts: 481 |
|
Re: Please add built-in kernel UBIFS support for Kirkwood boards October 26, 2024 02:23PM |
Admin Registered: 14 years ago Posts: 19,916 |
Larry,
> Yet, what puzzles me is when I run Debian 11 on
> USB, the 5.10.0-32-marvell kernel comes up just
> fine with init_ionics mode bootup.
> The USB
> drive is enumerated early and there is no
> disconnect. Should not that have had the power
> problem you describe since Linux doesn't know from
> the kirkwood-sheevaplug.dtb appended to that
> kernel that the USB Power pin is inverted?
The kernel code changes from 5.10.x to 5.15.x have a lot to do with that behaviour.
> I don't think Linux 5.10.x actively managed USB
> power anyway
Not true, it does. But perhaps bad assumption was made in 5.10.x and earlier, and then later somewhere before 5.15.x, the pinctrl and/or regulator drivers were fixed to correct that. So now it does the right thing, but causing problem for old code.
> The just happened to be the way I booted the
> hybrid UBIFS uImage with the USB uInitrd and USB
> rootfs. The way it normally boots up the Debian
> 11 USB rootfs (the default bootcmd),
> init_ionics mode bootup is the first
> command given.
The init_ionics command in stock u-boot does nothing special, just flashing the LEDs during boot, and then provide a way to shutdown. Since you are booting Debian, this command is not needed.
> Good catch. I forgot about how much larger your
> kernels are than the Debian kernels. It didn't
> matter anyway, because I don't need anything in
> the uInitrd to successfully boot up the Debian 11
> USB rootfs.
Booting Debian without initrd causes many limitation and restriction that you don't want to have. Note that this is not applicable to distro such as Arch or OpenWrt, where the standard is booting without initrd (needed modules are built into the kernel image).
>
> > you can use the bootarg root=LABEL=rootfs
>
> I thought about that before, but I knew the drive
> was enumerated as sda1, so that's what I used.
Yes indeed for this configuration with 1 USB drive.
However, this should be corrected because as soon as you plug in a USB hub and connect multiple drives, if one of them is the rootfs drive that you want to boot to, then you'll have booting problem because /dev/sda could be assigned to any of those drives (the order of enumeration is unpredictable).
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
> Yet, what puzzles me is when I run Debian 11 on
> USB, the 5.10.0-32-marvell kernel comes up just
> fine with init_ionics mode bootup.
> The USB
> drive is enumerated early and there is no
> disconnect. Should not that have had the power
> problem you describe since Linux doesn't know from
> the kirkwood-sheevaplug.dtb appended to that
> kernel that the USB Power pin is inverted?
The kernel code changes from 5.10.x to 5.15.x have a lot to do with that behaviour.
> I don't think Linux 5.10.x actively managed USB
> power anyway
Not true, it does. But perhaps bad assumption was made in 5.10.x and earlier, and then later somewhere before 5.15.x, the pinctrl and/or regulator drivers were fixed to correct that. So now it does the right thing, but causing problem for old code.
> The just happened to be the way I booted the
> hybrid UBIFS uImage with the USB uInitrd and USB
> rootfs. The way it normally boots up the Debian
> 11 USB rootfs (the default bootcmd),
> init_ionics mode bootup is the first
> command given.
The init_ionics command in stock u-boot does nothing special, just flashing the LEDs during boot, and then provide a way to shutdown. Since you are booting Debian, this command is not needed.
> Good catch. I forgot about how much larger your
> kernels are than the Debian kernels. It didn't
> matter anyway, because I don't need anything in
> the uInitrd to successfully boot up the Debian 11
> USB rootfs.
Booting Debian without initrd causes many limitation and restriction that you don't want to have. Note that this is not applicable to distro such as Arch or OpenWrt, where the standard is booting without initrd (needed modules are built into the kernel image).
>
> > you can use the bootarg root=LABEL=rootfs
>
> I thought about that before, but I knew the drive
> was enumerated as sda1, so that's what I used.
Yes indeed for this configuration with 1 USB drive.
However, this should be corrected because as soon as you plug in a USB hub and connect multiple drives, if one of them is the rootfs drive that you want to boot to, then you'll have booting problem because /dev/sda could be assigned to any of those drives (the order of enumeration is unpredictable).
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: Please add built-in kernel UBIFS support for Kirkwood boards October 28, 2024 12:40AM |
Registered: 1 year ago Posts: 61 |
bodhi,
Here's what I have learned this weekend.
I installed Debian 12 to USB on a SheevaPlug, Linux version 6.1.0-26-marvell.
It booted fine (kernel image plus initrd) on the SheevaPlug.
I renamed the Debian 12 uImage (with their kirkwood-sheevaplug.dtb) to uImage-sheevaplug.
I created a uImage-nimbus from their vmlinuz-6.1.0-26-marvell and your kirkwood-nimbus-100.dtb.
I created a uImage soft link that points to either uImage-sheevaplug or uImage-nimbus for U-Boot.
1. uImage-sheevaplug on SheevaPlug boots fine, as expected.
2. uImage-nimbus on SheevaPlug also boots fine, which surprises me. Why didn't the difference in the USB Power GPIO Active Low/High setting cause problems?
Other than the timestamp jitter and a few changes in the order of completion of the systemd steps, the only difference in the startup messages was:
3. uImage-sheevaplug on Nimbus as-is fails to mount the USB rootfs and gives up. The boot log shows no USB drives found. No surprise.
4. uImage-nimbus on Nimbus as-is also fails; the kernel does not even start. Why? There must be something in the initrd that doesn't match between a SheevaPlug and a Nimbus. It should not be the UUID of the rootfs, since that is the same USB drive. What then? (I hate initrd's. They are opaque and can do anything they want to in their init, without documentation or standards. Not like a straightforward Linux kernel boot.)
5. uImage-nimbus on Nimbus with rootfs bootargs works fine after I added "rootfstype=ext2 root=/dev/sda1 rw" to the bootargs. Why does Nimbus need these whereas SheevaPlug does not? There is some collusion between the kernel and the initrd, but what? And why is it different between the two? (One of the many reasons why I hate initrd's!)
I compared the boot logs of the 1. uImage-sheevaplug on SheevaPlug with this 5. uImage-nimbus on Nimbus with rootfs bootargs. As above, there is timestamp jitter and a few changes in the order of completion of the systemd steps, and the same difference in the OF: fdt: message:
Kernel command line (expected):
I saved all the boot logs from the five different runs above, if you want to see them.
I build my own minimal Debian 12 rootfs for the internal UBIFS flash rootfs. I do not use an initrd. It works fine, like on a PC Linux box.
Besides shrinking the footprint using compressing kernel module files, which we already discussed, I also removed all the DEBUG options except those enabled in the default ARM Multi_V5 configuration file in the 6.10.11-UBIFS-2 kernel I use:
Finally, I recall reading a post requesting "Help flashing to a Sheevaplug NAND", https://forum.doozan.com/read.php?2,135980. I think that is how I found your forum. Would you like me to post my instructions for creating a minimal Debian 12 (bookworm) rootfs for the internal UBIFS flash rootfs, and my instructions for creating the UBIFS volume? In which main topic area? It sounded like the author gave up on his attempts to install Debian 12 and went to OpenWrt instead. If his application is better suited to a more mainstream, flexible, and tailorable distribution, he may prefer Debian. That is my preference for my SheevaPlugs and Nimbus.
P.S. Ray was looking for a DTB in the Nimbus SDK. I hadn't thought of that before. I checked, and there is none. Ionics did include their kernel config file and their kernel patches, along with their patches to U-Boot and a small rootfs.
Thank you,
Larry Baker
Edited 2 time(s). Last edit at 10/28/2024 12:06PM by mossbeachlarry.
Here's what I have learned this weekend.
I installed Debian 12 to USB on a SheevaPlug, Linux version 6.1.0-26-marvell.
It booted fine (kernel image plus initrd) on the SheevaPlug.
I renamed the Debian 12 uImage (with their kirkwood-sheevaplug.dtb) to uImage-sheevaplug.
I created a uImage-nimbus from their vmlinuz-6.1.0-26-marvell and your kirkwood-nimbus-100.dtb.
I created a uImage soft link that points to either uImage-sheevaplug or uImage-nimbus for U-Boot.
1. uImage-sheevaplug on SheevaPlug boots fine, as expected.
2. uImage-nimbus on SheevaPlug also boots fine, which surprises me. Why didn't the difference in the USB Power GPIO Active Low/High setting cause problems?
Other than the timestamp jitter and a few changes in the order of completion of the systemd steps, the only difference in the startup messages was:
[ 0.000000] OF: fdt: Machine model: Globalscale Technologies SheevaPlugversus
[ 0.000000] OF: fdt: Machine model: Ionics Nimbus 100Also, the message we saw previously with your new kirkwood-nimbus-100.dtb is not there:
[ 22.039765][ T11] regulator@1 enforce active low on GPIO handleThat is because the code that prints that message did not appear until Linux 6.2. In my earlier tests, I ran my modified version of your 6.10.11 kernel. The Debian 12 kernel is 6.1.0-32, before the addition of that status message.
3. uImage-sheevaplug on Nimbus as-is fails to mount the USB rootfs and gives up. The boot log shows no USB drives found. No surprise.
4. uImage-nimbus on Nimbus as-is also fails; the kernel does not even start. Why? There must be something in the initrd that doesn't match between a SheevaPlug and a Nimbus. It should not be the UUID of the rootfs, since that is the same USB drive. What then? (I hate initrd's. They are opaque and can do anything they want to in their init, without documentation or standards. Not like a straightforward Linux kernel boot.)
5. uImage-nimbus on Nimbus with rootfs bootargs works fine after I added "rootfstype=ext2 root=/dev/sda1 rw" to the bootargs. Why does Nimbus need these whereas SheevaPlug does not? There is some collusion between the kernel and the initrd, but what? And why is it different between the two? (One of the many reasons why I hate initrd's!)
I compared the boot logs of the 1. uImage-sheevaplug on SheevaPlug with this 5. uImage-nimbus on Nimbus with rootfs bootargs. As above, there is timestamp jitter and a few changes in the order of completion of the systemd steps, and the same difference in the OF: fdt: message:
[ 0.000000] OF: fdt: Machine model: Globalscale Technologies SheevaPlugversus
[ 0.000000] OF: fdt: Machine model: Ionics Nimbus 100The other differences were:
Kernel command line (expected):
SheevaPlug: Kernel command line: console=ttyS0,115200 Nimbus: Kernel command line: console=ttyS0,115200 cmdlinepart.mtdparts=orion_nand:1m@0m(u-boot),4m@1m(kernel),5m@5m(pluginfo),-(rootfs) rootfstype=ext2 root=/dev/sda1 rwSoC Rev (SheevaPlug is a newer rev part):
SheevaPlug: mvebu-soc-id: MVEBU SoC ID=0x6281, Rev=0x3 Nimbus: mvebu-soc-id: MVEBU SoC ID=0x6281, Rev=0x2L2 cache (bug):
SheevaPlug: Feroceon L2: Enabling L2 Nimbus: [Firmware Bug]: Feroceon L2: bootloader left the L2 cache on!This bug is caused by the code Ionics added in the Nimbus U-Boot patch to board/Marvell/sheevaplug/kwbimage.cfg:
+DATA 0xFFD20134 0x66666666 <=== L2 RAM Timing 0 Register
+DATA 0xFFD20138 0x66666666 <=== L2 RAM Timing 1 Register
lsmod was the same on both systems.
I saved all the boot logs from the five different runs above, if you want to see them.
I build my own minimal Debian 12 rootfs for the internal UBIFS flash rootfs. I do not use an initrd. It works fine, like on a PC Linux box.
Besides shrinking the footprint using compressing kernel module files, which we already discussed, I also removed all the DEBUG options except those enabled in the default ARM Multi_V5 configuration file in the 6.10.11-UBIFS-2 kernel I use:
$ ARCH=arm CROSS_COMPILE=arm-none-eabi- make mrproper $ ARCH=arm CROSS_COMPILE=arm-none-eabi- make multi_v5_defconfig $ cp .config ../bodhi/config-6.10.11-multi_v5_defconfigI compared the DEBUG choices in that config file with my UBIFS-enabled version of your 6.10.11 config file and kept only theirs, except DEBUG_INFO:
$ ARCH=arm CROSS_COMPILE=arm-none-eabi- make mrproper $ grep DEBUG ../bodhi/config-6.10.11-multi_v5_defconfig | \ grep -v "^# " | grep -v "DEBUG_INFO" | sort >.config $ grep DEBUG_INFO ../bodhi/config-6.10.11-kirkwood-UBIFS | \ grep -v "^# " | sort >>.config $ grep -v DEBUG ../bodhi/config-6.10.11-kirkwood-UBIFS | \ sed -e 's/-kirkwood-UBIFS/-kirkwood-UBIFS-2/' >>.config $ ARCH=arm CROSS_COMPILE=arm-none-eabi- make olddefconfig $ cp .config ../bodhi/config-6.10.11-kirkwood-UBIFS-2That shrunk the kernel so the space penalty of adding UBIFS support went away. I encourage you to trim DEBUG options you no longer need in your upcoming 6.11.x release. I am looking forward to it. :)
Finally, I recall reading a post requesting "Help flashing to a Sheevaplug NAND", https://forum.doozan.com/read.php?2,135980. I think that is how I found your forum. Would you like me to post my instructions for creating a minimal Debian 12 (bookworm) rootfs for the internal UBIFS flash rootfs, and my instructions for creating the UBIFS volume? In which main topic area? It sounded like the author gave up on his attempts to install Debian 12 and went to OpenWrt instead. If his application is better suited to a more mainstream, flexible, and tailorable distribution, he may prefer Debian. That is my preference for my SheevaPlugs and Nimbus.
P.S. Ray was looking for a DTB in the Nimbus SDK. I hadn't thought of that before. I checked, and there is none. Ionics did include their kernel config file and their kernel patches, along with their patches to U-Boot and a small rootfs.
Thank you,
Larry Baker
Edited 2 time(s). Last edit at 10/28/2024 12:06PM by mossbeachlarry.
|
Re: Please add built-in kernel UBIFS support for Kirkwood boards October 28, 2024 03:21PM |
Admin Registered: 14 years ago Posts: 19,916 |
Larry,
> I build my own minimal Debian 12 rootfs for the
> internal UBIFS flash rootfs. I do not use
> an initrd. It works fine, like on a PC Linux
> box.
If any of your testing were done without uInitrd and failed to mount rootfs using partition label rootfs, then that test does not count. initrd is required when you use the partition LABEL option for root device.
> Besides shrinking the footprint using compressing
> kernel module files, which we already discussed, I
> also removed all the DEBUG options except those
> enabled in the default ARM Multi_V5 configuration
> That shrunk the kernel so the space penalty of
> adding UBIFS support went away. I encourage you
> to trim DEBUG options you no longer need in your
> upcoming 6.11.x release. I am looking forward to
> it. :)
The answer is no :) You've stripped out too many useful debug options by doing that. Debug configs should be selectively included. We are hacking Linux devices, a lot of times without documentation, certain debug options are very important for the process.
I don't have kernel size problem anymore with UBIFS configured in kernel 6.11.x and some other modules moved out to initrd. I also removed some insignicant DEBUG configs, but they did not make much difference, if at all.
> Finally, I recall reading a post requesting "Help
> flashing to a Sheevaplug NAND",
> https://forum.doozan.com/read.php?2,135980. I
> think that is how I found your forum. Would you
> like me to post my instructions for creating a
> minimal Debian 12 (bookworm) rootfs for the
> internal UBIFS flash rootfs, and my instructions
> for creating the UBIFS volume? In which main
> topic area? It sounded like the author gave up on
> his attempts to install Debian 12 and went to
> OpenWrt instead.
I do recommend using OpenWrt if people run their system entirely on flash. I don't recall if I did in that case.
> If his application is better
> suited to a more mainstream, flexible, and
> tailorable distribution, he may prefer Debian.
OpenWrt is a great mainstream distro for routers and true embedded devices. Debian is a server and/or desktop oriented distro. What we do here is providing a way to run old (i.e inexpensive) and low memory devices as Debian servers with latest Linux kernel.
> That is my preference for my SheevaPlugs and
> Nimbus.
To each his own! you are an experience Linux user so you can manage your own. But I always discourage people from all-flash solution if their boxes have low NAND capacity and trying to squeeze the rootfs into it. It's better to use OpenWrt if the goal is to use flash for rootfs.
> P.S. Ray was looking for a DTB in the Nimbus SDK.
> I hadn't thought of that before. I checked, and
> there is none. Ionics did include their kernel
> config file and their kernel patches, along with
> their patches to U-Boot and a small rootfs.
No, it is not possible that there is any DTB in Nimbus SDK. Its stock kernel is old, from way back. Flatten Device Tree did not exist back then.
So Ray can use my newly created DTS and add to that for the other Nimbus models.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
> I build my own minimal Debian 12 rootfs for the
> internal UBIFS flash rootfs. I do not use
> an initrd. It works fine, like on a PC Linux
> box.
If any of your testing were done without uInitrd and failed to mount rootfs using partition label rootfs, then that test does not count. initrd is required when you use the partition LABEL option for root device.
> Besides shrinking the footprint using compressing
> kernel module files, which we already discussed, I
> also removed all the DEBUG options except those
> enabled in the default ARM Multi_V5 configuration
> That shrunk the kernel so the space penalty of
> adding UBIFS support went away. I encourage you
> to trim DEBUG options you no longer need in your
> upcoming 6.11.x release. I am looking forward to
> it. :)
The answer is no :) You've stripped out too many useful debug options by doing that. Debug configs should be selectively included. We are hacking Linux devices, a lot of times without documentation, certain debug options are very important for the process.
I don't have kernel size problem anymore with UBIFS configured in kernel 6.11.x and some other modules moved out to initrd. I also removed some insignicant DEBUG configs, but they did not make much difference, if at all.
> Finally, I recall reading a post requesting "Help
> flashing to a Sheevaplug NAND",
> https://forum.doozan.com/read.php?2,135980. I
> think that is how I found your forum. Would you
> like me to post my instructions for creating a
> minimal Debian 12 (bookworm) rootfs for the
> internal UBIFS flash rootfs, and my instructions
> for creating the UBIFS volume? In which main
> topic area? It sounded like the author gave up on
> his attempts to install Debian 12 and went to
> OpenWrt instead.
I do recommend using OpenWrt if people run their system entirely on flash. I don't recall if I did in that case.
> If his application is better
> suited to a more mainstream, flexible, and
> tailorable distribution, he may prefer Debian.
OpenWrt is a great mainstream distro for routers and true embedded devices. Debian is a server and/or desktop oriented distro. What we do here is providing a way to run old (i.e inexpensive) and low memory devices as Debian servers with latest Linux kernel.
> That is my preference for my SheevaPlugs and
> Nimbus.
To each his own! you are an experience Linux user so you can manage your own. But I always discourage people from all-flash solution if their boxes have low NAND capacity and trying to squeeze the rootfs into it. It's better to use OpenWrt if the goal is to use flash for rootfs.
> P.S. Ray was looking for a DTB in the Nimbus SDK.
> I hadn't thought of that before. I checked, and
> there is none. Ionics did include their kernel
> config file and their kernel patches, along with
> their patches to U-Boot and a small rootfs.
No, it is not possible that there is any DTB in Nimbus SDK. Its stock kernel is old, from way back. Flatten Device Tree did not exist back then.
So Ray can use my newly created DTS and add to that for the other Nimbus models.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: Please add built-in kernel UBIFS support for Kirkwood boards October 28, 2024 03:52PM |
Registered: 1 year ago Posts: 61 |
bodhi,
Fair enough.
> initrd is required when you use the partition LABEL option for root device.
When booting from UBIFS flash rootfs, there is only one choice for root=ubi0:rootfs (or whatever you have named the MTD partition), so LABEL= is not really helpful.
> But I always discourage people from all-flash solution if their boxes have low NAND capacity and trying to squeeze the rootfs into it.
The alternative is to build a custom rootfs using debbootsdtrap and debuerreotype, as I do. I have over half the ~500 MB rootfs space available (since I compressed the kernel modules). I could have an even larger MTD "rootfs" partition by eliminating the "kernel" (unused, in my case) and "pluginfo" MTD partitions, but I have not needed to do that. (Nimbus includes flash recovery tools in their "pluginfo" partition.)
> OpenWrt is a great mainstream distro for routers and true embedded devices.
It is also a good out-of-the-box solution for people that don't care to build their own custom kernels and/or rootfs.
Thank you for all your help. Again, should you benefit from testing your upcoming 6.11.x kernel, I volunteer to help out.
Larry Baker
Fair enough.
> initrd is required when you use the partition LABEL option for root device.
When booting from UBIFS flash rootfs, there is only one choice for root=ubi0:rootfs (or whatever you have named the MTD partition), so LABEL= is not really helpful.
> But I always discourage people from all-flash solution if their boxes have low NAND capacity and trying to squeeze the rootfs into it.
The alternative is to build a custom rootfs using debbootsdtrap and debuerreotype, as I do. I have over half the ~500 MB rootfs space available (since I compressed the kernel modules). I could have an even larger MTD "rootfs" partition by eliminating the "kernel" (unused, in my case) and "pluginfo" MTD partitions, but I have not needed to do that. (Nimbus includes flash recovery tools in their "pluginfo" partition.)
> OpenWrt is a great mainstream distro for routers and true embedded devices.
It is also a good out-of-the-box solution for people that don't care to build their own custom kernels and/or rootfs.
Thank you for all your help. Again, should you benefit from testing your upcoming 6.11.x kernel, I volunteer to help out.
Larry Baker
|
Re: Please add built-in kernel UBIFS support for Kirkwood boards October 28, 2024 06:04PM |
Admin Registered: 14 years ago Posts: 19,916 |
Larry,
Perhaps there is a bug somewhere in the regulator code.
I meant when you boot with USB rootfs.
Sure, it will be next month, after Linux stable tree has a couple more releases. Thanks!
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Quote
2. uImage-nimbus on SheevaPlug also boots fine, which surprises me. Why didn't the difference in the USB Power GPIO Active Low/High setting cause problems?
Perhaps there is a bug somewhere in the regulator code.
Quote
> > initrd is required when you use the partition
> LABEL option for root device.
>
> When booting from UBIFS flash rootfs, there is
> only one choice for root=ubi0:rootfs (or whatever
> you have named the MTD partition), so LABEL= is
> not really helpful.
I meant when you boot with USB rootfs.
Quote
> Thank you for all your help. Again, should you
> benefit from testing your upcoming 6.11.x kernel,
> I volunteer to help out.
Sure, it will be next month, after Linux stable tree has a couple more releases. Thanks!
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: Please add built-in kernel UBIFS support for Kirkwood boards October 28, 2024 08:10PM |
Registered: 10 years ago Posts: 481 |
mossbeachlarry Wrote:
> P.S. Ray was looking for a DTB in the Nimbus SDK.
> I hadn't thought of that before. I checked, and
> there is none. Ionics did include their kernel
> config file and their kernel patches, along with
> their patches to U-Boot and a small rootfs.
>
I knew there would be no DTB as the source is too old. I was looking for the patches as that would potentially provide the information needed to create an appropriate device tree.
Ray
> P.S. Ray was looking for a DTB in the Nimbus SDK.
> I hadn't thought of that before. I checked, and
> there is none. Ionics did include their kernel
> config file and their kernel patches, along with
> their patches to U-Boot and a small rootfs.
>
I knew there would be no DTB as the source is too old. I was looking for the patches as that would potentially provide the information needed to create an appropriate device tree.
Ray
|
Re: Please add built-in kernel UBIFS support for Kirkwood boards October 28, 2024 08:25PM |
Registered: 1 year ago Posts: 61 |
Bodhi,
> Perhaps there is a bug somewhere in the regulator code.
Or that regulator code had not been fully implemented in the 6.0.x kernel. That status message about setting the USB Power active low does not appear until the 6.2 kernel.
I plan to use your 6.10.11 kernel until you come out with your 6.11.x kernel. I can see what happens pairing the 6.10.11 kernel with the wrong DTB. I have to clean up all the debris from the tests I have been making and straighten out the configuraton and documentation of the UBIFS rootfs I want to use for my application first.
> I meant when you boot with USB rootfs.
Of course. That is when it makes sense. The use case for a flash rootfs is to be as small as possible, i.e., avoid the extra space for a uInitrd.
What is your opinion about updating the Nimbus U-Boot? Is it worth it? E.g., for ext3/4 and other file system support?
As far as I can tell, there are only two significant differences between the SheevaPlug U-Boot code (unpatched 2011.03-rc1) and the Nimbus U-Boot code (2011.03-rc1 with Nimbus patches).
The first is the initialization of the USB Power in board/Marvell/sheevaplug/sheevaplug.c. It looks like all the GPIO pins are active low on the Nimbus. They also initialize both Output Enable registers to drive all the GPIO outputs. The SheevaPlug U-Boot tri-states all the GPIO outputs.
In board/Marvell/sheevaplug/sheevaplug.h:
Nimbus sets bits 9:11, Write recovery for auto-precharge, in the DDR Mode register to 3 instead of 6:
Nimbus is missing the CS[0]n Base address register. Since the default value is 0x0, this is harmless. Nevertheless, it is sloppy.
Nimbus incudes values for the L2 RAM Timing registers. They should probably not be there, since Linux complains when it sets up L2 cache:
That leaves the USB Power setting as the only significant difference. It looks like Linux 6.10.11 manages USB power correctly. The DTS file also says the USB power regulator should always be on and should be on at boot. That takes care of Linux.
What about U-Boot? What will happen in a more modern SheevaPlug U-Boot if at power up U-Boot does not enable USB Power on Nimbus? Would I still be able to read or boot a USB drive? I can't tell. I tried flipping the USB Power GPIO bit in the GPIO Data Out register in U-Boot, but I didn't notice it made any difference. I could still start USB and see the USB drive with usb info.
Would a more modern U-Boot with your kirkwood-nimbus.dtb appended set up USB Power active low? I have never dealt with DTBs when I have rebuilt U-Boot before. I don't know the process, and I don't know where the U-Boot DTBs come from. Are they full-flown Linux DTBs, or are they stripped down versions?
Or, would you recommend I leave well enough alone? That is a perfectly reasonable choice for me. I might lose the ability to boot an ext4 USB drive, but that is not of interest to me anyway.
Thank you,
Larry Baker
> Perhaps there is a bug somewhere in the regulator code.
Or that regulator code had not been fully implemented in the 6.0.x kernel. That status message about setting the USB Power active low does not appear until the 6.2 kernel.
I plan to use your 6.10.11 kernel until you come out with your 6.11.x kernel. I can see what happens pairing the 6.10.11 kernel with the wrong DTB. I have to clean up all the debris from the tests I have been making and straighten out the configuraton and documentation of the UBIFS rootfs I want to use for my application first.
> I meant when you boot with USB rootfs.
Of course. That is when it makes sense. The use case for a flash rootfs is to be as small as possible, i.e., avoid the extra space for a uInitrd.
What is your opinion about updating the Nimbus U-Boot? Is it worth it? E.g., for ext3/4 and other file system support?
As far as I can tell, there are only two significant differences between the SheevaPlug U-Boot code (unpatched 2011.03-rc1) and the Nimbus U-Boot code (2011.03-rc1 with Nimbus patches).
The first is the initialization of the USB Power in board/Marvell/sheevaplug/sheevaplug.c. It looks like all the GPIO pins are active low on the Nimbus. They also initialize both Output Enable registers to drive all the GPIO outputs. The SheevaPlug U-Boot tri-states all the GPIO outputs.
In board/Marvell/sheevaplug/sheevaplug.h:
#define SHEEVAPLUG_OE_LOW (~(0)) #define SHEEVAPLUG_OE_HIGH (~(0)) #define SHEEVAPLUG_OE_VAL_LOW (1 << 29) /* USB_PWEN low */ #define SHEEVAPLUG_OE_VAL_HIGH (1 << 17) /* LED pin high */and board/Marvell/sheevaplug/sheevaplug.c:
$ diff -u {SOURCE,PATCH}/u-boot-marvell/board/Marvell/sheevaplug/sheevaplug.c
--- SOURCE/u-boot-marvell/board/Marvell/sheevaplug/sheevaplug.c 2011-02-14 02:48:13
+++ PATCH/u-boot-marvell/board/Marvell/sheevaplug/sheevaplug.c 2024-10-25 12:48:04
@@ -37,10 +37,16 @@
* There are maximum 64 gpios controlled through 2 sets of registers
* the below configuration configures mainly initial LED status
*/
- kw_config_gpio(SHEEVAPLUG_OE_VAL_LOW,
- SHEEVAPLUG_OE_VAL_HIGH,
- SHEEVAPLUG_OE_LOW, SHEEVAPLUG_OE_HIGH);
+ //kw_config_gpio(SHEEVAPLUG_OE_VAL_LOW,
+ //SHEEVAPLUG_OE_VAL_HIGH,
+ //SHEEVAPLUG_OE_LOW, SHEEVAPLUG_OE_HIGH);
+ /* Initial GPIO configuration for IONICS board */
+ kw_config_gpio( 0xdfffffff,
+ 0xfffdffff,
+ 0x00000000,
+ 0x00000000 );
+
/* Multi-Purpose Pins Functionality configuration */
u32 kwmpp_config[] = {
MPP0_NF_IO2,
The second difference is in the memory configuration in board/Marvell/sheevaplug/kwbimage.cfg. I edited the Nimbus patched version to restore Marvell's comments, which makes it easier to find and understand the differences:
$ diff -u {SOURCE,PATCH}/u-boot-marvell/board/Marvell/sheevaplug/kwbimage.cfg
--- SOURCE/u-boot-marvell/board/Marvell/sheevaplug/kwbimage.cfg 2011-02-14 02:48:13
+++ PATCH/u-boot-marvell/board/Marvell/sheevaplug/kwbimage.cfg 2024-10-25 13:06:56
@@ -37,9 +37,9 @@
DATA 0xFFD100e0 0x1b1b1b9b
#Dram initalization for SINGLE x16 CL=5 @ 400MHz
-DATA 0xFFD01400 0x43000c30 # DDR Configuration register
+DATA 0xFFD01400 0x43010c30 # DDR Configuration register
# bit13-0: 0xc30 (3120 DDR2 clks refresh rate)
-# bit23-14: zero
+# bit23-14: zero >>> Bit 16 is SET <<<
# bit24: 1= enable exit self refresh mode on DDR access
# bit25: 1 required
# bit29-26: zero
@@ -97,13 +97,13 @@
# bit3-0: 0x0, DDR cmd
# bit31-4: 0 required
-DATA 0xFFD0141C 0x00000C52 # DDR Mode
+DATA 0xFFD0141C 0x00000652 # DDR Mode
# bit2-0: 2, BurstLen=2 required
# bit3: 0, BurstType=0 required
# bit6-4: 4, CL=5
# bit7: 0, TestMode=0 normal
# bit8: 0, DLL reset=0 normal
-# bit11-9: 6, auto-precharge write recovery ????????????
+# bit11-9: 6, auto-precharge write recovery ???????????? >>> Bit 11 is CLEAR, bit 9 is SET <<<
# bit12: 0, PD must be zero
# bit31-13: 0 required
@@ -134,7 +134,7 @@
DATA 0xFFD01428 0x00085520 # DDR2 ODT Read Timing (default values)
DATA 0xFFD0147C 0x00008552 # DDR2 ODT Write Timing (default values)
-DATA 0xFFD01500 0x00000000 # CS[0]n Base address to 0x0
+#DATA 0xFFD01500 0x00000000 # CS[0]n Base address to 0x0 >>> MISSING <<<
DATA 0xFFD01504 0x0FFFFFF1 # CS[0]n Size
# bit0: 1, Window enabled
# bit1: 0, Write Protect disabled
@@ -158,5 +158,8 @@
DATA 0xFFD01480 0x00000001 # DDR Initialization Control
#bit0=1, enable DDR init upon this register write
+DATA 0xFFD20134 0x66666666 # >>> NEW L2 RAM Timing 0 Register <<<
+DATA 0xFFD20138 0x66666666 # >>> NEW L2 RAM Timing 1 Register<<<
+
# End of Header extension
DATA 0x0 0x0
Nimbus sets bit 16 in the DDR Configuration register:
0 = To Store: Write buffer configure to store & forward mode 1 = To Cut: Write buffer configure to cut through modeWhile cut through mode may have a subtle affect on performance, I don't think changing the setting to store & forward mode will cause any incorrect behavior.
Nimbus sets bits 9:11, Write recovery for auto-precharge, in the DDR Mode register to 3 instead of 6:
Write recovery for auto-precharge NOTE: This device does not support auto-precharge. Must be 0x3.According to the manual, 3 is actually the correct value.
Nimbus is missing the CS[0]n Base address register. Since the default value is 0x0, this is harmless. Nevertheless, it is sloppy.
Nimbus incudes values for the L2 RAM Timing registers. They should probably not be there, since Linux complains when it sets up L2 cache:
[Firmware Bug]: Feroceon L2: bootloader left the L2 cache on!It looks to me like the custom Nimbus memory configuration settings are not necessary.
That leaves the USB Power setting as the only significant difference. It looks like Linux 6.10.11 manages USB power correctly. The DTS file also says the USB power regulator should always be on and should be on at boot. That takes care of Linux.
What about U-Boot? What will happen in a more modern SheevaPlug U-Boot if at power up U-Boot does not enable USB Power on Nimbus? Would I still be able to read or boot a USB drive? I can't tell. I tried flipping the USB Power GPIO bit in the GPIO Data Out register in U-Boot, but I didn't notice it made any difference. I could still start USB and see the USB drive with usb info.
Would a more modern U-Boot with your kirkwood-nimbus.dtb appended set up USB Power active low? I have never dealt with DTBs when I have rebuilt U-Boot before. I don't know the process, and I don't know where the U-Boot DTBs come from. Are they full-flown Linux DTBs, or are they stripped down versions?
Or, would you recommend I leave well enough alone? That is a perfectly reasonable choice for me. I might lose the ability to boot an ext4 USB drive, but that is not of interest to me anyway.
Thank you,
Larry Baker
|
Re: Please add built-in kernel UBIFS support for Kirkwood boards October 28, 2024 08:40PM |
Registered: 1 year ago Posts: 61 |
Ray,
> I knew there would be no DTB as the source is too old. I was looking for the patches as
> that would potentially provide the information needed to create an appropriate device tree.
bodhi has taken care of that for us. It seems to be working well for the newer Linux kernels that are more actively managing USB power. The Nimbus GPIO data output are all active low, so he changed the USB Power and the two LED definitions from active high to active low.
See his https://forum.doozan.com/read.php?2,138142,138266#msg-138266 post. He attached both a kirkwood-nimbus.dtb and dts.
Cheers,
Larry Baker
> I knew there would be no DTB as the source is too old. I was looking for the patches as
> that would potentially provide the information needed to create an appropriate device tree.
bodhi has taken care of that for us. It seems to be working well for the newer Linux kernels that are more actively managing USB power. The Nimbus GPIO data output are all active low, so he changed the USB Power and the two LED definitions from active high to active low.
See his https://forum.doozan.com/read.php?2,138142,138266#msg-138266 post. He attached both a kirkwood-nimbus.dtb and dts.
Cheers,
Larry Baker
|
Re: Please add built-in kernel UBIFS support for Kirkwood boards October 28, 2024 09:31PM |
Registered: 1 year ago Posts: 61 |
Ray,
By the way, if you don't already have a copy of Marvell's 88F6180, 88F6190, 88F6192, and 88F6281 Integrated Controller Functional Specifications, you can download it from the Internet Way-Back machine at https://web.archive.org/web/20140327024228/http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf.
Regards,
Larry Baker
By the way, if you don't already have a copy of Marvell's 88F6180, 88F6190, 88F6192, and 88F6281 Integrated Controller Functional Specifications, you can download it from the Internet Way-Back machine at https://web.archive.org/web/20140327024228/http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf.
Regards,
Larry Baker
|
Re: Please add built-in kernel UBIFS support for Kirkwood boards October 28, 2024 10:44PM |
Admin Registered: 14 years ago Posts: 19,916 |
Larry,
> > Perhaps there is a bug somewhere in the
> regulator code.
>
> Or that regulator code had not been fully
> implemented in the 6.0.x kernel. That status
> message about setting the USB Power active low
> does not appear until the 6.2 kernel.
That was just more information spitting out by the regulator driver. Regulator is quite old so I would not say it's lacking something. The behavior seems to be a bug. The info message might be added when they fixed a real bug.
I have not looked at the regulator code and comparing versions. But I can smell a bug there :) I could explain my theory if anyone is curious.
However, it's really academic by now that we knew how that part of the Nimbus 100 was implemented, and adjust the DTS accordingly.
> What is your opinion about updating the Nimbus
> U-Boot? Is it worth it? E.g., for ext3/4 and
> other file system support?
There are things that old u-boot cannot do, such as reading Ext4. But that's not really important to your purpose. Ext4 is supported in Linux after booted.
> + /* Initial GPIO configuration for IONICS
> board */
> + kw_config_gpio( 0xdfffffff,
> + 0xfffdffff,
> + 0x00000000,
> + 0x00000000 );
> +
We saw this in the patch. Sloppy. The right thing to do is to code it in the right place here
> It looks to me like the custom Nimbus memory
> configuration settings are not necessary.
Correct.
> Would a more modern U-Boot with your
> kirkwood-nimbus.dtb appended set up USB Power
> active low? I have never dealt with DTBs when I
> have rebuilt U-Boot before. I don't know the
> process, and I don't know where the U-Boot DTBs
> come from. Are they full-flown Linux DTBs, or are
> they stripped down versions?
>
> Or, would you recommend I leave well enough alone?
I think it is good for now.
> That is a perfectly reasonable choice for me. I
> might lose the ability to boot an ext4 USB drive,
> but that is not of interest to me anyway.
We'll cross that bridge when you have to have Ext4 and large HDD > 2TB (in USB enclosure).
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Edited 1 time(s). Last edit at 10/28/2024 10:46PM by bodhi.
> > Perhaps there is a bug somewhere in the
> regulator code.
>
> Or that regulator code had not been fully
> implemented in the 6.0.x kernel. That status
> message about setting the USB Power active low
> does not appear until the 6.2 kernel.
That was just more information spitting out by the regulator driver. Regulator is quite old so I would not say it's lacking something. The behavior seems to be a bug. The info message might be added when they fixed a real bug.
I have not looked at the regulator code and comparing versions. But I can smell a bug there :) I could explain my theory if anyone is curious.
However, it's really academic by now that we knew how that part of the Nimbus 100 was implemented, and adjust the DTS accordingly.
> What is your opinion about updating the Nimbus
> U-Boot? Is it worth it? E.g., for ext3/4 and
> other file system support?
There are things that old u-boot cannot do, such as reading Ext4. But that's not really important to your purpose. Ext4 is supported in Linux after booted.
> + /* Initial GPIO configuration for IONICS
> board */
> + kw_config_gpio( 0xdfffffff,
> + 0xfffdffff,
> + 0x00000000,
> + 0x00000000 );
> +
We saw this in the patch. Sloppy. The right thing to do is to code it in the right place here
> #define SHEEVAPLUG_OE_LOW (~(0)) > #define SHEEVAPLUG_OE_HIGH (~(0)) > #define SHEEVAPLUG_OE_VAL_LOW (1 << 29) /* > USB_PWEN low */ > #define SHEEVAPLUG_OE_VAL_HIGH (1 << 17) /* LED > pin high */
> It looks to me like the custom Nimbus memory
> configuration settings are not necessary.
Correct.
> Would a more modern U-Boot with your
> kirkwood-nimbus.dtb appended set up USB Power
> active low? I have never dealt with DTBs when I
> have rebuilt U-Boot before. I don't know the
> process, and I don't know where the U-Boot DTBs
> come from. Are they full-flown Linux DTBs, or are
> they stripped down versions?
>
> Or, would you recommend I leave well enough alone?
I think it is good for now.
> That is a perfectly reasonable choice for me. I
> might lose the ability to boot an ext4 USB drive,
> but that is not of interest to me anyway.
We'll cross that bridge when you have to have Ext4 and large HDD > 2TB (in USB enclosure).
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Edited 1 time(s). Last edit at 10/28/2024 10:46PM by bodhi.
|
Re: Please add built-in kernel UBIFS support for Kirkwood boards October 29, 2024 12:10AM |
Registered: 1 year ago Posts: 61 |
bodhi,
I have created a Debian 12 Nimbus installer uImage using your Nimbus 100 DTB and hacked the Debian installer to support the Nimbus 100. Here are my notes.
(I have attached a PDF of my own installation documentation that is specific to my application and includes my customizations to create a basic Linux system ready for the installation of my application, esp. to install ntp for timekeeping.)
Install Debian 12 Kirkwood ARMEL Linux on a Nimbus 100
The Ionics Nimbus 100 is a repackaged version of the Marvell SheevaPlug. Until Debian 12, Debian SheevaPlug installers could install Linux on a Nimbus 100. Unfortunately, as of Debian 12, that is no longer the case. To install Debian 12 on a Nimbus 100, we must modify the Debian 12 SheevaPlug installer to support the Nimbus 100.
The Debian 12 “bookworm” SheevaPlug installer does not enumerate the USB installation drive on a Nimbus 100, whereas the Debian 11 “bullseye” SheevaPlug installer does. This is because of changes in Linux in the management of USB power between Debian 11 and Debian 12.
While the Nimbus 100 is a SheevaPlug clone, it is not precisely the same. One difference is the GPIO outputs are inverted. Thus, on a SheevaPlug, the GPIO USB Power pin is “active high”. On a Nimbus, it is “active low”. As a result of changes to the USB power management in the Linux kernel beginning with version 5.15, USB devices no longer function on a Nimbus that is running a Linux kernel bound to the SheevaPlug DTB. (And there are no alternatives.) Debian 11 uses a Linux 5.10 kernel; Debian 12 uses a Linux 6.1 kernel.
SheevaPlug and Nimbus boot from a Linux kernel uImage, which is a bundle of a compressed Linux kernel binary with a Device Tree Blob (DTB) that describes the hardware. Debian SheevaPlug installers bundle the SheevaPlug DTB. The SheevaPlug DTB defines its GPIO USB Power pin as “active high”. This is the reverse of the GPIO USB Power pin polarity on a Nimbus. As a result, a Nimbus fails to energize the USB port, thus preventing the recognition of any USB devices. (See Debian on Ionics Nimbus 100 for a discussion of the topic.)
To install Debian 12 on a Nimbus, we need a Debian 12 installer that bundles the Nimbus 100 DTB. Luckily, a Nimbus DTB file has been written by “bodhi”, a Linux embedded systems expert at the Linux Device Hacking forum.
Create a Debian 12 “bookworm” Nimbus 100 Installer
Login to a suitable account on a Linux PC. (I use the root account because I create files in /opt.)
I use minicom to connect to the Nimbus 100 USB console port. Configure the serial port (Serial port setup), /dev/ttyUSB0, for 115200 baud, 8 data bits, no parity, 1 stop bit, and no flow control.
You will need to install minicom, wget, and uboot-tools (for mkimage).
Download the Nimbus 100 DTB file from https://forum.doozan.com:
Plug the USB drive with the Debian 12 Nimbus 100 installer into the Nimbus.
Connect the USB console cable to the Nimbus and power it on.
Run minicom.
Power up the Nimbus and interrupt the boot loader (Hit any key to stop autoboot:):
Start The Installation
Continue the minicom Nimbus console session from above.
Plug a USB drive for the installation into the Nimbus.
Plug the Nimbus Ethernet port into an Internet router with DHCP support.
Start the installer:
Because the Debian 12 SheevaPlug installer’s archdetect program does not recognize the Nimbus 100, it returns armel/generic for the architecture. The architecture should be kirkwood, the family name of the SoC CPU chip used in a SheevaPlug and a Nimbus 100. Because of that, the installer fails to find a suitable kernel.
As a workaround, create a replacement for the installer’s archdetect program that always returns kirkwood.
Type <CTRL-A> <CTRL-A> 2 from minicom to switch to console 2 when the Debian installer screen appears.
Replace the Debian 12 archdetect program with a shell script that always returns kirkwood:
Proceed with the Installation
To monitor the progress of the installation, switch to console 4 from minicom by typing <CTRL-A> <CTRL-A> 4. The installation session is on console 1. Consoles 2 and 3 are BusyBox shell sessions.
Select the Debian options you want for your system.
If the installer fails to find a suitable kernel, proceed with the installation, but do not exit the installer when the installation is complete. This should not happen with the workaround described above in place.
When the Installation complete window appears, do not Continue to reboot.
If necessary, continue to the next section to install the Linux kernel. Otherwise, proceed to the following section to prepare the Linux kernel U-Boot boot loader files.
Manually Install the Linux Kernel if the Installer Fails to Find a Suitable Kernel
Follow these instructions if the installer fails to find a suitable kernel.
This should not happen with the workaround described above in place.
Enter <CTRL-A> <CTRL-A> 2 from minicom to switch to console 2.
chroot to the target root volume and install the linux-image-marvell kernel:
Manually Prepare the Linux Kernel U-Boot Boot Loader Files
Preparation of the Linux kernel uImage and uInitrd U-Boot boot loader files is performed by the Debian 12 installer flash-kernel script. As was the case for the archdetect program, the stock flash-kernel script does not recognize the Nimbus 100 and exits. The dpkg log in console 4 displays the message “Unsupported platform 'Ionics Nimbus 100'.”
Unlike the archdetect program, that had to be replaced above, the flash-kernel script has provisions to add support for additional platforms. The changes made here will enable flash-kernel to support Nimbus 100 for the installation as well as for future Linux kernel updates.
Enter <CTRL-A> <CTRL-A> 2 from minicom to switch to console 2.
Download the Nimbus 100 DTB file from https://forum.doozan.com: to the target /etc/flash-kernel/dtbs/ directory:
With these entries, flash-kernel will only create uImage and uInitrd; flash-kernel will not attempt to copy uImage to an MTD flash partition.
Finish the Installation
Select Continue to finish the installation and reboot the Nimbus.
Interrupt the boot loader when the Nimbus restarts (Hit any key to stop autoboot:):
Resume the minicom session on the Nimbus console.
Configure U-Boot to boot the Debian 12 rootfs on the USB drive (an ext2 file system labeled COMLOGGER in my case):
QED
That's it! You can login and customize your installation. Every time you power up or reset your Nimbus, it will boot the Debian 12 USB rootfs.
Postscript:
Define the MTD Flash Partitions in the U-Boot Linux Boot Command
There is no partition map for the MTD flash partitions; they must be properly defined for the Linux kernel from the U-Boot configuration.
The U-Boot mtdparts variable must be defined with the MTD partitions map:
Add the cmdlinepart.mtdparts kernel boot option to the U-Boot Linux boot command:
Larry Baker
==========
Major edits from the first edition of this post to add the changes required to support the Nimbus 100 in the Debian 12 installer.
Edited 3 time(s). Last edit at 11/01/2024 07:52PM by mossbeachlarry.
I have created a Debian 12 Nimbus installer uImage using your Nimbus 100 DTB and hacked the Debian installer to support the Nimbus 100. Here are my notes.
(I have attached a PDF of my own installation documentation that is specific to my application and includes my customizations to create a basic Linux system ready for the installation of my application, esp. to install ntp for timekeeping.)
Install Debian 12 Kirkwood ARMEL Linux on a Nimbus 100
The Ionics Nimbus 100 is a repackaged version of the Marvell SheevaPlug. Until Debian 12, Debian SheevaPlug installers could install Linux on a Nimbus 100. Unfortunately, as of Debian 12, that is no longer the case. To install Debian 12 on a Nimbus 100, we must modify the Debian 12 SheevaPlug installer to support the Nimbus 100.
The Debian 12 “bookworm” SheevaPlug installer does not enumerate the USB installation drive on a Nimbus 100, whereas the Debian 11 “bullseye” SheevaPlug installer does. This is because of changes in Linux in the management of USB power between Debian 11 and Debian 12.
While the Nimbus 100 is a SheevaPlug clone, it is not precisely the same. One difference is the GPIO outputs are inverted. Thus, on a SheevaPlug, the GPIO USB Power pin is “active high”. On a Nimbus, it is “active low”. As a result of changes to the USB power management in the Linux kernel beginning with version 5.15, USB devices no longer function on a Nimbus that is running a Linux kernel bound to the SheevaPlug DTB. (And there are no alternatives.) Debian 11 uses a Linux 5.10 kernel; Debian 12 uses a Linux 6.1 kernel.
SheevaPlug and Nimbus boot from a Linux kernel uImage, which is a bundle of a compressed Linux kernel binary with a Device Tree Blob (DTB) that describes the hardware. Debian SheevaPlug installers bundle the SheevaPlug DTB. The SheevaPlug DTB defines its GPIO USB Power pin as “active high”. This is the reverse of the GPIO USB Power pin polarity on a Nimbus. As a result, a Nimbus fails to energize the USB port, thus preventing the recognition of any USB devices. (See Debian on Ionics Nimbus 100 for a discussion of the topic.)
To install Debian 12 on a Nimbus, we need a Debian 12 installer that bundles the Nimbus 100 DTB. Luckily, a Nimbus DTB file has been written by “bodhi”, a Linux embedded systems expert at the Linux Device Hacking forum.
Create a Debian 12 “bookworm” Nimbus 100 Installer
Login to a suitable account on a Linux PC. (I use the root account because I create files in /opt.)
I use minicom to connect to the Nimbus 100 USB console port. Configure the serial port (Serial port setup), /dev/ttyUSB0, for 115200 baud, 8 data bits, no parity, 1 stop bit, and no flow control.
You will need to install minicom, wget, and uboot-tools (for mkimage).
Download the Nimbus 100 DTB file from https://forum.doozan.com:
# mkdir -p /opt/nimbus/bookworm-installers # cd /opt/nimbus/bookworm-installers # wget -O kirkwood-nimbus-100.dtb https://forum.doozan.com/file.php?2,file=7040,filename=kirkwood-nimbus-100.dtbDownload the Debian 12 SheevaPlug installer uImage and uInitrd from http://ftp.debian.org:
# wget -O uImage-6.1.0-25-debian http://ftp.debian.org/debian/dists/bookworm/main/installer-armel/current/images/kirkwood/netboot/marvell/sheevaplug/uImage # wget -O uInitrd-6.1.0-25-debian http://ftp.debian.org/debian/dists/bookworm/main/installer-armel/current/images/kirkwood/netboot/marvell/sheevaplug/uInitrdDownload the Debian 12 compressed Linux kernel binary from http://ftp.debian.org:
# wget http://ftp.debian.org/debian/dists/bookworm/main/installer-armel/current/images/kirkwood/netboot/vmlinuz-6.1.0-25-marvellCombine the Debian compressed Linux kernel binary with the Nimbus 100 DTB file to create a U-Boot uImage to install Debian 12 on a Nimbus 100:
# KERNEL=6.1.0-25-nimbus
# IMAGE=vmlinuz-6.1.0-25-marvell
# NAME="kernel ${KERNEL}"
# cat ${IMAGE} kirkwood-nimbus-100.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.1.0-25-nimbus
Created: Tue Oct 29 17:49:09 2024
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2638969 Bytes = 2577.12 KiB = 2.52 MiB
Load Address: 00008000
Entry Point: 00008000
# rm zImage.fdt
Copy the uImage and uInitrd files to a USB drive formatted with the FAT16 filesystem (e.g., /dev/sdc1):
# mount /dev/sdc1 /mnt/sdc1
# cp uImage-6.1.0-25-{debian,sheevaplug,nimbus} /mnt/sdc1/
# cp uInitrd-6.1.0-25-debian /mnt/sdc1/
# umount /mnt/sdc1
Remove the USB drive from the Linux PC.
Plug the USB drive with the Debian 12 Nimbus 100 installer into the Nimbus.
Connect the USB console cable to the Nimbus and power it on.
Run minicom.
Power up the Nimbus and interrupt the boot loader (Hit any key to stop autoboot:):
Hit any key to stop autoboot: 0 Marvell>>Load the Debian 12 “bookworm” Nimbus 100 installer into RAM:
Marvell>> usb start Marvell>> fatload usb 0:1 0x00800000 uImage-6.1.0-25-nimbus reading uImage-6.1.0-25-nimbus 2639033 bytes read Marvell>> fatload usb 0:1 0x01100000 uInitrd-6.1.0-25-debian reading uInitrd-6.1.0-25-debian 12219305 bytes read Marvell>> usb stopUnplug the USB drive from the Nimbus.
Start The Installation
Continue the minicom Nimbus console session from above.
Plug a USB drive for the installation into the Nimbus.
Plug the Nimbus Ethernet port into an Internet router with DHCP support.
Start the installer:
Marvell>> setenv bootargs console=ttyS0,115200n8 base-installer/initramfs-tools/driver-policy=most Marvell>> bootm 0x00800000 0x01100000 Marvell>> setenv bootargs console=ttyS0,115200n8 base-installer/initramfs-tools/driver-policy=most Marvell>> bootm 0x00800000 0x01100000 ## Booting kernel from Legacy Image at 00800000 ... Image Name: kernel 6.1.0-25-nimbus Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 2638969 Bytes = 2.5 MiB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 01100000 ... Image Name: debian-installer ramdisk Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 12219241 Bytes = 11.7 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 6.1.0-25-marvell (debian-kernel@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils) [ 0.000000] CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=0005397f [ 0.000000] CPU: VIVT data cache, VIVT instruction cache [ 0.000000] OF: fdt: Machine model: Ionics Nimbus 100 <snip>Interrupt the Installation to Replace the Installer’s archdetect Program
Because the Debian 12 SheevaPlug installer’s archdetect program does not recognize the Nimbus 100, it returns armel/generic for the architecture. The architecture should be kirkwood, the family name of the SoC CPU chip used in a SheevaPlug and a Nimbus 100. Because of that, the installer fails to find a suitable kernel.
As a workaround, create a replacement for the installer’s archdetect program that always returns kirkwood.
Type <CTRL-A> <CTRL-A> 2 from minicom to switch to console 2 when the Debian installer screen appears.
Replace the Debian 12 archdetect program with a shell script that always returns kirkwood:
~ # archdetect armel/generic ~ # echo -e "#!/bin/sh\necho kirkwood" > /bin/archdetect ~ # archdetect kirkwoodType <CTRL-A> <CTRL-A> 1 from minicom to return to the installation console and proceed with the installation.
Proceed with the Installation
To monitor the progress of the installation, switch to console 4 from minicom by typing <CTRL-A> <CTRL-A> 4. The installation session is on console 1. Consoles 2 and 3 are BusyBox shell sessions.
Select the Debian options you want for your system.
If the installer fails to find a suitable kernel, proceed with the installation, but do not exit the installer when the installation is complete. This should not happen with the workaround described above in place.
When the Installation complete window appears, do not Continue to reboot.
If necessary, continue to the next section to install the Linux kernel. Otherwise, proceed to the following section to prepare the Linux kernel U-Boot boot loader files.
Manually Install the Linux Kernel if the Installer Fails to Find a Suitable Kernel
Follow these instructions if the installer fails to find a suitable kernel.
This should not happen with the workaround described above in place.
Enter <CTRL-A> <CTRL-A> 2 from minicom to switch to console 2.
chroot to the target root volume and install the linux-image-marvell kernel:
~ # ls /target/boot ~ # chroot /target apt install linux-image-marvell ~ # ls /target/boot -rw-r--r-- 1 root root 83 Sep 30 19:08 System.map-6.1.0-26-marvell -rw-r--r-- 1 root root 202.2K Sep 30 19:08 config-6.1.0-26-marvell -rw-r--r-- 1 root root 16.3M Oct 29 19:07 initrd.img-6.1.0-26-marvell -rw-r--r-- 1 root root 2.5M Sep 30 19:08 vmlinuz-6.1.0-26-marvellContinue to the next section to prepare the U-Boot uImage and uInitrd files.
Manually Prepare the Linux Kernel U-Boot Boot Loader Files
Preparation of the Linux kernel uImage and uInitrd U-Boot boot loader files is performed by the Debian 12 installer flash-kernel script. As was the case for the archdetect program, the stock flash-kernel script does not recognize the Nimbus 100 and exits. The dpkg log in console 4 displays the message “Unsupported platform 'Ionics Nimbus 100'.”
Unlike the archdetect program, that had to be replaced above, the flash-kernel script has provisions to add support for additional platforms. The changes made here will enable flash-kernel to support Nimbus 100 for the installation as well as for future Linux kernel updates.
Enter <CTRL-A> <CTRL-A> 2 from minicom to switch to console 2.
~ # ls -lh /target/boot -rw-r--r-- 1 root root 83 Aug 26 19:47 System.map-6.1.0-25-marvell -rw-r--r-- 1 root root 83 Sep 30 19:08 System.map-6.1.0-26-marvell -rw-r--r-- 1 root root 202.2K Aug 26 19:47 config-6.1.0-25-marvell -rw-r--r-- 1 root root 202.2K Sep 30 19:08 config-6.1.0-26-marvell lrwxrwxrwx 1 root root 27 Nov 1 03:14 initrd.img -> initrd.img-6.1.0-26-marvell -rw-r--r-- 1 root root 16.3M Nov 1 03:07 initrd.img-6.1.0-25-marvell -rw-r--r-- 1 root root 16.3M Nov 1 03:17 initrd.img-6.1.0-26-marvell lrwxrwxrwx 1 root root 27 Nov 1 03:01 initrd.img.old -> initrd.img-6.1.0-25-marvell lrwxrwxrwx 1 root root 24 Nov 1 03:14 vmlinuz -> vmlinuz-6.1.0-26-marvell -rw-r--r-- 1 root root 2.5M Aug 26 19:47 vmlinuz-6.1.0-25-marvell -rw-r--r-- 1 root root 2.5M Sep 30 19:08 vmlinuz-6.1.0-26-marvell lrwxrwxrwx 1 root root 24 Nov 1 03:01 vmlinuz.old -> vmlinuz-6.1.0-25-marvellchroot to the target root volume and install the flash-kernel package (needs /proc and /sys):
~ # mount --bind /proc /target/proc ~ # mount --bind /sys /target/sys ~ # chroot /target apt install flash-kernelIgnore the message “Unsupported platform 'Ionics Nimbus 100'.”
Download the Nimbus 100 DTB file from https://forum.doozan.com: to the target /etc/flash-kernel/dtbs/ directory:
~ # wget -O /target/etc/flash-kernel/dtbs/kirkwood-nimbus-100.dtb https://forum.doozan.com/file.php?2,file=7040,filename=kirkwood-nimbus-100.dtbAppend the information flash-kernel needs to create the Linux kernel uImage and uInitrd files for a Nimbus 100 to the target /etc/flash-kernel/db file:
With these entries, flash-kernel will only create uImage and uInitrd; flash-kernel will not attempt to copy uImage to an MTD flash partition.
~ # cat >> /target/etc/flash-kernel/db << 'EOF' Machine: Ionics Nimbus 100 Kernel-Flavors: kirkwood marvell DTB-Id: kirkwood-nimbus-100.dtb DTB-Append-From: 3.12 U-Boot-Kernel-Address: 0x00008000 U-Boot-Initrd-Address: 0x0 Boot-Kernel-Path: /boot/uImage Boot-Initrd-Path: /boot/uInitrd Boot-DTB-Path: /boot/dtb Required-Packages: u-boot-tools EOFchroot to the target root volume and re-run the installation of flash-kernel, which will re-run the failed initramfs-tools trigger, then re-run flash-kernel, which will successfully create the uImage and uInitrd files for a Nimbus 100 this time:
~ # chroot /target apt -y install flash-kernel <snip> Using DTB: kirkwood-nimbus-100.dtb Installing /etc/flash-kernel/dtbs/kirkwood-nimbus-100.dtb into /boot/dtbs/6.1.0-26-marvell/./kirkwood-nimbus-100.dtb Installing new kirkwood-nimbus-100.dtb. Installing /etc/flash-kernel/dtbs/kirkwood-nimbus-100.dtb into /boot/dtbs/6.1.0-26-marvell/./kirkwood-nimbus-100.dtb Taking backup of kirkwood-nimbus-100.dtb. Installing new kirkwood-nimbus-100.dtb. flash-kernel: installing version 6.1.0-26-marvell flash-kernel: appending /etc/flash-kernel/dtbs/kirkwood-nimbus-100.dtb to kernel Generating kernel u-boot image... done. Installing new uImage. Generating initramfs u-boot image... done. Installing new uInitrd. Taking backup of dtb. Installing new dtb.
~ # ls -lh /target/boot -rw-r--r-- 1 root root 83 Aug 26 19:47 System.map-6.1.0-25-marvell -rw-r--r-- 1 root root 83 Sep 30 19:08 System.map-6.1.0-26-marvell -rw-r--r-- 1 root root 202.2K Aug 26 19:47 config-6.1.0-25-marvell -rw-r--r-- 1 root root 202.2K Sep 30 19:08 config-6.1.0-26-marvell -rw-r--r-- 1 root root 10.1K Nov 1 04:40 dtb lrwxrwxrwx 1 root root 47 Nov 1 04:40 dtb-6.1.0-26-marvell -> dtbs/6.1.0-26-marvell/./kirkwood-nimbus-100.dtb lrwxrwxrwx 1 root root 47 Nov 1 04:40 dtb.bak -> dtbs/6.1.0-26-marvell/./kirkwood-nimbus-100.dtb drwxr-xr-x 3 root root 4.0K Nov 1 04:40 dtbs lrwxrwxrwx 1 root root 27 Nov 1 04:35 initrd.img -> initrd.img-6.1.0-26-marvell -rw-r--r-- 1 root root 16.3M Nov 1 03:07 initrd.img-6.1.0-25-marvell -rw-r--r-- 1 root root 16.3M Nov 1 04:38 initrd.img-6.1.0-26-marvell -rw-r--r-- 1 root root 16.3M Nov 1 03:17 initrd.img-6.1.0-26-marvell.dpkg-bak lrwxrwxrwx 1 root root 27 Nov 1 04:35 initrd.img.old -> initrd.img-6.1.0-25-marvell -rw-r--r-- 1 root root 2.5M Nov 1 04:40 uImage -rw-r--r-- 1 root root 16.3M Nov 1 04:40 uInitrd lrwxrwxrwx 1 root root 24 Nov 1 04:35 vmlinuz -> vmlinuz-6.1.0-26-marvell -rw-r--r-- 1 root root 2.5M Aug 26 19:47 vmlinuz-6.1.0-25-marvell -rw-r--r-- 1 root root 2.5M Sep 30 19:08 vmlinuz-6.1.0-26-marvell lrwxrwxrwx 1 root root 24 Nov 1 04:35 vmlinuz.old -> vmlinuz-6.1.0-25-marvellEnter <CTRL-A> <CTRL-A> 1 from minicom to return to the installation console.
Finish the Installation
Select Continue to finish the installation and reboot the Nimbus.
Interrupt the boot loader when the Nimbus restarts (Hit any key to stop autoboot:):
Hit any key to stop autoboot: 0 Marvell>>Boot Debian 12 on the Nimbus 100
Resume the minicom session on the Nimbus console.
Configure U-Boot to boot the Debian 12 rootfs on the USB drive (an ext2 file system labeled COMLOGGER in my case):
Marvell>> setenv bootargs_console console=ttyS0,115200 Marvell>> setenv bootcmd_usb 'usb start; ext2load usb 0:1 0x00800000 /boot/uImage; ext2load usb 0:1 0x01100000 /boot/uInitrd' Marvell>> setenv set_usb_bootargs 'setenv bootargs $(bootargs_console) rootfstype=ext2 root=LABEL=COMLOGGER rw' Marvell>> setenv usb_boot 'init_ionics mode bootup; run bootcmd_usb; run set_usb_bootargs; bootm 0x00800000 0x01100000' Marvell>> setenv usb_bootcmd 'setenv bootcmd $(usb_boot); saveenv' Marvell>> run usb_bootcmd Saving Environment to NAND… Erasing Nand… Erasing at 0x60000 – 100% complete. Writing to Nand… doneReset the Nimbus to boot Debian 12:
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
(Re)start USB…
USB: Register 10011 NbrPorts 1
USB EHCI 1.00
scanning bus for devices… 3 USB Device(s) found
scanning bus for storage devices… 1 Storage Device(s) found
Loading file “/boot/uImage” from usb device 0:1 (usbda1)
2641321 bytes read
Loading file “/boot/uInitrd” from usb device 0:1 (usbda1)
17112203 bytes read
## Booting kernel from Legacy Image at 00800000 …
Image Name: kernel 6.1.0-26-marvell
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2641257 Bytes = 2.5 MiB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum … OK
## Loading init Ramdisk from Legacy Image at 01100000 …
Image Name: ramdisk 6.1.0-26-marvell
Image Type: ARM Linux RAMDisk Image (uncompressed)
Data Size: 17112139 Bytes = 16.3 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum … OK
Loading Kernel Image … OK
OK
Starting kernel …
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 6.1.0-26-marvell (debian-kernel@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binut)
[ 0.000000] CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=0005397f
[ 0.000000] CPU: VIVT data cache, VIVT instruction cache
[ 0.000000] OF: fdt: Machine model: Ionics Nimbus 100
<snip>
Welcome to Debian GNU/Linux 12 (bookworm)!
[ 10.077786] systemd[1]: Hostname set to <comlogger>.
<snip>
Debian GNU/Linux 12 comlogger ttyS0
comlogger login:
QED
That's it! You can login and customize your installation. Every time you power up or reset your Nimbus, it will boot the Debian 12 USB rootfs.
Postscript:
Define the MTD Flash Partitions in the U-Boot Linux Boot Command
There is no partition map for the MTD flash partitions; they must be properly defined for the Linux kernel from the U-Boot configuration.
The U-Boot mtdparts variable must be defined with the MTD partitions map:
Marvell>> printenv mtdparts mtdparts=mtdparts=orion_nand:1m@0m(u-boot),4m@1m(kernel),5m@5m(pluginfo),-(rootfs)
Marvell>> mtdparts device nand0 <orion_nand>, # parts = 4 #: name size offset mask_flags 0: u-boot 0x00100000 0x00000000 0 1: kernel 0x00400000 0x00100000 0 2: pluginfo 0x00500000 0x00500000 0 3: rootfs 0x1f600000 0x00a00000 0 active partition: nand0,0 - (u-boot) 0x00100000 @ 0x00000000 defaults: mtdids : none mtdparts: noneLinux uses the cmdlinepart.mtdparts kernel boot command option to define the MTD partitions (see https://unix.stackexchange.com/questions/554266/mtdparts-arguments-seems-ignored-by-linux-kernel-since-buster-upgrade).
Add the cmdlinepart.mtdparts kernel boot option to the U-Boot Linux boot command:
Marvell>> setenv bootargs_console console=ttyS0,115200 cmdlinepart.$(mtdparts) Marvell>> saveenvLinux view of the MTD partitions, before:
# cat /proc/mtd dev: size erasesize name mtd0: 00100000 00020000 "u-boot" mtd1: 00400000 00020000 "uImage" mtd2: 1fb00000 00020000 "root"And after:
# cat /proc/mtd dev: size erasesize name mtd0: 00100000 00020000 "u-boot" mtd1: 00400000 00020000 "kernel" mtd2: 00500000 00020000 "pluginfo" mtd3: 1f600000 00020000 "rootfs"Thank you,
Larry Baker
==========
Major edits from the first edition of this post to add the changes required to support the Nimbus 100 in the Debian 12 installer.
Edited 3 time(s). Last edit at 11/01/2024 07:52PM by mossbeachlarry.
|
Re: Please add built-in kernel UBIFS support for Kirkwood boards October 29, 2024 02:03PM |
Admin Registered: 14 years ago Posts: 19,916 |
Larry,
> I have just finished creating a Debian 12 Nimbus
> installer uImage using your Nimbus 100 DTB!
Nice!
> Marvell>> fatload usb 0:1 0x01100000
> bookworm-sheevaplug-installer-uinitrd
Should be
> Marvell>> setenv bootargs console=ttyS0,115200n8
> base-installer/initramfs-tools/driver-policy=most
Should be driver-policy=dep to make the initrd smaller right of the bat. But this step can be done later after the system is running.
> I already donate to Doctor's Without Borders and
> lots of other charities. So, tell me how to
> really buy you a beer! :)
Thanks Larry! donation to MSF is already great, more than enough for me.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
> I have just finished creating a Debian 12 Nimbus
> installer uImage using your Nimbus 100 DTB!
Nice!
> Marvell>> fatload usb 0:1 0x01100000
> bookworm-sheevaplug-installer-uinitrd
Should be
fatload usb 0:1 0x02100000 bookworm-sheevaplug-installer-uinitrd
> Marvell>> setenv bootargs console=ttyS0,115200n8
> base-installer/initramfs-tools/driver-policy=most
Should be driver-policy=dep to make the initrd smaller right of the bat. But this step can be done later after the system is running.
> I already donate to Doctor's Without Borders and
> lots of other charities. So, tell me how to
> really buy you a beer! :)
Thanks Larry! donation to MSF is already great, more than enough for me.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: Please add built-in kernel UBIFS support for Kirkwood boards October 29, 2024 03:04PM |
Registered: 1 year ago Posts: 61 |
bodhi,
> fatload usb 0:1 0x02100000 bookworm-sheevaplug-installer-uinitrd
The Debian kernel is only 2.5 MB. It's their initramfs that is HUGE! (A consequence of their driver policy, as you know.) The load address I used is from Martin Michlmayer's instructions. It is fine for Debian's kernel, but not for yours.
I did have a hiccup in the Debian 12 installation on Nimbus. It could not find a suitable kernel. I traced the problem to the FLAVOUR variable being empty. FLAVOUR=arch_get_kernel_flavour() (in armel.sh), which returns "marvell" if SUBARCH is either kirkwood or orion5x, else "". SUBARCH=archdetect, whose source code I cannot find. archdetect returns something like armel/generic (I forgot to write it down). I did not have this problem with the Debian 12 installer on my SheevaPlug. I am going to fire up the installer again on my SheevaPlug and see what archdetect returns there. Meanwhile, I'm installing apt-file so I can search for where archdetect comes from. (I told you before, I don't run Debian except on these SoCs. Every time I reinstall, I have to add packages again. :) )
Cheers,
Larry Baker
> fatload usb 0:1 0x02100000 bookworm-sheevaplug-installer-uinitrd
The Debian kernel is only 2.5 MB. It's their initramfs that is HUGE! (A consequence of their driver policy, as you know.) The load address I used is from Martin Michlmayer's instructions. It is fine for Debian's kernel, but not for yours.
I did have a hiccup in the Debian 12 installation on Nimbus. It could not find a suitable kernel. I traced the problem to the FLAVOUR variable being empty. FLAVOUR=arch_get_kernel_flavour() (in armel.sh), which returns "marvell" if SUBARCH is either kirkwood or orion5x, else "". SUBARCH=archdetect, whose source code I cannot find. archdetect returns something like armel/generic (I forgot to write it down). I did not have this problem with the Debian 12 installer on my SheevaPlug. I am going to fire up the installer again on my SheevaPlug and see what archdetect returns there. Meanwhile, I'm installing apt-file so I can search for where archdetect comes from. (I told you before, I don't run Debian except on these SoCs. Every time I reinstall, I have to add packages again. :) )
Cheers,
Larry Baker
|
Re: Please add built-in kernel UBIFS support for Kirkwood boards October 29, 2024 03:54PM |
Registered: 1 year ago Posts: 61 |
bodhi,
I ran archdetect on console #2 immediately after the Debian 12 installer screen appeared on both my SheevaPlug and my Nimbus.
On SheevaPlug:
Is there something in the Nimbus DTB that could explain this?
I am going to follow the instructions at DebianInstaller Checkout to try to find the source code for archdetect. Once I know how it comes up with its response, I can pass that along to you in case a new version of the Nimbus DTB will fix this problem.
Thank you,
Larry Baker
I ran archdetect on console #2 immediately after the Debian 12 installer screen appeared on both my SheevaPlug and my Nimbus.
On SheevaPlug:
~ # archdetect armel/kirkwoodOn Nimbus:
~ # archdetect armel/genericThis explains why the Debian 12 installer could not find a suitable kernel to install on my Nimbus.
Is there something in the Nimbus DTB that could explain this?
I am going to follow the instructions at DebianInstaller Checkout to try to find the source code for archdetect. Once I know how it comes up with its response, I can pass that along to you in case a new version of the Nimbus DTB will fix this problem.
Thank you,
Larry Baker
|
Re: Please add built-in kernel UBIFS support for Kirkwood boards October 29, 2024 05:03PM |
Admin Registered: 14 years ago Posts: 19,916 |
Larry,
> This explains why the Debian 12 installer could
> not find a suitable kernel to install on my
> Nimbus.
>
> Is there something in the Nimbus DTB that could
> explain this?
Arch Kirkwood is correct. It's should be defined in the kernel config. The DTB does not define the board architecture.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
> This explains why the Debian 12 installer could
> not find a suitable kernel to install on my
> Nimbus.
>
> Is there something in the Nimbus DTB that could
> explain this?
Arch Kirkwood is correct. It's should be defined in the kernel config. The DTB does not define the board architecture.
CONFIG_MACH_KIRKWOOD=y
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: Please add built-in kernel UBIFS support for Kirkwood boards October 29, 2024 05:22PM |
Registered: 1 year ago Posts: 61 |
bodhi,
I assumed the Debian 12 kernel I downloaded from http://ftp.debian.org/debian/dists/bookworm/main/installer-armel/current/images/kirkwood/netboot/vmlinuz-6.1.0-25-marvell is the same kernel in the Debian 12 installer at http://ftp.debian.org/debian/dists/bookworm/main/installer-armel/current/images/kirkwood/netboot/marvell/sheevaplug/uImage. Perhaps that was a mistake.
I'll boot the Debian 12 installer uImage on both my SheevaPlug and my Nimbus and see what archdetect says. If they both say armel/kirkwood, then I'll have to unwrap the Debian 12 installer uImage to use that kernel with your Nimbus DTB.
Thanks for the info.
Larry Baker
I assumed the Debian 12 kernel I downloaded from http://ftp.debian.org/debian/dists/bookworm/main/installer-armel/current/images/kirkwood/netboot/vmlinuz-6.1.0-25-marvell is the same kernel in the Debian 12 installer at http://ftp.debian.org/debian/dists/bookworm/main/installer-armel/current/images/kirkwood/netboot/marvell/sheevaplug/uImage. Perhaps that was a mistake.
I'll boot the Debian 12 installer uImage on both my SheevaPlug and my Nimbus and see what archdetect says. If they both say armel/kirkwood, then I'll have to unwrap the Debian 12 installer uImage to use that kernel with your Nimbus DTB.
Thanks for the info.
Larry Baker
|
Re: Please add built-in kernel UBIFS support for Kirkwood boards October 29, 2024 08:54PM |
Registered: 1 year ago Posts: 61 |
bodhi,
> Arch Kirkwood is correct. It's should be defined in the kernel config.
> The DTB does not define the board architecture.
Well, something fishy is going on and the evidence points to the Nimbus DTB file. Why? I don't know yet.
I created two Debian 12 installer uImage's using their Kirkwood vmlinuz file, one with their SheevaPlug DTB and one with the Nimbus DTB file. I ran those two on my Nimbus, as well as the stock Debian 12 installer uImage. The same 6.1.0-25-marvell kernel is in all three (proof below). archdetect returns armel/kirkwood for both uImage's with the SheevaPlug DTB. It returns armel/generic for the uImage with the Nimbus DTB.
Here's exactly what I did (from the history command). I am doing the uImage manipulation on a Linux x86_64 PC and writing the results to a USB FAT drive. I then run each Debian 12 installer on my Nimbus.
Create Debian 12 installer uImage files using the Debian 12 vmlinuz-6.1.0-25-marvell
kernel with the Debian 12 kirkwood-sheevaplug.dtb and the bodhi kirkwood-nimbus-100.dtb
While you ponder this, I am going to download the Debian Installer sources to figure out how archdetect works.
More later.
Larry Baker
> Arch Kirkwood is correct. It's should be defined in the kernel config.
> The DTB does not define the board architecture.
Well, something fishy is going on and the evidence points to the Nimbus DTB file. Why? I don't know yet.
I created two Debian 12 installer uImage's using their Kirkwood vmlinuz file, one with their SheevaPlug DTB and one with the Nimbus DTB file. I ran those two on my Nimbus, as well as the stock Debian 12 installer uImage. The same 6.1.0-25-marvell kernel is in all three (proof below). archdetect returns armel/kirkwood for both uImage's with the SheevaPlug DTB. It returns armel/generic for the uImage with the Nimbus DTB.
Here's exactly what I did (from the history command). I am doing the uImage manipulation on a Linux x86_64 PC and writing the results to a USB FAT drive. I then run each Debian 12 installer on my Nimbus.
Create Debian 12 installer uImage files using the Debian 12 vmlinuz-6.1.0-25-marvell
kernel with the Debian 12 kirkwood-sheevaplug.dtb and the bodhi kirkwood-nimbus-100.dtb
# mkdir -p /opt/nimbus/bookworm-installers # cd /opt/nimbus/bookworm-installers
# wget http://ftp.debian.org/debian/dists/bookworm/main/installer-armel/current/images/kirkwood/device-tree/kirkwood-sheevaplug.dtb # wget -O kirkwood-nimbus-100.dtb https://forum.doozan.com/file.php?2,file=7018,filename=kirkwood-nimbus-100.dtb # wget -O uImage-6.1.0-25-debian http://ftp.debian.org/debian/dists/bookworm/main/installer-armel/current/images/kirkwood/netboot/marvell/sheevaplug/uImage # wget -O uInitrd-6.1.0-25-debian http://ftp.debian.org/debian/dists/bookworm/main/installer-armel/current/images/kirkwood/netboot/marvell/sheevaplug/uInitrd # wget http://ftp.debian.org/debian/dists/bookworm/main/installer-armel/current/images/kirkwood/netboot/vmlinuz-6.1.0-25-marvell
# ls -lh total 17M -rw-r--r--. 1 root root 11K Oct 25 14:57 kirkwood-nimbus-100.dtb -rw-r--r--. 1 root root 11K Aug 27 15:35 kirkwood-sheevaplug.dtb -rw-r--r--. 1 root root 2.6M Aug 27 15:35 uImage-6.1.0-25-debian -rw-r--r--. 1 root root 12M Aug 27 15:35 uInitrd-6.1.0-25-debian -rw-r--r--. 1 root root 2.6M Aug 26 12:47 vmlinuz-6.1.0-25-marvell
# KERNEL=6.1.0-25-sheevaplug
# IMAGE=vmlinuz-6.1.0-25-marvell
# NAME="kernel ${KERNEL}"
# cat ${IMAGE} 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.1.0-25-sheevaplug
Created: Tue Oct 29 17:47:47 2024
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2639008 Bytes = 2577.16 KiB = 2.52 MiB
Load Address: 00008000
Entry Point: 00008000
# rm zImage.fdt
# KERNEL=6.1.0-25-nimbus
# IMAGE=vmlinuz-6.1.0-25-marvell
# NAME="kernel ${KERNEL}"
# cat ${IMAGE} kirkwood-nimbus-100.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.1.0-25-nimbus
Created: Tue Oct 29 17:49:09 2024
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2638969 Bytes = 2577.12 KiB = 2.52 MiB
Load Address: 00008000
Entry Point: 00008000
# rm zImage.fdt
# mount /dev/sdc1 /mnt/sdc1
# cp uImage-6.1.0-25-{debian,sheevaplug,nimbus} /mnt/sdc1/
# cp uInitrd-6.1.0-25-debian /mnt/sdc1/
# sync
# ls -lh /mnt/sdc1/*6.1.0-25* -rwxr-xr-x. 1 root root 2.6M Oct 29 17:53 /mnt/sdc1/uImage-6.1.0-25-debian -rwxr-xr-x. 1 root root 2.6M Oct 29 17:53 /mnt/sdc1/uImage-6.1.0-25-nimbus -rwxr-xr-x. 1 root root 2.6M Oct 29 17:53 /mnt/sdc1/uImage-6.1.0-25-sheevaplug -rwxr-xr-x. 1 root root 12M Oct 29 17:53 /mnt/sdc1/uInitrd-6.1.0-25-debian
# umount /mnt/sdc1Boot the stock Debian 12 installer uImage
Marvell>> fatload usb 0:1 0x00800000 uImage-6.1.0-25-debian 2639072 bytes read Marvell>> fatload usb 0:1 0x01100000 uInitrd-6.1.0-25-debian 12219305 bytes read [ 0.000000] OF: fdt: Machine model: Globalscale Technologies SheevaPlug ~ # uname -a Linux (none) 6.1.0-25-marvell #1 Debian 6.1.106-3 (2024-08-26) armv5tel GNU/Linux ~ # archdetect armel/kirkwoodBoot the Debian 12 vmlinuz with Debian 12 kirkwood-sheevaplug.dtb
Marvell>> fatload usb 0:1 0x00800000 uImage-6.1.0-25-sheevaplug 2639072 bytes read Marvell>> fatload usb 0:1 0x01100000 uInitrd-6.1.0-25-debian 12219305 bytes read [ 0.000000] OF: fdt: Machine model: Globalscale Technologies SheevaPlug ~ # uname -a Linux (none) 6.1.0-25-marvell #1 Debian 6.1.106-3 (2024-08-26) armv5tel GNU/Linux ~ # archdetect armel/kirkwoodBoot the Debian 12 vmlinuz with the bodhi kirkwood-nimbus-100.dtb
Marvell>> fatload usb 0:1 0x00800000 uImage-6.1.0-25-nimbus 2639033 bytes read Marvell>> fatload usb 0:1 0x01100000 uInitrd-6.1.0-25-debian 12219305 bytes read [ 0.000000] OF: fdt: Machine model: Ionics Nimbus 100 ~ # uname -a Linux (none) 6.1.0-25-marvell #1 Debian 6.1.106-3 (2024-08-26) armv5tel GNU/Linux ~ # archdetect armel/genericuImage-6.1.0-25-debian and uImage-6.1.0-25-sheevaplug are the same w/o headers
# cd /opt/nimbus/bookworm-installers/ # diff uImage-6.1.0-25-debian uImage-6.1.0-25-sheevaplug Binary files uImage-6.1.0-25-debian and uImage-6.1.0-25-sheevaplug differ # dd if=uImage-6.1.0-25-debian of=stripped-6.1.0-25-debian skip=64 bs=1 2639008+0 records in 2639008+0 records out 2639008 bytes (2.6 MB) copied, 6.44447 s, 409 kB/s # dd if=uImage-6.1.0-25-sheevaplug of=stripped-6.1.0-25-sheevaplug skip=64 bs=1 2639008+0 records in 2639008+0 records out 2639008 bytes (2.6 MB) copied, 6.48688 s, 407 kB/s # diff stripped-6.1.0-25-debian stripped-6.1.0-25-sheevaplugGot any ideas?
While you ponder this, I am going to download the Debian Installer sources to figure out how archdetect works.
More later.
Larry Baker
