[HN Gopher] NuttX RTOS for PinePhone: Framebuffer
___________________________________________________________________
NuttX RTOS for PinePhone: Framebuffer
Author : picture
Score : 57 points
Date : 2022-12-30 16:50 UTC (6 hours ago)
(HTM) web link (lupyuen.github.io)
(TXT) w3m dump (lupyuen.github.io)
| m463 wrote:
| I haven't heard of NuttX before.
|
| How did it come about? Was it developed from scratch or released
| from an existing project?
| snvzz wrote:
| As cool as this is, Genode is much farther ahead[0] and has a
| much stronger security model (microkernel multiserver with
| capabilities).
|
| AIUI they're planning to provide user-installable images by next
| release (2023-02).
|
| It was gonna be 2022-11, but they chose to delay so that end
| users only see it polished. It is possible to try it by building
| it yourself, and it's pretty cool.
|
| 0. (grep for Pine) https://genodians.org/
| nanch wrote:
| Lup has such detailed and well-thought-out posts.
|
| I used his guides when developing for the PineTime and everything
| worked perfectly. I would have been completely lost without his
| information.
|
| Thank you Lup!
| monocasa wrote:
| // Copy the Entire Framebuffer to itself, // to fix the
| missing pixels. // Not sure why this works.
|
| That has big lack of proper cache flushing energy. ARM-A device
| support tends to be where you need to get really intentional
| about managing your memory hierarchy. Smaller cores tend to have
| simple enough (or no) caches that they don't tend to get in your
| way much except for knife edge bugs. Bigger systems like x86 just
| tend to push the cache coherency out even to IO devices. ARM-A
| class SoCs are that sweet spot of a ton of caches between the CPU
| and main memory, but simple enough peripherals and fabric that
| only the CPU cores are coherent.
| jbirer wrote:
| Yep, and I am not comfortable using software developed by
| people who don't know about this. Almost the entire ARMv8 TRM
| constantly mentions cache considerations.
| jancsika wrote:
| So is copying the thing to itself the only solution in the
| interim in order to force the thing to copy itself correctly
| into the thing?
| Veserv wrote:
| You manually flush the addresses of the framebuffer via a
| cache maintenance instruction.
|
| The internet tells me the phone has a A53 which should be
| ARMv8, so probably a loop of DC CIVAC (Data Cache Clean and
| Invalidate by Virtual Address to Coherency) instructions over
| the framebuffer. Though the buffer might be large enough to
| not even fit in the cache, so it might be more efficient to
| just flush the entire cache.
| ajross wrote:
| No, ARM has cache management hardware (and a memory ordering
| model which you need to understand on the OOO cores). You
| just have to use it.
| monocasa wrote:
| Not only is copying it over itself not the only solution (all
| you need to do is issue the right sequence of cache flushes
| over the affected area, so first CPU cache flush
| instructions, and then maybe an additional set of MMIO based
| cache flushes depending on how your L2 and/or L3 work), but
| copying over itself isn't even enough to be correct. They
| lucked out that it seems to work, but it's kind of by chance.
| That cache is more than in the right to still not flush some
| lines even with this big copy.
| pixelfarmer wrote:
| Exactly. The artifacts shown are stereotypical caching issues:
| Always same length (cache line size) and earlier written
| entries are more likely to be fully committed than later
| written ones but it is (seemingly) random in overall.
| als0 wrote:
| What is the NuttX community like compared to Zephyr? Seems like
| they have similar goals and I noticed that the latter has ten
| times the number of open pull requests.
| snovv_crash wrote:
| NuttX was the project of a single guy, over 20 years, which
| only recently got picked up by bigger players (eg. Xiaomi) when
| the project was moved to Apache Foundation governance. Before
| that it was very, very quirky, and while it was possible to do
| a lot, it was also very effort intensive. I would choose Zephyr
| just because it has less technical debt.
___________________________________________________________________
(page generated 2022-12-30 23:00 UTC)