3 ms·

To elaborate, I made this to develop an open source VPU side bootloader for Raspberry Pi because I was unhappy with the state of other C compilers targeting VC4

To elaborate, I made this to develop an open source VPU side bootloader for Raspberry Pi because I was unhappy with the state of other C compilers targeting VC4 (I explained why in my blog). I haven't had the time to work on my firmware recently due to IRL events so I decided to publish the compiler. Not publishing any of the firmware work yet since it can't boot ARM yet (but SDRAM init reliably works across all boards). Once I get ARM working to some extent, I'll probably clean the code up and publish it too.

khedoros 10y ago
This is awesome! It seems like an important series of steps towards having a legitimately-open educational platform, rather than the somewhat asterisk-laden one that the Pi currently represents.
david-given 10y ago
Thanks for making this work! I'd given up on the LLVM backend completely due to showstopping issues I couldn't resolve, and had assumed it had vanished into the aether. Glad to know you found it useful! Regarding the boot loader, have you seen my piface boot loader? http://cowlark.com/piface/ http://cowlark.com/piface/ It sounds like what you have is way more sophisticated, as I never got SDRAM init working properly, but you never know --- there might be something useful there. I was actually considering having another go at a VC4 compiler, this time with pcc; there's an OS I want to port. I'm really happy to know that I no longer have to!
- david-given 10y ago
  ...hilariously, I've just checked my email, and I see a two-day old message from someone who's just got my previous attempt at a VC4 compiler working. This one was with gcc: https://github.com/puppeh/vc4-toolchain https://github.com/puppeh/vc4-toolchain
- christina_b 10y ago
  Yeah I looked at it, my firmware mostly just aims at bringing up enough stuff to be able to boot ARM, which is essentially just: - Setting up exception vectors and enabling exceptions - Reclocking VPU from PLLC - UART initialization - SDRAM initialization - Copying an ARM blinker stub to 0x0 - ARM power domain initialization - PLLB initialization - Enabling passthrough mapping for ARM - ARM AXI interface initilaization I'm still trying to figure out what I'm missing in order to get it to work but I suspect it's related to not properly setting up the ARM PLL. I was going to port the RPi clock management driver from Linux but I don't have the time at the moment. As far as the compiler goes, I think it works reasonably well, though I only tested it by compiling my own code with it, there may be things that cause it to error out (anything that involves the frame pointer like VLAs/some C++ features). Also code quality is not ideal since it still doesn't make use of conditional instructions (aside from conditional branches) and doesn't implement AnalyzeBranch to eliminate redundant branches. I started cleaning up TableGen to turn multi-instruction asm prints into glue DAG in SelDAGtoDAG but I still have to do it for like 4 instructions, which is pretty much a requirement to have MC code emission.
  - david-given 10y ago
    It's been too long and I've forgotten too much about how LLVM works. The gcc port I linked to, BTW, claims to have VC4 binutils. Random question: how did you do 64 bit arithmetic? I couldn't find any kind of add-with-carry or subtract-with-carry instruction. I was semi-resigning myself to have to do a compare-and-test as well as the add, which would have more than doubled the amount of work. Also, nice work reverse engineering the ARM controller --- how did you get the info?
hermanhermitage 10y ago
Great work. Very interested to see what you have going on the firmware side.
- christina_b 10y ago
  I outlined what I did in another comment, here's a log from my current firmware: http://crna.cc/vpu_bootlog.txt http://crna.cc/vpu_bootlog.txt I think I'm on the right track but I don't have ARM working yet, most likely due to clock misconfiguration. Can probably fix it when I have more time. Sidenote, I wish #raspberrypi-internals was more active :(
ashitlerferad 10y ago
Will you be getting this merged into LLVM upstream?
- christina_b 10y ago
  Don't think I can without first implementing MC emission and running LLVM unit tests on it.

khedoros 10y ago

This is awesome! It seems like an important series of steps towards having a legitimately-open educational platform, rather than the somewhat asterisk-laden one that the Pi currently represents.

david-given 10y ago

Thanks for making this work! I'd given up on the LLVM backend completely due to showstopping issues I couldn't resolve, and had assumed it had vanished into the aether. Glad to know you found it useful! Regarding the boot loader, have you seen my piface boot loader? http://cowlark.com/piface/ http://cowlark.com/piface/ It sounds like what you have is way more sophisticated, as I never got SDRAM init working properly, but you never know --- there might be something useful there. I was actually considering having another go at a VC4 compiler, this time with pcc; there's an OS I want to port. I'm really happy to know that I no longer have to!

david-given 10y ago
...hilariously, I've just checked my email, and I see a two-day old message from someone who's just got my previous attempt at a VC4 compiler working. This one was with gcc: https://github.com/puppeh/vc4-toolchain https://github.com/puppeh/vc4-toolchain
christina_b 10y ago
Yeah I looked at it, my firmware mostly just aims at bringing up enough stuff to be able to boot ARM, which is essentially just: - Setting up exception vectors and enabling exceptions - Reclocking VPU from PLLC - UART initialization - SDRAM initialization - Copying an ARM blinker stub to 0x0 - ARM power domain initialization - PLLB initialization - Enabling passthrough mapping for ARM - ARM AXI interface initilaization I'm still trying to figure out what I'm missing in order to get it to work but I suspect it's related to not properly setting up the ARM PLL. I was going to port the RPi clock management driver from Linux but I don't have the time at the moment. As far as the compiler goes, I think it works reasonably well, though I only tested it by compiling my own code with it, there may be things that cause it to error out (anything that involves the frame pointer like VLAs/some C++ features). Also code quality is not ideal since it still doesn't make use of conditional instructions (aside from conditional branches) and doesn't implement AnalyzeBranch to eliminate redundant branches. I started cleaning up TableGen to turn multi-instruction asm prints into glue DAG in SelDAGtoDAG but I still have to do it for like 4 instructions, which is pretty much a requirement to have MC code emission.
- david-given 10y ago
  It's been too long and I've forgotten too much about how LLVM works. The gcc port I linked to, BTW, claims to have VC4 binutils. Random question: how did you do 64 bit arithmetic? I couldn't find any kind of add-with-carry or subtract-with-carry instruction. I was semi-resigning myself to have to do a compare-and-test as well as the add, which would have more than doubled the amount of work. Also, nice work reverse engineering the ARM controller --- how did you get the info?

hermanhermitage 10y ago

Great work. Very interested to see what you have going on the firmware side.

christina_b 10y ago
I outlined what I did in another comment, here's a log from my current firmware: http://crna.cc/vpu_bootlog.txt http://crna.cc/vpu_bootlog.txt I think I'm on the right track but I don't have ARM working yet, most likely due to clock misconfiguration. Can probably fix it when I have more time. Sidenote, I wish #raspberrypi-internals was more active :(

ashitlerferad 10y ago

Will you be getting this merged into LLVM upstream?

christina_b 10y ago
Don't think I can without first implementing MC emission and running LLVM unit tests on it.