U-Boot Hacking

[Alex H]

 Hey, all!

I've been wanting to do some U-Boot hacking on my GB-PC1. I want the boot process to be less "embedded computer" and more "personal computer".

I want to change U-Boot so it instead boots a kernel in a filesystem on a plugged in USB or SATA drive or SD card; failing that it will boot the kernel on flash for recovery.

This allows the firmware, kernel and rootfs on flash to be untouched (until necessary), and make kernel hacking easier, too.

What hardware will I need? I'm a little confused by what I've read about the debricking process. In this post, Larry Pinney mentions installing a SOP8 adapter and putting a flash chip on that. However, it is also mentioned to use another board that has a similar CPU and has an available SPI interface to flash the chip. The former suggests to me that the headers are for a secondary flash chip to boot from, but the latter suggests that they're to program the primary flash chip. I looked at the schematics for my board and it looks to me (not an electrical engineer) that the headers are shared by the flash chip. I may simply be misunderstanding Larry about how to use a SOP8 adapter.

I'm not sure what is shown in debrick-01.png. It looks to be an unmarked flash chip installed on an adapter. That is contrary to my theory that the headers are for programming the flash, or it could be a "dummy" chip for connecting a Pomona 5250.

Would I be able to solder some header pins and use a SBC to program the flash chip?

Thanks!

[Neil Brown]

I think you can experiment with u-boot without any hardware hacking.  I haven't actually tried this, but I have a high expectation of success.

The GB-PC1 has a 32M flash ROM, but the standard SPI protocol for accessing flash only supports 16MB.  Various extensions have been added to the protocol by various vendors.

There is a mode where you program in the msb to select bottom half or top half, and then access that half normally.  It is quite easy to get into this mode my accident.

Why you power-off the GB-PC1, the flash chip resets and will access the bottom half when powered on again, but if you reboot from Linux, it only works reliably if we soft-reset the Flash ROM.

See SNOR_F_BROKEN_RESET in the Linux kernel source.

It would be quite easy to get that soft reset to SET the msb, rather than clear it.  If you did this then:

- when you power-cycle, the CPU will load from the bottom half of flash

- when you reboot from Linux, the CPU will load from the top half of flash

This is exactly the sort of thing you want for u-boot hacking.

So you could:

- modify Linux to set the bit rather than clear it

- modify the partition table to place a second "u-boot" partition at the 16Meg mark. (and as secondary u-boot-env  and probably a secondary firmware).

- copy the normal u-boot partition over the secondary u-boot partition, and maybe binary-edit it so that some message changes (unless that will break a checksums)

and try it out.

Doing this will reduce the space for firmware from (nearly) 32M to (nearly) 16M.  The firmware I produce is 20M which is too large.

If you stripe out all the modules that you don't want - and some of the initramfs - you should be able to get it under 16M easily.

I've love to read about any success you have with this, am happy to help if the above isn't clear enough.

[Alex]

Thanks, Neil!

That's a clever idea. I might give it a go. 16 megs, though. That will be tight. At least I have UART access and won't need anything internet related.

I'll still look at hardware hacking. I *will* goof something and will need some way to recover.

I just don't want to fry my gnubee. Messing up will force my hand and I'll have no other choice but to hook things up and hope for the best.

--
You received this message because you are subscribed to the Google Groups "GnuBee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gnubee+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gnubee/82084041-c535-4b89-8d1b-a18c5f98c425%40googlegroups.com.

[Eric Culp]

Besides messing with uboot, you could flash a kernel and init that search your devices and kexec another kernel or else start a recovery shell. I essentially have that now except it does switch_root instead of kexec.

It's easy to debug over serial and if you mess it up, you can easily flash over usb.

To view this discussion on the web visit https://groups.google.com/d/msgid/gnubee/CAOP%2B-DuJiMRD1W7uMTwaP_mQHx9ikxO0mObh1NW0NZNTG1AnxA%40mail.gmail.com.

[Alex]

kexec is my backup plan :)

Same way Petitboot works. I want to try pushing U-Boot to reduce intermediate steps and see where that goes.

Don't know why it never occurred to me before, but I do own a small wireless router that has an accessible 16MB flash (Winbond, too!) and USB port that I could try practicing on. It's an Atheros, though.

[Neil Brown]

Your interest in u-boot hacking has helped motivate me to do something I've wanted to do for a while - and which I described in general terms already.

So if you get my latest gnubee/v5.6 kernel, and may latest gnubee-tools, and run

make firmware-gbpc1u-5.6

it will build a firmware image called gnubee-5.6.3-gbpc1u.bin - or you can just download from http://neil.brown.name/gnubee/

This firmware image doesn't have various recovery and installation tools, but it is enough to boot most configs.

It also doesn't contain lots of modules (sound, netfilter etc) but you usually only need them first-boot anyway.

Consequently it is less than 16MB.

The kernel in this firmware partitions the 32MB flash differently - The normal uboot, env, factory, firmware partitions still exist in the first 16MB (the 'firmware' partition is smaller)..

There is a second set of these 4 partitions in the second 16MB.

Finally, the kernel has a small hack so that when you 'reboot -f', the flash is configured so that "3-byte address reads" (as generated by the MT7621 during boot) read from the second half of the flash.

The net result is that if you copy a new u-boot into /dev/mtd4 and reboot, it will boot using that new u--boot.  But if you power-cycle, it will boot using the normal u-boot.

Also, I've fixed some issues with the GnuBee u-boot so you can build it with newer gcc.

So on you gnubee you can:

apt-get install libncurses5-dev zlib1g-dev

git clone https://github.com/neilbrown/GnuBee_PCx_uboot.git

cd GnuBee_PCx_uboot
cd  uboot-5.x.x.x
cp ../profiles/GB-PCx/GB-PCx-config-900MHz .config
make menuconfig # Just exit and save

make -j4  CROSS_COMPILE=/usr/bin/ # takes about 1 minute - lots of warnings.

flashcp -v uboot.bin /dev/mtd4

reboot -f

and this will boot using your newly compiled u-boot.

What I would really like to do longer term is to modify the u-boot so that if the press-button isn't pressed and if the u--boot- env contains suitable instructions, then it immediately chains to a boot loader somewhere else in flash (maybe at the end).

Then we could leave the main u-boot otherwise untouched and largely ignore it except when something goes wrong.  All interesting functionality can be added to the secondary u-boot which can be updated freely, with the assurance that (as long as you have physical access to the gnubee), it is easy to unbrick and start again.

[Alex]

I've been working on this on-and-off for the past six months and have learned some things.

My number one concern for this was putting U-Boot in a state where it could no longer boot and allow recovery from software. I finally got all the tools (and nerves) last weekend to at least read the flash chip contents through an external SPI programmer.

I wanted to see if it was possible to read and write the flash chip "in-place" while still attached to the board.

I've come to the conclusion that may be unwise.

I soldered some headers for the SPI connections to the board and connected them to an SBC. Too much power is drawn from the 3.3V and causes the SBC to flake out. I can confirm that there are no shorts. Some tutorials on the web say that some SBCs can only supply limited current on the 3.3V pin and will need an external power source for programming flash chips. I can see the ethernet power LEDs light up when the SBC 3.3V is connected so I'm assuming that other chips and components are also receiving power and overwhelming the SBC. I got an ATX PSU to benchtop power conversion kit in case the SBC could not provide enough amps. Before connecting I tested with a voltmeter and got 3.31V from the PSU. Sometimes it works and I can run `flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=2000` and it will correctly identify the W25Q256.V chip. Other times connecting the power causes the PSU to shut off. No (5 amp) fuses are blown and the PSU specs state that it can supply 3.3V at 30A; it is a 700 watt PSU.

One thing I notice now is that the power LEDs for the ethernet jacks no longer light up. The ethernet activity lights work. The board still boots, so that's a relief.

--
You received this message because you are subscribed to the Google Groups "GnuBee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gnubee+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/gnubee/da5aaf8c-d0a7-4138-aeda-72aeaecaa63c%40googlegroups.com.

[Alex]

Ok, good news! I did not damage my GnuBee.

The way I had things wired at first was to have ground from the flash chip attached to the ground of the PSU. I realized that would not be ideal if I wanted to read from the flash, so I attached ground from the flash chip to a ground pin on my SBC. That stopped my PSU from shutting down but that caused the 3.3 volt supply to drop to below 2.5 causing the lights on the ethernet jacks to be too dim to be seen.

One thing about certain PSUs is that they will power off if they don't detect a sufficient load. I wondered if there was some internal oddity from a lack of load causing the voltage to drop so much. I attached some case fans to the 12 volt supply to give a load for the PSU. That fixed the 3.3 volt supply dropping and I can read the flash with absolutely no problems. I will try writing to the flash someday. I'm just glad I did no damage.

[Miles Raymond]

Would it be possible to have the PSU power both the SBC and the GnuBee SPI directly?

I am very interested to know if there was any progress on making a new uboot to control boot flow.

Ideally I'd like it to prioritize:

1. SD

2. USB

3. SATA

4. SPI as last resort

[Miles Raymond]

Do you know why are there 2 uboot versions when GnuBee2 boots up? Is there an internal uboot (1.1.3) in the SoC which loads the uboot (5.0.1.0-6) from SPI?

U-Boot 1.1.3 (Aug  7 2017 - 16:23:41)

Board: MediaTek APSoC DRAM: 512 MB

Config XHCI 40M PLL

MediaTek SPI flash driver, SPI clock: 45MHz

spi device id: 1 2 19 4d

find flash: S25FL256S

*** Warning - bad CRC, using default environment

============================================

MediaTek U-Boot Version: 5.0.1.0-6

--------------------------------------------

Or are both uboot versions stored on the SPI just at different locations and accessed with different methods?