This function is a wrapper around simple_strtoul, and allows us to expose
it, replacing the one in bionic.c.
Signed-off-by: Sean Cross <xobs@kosagi.com>
Rather than completely rewriting everything on each runthrough, we
now only refill the command buffer before toggling the RUN bit.
This will improve performance by eliminating excessive register writes.
Signed-off-by: Sean Cross <xobs@kosagi.com>
This major refactor of the "lcd" command gets two different PIO test
commands working (tpp1 and tpp2), along with a test command for dma
(tpd) that, when called multiple times, will step through a framebuffer
pattern and blast it out to the screen.
Signed-off-by: Sean Cross <xobs@kosagi.com>
This supports setting up the LCD, and then starting a transfer.
Interrupts are required to have self-refresh working.
Signed-off-by: Sean Cross <xobs@kosagi.com>
We used to while(1) wait for EMI to calibrate, but sometimes EMI never
returns from calibration. Break if it hasn't finished after 256 tries.
Signed-off-by: Sean Cross <xobs@kosagi.com>
Before we work on trying to get the LCD to be self-refreshing, reformat
the code to use our macros and indentation style.
Signed-off-by: Sean Cross <xobs@kosagi.com>
Some basic progress on the LCD, such that the interface can
turn-on and draw.
The implementation uses a slow sequential-write method to update
the display; the vestiges of an auto-copy system are also in
place but not yet debugged.
The system seems to support two methods for issuing commands and
data to the LCD. One is a simple write-to-commit method. The
other is a more sophisticated command list that's set up, and
then dispatched. The write-to-commit kind of works now, although
it's left to be seen if we aren't running too far ahead of
commands or missing some wait states.
To get the demo to work, run the following commands in fernly:
bl 5 (turns on backlight)
lcd su (sets up GPIOs and timing)
lcd init (initializes the LCD-side controller)
lcd tp1 (blasts a small test pattern to the top of display)
You'll note that the VCOM setting looks to be off (alternate
light/dark lines).
Next steps include:
1) verify that commands are being issued correctly to the LCD
(no missing commands due to writes happening faster than
the interface can keep up)
2) cross-check with LCD datasheet for the initialization
of the controller -- there are some undocumented commands
I left out in this implementation, maybe they need to go in
there; I also left out the gamma table.
3) get the autocopy method to work. I think, from what I can
tell, the autocopy will take a region of interest from memory,
composite it with up to four other regions with alpha blending,
and then auto-copy this to the LCD. You can insert commands
into the auto-copy stream as necessary, but I believe this,
combined with the TE (tearing effect) sync bit, will allow
you to just write to a region of memory as a frame buffer
and have it show up on the display without any CPU intervention.
Could be wrong tho....
Nothing is correct at the moment, but basic commands are integrated
into the shell, which will simplifying merging later on for files
that are shared-edit.
THe Fernly loader consists of a binary run on the target, to load
data into RAM, and on the host, to feed data to the target. This
gets the build system to compile both halves.
When Novena first boots, its serial port is running at an unknown
speed. Fernvale runs at 115200. Set the serial port speed once
the serial port is opened.
Signed-off-by: Sean Cross <xobs@kosagi.com>
The romulator only emulates 64k of SPI ROM. That's not enough for anything
interesting.
Add a second-stage bootloader to send data to Fernvale over serial. This
will allow us to work around needing code relocations, and allow for much
larger binaries.
