The most critical thing is the architecture of the graphics subsystem,
not any particular framebuffer driver. We should discuss and settle on
a clean, modular architecture before getting ahead of ourselves.
A simple 2D graphics system can be implemented with only a framebuffer
driver and, say, LVGL. If that is all you want to accomplish, then all
that you need is the framebuffer driver.
But a full 3D windowing solution requires more. The NuttX graphics
logic is essentially such a windowing solution. 2D solutions simply
bypass the graphics subsystem.
Drawing capabiliry is limited and LVGL does a better job at that.
Having LVGL drawing into multiple windows would be one good, rather
simple, solution. I ported a drawing package that I named NxWidgets. I
supports drawing into multiple windows but still has issues to be resolved.
On 11/5/25 19:01, Tomek CEDRO wrote:
Lup Yuen LEE ported NuttX to Pine64 Phone and he made the LCD and
framebuffer driver with NuttX console and some touchscreen keyboard! You
may be looking for something like that right? :-)
Lup documents everything very well on his blog :-)
https://lupyuen.org/
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
On Wed, Nov 5, 2025, 22:49 Matteo Golin <[email protected]> wrote:
Hi all,
Despite a relatively small bug with transfer size limits, the RPi4B microSD
card support is basically done. This is largely in part to how simple it is
on NuttX to write a lower-half SDIO implementation and have things just
work, which is incredible :)
I now (ambitiously) want to set my eyes on graphics. It turns out that
rendering with a framebuffer is actually quite easy, but very CPU
intensive. I'm going to need to figure out how to get at the GPU properly.
*My
question is: *is anyone familiar with examples on how to implement the
necessary "lower-half" for the NuttX graphics library? I.e. what
functions/drivers I would need to get written to allow the basic windowing
display manager & LVGL to work on the HDMI outputs of the Pi? I have
briefly read the docs about the window manager and saw that there is a
framebuffer char driver that can be implemented, but I'm not sure how well
that scales to decent graphics. I suppose this is relatively uncharted
territory on an RTOS designed mainly with LCDs in mind as the only graphics
(?). If anyone has implemented graphics support for a device before and can
let me know a few source files to look at, that would be great!
My main goal is essentially to get decently fast graphics going, since once
that's done and some USB HID device support is set up, I can port DOOM to
NuttX :)
Thanks,
Matteo
On Wed, Oct 22, 2025 at 12:32 PM Matteo Golin <[email protected]>
wrote:
Thanks Tomek! That would be a good resource.
On Wed, Oct 22, 2025 at 7:29 AM Tomek CEDRO <[email protected]> wrote:
OpenBSD 7.8 has been just released and it has official support for rPI
5 with all sorts of peripherals.. maybe this is the new source to look
for drivers code? :-)
https://ftp.openbsd.org/pub/OpenBSD/7.8/arm64/INSTALL.arm64
https://cvsweb.openbsd.org/src/
Have a good day :-)
Tomek
On Tue, Sep 16, 2025 at 5:22 PM Matteo Golin <[email protected]>
wrote:
Thanks Alan! Maybe I will reach out to Arasan, could have more luck
than
with Broadcom, but I doubt it.
I'll take a look at these documents!
Thanks again,
Matteo
On Tue, Sep 16, 2025, 11:00 AM Alan C. Assis <[email protected]>
wrote:
Hi Matteo,
Please that a look:
https://www.arasan.com/products/sd-emmc/sdio-3-0-device/
There is an option to Download (request) the Datasheet from that
page, but
you can access it directly here:
https://www.arasan.com/wp-content/uploads/2016/05/3MCR-Total-IP-Solution.pdf
This document is more about the IP core details, but could give you
more
understanding about internal block of the SDIO controller (its FIFO,
initialization diagram, etc)
You can also try to find the original
SD3.0_Host_AHB_eMMC4.4_Usersguide_ver5.9_jan11_10.pdf cited in
Raspberry
documentation.
BR,
Alan
On Tue, Sep 16, 2025 at 11:17 AM Matteo Golin <
[email protected]
wrote:
Hi Alan,
Thank you for the tips! Yes, SDIO looks pretty involved compared
to
SPI
or
I2C. I'll try reading the specification like you suggested.
The BCM2711 datasheet doesn't document it at all, however the EMMC
interface is supposedly the exact same from the BCM2835 and the
registers
there are at least documented. All I know is that it is using an
interface
by Arasan. I'm not as familiar with NuttX, but if this at all
looks
like
something that's already been supported, please let me know. In
the
meantime, I'll look through the SDIO implementations to check:
https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf
(page 65)
Thanks again!
Matteo
On Tue, Sep 16, 2025 at 9:49 AM Alan C. Assis <[email protected]>
wrote:
HI Matteo,
I implemented the SDIO support for LPC43 some years ago and what
helped
me
most was reading the SD/MMC specification, the LPC43 reference
manual
and
enabling the NuttX SD/MMC debug messages.
There are many details to take care of: clock enable for the
controller,
interrupts, pins configuration, etc.
Unfortunately, the BCM2711 doc is not good. You can start
verifying the
registers, maybe it is based on some SD/MMC core IP already
supported
by
NuttX.
BR,
Alan
On Mon, Sep 15, 2025 at 6:34 PM Matteo Golin <
[email protected]>
wrote:
Hi everyone,
Now that I2C has been tackled, I am moving on to SDIO
interfaces so
the
SD
card can be interacted with from NuttX.
The NuttX SDIO documentation is a little bare, and I'm not the
most
familiar with SDIO. Does anyone have any recommendations for
implementations to look at (besides the STM32 one that is
linked in
the
docs), resources to read (any blog posts from when you ported
SDIO)
or
advice in general? It would be much appreciated.
Thank you,
Matteo
On Fri, Sep 5, 2025, 11:15 AM Matteo Golin <
[email protected]>
wrote:
Got another response from my earlier request to Raspberry Pi
through
their
website:
Hi Matteo
Thanks for getting in touch. We don't actually have any
more
documentation that we can release on this. My usual
recommendation
is
for
SW people to take a look at the Linux drivers to get a
closer
understanding
of how the HW works. Not ideal, but the best I can offer.
So I guess everyone is telling us the same thing!
On Mon, Sep 1, 2025 at 3:49 PM Tomek CEDRO <
[email protected]>
wrote:
Sure! Public now :-)
Tomek
On Mon, Sep 1, 2025 at 9:24 PM Matteo Golin <
[email protected]
wrote:
I have populated the RPi 4B project with some starting
issues to
tackle
for
the 4B implementation. I see that the project is marked
as
private;
is
there any way to make it visible to potential
contributors
just
visiting
the GitHub page? I think if they can see a list of issues
in one
place
when
they go to the page it might help.
Thanks,
Matteo
On Mon, Sep 1, 2025 at 3:02 PM Tomek CEDRO <
[email protected]>
wrote:
Thank you Linguini, good luck and have fun! :-)
Tomek
On Mon, Sep 1, 2025 at 8:48 PM Matteo Golin <
[email protected]
wrote:
To update the community, we've been told by Gordon
that the
Pi
Foundation
doesn't have any documentation for the chip beyond
what was
written
in
the
peripheral datasheet. Broadcom themselves has written
the
Linux
drivers
and
Raspberry Pi has only made some slight bug fixes,
etc.
We've
been
suggested
to read the source to discover undocumented
registers/configuration
options.
I plan to still continue with the port until the
feature set
on
NuttX is
equal or greater to what is available on QNX. I at
least
want
to
get
Ethernet and some graphics running after the base
peripheral
set
(I2C,
SPI,
UART) are supported.
Matteo
On Sun, Aug 31, 2025 at 6:10 PM Matteo Golin <
[email protected]>
wrote:
Very interesting Sebastian. I got that impression
from
Broadcom
when I
was
initially trying to port NuttX to the Pi. The
inability to
submit
forms on
their website seems like it might be by design...
I'm hopeful the Raspberry Pi Foundation will have
something
more
for
us to
work with, they seem more positive to FOSS.
Otherwise I
will
still
continue
with reverse engineering until at least the point
where
the
functionality
driver-wise is on par with QNX.
On Sun, Aug 31, 2025, 10:46 AM Tomek CEDRO <
[email protected]>
wrote:
James Dougherty contacted us with Gordon
Hollingworth
from
Raspberry
Pi Foundation recently :-) We are waiting for
response
:-)
I
really
hope we can get some sort of documentation and/or
code
samples
to
write high quality NuttX port for the big
raspberries :-)
Open-Source matters even more in this crazy world.
Thanks
for
interesting article Sebastien! Personally I think
we
should
focus only
on vendors that support Open-Source. What is the
reason
for
bumping
sales for companies that in the end can sue you
for
reversing?
:D
Have a good day folks :-)
Tomek
On Sun, Aug 31, 2025 at 10:15 AM Sebastien
Lorquet <
[email protected]>
wrote:
Hello,
I just found this interesting document:
https://fastcode.io/2025/08/30/the-69-billion-domino-effect-how-vmwares-debt-fueled-acquisition-is-killing-open-source-one-repository-at-a-time/
In a summary, if you expect anything cool from
broadcom:
dont.
go go go reverse engineering!
Sebastien
On 8/29/25 15:37, Tomek CEDRO wrote:
No response from #infra@slack, I just sent
request
to
[email protected] mailing list maybe
someone can
reply
over
there
:-)
https://lists.apache.org/thread/n9y5vrvjm23npwgbr45f7zq5ys5l8dok
We should also know the official stance from
Broadcom
and
RPI
Foundation :-)
Thanks :-)
Tomek
On Thu, Aug 28, 2025 at 9:35 PM Tomek CEDRO <
[email protected]>
wrote:
I just asked question at #asfinfra / slack,
maybe
someone
can
help
there or recommend someone who can, waiting
for
response
:-)
For a good start you can contact Broadcom and
RaspberryPi
Foundation,
introduce yourself as Apache NuttX RTOS
developer
that
want
to
port
NuttX to rPI boards, and just ask if
DataSheets are
available
:-) We
will know then first hand if this is possible
or are
there
any
problems / requirements :-)
You can ask for 4B and probably Zero-2W SoC
documentation
these
seems
most popular nowadays :-)
Thanks :-)
Tomek
On Thu, Aug 28, 2025 at 8:45 PM Matteo Golin
<
[email protected]>
wrote:
Hi Tomek,
Thanks so much! I actually hadn't thought of
that,
maybe
we
could
ask for
help from the foundation. Do you know who's
the
best
point
of
contact for
that?
I know Linux must have received the
datasheets to
make
Raspberry Pi
OS. No
offence to NuttX, but Linux is pretty
popular
in
comparison. If
Broadcom or
Raspberry Pi would release us some
information that
would
be an
immense
help. I suspect there was some kind of deal
with
the
Linux
group
but I have
no idea. I believe even QNX didn't have
access to
the
datasheets
and rather
just reverse engineered the Linux drivers.
Matteo
On Thu, Aug 28, 2025, 12:42 PM Tomek CEDRO <
[email protected]>
wrote:
On Tue, Aug 26, 2025 at 10:05 PM Matteo
Golin <
[email protected]>
wrote:
I2C still needs some work unfortunately.
However, I
agree
with you
generally. Personally, I think HDMI,
networking
(including
WiFi
and BLE)
and some kind of interaction with storage
(eMMC
or
SD
card)
are
the most
important. Unfortunately, those are likely
going
to
be
the
most
difficult
because of the lack of documentation on
the
peripherals.
It is
definitely
not an impossible task, but it will be
challenging.
Hence my
request for
creating the new project roadmap, so maybe
some
discoveries
can be
documented there and more eyes can get on
the RPi
implementation.
The lack of documentation is a real pain,
and
known
issue
for
years in
many areas, but some vendors are especially
famous
for
that.
Considering someone wants to create
Open-Source
drivers
for
free
and
bring customers to the vendor.
Maybe we could ask Apache Foundation for
help in
obtaining
required
datasheets? :-)
--
CeDeROM, SQ7MHZ,
http://www.tomek.cedro.info
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
