OpenBIOS January 2022

openbios@openbios.org

9 participants
13 discussions

[PATCH] kernel: Fix compiler format string warnings when some debugging options are enabled
by Glenn Washburn 29 Jul '23

29 Jul '23

Signed-off-by: Glenn Washburn <development(a)efficientek.com> --- This compile-time errors from GCC 10.1.0 when the config options CONFIG_DEBUG_BOOT, CONFIG_DEBUG_DICTIONARY, and CONFIG_DEBUG_INTERPRETER are set to true in the ppc64_config.xml. I suspect these are issues for 32-bit PPC as well, but haven't checked. Glenn --- kernel/bootstrap.c | 8 ++++---- kernel/dict.c | 4 ++-- kernel/forth.c | 4 ++-- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/kernel/bootstrap.c b/kernel/bootstrap.c index b7658ab..6834597 100644 --- a/kernel/bootstrap.c +++ b/kernel/bootstrap.c @@ -133,9 +133,9 @@ static void relocation_table(unsigned char * dict_one, unsigned char *dict_two, } #ifdef CONFIG_DEBUG_DICTIONARY - printk("dict1 %lx dict2 %lx dict %lx\n",dict_one, dict_two, dict); + printk("dict1 %p dict2 %p dict %p\n",dict_one, dict_two, dict); for (i=0; i< relocation_length ; i++) - printk("reloc %d %lx\n",i+1, reloc_table[i]); + printk("reloc %d "FMT_ucellx"\n",i+1, reloc_table[i]); #endif relocation_address=reloc_table; } @@ -819,7 +819,7 @@ static int build_dictionary(void) dicthead = 0; #ifdef CONFIG_DEBUG_DICTIONARY - printk("building dictionary, %d primitives.\nbuilt words:", + printk("building dictionary, %lu primitives.\nbuilt words:", sizeof(wordnames) / sizeof(void *)); #endif @@ -1248,7 +1248,7 @@ int main(int argc, char *argv[]) printf("dict1: %p\n",bootstrapdict[0]); printf("dict2: %p\n",bootstrapdict[1]); printf("trampoline: %p\n",trampoline); - printf("size=%d, trampoline_size=%d\n",MEMORY_SIZE + (2 * + printf("size=%ld, trampoline_size=%ld\n",MEMORY_SIZE + (2 * DICTIONARY_SIZE) + TRAMPOLINE_SIZE, TRAMPOLINE_SIZE); #endif diff --git a/kernel/dict.c b/kernel/dict.c index 0986cb1..e449c5b 100644 --- a/kernel/dict.c +++ b/kernel/dict.c @@ -293,8 +293,8 @@ ucell load_dictionary(const char *data, ucell len) reloc_table=(ucell *)(data+dicthead); #ifdef CONFIG_DEBUG_DICTIONARY - printk("\nmoving dictionary (%x bytes) to %x\n", - (ucell)dicthead, (ucell)dict); + printk("\nmoving dictionary (%x bytes) to "FMT_ucellx"\n", + (ucell)dicthead, pointer2cell(dict)); printk("\ndynamic relocation..."); #endif diff --git a/kernel/forth.c b/kernel/forth.c index 61dd70d..ca3fda3 100644 --- a/kernel/forth.c +++ b/kernel/forth.c @@ -111,7 +111,7 @@ static void docol(void) PUSHR(PC); PC = read_ucell(cell2pointer(PC)); - dbg_interp_printk("docol: %s\n", cell2pointer( lfa2nfa(PC - sizeof(cell)) )); + dbg_interp_printk("docol: %s\n", (char *)cell2pointer( lfa2nfa(PC - sizeof(cell)) )); } static void semis(void) @@ -719,7 +719,7 @@ static void docol_dbg(void) debug_xt_item = debug_xt_item->next; } - dbg_interp_printk("docol_dbg: %s\n", cell2pointer(lfa2nfa(PC - sizeof(cell)))); + dbg_interp_printk("docol_dbg: %s\n", (char *)cell2pointer(lfa2nfa(PC - sizeof(cell)))); } static void semis_dbg(void) -- 2.30.2

2 4

[PATCH] ppc: fix ciface_milliseconds using incorrect frequency for delay
by Glenn Washburn 08 Feb '22

08 Feb '22

Instead of using a constant frequency for all CPUs, which have varying frequencies, use the time frequency as returned by the processor. This fixes issues where delays from ciface_milliseconds were not corresponding to elapsed time as given by the real time clock on certain platforms, eg. QEMU's mac99 machine. Signed-off-by: Glenn Washburn <development(a)efficientek.com> --- Mark, if I missed something in the commit message, feel free to make edits as you see fit. Glenn --- arch/ppc/qemu/methods.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/ppc/qemu/methods.c b/arch/ppc/qemu/methods.c index 930b47c..a423b9f 100644 --- a/arch/ppc/qemu/methods.c +++ b/arch/ppc/qemu/methods.c @@ -126,7 +126,8 @@ ciface_quiesce( unsigned long args[], unsigned long ret[] ) } /* ( -- ms ) */ -#define TIMER_FREQUENCY 16600000ULL +/* From drivers/timer.c */ +extern unsigned long timer_freq; static void ciface_milliseconds( unsigned long args[], unsigned long ret[] ) @@ -146,7 +147,7 @@ ciface_milliseconds( unsigned long args[], unsigned long ret[] ) : "cc"); ticks = (((unsigned long long)tbu) << 32) | (unsigned long long)tbl; - msecs = (1000 * ticks) / TIMER_FREQUENCY; + msecs = (1000 * ticks) / timer_freq; PUSH( msecs ); } -- 2.30.2

3 8

Possible bug in PMU RTC
by Glenn Washburn 31 Jan '22

31 Jan '22

Resending this because I didn't realize I needed to be subscribed to the list to send emails to it. Sorry for any duplicates. --- Hi list, I've noticed what I think is a bug in the PPC OpenBIOS, but it could be in QEMU. First off, are github issues[1] an acceptable way of interacting with OpenBIOS developers? I have another potential bug to report with an attachment and github seems like a better place for the attachment than the mailing list. Also, I'm not subscribed, so a friendly reminder to do reply-all when responding. I'm running the GRUB functional test suite for PPC on QEMU using the machine type mac99,via=pmu and noticed the sleep test fails. The sleep test, one of the first several tests that gets run, uses the RTC to get the current time, waits 10 seconds and gets the time again. The output from GRUB shows that the "get-time" firmware command is returning times before and after the 10 second sleep that differ by 2 seconds. The sleep is implemented in GRUB using the firmware "milliseconds" method. It calls the method in a loop until the last call minus the first call is greater or equal to the number of milliseconds given (10000 in this case). It does seem that by my watch 10 seconds do not go by, so I suspect this is an issue with the clock speed being faster than OpenBIOS thinks it is. Could this be an issue with using two different time sources one from QEMU's RTC and the other using emulated CPU frequency? I've testing with QEMU 5.2 and 6.1 on debian stable with the same results. This can be reproduced by downloading the attached XZ compressed iso, uncompressing and invoking QEMU like this: $ qemu-system-ppc -m 2047M -nographic -monitor file:/dev/null -fw_cfg name=etc/sercon-port,string=0 -serial null -serial stdio -hda grub.iso -boot c I also noticed that the firmware outputs a message "milliseconds isn't unique." Is it just a coincidence that this mentions milliseconds and that is also the name of the firmware method that seems to be at issue here? $ qemu-system-ppc -M mac99,via=pmu -display none -serial stdio s>> et_property: NULL phandle >> ============================================================= >> OpenBIOS 1.1 [Apr 16 2021 09:43] >> Configuration device id QEMU version 1 machine id 1 >> CPUs: 1 >> Memory: 128M >> UUID: 00000000-0000-0000-0000-000000000000 >> CPU type PowerPC,G4 milliseconds isn't unique. Glenn [1] https://github.com/openbios/openbios

3 7

[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