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
Author:

Your Email:


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: