OpenWrt on TBS MOI+

bodhi,

having

SoC:   Kirkwood 88F6282_A1
Model: TBS MOI+
DRAM:  512 MiB
Core:  19 devices, 14 uclasses, devicetree: separate
NAND:  512 MiB
Loading Environment from NAND... OK
In:    serial
Out:   serial
Err:   serial
pcie0.0: Link up
Net:   eth0: ethernet-controller@72000
Hit any key to stop autoboot:  0 
MOI+> mtd     
  mtd mtdparts
MOI+> mtdparts 

device nand0 <orion_nand>, # parts = 2
 #: name		size		offset		mask_flags
 0: uboot               0x00100000	0x00000000	0
 1: data                0x1ff00000	0x00100000	0

active partition: nand0,0 - (uboot) 0x00100000 @ 0x00000000

defaults:
mtdids  : nand0=orion_nand
mtdparts: mtdparts=orion_nand:1m(uboot),-(data)
MOI+>

1. how i have change $mtdparts in order to be able to make visible to the u-boot an ubi partition
i made from debian on mtd1

root@debian:~# ubiattach /dev/ubi_ctrl -m 1

[   77.885942][ T1188] ubi0: attaching mtd1
[   78.607169][ T1188] ubi0: scanning is finished
[   78.637189][ T1188] ubi0: attached mtd1 (name "data", size 511 MiB)
[   78.643508][ T1188] ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes
[   78.656313][ T1188] ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 512
[   78.664050][ T1188] ubi0: VID header offset: 512 (aligned 512), data offset: 2048
[   78.671819][ T1188] ubi0: good PEBs: 4088, bad PEBs: 0, corrupted PEBs: 0
[   78.678824][ T1188] ubi0: user volume: 1, internal volumes: 1, max. volumes count: 128
[   78.686986][ T1188] ubi0: max/mean erase counter: 2/1, WL threshold: 4096, image sequence number: 693956855
[   78.696956][ T1188] ubi0: available PEBs: 0, total reserved PEBs: 4088, PEBs reserved for bad PEB handling: 80
[   78.707212][ T1190] ubi0: background thread "ubi_bgt0d" started, PID 1190
UBI device number 0, total 4088 LEBs (527450112 bytes, 503.0 MiB), available 0 LEBs (0 bytes), LEB size 129024 bytes (126.0 KiB)
root@debian:~# mount.ubifs /dev/ubi0_0 /mnt/ubifs/
[   96.833144][ T1192] UBIFS (ubi0:0): Mounting in unauthenticated mode
[   96.849615][ T1193] UBIFS (ubi0:0): background thread "ubifs_bgt0_0" started, PID 1193
[   96.981245][ T1192] UBIFS (ubi0:0): UBIFS: mounted UBI device 0, volume 0, name "rootfs"
[   96.989437][ T1192] UBIFS (ubi0:0): LEB size: 129024 bytes (126 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
[   97.000456][ T1192] UBIFS (ubi0:0): FS size: 262821888 bytes (250 MiB, 2037 LEBs), max 2048 LEBs, journal size 9033728 bytes (8 MiB, 71 LEBs)
[   97.013457][ T1192] UBIFS (ubi0:0): reserved for root: 0 bytes (0 KiB)
[   97.020025][ T1192] UBIFS (ubi0:0): media format: w4/r0 (latest is w5/r0), UUID 7C65E193-A894-4039-ACB0-40659E388690, small LPT model
root@debian:~# file /mnt/ubifs/boot/uImage 
/mnt/ubifs/boot/uImage: u-boot legacy uImage, Linux-2.6.35.14, Linux/ARM, OS Kernel Image (Not compressed), 3546932 bytes, Wed Mar 26 08:08:36 2014, Load Address: 0X008000, Entry Point: 0X008000, Header CRC: 0X64D64730, Data CRC: 0X102A26D8
root@debian:~#

2. since you've mentioned OpenWrt as rescue system on nand(i have 500MB on mtd1),
which image you'd suggest for this box

root@debian:~# ethtool -i eth0

driver: mv643xx_eth
version: 1.4
firmware-version: N/A
expansion-rom-version: 
bus-info: platform
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no

Regards,
alex

======
bodhi edited: please use code tags (formatted code button) to post log.



Edited 1 time(s). Last edit at 12/15/2024 03:57PM by bodhi.

Alex,

Try using Netgear ReadyNAS Duo V2 image.

After you tried this, post the entire boot log, and we'll go from there. You will need to do more steps to get it to boot with the MOI+ DTB.

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



Edited 1 time(s). Last edit at 12/15/2024 04:49PM by bodhi.

Alex,

This will be a guide, so post the entire boot log, with as much detail as possible (i.e. just copy your log here).

Log into OpenWrt, and

cat /proc/mtd
ls -latr /boot

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

bodhi,

following a thread https://forum.doozan.com/read.php?4,42279
made the stuff they're suggesting while in uboot, inclusive nand erase.ubi
booted into Openwrt kernel,
opkg-update, opkg install ...
opkg install ethtool
(suppressed echo ont eth0 with it, thank an you:-)
uploaded and installed systemupgrade
(openwrt-24.10.0-rc2-kirkwood-generic-netgear_readynas-duo-v2-squashfs-sysupgrade.bin )
after reboot have following:

MOI+> printenv bootcmd_lede
bootcmd_lede=run set_bootargs_lede; ubi part ubi; ubi read 0x800000 kernel; bootm 0x800000
MOI+> run bootcmd_lede     
ubi0: attaching mtd2
ubi0: scanning is finished
ubi0: attached mtd2 (name "ubi", size 511 MiB)
ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes
ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 512
ubi0: VID header offset: 512 (aligned 512), data offset: 2048
ubi0: good PEBs: 4088, bad PEBs: 0, corrupted PEBs: 0
ubi0: user volume: 2, internal volumes: 1, max. volumes count: 128
ubi0: max/mean erase counter: 3/1, WL threshold: 4096, image sequence number: 1274943845
ubi0: available PEBs: 3128, total reserved PEBs: 960, PEBs reserved for bad PEB handling: 80
Volume kernel not found!
Wrong Image Type for bootm command
ERROR -91: can't get kernel image!
MOI+>

Regards,
alex



Edited 1 time(s). Last edit at 12/16/2024 06:38AM by ri8.

Alex,

Your log:

MOI+> ubi list
0: rootfs
1: rootfs_data

MOI+> ubifsmount ubi:0
UBIFS error (pid: 1): cannot open "ubi:0", error -19

u-boot command syntax:

ubifsmount ubi0:<volume name>

So do this to see what's in it:

ubi part ubi
ubifsmount ubi0:rootfs

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

bodhi,

OI+> ubi part ubi
ubi0: attaching mtd2
ubi0: scanning is finished
ubi0: attached mtd2 (name "ubi", size 511 MiB)
ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes
ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 512
ubi0: VID header offset: 512 (aligned 512), data offset: 2048
ubi0: good PEBs: 4088, bad PEBs: 0, corrupted PEBs: 0
ubi0: user volume: 2, internal volumes: 1, max. volumes count: 128
ubi0: max/mean erase counter: 3/1, WL threshold: 4096, image sequence number: 1038561546
ubi0: available PEBs: 3128, total reserved PEBs: 960, PEBs reserved for bad PEB handling: 80
MOI+> ubifsmount ubi0:rootfs
UBIFS error (ubi0:0 pid 0): ubifs_read_node: bad node type (4 but expected 6)
UBIFS error (ubi0:0 pid 0): ubifs_read_node: bad node at LEB 0:0, LEB mapping status 1
Error reading superblock on volume 'ubi0:rootfs' errno=-22!
MOI+> ubi list              
0: rootfs
1: rootfs_data
MOI+> ubifsmount ubi0:rootfs_data
MOI+> ubifs
  ubifsload ubifsls ubifsmount ubifsumount
MOI+> ubifsls
MOI+> ubifsls help
** File not found help **
MOI+> help ubifsls 
ubifsls - list files in a directory

Usage:
ubifsls [directory]
    - list files in a 'directory' (default '/')
MOI+> ubifsls /    
MOI+> ubifsls /boot
** File not found /boot **
MOI+> ubifsmount ubi0:rootfs     
UBIFS error (ubi0:0 pid 0): ubifs_read_node: bad node type (4 but expected 6)
UBIFS error (ubi0:0 pid 0): ubifs_read_node: bad node at LEB 0:0, LEB mapping status 1
Error reading superblock on volume 'ubi0:rootfs' errno=-22!
MOI+> 
MOI+> ubiumount 
Unknown command 'ubiumount' - try 'help'
MOI+> ubi       
  ubi ubifsload ubifsls ubifsmount ubifsumount
MOI+> ubifsumount 
MOI+> ubifsls               
UBIFS not mounted, use ubifsmount to mount volume first!

- the same, as in debian;
i've tried it with old nsa345.kwb- (same results- unmountable mtd2, empty mtd3)
after booting openwrt uimage
the same mtd layout:

root@OpenWrt:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00180000 00020000 "u-boot"
mtd1: 00020000 00020000 "u-boot-env"
mtd2: 00600000 00020000 "kernel"
mtd3: 07800000 00020000 "ubi"

i've untared their sysupgrade:

bash-5.1$ binwalk untar/sysupgrade-netgear_readynas-duo-v2/root 

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             Squashfs filesystem, little endian, version 4.0, compression:xz, size: 2920326 bytes, 1287 inodes, blocksize: 262144 bytes, created: 2024-12-03 11:41:08

bash-5.1$ binwalk untar/sysupgrade-netgear_readynas-duo-v2/kernel 

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             uImage header, header size: 64 bytes, header CRC: 0xB8326DAF, created: 2024-12-03 11:41:08, image size: 3125646 bytes, Data Address: 0x8000, Entry Point: 0x8000, data CRC: 0x7559279A, OS: Linux, CPU: ARM, image type: OS Kernel Image, compression type: none, image name: "ARM OpenWrt Linux-6.6.63"
100           0x64            Linux kernel ARM boot executable zImage (little-endian), load address: "0x00000000", end address: "0x002F7DC0"
30384         0x76B0          xz compressed data
30908         0x78BC          xz compressed data

bash-5.1$

since openwrt has mtd write,
i could do:
mtd -r write kernel kernel
mtd -r write root ubi

(may be i have to ubinize first );
- and we had wthat sysupgrade does behind the scene,
-but i'm somewhat anxious about u-boot ,env etc

or use already ubinized one:

ash-5.1$ binwalk GoFlex/Rescue-System-V2.8.2-for-GoFlexNet-Home-Zyxel-NSA3x0-and-others-by-davygravy/rootfs-mtd2.img 

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             UBI erase count header, version: 1, EC: 0x0, VID header offset: 0x200, data offset: 0x800
^C
bash-5.1$ binwalk GoFlex/Rescue-System-V2.8.2-for-GoFlexNet-Home-Zyxel-NSA3x0-and-others-by-davygravy/uImage-mtd1.img 

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             uImage header, header size: 64 bytes, header CRC: 0x90566931, created: 2012-10-29 22:52:12, image size: 3627768 bytes, Data Address: 0x8000, Entry Point: 0x8000, data CRC: 0x4F789AAA, OS: Linux, CPU: ARM, image type: OS Kernel Image, compression type: none, image name: "Linux-3.3.2-kirkwide"
17287         0x4387          gzip compressed data, maximum compression, from Unix, NULL date (1970-01-01 00:00:00)

bash-5.1$

- just to see, if it's works from openwrt
Regards,
alex



Edited 3 time(s). Last edit at 12/17/2024 02:42AM by ri8.

Alex,

> i've untared their sysupgrade:

Slow down. That's entirely unecessary! that will confuse you even more.

First, clean up your log. And then reread it. You'll notice this

- In u-boot, initially you have 2 mtd partitions: u-boot and ubi.

- After loading and run the initramfs-uImage from RAM. You've booted into OpenWrt, you have 4 mtd partitions.

> root@OpenWrt:~# cat /proc/mtd
> dev:    size   erasesize  name
> mtd0: 00180000 00020000 "u-boot"
> mtd1: 00020000 00020000 "u-boot-env"
> mtd2: 00600000 00020000 "kernel"
> mtd3: 07800000 00020000 "ubi"

So make that consistent first, before you try anything else.

Now you are running this box as the Netgear ReadyNAS V2, you must either: use it mtdparts definition when you reboot, OR make sure the 2 mtds partions scheme is carried into OpenWrt in the first RAM boot.

=====

And then after you have done all that and reboot a few times as the ReadyNAS V2, you would proceed to make it run as the MOI+ for real.

I'll be back shortly.

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



Edited 1 time(s). Last edit at 12/17/2024 01:28PM by bodhi.

To see why the mtdparts defintion was not used by Openwrt in the 1st RAM boot.

Before booting,

printenv

After booting into Openwrt, log in and,

dmesg
cat /proc/cmdline
cat /proc/mtd

And please post the entire boot log here.

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



Edited 1 time(s). Last edit at 12/17/2024 02:50PM by bodhi.

bodhi,

mtdparts, exactly.
thanks for your insights.
the /proc/cmdline was empty of mtdparts definition,
and openwrt 's set it to his default of 4 partitions.

i've changed it as you suggested:
after systemupdate

root@OpenWrt:/tmp# sysupgrade -n openwrt-24.10.0-rc2-kirkwood-generic-netgear_re
adynas-duo-v2-squashfs-sysupgrade.bin 
Wed Dec 18 14:06:09 UTC 2024 upgrade: Commencing upgrade. Closing all shell sessions.
Command failed: Watchdog handover: fd=3
- watchdog -
Watchdog does not have CARDRESET support
Wed Dec 18 14:06:10 UTC 2024 upgrade: Sending TERM to remaining processes ...
Wed Dec 18 14:06:14 UTC 2024 upgrade: Sending KILL to remaining processes ...
[  631.575104] stage2 (4483): drop_caches: 3
Wed Dec 18 14:06:20 UTC 2024 upgrade: Switching to ramdisk...
Wed Dec 18 14:06:22 UTC 2024 upgrade: Performing system upgrade...
verifying sysupgrade tar file integrity
[  633.937304] ubi0: attaching mtd3
[  633.943156] ubi0 error: 0xc0543b00: bad image sequence number 870072382 in PEB 16, expected 689913973
[  633.952446] Erase counter header dump:
[  633.956213]  magic          0x55424923
[  633.959978]  version        1
[  633.962953]  ec             1
[  633.965927]  vid_hdr_offset 512
[  633.969074]  data_offset    2048
[  633.972317]  image_seq      870072382
[  633.975989]  hdr_crc        0x7782b461
[  633.979766] erase counter header hexdump:
[  633.983823] ubi0 error: 0xc0538148: failed to attach mtd3, error -22
ubiattach: error!: cannot attach mtd3
           error 22 (Invalid argument)
ubiformat: mtd3 (nand), size 530579456 bytes (506.0 MiB), 4048 eraseblocks of 131072 bytes (128.0 KiB), min. I/O size 2048 bytes
[  642.120180] ubi0: attaching mtd3 1 % complete  
ubiformat: formatting erasebloc
[  642.720585] ubi0: scanning is finished
[  642.738436] ubi0: attached mtd3 (name "ubi", size 506 MiB)
[  642.743970] ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes
[  642.750904] ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 512
[  642.757647] ubi0: VID header offset: 512 (aligned 512), data offset: 2048
[  642.764467] ubi0: good PEBs: 4048, bad PEBs: 0, corrupted PEBs: 0
[  642.770596] ubi0: user volume: 0, internal volumes: 1, max. volumes count: 128
[  642.777860] ubi0: max/mean erase counter: 0/0, WL threshold: 4096, image sequence number: 2054382410
[  642.787042] ubi0: available PEBs: 3964, total reserved PEBs: 84, PEBs reserved for bad PEB handling: 80
[  642.796524] ubi0: background thread "ubi_bgt0d" started, PID 5206
UBI device number 0, total 4048 LEBs (522289152 bytes, 498.0 MiB), available 3964 LEBs (511451136 bytes, 487.7 MiB), LEB size 129024 bytes (126.0 KiB)
Volume ID 0, size 25 LEBs (3225600 bytes, 3.0 MiB), LEB size 129024 bytes (126.0 KiB), dynamic, name "kernel", alignment 1
[  642.884882] block ubiblock0_1: created from ubi0:1(rootfs)
[  642.890413] ubiblock: device ubiblock0_1 (rootfs) set to be root filesystem
Volume ID 1, size 23 LEBs (2967552 bytes, 2.8 MiB), LEB size 129024 bytes (126.0 KiB), dynamic, name "rootfs", alignment 1
Set volume size to 505257984
Volume ID 2, size 3916 LEBs (505257984 bytes, 481.8 MiB), LEB size 129024 bytes (126.0 KiB), dynamic, name "rootfs_data", alignment 1
sysupgrade successful
umount: can't unmount /dev: Resource busy
umount: can't unmount /tmp: Resource busy
[  645.427781] sd 0:0:0:0: [sda] Synchronizing SCSI cache
:

uboot founds openwrt kernel, kernel rootfs -
and openwrt up , running!

i've (previously) had to hardcode scan_disk to 3. partition of sata,
in order it finds rootfs on sda3(not neat, but works)

What doesn work,
mtdparts, as i defined it now,
don't go correctly into debian boot;
from debian i see only one mtd partition
,that of u-boot.
after reviewing the u-boot env, i do not see where it is a mistake there.

root@debian:~# cat /proc/c
cgroups   cmdline   consoles  cpu/      cpuinfo   crypto    
root@debian:~# cat /proc/cmdline 
console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 orion_nand:0x180000@0(u-boot),0x20000@0x180000(u-boot-env),0x600000@0x200000(uImage),-@0x600000(ubi)
root@debian:~# cat /proc/mtd     
dev:    size   erasesize  name
mtd0: 00100000 00020000 "uboot"
root@debian:~#

while in u-boot, fails to mount ubiparts

MOI+> ubi part
Error, no UBI device selected!
MOI+> ubi part ubi
ubi0: attaching mtd4
ubi0: scanning is finished
ubi0: attached mtd4 (name "ubi", size 504 MiB)
ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes
ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 512
ubi0: VID header offset: 512 (aligned 512), data offset: 2048
ubi0: good PEBs: 4035, bad PEBs: 0, corrupted PEBs: 0
ubi0: user volume: 3, internal volumes: 1, max. volumes count: 128
ubi0: max/mean erase counter: 1/0, WL threshold: 4096, image sequence number: 2054382410
ubi0: available PEBs: 0, total reserved PEBs: 4035, PEBs reserved for bad PEB handling: 67
MOI+> ubi list
0: kernel
1: rootfs
2: rootfs_data
MOI+> ubifsmount ubi0:kernel
UBIFS error (pid: 1): cannot open "ubi�0:kernel", error -22
Error reading superblock on volume 'ubi�0:kernel' errno=-22!
MOI+> ubifsmount ubi0:kernel 
UBIFS error (ubi0:0 pid 0): ubifs_read_node: bad node type (0 but expected 6)
UBIFS error (ubi0:0 pid 0): ubifs_read_node: bad node at LEB 0:0, LEB mapping status 1
Error reading superblock on volume 'ubi0:kernel' errno=-22!
MOI+> ubifsmount ubi0:rootfs
UBIFS error (ubi0:1 pid 0): ubifs_read_node: bad node type (4 but expected 6)
UBIFS error (ubi0:1 pid 0): ubifs_read_node: bad node at LEB 0:0, LEB mapping status 1
Error reading superblock on volume 'ubi0:rootfs' errno=-22!
MOI+> ubifsmount ubi0:rootfs_data
UBIFS error (ubi0:2 pid 0): mount_ubifs: can't format empty UBI volume: read-only mount
Error reading superblock on volume 'ubi0:rootfs_data' errno=-30!

But, all in all, (after i followed your advices;-)
it was a straighforward install
Thankyou very-very match!
Regards,
alex



Edited 12 time(s). Last edit at 12/18/2024 01:25PM by ri8.

Alex,

> uboot founds openwrt kernel, kernel rootfs -
> and openwrt up , running!

> But, all in all, (after i followed your
> advices;-)
> it was a straighforward install

Cool!

=====

Now there are a few more easy steps to make it run as the MOI+.

Your log was not compele. Boot into Openwrt, log in, mount each of the UBIFS volume and list the top level files. If there is /boot then list that directory too.

Basically, I'm trying to find the uImage. It looks like the kernel volume. But I need to see the files.

Please post the entire serial boot log of the above.

=====

But first, since it is a rescue system, you should set up the boot envs so it will fall back when you have problem with th Debian rootfs. And don't fix the missing mtd in Debian yet. It is not relevant, because only u-boot (mtd0) is needed in Debian.

Let me look at the envs.

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

> But first, since it is a rescue system, you should
> set up the boot envs so it will fall back when you
> have problem with th Debian rootfs. And don't fix
> the missing mtd in Debian yet. It is not relevant,
> because only u-boot (mtd0) is needed in Debian.
>
> Let me look at the envs.

Looks like you have it setup correctly.

bootcmd=run bootcmd_uenv; run scan_disk; run set_bootargs; run bootcmd_exec; run bootcmd_lede

Have you tested it by shuting down, remove the USB rootfs, and power up?

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

>
> Now there are a few more easy steps to make it run
> as the MOI+.
>
> Your log was not compele. Boot into Openwrt, log
> in, mount each of the UBIFS volume and list the
> top level files. If there is /boot then list that
> directory too.
>
> Basically, I'm trying to find the uImage. It looks
> like the kernel volume. But I need to see the
> files.
>
> Please post the entire serial boot log of the
> above.
>

Yes it is kernel volume.

bootcmd_lede=run set_bootargs_lede; ubi part ubi; ubi read 0x800000 kernel; bootm 0x800000

Read 3225600 bytes from volume kernel to 00800000
## Booting kernel from Legacy Image at 00800000 ...

So I'm wondering what it looks like, in either Openwrt or Debian?

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

bodhi,

i'm sorry, it was not doable
to mount another volumes, besides what was
mounted automatically;
it is no top level boot directory in root of any
mounted(able) volumes;
as i flashed systemupdate, there were some
errors; i've posted in previous message:
may be, it could give some hints?

root@OpenWrt:/tmp# sysupgrade -n openwrt-24.10.0-rc2-kirkwood-generic-netgear_re
adynas-duo-v2-squashfs-sysupgrade.bin 
Wed Dec 18 14:06:09 UTC 2024 upgrade: Commencing upgrade. Closing all shell sessions.
Command failed: Watchdog handover: fd=3
- watchdog -
Watchdog does not have CARDRESET support
Wed Dec 18 14:06:10 UTC 2024 upgrade: Sending TERM to remaining processes ...
Wed Dec 18 14:06:14 UTC 2024 upgrade: Sending KILL to remaining processes ...
[  631.575104] stage2 (4483): drop_caches: 3
Wed Dec 18 14:06:20 UTC 2024 upgrade: Switching to ramdisk...
Wed Dec 18 14:06:22 UTC 2024 upgrade: Performing system upgrade...
verifying sysupgrade tar file integrity
[  633.937304] ubi0: attaching mtd3
[  633.943156] ubi0 error: 0xc0543b00: bad image sequence number 870072382 in PEB 16, expected 689913973
[  633.952446] Erase counter header dump:
[  633.956213] 	magic          0x55424923
[  633.959978] 	version        1
[  633.962953] 	ec             1
[  633.965927] 	vid_hdr_offset 512
[  633.969074] 	data_offset    2048
[  633.972317] 	image_seq      870072382
[  633.975989] 	hdr_crc        0x7782b461
[  633.979766] erase counter header hexdump:
[  633.983823] ubi0 error: 0xc0538148: failed to attach mtd3, error -22
ubiattach: error!: cannot attach mtd3
           error 22 (Invalid argument)
ubiformat: mtd3 (nand), size 530579456 bytes (506.0 MiB), 4048 eraseblocks of 131072 bytes (128.0 KiB), min. I/O size 2048 bytes
[  642.120180] ubi0: attaching mtd3 1 % complete  
ubiformat: formatting erasebloc
[  642.720585] ubi0: scanning is finished
[  642.738436] ubi0: attached mtd3 (name "ubi", size 506 MiB)
[  642.743970] ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes
[  642.750904] ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 512
[  642.757647] ubi0: VID header offset: 512 (aligned 512), data offset: 2048
[  642.764467] ubi0: good PEBs: 4048, bad PEBs: 0, corrupted PEBs: 0
[  642.770596] ubi0: user volume: 0, internal volumes: 1, max. volumes count: 128
[  642.777860] ubi0: max/mean erase counter: 0/0, WL threshold: 4096, image sequence number: 2054382410
[  642.787042] ubi0: available PEBs: 3964, total reserved PEBs: 84, PEBs reserved for bad PEB handling: 80
[  642.796524] ubi0: background thread "ubi_bgt0d" started, PID 5206
UBI device number 0, total 4048 LEBs (522289152 bytes, 498.0 MiB), available 3964 LEBs (511451136 bytes, 487.7 MiB), LEB size 129024 bytes (126.0 KiB)
Volume ID 0, size 25 LEBs (3225600 bytes, 3.0 MiB), LEB size 129024 bytes (126.0 KiB), dynamic, name "kernel", alignment 1
[  642.884882] block ubiblock0_1: created from ubi0:1(rootfs)
[  642.890413] ubiblock: device ubiblock0_1 (rootfs) set to be root filesystem
Volume ID 1, size 23 LEBs (2967552 bytes, 2.8 MiB), LEB size 129024 bytes (126.0 KiB), dynamic, name "rootfs", alignment 1
Set volume size to 505257984
Volume ID 2, size 3916 LEBs (505257984 bytes, 481.8 MiB), LEB size 129024 bytes (126.0 KiB), dynamic, name "rootfs_data", alignment 1
sysupgrade successful
umount: can't unmount /dev: Resource busy
umount: can't unmount /tmp: Resource busy
[  645.427781] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[  645.435381] reboot: Restarting system

and, it were not possible to mount those
volume in u-boot, too, helas

root@OpenWrt:/lib/firmware# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 3.0M      3.0M         0 100% /rom
tmpfs                   248.6M      1.2M    247.4M   0% /tmp
/dev/ubi0_2             450.7M     75.8M    370.1M  17% /overlay
overlayfs:/overlay      450.7M     75.8M    370.1M  17% /
tmpfs                   512.0K         0    512.0K   0% /dev
root@OpenWrt:/lib/firmware# blkid
[ 1366.012651] mtdblock: MTD device 'uImage' is NAND, please consider using UBI block devices instead.
[ 1366.052216] mtdblock: MTD device 'u-boot' is NAND, please consider using UBI block devices instead.
[ 1366.092802] mtdblock: MTD device 'ubi' is NAND, please consider using UBI block devices instead.
[ 1366.137321] mtdblock: MTD device 'u-boot-env' is NAND, please consider using UBI block devices instead.
/dev/ubi0_2: UUID="3e3cacd3-0ff7-44ad-9e5b-383de024a377" TYPE="ubifs"
/dev/ubi0_1: BLOCK_SIZE="262144" TYPE="squashfs"
/dev/mtdblock2: UUID="689913973" TYPE="ubi"
/dev/mtdblock3: UUID="2054382410" TYPE="ubi"
/dev/ubiblock0_1: BLOCK_SIZE="262144" TYPE="squashfs"
/dev/sda4: LABEL="ext3_data" UUID="1a6212d0-5c67-4ed8-8cd7-267403e21fe7" SEC_TYPE="ext2" BLOCK_SIZE="4096" TYPE="ext3" PARTLABEL="rootfs" PARTUUID="6d15910d-044d-473f-abb2-232654acbe1b"
/dev/sda3: LABEL="rootfs" UUID="0dab553c-2087-4866-8318-a06a2829035e" SEC_TYPE="ext2" BLOCK_SIZE="4096" TYPE="ext3" PARTLABEL="Linux filesystem" PARTUUID="169fc700-47f8-4d09-a61c-838e6be82ba4"
/dev/sda1: LABEL_FATBOOT="EFI_2TM" UUID="37AD-EE94" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="Microsoft basic data" PARTUUID="cb6f8465-9ae8-4ead-bf1f-77e526776fbb"
/dev/sda2: PARTLABEL="Linux swap" PARTUUID="95f67525-f797-488f-a67d-68c04b98806f"
root@OpenWrt:/lib/firmware# mount -t squashfs /dev/ubiblock0_1 /mnt/ubi0_1/
[ 1417.431629] ubiblock0_1: Can't mount, would change RO state
mount: mounting /dev/ubiblock0_1 on /mnt/ubi0_1/ failed: Resource busy
root@OpenWrt:/lib/firmware# ls /dev/ubi*
/dev/ubi0         /dev/ubi0_1       /dev/ubi_ctrl
/dev/ubi0_0       /dev/ubi0_2       /dev/ubiblock0_1
root@OpenWrt:/lib/firmware# 

root@OpenWrt:~# cat /proc/mtd 
dev:    size   erasesize  name
mtd0: 00180000 00020000 "u-boot"
mtd1: 00020000 00020000 "u-boot-env"
mtd2: 00600000 00020000 "uImage"
mtd3: 1fa00000 00020000 "ubi"
root@OpenWrt:~#

Regards, alex



Edited 1 time(s). Last edit at 12/18/2024 03:11PM by ri8.

Alex,

> and, it were not possible to mount those
> volume in u-boot, too, helas

True. But not quite like that.

The kernel volume is accessible, because it is the uImage that being used for booting. It seems they flashed it raw ('ubi read' was used instead of ubifsload)

This is the old scheme in Openwrt. Due to the small size of the NAND for ReadyNAS Duo V2, they use squashfs for the volume rootfs. It is not mountable because u-boot does not support squashfs. So even though you can see rootfs and rootfs_data volume in u-boot, they are not accessible.

I'm wondering if we can find the source code for openwrt-24.10.0-rc2-kirkwood-generic-netgear_readynas-duo-v2-squashfs-sysupgrade.bin. It has been a long time ago, I forgot most of the UBI know-hows. Basically, you would attach the UBI partition in Debian, and access the volumes and then write a raw image, or a UBIFS image to a volume.

What we want to do here is create a new uImage with the MOI+ DTB, and write it to the kernel volume. We can get the Openwrt zImage for this purpose.

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



Edited 1 time(s). Last edit at 12/18/2024 04:12PM by bodhi.

bodhi,

they have the openwrt-build or something
like that ant it is downloadble,
i cat give it a go;
so, it's a openwrt imagebuilder
compiles(in seconds with make PROFILE=$device)
an openwrt-$version-$device-systemupdate.bin
to bin/$arch
after imagebuilder untarring there are in

bash-5.1$ ls  build_dir/target-arm_xscale_musl_eabi/linux-kirkwood_generic/
checkpoint_l-50-uImage		      image-kirkwood-e4200-v2.dtb		  image-kirkwood-nsa310b.dtb		linksys_ea3500-uImage		  vmlinux-initramfs
cisco_on100-uImage		      image-kirkwood-ea3500.dtb			  image-kirkwood-nsa310s.dtb		linksys_ea4500-uImage		  vmlinux-initramfs.debug
cloudengines_pogoe02-uImage	      image-kirkwood-ea4500.dtb			  image-kirkwood-nsa325.dtb		linux-5.15.167			  vmlinux-initramfs.elf
cloudengines_pogoplugv4-uImage	      image-kirkwood-goflexhome.dtb		  image-kirkwood-on100.dtb		netgear_readynas-duo-v2-uImage	  vmlinux.elf
ctera_c200-v1-factory.firm	      image-kirkwood-goflexnet.dtb		  image-kirkwood-pogo_e02.dtb		raidsonic_ib-nas62x0-uImage	  zImage
ctera_c200-v1-factory.firm.fakehdr    image-kirkwood-ib62x0.dtb			  image-kirkwood-pogoplug-series-4.dtb	root.squashfs			  zImage-initramfs
endian_4i-edge-200-uImage	      image-kirkwood-iconnect.dtb		  image-kirkwood-sheevaplug.dtb		seagate_blackarmor-nas220-uImage  zyxel_nsa310b-uImage
globalscale_sheevaplug-uImage	      image-kirkwood-iomega_ix2_200.dtb		  iom_iconnect-1.1-uImage		seagate_dockstar-uImage		  zyxel_nsa310s-uImage
image-kirkwood-4i-edge-200.dtb	      image-kirkwood-ix4-200d.dtb		  iom_ix2-200-uImage			seagate_goflexhome-uImage	  zyxel_nsa325-uImage
image-kirkwood-blackarmor-nas220.dtb  image-kirkwood-l-50.dtb			  iom_ix4-200d-uImage			seagate_goflexnet-uImage
image-kirkwood-c200-v1.dtb	      image-kirkwood-nas1.dtb			  iptime_nas1-uImage			tmp
image-kirkwood-dockstar.dtb	      image-kirkwood-netgear_readynas_duo_v2.dtb  linksys_e4200-v2-uImage		vmlinux

those files;
the systemupdate has this structure:

bash-5.1$ ls -l ../untar/sysupgrade-netgear_readynas-duo-v2/
total 5912
-rw-r--r-- 1 riacht users      30 Dec  3 12:41 CONTROL
-rw-r--r-- 1 riacht users 3125710 Dec  3 12:41 kernel
-rw-r--r-- 1 riacht users 2920448 Dec  3 12:41 root
bash-5.1$ less ../untar/sysupgrade-netgear_readynas-duo-v2/CONTROL 
bash-5.1$ cat ../untar/sysupgrade-netgear_readynas-duo-v2/CONTROL 
BOARD=netgear_readynas-duo-v2
bash-5.1$ binwalk ../untar/sysupgrade-netgear_readynas-duo-v2/kernel 

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             uImage header, header size: 64 bytes, header CRC: 0xB8326DAF, created: 2024-12-03 11:41:08, image size: 3125646 bytes, Data Address: 0x8000, Entry Point: 0x8000, data CRC: 0x7559279A, OS: Linux, CPU: ARM, image type: OS Kernel Image, compression type: none, image name: "ARM OpenWrt Linux-6.6.63"
100           0x64            Linux kernel ARM boot executable zImage (little-endian), load address: "0x00000000", end address: "0x002F7DC0"
30384         0x76B0          xz compressed data
30908         0x78BC          xz compressed data

bash-5.1$ binwalk ../untar/sysupgrade-netgear_readynas-duo-v2/root 

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             Squashfs filesystem, little endian, version 4.0, compression:xz, size: 2920326 bytes, 1287 inodes, blocksize: 262144 bytes, created: 2024-12-03 11:41:08

unsquashed root is - see attached .txt

So, one could easily create a sysupgrade.bin with and flash it with sysupgrade.bin
Curious,what would exactly do the attaching of moi-dtb to that zImage ?

Now, i made the new uImage, from their zImage (called it kernel), repacked with tar cfv , cp *.tar -> openwrt_moi.bin,
flashed it with sysupgrade -c -F
The log attached.

root@OpenWrt:~# uname -av
Linux OpenWrt 6.6.63 #0 Tue Dec  3 11:41:08 2024 armv5tel GNU/Linux

Regards,
alex

P.S. what i found in there opkg find *kernel*:

kexec - 2.0.28-r2 - The kexec utility allows to load and boot another kernel.
kexec-tools - 2.0.28-r2 - kexec is a set of system calls that allows you to load
 another kernel from the currently executing Linux kernel. The kexec utility all
ows to load and boot another kernel.

root@OpenWrt:~# grep Linux hwinfo.txt 
    manufacturer = "Linux 6.6.63 ehci_hcd"
  <6>[ 1519.420585] Loading modules backported from Linux version v6.11.2-0-g7aa21fec187b
  Model: "Linux Foundation 2.0 root hub"
  Vendor: usb 0x1d6b "Linux Foundation"

Edited 5 time(s). Last edit at 12/19/2024 04:57AM by ri8.

Alex,

> they have the openwrt-build or something
> like that ant it is downloadble,
> i cat give it a go;
> so, it's a openwrt imagebuilder
> compiles(in seconds with make PROFILE=$device)
> an openwrt-$version-$device-systemupdate.bin

You were on the right track until this point. Yes, the Openwrt image builder is where the Kirkwood files are. This is used to create the rootfs and the kernel files for a specific Kirkwood board.

> those files;
> the systemupdate has this structure:
> bash-5.1$ ls -l
> ../untar/sysupgrade-netgear_readynas-duo-v2/

> So, one could easily create a sysupgrade.bin with and flash it with sysupgrade.bin

Now you got into reverse enginering mode.

>
> Now, i made the new uImage, from their zImage
> (called it kernel), repacked with tar cfv , cp
> *.tar -> openwrt_moi.bin,
> flashed it with sysupgrade -c -F

What you did was correct, and by the book. But, the better way would be flashing the new kernel image directly to the ubi kernel volume. You already have the system running with that zImage+kirkwood-netgear_readynas_duo_v2.dtb. Now you just need to replace it with zImage+kirkwood-moi-plus.dtb.

If you look back to my kernel release instruction, Step 4B:

Quote
https://forum.doozan.com/read.php?2,12096
4b. Boot with DTB file embedded in the kernel image.Again, this step 4b is for stock U-Boot only.

Please replace kirkwood-goflexnet.dtb below with the correct DTB name for your box (find in /boot/dts).

Generate the uImage and uInitrd (the kernel files vmlinuz-6.11.6-kirkwood-tld-1 and initrd.img-6.11.6-kirkwood-tld-1 were generated by dpkg in Step 3):
cd /boot
mv uImage uImage.orig
mv uInitrd uInitrd.orig
cp -a zImage-6.11.6-kirkwood-tld-1 zImage.fdt
cat dts/kirkwood-goflexnet.dtb >> zImage.fdt
mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n Linux-6.11.6-kirkwood-tld-1 -d zImage.fdt uImage
mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n initramfs-6.11.6-kirkwood-tld-1 -d initrd.img-6.11.6-kirkwood-tld-1 uInitrd

The zImage you found in the Openwrt Image Builder tarball is similar to my zImage-6.11.6-kirkwood-tld-1. It's a generic/universal Kirkwood kernel that can run any Kirkwood board providing you have the correct DTB appended to it.

So the system you are running now is a real MOI+ NAS, it's no longer the ReadyNAS Duo v2!

=====

Could you research how to write the new uImage to the UBI kernel volume. I recall the flow is like this:
- Make the MOI+ uImage using zImage and MOI+ DTB file
- attach the UBI device, and mount the volume(?)
- Backup the current kernel image (ReadyNAS Duo V2).
- Write the MOI+ uImage to kernel volume. IIRC, the command is ubinize.

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



Edited 3 time(s). Last edit at 12/19/2024 01:44PM by bodhi.

bodhi,

good round-up.
One topic remains though,
if speaking about moi+ native;
thats the RTL8188EUS WIFI chip on the board
still not being used, openwrt or debian
the same thing. Is it a pci
or usb thing? It doesn't help, if any rtl firmware packages
or rtl wifi kmod are installed, wlan device
will not appear.
the site
https://wikidevi.wi-cat.ru/Realtek
says, it's USB
Interesting thing, as i extracted a rootfs
from the original tbs-systemupdate archive
and untarred it, i see the following

root@OpenWrt:~# tree /mnt/hd/lib/firmware/
/mnt/hd/lib/firmware/
├── RTL8192SU
│   └── rtl8192sfw.bin
└── iwlwifi-4965-2.ucode

therefore i'd love to be able
to launch the old 2.6.35.14 kernel
with that rootfs, to see, how wifi
is initialized on that board.

And, what do i wrong on this in debian (i shortend it ) ->

1. ubinized uImage > kernel.ubi
2 mkfs.ubifs  -o rootfs.ubifs rootfs/ 
3. ubinized rootfs.ubifs > rootfs.ubi
4 ubiformat /dev/mtd2, /dev/mtd3
5 nandwrite kernel.ubi to mtd2, rootfs.ubi to mtd3

now, can't ubiattach nor in u-boot ubi part ubi,
multiple errors
Regards,
alex



Edited 2 time(s). Last edit at 12/20/2024 08:46AM by ri8.

Alex,

> thats the RTL8188EUS WIFI chip on the board
> still not being used, openwrt or debian
> the same thing. Is it a pci
> or usb thing?

It's USB.

> 1. ubinized uImage > kernel.ubi
OK

> 2 mkfs.ubifs -o rootfs.ubifs rootfs/
> 3. ubinized rootfs.ubifs > rootfs.ubi
Should not do 2 and 3 above. You alread have a working roofs for ReadyNAS Duo V2.

> 4 ubiformat /dev/mtd2, /dev/mtd3
Should not do this ubiformat for either.

Quote
bodhi
The kernel volume is accessible, because it is the uImage that being used for booting. It seems they flashed it raw ('ubi read' was used instead of ubifsload)

Looks like this kernel file is raw image, it was loaded with ubi read. So don't format the kernel volume as UBIFS.

Summary:
- No change to the rootfs is necessary.
- Just run the system as the ReadyNAS Duo v2.
- Find a way to replace the uImage in the kernel voulme with the MOI+ uImage.

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



Edited 1 time(s). Last edit at 12/20/2024 01:32PM by bodhi.

bodhi,

to reiterate;

if i were about
to make my own rootfs and kernel,
the steps are following:

1. ubinize uImage -> kernel.ubi
2. mkfs.ubifs rootfs/
3. ubinize rootfs.ubifs -> rootfs.ubi

4 ubiformat /dev/mtd2 kernel.ubi
5- ubiformat /dev/mtd3 rootf.ubi

Right?

Regards,
alex

bohdi,

why nobody says?
because the only way to KNOW
it is to find in one your OWN;-)

pretty simple, if you now, HOWTO

root@debian:~# cat /proc/mtd 
dev:    size   erasesize  name
mtd0: 00180000 00020000 "u-boot"
mtd1: 00020000 00020000 "u-boot-env"
mtd2: 00600000 00020000 "uImage"
mtd3: 01400000 00020000 "uInitrd"
mtd4: 1ec00000 00020000 "ubi"

root@debian:~# ubiscan /dev/mtd4|grep PEB
PEBs   : 3936
PEB erase counters

now, give mkfs.ubifs a try : -c param is really important! (will be that PEBs : 3936)

mkfs.ubifs -r moi_rootfs/ -m 2048 -e 129024 -c 3936   -x zlib -o moi+_rootfs.ubifs
root@debian:~# cat moi+_rootfs_ubi.conf 
[moi_rootfs]
mode=ubi
image=moi+_rootfs.ubifs
vol_id=1
vol_type=dynamic
vol_name=rootfs
vol_alignment=1
vol_flags=autoresize

ubinize -vv -o moi+_rootfs.ubi -m 2048 -p 131072 -s 512 moi+_rootfs_ubi.conf
flash_eraseall /dev/mtd4root@debian:~# ubiattach /dev/ubi_ctrl -m 4
[  999.451596][ T1214] ubi0: attaching mtd4
[ 1000.122463][ T1214] ubi0: scanning is finished
[ 1000.145277][ T1214] ubi0: attached mtd4 (name "ubi", size 492 MiB)
[ 1000.162202][ T1214] ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes
[ 1000.175232][ T1214] ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 512
[ 1000.182685][ T1214] ubi0: VID header offset: 512 (aligned 512), data offset: 2048
[ 1000.200466][ T1214] ubi0: good PEBs: 3936, bad PEBs: 0, corrupted PEBs: 0
[ 1000.207629][ T1214] ubi0: user volume: 1, internal volumes: 1, max. volumes count: 128
[ 1000.215831][ T1214] ubi0: max/mean erase counter: 1/0, WL threshold: 4096, image sequence number: 2008244636
[ 1000.225926][ T1214] ubi0: available PEBs: 0, total reserved PEBs: 3936, PEBs reserved for bad PEB handling: 80
[ 1000.236181][ T1215] ubi0: background thread "ubi_bgt0d" started, PID 1215
UBI device number 0, total 3936 LEBs (507838464 bytes, 484.3 MiB), available 0 LEBs (0 bytes), LEB size 129024 bytes (126.0 KiB)
root@debian:~# 

root@debian:~# ubiformat /dev/mtd4  -f  moi+_rootfs.ubi
root@debian:~# ubiattach /dev/ubi_ctrl -m 4
oot@debian:~# mount.ubifs /dev/ubi0_1 /mnt/ubifs
[ 1239.924116][ T1231] UBIFS (ubi0:1): Mounting in unauthenticated mode
[ 1239.949607][ T1233] UBIFS (ubi0:1): background thread "ubifs_bgt0_1" started, PID 1233
[ 1240.082004][ T1231] UBIFS (ubi0:1): UBIFS: mounted UBI device 0, volume 1, name "rootfs"
[ 1240.090206][ T1231] UBIFS (ubi0:1): LEB size: 129024 bytes (126 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
[ 1240.101238][ T1231] UBIFS (ubi0:1): FS size: 495581184 bytes (472 MiB, 3841 LEBs), max 3936 LEBs, journal size 9033728 bytes (8 MiB, 71 LEBs)
[ 1240.114221][ T1231] UBIFS (ubi0:1): reserved for root: 0 bytes (0 KiB)
[ 1240.120982][ T1231] UBIFS (ubi0:1): media format: w4/r0 (latest is w5/r0), UUID 049F6609-7C86-4892-9579-F94811ACF2CD, small LPT model
root@debian:~# 
root@debian:~# ls /mnt/ubifs
.   bin  etc   lib      mnt  proc  run   sys  usr  video
..  dev  home  linuxrc  opt  root  sbin  tmp  var  www
root@debian:~# 
oot@debian:~# umount  /mnt/ubifs
[ 1375.897200][ T1238] UBIFS (ubi0:1): un-mount UBI device 0
[ 1375.903411][ T1233] UBIFS (ubi0:1): background thread "ubifs_bgt0_1" stops

root@debian:~# ubidetach /dev/ubi_ctrl -m 4
[ 3683.132338][ T1247] ubi0: detaching mtd4
[ 3683.148594][ T1247] ubi0: mtd4 is detached

eventually, it works!!
now, while in uboot

MOI+> ubi part ubi
ubi0: attaching mtd5
ubi0: scanning is finished
ubi0: attached mtd5 (name "ubi", size 484 MiB)
ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes
ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 512
ubi0: VID header offset: 512 (aligned 512), data offset: 2048
ubi0: good PEBs: 3875, bad PEBs: 0, corrupted PEBs: 0
ubi0: user volume: 1, internal volumes: 1, max. volumes count: 128
ubi0: max/mean erase counter: 1/0, WL threshold: 4096, image sequence number: 1924393240
ubi0: available PEBs: 0, total reserved PEBs: 3875, PEBs reserved for bad PEB handling: 19
MOI+> ubi list
1: rootfs
MOI+> ubifsmount ubi0:rootfs
MOI+> ubifsls /    
<DIR>	     5896  Thu Jul 24 06:42:25 2014  bin
<DIR>	      288  Thu Jul 24 06:42:26 2014  dev
<DIR>	     2712  Tue Aug 05 10:22:01 2014  etc
<DIR>	     6200  Thu Jul 24 06:42:29 2014  lib
<DIR>	      288  Thu Jul 24 06:42:25 2014  mnt
<DIR>	      160  Thu Jul 24 06:42:29 2014  opt
<DIR>	      160  Thu Jul 24 06:42:26 2014  run
<DIR>	      368  Thu Jul 24 06:42:29 2014  tmp
<DIR>	      160  Thu Jul 24 06:42:29 2014  sys
<DIR>	      416  Thu Jul 24 06:42:29 2014  var
<DIR>	      608  Thu Jul 24 06:42:42 2014  usr
<DIR>	     1920  Fri Mar 06 02:33:02 2015  www
<DIR>	      840  Thu Jul 24 06:42:26 2014  home
<DIR>	      160  Thu Jul 24 06:42:25 2014  proc
<DIR>	     4712  Thu Jul 24 06:42:42 2014  sbin
<DIR>	      704  Thu Jul 24 06:42:26 2014  root
<LNK>	       11  Thu Jul 24 06:42:29 2014  linuxrc
<DIR>	      160  Thu Jul 24 06:42:26 2014  video

works too.
:-))
but, if you not umount in debian, screws up
how can one fsck on ubi0_1 ?

lot of output, but, you now ...

Regards,
alex



Edited 2 time(s). Last edit at 12/22/2024 01:23AM by ri8.

Alex,

At the moment, I'm not interested in any of that.

I'm intererested in what I've recommended for your next step (the 3rd bullet):

https://forum.doozan.com/read.php?4,138683,138712#msg-138712

Quote

Summary:
- No change to the rootfs is necessary.
- Just run the system as the ReadyNAS Duo v2.
- Find a way to replace the uImage in the kernel volume with the MOI+ uImage.

Once you can do the above, in the future you can upgrade OpenWrt easily. IOW, you won't need to rebuild your system from scratch each time.

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

bodhi

Quote
bodhi
This is the old scheme in Openwrt. Due to the small size of the NAND for ReadyNAS Duo V2, they use squashfs for the volume rootfs. It is not mountable because u-boot does not support squashfs. So even though you can see rootfs and rootfs_data volume in u-boot, they are not accessible.

Quote
bodhi

> 2 mkfs.ubifs -o rootfs.ubifs rootfs/
> 3. ubinized rootfs.ubifs > rootfs.ubi
Should not do 2 and 3 above. You alread have a working roofs for ReadyNAS Duo V2.
> 4 ubiformat /dev/mtd2, /dev/mtd3
Should not do this ubiformat for eithe

and

Quote
bodhi
At the moment, I'm not interested in any of that.

Why not to do a small effort to repack that systemupdate of openwrt?
as you's already said, it's not a ReadyNAS any more, after all, this box has plenty of flash.

bash-5.1$ ls -lh ~/moi+/ReadyNAS_Duo_V2/openwrt-24.10.0-rc2-kirkwood-generic-netgear_readynas-duo-v2-squashfs-sysupgrade.bin 
-rw-r--r-- 1 riacht users 5.8M Dec 16 09:48 /home/riacht/moi+/ReadyNAS_Duo_V2/openwrt-24.10.0-rc2-kirkwood-generic-
bash-5.1$ ls -lh  untar/sysupgrade-moiplus-v1/
total 5.8M
-rw-r--r-- 1 riacht users   15 Dec 19 10:45 CONTROL
-rw-r--r-- 1 riacht users 3.0M Dec 19 10:45 kernel
-rw-r--r-- 1 riacht users 2.8M Dec 19 10:45 root
root@debian:~/openwrt/sysupgrade-moiplus-v1# unsquashfs root
root@debian:~/openwrt/sysupgrade-moiplus-v1# du -h squashfs-root/|tail -3
4.0K	squashfs-root/proc
620K	squashfs-root/bin
13M	squashfs-root/
 mkfs.ubifs of -> squashfs-root/
root@debian:~/openwrt# cat moi+_root_rootfs_ubi_openwrt.conf 
[uImage]
mode=ubi
image=sysupgrade-moiplus-v1/kernel
vol_id=0
vol_type=dynamic
vol_name=kernel
vol_alignment=1
[rootfs]
mode=ubi
image=moi+_rootfs_openwrt.ubifs
vol_id=1
vol_type=dynamic
vol_name=rootfs
vol_alignment=1
vol_flags=autoresize

ubize them:

root@debian:~/openwrt# ls -lh *.ubifs;ls -lh sysupgrade-moiplus-v1/kernel
-rw-r--r-- 1 root root 6.4M Dec 22 01:28 moi+_rootfs_openwrt.ubifs
-rw-r--r-- 1 root root 3.0M Dec 22 01:36 sysupgrade-moiplus-v1/kernel
root@debian:~/openwrt# file sysupgrade-moiplus-v1/kernel
sysupgrade-moiplus-v1/kernel: u-boot legacy uImage, openwrt_24_kirkwood_moi+, Linux/ARM,
 OS Kernel Image (Not compressed), 3123257 bytes, Sun Dec 22 09:35:08 2024, Load Address: 0X008000, Entry Point: 0X008000, Header CRC: 0X3D45E6C, Data CRC: 0X314DCC5D

root@debian:~/openwrt# ls -lh *.ubi
-rw-r--r-- 1 root root 9.0M Dec 22 01:37 moi+_root_rootfs_openwrt.ubi

9.4M as opposed to 5.8M of systemupgrade
flash_eraseall /dev/mtd4
ubiformat /dev/mtd4 -f moi+_root_rootfs_openwrt.ubi

Now, while rootfs volume on mtd4 is mountable (root volume ist not)
, you can rsync it to make a backups.
True, it's not fully usable, because if you write to it even once, you can't
mount it any more (fsck would't do it), - but you can ubinize your backups
and reflash it, if you ever need to;
(i reformat my flash often), so, you can't use those dumps any more, obviously

Quote
on the internet
On a clean disk you can seek forever

;-)

Besides, if you see the openwrt as an add-on to
already existing debian installation, it is the most natural way
to to install it- no need for tftpboot/ext2load-
just make those imagebilder/systemupgrade downloads,
make uImage, unsquash root.squash, edit it (like /etc/config/network)
make.ubifs, make rootfs.ubi, flash it to mtd, change u-boot env accordingly-
and up you go.

so far so good:

But, because that RTL8188eus wifi device is still not working,
(it has a good antenna, and is AP - able)
one can't speak about complete openwrt/debian port on it,
isn't it?
i've tried everything i could find on inet, and on both os's,
8188eu is loadable, but wlan0 device is to no avail.


Regards,
alex



Edited 8 time(s). Last edit at 12/23/2024 09:50AM by ri8.

Alex,

> Besides, if you see the openwrt as an add-on to
> already existing debian installation

I do see it as a rescue system. Debian is something you run everyday. So we were done with this goal when you can run it as the ReadyNAS Duo V2. Anything more is just an experiment to see what-ifs.

> But, because that RTL8188eus wifi device is still
> not working,
> (it has a good antenna, and is AP - able)
> one can't speak about complete openwrt/debian
> port on it,
> isn't it?

That's a kernel topic.

> i've tried everything i could find on inet, and on
> both os's,
> 8188eu is loadable, but wlan0 device is to no
> avail.

Perhaps the module source code you are using is not a right one.

I'll revisit this issue in the next kernel release.

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



Edited 1 time(s). Last edit at 12/23/2024 06:04PM by bodhi.

bodhi,

>Perhaps the module source code you are using is not a right one.

>I'll revisit this issue in the next kernel release.

Great.

while i don't have any experience in kernel development,
nevertheless, may be you can give me some
starting point, where i can start to look
at it; say, for this specific wifi device,
to begin with.

Just for the sake of completeness:
i found this in stock-rootfs:

bash-5.1$ find ~/moi+/moi+_rootfs/lib/|grep rtl
/home/riacht/moi+/moi+_rootfs/lib/firmware/RTL8192SU/rtl8192sfw.bin
/home/riacht/moi+/moi+_rootfs/lib/firmware/RTL8192SU/.svn/prop-base/rtl8192sfw.bin.svn-base
/home/riacht/moi+/moi+_rootfs/lib/firmware/RTL8192SU/.svn/text-base/rtl8192sfw.bin.svn-base
/home/riacht/moi+/moi+_rootfs/lib/modules/2.6.35.14/kernel/drivers/net/wireless/rtl818x
/home/riacht/moi+/moi+_rootfs/lib/modules/2.6.35.14/kernel/drivers/net/wireless/rtl818x/rtl8187.ko
/home/riacht/moi+/moi+_rootfs/lib/modules/2.6.35.14/kernel/drivers/net/wireless/rtl8188eu
/home/riacht/moi+/moi+_rootfs/lib/modules/2.6.35.14/kernel/drivers/net/wireless/rtl8188eu/8188eu.ko

in the debian,

i've modprobe'd both rtl8187 and 8188eu,
with the firmware rtl8192sfw.bin in /lib/firmware/rtlwifi
and in /lib/firmware/RTL8192SU
directories;

root@debian:~# lsmod
Module                  Size  Used by
8188eu               1183744  0
rtl8187                45056  0
eeprom_93cx6           12288  1 rtl8187
mac80211              962560  1 rtl8187
cfg80211              872448  2 mac80211,rtl8187
rfkill                 28672  2 rtl8187,cfg80211
sg                     28672  0
marvell_cesa           36864  0
kirkwood_thermal       12288  0
orion_wdt              12288  0
fixed                  16384  0
uio_pdrv_genirq        16384  0
uio                    20480  1 uio_pdrv_genirq

with no effect whatsoever as to wlan0 to be created.

Regards,
alex