OpenBIOS

openbios@openbios.org

4297 discussions

[PATCH] ppc: Add TLB miss exception handlers for the 603 core
by Christophe Leroy 28 Jan '22

28 Jan '22

Unlike the 604 core, the 603 doesn't perform table search in HW. When a TLB Miss occurs, the 603 generates one of three specific TLB Miss exception: - Instruction TLB Miss - Data read TLB Miss - Data store TLB Miss The associated exception handlers have to search the match page table entry and load it in a TLB entry. This patch implements the exemple provided in the reference manual (with a couple of errors corrected). Signed-off-by: Christophe Leroy <christophe.leroy(a)csgroup.eu> Cc: Fabiano Rosas <farosas(a)linux.ibm.com> Cc: Cédric Le Goater <clg(a)kaod.org> Cc: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- arch/ppc/qemu/start.S | 158 +++++++++++++++++++++++++++++++++++++++++- 1 file changed, 155 insertions(+), 3 deletions(-) diff --git a/arch/ppc/qemu/start.S b/arch/ppc/qemu/start.S index c679230..3d4102d 100644 --- a/arch/ppc/qemu/start.S +++ b/arch/ppc/qemu/start.S @@ -25,6 +25,14 @@ #define ILLEGAL_VECTOR( v ) .org __vectors + v ; vector__##v: bl trap_error ; #define VECTOR( v, dummystr ) .org __vectors + v ; vector__##v +#define SPR_DMISS 976 +#define SPR_DCMP 977 +#define SPR_HASH1 978 +#define SPR_HASH2 979 +#define SPR_IMISS 980 +#define SPR_ICMP 981 +#define SPR_RPA 982 + #ifdef CONFIG_PPC_64BITSUPPORT /* We're trying to use the same code for the ppc32 and ppc64 handlers here. @@ -329,9 +337,153 @@ ILLEGAL_VECTOR( 0xd00 ) ILLEGAL_VECTOR( 0xe00 ) ILLEGAL_VECTOR( 0xf00 ) ILLEGAL_VECTOR( 0xf20 ) -ILLEGAL_VECTOR( 0x1000 ) -ILLEGAL_VECTOR( 0x1100 ) -ILLEGAL_VECTOR( 0x1200 ) + +VECTOR( 0x1000, "IFTLB" ): + mfspr r2, SPR_HASH1 + li r1, 8 + mfctr r0 + mfspr r3, SPR_ICMP + addi r2, r2, -8 +0: mtctr r1 +1: lwzu r1, 8(r2) + cmp cr0, r1, r3 + bdnzf eq, 1b + bne 2f + lwz r1, 4(r2) + andi. r3, r1, 8 + bne 3f + mtctr r0 + mfspr r0, SPR_IMISS + mfsrr1 r3 + mtcrf 0x80, r3 + mtspr SPR_RPA, r1 + ori r1, r1, 0x100 + srwi r1, r1, 8 + tlbli r0 + stb r1, 6(r2) + rfi +2: + andi. r1, r3, 0x0040 + bne 4f + mfspr r2, SPR_HASH2 + ori r3, r3, 0x0040 + addi r1, 0, 8 + addi r2, r2, -8 + b 0b +3: + mfsrr1 r3 + andi. r2,r3,0xffff + addis r2, r2, 0x0800 + b 5f +4: + mfsrr1 r3 + andi. r2,r3,0xffff + addis r2, r2, 0x4000 +5: mtctr r0 + mtsrr1 r2 + mfmsr r0 + xoris r0, r0, 0x02 + mtcrf 0x80, r3 + mtmsr r0 + b real_isi + +VECTOR( 0x1100, "DLTLB" ): + mfspr r2, SPR_HASH1 + addi r1, 0, 8 + mfctr r0 + mfspr r3, SPR_DCMP + addi r2, r2, -8 +0: mtctr r1 +1: lwzu r1, 8(r2) + cmp cr0, r1, r3 + bdnzf eq, 1b + bne 2f + lwz r1, +4(r2) + mtctr r0 + mfspr r0, SPR_DMISS + mfsrr1 r3 + mtcrf 0x80, r3 + mtspr SPR_RPA, r1 + ori r1, r1, 0x100 + srw r1, r1, 8 + tlbld r0 + stb r1, +6(r2) + rfi +2: + andi. r1, r3, 0x0040 + bne 7f + mfspr r2, SPR_HASH2 + ori r3, r3, 0x0040 + addi r1, 0, 8 + addi r2, r2, -8 + b 0b + +VECTOR( 0x1200, "DSTLB" ): + mfspr r2, SPR_HASH1 + addi r1, 0, 8 + mfctr r0 + mfspr r3, SPR_DCMP + addi r2, r2, -8 +0: mtctr r1 +1: lwzu r1, 8(r2) + cmp cr0, r1, r3 + bdnzf eq, 1b + bne 3f + lwz r1, +4(r2) + andi. r3,r1,0x80 + beq 4f +2: mtctr r0 + mfspr r0, SPR_DMISS + mfsrr1 r3 + mtcrf 0x80, r3 + mtspr SPR_RPA, r1 + tlbld r0 + rfi +3: + andi. r1, r3, 0x0040 + bne 7f + mfspr r2, SPR_HASH2 + ori r3, r3, 0x0040 + addi r1, 0, 8 + addi r2, r2, -8 + b 0b +4: + rlwinm. r3,r1,30,0,1 + bge- 5f + andi. r3,r1,1 + beq+ 6f + b 8f +5: mfsrr1 r3 + andis. r3,r3,0x0008 + beq 6f + b 8f +6: ori r1, r1, 0x180 + sth r1, 6(r2) + b 2b +7: + mfsrr1 r3 + rlwinm r1, r3, 9,6,6 + addis r1, r1, 0x4000 + b 9f +8: + mfsrr1 r3 + rlwinm r1, r3, 9,6,6 + addis r1, r1, 0x0800 +9: mtctr r0 + andi. r2, r3, 0xffff + mtsrr1 r2 + mtdsisr r1 + mfspr r1, SPR_DMISS + rlwinm. r2,r2,0,31,31 + beq 10f + xor r1,r1,0x07 +10: mtdar r1 + mfmsr r0 + xoris r0, r0, 0x02 + mtcrf 0x80, r3 + mtmsr r0 + b real_dsi + ILLEGAL_VECTOR( 0x1300 ) ILLEGAL_VECTOR( 0x1400 ) ILLEGAL_VECTOR( 0x1500 ) -- 2.33.1

3 6

Issues compiling qemu-ppc64
by Glenn Washburn 28 Jan '22

28 Jan '22

Hi list, I've gotten the qemu-ppc target to build correctly, however, I'm having issues with the qemu-ppc64 target. I'm using the 10.1.0 GCC ppc64 compiler distributed at kernel.org[1]. I'm doing the following: $ PATH=/home/user/cross/gcc-10.1.0-nolibc/powerpc64-linux/bin:$PATH $ ./config/scripts/switch-arch qemu-ppc64 $ make V=1 The make is fine until the forthstrap command, which has this output: ./forthstrap -I/home/user/openbios.git/forth/bootstrap/ -I/home/user/openbios.git/forth/bootstrap/ -I/home/user/openbios.git/forth/lib/ -I/home/user/openbios.git/forth/device/ -I/home/user/openbios.git/forth/debugging/ -I/home/user/openbios.git/forth/admin/ -I/home/user/openbios.git/forth/util/ -I/home/user/openbios.git/forth/packages/ -I/home/user/openbios.git/forth/system/ -I/home/user/openbios.git/libopenbios/ -I/home/user/openbios.git/packages/ -I/home/user/openbios.git/drivers/ -I/home/user/openbios.git/arch/ppc/ -I/home/user/openbios.git -I./forth -D bootstrap.dict -M bootstrap.dict.d -c bootstrap.dict-console.log forth/bootstrap/start.fs panic: segmentation violation at 0xa6dbc62c dict=0x7fa7a6dbc010 here=0x7fa7a6dbc638(dict+0x628) pc=0x0(dict+0x59243ff0) dstackcnt=0 rstackcnt=0 instruction=deadbeef dstack: 0x0 rstack: 0x0 Writing dictionary core file Is anyone else seeing this? Can someone with forth experience help here? Glenn [1] https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/10.1.0…

4 12

Link error when building amd64
by Glenn Washburn 27 Jan '22

27 Jan '22

Is amd64 is another non-working/unused build target? Here's the link error. ar cru liblibc.a target/libc/ctype.o target/libc/diskio.o target/libc/extra.o target/libc/misc.o target/libc/string.o target/libc/vsprintf.o; ranlib liblibc.a ar: `u' modifier ignored since `D' is the default (see `U') gcc -fno-builtin -O0 -g -DNATIVE_BITWIDTH_EQUALS_HOST_BITWIDTH -USWAP_ENDIANNESS -Wall -Wredundant-decls -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wundef -Wendif-labels -Wstrict-aliasing -Wwrite-strings -Wmissing-prototypes -Wnested-externs -Werror -MMD -MP -MT openbios-unix -MF '/.d' -rdynamic -o openbios-unix target/arch/unix/unix.o target/arch/unix/boot.o target/arch/unix/blk.o libbootstrap.a libpackages.a libopenbios.a libdrivers.a libfs.a liblibc.a /usr/bin/ld: liblibc.a(misc.o):/home/g10/openbios.git/libc/misc.c:20: multiple definition of `errno_int'; target/arch/unix/unix.o:/home/g10/openbios.git/arch/unix/unix.c:71: first defined here Indeed errno_int is declared in both those locations. It would be easy enough for me to fix for amd64 Linux, but I can't test that it would work on OS X (per the comment in ./arch/unix/unix.c). Glenn

2 1

[PATCH] cuda: fix get-time word
by Glenn Washburn 27 Jan '22

27 Jan '22

An extra byte is written after the CUDA_GET_TIME command causing the command to return an incorrect time. Running QEMU with CUDA debug messages on yields these messages: 1177318@1642469573.070752:cuda_packet_receive length 3 1177318@1642469573.070768:cuda_packet_receive_data [0] 0x01 1177318@1642469573.070771:cuda_packet_receive_data [1] 0x03 1177318@1642469573.070773:cuda_packet_receive_data [2] 0xfb 1177318@1642469573.070776:cuda_receive_packet_cmd handling command GET_TIME CUDA: GET_TIME: wrong parameters 2 Fix the outgoing command length to remove the extra byte. Signed-off-by: Glenn Washburn <development(a)efficientek.com> --- drivers/cuda.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/cuda.c b/drivers/cuda.c index c89b174..86d2ddb 100644 --- a/drivers/cuda.c +++ b/drivers/cuda.c @@ -234,7 +234,7 @@ static inline int is_leap(int year) static void rtc_get_time(int *idx) { - uint8_t cmdbuf[2], obuf[64]; + uint8_t cmdbuf[1], obuf[64]; ucell second, minute, hour, day, month, year; uint32_t now; int current; -- 2.30.2

2 4

Forth interpreter?
by Jd Lyons 24 Jan '22

24 Jan '22

Does OB support a forth interpreter? When I try and load one with the boot command it seems to treat it as a :tbxi and I just get the no valid init file. \ comment cr hex 00000000 encode-int " fcode-rom-offset" property " scsi" encode-string " device-type" property " UltraTek133" encode-string " name" property " UltraTek133" encode-string " compatible" property " 3.5.0" encode-bytes " Rom#" property " 3.5.0" encode-string " rom-revision" property " UltraTek133" encode-string " release" property " PDC20269" encode-string " model" property " UltraTek Firmware by FirmTek LLC, 2001. You may not alter or reverse engineer this product" \ encode-bytes " Copyright" property " Authors: Nguyen Kim Chi, Rath Gyoergy." encode-bytes " authors" property " Szerzoek: Nguyen Kim Chi, Rath Gyoergy." encode-bytes " Szerzoek" \ property " 10/23/02" encode-string " release-date" property " 12:33.03" encode-string " release-time" property 0000AD69 encode-int " subsystem-id" property " SLOT-5" encode-string " AAPL,slot-name” property The \ comment should trigger the forth interpreter, but that doesn’t seem to work with OpenBios. Also, how does Openbios handle Fcode ROM’s that use compression? The FCode probably has some compression and therefore loads itself in two different steps. The first step is something like this: Code: hex tokenizer[ 0000 ]tokenizer set-rev-level tokenizer[ 004A ]tokenizer pci-architecture tokenizer[ 002A ]tokenizer pci-data-structure-start tokenizer[ 0020 ]tokenizer pci-data-structure-length tokenizer[ 105A 4D69 018085 ]tokenizer pci-header tokenizer[ 10000 ]tokenizer rom-size fcode-version2 \ format: 0x08 \ checksum: 0x72c0 (ok) \ len: 0xfd1a (64794 bytes) hex headerless variable variable_800 \ (800) … variable variable_816 \ (816) : colon_l! \ (817) : colon_l@ \ (818) : colon_variable_805_l@ \ (819) : colon_variable_804_l@ \ (81a) : colon_definition_function_81b \ (81b) … : colon_definition_function_822 \ (822) : colon_variable_80a_l! \ (823) : colon_definition_function_824 \ (824) … : colon_definition_function_83f \ (83f) " "(…)" \ 252 bytes encode-bytes " "(…)" \ 252 bytes encode-bytes encode+ … " "(…)" \ < 252 bytes encode-bytes encode+ " driver,FirmTek,MacOS,PowerPC" property colon_definition_function_83f \ (83f) colon_definition_function_824 \ (824) ['] c@ byte-load fcode-end pci-end " driver,FirmTek,MacOS,PowerPC" is a property that's ≈ 61K bytes. Some stuff is done with this (colon_definition_function_83f), then it calls byte-load on the result which means there's more FCode in the result. colon_definition_function_83f is like this: Code: : colon_definition_function_83f \ (83f) " driver,FirmTek,MacOS,PowerPC" colon_definition_function_83e \ (83e) 0= if \ (0x5) 2drop exit then get-package-property if \ (0x4) exit then drop dup colon_l@ \ (818) dup 0 <> if \ (0x56) colon_variable_80a_l! \ (823) 4 + colon_variable_809_l! \ (821) " create driver-buffer" evaluate colon_variable_80a_l@ \ (822) allot " driver-buffer" evaluate colon_variable_80b_l! \ (825) colon_variable_80b_l@ \ (824) 0 <> if \ (0xb) colon_variable_80b_l@ \ (824) colon_variable_80a_l@ \ (822) erase colon_definition_function_83d \ (83d) then else \ (0x5) 2drop then " driver,FirmTek,MacOS,PowerPC" delete-property ; colon_definition_function_83d is maybe the decompression function. I have a PC Promise ATA 133 card that by all looks is identical to the one used by Sonnet Tech in the Tempo ATA 133 line, however there exists no tool for flashing the Mac Fcode ROM to the card sans the Sonnet Flashing tool that won’t recognize a PC Card. I tried using PCI-Passthough to Qemu-System-PPC to load the Fcode ROM from a file in OpenBios, but the compressed part of the ROM doesn’t seem to work correct in OpenBios. load hd:,\ppc\fwata3.bin “ /pci/@e” open-dev to my-self 400004a 1 byte-load

3 2

openbios wrongly considers e300 core as a 64 bits CPU
by Christophe Leroy 20 Jan '22

20 Jan '22

Hello, I have encountered a problem with Openbios while trying to run it under QEMU for a e300 CPU. openbios replaces rfi by rfid on e300 processors, leading to program check exception. Following function seems wrong, the pvr for CPUs with e300 core are inside the range static int is_ppc64(void) { #ifdef __powerpc64__ return 1; #elif defined(CONFIG_PPC_64BITSUPPORT) unsigned int pvr = mfpvr(); return ((pvr >= 0x330000) && (pvr < 0x70330000)); #else return 0; #endif } $ qemu-system-ppc -cpu help | grep -e mpc83 -e e300 PowerPC mpc8343 PVR 00830010 PowerPC mpc8349a PVR 00830010 PowerPC mpc8347at PVR 00830010 PowerPC mpc8347a (alias for mpc8347at) PowerPC e300c1 PVR 00830010 PowerPC mpc8343ea PVR 00830010 PowerPC mpc8349e PVR 00830010 PowerPC mpc8347ep PVR 00830010 PowerPC mpc8347p PVR 00830010 PowerPC mpc8347eap PVR 00830010 PowerPC mpc8349 PVR 00830010 PowerPC mpc8347et PVR 00830010 PowerPC mpc8347e (alias for mpc8347et) PowerPC mpc8347t PVR 00830010 PowerPC mpc8347 (alias for mpc8347t) PowerPC mpc8343a PVR 00830010 PowerPC mpc8347eat PVR 00830010 PowerPC mpc8347ea (alias for mpc8347eat) PowerPC mpc8347ap PVR 00830010 PowerPC mpc8349ea PVR 00830010 PowerPC mpc8343e PVR 00830010 PowerPC e300c2 PVR 00840010 PowerPC e300c3 PVR 00850010 PowerPC e300 (alias for e300c3) PowerPC mpc8379e PVR 00860010 PowerPC e300c4 PVR 00860010 PowerPC mpc8377e PVR 00860010 PowerPC mpc8377 PVR 00860010 PowerPC mpc8378 PVR 00860010 PowerPC mpc8379 PVR 00860010 PowerPC mpc8378e PVR 00860010 Christophe

1 0

[PATCH RESEND] ppc: Add PVRs for the MPC7450 family
by Fabiano Rosas 15 Jan '22

15 Jan '22

This allows the processors from the 7450 family to pass the initial PVR verification. Enables 7441, 7445, 7447, 7447a, 7450, 7451, 7455, 7457 and 7457a. This should be used along with a QEMU that includes commit 1da666cd8e ("target/ppc: Disable software TLB for the 7450 family"). With Linux 5.15: $ cd buildroot $ make qemu_ppc_mac99_defconfig $ make $ qemu-system-ppc -m 1G -M mac99,via=pmu -cpu 7450 \ -kernel ./output/images/vmlinux \ -append root=/dev/sda \ -drive file=./output/images/rootfs.ext2,format=raw \ -net nic,model=sungem -net user -serial mon:stdio -nographic >> ============================================================= >> OpenBIOS 1.1 [Jan 10 2022 13:27] >> Configuration device id QEMU version 1 machine id 1 >> CPUs: 1 >> Memory: 1024M >> UUID: 00000000-0000-0000-0000-000000000000 >> CPU type PowerPC,G4 (...) Booting Linux via __start() @ 0x01000000 ... (...) Welcome to Buildroot buildroot login: Signed-off-by: Fabiano Rosas <farosas(a)linux.ibm.com> --- arch/ppc/qemu/init.c | 52 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 52 insertions(+) diff --git a/arch/ppc/qemu/init.c b/arch/ppc/qemu/init.c index 45cd77e..e40385a 100644 --- a/arch/ppc/qemu/init.c +++ b/arch/ppc/qemu/init.c @@ -569,6 +569,58 @@ static const struct cpudef ppc_defs[] = { .tlb_size = 0x80, .initfn = cpu_g4_init, }, + { + .iu_version = 0x80000000, + .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 = 0x80010000, + .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 = 0x80020000, + .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 = 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", -- 2.33.1

2 1

[PATCH] drivers: Spell QEMU all caps
by Philippe Mathieu-Daudé 15 Jan '22

15 Jan '22

Replace Qemu -> QEMU. Signed-off-by: Philippe Mathieu-Daudé <philmd(a)redhat.com> --- drivers/pci_database.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci_database.c b/drivers/pci_database.c index 14ebd29..edcc0fd 100644 --- a/drivers/pci_database.c +++ b/drivers/pci_database.c @@ -247,7 +247,7 @@ static const pci_dev_t vga_devices[] = { }, { PCI_VENDOR_ID_QEMU, PCI_DEVICE_ID_QEMU_VGA, - NULL, "QEMU,VGA", "Qemu VGA", "VGA\0", + NULL, "QEMU,VGA", "QEMU VGA", "VGA\0", 0, 0, 0, NULL, NULL, }, -- 2.31.1

2 1

[PATCH] drivers/usb: Fix building with gcc 10.x
by BALATON Zoltan 15 Jan '22

15 Jan '22

Signed-off-by: BALATON Zoltan <balaton(a)eik.bme.hu> --- drivers/usbohci.c | 16 +++++++--------- 1 file changed, 7 insertions(+), 9 deletions(-) diff --git a/drivers/usbohci.c b/drivers/usbohci.c index 774164b..c2c0f78 100644 --- a/drivers/usbohci.c +++ b/drivers/usbohci.c @@ -232,12 +232,12 @@ ohci_init (void *bar) usb_debug("HCCA addr %p\n", OHCI_INST(controller)->hcca); /* Initialize interrupt table. */ - u32 *const intr_table = OHCI_INST(controller)->hcca->HccaInterruptTable; + ohci_t *const ohci = OHCI_INST(controller); ed_t *const periodic_ed; ofmem_posix_memalign((void **)&periodic_ed, sizeof(ed_t), sizeof(ed_t)); memset((void *)periodic_ed, 0, sizeof(*periodic_ed)); for (i = 0; i < 32; ++i) - intr_table[i] = __cpu_to_le32(virt_to_phys(periodic_ed)); + ohci->hcca->HccaInterruptTable[i] = __cpu_to_le32(virt_to_phys(periodic_ed)); OHCI_INST (controller)->periodic_ed = periodic_ed; OHCI_INST (controller)->opreg->HcHCCA = __cpu_to_le32(virt_to_phys(OHCI_INST(controller)->hcca)); @@ -607,7 +607,7 @@ struct _intrq_td { u8 *data; struct _intrq_td *next; struct _intr_queue *intrq; -}; +} __attribute__ ((packed)); struct _intr_queue { volatile ed_t ed; @@ -698,14 +698,13 @@ ohci_create_intr_queue(endpoint_t *const ep, const int reqsize, /* Insert ED into periodic table. */ int nothing_placed = 1; ohci_t *const ohci = OHCI_INST(ep->dev->controller); - u32 *const intr_table = ohci->hcca->HccaInterruptTable; const u32 dummy_ptr = __cpu_to_le32(virt_to_phys(ohci->periodic_ed)); for (i = 0; i < 32; i += reqtiming) { /* Advance to the next free position. */ - while ((i < 32) && (intr_table[i] != dummy_ptr)) ++i; + while ((i < 32) && (ohci->hcca->HccaInterruptTable[i] != dummy_ptr)) ++i; if (i < 32) { usb_debug("Placed endpoint %lx to %d\n", virt_to_phys(&intrq->ed), i); - intr_table[i] = __cpu_to_le32(virt_to_phys(&intrq->ed)); + ohci->hcca->HccaInterruptTable[i] = __cpu_to_le32(virt_to_phys(&intrq->ed)); nothing_placed = 0; } } @@ -729,10 +728,9 @@ ohci_destroy_intr_queue(endpoint_t *const ep, void *const q_) /* Remove interrupt queue from periodic table. */ ohci_t *const ohci = OHCI_INST(ep->dev->controller); - u32 *const intr_table = ohci->hcca->HccaInterruptTable; for (i=0; i < 32; ++i) { - if (intr_table[i] == __cpu_to_le32(virt_to_phys(intrq))) - intr_table[i] = __cpu_to_le32(virt_to_phys(ohci->periodic_ed)); + if (ohci->hcca->HccaInterruptTable[i] == __cpu_to_le32(virt_to_phys(intrq))) + ohci->hcca->HccaInterruptTable[i] = __cpu_to_le32(virt_to_phys(ohci->periodic_ed)); } /* Wait for frame to finish. */ mdelay(1); -- 2.30.2

3 10

Re: [RFC PATCH 0/2] QEMU/openbios: PPC Software TLB support in the G4 family
by Fabiano Rosas 07 Jan '22

07 Jan '22

Fabiano Rosas <farosas(a)linux.ibm.com> writes: > Hi all, > > We have this bug in QEMU which indicates that we haven't been able to > run openbios on a 7450 cpu for quite a long time: > > https://gitlab.com/qemu-project/qemu/-/issues/86 > > OK: > $ ./qemu-system-ppc -serial mon:stdio -nographic -cpu 7410 > > >> ============================================================= > >> OpenBIOS 1.1 [Nov 1 2021 20:36] > ... > > NOK: > $ ./qemu-system-ppc -serial mon:stdio -nographic -cpu 7450 -d int > Raise exception at fff08cc4 => 0000004e (00) > QEMU: Terminated > > The actual issue is straightforward. There is a non-architected > feature that QEMU has enabled by default that openbios doesn't know > about. From the user manual: > > "The MPC7540 has a set of implementation-specific registers, > exceptions, and instructions that facilitate very efficient software > searching of the page tables in memory for when software table > searching is enabled (HID0[STEN] = 1). This section describes those > resources and provides three example code sequences that can be used > in a MPC7540 system for an efficient search of the translation tables > in software. These three code sequences can be used as handlers for > the three exceptions requiring access to the PTEs in the page tables > in memory in this case-instruction TLB miss, data TLB miss on load, > and data TLB miss on store exceptions." > > The current state: > > 1) QEMU does not check HID0[STEN] and makes the feature always enabled > by setting these cpus with the POWERPC_MMU_SOFT_74xx MMU model, > instead of the generic POWERPC_MMU_32B. > > 2) openbios does not recognize the PVRs for those cpus and also does > not have any handlers for the software TLB exceptions (vectors 0x1000, > 0x1100, 0x1200). > > Some assumptions (correct me if I'm wrong please): > > - openbios is the only firmware we use for the following cpus: 7441, > 7445, 7450, 7451, 7455, 7457, 7447, 7447a, 7448. > - without openbios, we cannot have a guest running on these cpus. > > So to bring 7450 back to life we would need to either: > > a) find another firmware/guest OS code that supports the feature; > > b) implement the switching of the feature in QEMU and have the guest > code enable it only when supported. That would take some fiddling with > the MMU code to: merge POWERPC_MMU_SOFT_74xx into POWERPC_MMU_32B, > check the HID0[STEN] bit, figure out how to switch from HW TLB miss to > SW TLB miss on demand, block access to the TLBMISS register (and > others) when the feature is off, and so on; > > c) leave the feature enabled in QEMU and implement the software TLB > miss handlers in openbios. The UM provides sample code, so this is > easy; > > d) remove support for software TLB search for the 7450 family and > switch the cpus to the POWERPC_MMU_32B model. This is by far the > easiest solution, but could cause problems for any (which?) guest OS > code that actually uses the feature. All of the existing code for the > POWERPC_MMU_SOFT_74xx MMU model would probably be removed since it > would be dead code then; > > Option (c) seemed to me like a good compromise so this is a patch > series for openbios doing that and also adding the necessary PVRs so > we can get a working guest with these cpus without too much effort. > > I have also a patch for QEMU adding basic sanity check tests for the > 7400 and 7450 families. I'll send that separately to the QEMU ml. > > Fabiano Rosas (2): > ppc: Add support for MPC7450 software TLB miss interrupts > ppc: Add PVRs for the MPC7450 family > > arch/ppc/qemu/init.c | 52 ++++++++++ > arch/ppc/qemu/start.S | 236 +++++++++++++++++++++++++++++++++++++++++- > 2 files changed, 285 insertions(+), 3 deletions(-) (Adding Mark because his email got somehow dropped from the original message) So with these patches in OpenBIOS we could get a bit further and call into the Linux kernel using the same image as the one used for the 7400. However there seems to be no support for the 7450 software TLB in the kernel. There are only handlers for the 4xx, 8xx and 603 which are different code altogether. There's no mention of the TLBMISS and PTEHI/LO registers in the code as well. Do we know of any guest OS that implements the 7450 software TLB at vectors 0x1000, 0x1100 and 0x1200? Otherwise replacing the POWERPC_MMU_SOFT_74xx model with POWERPC_MMU_32B might be the only way of getting an OS to run in the 7450 family.

5 23

← Newer
1
2
3
4
5
6
7
8
...
430
Older →

Jump to page: