Did you follow the instructions at Pre-requisite Software | Haiku Project to install the required dependencies?
1 Like
Not much progress to report.
Iāve started reading about ARM mmu setup, but there is a lot to learn about the processor. Someone that already has knowledge of the CPU and its modes would probably make faster progress. So help wanted!
10 Likes
Native build should be made functional first, so bootstrap packages should be uploaded (even if broken). I donāt want to bother with Linux.
6 Likes
Itās a work in progress, I was waiting for buildtools PR for gcc, which is merged now, and some other minor things. Problem is my tree is so outdated so I have yet to find enough time to work to update and test the gcc package.
4 Likes
If the code does not work, the bootstrup will not be included, please donāt be surprised that nobody wants to help port Haiku on ARM, please fill in the haiku code to be able to compile the image. Second, what processor do you want to port A72, A73?
My target is RPi4 for now. It has UEFI and ACPI device tree as far as I can tell. This is also why am Iām holding of on adding FDT for now, as it just adds an additional unknown. Solving one problem at a time I think is the best approach, and right now that is MMU-handling.
Once we are further along in the boot process, we can pick and add tech for iterating over hw.
9 Likes
This is a difficult task, especially at this stage. Iād help if I knew how to do such low-level development. Donāt be discouraged @tqh! I check back often to see how the hardware ports progress, and Iām sure others do too.
Iām taking some time off work for (at least) part of the coding sprint, Iāll compile and see what I can figure out for ARM. Iāll commit to helping some of the apps in haikuports to compile for ARM as well, when the time comes.
8 Likes
it is certain the development of the initial phases are slow and the most cumbersome and probably only a few have such ability to develop at such low levels, but as the steps are taken the development will become exponential because other developers will surely arrive. RPI 4 are very very popular, especially among those who are more geeks.
4 Likes
Uploading built bootstrap packages should be easy if you have enough access permissions. It is fine that some of packages will be broken, most of them are used only when enter user mode.
2 Likes
I am not discouraged at all. So no problems there. I just havnāt written mmu code for an architecture and I have zero prior knowledge of ARM64, so just a bit of advertising for someone that may already have that skillset (and maybe more free time) 
2 Likes
If several people want to do the job, someone has to break the job lest they do the same.
My time has just ended, from tomorrow I am a student of computer science for the second time. My skills are still weak, especially with C ++, I didnāt do any commercialization, I just practiced privately. And now I am studying at university. peace
Just out of curiosity. how are you going to implement the VM? is it going to be the whole 4-level translation? for both regions. giving thus whopping 512TB of VM (256TB on each side - TTBR0 and TTBR1). or, you want to cut off the top level, which is possible by limiting the virtual address space, say from the maximum 48 bits to 39 (a possible configuration for 4KB pages). careful reader might notice the VAS capacity difference between x64 with the same 48 bits of the VAS length. thatās right - x64 sets ācanonicalā address by propagating the value of the highest implemented bit to the higher unimiplemented, whereas ARM does this by the value of the lowest unimplemented bit (bits 47 and 48 resp). thatās why the difference.
What page size? 4KB, 16KB or 64KB? are there plans to use blocking - say at level 2, a table entry instead of pointing to the page table, maps one big region of memory (2MB in this case, 4KB pages). using this feature would decrease TLB pressure and definitely is possible for big nonpageable kernel regions (with the same attributes) like nonpaged pool or PFN database - these are Windows entities, but probably, there is something similar in Haiku.
Interesting to note also, that most probably, the FW is running in EL2 (Hypervisor), so the trampoline code should take care of proper jumping into EL1, before passing to the kernel. in this relation, what are your plans about that āstage 2ā translation - that is, the additional address space translation (yeah), from what your kernel, running in EL1 thinks are physical (system addresses) and what in fact are āvirtualizedā physical addresses, so called IPA (Intermediate Physical Addresses) to finally ārealā physical addresses (which on RPI are not such still, 
because there is another space translation from what ARM cores see to what VC does - the latter being a real system address space). that stage 2 translation happens (and is controlled) only at EL2 and could be turned off there. what probably speeds things up but cuts off the Hypervisor assistence in virtualization, if there is need in it, of course. I am interested in knowing this, because I still havenāt figured out it on my own - is it possible to retain Hyp mode capabilities for possible use, yet turn off stage 2 translation for the host OS - our OS, that is. so far, it looks like itās not possible: itās a global thing, if you turn stage 2 translation off, it is turned off for every virtual machine; or putting it another way - if you want to be able to run several VMs, then your host OS would be running on just one of those VMs and so the needless overhead with the additional address translation, interrupt routing etc follows. plus - additional mess in the code, because that hypervisor must become a part of your code.
Honestly, ARM VMSA (Virtual Memory System Architecture) is hell. it got better for ARM64, but still is pretty clumsy and overdesigned.
6 Likes
Sounds like you might be able to code an important part for ARM 
9 Likes
Some one is going to implement/review graphical system in Raspbey Pi 3 & 4?
1 Like
Personally I expect: yes. Itās way too interesting to -not- have at least setmode capability 
3 Likes
Sorry for the late reply. I donāt have many answers. We use 4KB paging on other platforms so to avoid problems I think it is good to aim for that. It will start with the simplest config to get it working as well. UEFI has some info on what to do for different platforms, so will also try to follow that.
I think we are already in EL1 when we leave UEFI, and we need to setup exception handling and mmu. You can set a memory map through UEFI, but I want to work on native one as we need it in the kernel anyway. First step I want to do is to just list the memory map to make sure structs are done correctly.
All of this will need testing and experimenting.
Right now I am fixing the build process, as it has broken a bit, and hopefully uploading bootstrap packages soon. I may want to do some mmu experiments before that, unless someone really wants them.
Somewhat related I got a lot of motivation by reading this series: https://github.com/isometimes/rpi4-osdev
It shows that most things can be done with not that much hassle.
8 Likes
Pushed haikuports.cross deps to be the haiku tree. You canāt use the latest version of haikuporter at the moment as its latest commit breaks cross-compile. So we use the revision before that (in haikuporter directory):
git reset --hard 48afa21f63069090976b27715e025f4a44be2b21
Just a quick note - donāt assume the former, 1) UEFI states, that the highest priveleged level must be used, that is EL2 if implemented (almost always is) and 2) uboot on real HW (like my Rock Pi 4B) runs and passes control to you in EL2. But yeah, qemuās virt machine runs OVMF in EL1. 
2 Likes
It is all assumptions right now They need to be verified or reevaluated all the time.