Modify

Opened 7 years ago

Closed 7 years ago

Last modified 4 years ago

#9323 closed defect (fixed)

NVRAM commit does not save NVRAM changes on SimpleShare

Reported by: JohnC60 <johnc60@…> Owned by: hauke
Priority: high Milestone: Backfire 10.03.1
Component: base system Version: Backfire 10.03.1 RC4
Keywords: NVRAM, boot wait, firmware upgrade Cc:

Description

On a SimpleShare using the brcm47xx image, changes to the NVRAM are not saved after what appears to be a successful commit. To reproduce:

Use "nvram set" to change the value of some NVRAM variables
Use "nvram show" to verify the changes
Use "nvram commit" to commit and permanently save the changes
Reboot the SimpleShare and you will find that none of the changes are retained.

Because of this, there is no way to enable the "boot wait" functionality.

-John

SimpleShare STI-NAS/250 running OpenWrt Backfire 10.03.1-RC5 (openwrt-brcm47xx-squashfs.trx)

Attachments (2)

bcm47xx-flash.c (17.3 KB) - added by realopty <realopty@…> 7 years ago.
flash mapping fix for simpleshare
bcm47xx-flash.2.c (11.6 KB) - added by realopty <realopty@…> 7 years ago.
lame hack to backport nvram fixes

Download all attachments as: .zip

Change History (23)

comment:1 Changed 7 years ago by RealOpty <realopty@…>

I had this same issue also. Jow helped me come up with a hacked up solution to fix this bug. It happens because there is a nvram 'backup' that gets restored on every boot it seems.

comment:2 Changed 7 years ago by RealOpty <realopty@…>

so i found the hacked up patch.

Index: target/linux/brcm47xx/files-2.6.35/drivers/mtd/maps/bcm47xx-flash.c
===================================================================
--- target/linux/brcm47xx/files-2.6.35/drivers/mtd/maps/bcm47xx-flash.c (revision 23042)
+++ target/linux/brcm47xx/files-2.6.35/drivers/mtd/maps/bcm47xx-flash.c (working copy)
@@ -442,8 +442,8 @@
 
        /* nvram */
        if (cfe_size != 384 * 1024) {
-               bcm47xx_parts[3].offset = size - ROUNDUP(NVRAM_SPACE, mtd->erasesize);
-               bcm47xx_parts[3].size   = ROUNDUP(NVRAM_SPACE, mtd->erasesize);
+               bcm47xx_parts[3].offset = size - ROUNDUP(NVRAM_SPACE, mtd->erasesize) * 2;
+               bcm47xx_parts[3].size   = ROUNDUP(NVRAM_SPACE, mtd->erasesize) * 2;
        } else {
                /* nvram (old 128kb config partition on netgear wgt634u) */
                bcm47xx_parts[3].offset = bcm47xx_parts[0].size;

comment:3 Changed 7 years ago by RealOpty <realopty@…>

please provide a "nvram show | sort "

comment:4 Changed 7 years ago by JohnC60 <johnc60@…>

Hmmm... I was wondering about that myself because I did see two copies of the NVRAM data and only one of the copies was updated when the "nvram commit" command is executed.

If you look at the MTD partitions, it only identifies one NVRAM partition at 0x7f0000 and this is where the "nvram commit" update occurs.

The other copy of NVRAM is stored at 0x7e0000, which is the last 64KB of the "rootfs_data" partition! Isn't this overlap bad?

Are the MTD partitions incorrectly allocated? Shouldn't the "rootfs_data" partition end at 0x7dffff and the NVRAM partition allocated starting from 0x7e0000 for a length of 128KB? Or perhaps allocate two 64KB NVRAM partitions?

I'm pretty sure that the SimpleShare CFE considers the NVRAM data at 0x7e0000 as primary and the 0x7f0000 area is treated as the backup.

-John

From OpenWrt dmesg:

Creating 4 MTD partitions on "Physically mapped flash":
0x000000000000-0x000000040000 : "cfe"
0x000000040000-0x0000007f0000 : "linux"
0x00000011b400-0x0000007f0000 : "rootfs"
mtd: partition "rootfs" must either start or end on erase block boundary or be
smaller than an erase block -- forcing read-only
mtd: partition "rootfs" set to be root filesystem
mtd: partition "rootfs_data" created automatically, ofs=2A0000, len=550000
0x0000002a0000-0x0000007f0000 : "rootfs_data"
0x0000007f0000-0x000000800000 : "nvram"

comment:5 Changed 7 years ago by JohnC60 <johnc60@…>

Here's the "nvram show" information that you requested.

-John

root@simpleshare:~# nvram show | sort

boardflags=0
boardnum=04FN51804579_SD_C-04
boardrev=0x10
boardtype=0x042f
boot_wait=off
broadnas_unique_id=00:01:6C:BE:B9:57
cfe_configuration_state=initialized
cfe_gpio_init_out_3=0
clkfreq=264
default_http_passwd=simple
default_http_username=admin
default_lan_ipaddr=192.168.1.254
default_lan_proto=dhcp_client
default_machine_name=SimpleShare
default_new_disk_action=one_jbod
default_nfs_master_enable=enabled
default_physical_authentication_enable=disabled
default_primary_pool_name=SimplePool
default_primary_share_name=NetFolder
default_start_page=/administration/basic.asp
default_ubsa_guest_account=guest
default_workgroup=WORKGROUP
dl_ram_addr=a0001000
et0macaddr=00:01:6C:BE:B9:57
et0mdcport=0
et0phyaddr=5
et1macaddr=40:01:6C:BE:B9:57
et1mdcport=1
et1phyaddr=30
gpio_0_name=soft_power_switch
gpio_3_name=system_ready_LED
gpio_6_name=power_enable
http_passwd=simple
http_username=admin
lan_ifname=eth0
lan_ifnames=eth0 eth2
lan_ipaddr=192.168.1.254
lan_netmask=255.255.255.0
lan_proto=dhcp_client
machine_name=SimpleShare
manufacturing_state=tested_ok
misc_io_mode=bcmgpio
new_disk_action=one_jbod
nfs_master_enable=enabled
opo=0x0
os_flash_addr=bfc40000
os_ram_addr=80001000
pmon_ver=CFE 3.61.13.0
primary_pool_name=SimplePool
primary_share_name=NetFolder
reset_gpio=7
rtc_device=st4181
scratch=a0180000
sdram_config=0x8062
sdram_init=0x0009
sdram_ncdl=0x10407
sdram_refresh=0x0000
st_rev=0x11
startup_command=if [ -e /shares/NAS_pool ]; then /shares/NAS_pool/NAS_share/mfg.sh; fi; /usr/sbin/st_startup.sh
sync_to_hwclock_interval=1
ubsa_guest_account=guest
wait_time=5
wan_ifname=eth1
watchdog=0
wlan_hardware_present=no
wlan_ipaddr=192.168.2.254
wlan_netmask=255.255.255.0
workgroup=WORKGROUP

comment:6 Changed 7 years ago by JohnC60 <johnc60@…>

I loaded the original SimpleShare firmware (v1.07) and it creates the MTD partitions differently. Interestingly enough, it allocates two NVRAM partitions at 0x7e0000 and 0x7f0000. Compare that with OpenWrt (back two posts) which only creates one NVRAM partition at 0x7f0000 and, the area at 0x7e0000 is the last 64KB of the "rootfs_data".

From dmesg of original firmware:

Creating 5 MTD partitions on "Physically mapped flash":
0x00000000-0x00040000 : "cfe"
0x00040000-0x007e0000 : "linux"
0x001592d0-0x007e0000 : "rootfs"
0x007e0000-0x007f0000 : "nvramcopy"
0x007f0000-0x00800000 : "nvram"

I'm guessing that with OpenWrt, if I fill up the writable filesystem, it would destroy the NVRAM information at 0x7e0000, which the CFE uses first at boot.

Can this be fixed in OpenWrt? Can we get OpenWrt to also detect and create both NVRAM partitions and not overlap it with the "rootfs_data"? As it is now, there seems to be a danger of NVRAM corruption.

Thanks!
-John

comment:7 Changed 7 years ago by realopty <realopty@…>

Ive worked up a patch to resolve this. Its currently undergoing testing to make sure it dont break other devices. Im happy to report that nvram is working now. This is how it looks in openwrt with my patch.

Creating 5 MTD partitions on "Physically mapped flash":
0x000000000000-0x000000040000 : "cfe"
0x000000040000-0x0000007e0000 : "linux"
0x00000011ec00-0x0000007e0000 : "rootfs"
mtd: partition "rootfs" must either start or end on erase block boundary or be smaller than an erase block -- forcing read-only
mtd: partition "rootfs" set to be root filesystem
mtd: partition "rootfs_data" created automatically, ofs=3E0000, len=400000
0x0000003e0000-0x0000007e0000 : "rootfs_data"
0x0000007e0000-0x0000007f0000 : "nvram"
0x0000007f0000-0x000000800000 : "nvram_copy"

comment:8 Changed 7 years ago by JohnC60 <johnc60@…>

Great. Thanks! I'm not sure how you would detect this. I suspect that there may be some devices that only have one copy of NVRAM.

comment:9 Changed 7 years ago by hauke

  • Owner changed from developers to hauke
  • Status changed from new to accepted

comment:10 Changed 7 years ago by JohnC60 <johnc60@…>

Well, I inadvertantly proved my theory. I filled up the file system while installing some packages and it apparently destroyed the NVRAM data at 0x7e0000. The SimpleShare will not reboot after this. Outwardly, it appears to be "bricked". OpenWrt gets a kernal panic and halts immediately after starting. The CFE bootloader will not perform a boot_wait so there's no way to reload a new OpenWrt TRX image. Even if you could, it would probably kernal panic again because the bad NVRAM data is not allowing the hardware environment to be setup correctly.

I have a serial connection so I can see that the NVRAM is indeed empty except for a few runtime generated entries.

In case anyone runs into this problem, fortunately there may be a way out. Hold down the reset button for 10 seconds and the CFE bootloader will restore the NVRAM to its default values. Doing this allowed OpenWrt to start normally without the kernal panic. However, the NVRAM default is "boot_wait=off" and, the OpenWrt NVRAM utility is not able to change this. Therefore you will not be able to update the OpenWrt image again (unless you have a serial console connection).

Looking forward to the changes that will allow the NVRAM utility to work correctly. :)

-John

comment:11 Changed 7 years ago by realopty <realopty@…>

plz post the cfe restored nvram. The developers are taking a while to review my patch & commit it so ill just up load my changes to this ticket. just replace it in the folder /target/linux/brcm47xx/files/drivers/mtd/maps/ then do a make target/linux/clean V=99

note: this has only been tested on latest revision of Trunk. kernel 2.6.2.6.37.6

Changed 7 years ago by realopty <realopty@…>

flash mapping fix for simpleshare

comment:12 Changed 7 years ago by JohnC60 <johnc60@…>

NVRAM before CFE restoration (OpenWrt starts then halts with kernel panic):

CFE> nvram show
pmon_ver=CFE 3.61.13.0
sdram_config=0x8062
sdram_refresh=0x0000
sdram_ncdl=0x10407
sdram_init=0x0009
size: 121 bytes (32647 left)
* command status = 0
CFE>

NVRAM after CFE restoration (long reset) (OpenWrt starts OK):

CFE> nvram show
default_primary_pool_name=SimplePool
os_ram_addr=80001000
rtc_device=st4181
boardrev=0x10
et0macaddr=00:01:6C:BE:B9:57
watchdog=0
boot_wait=off
et0mdcport=0
reset_gpio=7
pmon_ver=CFE 3.61.13.0
machine_name=SimpleShare
sync_to_hwclock_interval=1
os_flash_addr=bfc40000
broadnas_unique_id=00:01:6C:BE:B9:57
boardtype=0x042f
default_lan_proto=dhcp_client
et1macaddr=40:01:6C:BE:B9:57
lan_netmask=255.255.255.0
http_username=admin
et1mdcport=1
default_start_page=/administration/basic.asp
workgroup=WORKGROUP
wlan_ipaddr=192.168.2.254
http_passwd=simple
gpio_6_name=power_enable
primary_pool_name=SimplePool
wait_time=5
default_physical_authentication_enable=disabled
default_nfs_master_enable=enabled
startup_command=if [ -e /shares/NAS_pool ]; then /shares/NAS_pool/NAS_share/mfg.sh; fi; /usr/sbin/st_startup.sh
manufacturing_state=tested_ok
new_disk_action=one_jbod
gpio_0_name=soft_power_switch
wlan_netmask=255.255.255.0
lan_ifnames=eth0 eth2
clkfreq=264
lan_ipaddr=192.168.1.254
lan_proto=dhcp_client
default_primary_share_name=NetFolder
cfe_configuration_state=initialized
default_ubsa_guest_account=guest
sdram_config=0x8062
scratch=a0180000
cfe_gpio_init_out_3=0
lan_ifname=eth0
boardflags=0
sdram_refresh=0x0000
sdram_ncdl=0x10603
default_lan_ipaddr=192.168.1.254
default_machine_name=SimpleShare
nfs_master_enable=enabled
misc_io_mode=bcmgpio
et0phyaddr=5
wan_ifname=eth1
default_new_disk_action=one_jbod
sdram_init=0x0549
dl_ram_addr=a0001000
primary_share_name=NetFolder
ubsa_guest_account=guest
default_http_passwd=simple
gpio_3_name=system_ready_LED
default_workgroup=WORKGROUP
st_rev=0x11
wlan_hardware_present=no
et1phyaddr=30
boardnum=04FN51804579_SD_C-04
default_http_username=admin
size: 1718 bytes (31050 left)
* command status = 0
CFE>

comment:13 Changed 7 years ago by JohnC60 <johnc60@…>

Just compiled and tested. Works great!

The commit on the NVRAM utility only updates the "nvram" partition and not "nvram_copy". This should be OK. During a restart, CFE will sync "nvram" to "nvram_copy".

Thanks for fixing this!

-John

(Can this be rolled into the Backfire 10.03.1-RC5 release? Unfortunately, the Attitude Adjustment trunk is MUCH slower than Backfire. All of my disk throughput is about half of what they used to be with 10.03. That's another mystery to solve. Thanks again for this NVRAM fix.)

From dmesg:

Creating 5 MTD partitions on "Physically mapped flash":
0x000000000000-0x000000040000 : "cfe"
0x000000040000-0x0000007e0000 : "linux"
0x00000010c400-0x0000007e0000 : "rootfs"
mtd: partition "rootfs" must either start or end on erase block boundary or be smaller than an erase block -- forcing read-only
mtd: partition "rootfs" set to be root filesystem
mtd: partition "rootfs_data" created automatically, ofs=310000, len=4D0000
0x000000310000-0x0000007e0000 : "rootfs_data"
0x0000007e0000-0x0000007f0000 : "nvram"
0x0000007f0000-0x000000800000 : "nvram_copy"

root@OpenWrt:/# cat /proc/mtd
dev: size erasesize name
mtd0: 00040000 00010000 "cfe"
mtd1: 007a0000 00010000 "linux"
mtd2: 006d3c00 00010000 "rootfs"
mtd3: 004d0000 00010000 "rootfs_data"
mtd4: 00010000 00010000 "nvram"
mtd5: 00010000 00010000 "nvram_copy"

root@OpenWrt:~# nvram show | grep -i "wait_time"
wait_time=5
root@OpenWrt:~# grep -i "wait_time" /dev/mtd4
wait_time=5
root@OpenWrt:~# grep -i "wait_time" /dev/mtd5
wait_time=5

root@OpenWrt:~# nvram set wait_time=10
root@OpenWrt:~# nvram commit

root@OpenWrt:~# nvram show | grep -i "wait_time"
wait_time=10
root@OpenWrt:~# grep -i "wait_time" /dev/mtd4
wait_time=10
root@OpenWrt:~# grep -i "wait_time" /dev/mtd5
wait_time=5

<<reboot>>

root@OpenWrt:~# nvram show | grep -i "wait_time"
wait_time=10
root@OpenWrt:~# grep -i "wait_time" /dev/mtd4
wait_time=10
root@OpenWrt:~# grep -i "wait_time" /dev/mtd5
wait_time=10

comment:14 Changed 7 years ago by realopty <realopty@…>

im almost 100% sure that you can just copy that file into the same location on backfire branch. Only if you plan on running kernel 2.6 that is ;)


I havent tested this yet, but will soon.

comment:15 Changed 7 years ago by hauke

  • Resolution set to fixed
  • Status changed from accepted to closed

Thank you for the report and the patch this is fixed in current trunk r27005.

comment:16 Changed 7 years ago by realopty <realopty@…>

I was wrong about just copying it into backfire. But until we git this backported here is a hacked up flash mapping to get you by.

Changed 7 years ago by realopty <realopty@…>

lame hack to backport nvram fixes

comment:17 Changed 7 years ago by JohnC60 <johnc60@…>

Thanks. I will rebuild my Attitude trunk with r27005+ tonight and verify.

Since the Attitude will not build a 2.4 kernel, I'm going to have to go back to Backfire once I'm done testing. Is the hack good for Backfire with 2.4 kernel also? Guess I'll try and find out.

comment:18 follow-up: Changed 7 years ago by JohnC60 <johnc60@…>

I applied the "hack" (multiply by 2) to Backfire RC5 (brcm-2.4) and it works, moving the NVRAM partition to 0x7e0000. The NVRAM tool is now able to commit changes that survives a reboot. Obviously, the real fix is much more elegant and I look forward to it being ported back into Backfire.

I was not able to test the hack against Backfire RC5 (brcm47xx). I cannot get brcm47xx to run. It compiles and builds with no errors but gets into a kernel panic when booting. I completely deleted everything and checked out a clean copy of Backfire. Even a plain vanilla build with no changes fails to run.

comment:19 in reply to: ↑ 18 Changed 7 years ago by hauke

Replying to JohnC60 <johnc60@…>:

I was not able to test the hack against Backfire RC5 (brcm47xx). I cannot get brcm47xx to run. It compiles and builds with no errors but gets into a kernel panic when booting. I completely deleted everything and checked out a clean copy of Backfire. Even a plain vanilla build with no changes fails to run.

Could you please open a new ticket with the panic message for this issue.

comment:20 Changed 7 years ago by JohnC60 <johnc60@…>

Oh, yes of course. I didn't mean to have a discussion about it here. I was just letting everyone know that I could not test the hack against Backfire with a 2.6 kernel.

-John

comment:21 Changed 5 years ago by blzngz008@…

frnds.... i have an issue with my android nvram part.. i had done a full format flash then after installing a new rom i got IMEI issue nd wifi... for new i did fied it.. with the help of xda but i think its temporary... bcz soon after that i again flashed a new rom... nd then IMEI nd wifi were again like that.... so... how to permanently fix it... plz email me if u could help.. thx...

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.