[Done] - Fix ppc: mem_claim() and mmu_claim() - Initial patch has been sent to the OpenBIOS mailing list. - Newest version submitted and waiting to be pushed to trunk. - Verify that the carriage return / newline problem is related to stack corruption - The fixes to mem_claim and mmu_claim do not fix the boot script's behavior when using carriage returns. - Turns out that this is an issue with the way `eval()` slices lines. Mark submitted a patch that fixes this limitation.
[Awaiting Review] - Remove extraneous "interrupts" property from /pci/mac-io - I'm having trouble tracking down where the property is actually being set. The mac-io devices are defined in drivers/pci_database.c, but the pci_dev_t struct (drivers/pci_database.h) doesn't appear to have an interrupts field. Much of the mac-io related functionality is defined in drivers/macio.c, but there's no mention of interrupts there so I'm kind of at a loss. - This originates from the PCI device's announcement of an IRQ pin which really shouldn't be there - This only requires minimal changes, so the patch is ready. Just has to be tested before submission. - Initial patch version has been submitted to the qemu-devel mailing list. - Review requires v2, need to follow up with that now - Patch v2 has been submitted to qemu-devel, qemu-ppc for review. - Test and debug boot script loader - We're going to shrink the scope of the patch for a less complex solution -- just a different method of measuring script length. - Patch has been submitted to the OpenBIOS mailing list for review. [This Week] - Trace virtual memory maps for rom-virt and figure out why copying the rom there doesn't work - Try to run the boot script without RELEASE-LOAD-AREA - Update project log (6.17) - Extract and disassemble nanokernel and macos kernels [Next Week] - Enable debugging in MOL - The installation is now broken after a failed make. Tried reinstalling from Zypper but it couldn't find the config files -- do they have to be added manually? - The config files are at a different location when you compile manually, but I don't remember where everything was :). Just run mol with strace, it will tell you where it's looking for things. The current ones should be somewhere in /etc. [Long Term] - Progress past quiesce() client interface call - At the moment, this function simply closes all USB devices (`usb_exit()`) and sets the Instruction and Data Address Translation bits in the MSR (@agraf: does this cause any side effects?). The stack diagram shows no arguments or return values, and none of the other `ciface` functions make any modifications to the stack other than their arguments or return values. - Looks like `quiesce` either hangs on `mtmsr` or makes a jump out of the function. - MSR.IR and MSR.DR enable paging for instructions and data respectively. IIRC we disable paging when quiesce gets called because it's the last call that Linux runs before it executes non-OF aware code IIRC. - Try to run qemu with -d in_asm,cpu,int -D log and check where the code execution hangs :). There's a good chance we're already in the Mac OS 9 kernel. - It would appear that execution has branched off into invalid memory. invalid/unsupported opcode: 00 - 00 - 00 (00000000) 00f03000 0 IN: 0x00f03000: .long 0x0 - Awesome. What code gets executed before that? Maybe we shouldn't turn off IR/DR? - Actually looking at the code, the MSR IR/DR part is surround by a #if 0 ... #endif pair... maybe something in usb_exit() is breaking things? Possibly try removing it temporarily? - usb_exit() doesn't appear to be causing any issues. - This is probably where things go wrong. At 0x07400000 I can't see a ToolboxImage: ToolboxImage current logical address = 0x07400000, ToolboxImage final physical address = 0x00C00000. - Is it just the virt<->phys map that is missing, i.e. can you see if the toolbox image is present in physical memory using the QEMU monitor "xp" command? In that case it might be that we need to mark a region as free in the virtual memory properties in order to allow the mapping to succeed. A DEBUG_CIF enabled log would help here. - IIRC we're just using a 1:1 map for almost everything, so I doubt that it's an MMU problem. From a small glimpse it almost looked like the binary simply never got loaded to the address it thought it would be loaded at. - Continue updating project log - Create and send patches - [ ] Patch: Boot script loader - [ ] ROM node - Patch: RTAS node - Patch has been sent in and is awaiting review.