Hello everyone, Thank you for the responses of support! I will try to address them one-by-one.
1) I am actually familiar with the rpi4-osdev project. In part 5, the author uses the framebuffer approach for graphics: https://github.com/babbleberry/rpi4-osdev/tree/master/part5-framebuffer. This is actually a really simple approach to implement, which is why I imagine it wouldn't be difficult to integrate with NuttX's frame buffer method of graphics. The main problem for me is that it's very slow. I want to figure out how to leverage the actual GPU so that graphics can be faster and more complex. I have not started looking extensively into that yet, but was mainly wondering how that approach fits into NuttX's graphics system. 2) I will look through Lup's blog! I'd imagine the Pinephone has one of the more complex graphics outputs of what's on NuttX. Thanks for the tip! 3) I was kind of afraid that the existing NuttX support is limited to framebuffers/low complexity graphics in its current state. It is an RTOS after all, and runs mainly on low-resource systems. It seems that is the case from some of the responses here. I may spend some time reading Lup's blog and the framebuffer documentation for NuttX. I'm starting to think that a simple framebuffer driver would be a good initial approach to this as a proof-of-concept. Thanks again everyone, Matteo On Thu, Nov 6, 2025 at 6:15 AM Tim Hardisty <[email protected]> wrote: > Just some semi-random thoughts to throw in here. > > I use a SAMA5D27 with a 164MHz main clock and with an 800x480 lcd using > ARGB8888 with lvgl via NuttX framebuffer and complex gauge graphics I get > <10 bps. > > Only just started my investigation into this but I think the NuttX + lvgl > FB approach is flawed as it uses 2 full frame render buffers and then > copies one to the framebuffer when ready. Only takes 3 ms but it is > inefficient and would be better done by the NuttX/arch driver flipping DMA > buffers. > > Might be other things at play but I’m not yet sure if the FB will handle > advanced lvgl graphics as it is at the moment. > > Regards, > > Tim. > > > On 5 Nov 2025, at 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 > >>> > >> >
