TheYanusz, The rootfs name is Debian-6.5.7-kirkwood-tld-1-rootfs-bodhi.tar.bz2. Was this what you downloaded and used to create the rootfs? QuoteUpdated 01 Nov 2023: Basic Debian bookworm Kirkwood rootfs for most Kirwood plugs: - tarball size: 250MB - install size: 714MB - The init system used in this rootfs is sysvinit . To boot with systemd, see Notes below. - Installed paby bodhi - Debian
Unfortunately, this u-boot is very old, so I don't remember most of its peculiarities. kref did a good job getting it working, but also did some hacks. Let's correct these envs. This will solve the UBIFS issue, and allow you to mount the UBIFS volume in Debian. Also, for other problem, earlyprintk will hopefully print out more info than just stuck at "Uncompressing Linux....&quoby bodhi - Rescue System
> It originated after RedHat 7 or 8 later ? and some > say it came from UFS, BSD disklabel (FreeBSD > partition tables) support. Cool! I did not know that. > If grub and fstab still mount the disk according > to the old markings, it will cause the system to > be unable to boot. > BTW, SoC should be able to write U-Boot to MBR or > Super Block to boot like LILOby bodhi - Rescue System
I see you already have the correct bootargs ide_set_bootargs=setenv bootargs root=LABEL=rootfs rootfstype=ext3 console=ttyS0,115200 elevator=cfq mac_adr=0x00,0x30,0xe0,0x00,0x00,0x01 mem=256M poweroutage=yesby bodhi - Rescue System
Popo, > Now you can boot the USB rootfs, > I try to remove HDD from this box, and plug USB > stick to USB1/USB2 (all prepared as the same as > the HDD) > I have never see u-boot come from USB. Just come > from stock flash. > Maybe this box can't boot from USB directly ? Correct. Either u-boot is on NAND or on HDD raw sector. Not possible to do the same foby bodhi - Rescue System
> HDD speed ... > Perhaps it is to allow U-Boot to adapt to the > speed of HDD, so the speed is limited SATA 1.5 > Gbps. U-Boot has nothing to do with the SATA speed at all. The kernel does its own discovery and spin up. If you see slower speed in dmesg than what you expect, try reboot the system, and check dmesg again. If the box has SATA 3.0 Gbps, when encounter errors iby bodhi - Rescue System
> QuoteI got some trouble with EXT3 for u-boot. > > Everytime, after I force shutdown (kernel boot > stuck ....kernel panic .....blablabla.....) > > Next time , I power on , uImage seems load ok , > but stuck in 'Uncompressing Linux ........ done, > booting the kernel' > > I must do 'mkimage' or 'copy backup' > uImageby bodhi - Rescue System
QuoteOK, I had already upgrade to bookworm 12 Congrats! 2: end0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 That's the new naming scheme that affect these OXNAS boxes. For Kirkwood, they stay the same as eth0. QuoteI got some trouble with EXT3 for u-boot. Everytime, after I force shutdown (kernel boot stuck ....kernel panic ..by bodhi - Rescue System
QuoteI change the cable .....sigh .... It's OK, HW fails more often than we think :) Quotework well for 1Gbps.. ------------------------------------------------------------ Client connecting to 192.168.30.12, TCP port 5001 TCP window size: 16.0 MByte (default) ------------------------------------------------------------ [ 3] local 10.0.3.2 port 32850 connected with 192.168.30.1by bodhi - Rescue System
Hit:1 http://opensource.nchc.org.tw/debian buster InRelease Get:2 http://opensource.nchc.org.tw/debian buster-updates InRelease [56.6 kB] Hit:3 http://security.debian.org/debian-security oldstable-security InRelease Get:4 http://opensource.nchc.org.tw/debian buster-updates/main Sources [4616 B] Get:5 http://opensource.nchc.org.tw/debian buster-updates/main armel Packages [8792 B] Get:6 httby bodhi - Rescue System
@ 1000001101000, Very nice! I must have missed a config option somewhere. Thanks! @wibu, Regarding this error [ 2.953840] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) Note that there is no root device in the bootargs [ 0.000000] Kernel command line: console=ttyS0,115200 bootshim=1 Since you are booting with uInitrd, I would add root=LABELby bodhi - uBoot
Popo, Congrat! it's the wrong DTB, but if it works then use it :) just keep in mind this fact whenever you see something strange while the system is running. [ 3.737361] nand: Could not find valid ONFI parameter page; aborting [ 32.951370] oxnas-dwmac 40400000.ethernet eth0: No phy led trigger registered for speed(-1) The above are not errors. Just warnings, and safe to ignore.by bodhi - Rescue System
Peter, > Sorry to intrude here with a not (yet?) hacked > device, from a not (yet?) linuxhacker (:)), but > "you are my only hope". Wellcome! and no worry, we will help users at all level. > So I got a NSA310 from a friend, who had it run > for several years, when all of a sudden it was > unavailable. Upon restarting, after some blinking > for 30secs,by bodhi - uBoot
Thanks 1000001101000!by bodhi - uBoot
Popo, Good work! so far the booting looks good. As long as you can boot with SATA u-boot from HDD raw sector, you have many options. Now you can boot the USB rootfs, too. I suspect the kernel stuck at that point might be because it is too old or becasue the overlock 850Mhz. But I need to look at my notes to see. I'll be back shortly.by bodhi - Rescue System
Popo, [ 0.000000] Linux version 2.6.31.14_OX820_1.2_shv (root@plug2) (gcc version 4.4.5 (Debian 4.4.5-8) ) #1 SMP Fri Oct 4 11:38:10 CEST 2013 That indicated you're booting the wong kernel. So your HDD preparation is not correct. Which instruction did you follow? youxiaojie: https://forum.doozan.com/read.php?2,32994 or hacksome: https://forum.doozan.com/read.php?3,93499,93by bodhi - Rescue System
wibu, There is something in this u-boot I don't understand yet. The booting behavior is as though the kernel does not know where the RAM is and how big. Like the ATAG registers didn't pass along the memory characteristics. And what defined in the kernel DTS should be correct already. How about adding the mem option to the bootargs: setenv bootargs 'console=ttyS0,115200by bodhi - uBoot
Quote Marvell>> setenv bootargs console=ttyS0,115200 earlyprintk=serial initcall_debug loglevel=7 init=/bin/sh root=/dev/scsi/host2/bus0/target0/lun0/part2 Marvell>> tftpboot 0x800000 ix2-kw/uImage We don't care much about root at this point. So try setenv bootargs 'console=ttyS0,115200 root=/dev/sda1 rootdelay=10 earlyprintk=serial' tftpboot 0x1400000 ix2-by bodhi - uBoot
> PS : date of release is not november ? (writed > october) Yeah, it was a typo, thanks!by bodhi - Debian
Hold on, Geoff set it up a bit different from my default envs. Try setenv conf_usb 'usb reset; setenv boot_dev usb; setenv bootargs $(console) root=LABEL=usbroot earlyprintk=serial init=/bin/systemd' and then bootby bodhi - Debian
> To something like this? > > > fw_setenv set_bootargs 'setenv bootargs > console=ttyS0,115200 root=LABEL=rootfs > rootdelay=10 $mtdparts init=/bin/systemd' > > Not quite. You have other problems related to fw_setenv that I will come back tomorrow for those. Right now, add it to the bootargs in serial console. Like this, setenv usb_set_bootargby bodhi - Debian
DeDaMrAz, The rootfs is probably a bit old when Geoff wrote the instruction. It probably was Debian bullseye. In the old rootfs, systemd was at /bin, not /usr/bin. Your log got cut off, not a complete log, so a bit hard to tell the reason right way, I need to ask more questions. Starting kernel ... <important part in the first 4 sceonds is missing here> [ 4.103915][ Tby bodhi - Debian
> I was not able to boot 6.5.7 - tried everything > that I can find on this forum, no luck. It will > read USB but gives Bad Magic Number > end exits. Tried multiple USB drives and both ext2 > and ext3 format... > > However I was able to boot 5.18.7 from here - > https://minaret.biz/tips/ix2/index.html Cool! > You can see I tried to add > init=/usr/binby bodhi - Debian
Download at Dropbox linux-6.6.1-kirkwood-tld-2-bodhi.tar.bz2 md5: eedd7e0abe6327acc6ee409cd1d35767 sha256: 94cc4e5e1b95a366baf04960af197fbb5ff358986a59e075d6e9b6da2b26c56a Extract the zImage-6.6.1-kirkwood-tld-2 and orion5x-rd88f5182-nas.dtb from this tarball. And create the uImage. cp -a zImage-6.6.1-kirkwood-tld-2 zImage.fdt cat orion5x-rd88f5182-nas.dtb >> zImage.fdtby bodhi - uBoot
> I tried your rootfs Debian-6.5.7, but all binaries > give a segfault. Understandable. Let's wait until you can boot the new kernel and we can see it better. > I had earlier tried a cross-compile of a simple > write(1, "Simple\n", 7) hello world program, > and found this behavior seems to be traced to > incompatible EABI5. > The busybox (v1.00 !) thby bodhi - uBoot
QuoteThis guide troubled me so much that I didn’t know how to follow the instructions in the article. OK. This needs a bit of explaining. There are 3 ways to run Debian on this OXNAS SoC. There is also another way with OpenWrt u-boot, but it is out of scope as this is Debian we are interested in. 1. Running with stock u-boot on NAND, and Debian rootfs on USB or HDD Ext3/Ext4 parttion. 2.by bodhi - Rescue System
Sagittarius, Your box is a Kirkwood 88F6282 SoC, not Armada XP SoC like the DS214. DS212 is supported in mainline kernel with this DTB : kirkwood-ds212.dtb (looks like this DTB is for both 212 and 212+). So the installation will not be quite the same as Martin described for the DS214. Of course, other useful info specific to Synplogy are still applicable. You could just do a simple inby bodhi - Debian
cHIbINAb, > any update? just purchased a pogo pro biz. What Koen wrote in the first post is good to go. I don't see any problem.by bodhi - uBoot
wibu, This Orion5x SoC is very old, so I never thought about adding it to the Kirkwood kernel. But I think it is quite possible to configure it in and you can use the rootfs Debian-6.5.7-kirkwood-tld-1-rootfs-bodhi.tar.bz2 from the release thread: https://forum.doozan.com/read.php?2,12096 This basic rootfs is armel so it should work on Orion5x. I'll build an experimental kernel andby bodhi - uBoot
> the ping/tftpboot command in the U-boot function > on my machine. It always prompts that the PHY is > not recognized, and then it is waiting for the > connection to the TFTP Server without prompting. > timeout. So I think the manufacturer seems to have > taken advantage of a certain firmware update to > rewrite the U-boot program, causing the tftp boot > functionby bodhi - Rescue System