bodhi Wrote: ------------------------------------------------------- > > ===== > > If this box has not been frozen in OpenWrt, I > could try to send a pull request to add the > bootloader commandline capability to the kernel. I > think it must have been an oversight, because the > Kirkwood kernel in OpenWrt included this > capabilty, but the OXNAS kernel dby chessplayer - Rescue System
bodhi, sorry, but that does not make too much sense to me and I cannot really see the added value in this. In my eyes, the instructions are consistent and do make sense as they are. Also, it is steps 5 and 7 where we have a difference to the Kirkwood instructions, so I believe it is at these points where the issues should be mentioned. Cheers, chessplayerby chessplayer - Rescue System
bodhi, the first post is definitely updated: Edited 3 time(s). Last edit at 08/15/2022 01:44PM by chessplayer. Do you need to refresh the page, maybe? Cheers, chessplayerby chessplayer - Rescue System
bodhi, since I had not touched my Pogoplug Pro for a while, I tried the first post on it and, as expected, got as far as we had gotten on the classic before. So then I looked at your proposed tests again and decided to modify them a bit, not quite knowing whether that would be what you really needed, but at least it got me some more info. In principle, the idea was to leave the mtdparts definiby chessplayer - Rescue System
bodhi, thanks for taking the time to critically appraise my first post. I have implemented your suggestions and hope that we are now good to go searching for a solution. Cheers, chessplayerby chessplayer - Rescue System
bodhi, thanks, I am beginning to understand that and I will update my Kirkwood HowTo tomorrow. Also, I will update the first post here to reflect what we worked out so far. As always, thanks for the consideration. Cheers, chessplayerby chessplayer - Rescue System
bodhi, thanks for the explanation. I'll wait for your next suggestion and then conduct the tests you would like me to. Cheers, chessplayerby chessplayer - Rescue System
After the sysupgrade with the squasfs instead of the ubifs, the result is exactly the same: U-Boot 2015.10-tld-2 (Oct 21 2017 - 22:00:02 -0700) OXNAS OX820 gcc (Debian 6.3.0-18) 6.3.0 20170516 GNU ld (GNU Binutils for Debian) 2.28 Hit any key to stop autoboot: 10 0 OX820> setenv mtdparts 'mtdparts=41000000.nand:0x100000@0x0(u-boot),-@0x100000(ubi)' setenv mtdpartsby chessplayer - Rescue System
bodhi Wrote: ------------------------------------------------------- [... snap] > > No need to reinstall uboot. You can either reflash > the env image, and adjust it. > > Or just copy the entire default envs into > uEnv.txt. And boot into serial/net consile and > populate the envs, and save thems. Ok, that's what you mean, I do not have to re-install uBooby chessplayer - Rescue System
Ok, so now I re-installed uBoot and installed OpenWrt the following way: OX820> printenv mtdparts printenv mtdparts mtdparts=mtdparts=41000000.nand:14m(boot),-(data) OX820> nand erase.part data usb reset; fatload usb 0 0x60500000 ox_classic-uImage; bootm 0x60500000nand erase.part data NAND erase.part: device 0 offset 0xe00000, size 0x7200000 Erasing at 0x7fe0000 -- 100% completby chessplayer - Rescue System
So, I did all of these again and got the same results as above: setenv mtdparts 'mtdparts=41000000.nand:0x100000@0x0(u-boot),-@0x100000(ubi)' setenv partition 'nand0,0' ubi part ubi ubi info ubi info layout Then, I got (which seems like relevant info): OX820> ubifsmount ubi0:rootfs_data OX820> ubifsls etc ** File not found etc ** OX820> printenv ubifby chessplayer - Rescue System
bodhi, thanks for the hint. However, I am unclear on some points: Re-reading my Kirkwood-HowTo, I actually found that @daviddyer mentioned this early on, but, as you can see from my answer, I never had this issue on the Kirkwoods (and I can now even add the NSA320 and NSA325 to the list ...). However, it now seems to come to bite me that I did not just add it at the time, since it looks likby chessplayer - Rescue System
Hi bodhi, thanks for looking into this further. I'll report here what I found so far and will stop at the question as to how to proceed. What you should know beforehand is that I unbricked the box again can boot your latest OXNAS kernel with the latest rootfs do not have OpenWrt in NAND back again (as I just found out; see below) we could try the ubinized version for sysupgrade if yoby chessplayer - Rescue System
Thanks guys! chessplayer@cp-laptop:~$ nc -l -u -p 6666 U-Boot 2017.07-tld-1 (Sep 05 2017 - 00:21:31 -0700) Seagate GoFlex Home gcc (Debian 6.3.0-18) 6.3.0 20170516 GNU ld (GNU Binutils for Debian) 2.28 Hit any key to stop autoboot: 8 0 GoFlexHome> (hope you noticed that this is now netconsole ...). Now on to OpenWrt and finally having a real fallback for my trusted GoFlexHoby chessplayer - Debian
David, thanks. I probably use JTAG the wrong way, was aiming for the serial connection and kwboot (I am not an electronics person - otherwise I would, obviously, have a soldering iron ;-) ). Attached please find my current state of affairs. Now I will continue on the other end with a Nokia CA-42, with which I can connect individual wires. Hoping for the best ... Cheers, chessplayerby chessplayer - Debian
bodhi Wrote: ------------------------------------------------------- > Navi, > > > bash-3.2# fw_printenv ethaddr > > Warning: Bad CRC, using default environment > > ## Error: "ethaddr" not defined > > > ----------------------------------------------------------------- > > Is it ok to continue with your instructions > after > >by chessplayer - Debian
Hi bodhi, yes, I am aware of this. The problem is, however, that this is somewhat arbitrary and I wanted to be able to set up some kind of fileserver with hotplug capabilities, which I can also easily reboot, so that solution would not be practical. But putting the command into the standard bootcmd solved the issue for me, so all is well. Cheers, chessplayerby chessplayer - uBoot
Hi, I just wanted to report an issue I just had on a Pogo E02 concerning uEnv.txt. I wanted to use the file to use systemd and it worked about three or four times. However, since what I am testing is to have the box act as a file server in the Windows network with automount of the non-boot attached devices, I have more than one USB drive attached. It now looks that the attempt of reading uEnv.by chessplayer - uBoot
Hi guys, did you ever get anywhere with this? I am interested in the NSA325 and NSA320. Cheers, chessplayerby chessplayer - Debian
bodhi Wrote: ------------------------------------------------------- [...snap] > > Have you tried > > ubifsmount ubi0:mdt1 > So, after unbricking the OXNAS box, I tried this suggestion, but without success (preliminary steps as before): OX820> ubifsmount ubi0:mdt1 ubifsmount ubi0:mdt1 Error reading superblock on volume 'ubi0:mdt1' errno=-19! ubifby chessplayer - Rescue System
bodhi Wrote: ------------------------------------------------------- > QuoteConclusion: The /boot-directory did not > survive. Thus, if the file absolutely has to be in > /boot, it should be symlinked. However, since the > uBoot-env will have to be customized anyway, why > not just read it from /etc/config right away for > the OpenWrt boot? > > No it does not haveby chessplayer - Rescue System
bodhi Wrote: ------------------------------------------------------- > chessplayer, > > Sure, > > 1. Make sure the uEnv.txt will survive a > sysupgrade. Most important to find out first! if > it does not, then that will need to be a caveat > for users to save the file and restore. > I am pretty sure that nothing survives a sysupgrade except for files inby chessplayer - Rescue System
bodhi Wrote: ------------------------------------------------------- > This is my current thinking. A bit of experiement > needed to script the u-boot envs during boot so > that it can attach and read the ubi rootfs and > load a text file from it. > > It sounds overkilled, but this is probably the > only way, given the limitation of OpenWrt put on > us. And we doby chessplayer - Rescue System
chessplayer Wrote: ------------------------------------------------------- > Ok, one more thing: I now made this > mtdparts-definition permanent and had a look at > what we see in debian then: > root@debian ~ $ uname -a Linux debian 5.4.179-oxnas-tld-1 #1.0 SMP PREEMPT Mon Feb 14 21:50:21 PST 2022 armv6l GNU/Linux root@debian ~ $ cat /proc/cmdline console=ttyS0,115200 rooby chessplayer - Rescue System
Hi guys, any more suggestions what I could try? I am completely out of ideas (not that I had too many of them here) at this point. In the end, it might come down to David's "stable version" (I like that ;-) ). Cheers, chessplayerby chessplayer - Rescue System
bodhi Wrote: ------------------------------------------------------- > Hold on. > > By " with the calculated file I can read from, but > not write to uBoot-env." > > Do you mean the envs from my u-boot installation? I mean using /dev/mtd1 0xc0000 0x20000 0x20000 (which was calculated from the OpenWrt MTD-layout) instead of this /dev/mtd2 0x0 0by chessplayer - Rescue System
bodhi Wrote: ------------------------------------------------------- > chessplayer, > > I meant forget about Debian for a moment. Run the > sysupgrade to flash "kernel' and "ubi' partitions > inside OpenWrt. > > After that, you will run OpenWrt from flash. So if > the "u-boot-env" partition was touched by the > sysupgrade proceby chessplayer - Rescue System
Actually, this is what I did during installation, but I can, of course, just do this once more.by chessplayer - Rescue System
bodhi Wrote: ------------------------------------------------------- > Ok I think I have a good solution. > > But I still would like to know if sysupgrade > writes to OpenWrt "u-boot-env" mtd partition first > to make sure the solution is sound. Well, without trying this again, this would just be at /dev/mtd2 0x0, reflecting the original fw_env.config from Opeby chessplayer - Rescue System
Ok, one more thing: I now made this mtdparts-definition permanent and had a look at what we see in debian then: root@debian ~ $ uname -a Linux debian 5.4.179-oxnas-tld-1 #1.0 SMP PREEMPT Mon Feb 14 21:50:21 PST 2022 armv6l GNU/Linux root@debian ~ $ cat /proc/cmdline console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 mtdparts=41000000.nand:0x100000@0x0(u-boot),0x20000@0x100000(u-boot-env-by chessplayer - Rescue System