[haiku-development] Re: Raspberry Pi 2
- From: Adrien Destugues <pulkomandy@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sun, 18 Oct 2015 21:46:06 +0200
On Sun, Oct 18, 2015 at 03:03:53PM +0200, LECOQ Vincent wrote:
Hello,
Everything compile now, I can start haiku boot process on my Rpi2 and
explore the current status of the port.
U-boot start and after activation of TRACE macro, I can obtain the
following from serial port :
▒fdt_get_range_offset: range offset: 0x0
fdt_get_device_reg_byname: /axi/mbox found @ 0x3f00b880
Found boot tgz from FDT @ 0x079bc000, 1629195 bytes
argc = 0
os: 2
gd @ 0x00000000
FDT @ 0x079b7000:
fdt_totalsize: 8320
fdt_off_dt_struct: 88
fdt_off_dt_strings: 7232
fdt_off_mem_rsvmap: 40
fdt_version: 17
fdt_last_comp_version: 16
fdt_boot_cpuid_phys: 3840
fdt_size_dt_strings: 646
fdt_size_dt_struct: 7144
fdtSize: 0x2080
checking for memory...
0: base = 0,size = 134217728
total physical memory = 128MB
args.arguments_count = 0
boot(): enter
malloc(256) -> 0x80995008
boot(): heap initialized...
malloc(32) -> 0x80995110
And stay here.
I ve insert more traces for check where the code stop exactly, it is on in
system/boot/platform/u-boot/video.cpp on the call of
gFrameBuffer->Probe(); but doesn't seem to enter into :/
I don't care of the frame buffer initialisation now, I want first have a
MMC driver working. So I ve decide to disable this framebuffer
initialization and see later.
But more far, into system/boot/loader/vfs.cpp, into open_node(), on the
call of node->Open(.....), the same behavior, execution block again here
and seems don't entre into the method.
I feel like C code run well, but when it is CPP code, we have wrong memory
jump or something like that.
Have somebody meet this problem ? what can I fix ?
I don't know how far the Pi support is exactly. The first thing I would
try is enabling traces for the MMU code. Your trace stops right after a
malloc and it's possible that the memory to back it was not properly
mapped.
It may be useful to know what is the problem exactly. This is not easy
without a debugger, which is why our efforts are more focused on
platforms with QEmu support. One possibility is setting up fault
handlers, or if there already are some, add a debug message there. This
way, when the CPU makes a page fault, you get a warning message. The ARM
core even provides a "fault address" register where you can see which
address the CPU was trying to access. You can then check this with the
MMU and see what happens.
C++ does not require any kind of magic tricks to run, so I don't think
that is your problem. However, a working memory allocator is required if
allocating objects with the new operator.
The MMU code has a platform specific code for bootstrap. The idea is
that u-boot starts execution of the kernel with the MMU disabled. The
MMU first sets an "identity mapping" which allows to enable the MMU
without changing the memory map (everything is mapped so physical
address == virtual address). Then, the kernel is moved to 0x80000000
upwards (that is kernel side, address below that are userland), the
physical mappings removed, and we start running in "protected mode".
This step is a bit tricky because there may be things in the kernel
range, including the RAM we are booting from. We don't have fully
generic code for this yet. The tracing available in the MMU code will
tell you everything that happens, try to see if it forgets to map
something or overlaps some areas.
--
Adrien.
Other related posts:
