Lookin at your current nvram it is obvious that you have achieved something.
The nvram show from one of your first posts is short, it is taken from the data in the beginning of the cfe
and that is what happens when the nvram partition is corrupted or can't be found.
Now you have a full set of nvram variables and variables that are not present in the board_data partition of the flash so they ought to be from one of your flash write commands.
The mac addresses in your nvram are still only ff's and that is a bit strange but can be related to your environment variables.
The environment is a subset of the nvram, variables that are chosen by the cfe to be read from nvram, stored in the cfe's environment and used for some of the cfe commands.
You have three environment commands available to you, setenv, unsetenv, and printenv.
You can use the -p switch for the setenv to store an environment variable permanently in nvram, that is probably the way for you to correct the ff mac addresses in the nvram.
"Set an environment variable
setenv [-p] varname value
This command sets an environment variable.
By default, an environment variable is stored only in memory and will not be retained across system restart
-p Store environment variable permanently in the NVRAM device, if present"
"Delete an environment variable
unsetenv varname
This command deletes an environment variable from memory and also removes it from the NVRAM device (if present)"
"Display the environment variables
printenv
This command prints a table of the environment variables and their current values" _________________ Kernel panic: Aiee, killing interrupt handler!
Joined: 31 Aug 2009 Posts: 2448 Location: Third Rock from the Sun
Posted: Fri May 28, 2010 4:35 Post subject:
the -p function doesn't makem' stick. Maybe I will fool with it more tomorrow. Thanks again to everybody.
@Eko, Could I flash a know working CFE to flash0?
Still need to figure out how to save the information from the router. I f I could figure this out I could save the board data partition from my working 3300 and put it on this one.
I am not really sure what happened to the board data, I got this router this way. _________________ Peacock Thread-FAQ -- dd-wrt Wiki
I couldn't find any specific info on this via google and the broadcom cfe manual.
-4 is "Undefined error" meaning only that there was no other predefined error string describing the error in detail. _________________ Kernel panic: Aiee, killing interrupt handler!
I f I could figure this out I could save the board data partition from my working 3300 and put it on this one.
I am not really sure what happened to the board data, I got this router this way.
The board data was probably overwritten by a too long firmware, dd-wrt or openwrt. The board data from your working WNDR3300 is not any better than the one from Eko's wholeflash, it is just a matter of getting it written to the flash.
I guess, since it is possible to overwrite the POT, T-Meter and board_data with a too long firmware that this is the way they are programmed by Netgear.
There is no cfe function to write these special partions separately so it has to be done with a .trx file containing everything between the cfe partition and the nvram partition.
From the cfe, without having disassembled it just looking at text strings now, the known partitions for tftp are:
flash0.0
flash0.trx
flash0.nvram
flash0.os
flash1.nvram
flash1.trx
flash0.0 is the whole flash and what has to be specified in order to flash the cfe, danger !! _________________ Kernel panic: Aiee, killing interrupt handler!
So 192.168.1.10:board_data.bin flash1.trx is basically host:File destination?
Yes or simplified, source and destination.
I think you should try to flash everything in one go right now and don't care about board id or mac addresses.
Take Eko's whole flash, cut off the first 128KB (the cfe) so you get a file starting with HDR0.
use the command:
flash 192.168.1.10:myfile.trx flash1.trx
With some luck it will flash the firmware, board_data, and nvram.
You can then load dd-wrt onto the router and telnet and ssh into it and move the correct board_data and nvram binaries over to it and write them with the mtd command.
Edit: Eko's suggestion to remove the 64Kb of nvram in the end of the file as well as the cfe in the beginning is prolly better - you don't risk getting an error for a too long file in case they don't allow the nvram partition to be written together with the 2 others. _________________ Kernel panic: Aiee, killing interrupt handler!
Last edited by LOM on Fri May 28, 2010 12:09; edited 2 times in total
Joined: 31 Aug 2009 Posts: 2448 Location: Third Rock from the Sun
Posted: Fri May 28, 2010 12:26 Post subject:
LOM wrote:
Edit: Eko's suggestion to remove the 64Kb of nvram in the end of the file as well as the cfe in the beginning is prolly better - you don't risk getting an error for a too long file in case they don't allow the nvram partition to be written together with the 2 others.
I don't know how to cut the file, ll the files I got where from BW cutting it. _________________ Peacock Thread-FAQ -- dd-wrt Wiki
Edit: Eko's suggestion to remove the 64Kb of nvram in the end of the file as well as the cfe in the beginning is prolly better - you don't risk getting an error for a too long file in case they don't allow the nvram partition to be written together with the 2 others.
I don't know how to cut the file, ll the files I got where from BW cutting it.