[haiku-development] Re: Haiku over Raspberry PI
- From: "Adrien Destugues" <pulkomandy@xxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 03 Apr 2018 13:02:57 +0000
3 avril 2018 14:37 "Rahul Jain" <talentediq@xxxxxxxxx> a écrit:
Hi All,
I tried to pull the latest code and built it for the ARM again,
I tried running on QEMU, by the command :
qemu-system-arm -M raspi2 -kernel haiku_loader.ub -initrd
haiku-floppyboot.tgz.ub -dtb rpi2.nographic
But this time it is getting hanged on mapping memory
mmu_map_identity: [ 80000000 - 80800000]
get_next_page_table, sNextPageTableAddress 0x1104c00, sPageTableRegionEnd
0x1300000, type 0x1
get_next_page_table, sNextPageTableAddress 0x1105000, sPageTableRegionEnd
0x1300000, type 0x1
get_next_page_table, sNextPageTableAddress 0x1105400, sPageTableRegionEnd
0x1300000, type 0x1
get_next_page_table, sNextPageTableAddress 0x1105800, sPageTableRegionEnd
0x1300000, type 0x1
get_next_page_table, sNextPageTableAddress 0x1105c00, sPageTableRegionEnd
0x1300000, type 0x1
get_next_page_table, sNextPageTableAddress 0x1106000, sPageTableRegionEnd
0x1300000, type 0x1
get_next_page_table, sNextPageTableAddress 0x1106400, sPageTableRegionEnd
0x1300000, type 0x1
get_next_page_table, sNextPageTableAddress 0x1106800, sPageTableRegionEnd
0x1300000, type 0x1
Any idea what is wrong in here?
We can't guess a lot from these logs.
If I remember correctly, last time we investigated these things, the problem
was that the memory was not properly mapped. The next step would be that the
code would try to talk with the GPU using the "black board" shared memory area,
and would never get a reply from the GPU side. This could be because of
incorrect mapping, or maybe because that specific area was accidentally marked
as "cacheable" when it is not. But it could be another problem this time, I
don't know.
As you know the early boot process is:
- We configure the MMU for identity mapping (map each bit of memory we need
through the MMU, so that physical addr == virtual addr)
- We enable the MMU (this should not change the memory mapping)
- We proceed with booting, which involves moving memory around to match our
usual layout (kernel RAM mapped at 0x80000000 onwards - and no userland yet, it
will be mapped later).
In the case of ARM, in the last step we must make sure that all the hardware we
need (UART, etc) is mapped at sane addresses too. The UART in particular is
very important because if it is not properly mapped, we stop getting logs.
However, since you are using qemu, you can do some debugging without JTAG, by
looking in qemu debugger to see what the CPU is doing and why it is not sending
anything to the UART anymore. Is it waiting on something from the hardware? Did
it jump to an abort handler? Is it processing an IRQ?
--
Adrien.
Other related posts:
