Posted: Thu Jun 22, 2006 5:54 Post subject: I've got the VxWorks BSP to flash over itself!
BrainSlayer wrote:
okay lets start to write a overtaking image. mmh could someone provide a vxworks flash dump here? my one is already flashed and i lost the backup
I can give you everything you need. I'll put it somewhere and send u the link PM. We need to coordinate on IRC, but I think you sleep when I am awake (which is all night).
....
However, we *might* have another alternative .
I discovered while going through the disassembly one more file type .. file id #1, bootrom.bin!
I just got the VxWorks BSP to flash over itself with the v4 CFE by simply including the CFE in the image. Now, the unit didn't boot, likely because it stopped flashing at 40k (maybe because the file was too small).
If this works, this is the easiest way of all to flash these units. I'm looking into it now. I'll go ahead and release an updated tool with suppot for bootrom.bin.
Hmmm, I can see BOOTROM_SIZE is 10 x 32k (327680), or is it a typo?
You are too fast, ur supposed to give me time to correct my mistakes<g>. I edit 9/10 of my posts because I find mistakes soon afterwards .
You are right, it turns out there is no 32k limit, it's instead 320k! That was me mis-reading the serial output in my rush to get over here and post this new discovery . Whoops. I have a little problem with excitement.
Good news is that this means this method may very well work.
I've got to wait an hour to re-flash this thing.. by then maybe I'll have everything figured out.
Last edited by on Thu Jun 22, 2006 7:08; edited 1 time in total
// Revisions:
//
// 0.03 alpha - Added -f (fix checksum of existing firmware)
// Added support for bootrom.bin (1). Auto pads if incorrect size.
// Fixed problem with -v incorrectly calculating checksums on images with last DWORD not NULL.
// 0.02 alpha - Added build capability.
// 0.01 alpha - Early alpha. No firmware building supoprt yet.
//
I just read over your v5 takeover firmware docs...you may want to add a note that this is irreversible, meaning you can't reload the VxWorks firmware without JTAGing.
(or can you? if you make a second version of the takeover firmware meant specifically for reloading VxWorks...maybe?)
I bring this up in case a flashed v5 unit needs warranty support, and thus needs to be running 'stock' firmware.
Brainslayer, I sent you a link to a v5 wholeflash.
Ok, I've had it with the bootrom.bin option ;p. I'm not sure why yet, (perhaps there is some header involved), but I've not been able to make it flash more than about 50kb.
Brainslayer, I'm passing the football to you .
I tried creating a vmlinux that was small enough, but my stumbling around self only got to 1.6Mb. I suppose one could use some sort of decompression stub, but that adds another layer of complexity. Since I'm a linux retard, I'm sure you can do better than I in this task (I barely know what is going on). I don't have the exact number handy, but I think the vmlinux needs to be no larger than 1.4Mb or so.
A helpful user posted in this thread a place to grab a tool to adjust the ELF header so that vmlinux is loaded to the right place by the VxWorks BSP. If this tool doesn't work anymore (it seemed to be kinda fragile), it ought to be easy to make it work.
.....
Please pick up where I've left off now, I must take a break from this for a while. I am losing my mind.
I think I'll keep mucking around with bootrom.bin when I get a chance, but I don't plan on exploring vmlinux for a while. Well, ok, who knows what the future holds, I may change my mind in an hour ;p.
Anyway, good luck Brainslayer and all! Make me proud .
.....
I've updated 'the tool' and data structures again, too tired to post changes.
Latest header defintion updated 06/22/06 @ 6am EST.
Latest 'tool' version is 0.4a, same URL.
Last edited by on Thu Jun 22, 2006 11:21; edited 1 time in total
I just read over your v5 takeover firmware docs...you may want to add a note that this is irreversible, meaning you can't reload the VxWorks firmware without JTAGing.
One could concievably host the VxWorks flash image(s) somewhere on the web and allow for reversion.. but other than that, you are right.
When this project is finally done, and I am using the word 'when' now, I plan to post some very severe warnings about the irreversability and possibility of bricking if the flash goes wrong.
Joined: 06 Jun 2006 Posts: 7492 Location: Dresden, Germany
Posted: Thu Jun 22, 2006 12:56 Post subject:
you may use the lzma-loader out from openwrt or from my sourcetree
src/router/lzma-loader/rb500 contains a special one which creates a compressed vmlinux file with a elf header. i'm using it for the mikrotik rb500. you maybe need to adjust the memory segments etc. but it should be easy at all
flashing if the bootrom itself with this trick would not be possible in your way, since the vxworks bootrom is bigger than the cfe. i guess this is your problem. another thing. while booting the kernel you may find out that the mtd partitions will no be created. because the trx header is missing in the flash. so you have maybe to adjust the mtd partition code in setup.c too _________________ "So you tried to use the computer and it started smoking? Sounds like a Mac to me.." - Louis Rossmann https://www.youtube.com/watch?v=eL_5YDRWqGE&t=60s
you may use the lzma-loader out from openwrt or from my sourcetree
src/router/lzma-loader/rb500 contains a special one which creates a compressed vmlinux file with a elf header. i'm using it for the mikrotik rb500. you maybe need to adjust the memory segments etc. but it should be easy at all
flashing if the bootrom itself with this trick would not be possible in your way, since the vxworks bootrom is bigger than the cfe. i guess this is your problem. another thing. while booting the kernel you may find out that the mtd partitions will no be created. because the trx header is missing in the flash. so you have maybe to adjust the mtd partition code in setup.c too
Ok, Thanks. I'll take a look at this when and if I can. Let me know if you get to it yourself. Everything linux takes me at least 2x longer than it would a linux guru. I figured I could use a decompression stub like you suggest, but couldn't get any of the openwrt people to give me an answer when I asked about it.. (nobody cares ;p).
As far as the BSP being bigger than CFE, yea it is by 64k. My tool automatically pads a bootrom.bin if its not big enough, but this didn't solve the issue. I dunno what the problem is.. but I suspect there is some sort of header or flash mapping at the beggining of the BSP (you can see some sort of table is there). Of course, I tried just slapping this table over the first 0x400 bytes of the CFE (for experimentation), but that didn't help either.
Thanks for heads up about the mtd .. I woulda surely run into that...well, if I ever get this done. The thought of going back into linux to muck around with vmlinux more doesn't appeal to me at the moment ;p.
Well, I guess I'll take the initiative ... if I don't finish this now it may never get done.
I'd still like to figure out why bootrom.bin isn't working right, as it would be the easiest way to upgrade the CFE. However, I'll go much with vmlinux .. since it ought to be pretty easy.
If anyone wants to chat about this project on irc...
Joined: 06 Jun 2006 Posts: 7492 Location: Dresden, Germany
Posted: Fri Jun 23, 2006 10:53 Post subject:
after flashing the bootrom, the nvram area needs to be cleared too. otherwise all switch lamps will go on and thats it. i'm now in the irc. but the channel is empty _________________ "So you tried to use the computer and it started smoking? Sounds like a Mac to me.." - Louis Rossmann https://www.youtube.com/watch?v=eL_5YDRWqGE&t=60s
after flashing the bootrom, the nvram area needs to be cleared too. otherwise all switch lamps will go on and thats it. i'm now in the irc. but the channel is empty
I'm there too now, I had accidentally created the channel on Efnet first.. too many damn irc networks at once.. A sign I waste far too much time on IRC .
I hadn't even got it to flash completely .. so didn't make it to that point.. but if the nvram needs to be cleared too, that might not be a problem.. depending on if one of the other file types flashes over the area the CFE uses for nvram storage.
Joined: 06 Jun 2006 Posts: 7492 Location: Dresden, Germany
Posted: Fri Jun 23, 2006 13:15 Post subject:
the nvram is alwas aligned to the end of the flash and is 32 kb _________________ "So you tried to use the computer and it started smoking? Sounds like a Mac to me.." - Louis Rossmann https://www.youtube.com/watch?v=eL_5YDRWqGE&t=60s
Posted: Fri Jun 23, 2006 23:06 Post subject: got it ;)
I made a very silly mistake that cost us two days.. turns out I had this problem solved when I dsicovered bootrom.bin . Well, almost anyway.
I just spent 7 hours in a disassembler, looking for a problem that didn't exist..... so, please forgive my delerium.
I've got the entire CFE flashing via bootrom.bin method. It actually always was, I just assumed it wasn't.. the written size is in hexadecimal, but I assumed decimal due to misintepreptations of other things, specifically:
The bootrom is written in one swipe, unlike the other file types that are written in ~100k blocks.. This made me think that it was aborting pre-maturely,
I was so convinced it didn't flash, I never checked it. I was attempting to flash the WRT54Gv4 CFE, which WON'T BOOT on the WRT54G v5.
Furthermore, I discovered in my disassembly that the size should actually be 319k, since there is a 1024 byte BOOTP storage area at the end of the BSP that is not flashed.
However, the WAP54G CFE *WILL* flash fine, as we all know. All I have to do is use it instead and all should be fine. If I need to wipe out nvram and kernel, no problem there.. we already know how to flash the rest of the device with the other file types .
----------------------------------------
I must wait about an hour to have my unit back to default state. Then I almost certainly will have it working.
This is a bit premature, but I am pretty damn certain it'll work.
Last edited by on Sat Jun 24, 2006 9:22; edited 3 times in total
.
.