hello,
as i was digging around for FreeBSD compatibility layer for fdt devices (arm, risc-v) i was not able to find about any clock manager for haiku that controls clocks/resets as most of the fdt devices needs you to toggle clock or or reset bits in soc’s clock control unit and im sure the FreeBSD drivers will try to call something to clock/reset control.
so i was wondering if there is a api or something, as i was not able to find anything while i was searching haiku’s api documentation.
maybe its under different name.
can someone tell me if im missing something or where i might be able to find them.
thanks
Hello,
Indeed it is part of the things we didn’t get to yet. Same thing for automatic IO pins configuration I think.
At the moment our FDT support is quite minimal, and relieso n the bootloader (typically U-Boot) to already have configured the devices as we need them. Since our ARM and RISC-V ports are still somewhat early stages, and we don’t need this many devices (we don’t really do SPI, I2C, …), it has worked well enough for now.
But adding the clock control and IO control modules will certainly be needed at some point. It may be needed as part of this project, or if there is enough work to do otherwise, it may be ignored for now.
In my personal use case, U-Boot will likely also set up the network card during boot with the clock and IO pins already up and running, so at least initially I will be fine without clock configuration support.
2 Likes
hello,
and thanks for clarifying and just some small doubts
-
does haiku currently supports interrupt controllers?
-
do we also need to handle dma memory because its handled differently in arm as farm as i know(im really unsure about this) FDT needs dma ranges property, as arm needs manual cache management( i dont know if this is the exact reason arm is different from x86_64 in memory management)
-does haiku FreeBSD shim handles MAC and PHY well?
im really unsure about lot of things but its all fun to do, better than my college curriculum.
We already handle most parts of PHY that FreeBSD drivers tend to use, at least.
IIRC when I looked into this before, the number of FDT-related API calls from FreeBSD that we likely needed to support were not very high. I think @X512 pointed out a FDT network device that is supported by QEMU, so initial development can probably happen under the RISC-V port on QEMU.
2 Likes
Thanks,
I will keep that in mind
Haiku has support for interrupt ocntrollers (otherwise, not much would work). But it may be too limited to handle all types of hardware.
This patch series is an attempt to clean that up (at least the first four patches at the bottom of the “relation chain” list):
https://review.haiku-os.org/c/haiku/+/5876
The first one was not merged due to some discussion over where the files should be placed, function naming, and the need for documentation explaining the new API (it’s quite hard to review code when it doesn’t come with documentation).
So maybe this would be a good place to start your work? You can take that patch and try to address the review comments and get it into a state where it can be merged.
2 Likes
yes sir, i’m on it.
thanks for the info.
Exact guidance is needed. I do not know what to do with that and what is demanding.
Just ask me, I will answer anything 
But it looks quite obvious anyway.
2 Likes
great i will if i get stuck.
I can only repeat what I already wrote in the comments:
- Files that are shared between some architectures should not be in arch/generic/. The arch/ directory is for files that are specific to each architecture. Solution: move the files outside of arch/ directory. It doesn’t matter if they are used by only some architectures and not all of them yet. The way they are included in the build by jamfiles in each architecture is not a problem, and that can stay as you made it.
- Renaming of _ex functions to remove the _ex, and renaming of the older functions to _legacy suffix when we need to keep them and they share the same name
- One suggestion to change the order of arguments to have the start before the count, as that seems more usual in other APIs in general
- Three cases where two blank lines are needed according to the coding style rules.
Some things may just be my personal opinion and should not block the merge:
- There is one typo in a comment that was just in a renamed file (not actually touched by the change), I’m fine if that’s fixed separately from this patchset.
- The CHECK_RET macro seems not ideal since it hides returning from a caller function inside a macro. Given it’s limited use, it may be removed, and explicit
if (...) return;checks added directly in the code
It looks like Waddlesplash has other ideas about the API design but that part is not very clear to me. Due to the lack of documentation (nothing in the commit message explaining why the changes are needed, no comment on the functions themselves, and also the existing architectures are not migrated so I don’t see what code is removed/replaced), I have to guess what this change is meant to do. I think you have replied to that already in a comment in the review:
Old API also did not supported arbitrary interrupt vector assignment between multiple interrupt controllers and assume one global interrupt controller. RISC-V platform often use multiple nested interrupt controllers, for example PLIC and PCI host MSI interrupt controllers.
You can simply add that comment to the commit message.
Likewise for this comment that explains how the new APIs is used, you could add it to the commit message:
Yes, get_vector translates local interrupt controller interrupt number into kernel global interrupt number.
InterruptSource interface is needed because different interrupt controllers differently handle interrupt enable/disable/assign to CPU etc.. So each interrupt controller install their own interface to kernel global interrupt vector that tells how to manage that interrupt vector.
Waddlesplash seems to think that it is not needed to expose this API publicly, and that all of this could be entirely inside architecture code. But I’m not sure what he refers to, as that seems to already be the case so far. Maybe that part will become clearer if there are some drivers that actually use the new API?
Interrupt controllers are not arch-dependent, but driver-dependent. Interrupt controller driver logic in theory the same for all architectures. Each interrupt controller driver manage its interrupt vectors in its own way.
Stuff very similar to InterruptSource is already used in x86 and arm arch code, but it can be made generic and done that way in my RISC-V work.
See: haiku/src/add-ons/kernel/drivers/interrupt_controllers at device_manager2-r2 · X547/haiku · GitHub.
1 Like
Some explanation about why multiple interrupt controllers and its drivers are needed. For example on RISC-V, CPU itself support only single interrupt pin for external interrupts for each privilege level. So you need separate interrupt controller (PLIC, APLIC) that will provide multiple interrupt pins and dispatch it to single CPU interrupt pin (unlike x86, CPU itself do not know PLIC interrupt number, you need to ask PLIC for that). OS can ask interrupt controller from which pin interrupt have come, so it can dispatch interrupt to proper handler. And on top of it for example PCI host controller may have its own interrupt controller to handle MSI interrupts that is connected to single pin of parent interrupt controller.
So you have following interrupt controller chain:
MSI → PLIC → CPU
Each of them have independent way of how to enable/disable interrupt, query current local pending interrupt number, acknowledge interrupt etc. Also each interrupt controller have its own interrupt numbering that should be mapped to kernel global interrupt vector number.
Things can be even more complicated, for example:
MSI -> PLIC -> CPU
GPIO ->
, where GPIO is yet another interrupt controller connected to single PLIC pin.
1 Like
Or entirely inside the kernel. I am quite happy to do the work to refactor x86 code to help pave the way for support for other architectures, if we can agree on what the new API is or needs to be. I don’t fully understand the constraints involved here, but perhaps if @X512 and I discuss on IRC, I can get a better understanding and help move this refactor along.
Hello everyone,
sorry for being late i was busy with my exams recently that’s why i focused on writing the proposal first. the proposal draft: FDT haiku GSoC proposal - Google Documenten
i will be more than happy for any suggestions. i will now work on the mentioned problem in the thread and also on a proposal prototype
Hello,
I have put some comment in the Google doc.
Mainly, you seem to have studied the FreeBSD side of things, but you did not mention the existing (even if possibly incomplete) support for dtb parsing in Haiku (both in the kernel and bootloader). I put some links to relevant sourcefiles in my comments, but maybe someone else can show an example of a Haiku native driver already attaching itself to the FDT bus?
thanks for pointing this out,
i was focusing too much on freebsd and thought the already writtenn code related to fdt was placeholder code to be worked on later 
as there were too many things to change as i messed up, i made a new proposal ditching most of the old one.