explore has quit [Quit: Connection closed for inactivity]
aspe has joined #rust-embedded
Amadiro_ has joined #rust-embedded
Amadiro__ has quit [Ping timeout: 240 seconds]
<re_irc>
<James Munns> I'm gunna move Mnemos over to the Allwinner D1 after I get the current rework done
<re_irc>
<James Munns> I don't even know what I'm going to do with 512MiB of DDR3.
<re_irc>
<James Munns> (haha jk, probably spend a month building drivers for things)
<re_irc>
<James Munns> but hey, the whole OS probably fits in L1 cache (32KiB data/32KiB code)
<re_irc>
<James Munns> so it's gotta go brrrr, right?
<re_irc>
<James Munns> plus it's 1ghz! I can make a lot of dumb code run really fast at 1ghz.
<re_irc>
<James Munns> Hopefully the main OS will still run on a 32-bit Cortex-M tho
<re_irc>
<James Munns> but maybe with some limitations, like a single app/thread at a time or something
<re_irc>
<James Munns> The fact that it has a dedicated "smartled" peripheral definitely calls out to me though.
diagprov has quit [Ping timeout: 240 seconds]
<re_irc>
<mabez> James Munns: interesting! How are you planning on making the kernel hardware agnostic (Seems quite tied to the nrf hal atm)? Over the weekend I was inspired to hack on my university project, mainly to try and make the kernel work on other hardware (https://github.com/MWatch/kernel/pull/69). Most of it is easy with traits and such, but the cursed part in my implementation is passing context to user space
<re_irc>
<mabez> At the moment I'm casting everything to "* mut ()" and then casting back to the concrete type in C FFI calls - super cursed and I'm not sure it's even going to work yet :D
<re_irc>
<mabez> James Munns: interesting! How are you planning on making the kernel hardware agnostic (Seems quite tied to the nrf hal atm)? Over the weekend I was inspired to hack on my old university project, mainly to try and make the kernel work on other hardware (https://github.com/MWatch/kernel/pull/69). Most of it is easy with traits and such, but the cursed part in my implementation is passing context to user space
<re_irc>
<James Munns> @mabez - So, there's a couple levels of separation:
<re_irc>
Apps are portable, as they use a serialized syscall process. Basically everything is a "postcard-rpc" call.
<re_irc>
Basically every hardware specific driver is abstracted through a "dyn Trait". The idea is to eventually solidify that into _most_ of the business logic of the kernel held in that Machine structure, and the "hardware specific" binary is mostly just setting things up.
<re_irc>
I'm definitely going to be working on the HAL aspect of it, because for now I'm actually working on a desktop simulator, before I port it back to the nrf52/allwinner D1
<re_irc>
<James Munns> Currently (in 0.1) syscalls are blocking, so the userspace immediately halts and calls the kernel.
<re_irc>
In 0.2, syscalls will be batched, with async on both sides, so it'll be more of a ping/pong between the two, handling strides of tasks/events to avoid context switching overhead.
<re_irc>
<James Munns> The plan is to basically make a pass through the kernel executor "on the way back" from any interrupt, or when the userspace isn't able to make progress.
<re_irc>
<mabez> Ah thats cool! I like the rally RPC approach. One thing that stopped me implementing something similar in my initial implementation was the fact that I needed to write pixels to a display (relatively quickly too). Would the syscall RPC process be appropriate for something like writing to a display? Or would you expose the frame buffer to user space some how? Going through the C FFI albeit cursed is pretty low overhead.
<re_irc>
<mabez> * really
<re_irc>
<James Munns> So, the kernel understands "boxes" basically
<re_irc>
<James Munns> you RPC the ptr + len of a "Box<[u8]>", and "give ownership" of the buffer to the kernel, until it gives it back
<re_irc>
<James Munns> (in 0.1 the allocator lived in the kernel, in 0.2 it lives in userspace, but same deal, you "hand over" the buffer and forget about it, and the other one "hands it back" to be dropped)
<re_irc>
<James Munns> essentially (in 0.2) all comms happen as a future, where you send a message, and await a response.
<re_irc>
<James Munns> this is all vaguely io_uring inspired, though a little more flexible, because it's not using existing syscall APIs (like linux does)
<re_irc>
<James Munns> The kernel might also get an allocator at some point, but for now I'm mostly planning on just using a bump allocator, so I can box+leak all the drivers at startup
<re_irc>
<James Munns> the "working buffers", like what you'd receive serial data into, or send out for display stuff, all come from userspace
<re_irc>
<James Munns> (gotta run for a bit, happy to chat later, or drop by #anachro:matrix.org (https://matrix.to/#/#anachro:matrix.org) to chat :D)
<re_irc>
<mabez> Thanks! That's definitely a better approach, I'll see if I can implement something similar for my project! I think initially I wanted to support displays without a frame buffer, but in reality I used a frame buffer anyways, so I should just expose it.
causal has quit [Quit: WeeChat 3.5]
aspe has quit [Quit: aspe]
<re_irc>
<Imran K> I'm writing flash driver for the "stm32h723zg" board, I can write "256bit" data and "8bit". The problem arises when I try to write data at the same address where I have already written some data, so flash write does not work to rewrite the same address. Is there any way to write data multiple times in the same address. Below is my code snippet.
<re_irc>
<Imran K> I'm writing flash driver for the "stm32h723zg" board, I can write "256bit" data and "8bit". The problem arises when I try to write data at the same address where I have already written some data, so flash write does not work to rewrite the same address. Is there any way to write data multiple times in the same address. Below is my code snippet.
<re_irc>
<Imran K> I'm writing flash for the "stm32h723zg" board, I can write "256bit" data and "8bit". The problem arises when I try to write data at the same address where I have already written some data, so FlashWrite does not work to rewrite the same address. Is there any way to write data multiple times in the same address.