Subscribe Re: Embox RTOS on Raspberry Pi

[Kevin Peck]

Alex et. al. :


I'm also surprised to see little support for Pi Zero and RTOS.


You're looking for bare-metal boot methods, I've managed to figure that
out and have a base project here :


https://github.com/kpishere/PiZeroRTOS


k.

[Anton Bondarev]

Hi,

Thank you very much for the information. Your project looks interesting.

Could you also add your developments into Embox?

Regards, Anton

сб, 5 июн. 2021 г. в 09:46, Kevin Peck <kevin...@gmail.com>:

--
You received this message because you are subscribed to the Google Groups "embox-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to embox-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/embox-devel/23471e1e-8620-2634-b385-2f08917df387%40gmail.com.

[Kevin Peck]

Anton : 

I'm just getting acquainted with Embox now.  What I'm seeing, I think, is that the whole thing, for Raspberry Pi ARM anyway, is running at the same boot exception level.

Honestly, I'm just getting up to speed with that kind of thing but what it looks like, is that with using different exception levels, you can have different vector tables for each exception level.  This would be nice to make kernel more robust and guarded against other code running at a lower exception level.  I'm expecting that would be an invasive change for the HAL of ARM.  I'll likely have to keep that parked for a while until I experiment more with it.

The other thing I'm looking at, you may see in my repos a fork of fbcp-ili9341 (https://github.com/kpishere/fbcp-ili9341).  I know this driver quite well, it is very independent of linux OS and any other drivers.  I'd managed to make it work with touch screen ability, more as a kludge really, in Linux kernel -- it was quite awkwardly done.  I think it would work very nicely in Embox!

Only, I'm not seeing a like component right now to this.  Basically, this bit of code would be copying frame buffer changes to an SPI device and would also be reading back touch events from same pipeline.  Note that the touch events can only be read when the screen is being updated!  So, in linux, I'd gotten around that by always drawing a cursor or touch point on the screen.

If you had any pointers on where you'd like to see this go or which driver would be best to model after, I'm all ears.  Regardless, I go through your documentation and see what I can do.

Like, where would this driver show up under your devices?

.\driver\lcd\ili9341

.\driver\spi_lcd

.\driver\lcd_spi

.\driver\input\touchscreen\ili9341

I think I'm partial to the last path here as the framebuffer copying, besides taking over the SPI bus fully, is quite transparent to other tasks, the only interface point to other tasks is the touchscreen.

k.

[Anton Bondarev]

Hi Kevin,

I'm just getting acquainted with Embox now.  What I'm seeing, I think, is that the whole thing, for Raspberry Pi ARM anyway, is running at the same boot exception level.

 

Honestly, I'm just getting up to speed with that kind of thing but what it looks like, is that with using different exception levels, you can have different vector tables for each exception level.  This would be nice to make kernel more robust and guarded against other code running at a lower exception level.  I'm expecting that would be an invasive change for the HAL of ARM.  I'll likely have to keep that parked for a while until I experiment more with it.

Yes, you are right. There is a way to use different exception vectors but today it isn't used in Embox. As I remember we started research in this direction (look at 'src/arch/arm/armlib/monitor_exception_table.S', but we paused it. I agree it is useful, but it takes some time. On the other hand, there is the opportunity to add different ways to handle exceptions. You can add a new module (with a new exception table) and select in mods.conf, so the module can be developed independently.

The other thing I'm looking at, you may see in my repos a fork of fbcp-ili9341 (https://github.com/kpishere/fbcp-ili9341).  I know this driver quite well, it is very independent of linux OS and any other drivers.  I'd managed to make it work with touch screen ability, more as a kludge really, in Linux kernel -- it was quite awkwardly done.  I think it would work very nicely in Embox!

It is great if this driver would be added to Embox

Only, I'm not seeing a like component right now to this.  Basically, this bit of code would be copying frame buffer changes to an SPI device and would also be reading back touch events from same pipeline.  Note that the touch events can only be read when the screen is being updated!  So, in linux, I'd gotten around that by always drawing a cursor or touch point on the screen.

I think you should do the same as in Linux, Embox framebuffer and input devices structure look like Linux. Another way as I think is to use framebuffer and input dev with usual features however add upon these light graphical framework. I like LVGL (https://youtu.be/BrR9AWcMBfE)

In any case, I think you should start with SPI and base framebuffer functionality.

Like, where would this driver show up under your devices?

driver/lcd/ili9341 + driver/input/touchscreen/ili9341 - seems good. But If you will decide to use direct redrawing from the driver the last is better

Regards, Anton

сб, 5 июн. 2021 г. в 23:00, Kevin Peck <kevin...@gmail.com>: