Hacking u-boot for Pinebook. Part #1 - using FEL

It's been a while since I posted to my blog. A lot of things happened since then, I guess the most important is -- I moved to Canada. I've been living in Vancouver (OK, Greater Vancouver) with my wife and cat for more than 2 years now. But enough about me, let's get back to the topic.

Recently I've got a Pinebook, mostly for hacking purposes. It's pretty nice device - quad-core Allwinner A64 CPU, 2GB LPDDR3 RAM, eMMC storage, etc, etc. See pine64.org for full specs. But unfortunately it comes with BSP kernel from Allwinner which is pretty ancient - 3.10 (released in 2013, more than 4 years ago!)

Hopefully, mainline support for A64 is in pretty decent shape, see http://linux-sunxi.org/Linux_mainlining_effort. Sure some things are missing - LCD, sound, power management, and that's not all. But it's good - there's something to hack on, right?

So I decided to start with u-boot. Hopefully, Allwinner SoCs support boot over USB - it's called FEL, see http://linux-sunxi.org/FEL for details. So basically it's possible to load and execute SPL to configure DRAM, and then load and start u-boot. That's very convenient for development - you don't have to do SD-card juggling, just connect your laptop to the board using USB cable (USB-A to USB-A in my case), load your card with special image and you're good to go.

Unfortunately, 64-bit SPL doesn't support jumping back into FEL which is 32-bit code. To overcome this issue, it's possible to build SPL in 32-bit mode. It's not supported in mainline u-boot at the moment, but there're patches on the list, see https://lists.denx.de/pipermail/u-boot/2016-November/271732.html
So it works like this:

  • Load and executre 32-bit SPL using FEL, which jumps back to FEL code after it's done
    • sunxi-fel spl sunxi-spl.bin
  • Load ATF (ARM trust firmware)
    • sunxi-fel write 0x44000 bl31.bin
  • Load u-boot
    • sunxi-fel write 0x4a000000
  • Jump into 64-bit ATF, which jumps to u-boot after it's done:
    • sunxi-fel reset64 0x44000
Don't try to flash your card with 32-bit SPL and 64-bit u-boot - that won't work. 32-bit SPL doesn't know how to switch to 64-bit mode, use it only with FEL.

That's it for today. In part #2 I'll be talking about PMIC and LCD on Pinebook.

Comments

Nico said…
Hello Anarsoul,

A quick thank you for your Alarm image. I use it since 2019 on my Pine A64 LTS. I finally removed your custom repo and switched to plain Archlinux Arm ones, but it still works well, although I lost my BT/Wifi add-on card on the manufacturer slot over time. Not that much a problem, I use Ethernet.

This box hosts my screen'ed irssi which I can use through a SSH session. More important, it has some nifty services for the Cjdns-propelled Hyperboria trusted overlay network :

-It's the home of the Dir, the human-curated directory of websites that are reported automatically as currently reachable on Hyperboria (Hyped websites as we say). Thanx to your effort. Human part is just people categorizing them by tags.
-It is also the host of the initial tracker peer of the Hyperboria "Cjdradio" P2P audio streaming infrastructure, and also hosts one radio "station" (not real webradio, indeed, each stream being user specific).

I chose your image at the time, because Armbian just had no X. It gave me the opportunity to discover Arch Linux, I'm very happy since.

Many thanks
June 22, 2024 at 8:36 AM
anarsoul said…
Hey Nico,

Happy to hear that it's still useful for someone! :)

However as you already discovered, you shouldn't really need my custom repo anymore, since most of my changes are upstream now.

To get BT working you just need a device tree that enables BT node (or an overlay) and firmware from https://github.com/anarsoul/rtl8723bt-firmware in your /lib/firmware

For WiFi you also need a device tree that enables WiFi node (or an overlay) and 8723cs driver.

I'm using Archlinux ARM on most of my ARM devices, and for a new device I just bootstrap it on another working ARM device with arch-install-scripts.

Regards,
Vasily
June 27, 2024 at 10:39 PM
Post a Comment

Popular posts from this blog

Access point with Raspberry Pi and rtl8192cu dongle

On Thursday ethernet ports (WAN and LAN1-4) in my Asus WL500GPv1 router have completely died, so I needed a replacement. Hopefully, recently I've got Raspberry Pi, so I decided to use it as a router. I've got TP-LINK TL-WN821NC USB stick from local store which is based on RTL8192CU chipset. Unfortunately, its driver doesn't work with vanilla hostapd, but requires patched ancient version of hostapd from Realtek . I'm using Archlinux on my rpi and I've found manual how to setup AP using this USB stick  here , but I don't want to overwrite binaries from repository packages, since it's not a sane way, and it can (and will) be broken by hostapd update. So I prepared a package, here's source package (just unpack it and build with makepkg directly on rpi), and here's binary package for armv6h (you can install it with pacman -U). I can't put PKGBUILD in AUR, since there's no stable hosting for Realtek's hostapd. If anyone is willing to host
Read more

Wayland and software rendering

Image
Recently I spent few evenings for hacking wayland . I like idea of wayland - rendering is done completely on client (in whatever way), compositor (server part) is responsible in rendering buffers from clients on the screen. Issue for me was rendering part of weston (reference compositor for wayland) - it uses GLES for compositing, but I want to try wayland and weston on devices without hw acceleration (pure software rendering), and running software GL on PXA270@312MHz does not sound like a good idea, does it? :) So I asked on #wayland@irc.freenode.org if it possible to implement software renderer, Kristian Høgsberg (khr) responded that in master branch of weston repo there's a nice abstraction of renderer, so it's possible to implement pixman renderer. So I did :) weston with x11-backend and pixman renderer khr and pq from #wayland were very helpful, and described place of renderer in wayland architecture, here're some points renderer just performs rendering of
Read more

qemu with Z2 support

I spent some days getting qemu to emulate some Z2 hardware, and got some results :) Almost all hw is emulated, it lacks only voltage regulator and WiFi, but it's not easy to implement Marvell's WiFi chip, because there's no datasheet, and anyway it makes no sense. Also screen rotation is not supported (yet). Stock bootloader - blob - (with slight modification) and stock kernel works. Blob puts Z2 into deepsleep on reset, so I hacked it not to do this. How to compile qemu: git clone git://github.com/anarsoul/qemu-z2.git cd qemu-z2 ./configure --audio-drv-list=alsa --target-list=arm-softmmu make -j4 arm-softmmu/qemu-system-arm binary is what you need. So, how to hack blob: put your blob image (first 64kb of NOR) somewhere convert it to hex representation with xxd: xxd mtdblock1.bin >mtdblock1.hex apply patch onto mtdblock1.hex convert hex back to bin: mv mtdblock1.bin mtdblock1.bin.bak; xxd -r mtdblock1.hex >mtdblock1.bin I don't pu
Read more