[haiku-development] Re: ARM port status and info
- From: Michael Zucchi <notzed@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 5 Feb 2010 18:19:47 +1030
Hi Matt & Johannes,
On 5 February 2010 07:35, Matt Madia <mattmadia@xxxxxxxxx> wrote:
>
> On Thu, Feb 4, 2010 at 07:42, Michael Zucchi <notzed@xxxxxxxxx> wrote:
> > Now that the build tools are building on ARM - *yay* - i've been poking
> > around with Haiku on a BeagleBoard.
> >
> I noticed on your blog[0], you mentioned a fix for ARM "Managed to get
> it to build (with a small fix for a renamed type)". At least on
> FreeBSD, arch_vm_translation_map.cpp fails to build as
> 'vm_translation_map' isn't defined. Would you care to submit a patch
> for this at dev.haiku-os.org?
For that about all I did was s/vm_translation_map/VMTranslationMap/
since none of it is used anyway. But i'll try to get a patch or two of what
I have so far.
On 5 February 2010 12:56, johannes <johanneswi@xxxxxxxxx> wrote:
> better ;) The port is not dead but I have not done much lately
> because of university but I plan to take up work again... but can't
> say when yet...
Ok good o. I was more worried about someone being active on another
branch or privately and duplicating `effort' :)
> As I see you use the framebuffer console afaik it does not yet work
> corectly together with the mmu setup stuff yet... Can you tell me
> what you got befor user_menu:enter ? because it should not get to
> this point since this indicates that it failed to find the kernel
> for example...
The frame-buffer i just hardcoded to physical memory @ 128K (into ram)
at the moment, since it crashed when it tried allocating it using the
mmu code (it currently uses code from u-boot, so i can't distribute that).
And the BoardConfig I copied from the overo one.
It does this following before it crashes inside vfprintf(), (if my bodgy
exception handler is accurate anyway). (i added a bit more debug too)
[ mostly mmu code output ]
platform_init_video()
video framebuffer: 0x88000000
video mode: 1024x768x16
platform_switch_to_logo()
arch_set_default_video_mode()
arch_set_video_mode 1024,768 @ 16
set video mode: 0x00000000
[ lots of mmu code output ]
NEXT VIRRUADRSSS: 80232000
ADDR: 80232000
map_page: vaddr 0x80232000, paddr 0x81251000
map_page: pageTable 0x81112800
map_page: inserting pageTable 0x81112800, tableEntry 50,
physicalAddress 0x81251000
map_page: done
video_display_splash: 0x00000000
Welcome to the Haiku boot loader!
platform_add_boot_device
platform_add_block_devices
user_menu: enter
Exception: Data Abort
pc: 8000dcd4 sr: 200001d3
r0: 0000000e
r1: 00000000
r2: 0000000e
...
> so empty stubs are enough right now) In the blog he also writes that
> he fixed the code to use the new mmu-table format (but I don't know
> if this is absolutely needed since my reading of the documentation
> leads me to believe that the Cortex A8 does still support the old
> format)
Well, the ARM ARM, B4.9.2, says this about CP15, C1:
XP (bit[23]) Extended page table configuration. This bit configures
the hardware page table translation mechanism:
0 = VMSAv4/v5 and VMSAv6, subpages enabled
1 = VMSAv6, subpages disabled.
Then in the Cortex-A8 TRM, section 3.2.25, for the c1 control
register. Bits 14-24 are marked as 'reserved', and in the bit
definitions it is listed as as 'This field returns 11'b01100010100
when read'. i.e. bit 23 always on, subpages disabled, etc.
Regards,
Michael
Other related posts:
