HowTo: openWrt on OXNAS boxes [b][u]How to install OpenWrt on OXNAS boxes[/u][/b] This thread is based on my tutorial [url=https://forum.doozan.com/read.php?4,86219]HowTo: OpenWrt on Kirkwood boxes[/url] ([color=#d65773][b]Attention:[/b] if it is one of the Kirkwood Pogoplugs you have, it is that tutorial you want to follow![/color]). The basic approach is the same for the OXNAS', but some modifications are required (and, as we will see, not everything is perfect as of the original writeup of this tutorial on August 1st, 2022) [color=#0608a0]chessplayer's edit (Aug 15th, 2022): Quite some insights have been gained over the last two weeks, so I will update this first post today to reflect these at least, although this is still work in progress.[/color][color=#2c9cc9]The points where this is visible are still marked by using a light blue color.[/color] The procedure described in this thread is confirmed to work for both the Pogoplug Pro as well as the classic v3. [b][u]Credits[/u][/b] As always, credits are due to [url=https://forum.doozan.com/profile.php?2,297]bodhi[/url] as well as to [url=https://forum.doozan.com/profile.php?4,866]shv[/url] for his [url=https://forum.doozan.com/read.php?4,91284]post on the subject[/url] and similarly to [url=https://forum.doozan.com/profile.php?4,2639]echowarrior108[/url] for [url=https://forum.doozan.com/read.php?4,109979]his efforts[/url] and also to David Golle over at [url=https://openwrt.org/toh/cloud_engines/pogoplugpro]OpenWrt[/url]. [b][u]Assumptions[/u][/b] I assume that the box in question has the latest uBoot and is able to boot a USB device with the latest kernel and rootfs according to the first two links in section [b]Oxnas plugs[/b] of the [url=https://forum.doozan.com/read.php?2,23630]wiki[/url]. However, it will be [i][u]absolutely necessary[/u][/i] to be able to reach the box via netconsole or serial console. [b][u]The plan[/u][/b] We now want to install OpenWrt on our box. The steps we will need to take are [list=1] [*] Boot into debian and do some modifications to the uBoot environment variables [*] Download, rename and copy to a FAT32 USB drive an OpenWrt Image [*] Reboot the box without a USB device but with netconsole to interact with it https://forum.doozan.com/read.php?4,132635,132635#msg-132635 Sun, 08 Mar 2026 00:52:44 -0600 Phorum 5.2.23 https://forum.doozan.com/read.php?4,132635,132789#msg-132789 Re: HowTo: openWrt on OXNAS boxes https://forum.doozan.com/read.php?4,132635,132789#msg-132789 -------------------------------------------------------
[snip ...]
>
> =====
>
> 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 does not. However,
> we don't know whether it will be accepted.

[...snap]

bodhi,

thanks go mainly to you and I would say that sending this pull request probably makes the most sense. At least for 22.03 it should still be possible, since that is still in rc state (but then I have no idea how these release decisions are taken).

Cheers,

chessplayer]]> chessplayer Rescue System Sat, 20 Aug 2022 05:11:35 -0500 https://forum.doozan.com/read.php?4,132635,132786#msg-132786 Re: HowTo: openWrt on OXNAS boxes https://forum.doozan.com/read.php?4,132635,132786#msg-132786 bodhi Rescue System Fri, 19 Aug 2022 16:32:44 -0500 https://forum.doozan.com/read.php?4,132635,132785#msg-132785 Re: HowTo: openWrt on OXNAS boxes https://forum.doozan.com/read.php?4,132635,132785#msg-132785
Quote
https://forum.doozan.com/read.php?2,23630
Rescue Systems

Rescue System V2 (Original)
MacPlug & SMBPLug
Rescue System Pogo V3
Rescue System V4, using a custom LEDE firmware (BETA)
Rescue System for Pogo E02 using LEDE/OpenWrt (Install with Serial Console)
Rescue System for Pogo V4/Mobile using OpenWrt (Install with NetConsole)
Rescue System using OpenWrt on Kirkwood boxes
Rescue System using OpenWrt on OXNAS (Pogoplug V3 Classic and Pro)
]]> bodhi Rescue System Fri, 19 Aug 2022 16:30:43 -0500 https://forum.doozan.com/read.php?4,132635,132780#msg-132780 Re: HowTo: openWrt on OXNAS boxes https://forum.doozan.com/read.php?4,132635,132780#msg-132780
The uEnv.txt method is really more appropriate when booting with rootfs on USB or SATA. If a mistake is introduced in this uEnv.txt file (quite easy to mess up the envs), and causes a semi-brick, we would be able to remove it easily from the drive. OTOH, if this file is in UBIFS, then we would need to either use net/serial console to unbrick it. Or boot back to Debian and mount the UBI partition to fix it.

So at this point, we will just live with the restriction that envs can be changed only in net/serial console.

=====

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 does not. However, we don't know whether it will be accepted.]]> bodhi Rescue System Wed, 17 Aug 2022 14:51:48 -0500 https://forum.doozan.com/read.php?4,132635,132779#msg-132779 Re: HowTo: openWrt on OXNAS boxes https://forum.doozan.com/read.php?4,132635,132779#msg-132779
It's your instruction after all. So if you feel that what it should be then keep it.

But the whole point about seeing the envs is a bit counterproductive at Step 5. You cannot really change them, and the new envs setup in Step 1 is applicable to u-boot only. OpenWrt does not use them at all.

If one looks at the mtdparts env and comparing that with output of cat /proc/mtd, one would be in doubt whether it is going to work :) Not setting up the envs would eliminate that confusion.

In the Kirkwood installation it is good to see envs, because the cat /proc/mtd is shown to have a layout consistent with the env mtdparts used in u-boot. And users can change envs at that point.

So we would only need to see the OpenWrt MTD layout to make sure that the subsequent Steps will succeed. If the MTD layout is different from what in the instruction, then everything will fail afterward.


=====

If you want some parallell with the Kirwood instruction, which I think a really good point, then I would just saying something like:

"At this point the u-boot envs are not modifiable due to the OpenWrt kernel configuration restriction. See further set up and explanation later in Step 7"]]> bodhi Rescue System Mon, 15 Aug 2022 21:25:37 -0500 https://forum.doozan.com/read.php?4,132635,132778#msg-132778 Re: HowTo: openWrt on OXNAS boxes https://forum.doozan.com/read.php?4,132635,132778#msg-132778
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,

chessplayer]]> chessplayer Rescue System Mon, 15 Aug 2022 18:22:49 -0500 https://forum.doozan.com/read.php?4,132635,132777#msg-132777 Re: HowTo: openWrt on OXNAS boxes https://forum.doozan.com/read.php?4,132635,132777#msg-132777 text in blue should be moved to Step 7. And delete the text in red.

We know the envs are not useable yet. And there is no way to adjust mtdparts. So everything about the envs should be discussed in Step 7. What remain in Step 5 is a sanilty check.


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 we would expect.

Verify your mtd layout.

Ideally, (see bodhi's u-Boot post) it should be:
root@OpenWrt:# cat /proc/mtd

dev: size erasesize name
mtd0: 00e00000 00020000 "boot"
mtd1: 07200000 00020000 "data"

Instead, what it will probably be (at least it was for me) is:

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"

This means that for OpenWrt, the boot-section is further subdivided, while the ubi-/data-section is the same - so that is promising. However, since apparently our mtdparts-definition from step 1 was not picked up, we will have to calculate a bit in order to specify where fw_printenv should find the uBoot environment.

Temporarily generate or modify /etc/fw_env.config
Check whether the file /etc/fw_env.config has the following contents (which is easily calculated from the above MTD layout in comparison to bodhi's):
/dev/mtd1 0xc0000 0x20000 0x20000
If not or if the file does not exist at all, the easiest way to modify/generate it is
echo '/dev/mtd1 0xc0000 0x20000 0x20000' > /etc/fw_env.config

Afterwards, check that the uBoot environment is found by printing the variables to screen using
fw_printenv

Remarks:
Since OpenWrt only runs in RAM at the moment, this is a temporary change. If you want to be able to access the uBoot environment from the OpenWrt rescue system later on, this step will most likely have to be repeated (see step 7 below).
If you would rather modify an existing file, you can do so using vim (which is pre-installed in OpenWrt). If, like me, you do not want to learn vim and prefer nano, you can instead do
opkg update && opkg install nano
]]> bodhi Rescue System Mon, 15 Aug 2022 16:32:27 -0500 https://forum.doozan.com/read.php?4,132635,132776#msg-132776 Re: HowTo: openWrt on OXNAS boxes https://forum.doozan.com/read.php?4,132635,132776#msg-132776
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,

chessplayer]]> chessplayer Rescue System Mon, 15 Aug 2022 16:09:08 -0500 https://forum.doozan.com/read.php?4,132635,132775#msg-132775 Re: HowTo: openWrt on OXNAS boxes https://forum.doozan.com/read.php?4,132635,132775#msg-132775
>. I have implemented your suggestions
> and hope that we are now good to go searching for
> a solution.

I don't see the updates in the 1st post ?

> Is there a command to show the contents of a file using ubifs<something>? My naive try ubifscat did not do the job ...

I don't think there is cat command for ubifs in u-boot. Usually you would just load a file to memory for some purpose, but no need to print the content.

So now we have proven that the user settings area could be accessed.

I'm still thinking of a better way to do this. So for now, please update the instruction and let it stew for a day or 2.]]> bodhi Rescue System Mon, 15 Aug 2022 16:03:47 -0500 https://forum.doozan.com/read.php?4,132635,132774#msg-132774 Re: HowTo: openWrt on OXNAS boxes https://forum.doozan.com/read.php?4,132635,132774#msg-132774
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 definition from the uBoot-env alone and start from there.

Here is the result: 

OX820> printenv mtdparts
printenv mtdparts
mtdparts=mtdparts=41000000.nand:14m(boot),-(data)
OX820> setenv partition 'nand0,0'
setenv partition 'nand0,0'
OX820> ubi part data
ubi part data
UBI: attaching mtd1 to ubi0
UBI: scanning is finished
UBI: attached mtd1 (name "mtd=1", size 114 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: 912, bad PEBs: 0, corrupted PEBs: 0
UBI: user volume: 1, internal volumes: 1, max. volumes count: 128
UBI: max/mean erase counter: 2/1, WL threshold: 4096, image sequence number: 3797175681
UBI: available PEBs: 0, 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:            114 MiB
UBI: physical eraseblock size:   131072 bytes (128 KiB)
UBI: logical eraseblock size:    129024 bytes
UBI: number of good PEBs:        912
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:     1
UBI: available PEBs:             0
UBI: total number of reserved PEBs: 912
UBI: number of PEBs reserved for bad PEB handling: 20
UBI: max/mean erase counter: 2/1
OX820> ubi info layout
ubi info layout
Volume information dump:
	vol_id          0
	reserved_pebs   888
	alignment       1
	data_pad        0
	vol_type        3
	name_len        6
	usable_leb_size 129024
	used_ebs        888
	used_bytes      114573312
	last_eb_bytes   129024
	corrupted       0
	upd_marker      0
	name            rootfs
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
ubifsmount ubi0:rootfs
OX820> ubifsls /
ubifsls /
<DIR>	     3984  Sat Apr 16 12:59:34 2022  bin
<DIR>	      160  Sat Apr 16 12:59:34 2022  dev
<DIR>	     4032  Fri Jan 29 20:20:40 2021  etc
<DIR>	     1904  Sat Apr 16 12:59:34 2022  lib
<DIR>	      160  Sat Apr 16 12:59:34 2022  mnt
<DIR>	      224  Sat Apr 16 12:59:34 2022  rom
<DIR>	      160  Sat Apr 16 12:59:34 2022  tmp
<DIR>	      160  Sat Apr 16 12:59:34 2022  sys
<LNK>	        3  Sat Apr 16 12:59:34 2022  var
<DIR>	      480  Tue Aug 02 18:04:25 2022  usr
<DIR>	      368  Sat Apr 16 12:59:34 2022  www
<DIR>	      160  Sat Apr 16 12:59:34 2022  proc
<DIR>	     3736  Sat Apr 16 12:59:34 2022  sbin
<DIR>	      160  Sat Apr 16 12:59:34 2022  root
<DIR>	      160  Sat Apr 16 12:59:34 2022  overlay
OX820> ubifsls /etc
ubifsls /etc
<LNK>	        7  Sat Apr 16 12:59:34 2022  TZ
	       70  Sat Apr 16 12:59:34 2022  udhcpc.user
<DIR>	      296  Fri Jan 29 20:20:40 2021  ssl
	       34  Mon Aug 15 12:12:37 2022  fw_env.config
<LNK>	       12  Sat Apr 16 12:59:34 2022  mtab
<DIR>	      376  Sat Apr 16 12:59:34 2022  opkg
<DIR>	     2320  Mon Aug 15 12:09:27 2022  rc.d
	      305  Sat Apr 16 12:59:34 2022  hotplug-preinit.json
<LNK>	       21  Sat Apr 16 12:59:34 2022  os-release
<DIR>	      376  Sat Apr 16 12:59:34 2022  iproute2
	      170  Sat Apr 16 12:59:36 2022  board.json
<DIR>	     1696  Sat Apr 16 12:59:34 2022  init.d
<DIR>	      328  Sat Apr 16 12:59:50 2022  dropbear
	     1522  Sat Apr 16 12:59:34 2022  hotplug.json
	       18  Sat Apr 16 12:59:34 2022  openwrt_version
<DIR>	      552  Sat Apr 16 12:59:34 2022  rc.button
<DIR>	      160  Sat Apr 16 12:59:34 2022  udhcpc.user.d
	      664  Sat Apr 16 12:59:36 2022  uhttpd.crt
	      121  Sat Apr 16 12:59:36 2022  uhttpd.key
	     3233  Sat Apr 16 12:59:34 2022  rc.common
<DIR>	      424  Sat Apr 16 12:59:34 2022  hotplug.d
<DIR>	      232  Sat Apr 16 12:59:34 2022  luci-uploads
	      948  Sat Apr 16 12:59:34 2022  diag.sh
	      352  Sat Apr 16 12:59:34 2022  firewall.user
	      320  Sat Apr 16 12:59:34 2022  passwd
	       80  Sat Apr 16 12:59:34 2022  sysctl.conf
<DIR>	      312  Sat Apr 16 12:59:34 2022  board.d
	       61  Sat Apr 16 12:59:34 2022  fstab
	      189  Sat Apr 16 12:59:34 2022  group
	      110  Sat Apr 16 12:59:34 2022  hosts
	      106  Sat Apr 16 12:59:34 2022  inittab
<DIR>	      824  Sat Apr 16 12:59:34 2022  modules-boot.d
<DIR>	     1960  Sat Apr 16 12:59:34 2022  modules.d
<DIR>	      312  Sat Apr 16 12:59:34 2022  sysctl.d
	      180  Sat Apr 16 12:59:34 2022  shadow
	        9  Sat Apr 16 12:59:34 2022  shells
	     1120  Sat Apr 16 12:59:34 2022  shinit
	      461  Sat Apr 16 12:59:34 2022  banner.failsafe
	      123  Sat Apr 16 12:59:34 2022  device_info
	      512  Sat Apr 16 12:59:54 2022  urandom.seed
<LNK>	       14  Sat Apr 16 12:59:34 2022  localtime
	      397  Sat Apr 16 12:59:34 2022  banner
	     2541  Sat Apr 16 12:59:34 2022  protocols
<DIR>	      160  Sat Apr 16 12:59:37 2022  uci-defaults
<DIR>	      160  Sat Apr 16 12:59:34 2022  crontabs
	      132  Sat Apr 16 12:59:34 2022  rc.local
<DIR>	      304  Sat Apr 16 12:59:34 2022  capabilities
<LNK>	       16  Sat Apr 16 12:59:34 2022  resolv.conf
<DIR>	      968  Mon Aug 15 12:11:00 2022  config
	      213  Sat Apr 16 12:59:34 2022  openwrt_release
	      128  Sat Apr 16 12:59:34 2022  sysupgrade.conf
	      609  Sat Apr 16 12:59:34 2022  preinit
	     1046  Sat Apr 16 12:59:34 2022  profile
	      108  Sat Apr 16 12:59:34 2022  opkg.conf
	      130  Sat Apr 16 12:59:34 2022  ethers
	     3073  Sat Apr 16 12:59:34 2022  services
OX820> ubifsls /etc/config
ubifsls /etc/config
	      973  Mon Aug 15 12:09:27 2022  luci
	      167  Sat Apr 16 12:59:34 2022  rpcd
	      521  Mon Aug 15 12:11:00 2022  network
	      788  Sat Apr 16 12:59:34 2022  ucitrack
	      134  Sat Apr 16 12:59:34 2022  dropbear
	      151  Sat Apr 16 12:59:36 2022  fstab
	      445  Sat Apr 16 12:59:34 2022  mdadm
	      449  Mon Aug 15 12:09:10 2022  system
	      783  Sat Apr 16 12:59:36 2022  uhttpd
	      352  Sat Apr 16 12:59:35 2022  wireless
	     4632  Sat Apr 16 12:59:34 2022  firewall
	      132  Sat Apr 16 12:59:37 2022  ubootenv

Hope this helps. Is there a command to show the contents of a file using ubifs<something>? My naive try ubifscat did not do the job ...

Cheers,

chessplayer]]> chessplayer Rescue System Mon, 15 Aug 2022 07:31:18 -0500 https://forum.doozan.com/read.php?4,132635,132773#msg-132773 Re: HowTo: openWrt on OXNAS boxes https://forum.doozan.com/read.php?4,132635,132773#msg-132773
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,

chessplayer]]> chessplayer Rescue System Mon, 15 Aug 2022 07:15:14 -0500 https://forum.doozan.com/read.php?4,132635,132772#msg-132772 Re: HowTo: openWrt on OXNAS boxes https://forum.doozan.com/read.php?4,132635,132772#msg-132772 bodhi Rescue System Sun, 14 Aug 2022 16:45:42 -0500 https://forum.doozan.com/read.php?4,132635,132771#msg-132771 Re: HowTo: openWrt on OXNAS boxes https://forum.doozan.com/read.php?4,132635,132771#msg-132771

Quote

7. Boot from NAND and log in to OpenWrt

.......

generate or modify /etc/fw_env.config
Check whether the file /etc/fw_env.config has the following contents (which is easily calculated from the above MTD layout in comparison to bodhi's):
/dev/mtd1 0xc0000 0x20000 0x20000
If not or if the file does not exist at all, the easiest way to modify/generate it is
echo '/dev/mtd1 0xc0000 0x20000 0x20000' > /etc/fw_env.config

Afterwards, check that the uBoot environment is found by printing the variables to screen using
fw_printenv

...

=====

Rationale:

The installation for OpenWrt on OXNAS and Kirkwood are different in step 5 and step 7. It is because we have no way of passing mtdparts into the system, so in Step 5 the envs are not used at all. In Step 7, we want to see if we can read the envs while OpenWrt is running. And possibly will implement something to make it writeable later.]]> bodhi Rescue System Sun, 14 Aug 2022 16:44:45 -0500 https://forum.doozan.com/read.php?4,132635,132770#msg-132770 Re: HowTo: openWrt on OXNAS boxes https://forum.doozan.com/read.php?4,132635,132770#msg-132770
Quote

6. Install to NAND

Finally, we can perform a sysupgrade of OpenWrt/LEDE either using the LUCI WIF (Web Interface) or the command line.

< text about removing all USB drives here>

Since we are already logged in via ssh, I only describe the latter option, while the former may be found, e.g., in step 4.b of Jörg's original post for the Kirkwoods. We must do:
opkg update
opkg install ca-certificates
cd /tmp
wget <URL of our desired sysupgrade file>
sysupgrade <name of our desired sysupgrade file>
The desired upgrade file may be found the same way as we found the image in step 2 above starting from the release page (but, ideally, you kept the browser tab open in step 2). There you can just copy the link address to the sysupgrade file (tar or bin depending on the release) and paste it into the ssh window.

Remark: Coresponding to the above uImages, the concrete files for the sysupgrade were
this upgrade file for the classic Pogoplug v3
this upgrade file for the Pogoplug Pro

remove: The upgrade process will result in an automatic reboot (during which I removed the USB stick, but that may not be necessary).


To make it foolproof, you should recommend removing all USB drives (in case the box was booted into Debian on USB before, and then users installing OpenwWrt). Also, it's serving as a rescue system, so seeing it booted without Debian would be a nice proof of concept.]]> bodhi Rescue System Sun, 14 Aug 2022 16:34:21 -0500 https://forum.doozan.com/read.php?4,132635,132769#msg-132769 Re: HowTo: openWrt on OXNAS boxes https://forum.doozan.com/read.php?4,132635,132769#msg-132769
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 Rescue System Sun, 14 Aug 2022 16:21:44 -0500 https://forum.doozan.com/read.php?4,132635,132760#msg-132760 Re: HowTo: openWrt on OXNAS boxes https://forum.doozan.com/read.php?4,132635,132760#msg-132760
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]]> chessplayer Rescue System Sat, 13 Aug 2022 20:08:31 -0500 https://forum.doozan.com/read.php?4,132635,132759#msg-132759 Re: HowTo: openWrt on OXNAS boxes https://forum.doozan.com/read.php?4,132635,132759#msg-132759
> 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 Rescue System Sat, 13 Aug 2022 19:57:03 -0500 https://forum.doozan.com/read.php?4,132635,132758#msg-132758 Re: HowTo: openWrt on OXNAS boxes https://forum.doozan.com/read.php?4,132635,132758#msg-132758
thanks for the explanation. I'll wait for your next suggestion and then conduct the tests you would like me to.

Cheers,

chessplayer]]> chessplayer Rescue System Sat, 13 Aug 2022 19:24:31 -0500 https://forum.doozan.com/read.php?4,132635,132757#msg-132757 Re: HowTo: openWrt on OXNAS boxes https://forum.doozan.com/read.php?4,132635,132757#msg-132757 > 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 Rescue System Sat, 13 Aug 2022 19:06:14 -0500 https://forum.doozan.com/read.php?4,132635,132755#msg-132755 Re: HowTo: openWrt on OXNAS boxes https://forum.doozan.com/read.php?4,132635,132755#msg-132755 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]]> chessplayer Rescue System Sat, 13 Aug 2022 17:35:49 -0500 https://forum.doozan.com/read.php?4,132635,132754#msg-132754 Re: HowTo: openWrt on OXNAS boxes https://forum.doozan.com/read.php?4,132635,132754#msg-132754 -------------------------------------------------------
[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]]> chessplayer Rescue System Sat, 13 Aug 2022 17:26:42 -0500 https://forum.doozan.com/read.php?4,132635,132753#msg-132753 Re: HowTo: openWrt on OXNAS boxes https://forum.doozan.com/read.php?4,132635,132753#msg-132753 
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]]> chessplayer Rescue System Sat, 13 Aug 2022 17:24:22 -0500 https://forum.doozan.com/read.php?4,132635,132752#msg-132752 Re: HowTo: openWrt on OXNAS boxes https://forum.doozan.com/read.php?4,132635,132752#msg-132752 -------------------------------------------------------
> 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 Rescue System Sat, 13 Aug 2022 17:17:03 -0500 https://forum.doozan.com/read.php?4,132635,132751#msg-132751 Re: HowTo: openWrt on OXNAS boxes https://forum.doozan.com/read.php?4,132635,132751#msg-132751 ubifsls /etc

And so on.....]]> bodhi Rescue System Sat, 13 Aug 2022 16:15:01 -0500 https://forum.doozan.com/read.php?4,132635,132750#msg-132750 Re: HowTo: openWrt on OXNAS boxes https://forum.doozan.com/read.php?4,132635,132750#msg-132750 
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]]> chessplayer Rescue System Sat, 13 Aug 2022 14:29:43 -0500 https://forum.doozan.com/read.php?4,132635,132749#msg-132749 Re: HowTo: openWrt on OXNAS boxes https://forum.doozan.com/read.php?4,132635,132749#msg-132749
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)'
]]> chessplayer Rescue System Sat, 13 Aug 2022 14:01:04 -0500 https://forum.doozan.com/read.php?4,132635,132748#msg-132748 Re: HowTo: openWrt on OXNAS boxes https://forum.doozan.com/read.php?4,132635,132748#msg-132748
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 Rescue System Sat, 13 Aug 2022 13:22:40 -0500 https://forum.doozan.com/read.php?4,132635,132747#msg-132747 Re: HowTo: openWrt on OXNAS boxes https://forum.doozan.com/read.php?4,132635,132747#msg-132747
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 ...]]> chessplayer Rescue System Sat, 13 Aug 2022 09:58:03 -0500 https://forum.doozan.com/read.php?4,132635,132744#msg-132744 Re: HowTo: openWrt on OXNAS boxes https://forum.doozan.com/read.php?4,132635,132744#msg-132744
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 Rescue System Fri, 12 Aug 2022 19:37:09 -0500 https://forum.doozan.com/read.php?4,132635,132716#msg-132716 Re: HowTo: openWrt on OXNAS boxes https://forum.doozan.com/read.php?4,132635,132716#msg-132716
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 Rescue System Sun, 07 Aug 2022 22:28:49 -0500