HowTo: openWrt on OXNAS boxes
Posted by chessplayer
|
Re: HowTo: openWrt on OXNAS boxes August 02, 2022 07:20PM |
Registered: 11 years ago Posts: 157 |
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
(which was calculated from the OpenWrt MTD-layout) instead of this
(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
-------------------------------------------------------
> 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 |
Registered: 11 years ago Posts: 157 |
|
Re: HowTo: openWrt on OXNAS boxes August 03, 2022 02:29PM |
Registered: 11 years ago Posts: 157 |
chessplayer Wrote:
-------------------------------------------------------
> Ok, one more thing: I now made this
> mtdparts-definition permanent and had a look at
> what we see in debian then:
>
> 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
-------------------------------------------------------
> 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 |
Admin Registered: 12 years ago Posts: 17,318 |
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
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 |
Admin Registered: 12 years ago Posts: 17,318 |
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.
==========
Testing steps
1. Log in to OpenWrt and create uEnv.txt with the initial content as below
Use nano to edit this file (to ensure it is a proper text file)
Add this single line
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
-bodhi
===========================
Forum Wiki
bodhi's corner
Edited 1 time(s). Last edit at 08/03/2022 05:30PM by bodhi.
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_rootfsExit 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 |
Registered: 11 years ago Posts: 157 |
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.
>
>
> ==========
>
> Testing steps
>
> 1. Log in to OpenWrt and create uEnv.txt with the
> initial content as below
>
>
> Use nano to edit this file (to ensure it is a
> proper text file)
>
> Add this single line
>
>
> 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
>
>
Anything I can do to help?
Cheers,
chessplayer
---
Standart ist der Standardfehler
-------------------------------------------------------
> 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 |
Admin Registered: 12 years ago Posts: 17,318 |
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
Mount it
List files in /boot
-bodhi
===========================
Forum Wiki
bodhi's corner
Edited 1 time(s). Last edit at 08/03/2022 06:55PM by bodhi.
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 infovolume 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 |
Admin Registered: 12 years ago Posts: 17,318 |
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
-bodhi
===========================
Forum Wiki
bodhi's corner
|
Re: HowTo: openWrt on OXNAS boxes August 04, 2022 01:50PM |
Registered: 11 years ago Posts: 157 |
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:
Additionally:
Now the sysupgrade (went back to the latest stable version)
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:
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
>
>
First of all, I think this has to start with:
So, this is as far as I got, since I am obviously too stupid to specify the volume name:
This did not help either (as you can see at the bottom of the above code).
Please advise!
Cheers,
chessplayer
---
Standart ist der Standardfehler
-------------------------------------------------------
> 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 |
Admin Registered: 12 years ago Posts: 17,318 |
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 |
Registered: 11 years ago Posts: 157 |
bodhi Wrote:
-------------------------------------------------------
>
> No it does not have to be in /boot. /etc/config is
> fine!
Great!
>
> Have you tried
>
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.
-------------------------------------------------------
>
>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 |
Registered: 11 years ago Posts: 157 |
bodhi Wrote:
-------------------------------------------------------
[snip ...]
[...snap]
>
> Have you tried
>
So, after unbricking the OXNAS box, I tried this suggestion, but without success (preliminary steps as before):
Now, in OpenWrt, I checked the available blocks beforehand:
That made me wonder (but not enough, apparently):
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
-------------------------------------------------------
[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 |
Admin Registered: 12 years ago Posts: 17,318 |
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
> 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 |
Registered: 8 years ago Posts: 375 |
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.
This should allow editing the environment after installing the uboot-envtools package and creating the appropriate config file.
-------------------------------------------------------
> 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 |
Admin Registered: 12 years ago Posts: 17,318 |
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
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 |
Admin Registered: 12 years ago Posts: 17,318 |
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.
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.
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
-bodhi
===========================
Forum Wiki
bodhi's corner
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
mountIt 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 |
Registered: 11 years ago Posts: 157 |
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
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
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
So, all is well. Let's see what we get when we log in.
2. inside OpenWrt in RAM
So, OpenWrt no cannot read the uBoot-env as it was able to before!
Therefore, I believe what I should do now is:
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.
thanks for looking into this further. I'll report here what I found so far and will stop at the question as to how to proceed. What you should know beforehand is that I
- unbricked the box again
- can boot your latest OXNAS kernel with the latest rootfs
- do not have OpenWrt in NAND back again (as I just found out; see below)
- we could try the ubinized version for sysupgrade if 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:
- re-install your uBoot for good measure
- 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 |
Admin Registered: 12 years ago Posts: 17,318 |
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).
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,
-bodhi
===========================
Forum Wiki
bodhi's corner
Edited 1 time(s). Last edit at 08/13/2022 01:24PM by bodhi.
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 |
Registered: 11 years ago Posts: 157 |
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:
(the nand.erase should be on the data-partion with this mtdparts-definition, shouldn't it?
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:
---
Standart ist der Standardfehler
Edited 1 time(s). Last edit at 08/13/2022 02:04PM by chessplayer.
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 |
Registered: 11 years ago Posts: 157 |
So, I did all of these again and got the same results as above:
Then, I got (which seems like relevant info):
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:
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
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 |
Admin Registered: 12 years ago Posts: 17,318 |
|
Re: HowTo: openWrt on OXNAS boxes August 13, 2022 05:17PM |
Admin Registered: 12 years ago Posts: 17,318 |
chessplayer Wrote:
-------------------------------------------------------
> So, I did all of these again and got the same
> results as above:
>
> Then, I got (which seems like relevant info):
>
>
> 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:
>
>
> 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
-------------------------------------------------------
> 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 |
Registered: 11 years ago Posts: 157 |
Ok, so now I re-installed uBoot and installed OpenWrt the following way:
In OpenWrt in RAM I did the usual, but then tried the ubifs instead of the squashfs
This led to (in uBoot):
So, I do not even get as far as I used to ... BUT:
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
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 |
Registered: 11 years ago Posts: 157 |
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
-------------------------------------------------------
[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 |
Registered: 11 years ago Posts: 157 |
After the sysupgrade with the squasfs instead of the ubifs, the result is exactly the same:
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
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 |
Admin Registered: 12 years ago Posts: 17,318 |
> 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
> 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 |
Registered: 11 years ago Posts: 157 |
|
Re: HowTo: openWrt on OXNAS boxes August 13, 2022 07:57PM |
Admin Registered: 12 years ago Posts: 17,318 |
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.
> 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 |
Registered: 11 years ago Posts: 157 |
|
Re: HowTo: openWrt on OXNAS boxes August 14, 2022 04:21PM |
Admin Registered: 12 years ago Posts: 17,318 |
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.
-bodhi
===========================
Forum Wiki
bodhi's corner
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
