Source to U-boot

noblepepper
 
Posts: 240
Joined: Sat Nov 29, 2014 3:22 pm

Re: Source to U-boot

Sun Dec 13, 2015 8:02 pm

I have been playing with uboot again (tryiing to load an image off usb storage this time) so this is in brain cells I haven't killed with beer yet since I mangaged to brick my VoCore at least once recently.

I hope you made a backup of the factory section before you did any of this if not do it now using flashrom before you try the below. factory is unique to each vocore and without it you have no wifi!!!

Gitoriuos has closed up shop so the source to GNUtoo's work isn't available there any more. I made a copy here. There is a link on the page to some documentation but my particulars are:

After loading the software on my Uno I do this to test the set up:
Code: Select all
./flashrom -p serprog:dev=/dev/ttyACM0:115200
flashrom v0.9.8-r1888 on Linux 3.2.0-4-amd64 (x86_64)
flashrom is free software, get the source code at http://www.flashrom.org

Calibrating delay loop... OK.
serprog: Programmer name is "serprog-duino"
Found Winbond flash chip "W25Q128.V" (16384 kB, SPI) on serprog.
No operations were specified.

If it finds the flash you should be ready to go.

You need a layout file, I call mine flashromlayout and its contents look like this:
Code: Select all
0x000000000000:0x00002FFFF uboot
0x000000030000:0x00003FFFF uboot-env
0x000000040000:0x00004FFFF factory
0x000000050000:0x000FFFFFF firmware


This let's you write only one of the flash sections, in this case we just want to write the uboot section. If you try this with the uboot from Vonger's server which is the one that came on your VoCore you get this
Code: Select all
./flashrom -p serprog:dev=/dev/ttyACM0:115200 -l ../../flashromlayout -w ../../uboot.img -i uboot
flashrom v0.9.8-r1888 on Linux 3.2.0-4-amd64 (x86_64)
flashrom is free software, get the source code at http://www.flashrom.org

Using region: "uboot".
Calibrating delay loop... OK.
serprog: Programmer name is "serprog-duino"
Found Winbond flash chip "W25Q128.V" (16384 kB, SPI) on serprog.
Error: Image size (136708 B) doesn't match the flash chip's size (16777216 B)!
which confused me for quite a while but I eventually figured out the file you try to write needs to be the full size of the flash chip even though we only write the uboot portion.
Code: Select all
dd if=/dev/zero bs=1 count=16673024 >>uboot.img
turned out to be the magic incantation. After that I can
Code: Select all
./flashrom -p serprog:dev=/dev/ttyACM0:115200 -l ../../flashromlayout -w ../../uboot.img -i uboot -c W25Q128.V -VV
flashrom v0.9.8-r1888 on Linux 3.2.0-4-amd64 (x86_64)
flashrom is free software, get the source code at http://www.flashrom.org

flashrom was built with libpci 3.1.9, GCC 4.7.2, little endian
Command line (11 args): ./flashrom -p serprog:dev=/dev/ttyACM0:115200 -l ../../flashromlayout -w ../../uboot.img -i uboot -c W25Q128.V -VV
romlayout 00000000 - 0002ffff named uboot
romlayout 00030000 - 0003ffff named uboot-env
romlayout 00040000 - 0004ffff named factory
romlayout 00050000 - 00ffffff named firmware
Using region: "uboot".
Calibrating delay loop... OS timer resolution is 1 usecs, 2013M loops per second, 10 myus = 9 us, 100 myus = 98 us, 1000 myus = 978 us, 10000 myus = 10013 us, 4 myus = 4 us, OK.
Initializing serprog programmer
Baud rate is 115200 now.
serprog: connected - attempting to synchronize
...
serprog: Synchronized
serprog: Interface version ok.
serprog: Bus support: parallel=off, LPC=off, FWH=off, SPI=on
Warning: Automatic command availability check failed for cmd 0x08 - won't execute cmd
Warning: Automatic command availability check failed for cmd 0x11 - won't execute cmd
serprog: Programmer name is "serprog-duino"
serprog: Serial buffer size is 65535
serprog: Warning: Programmer does not support toggling its output drivers
The following protocols are supported: SPI.
Probing for Winbond W25Q128.V, 16384 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4018
Found Winbond flash chip "W25Q128.V" (16384 kB, SPI) on serprog.
Chip status register is 0x00.
This chip may contain one-time programmable memory. flashrom cannot read
and may never be able to write it, hence it may not be able to completely
clone the contents of this chip (see man page for details).
serprog_delay used, but programmer doesn't support delays natively - emulating
Block protection is disabled.
Reading old flash chip contents...
and wait for a very long time and I have uboot back!

noblepepper
 
Posts: 240
Joined: Sat Nov 29, 2014 3:22 pm

Re: Source to U-boot

Sun Dec 13, 2015 10:55 pm

I'm curious as to why this didn't work for you. Did you use the precompiled uboot or download the source and compile yourself? I just downloaded the precompiled uboot and wrote it to my vocore with no problems.

Once the mtd write completes and you see "rebooting" there isn't much that can go wrong if the uboot image is good.

What do you mean by "just sits there" are you connected by the UART, ssh or the Luci interface? Is there any output at all?

nkhorman
 
Posts: 2
Joined: Sat Dec 12, 2015 9:14 pm

Re: Source to U-boot

Tue Dec 15, 2015 5:31 pm

noblepepper wrote:I'm curious as to why this didn't work for you. Did you use the precompiled uboot or download the source and compile yourself? I just downloaded the precompiled uboot and wrote it to my vocore with no problems.

Once the mtd write completes and you see "rebooting" there isn't much that can go wrong if the uboot image is good.

What do you mean by "just sits there" are you connected by the UART, ssh or the Luci interface? Is there any output at all?


I did use the precompiled uboot from your github https://github.com/noblepepper/ralink_sdk/releases/download/v0.1c/uboot.img.
Yes, I was connected to the serial console, and no, there was no further output after the reboot, hence, "it just sits there"
I admit that I mistakenly skipped the mtd command to zero the uboot env, but I wouldn't expect that to stop uboot from generating output on the console.
The one thing that I didn't do, regretfully, is validate the integrity of the uboot image that I scp'd to the linux /root before issuing the mtd write command, something, that won't happen again.

Thanks for all your usage notes in the previous posting, I'll let you know how things fall out when I further attempt recovery.

Regards

noblepepper
 
Posts: 240
Joined: Sat Nov 29, 2014 3:22 pm

Re: Source to U-boot

Wed Dec 16, 2015 11:33 am

Strange...

I just downloaded from the link you posted and wrote it to uboot and all is fine here.

Zeroing the uboot environment is totally optional, all it really does is give you this when you reboot
Code: Select all
.*** Warning - bad CRC, using default environment
until you do a saveenv in uboot.

Worst case if you don't have a Arduino and level translator chip laying around you could send the vocore to me and I can write the flash for you. Of course where you are located may make that more expensive than a new VoCore.

If you are working with a VoCore with dock i made a little adapter board to plug in the sdcard slot to get connection to the spi signals without "undocking". I did need to solder an additional wire to one of the pins betweeen the VoCore and the dock to get CS0 since the sdcard slot uses CS1.
Image

Vonger
 
Posts: 742
Joined: Sun Oct 19, 2014 6:00 am

Re: Source to U-boot

Wed Dec 23, 2015 3:15 pm

nkhorman wrote:
noblepepper wrote:I'm curious as to why this didn't work for you. Did you use the precompiled uboot or download the source and compile yourself? I just downloaded the precompiled uboot and wrote it to my vocore with no problems.

Once the mtd write completes and you see "rebooting" there isn't much that can go wrong if the uboot image is good.

What do you mean by "just sits there" are you connected by the UART, ssh or the Luci interface? Is there any output at all?


I did use the precompiled uboot from your github https://github.com/noblepepper/ralink_sdk/releases/download/v0.1c/uboot.img.
Yes, I was connected to the serial console, and no, there was no further output after the reboot, hence, "it just sits there"
I admit that I mistakenly skipped the mtd command to zero the uboot env, but I wouldn't expect that to stop uboot from generating output on the console.
The one thing that I didn't do, regretfully, is validate the integrity of the uboot image that I scp'd to the linux /root before issuing the mtd write command, something, that won't happen again.

Thanks for all your usage notes in the previous posting, I'll let you know how things fall out when I further attempt recovery.

Regards



Hi,
If you meet such problem have to use some "high skill" way to unbrick it.

There are some ways:
1. unsolder the flash chip and flash it by computer(you need a burn device).
2. connect to another spi device(such as another vocore, set cs1 in spi status too) to your current vocore spi port(cs1 -> cs0), keep the brick in reset mode(this might not necessary, it is already brick, will not broken the signal), the working VoCore is able to mount the flash as another mtd device, then you can write into it.

Previous
Return to VoCore & VoCore+Dock

Who is online

Users browsing this forum: No registered users and 2 guests