On 6 February 2010 02:32, johannes <johanneswi@xxxxxxxxx> wrote: > Excerpts from Michael Zucchi's message of Fri Feb 05 07:49:47 +0000 2010: > > How do you boot the whole thing? The problem is that it does not find the > memory disk that it should get from u-boot (look at platform_add_boot_device > in src/system/boot/platform/u-boot/devices.cpp and start2.c) If you use the > created haiku_loader.ub it should put the memory disk image at the right > position.. > Ahah! I was loading haiku_loader.ub, but u-boot was already loaded from nand, so it was a bit pointless re-loading a version of itself ... the fact it did something that looked like it was working was tricking me. The boot partition is setup wrong for beagleboard to boot it anyway, so I guess I should fix that so it can boot directly off the sd-card. If I load haiku_loader_nbsd.ub things look better: ## Booting kernel from Legacy Image at 84000000 ... Image Name: haiku_loader Image Type: ARM NetBSD Multi-File Image (uncompressed) Data Size: 1626655 Bytes = 1.6 MB Load Address: 80008000 Entry Point: 80008008 Contents: Image 0: 257944 Bytes = 251.9 kB Image 1: 1368699 Bytes = 1.3 MB Verifying Checksum ... OK Loading Multi-File Image ... OK OK ## Transferring control to NetBSD stage-2 loader (at address 80008008) ... Found boot tgz @ 0x8403efe4, 1368699 bytes argc = 2 argv[0] @80021e6c = 'haiku' argv[1] @80e4179a = 'debug_screen true' os: 1 gd @ 0x80e3ffdc gd->bd @ 0x80e3ffb8 fb_base 0x00000000 uimage @ 0x84000000 uimage @ 0x84000000: magic: 27051956 size: 1626655 load: 0x80008000 ep: 0x80008008 os: 2 arch: 2 type: 4 comp: 0 name: 'haiku_loader ' contents[0] :257944 bytes contents[1] :1368699 bytes hallo1hallothree 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 video_display_splash: 0x00000000 Welcome to the Haiku boot loader! platform_add_boot_device Memory Disk at: 8403efe4 size: 14e27b add_partitions_for(0x81204028, mountFS = no) add_partitions_for(fd = 0, mountFS = no) 0x812040a0 Partition::Partition 0x812040a0 Partition::Scan() check for partitioning_system: Intel Partition Map Exception: Data Abort pc: 0x8000b304 sr: 0x800001d3 r0: 0x6130f9f8 r1: 0x32303430 r2: 0x80013831 and from analysing the stack I get (in callee order): 8000b230 <memcpy>: ... 8000b2f8: 04805004 streq r5, [r0], #4 8000b2fc: 48b10018 ldmmi r1!, {r3, r4} 8000b300: 48a00018 stmiami r0!, {r3, r4} ... 8000c31c <_ZN10MemoryDisk6ReadAtEPvxS0_m>: 8000b86c <_ZN10Descriptor6ReadAtExPvm>: 8000ba28 <read_pos>: 8000d050 <_ZN4boot9Partition6ReadAtEPvxS1_m>: 8000b86c <_ZN10Descriptor6ReadAtExPvm>: 8000ba28 <read_pos>: 80013218 <_ZN18PartitionMapParser19_ReadPartitionTableExP15partition_table>: 800135c8 <_ZN18PartitionMapParser5ParseEPKhP12PartitionMap>: >> Well, the ARM ARM, B4.9.2, says this about CP15, C1: >> > > hm then I must obviously have misread something ;) I tell you what, it's been a frustrating few weeks, I think I misread everything the first 3 times I read it. I'm only now starting to get a hang of how the manuals are organised and the device works. Michael