[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 () 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 0x0740 I can't see a
ToolboxImage: ToolboxImage current logical address = 0x0740,
ToolboxImage final physical address = 0x00C0.
- 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.
