[Hackrf-dev] SPIFI Boot success with JellyBean

[Michael Ossmann]

On Mon, May 28, 2012 at 01:02:05PM +0200, Ben wrote:

>

> I have tested my JellyBean board and it work fine (2.7V OK with LED

> ON) and also tested to enable Analog 1V8 which work fine (1V8LED is ON

> and Analog Power is 1V8).


Excellent work!  I may have forgotten to tell you that the rest of us
are mostly running VCC at 3.3 V.  Jared noticed that the USB peripheral
requires at least 3.0 V, so my originally intended 2.7 isn't enough.  If
you have an extra 560k resistor (R38), you can simply solder one on top
of the existing R36 resistor to bring it up to 3.3 V.


> I also fixed the LED1/2&3 blink problem (was not blinking because of

> GCC optimization which remove the loop).


Nice.  For the record, I had an additional problem that prevented
execution.  The LPC43xx bootloader requires a checksum in the vector
table.  I was installing code directly to SPIFI without a checksum, so
it wouldn't boot.  You probably didn't have that problem because you
used the LPCXpresso tools to load the code (I used a GoodFET), and one
of those tools probably inserts the checksum automatically.

I wrote a little tool that inserts a checksum into a .bin file:

https://github.com/mossmann/libopencm3/blob/master/scripts/lpcvtcksum

Since fixing that problem, I also have had blinky success with the code
in my libopencm3 fork.

It is debatable where this checksum code should live.  It could be in
libopencm3, hackrf, goodfet, or elsewhere.  In the case of other LPCxxxx
tools, I think the function is usually built into the flash programming
utility.  I'm leaning toward leaving it in libopencm3 because it is
something that needs to be in any code that is linked to run from a
bootable address regardless of the flash tool used, and there is no harm
in having the checksum installed at compile time and then replaced by a
flash utility.  If we do leave it there, it would be nice to modify the
tool to operate on .elf files and call it from the makefile before the
.bin and .hex files are derived from the .elf.


> I will create an alternative startup script in order to copy SPIFI

> Code to Internal RAM and execute it in internal RAM to speed up the

> stuff else it's limited by SPIFI bandwidth (40MB/s IRC).


That would be great!  I suggest doing this (and any development that is
useful for general LPC43xx work, not just for HackRF) as an addition to
libopencm3.  I expect to throw out the existing hackrf/firmware
directory and replace it with HackRF specific stuff that is built on
libopencm3.  This week I'll probably be mostly working on building up
libopencm3 to support various peripherals.


> See my GitHub update: https://TitanMKD@github.com/TitanMKD/hackrf.git


pushed to mossmann/hackrf


> 1) Add SCU PinMux macro or function to configure all Pins at startup

> specific for JellyBean (to be based on my "LPC43xx PinMux ver1

> 2012/01/31" configuration file specific to JellyBean see in

> attachement JellyBean_PinMux.pmx).


Could you also work on a generic SCU implementation for libopencm3?


> 2) To start experimenting with SGPIO.


I'm starting on some basic SGPIO support in libopencm3 today.


> 3) To write some GPL driver with or without DMA like: USART, I2C, SPI,

> specialized SGPIO driver for Logic Analyzer stuff ...

> All those drivers are planned to be included in opencm3 branch in

> https://github.com/TitanMKD/libopencm3 (forked from mossman/libopencm3).


Great!  We will certainly need SPI and I2C for HackRF.  It would
probably be better to work on support for the SSP peripheral than the
SPI peripheral.  If you work on that stuff, I will start on:

SGPIO
CREG
CGU
CCU
RGU

Before long we'll have to tackle USB.  I'd like to have Jared's help
with that before getting in too deep as he has explored the peripheral
quite a bit, but I may get started on a basic header file.

And, for future reference, we'll probably eventually want support for:

GPDMA
ADC0/1
I2S
SDIO
SCT
GIMA
Cortex-M0 coprocessor
TIMER0/1/2/3


> 4) To create a specific startup code which will copy Code from SPIFI

> (0x80000000) to Internal RAM (0x10000000) will be limited by internal

> RAM, anyway we have 264KB of SRAM => Tell me if you have idea about

> this code to maybe only copy critical code part with specific section

> name to be defined or all *.text ?


For now I'd say we should copy all of .text, but we may want to consider
other options in the future.

Thanks so much for your help!