Welcome! Log In Create A New Profile

Advanced

HowTo: openWrt on OXNAS boxes

Posted by chessplayer 
Re: HowTo: openWrt on OXNAS boxes
August 02, 2022 07:20PM
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 0x20000 0x20000

(OpenWrt original) in fw_env.config

Cheers,

chessplayer

P.S.: Awake - not fully anymore, so anything else will have to happen tomorrow ...

---
Standart ist der Standardfehler
Re: HowTo: openWrt on OXNAS boxes
August 03, 2022 01:56PM
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,

chessplayer

---
Standart ist der Standardfehler
Re: HowTo: openWrt on OXNAS boxes
August 03, 2022 02:29PM
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 root=LABEL=rootfs
rootdelay=10
mtdparts=41000000.nand:0x100000@0x0(u-boot),0x20000@0x100000(u-boot-env-main),0x80000@0x3c0000(u-boot-env),0x440000@0x9C0000(kernel),-(ubi)
root@debian ~ $ cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00e00000 00020000 "boot"
mtd1: 07200000 00020000 "data"
root@debian ~ $ dmesg | grep -i 0x0
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Kernel command line: console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 mtdparts=41000000.nand:0x100000@0x0(u-boot),0x20000@0x100000(u-boot-env-main),0x80000@0x3c0000(u-boot-env),0x440000@0x9C0000(kernel),-(ubi)
[    8.477432] 0x000000000000-0x000000e00000 :"boot"
[    8.485373] 0x000000e00000-0x000008000000 :"data"
root@debian ~ $ fw_printenv | tail -n 5
partition=nand0,0
set_bootargs_owrt=setenv bootargs console=ttyS0,115200 $mtdparts
bootcmd_owrt=run set_bootargs_owrt; nboot 60500000 0 440000; bootm
bootcmd=run bootcmd_uenv; run scan_disk; run set_bootargs; run bootcmd_exec; run bootcmd_owrt
mtdparts=mtdparts=41000000.nand:0x100000@0x0(u-boot),0x20000@0x100000(u-boot-env-main),0x80000@0x3c0000(u-boot-env),0x440000@0x9C0000(kernel),-(ubi)
root@debian ~ $
>
> Maybe this is also of interest. I will now check
> what this does in OpenWrt. And, to answer my own
> question, the result is the same as above
> (Bootloader command line (ignored) ).

Actually, I would like to come back to this with a question: Should there not be a modified MTD-layout here as well after passing it in the uBoot-env? The debian MTD-layout is also not influenced by the setting in the uBoot-env, it seems to me...

As I said before: confused!

Cheers,

chessplayer

---
Standart ist der Standardfehler
Re: HowTo: openWrt on OXNAS boxes
August 03, 2022 04:27PM
chessplayer,

What you see in Debian is a better implementation. We have new u-boot defines the envs location at 1MB in flash. The DTS has mtd0 as writeable. And the Debian kernel was configured to accept the bootargs (command line arguments). So everything works.

On OpenWrt side, it's the other way around. The envs are at a different location. The MTDs are protected by read-only property in the DTS. And the OPenWrt kernel was not configured to accept the command line arguments. So we cannot change the envs at all.

Note that the only hurdle here is the command line arguments. If the OpenWrt kernel had this configured in, then we would be able to pass mtdparts into the kernel and everything will fall into place. But we don't want to recompile the kernel, or try to marry the Debian DTB file to OpenWrt kernel. Sysupgrade will wipe that out each time, and things will be confusing for the users.

So that where your confusion was.

====

OK, so now you guys have found a work around to specify the location of the envs from my u-boot. And can read them. It's half of the solution. Let me write in the next post the other half. To complete a relatively cookie cutter process.

-bodhi
===========================
Forum Wiki
bodhi's corner
Re: HowTo: openWrt on OXNAS boxes
August 03, 2022 05:28PM
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 dont want to recompile its kernel.

==========

Reference to the u-boot installation instruction: 2015.10 U-Boot for Pogoplug V3 (OXNAS OX820).

To be able to "set" envs in OpenWrt and let the new u-boot read it, we need to use uEnv.txt capability. This was mentioned in the installation Section A.

Quote

A. How to use the uEnv.txt script (Optional)

This uEnv.txt script can be used to further customizing u-boot envs without saving to NAND or to boot with a completely different set of u-boot envs.

Create a text file in /boot directory with the content in the format that u-boot envs are listed.

==========

Testing steps

1. Log in to OpenWrt and create uEnv.txt with the initial content as below

mkdir -p /boot
cd /boot

Use nano to edit this file (to ensure it is a proper text file)
nano uEnv.txt

Add this single line
loaded_envs=See_uEnv.txt_from_rootfs
Exit and save the file.

2. Reboot

2.1 Attach ubi partition

(TBD)

2.2 List the OpenWrt directory to find the exact location of uEnv.txt.

(TBD) The UBIFS volume is probably the first letter, and eventually down that path, we'll find uEnv.txt.

2.3 Setup u-boot env to load it.

(TBD) The current bootcmd_uenv scans and loads uEnv.txt from disk storage. So we need to adjust this to load from the UBIFS volume.

2.4 Test print

printenv loaded_envs

-bodhi
===========================
Forum Wiki
bodhi's corner



Edited 1 time(s). Last edit at 08/03/2022 05:30PM by bodhi.
Re: HowTo: openWrt on OXNAS boxes
August 03, 2022 05:33PM
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 dont want to recompile its kernel.
>
> ==========
>
> Reference to the u-boot installation instruction:
> 2015.10
> U-Boot for Pogoplug V3 (OXNAS OX820)
.
>
> To be able to "set" envs in OpenWrt and let the
> new u-boot read it, we need to use uEnv.txt
> capability. This was mentioned in the installation
> Section A.
>
>
Quote

A. How to use the uEnv.txt script
> (Optional)
>
> This uEnv.txt script can be used to further
> customizing u-boot envs without saving to NAND or
> to boot with a completely different set of u-boot
> envs.
>
> Create a text file in /boot directory with the
> content in the format that u-boot envs are
> listed.
>
> ==========
>
> Testing steps
>
> 1. Log in to OpenWrt and create uEnv.txt with the
> initial content as below
>
>
> mkdir -p /boot
> cd /boot
>
>
> Use nano to edit this file (to ensure it is a
> proper text file)
>
> nano uEnv.txt
>
>
> Add this single line
>
> loaded_envs=See_uEnv.txt_from_rootfs
>
> Exit and save the file.
>
> 2. Reboot
>
> 2.1 Attach ubi partition
>
> (TBD)
>
> 2.2 List the OpenWrt directory to find the exact
> location of uEnv.txt.
>
> (TBD) The UBIFS volume is probably the first
> letter, and eventually down that path, we'll find
> uEnv.txt.
>
> 2.3 Setup u-boot env to load it.
>
> (TBD) The current bootcmd_uenv scans and loads
> uEnv.txt from disk storage. So we need to adjust
> this to load from the UBIFS volume.
>
> 2.4 Test print
>
>
> printenv loaded_envs
>

Anything I can do to help?

Cheers,

chessplayer

---
Standart ist der Standardfehler
Re: HowTo: openWrt on OXNAS boxes
August 03, 2022 06:49PM
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.

2. Boot with serial/neconsole. Interrupt u-boot and

setenv mtdparts 'mtdparts=orion_nand:0x100000@0x0(u-boot),-@0x100000(ubi)'
setenv partition 'nand0,0'
ubi part ubi
ubi info
volume name should be in the output.

Mount it
ubifsmount <volume name>

List files in /boot
ubifsls boot

-bodhi
===========================
Forum Wiki
bodhi's corner



Edited 1 time(s). Last edit at 08/03/2022 06:55PM by bodhi.
Re: HowTo: openWrt on OXNAS boxes
August 03, 2022 06:54PM
Other thought: we can also file a "bug" report at OpenWrt site to request for this OXNAS kernel processes the bootargs passed into by u-boot :)

-bodhi
===========================
Forum Wiki
bodhi's corner
Re: HowTo: openWrt on OXNAS boxes
August 04, 2022 01:50PM
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 in /etc/config (see the output of 'sysupgrade -v' in David's post further up). So, here is my test, which I performed with an addition. Booted into OpenWrt and then:

mkdir -p /boot
cd /boot
nano uEnv.txt
# wrote loaded_envs=See_uEnv.txt_from_rootfs

Additionally:

# this should survive
cp uEnv.txt /etc/config/

Now the sysupgrade (went back to the latest stable version)

cd /tmp
wget https://downloads.openwrt.org/releases/21.02.3/targets/oxnas/ox820/openwrt-21.02.3-oxnas-ox820-cloudengines_pogoplug-series-3-squashfs-sysupgrade.tar
sysupgrade -v openwrt-21.02.3-oxnas-ox820-cloudengines_pogoplug-series-3-squashfs-sysupgrade.tar

root@OpenWrt:/tmp# sysupgrade -v openwrt-21.02.3-oxnas-ox820-cloudengines_pogoplug-series-3-squashfs-sysupgrade.tar
Thu Aug  4 17:52:47 UTC 2022 upgrade: Saving config files...
etc/config/dropbear
etc/config/firewall
etc/config/fstab
etc/config/luci
etc/config/mdadm
etc/config/network
etc/config/rpcd
etc/config/system
etc/config/uEnv.txt
etc/config/ubootenv
etc/config/ubootenv_bodhi
etc/config/ubootenv_owrt
etc/config/ubootenv_test1
etc/config/ubootenv_test2
etc/config/ucitrack
etc/config/uhttpd
etc/dropbear/dropbear_ed25519_host_key
etc/dropbear/dropbear_rsa_host_key
etc/fw_env.config
etc/group
etc/hosts
etc/inittab
etc/luci-uploads/.placeholder
etc/opkg/keys/2f8b0b98e08306bf
etc/opkg/keys/4d017e6f1ed5d616
etc/passwd
etc/profile
etc/rc.local
etc/shadow
etc/shells
etc/shinit
etc/sysctl.conf
etc/uhttpd.crt
etc/uhttpd.key
etc/uhttpd.key
etc/uhttpd.crt
Thu Aug  4 17:52:47 UTC 2022 upgrade: Commencing upgrade. Closing all shell sessions.
Command failed: Connection failed
root@OpenWrt:/tmp# Connection to 192.168.XXX.YYY closed by remote host.

As you can see (green line), uEnv.txt in /etc/config can be expected to survive (and forget about the red line - the sysupgrade works). Let's test that:

BusyBox v1.33.2 (2022-04-16 12:59:34 UTC) built-in shell (ash)

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------
 OpenWrt 21.02.3, r16554-1d4dea6d4f
 -----------------------------------------------------
=== WARNING! =====================================
There is no root password defined on this device!
Use the "passwd" command to set up a new password
in order to prevent unauthorized SSH logins.
--------------------------------------------------
root@OpenWrt:~# cd /boot
-ash: cd: can't cd to /boot: No such file or directory
root@OpenWrt:~# cat /etc/config/uEnv.txt 
loaded_envs=See_uEnv.txt_from_rootfs
root@OpenWrt:~#

Conclusion: 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?

> 2. Boot with serial/neconsole. Interrupt u-boot
> and
>
>
> setenv mtdparts
> 'mtdparts=orion_nand:0x100000@0x0(u-boot),-@0x100000(ubi)'
> setenv partition 'nand0,0'
> ubi part ubi
> ubi info
>
> volume name should be in the output.

First of all, I think this has to start with:
setenv mtdparts 'mtdparts=41000000.nand:0x100000@0x0(u-boot),-@0x100000(ubi)'

So, this is as far as I got, since I am obviously too stupid to specify the volume name:

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:  8 
 0 
OX820> setenv mtdparts 'mtdparts=41000000.nand:0x100000@0x0(u-boot),-@0x100000(ubi)'
setenv mtdparts 'mtdparts=41000000.nand:0x100000@0x0(u-boot),-@0x100000(ubi)'
OX820> setenv partition 'nand0,0'
setenv partition 'nand0,0'
OX820> ubi part ubi
ubi part ubi
UBI: attaching mtd1 to ubi0
UBI: scanning is finished
UBI: attached mtd1 (name "mtd=1", size 127 MiB) to ubi0
UBI: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes
UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 512
UBI: VID header offset: 512 (aligned 512), data offset: 2048
UBI: good PEBs: 1016, bad PEBs: 0, corrupted PEBs: 0
UBI: user volume: 2, internal volumes: 1, max. volumes count: 128
UBI: max/mean erase counter: 6/3, WL threshold: 4096, image sequence number: 834073264
UBI: available PEBs: 104, total reserved PEBs: 912, PEBs reserved for bad PEB handling: 20
OX820> ubi info
ubi info
UBI: MTD device name:            "mtd=1"
UBI: MTD device size:            127 MiB
UBI: physical eraseblock size:   131072 bytes (128 KiB)
UBI: logical eraseblock size:    129024 bytes
UBI: number of good PEBs:        1016
UBI: number of bad PEBs:         0
UBI: smallest flash I/O unit:    2048
UBI: VID header offset:          512 (aligned 512)
UBI: data offset:                2048
UBI: max. allowed volumes:       128
UBI: wear-leveling threshold:    4096
UBI: number of internal volumes: 1
UBI: number of user volumes:     2
UBI: available PEBs:             104
UBI: total number of reserved PEBs: 912
UBI: number of PEBs reserved for bad PEB handling: 20
UBI: max/mean erase counter: 6/3
OX820> ubifsmount /dev/mtd1
ubifsmount /dev/mtd1
Error reading superblock on volume '/dev/mtd1' errno=-22!
ubifsmount - mount UBIFS volume

Usage:
ubifsmount <volume-name>
    - mount 'volume-name' volume
OX820> ubifsmount mtd=1
ubifsmount mtd=1
Error reading superblock on volume 'mtd=1' errno=-22!
ubifsmount - mount UBIFS volume

Usage:
ubifsmount <volume-name>
    - mount 'volume-name' volume
OX820> ubifsmount mtd1
ubifsmount mtd1
Error reading superblock on volume 'mtd1' errno=-22!
ubifsmount - mount UBIFS volume

Usage:
ubifsmount <volume-name>
    - mount 'volume-name' volume
OX820> ubifsmount ubi0
ubifsmount ubi0
Error reading superblock on volume 'ubi0' errno=-22!
ubifsmount - mount UBIFS volume

Usage:
ubifsmount <volume-name>
    - mount 'volume-name' volume
OX820> ubifsmount ubi0_0
ubifsmount ubi0_0
Error reading superblock on volume 'ubi0_0' errno=-22!
ubifsmount - mount UBIFS volume

Usage:
ubifsmount <volume-name>
    - mount 'volume-name' volume
OX820> ubifsmount ubi:mtd1
ubifsmount ubi:mtd1
Error reading superblock on volume 'ubi:mtd1' errno=-19!
ubifsmount - mount UBIFS volume

Usage:
ubifsmount <volume-name>
    - mount 'volume-name' volume
OX820> ubifsmount ubi:mtd=1
ubifsmount ubi:mtd=1
Error reading superblock on volume 'ubi:mtd=1' errno=-19!
ubifsmount - mount UBIFS volume

Usage:
ubifsmount <volume-name>
    - mount 'volume-name' volume
OX820> 

OX820>

This did not help either (as you can see at the bottom of the above code).

Please advise!

Cheers,

chessplayer

---
Standart ist der Standardfehler
Re: HowTo: openWrt on OXNAS boxes
August 04, 2022 03:57PM
Quote

Conclusion: 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 have to be in /boot. /etc/config is fine!

Have you tried
ubifsmount ubi0:mdt1

-bodhi
===========================
Forum Wiki
bodhi's corner
Re: HowTo: openWrt on OXNAS boxes
August 04, 2022 04:09PM
bodhi Wrote:
-------------------------------------------------------
>
Quote

Conclusion: 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 have to be in /boot. /etc/config is
> fine!
Great!
>
> Have you tried
>
> ubifsmount ubi0:mdt1
>

No, seems like this is the one combination I haven't tried ;-)

Anyway, it looks like the last sysupgrade broke something, since the box is not picked up anymore by netconsole during boot and it does not boot OpenWrt anymore ... I am currently trying to boot your debian from stick and hope for the best - if it does not work, I might have to try reinstalling the rescue system, but then I do not know how to update the envs ...

Just realized that this won't work either, since I cannot install OpenWrt without access to nc ..

Will get back once this is sorted out but it may take some time, since I will be out of town tomorrow!

Cheers,

chessplayer

---
Standart ist der Standardfehler



Edited 1 time(s). Last edit at 08/04/2022 04:12PM by chessplayer.
Re: HowTo: openWrt on OXNAS boxes
August 07, 2022 05:13PM
bodhi Wrote:
-------------------------------------------------------
[snip ...]
[...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!
ubifsmount - mount UBIFS volume

Usage:
ubifsmount <volume-name>
    - mount 'volume-name' volume
OX820>

Now, in OpenWrt, I checked the available blocks beforehand:

root@OpenWrt:~# blkid
/dev/ubi0_1: UUID="eaa436ab-920d-454c-b47b-de15f9a5db60" TYPE="ubifs"
/dev/ubi0_0: TYPE="squashfs"
/dev/mtdblock4: UUID="834073264" TYPE="ubi"
/dev/ubiblock0_0: TYPE="squashfs"
root@OpenWrt:~#

That made me wonder (but not enough, apparently):

OX820> ubifsmount ubi0_0:mdt1
ubifsmount ubi0_2:mdt1
Error reading superblock on volume 'ubi0_0:mdt1' errno=-22!
ubifsmount - mount UBIFS volume

Usage:
ubifsmount <volume-name>
    - mount 'volume-name' volume
OX820> ubifsmount ubi0_1:mtd1    
ubifsmount ubi0_1:mtd1
Error reading superblock on volume 'ubi0_1:mtd1' errno=-22!
ubifsmount - mount UBIFS volume

Usage:
ubifsmount <volume-name>
    - mount 'volume-name' volume
OX820>

What now (or rather: tomorrow ...)?

Cheers,

chessplayer

P.S.: These commands apparently bricked the device again! So, I have to be extremely careful when performing the tests, it would seem ... I am confused!

---
Standart ist der Standardfehler
Re: HowTo: openWrt on OXNAS boxes
August 07, 2022 07:00PM
Hi chessplayer,

> P.S.: These commands apparently bricked the
> device again!


Arghhh :)

Let's regroup. I think we are trying too much to get around this limitation without examining the flash structure created by OpenWrt installation and sysupgrade.

For now it's a caveat in the installation: that you can only read from the envs inside Openwrt, but can only update it in serial/net console.

I have to boot up my Pogo V3 (it's on the shelf). I need to build new Debian stable kernel anyway. So will see what I will find out.

-bodhi
===========================
Forum Wiki
bodhi's corner
Re: HowTo: openWrt on OXNAS boxes
August 07, 2022 08:53PM
bodhi Wrote:
-------------------------------------------------------

> For now it's a caveat in the installation: that
> you can only read from the envs inside Openwrt,
> but can only update it in serial/net console.
>
Curious as to why you can't update envs in OpenWrt? The uboot-env partition is not set read-only.

+		partition@3c0000 {
+			label = "u-boot-env";
+			reg = <0x003c0000 0x00080000>;
+		};

This should allow editing the environment after installing the uboot-envtools package and creating the appropriate config file.
Re: HowTo: openWrt on OXNAS boxes
August 07, 2022 10:28PM
rayknight,

You should read the whole thread!

I will boot up my Pogo V3 and see for myself. But it does make sense to me from what I've seen in this thread that OpenWrt can not write to it currenly.

-bodhi
===========================
Forum Wiki
bodhi's corner
Re: HowTo: openWrt on OXNAS boxes
August 12, 2022 07:37PM
Hi chessplayer,

I've not been able to boot up my Pogo V3 yet. But I've looked at my old notes. Wow 5,6 years ago :) I created a Kirkwood rescue system but never release it.

ubi part ubi
ubi info
ubi info layout

If you see the volume rootfs_data from the layout, try mounting it. It seems to be OpenWrt standard naming convetion used also in Kirkwood boards.

ubifsmount ubi0:rootfs_data

That should be the overlay part of the system (formatted in ubifs). The rootfs volume cannot be mounted, since it is a squashfs. I don't believe this u-boot even knows squash.

Boot into OpenWrt and

mount
It should show the rootfs mounted with squashfs. And the /overlay is ubifs. The upper layer of the root file system is etc. (it's overlaid on top) So that's why /etc/config is sticky and not got overwritten by sysupgrade.

-bodhi
===========================
Forum Wiki
bodhi's corner
Re: HowTo: openWrt on OXNAS boxes
August 13, 2022 09:58AM
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
  1. unbricked the box again
  2. can boot your latest OXNAS kernel with the latest rootfs
  3. do not have OpenWrt in NAND back again (as I just found out; see below)
  4. we could try the ubinized version for sysupgrade if you think that helps?

What you will see from the logs to follow is that the OpenWrt in RAM cannot read your uBoot-env, which kind of makes me wonder how it is that it can nevertheless boot your system from stick ... (for the real conclusion scroll down to the P.S.) But, in particular, I am reluctant to install OpenWrt in this situation, since I do not want to brick the box again (-> I am a moron!)

0. in uBoot

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 mtdparts 'mtdparts=41000000.nand:0x100000@0x0(u-boot),-@0x100000(ubi)'
OX820> setenv partition 'nand0,0'
setenv partition 'nand0,0'
OX820> ubi part ubi
ubi part ubi
UBI: attaching mtd1 to ubi0
UBI: scanning is finished
UBI: attached mtd1 (name "mtd=1", size 127 MiB) to ubi0
UBI: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes
UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 512
UBI: VID header offset: 512 (aligned 512), data offset: 2048
UBI: good PEBs: 1016, bad PEBs: 0, corrupted PEBs: 0
UBI: user volume: 2, internal volumes: 1, max. volumes count: 128
UBI: max/mean erase counter: 6/3, WL threshold: 4096, image sequence number: 834073264
UBI: available PEBs: 104, total reserved PEBs: 912, PEBs reserved for bad PEB handling: 20
OX820> ubi info
ubi info
UBI: MTD device name:            "mtd=1"
UBI: MTD device size:            127 MiB
UBI: physical eraseblock size:   131072 bytes (128 KiB)
UBI: logical eraseblock size:    129024 bytes
UBI: number of good PEBs:        1016
UBI: number of bad PEBs:         0
UBI: smallest flash I/O unit:    2048
UBI: VID header offset:          512 (aligned 512)
UBI: data offset:                2048
UBI: max. allowed volumes:       128
UBI: wear-leveling threshold:    4096
UBI: number of internal volumes: 1
UBI: number of user volumes:     2
UBI: available PEBs:             104
UBI: total number of reserved PEBs: 912
UBI: number of PEBs reserved for bad PEB handling: 20
UBI: max/mean erase counter: 6/3
OX820> ubi info layout
ubi info layout
Volume information dump:
	vol_id          0
	reserved_pebs   24
	alignment       1
	data_pad        0
	vol_type        3
	name_len        6
	usable_leb_size 129024
	used_ebs        24
	used_bytes      3096576
	last_eb_bytes   129024
	corrupted       0
	upd_marker      0
	name            rootfs
Volume information dump:
	vol_id          1
	reserved_pebs   864
	alignment       1
	data_pad        0
	vol_type        3
	name_len        11
	usable_leb_size 129024
	used_ebs        864
	used_bytes      111476736
	last_eb_bytes   129024
	corrupted       0
	upd_marker      0
	name            rootfs_data
Volume information dump:
	vol_id          2147479551
	reserved_pebs   2
	alignment       1
	data_pad        0
	vol_type        3
	name_len        13
	usable_leb_size 129024
	used_ebs        2
	used_bytes      258048
	last_eb_bytes   2
	corrupted       0
	upd_marker      0
	name            layout volume
OX820> ubifsmount ubi0:rootfs_data
ubifsmount ubi0:rootfs_data
OX820> run bootcmd_owrt
run bootcmd_owrt

Loading from nand0, offset 0x440000
** Unknown image type
Wrong Image Format for bootm command
ERROR: can't get kernel image!
OX820>

So, spot on, bodhi, the rootfs_data volume can be ubifsmounted, but, apparently, the OpenWrt installation in NAND did not survive the brick status ...

So, next step: try installing it to NAND again:

1. Boot OpenWrt uImage to RAM

OX820> usb reset; fatload usb 0 0x60500000 ox_classic-uImage; bootm 0x60500000
usb reset; fatload usb 0 0x60500000 ox_classic-uImage; bootm 0x60500000
resetting USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... 3 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
reading ox_classic-uImage
7188634 bytes read in 231 ms (29.7 MiB/s)
## Booting kernel from Legacy Image at 60500000 ...
   Image Name:   ARM OpenWrt Linux-5.4.188
   Created:      2022-04-16  12:59:34 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    7188570 Bytes = 6.9 MiB
   Load Address: 60008000
   Entry Point:  60008000
   Verifying Checksum ... OK


Starting kernel ...

So, all is well. Let's see what we get when we log in.

2. inside OpenWrt in RAM

root@OpenWrt:~# fw_printenv
Warning: Bad CRC, using default environment
bootcmd=bootp; setenv bootargs root=/dev/nfs nfsroot=${serverip}:${rootpath} ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}::off; bootm
bootdelay=5
baudrate=115200
root@OpenWrt:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00040000 00020000 "stage1"
mtd1: 00380000 00020000 "u-boot"
mtd2: 00080000 00020000 "u-boot-env"
mtd3: 009c0000 00020000 "kernel"
mtd4: 07200000 00020000 "ubi"
root@OpenWrt:~# cat /etc/fw_env.config 
/dev/mtd2 0x0 0x2000 0x2000 1
root@OpenWrt:~# echo '/dev/mtd1 0xc0000 0x20000 0x20000' > /etc/fw_env.config
root@OpenWrt:~# fw_printenv bootcmd_owrt
Warning: Bad CRC, using default environment
## Error: "bootcmd_owrt" not defined
root@OpenWrt:~# mount
tmpfs on / type tmpfs (rw,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,noatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,noatime)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime)
tmpfs on /dev type tmpfs (rw,nosuid,relatime,size=512k,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,mode=600,ptmxmode=000)
debugfs on /sys/kernel/debug type debugfs (rw,noatime)
none on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,noatime,mode=700)
root@OpenWrt:~#

So, OpenWrt no cannot read the uBoot-env as it was able to before!

Therefore, I believe what I should do now is:
  1. re-install your uBoot for good measure
  2. only then install OpenWrt to NAND again

Would you agree?

Cheers,

chessplayer

P.S.: I thought this would be it BUT THE ABOVE PROCEDURE BRICKED THE BOX AGAIN - that is apparently what OpenWrt not being able to find the uBoot-env when booted into RAM was trying to tell me and I, of course, wasn't listening ... Off to fetch the CA-42 again, since netconsole is, for obvious reasons, not available anymore either - no, hold on, uEnv.txt does the trick, as we have learned ... :-)


EDIT: So, after the rant, I must make it clear that the "brick" is just a semi-brick, since using uEnv.txt I can boot debian, but, obviously, uBoot has to be re-installed and also OpenWrt. This is the current state of affairs and I am ready for the next tests ...

---
Standart ist der Standardfehler



Edited 1 time(s). Last edit at 08/13/2022 01:18PM by chessplayer.
Re: HowTo: openWrt on OXNAS boxes
August 13, 2022 01:22PM
Hi chessplayer,

No need to reinstall u-boot.

You've missed a recommended step in the installation. Joerg have mentioned this (now that I reread his post and tried it myself on the NSA310S).


Quote

# bootenvs for Pogo E02 based on uboot.2016.05-tld-1.environment:

setenv mtdparts 'mtdparts=orion_nand:0x100000@0x0(u-boot),-@0x100000(ubi)'
setenv partition 'nand0,0'
setenv set_bootargs_lede 'setenv bootargs console=ttyS0,115200 $mtdparts'
setenv bootcmd_lede 'run set_bootargs_lede; ubi part ubi; ubi read 0x800000 kernel; bootm 0x800000'
setenv bootcmd 'run bootcmd_uenv; run scan_disk; run set_bootargs; run bootcmd_exec; run bootcmd_lede'
setenv bootcmd_exec 'if run load_uimage; then; if run load_initrd; then if run load_dtb; then bootm $load_uimage_addr $load_initrd_addr $load_dtb_addr; else bootm $load_uimage_addr $load_initrd_addr; fi; else if run load_dtb; then bootm $load_uimage_addr - $load_dtb_addr; else bootm $load_uimage_addr; fi; fi; fi'
saveenv
nand erase.part ubi

# when you change/add a new partition layout you always need to erase the ubi nand first before new install:
nand erase.part ubi

So I think the reason for unsuccesful reinstall is sysupgrade behavior when the partition is not empty.

I have not modified your Kirkwood installation post to mention this, but you should after confirmation.

==========

Now continuing with the serial/net console info gathering,

ubifsmount ubi0:rootfs_data
ubifsls etc
ubifsls etc/config

-bodhi
===========================
Forum Wiki
bodhi's corner



Edited 1 time(s). Last edit at 08/13/2022 01:24PM by bodhi.
Re: HowTo: openWrt on OXNAS boxes
August 13, 2022 02:01PM
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 like the OXNAS' really want to have this.

But, what do you mean by 'confirmation'? How would I test, whether this is necessary? Or, better yet, where exactly would you add this command? It is my understanding, that step 4. (when booting OpenWrt into RAM) should be:

nand erase.part data
usb reset; fatload usb 0 0x60500000 uImage; bootm 0x60500000

(the nand.erase should be on the data-partion with this mtdparts-definition, shouldn't it?
fw_setenv mtdparts 'mtdparts=41000000.nand:14m(boot),-(data)'
)

Then, sysupgrade should proceed (but it does so also without it, as long as I re-install your uBoot - so which positive effect is it you are expecting? I do not quite understand - sorry about being a noob and doing trial and error here). Will report on the further tests soon.

Cheers,

chessplayer

EDIT: I think the question is whether you assume the mtdparts definition we should be using for the tests or the one we still have in the uBoot-env. For the tests we do:
setenv mtdparts 'mtdparts=41000000.nand:0x100000@0x0(u-boot),-@0x100000(ubi)'

---
Standart ist der Standardfehler



Edited 1 time(s). Last edit at 08/13/2022 02:04PM by chessplayer.
Re: HowTo: openWrt on OXNAS boxes
August 13, 2022 02:29PM
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
ubifsls etc/configprintenv
** File not found etc/configprintenv **

Also, I can now only boot into debian again with the uEnv.txt as mentioned (so, no more netconsole). When I do that, I get:

┌─[root@pogov3]─[~]
└──> fw_printenv | head -n 5
Warning: Bad CRC, using default environment
bootcmd=run distro_bootcmd
bootdelay=2
baudrate=115200
stdin=serial,cros-ec-keyb,usbkbd
stdout=serial,vidconsole

So, it seems to me that I WILL have to re-install uBoot at this point, won't I (at least if I want to use netconsole - with the serial cable, the situation might be different). I will go ahead and do this later and then I will see what happened to OpenWrt ...

Cheers,

chessplayer

---
Standart ist der Standardfehler
Re: HowTo: openWrt on OXNAS boxes
August 13, 2022 04:15PM
ubifsls /
ubifsls /etc

And so on.....

-bodhi
===========================
Forum Wiki
bodhi's corner
Re: HowTo: openWrt on OXNAS boxes
August 13, 2022 05:17PM
chessplayer Wrote:
-------------------------------------------------------
> 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
> ubifsls etc/configprintenv
> ** File not found etc/configprintenv **
>
>
> Also, I can now only boot into debian again with
> the uEnv.txt as mentioned (so, no more
> netconsole). When I do that, I get:
>
>
> ┌─[root@pogov3]─[~]
> └──> fw_printenv | head -n 5
> Warning: Bad CRC, using default environment
> bootcmd=run distro_bootcmd
> bootdelay=2
> baudrate=115200
> stdin=serial,cros-ec-keyb,usbkbd
> stdout=serial,vidconsole
>
>
> So, it seems to me that I WILL have to re-install
> uBoot at this point, won't I (at least if I want
> to use netconsole - with the serial cable, the
> situation might be different). I will go ahead and
> do this later and then I will see what happened to
> OpenWrt ...
>
> Cheers,
>
> chessplayer

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.

-bodhi
===========================
Forum Wiki
bodhi's corner
Re: HowTo: openWrt on OXNAS boxes
August 13, 2022 05:24PM
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% complete.
OK
OX820> usb reset; fatload usb 0 0x60500000 ox_classic-uImage; bootm 0x60500000
usb reset; fatload usb 0 0x60500000 ox_classic-uImage; bootm 0x60500000
resetting USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... 3 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
reading ox_classic-uImage
7188634 bytes read in 231 ms (29.7 MiB/s)
## Booting kernel from Legacy Image at 60500000 ...
   Image Name:   ARM OpenWrt Linux-5.4.188
   Created:      2022-04-16  12:59:34 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    7188570 Bytes = 6.9 MiB
   Load Address: 60008000
   Entry Point:  60008000
   Verifying Checksum ... OK


Starting kernel ...

In OpenWrt in RAM I did the usual, but then tried the ubifs instead of the squashfs

root@OpenWrt:/tmp# wget https://downloads.openwrt.org/releases/21.02.3/targets/oxnas/ox820/openwrt-21.02.3-oxnas-ox820-cloudengines_pogoplug-series-3-ubifs-sysupgrade.tar
Downloading 'https://downloads.openwrt.org/releases/21.02.3/targets/oxnas/ox820/openwrt-21.02.3-oxnas-ox820-cloudengines_pogoplug-series-3-ubifs-sysupgrade.tar';
Connecting to 168.119.138.211:443
Writing to 'openwrt-21.02.3-oxnas-ox820-cloudengines_pogoplug-series-3-ubifs-sysupgrade.tar'
openwrt-21.02.3-oxna 100% |*******************************| 10180k  0:00:00 ETA
Download completed (10424689 bytes)
root@OpenWrt:/tmp# sysupgrade openwrt-21.02.3-oxnas-ox820-cloudengines_pogoplug-series-3-ubifs-sysupgrade.tar 
Cannot save config while running from ramdisk.
Sat Aug 13 22:02:49 UTC 2022 upgrade: Commencing upgrade. Closing all shell sessions.

This led to (in uBoot):

OX820> setenv mtdparts 'mtdparts=41000000.nand:0x100000@0x0(u-boot),-@0x100000(ubi)'
setenv mtdparts 'mtdparts=41000000.nand:0x100000@0x0(u-boot),-@0x100000(ubi)'
OX820> setenv partition 'nand0,0'
setenv partition 'nand0,0'
OX820> ubi part ubi
ubi part ubi
UBI: attaching mtd1 to ubi0
UBI init error 22
OX820>

So, I do not even get as far as I used to ... BUT:

OX820> run bootcmd_owrt
run bootcmd_owrt

Loading from nand0, offset 0x440000
   Image Name:   ARM OpenWrt Linux-5.4.188
   Created:      2022-04-16  12:59:34 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3574682 Bytes = 3.4 MiB
   Load Address: 60008000
   Entry Point:  60008000
## Booting kernel from Legacy Image at 60500000 ...
   Image Name:   ARM OpenWrt Linux-5.4.188
   Created:      2022-04-16  12:59:34 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3574682 Bytes = 3.4 MiB
   Load Address: 60008000
   Entry Point:  60008000
   Verifying Checksum ... OK


Starting kernel ...

So, OpenWrt is still there in NAND and I can boot from it - thanks for the nand.erase hint again! I will now try the sysupgrade with the squashfs instead of the ubifs and see if I can get as far as before in uBoot.

Cheers,

chessplayer

---
Standart ist der Standardfehler
Re: HowTo: openWrt on OXNAS boxes
August 13, 2022 05:26PM
bodhi Wrote:
-------------------------------------------------------
[snip ...]
[... 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 uBoot itself, just the envs - of course! Thanks!

Cheers,

chessplayer

---
Standart ist der Standardfehler
Re: HowTo: openWrt on OXNAS boxes
August 13, 2022 05:35PM
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 mtdparts 'mtdparts=41000000.nand:0x100000@0x0(u-boot),-@0x100000(ubi)'
OX820> setenv partition 'nand0,0'
setenv partition 'nand0,0'
OX820> ubi part ubi
ubi part ubi
UBI: attaching mtd1 to ubi0
UBI init error 22
OX820>

So, the nand.erase was necessary also to realize that what we thought we saw before were really artefacts ...

Cheers,

chessplayer

---
Standart ist der Standardfehler
Re: HowTo: openWrt on OXNAS boxes
August 13, 2022 07:06PM
> So, the nand.erase was necessary also to realize
> that what we thought we saw before were really
> artefacts ...

Yes, that seems to be the case. Because I don't think you would want sysupgrade to format NAND partition at all (it would wipe out current user setting). It only update the existing partition using ubifs.

And with NAND you always need to erase the sectors before writing the inital image. After that, ubifs takes care of the managing of bad sectors, and also wear leveling.

-bodhi
===========================
Forum Wiki
bodhi's corner
Re: HowTo: openWrt on OXNAS boxes
August 13, 2022 07:24PM
bodhi,

thanks for the explanation. I'll wait for your next suggestion and then conduct the tests you would like me to.

Cheers,

chessplayer

---
Standart ist der Standardfehler
Re: HowTo: openWrt on OXNAS boxes
August 13, 2022 07:57PM
chessplayer,

> But, what do you mean by 'confirmation'? How would
> I test, whether this is necessary?

You did confirm that.

> nand erase.part data
> usb reset; fatload usb 0 0x60500000 uImage; bootm 0x60500000

> (the nand.erase should be on the data-partion with
> this mtdparts-definition, shouldn't it?

Yes.

Note that Kirkwood or OXNAS NAND, it is the same. You always want to erase NAND before initial image is written. If it works without erasing then you just got lucky :)

And then if you reinstall, then you need to treat it like the 1st time. Erase NAND partition again.

-bodhi
===========================
Forum Wiki
bodhi's corner



Edited 1 time(s). Last edit at 08/13/2022 07:58PM by bodhi.
Re: HowTo: openWrt on OXNAS boxes
August 13, 2022 08:08PM
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,

chessplayer

---
Standart ist der Standardfehler
Re: HowTo: openWrt on OXNAS boxes
August 14, 2022 04:21PM
chessplayer,

I'm reading the instruction in the 1st post. As I go, I will make a different post for each suggestion.

I think realy we don't want even mention the issue about envs not writable here. As long as the ubi partition appears correctly in OpenWrt layout, the installation will proceed OK. And then when you talk about fw_env.config later, you would elaborate.

Quote

5. Log in to OpenWrt

Find the IP address of your box and ssh into it (user root without password). The following step is absolutely crucial but does not yet quite work the way it should.

root@OpenWrt:~# cat /proc/mtd
dev: size erasesize name
mtd0: 00040000 00020000 "stage1"
mtd1: 00380000 00020000 "u-boot"
mtd2: 00080000 00020000 "u-boot-env"
mtd3: 009c0000 00020000 "kernel"
mtd4: 07200000 00020000 "ubi"

-bodhi
===========================
Forum Wiki
bodhi's corner
Author:

Subject:


Spam prevention:
Please, enter the code that you see below in the input field. This is for blocking bots that try to post this form automatically. If the code is hard to read, then just try to guess it right. If you enter the wrong code, a new image is created and you get another chance to enter it right.
Message: