Apple's BootX
by Jd Lyons
In an effort to figure out why qemu-system-ppc hangs at BootX when using some emulated and KVM CPU’s, I suppose it would be good to enter some breakpoints in the code.
I found some BootX sources at:
https://opensource.apple.com/tarballs/BootX/ <https://opensource.apple.com/tarballs/BootX/>
Tho I’m not sure what versions correspond to which release of OS X?
And it’s not clear how to build them, tho I haven’t tried yet.
I found some info on BootX as well as some idea how to do what I’m looking to do:
https://people.ffii.org/~zoobab/bh.udev.org/filez/apple/mac6100/BootX.pdf
There are few other useful debugging tech- niques. Setting "auto-boot?" to false will cause the system to enter the OpenFirmware User In- terface by default. Changing kFailToBoot to 0 in include.tproj/sl.h will alter BootX’s default be- havior on error, so that it will return to Open- Firmware. Finally, calling Enter(), will cause BootX to drop back into the OpenFirmware User Interface. This can be used as a break point. The "dumpl" word will dump some memory, by en- tering the address, then the length, then "dumpl". By calling printf in BootX immediately before En- ter(), the address can be easily determined, and the variable can then be examined and altered from OpenFirmware. Finally typing the "go" command will resume BootX’s execution.
I noted when I boot from boot usb0/disk:3,\\:tbxi while holding command+v BootX sends some info to the screen, seemingly via open firware, while displaying the “Apple Logo” boot graphic. The info show some of the boot process and what stage it’s loading” loading mach_kernel’ “ loading the .mkext”
It would be nice to get this output going via Open Bios, if anyone has any idea how I might be able to do that?
1 year, 1 month
- 8
- 34
L2 Cache Settings
by James Lyons
Looks like for the 7447a we set SPR 1017( L2CR ) bit 0 ( L2E ) or
just write 0x8000000 to the reg.
Not sure how we do this in Openbios.
1 year, 1 month
- 4
- 13
Re: [OpenBIOS] Apple's BootX
by Jd Lyons
> On Jan 27, 2018, at 4:22 PM, Programmingkid <programmingkidx(a)gmail.com> wrote:
>
>
>> like for example how Apple added Penryn support to 10.4.11 even tho the first Penryn macs shipped with 10.5”
>>
>> PK, I wonder why removing Bail/halt if unknown CPU doesn’t make the 7447a cpu boot this kernel.
>>
>> Anyway, if you could give me so tips on building a new kernel, I’ll play around with it and see if I can get some more cpu’s in qemu-ppc to boot.
>
> Attached are all the software I used to help build the XNU kernel. Let me know if you have any difficulties with installing them. You should build Mac OS 10.4's kernel on Mac OS 10.4.<bootstrap_cmds-49.tar.gz><cctools-622.3.tar><IOKitUser-277.6.tar.gz><kext_tools-59.tar.gz><Libstreams-24.1.tar.gz><xnu-compiletools-20050515.tar.bz2>
Thanks PK, I’l give it a go.
1 year, 1 month
- 1
- 0
[PATCH 0/5] SPARC: implement power-off functionality
by Mark Cave-Ayland
These patches, in conjunction with the corresponding QEMU patch, implement
the power-off word for SPARC32 and SPARC64. For SPARC64 we also implement
the SUNW,power-off CIF service which is used by most OSs to power down the
machine.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk>
Mark Cave-Ayland (5):
admin: add power.fs with initial dummy power-off implementation
SPARC32: implement power-off word
SPARC64: add power device under the ebus device
SPARC64: implement power-off word
ciface.fs: implement SUNW,power-off service
arch/sparc64/openbios.c | 27 +++++++++++++++++++++++++++
drivers/obio.c | 10 ++++++++++
drivers/pci.c | 34 ++++++++++++++++++++++++++++++++++
forth/admin/build.xml | 1 +
forth/admin/power.fs | 9 +++++++++
forth/system/ciface.fs | 8 ++++++++
6 files changed, 89 insertions(+)
create mode 100644 forth/admin/power.fs
--
2.11.0
1 year, 1 month
- 1
- 6
Patch:Add 7447a support.
by Jd Lyons
This patch should get all 7447a cpus working with openbios, needs a corresponding patch to Qemu-ppc for the v1.5
diff --git a/arch/ppc/qemu/init.c b/arch/ppc/qemu/init.c
index 5ce080c..09b2db4 100644
--- a/arch/ppc/qemu/init.c
+++ b/arch/ppc/qemu/init.c
@@ -550,6 +550,18 @@ static const struct cpudef ppc_defs[] = {
.tlb_size = 0x80,
.initfn = cpu_g4_init,
},
+ .iu_version = 0x80030000,
+ .name = "PowerPC,G4",
+ .icache_size = 0x8000,
+ .dcache_size = 0x8000,
+ .icache_sets = 0x80,
+ .dcache_sets = 0x80,
+ .icache_block_size = 0x20,
+ .dcache_block_size = 0x20,
+ .tlb_sets = 0x40,
+ .tlb_size = 0x80,
+ .initfn = cpu_g4_init,
+},
{
.iu_version = 0x00390000,
.name = "PowerPC,970",
1 year, 2 months
- 3
- 6
Adding support for more CPUs
by Jd Lyons
As an addition to my post at qemu-ppc, I’d like to add support for a few more cpus to Openbios, so when I get KVM to support -cpu host: openbios will be able to boot from the cpu’s I have.
Right now I have a Powerbook6,8 with a 7447a ( PRV 80030105 ) I think this CPU is V1.5.
I also have a iBook with a 750fx ( PVR 70000112 ).
Soon I will have a Quicksilver with Dual 1Ghz G4’s, and an iBook G4 with a 7447a, not sure of the PVR’s yet.
So, I see that I need to edit the init.c, and I noticed we might need some real values from some of the chips.
{ // XXX find out real values
.iu_version = 0x800c0000,
.name = "PowerPC,74xx",
.icache_size = 0x8000,
.dcache_size = 0x8000,
.icache_sets = 0x80,
.dcache_sets = 0x80,
.icache_block_size = 0x20,
.dcache_block_size = 0x20,
.tlb_sets = 0x40,
.tlb_size = 0x80,
.initfn = cpu_750_init,
Mark, how can I get the values needed from my CPU’s?
I’m assuming we need the values for the .icach_size etc.
1 year, 2 months
- 4
- 4
[PATCH 0/2] x86 build fixes
by Mark Cave-Ayland
Following up from the x86 build failures reported on-list by Jens, here are the
proper unsquashed versions.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk>
Mark Cave-Ayland (2):
pci: fix compilation for architectures where OFMEM isn't available
x86: remove static declaration from mbheader definition
arch/x86/multiboot.c | 2 +-
drivers/pci.c | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
--
2.11.0
1 year, 2 months
- 1
- 3
Re: [OpenBIOS] failed to build
by BALATON Zoltan
On Fri, 12 Jan 2018, Jens Bauernfeind wrote:
> I build openbios in the x86 version and added the openbios-bultin.elf as addtional payload to the image (with seabios as primary, so i could easily test openbios )
> Unfortunately when I start it, it doesn't recognize the keyboard and several messages "cannot manage <device name>...."
> I know that the laptop keyboard is attached via PS/2, and in the drivers/pci.c is a PS2 Keyboard block.
This is not relevant to PS/2 keyboard but the "cannot manage" messages
about USB devices reminded me that I've only ported the OHCI driver from
coreboot so it likely won't work on a PC where UHCI (or EHCI) is more
common. If you want to use USB peripherals then you may need to port at
least one of those too. If you also want to boot from USB then maybe the
usbmsc driver will also be needed which I've also skipped (I've only added
a HID driver in OpenBIOS sufficient for a keyboard so that's the only
thing expected to work currently).
In case you've tried booting from an HDD not from a USB drive then I'd
check if that has a driver (if the ATA/SATA controller is mentioned in one
of the cannot manage lines then it's likely missing a driver). Looking at
drivers/pci_database.c I think we only have driver for virtio and CMD646
based IDE controllers although the IDE one may work for similar
controllers, but I'm not sure about that.
Regards,
BALATON Zoltan
1 year, 2 months
- 1
- 0
Re: [OpenBIOS] failed to build
by Mark Cave-Ayland
On 12/01/18 13:55, Jens Bauernfeind wrote:
> Directly pointing to openbios-builtin.elf shows this:
> qemu: could not load PC BIOS
> :-(
That's a shame. Does it work using the instructions from the previous
link I sent through?
https://www.coreboot.org/QEMU#coreboot_v3_.2B_OpenBIOS
ATB,
Mark.
1 year, 2 months
- 3
- 2
Re: [OpenBIOS] failed to build
by Mark Cave-Ayland
On 12/01/18 13:19, Jens Bauernfeind wrote:
> It seems that out of the box my coreboot image is not able to start in qemu:
> 8<---
> qemu-system-x86_64 -M q35 -bios coreboot/build/coreboot.rom -nographic
> qemu-system-x86_64: Trying to execute code outside RAM or ROM at 0x00000000000a0000
> 8<---
>
> Jens
How about instead pointing directly to the OpenBIOS ELF binary instead,
e.g. -bios path/to/openbios.elf? That should definitely work.
Also you can try both with and without -nographic depending upon whether
the VGA driver is enabled or not.
ATB,
Mark.
1 year, 2 months
- 2
- 1