[This Week]
- Patch: Combined Adler-32 and copyright
- 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
- 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.
[Next Week]
- Test and debug boot script loader
- 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.
[Long Term]
- 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.
[Done]
- Investigate MOL device tree further
- <Mark> There is also an interesting dump of what seems to be a MOL tree
at http://josejx.net/mol/mol-stable/mollib/oftrees/oftree.nw.old (which
has a commented out entry for "AAPL,debug" set to -1). The interesting
parts I see here are the "interrupt-controller" node in /chosen and
various additional names in the "compatible" property for various
devices.
- The comparison will be done by tomorrow, at the moment I'm writing an
FCode function to dump the entire tree along with properties.
- The attached link has incomplete notes on the differences between the
device trees; they will be completed this week.
- Patch: Copyright string
- Patch has been sent in and is awaiting review.
