modding another u-boot

As I mentioned in another thread in the u-boot section, a few months ago i bought a nexx wt3020 minirouter device.

for those wondering, here is the openwrt page, it's white and cute, but it has CHINESE written all over it (literally) https://wiki.openwrt.org/toh/nexx/wt3020
I have the one with the USB port obviously.

The plan was to "marry" it (marry= connect it in a kinda permanent way) with a huawei 3372h usb 3g/4g dongle, since that dongle also features a microSD slot (and 2 external antenna ports) I could use to expand the firmware into.
Then hack together a battery pack for it with a couple 18650 li-ion cells I have laying around + voltage control circuit, and get a FOSS, pro-hacker version of the soap-like battery-powered 3g/4g devices you can get for 80 euros or so at the local carrier shop (or unbranded from ebay).

(a quick digression: I also cross-flashed the dongle back to "stickmode", the official name for "stay in plain USB modem mode", by default these devices seem to run some kind of weird router firmware with its own IP address, webinterface and all, the mode/firmware is called "HiLink")

At the moment everything works fine with stock bootloader (u-boot), OpenWrt inside and extroot into the external storage.

But I wanted a slightly less brainless bootloader that could allow me to boot an uimage + dtb from an ext4 partition on usb, just like we can do with Debian here.

This way I could devise some scripts to keep my little precious auto-updated from openwrt trunk's uImage and rootfs without the annoyance of dealing with read-only squashfs, kernels flashed raw to flash, and all that.

It isn't a kirkwood device, obviously (that's why I posted here), but its bootloader is u-boot and there are sources around.

I found sources of a working u-boot for my device here (last post, on second page talks about dtb and the modifications he did to the u-boot for that web-recovery feature) https://forum.openwrt.org/viewtopic.php?id=54717 (also on github) and found out it is basically based off mediatek sources and compliled with their SDK, so I uhm... fetched the latest mediatek SDK from uhm... shady chinese-only filesharing sites, now I have sources and toolchain to build it.
I was wondering if someone could give me some pointers.

From the sources it seems the current u-boot (in the /common folder of either full sources and custom u-boot sources) can already work with usb as it does have the usb code and also the code to do a fatload.

I was wondering what would happen if I just copy-pasted the ext4load code (and its dependencies), plus change the "boot" code to boot with dtb (by looking at other sources of a command that does) then I ricompile with the toolkit.

This SoC does not have the VERY VERY NICE feature of serial booting we have in kirkwood, or if it has none is talking about it. Will have to look at the docs of the .... um... SDK. At least they are in english.

I'm currently looking for a good spi flash programmer, possibly one that works on linux and with flashrom, so that I can test my bootloader and debrick this device when I test my new uboot.

So far I found only good ones that only work on Windows. this is the current best of the bunch (I'm avoiding chinese ones as I know the quality of their control software, that it likely won't run at all on anything newer than XP, and of the translations in the program interface) http://www.ebay.com/itm/291574131371?_trksid=p2060353.m1438.l2649&ssPageName=STRK%3AMEBIDX%3AIT

Found the spi flasher device. Buspirate 3.6, it's supported by flashrom and isn't chinese (a polish clone, but the buspirate is openhardware anyway, so it's fine).

bobafetthotmail Wrote:
-------------------------------------------------------
> Found the spi flasher device. Buspirate 3.6, it's
> supported by flashrom and isn't chinese (a polish
> clone, but the buspirate is openhardware anyway,
> so it's fine).

You got a link for this? ......



Edited 1 time(s). Last edit at 03/29/2016 11:45AM by Gravelrash.

bobafetthotmail ,

> I was wondering what would happen if I just
> copy-pasted the ext4load code (and its
> dependencies), plus change the "boot" code to boot
> with dtb (by looking at other sources of a command
> that does) then I ricompile with the toolkit.

Most likely it won't work. You have a better chance starting with the latest u-boot source.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

> You got a link for this? ......

You might need this to unbrick some of your devices lol.

I bought this one ->
http://www.ebay.co.uk/itm/BUS-Pirate-V3-6-clone-cable-with-probes-interface-analyzer-programmer-/301871729195?hash=item4648f50a2b:g:sucAAOSw-W5Uwss5

I'm still waiting for it, but the buspirate is a well-known device and you can find tutorials and stuff.

> Most likely it won't work. You have a better chance starting with the latest u-boot source.

Awwwwwwwwwwwwwww. :(

So you say it is easier to port the current u-boot to work on them than to add a bit of functionality to older one?

Might be harder than I anticipated.

Will have to go look at how it is customized for the hardware then and port that over.

bobafetthotmail,

> So you say it is easier to port the current u-boot
> to work on them than to add a bit of functionality
> to older one?

It is easy to rebuild stock u-boot with GPL exactly as it was. But adding a new file system driver to the stock u-boot is not simple. OTOH, if you only want to add some commands, then it is doable.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bobafetthotmail Wrote:
-------------------------------------------------------
> > You got a link for this? ......
>
> You might need this to unbrick some of your
> devices lol.
>

Definitely - although shame it wont help with the ones that have died at the hands of "Emperor Mings heatray" hot air paint stripper :)

> Definitely - although shame it wont help with the ones that have died at the hands of "Emperor Mings heatray" hot air paint stripper :)

Btw, I plan to solder short wires on the current chip's pins so I can attach the probes firmly without desoldering it from the board.

Like this (my chip has less pins, but you get the idea) http://www.usbjtag.com/jtagnt/spiflashsolder.jpg

bobafetthotmail Wrote:
-----------------------------------------------------
> Like this (my chip has less pins, but you get the
> idea)
> http://www.usbjtag.com/jtagnt/spiflashsolder.jpg

Nice! - will you be using mantis scope or simllar? or are you a JEDI with a soldering iron?

> Nice! - will you be using mantis scope or simllar? or are you a JEDI with a soldering iron?

I'm able to solder flash chips like the one in photo by hand, given enough time. It's not SMD chips with hundreds of minuscule feet or BGA.

The one in my router (and in your thin clients) has relatively big feet, so it is easy, see here https://forum.openwrt.org/viewtopic.php?id=54717 .

Of course I'm using a temperature-controlled small-tip soldering iron, and the magical solder wick takes care of most screwups.

The big issue isn't the magnifier though, but the steady hand. I use plenty of supports with pincers and things to keep stuff in place.

This one under the speaker in the t5325 thin clients.

-syong

Quick update, the buspirate can see and operate on the onboard flash, imaged the thing.

I also discovered rare and powerful artifacts from modern china called "SOIC clips" or "<name of the chip package> clip" that simply clamp on the chip and let me connect cables to the programmer to work on the EEPROM.
http://www.ebay.co.uk/itm/Programmer-Test-Clip-SOP8-SOP-SOIC-8-SOIC8-DIP8-DIP-8-Pin-IC-Test-Clamp-/311609665525?hash=item488d6227f5:g:6woAAOSw8vZXMfha

Also, I found around (in a cooler master stacker case from 2004) an obsolete motherboard (MSI P35 Platinum, socket 775, "gaming" mobo).

It starts up partially but from the debug leds (it's a high-end board from the past) fails to recognize the processor. The processor is in the "compatible at lowest BIOS version" list, and the board has issues recognizing 2GB RAM, so I'm assuming a BIOS reflash/update would save it.

Tried the buspirate on its bios chip (soldered but there is a header) and other EEPROMs (removable chips) from other motherboards I have. Nope. Not even with the latest flashrom.

I'm off to ebay again and the cheepest programmers are based off a CH341A chip, looked them up, it seems their USB protocol was reverse-engineered last year, and was then added to Flashrom 9.8 and newer. (there is also an opensource linux utility for operating this device for flashing also 24xxx chips as it can flash them too, https://github.com/setarcos/ch341prog )

http://www.ebay.com/itm/152069847771?_trksid=p2060353.m1438.l2649&ssPageName=STRK%3AMEBIDX%3AIT

Thanks for the great information about flashing in the "hard" way.

In the t5325, I found 3 different SPI flashes in the stock boxes:

1. SST25VF080B
2. MX25L8005
3. Numonyx-25P80

I can not do UART booting for the boxes with SST25VF080B, but fw_printenv/fw_setenv works flawlessly on these boxes.

I can do UART booting for the other boxes, but fw_printenv/fw_setenv does not work on those.

These imply that we can do wol on box with SST25VF080B and the stock uBoot, while testing new uBoot with UART booting on other boxes. For the new uBoot, wol seems the most interesting.

-syong

> For the
> new uBoot, wol seems the most interesting.

Not :) The approach HP uses for T5325 u-boot to do WOL is pretty messy.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

@bodhi,

Do you already have a better way in your uBoot?

I can not find your source for the t5325 uBoot.

If it is messy, let's clean it up, together. :)

-syong

> If it is messy, let's clean it up, together. :)

the approach of HP's t5325 u-boot is beyond stupid.

The firmware rewrites envs each power off, the system then does not "power down" but reboots and the new envs bring it into a "ninja low-power mode" and it waits there, when receives a signal from the WoL it rewrites envs and reboots again into its normal firmware.

I mean.... no. Just... no. :)

bobafetthotmail Wrote:
-------------------------------------------------------
> > If it is messy, let's clean it up, together. :)
>
> the approach of HP's t5325 u-boot is beyond
> stupid.
>
> The firmware rewrites envs each power off, the
> system then does not "power down" but reboots and
> the new envs bring it into a "ninja low-power
> mode" and it waits there, when receives a signal
> from the WoL it rewrites envs and reboots again
> into its normal firmware.
>
> I mean.... no. Just... no. :)

Yeah, I've looked at that in the GPL, too. Not a real WOL like what we'd expect to see.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

syong,

> I can not find your source for the t5325 uBoot.

I have not pushed it to the u-boot GitHub. I was debating myself whether to rebase my repo to u-boot to 2016.05 and release all at the same time :)

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 05/20/2016 05:25AM by bodhi.