- OpenBIOS - mail.coreboot.org

[commit] r1053 - in trunk/openbios-devel: arch/ppc/qemu arch/sparc32 arch/sparc64 drivers include/arch/sparc32 include/arch/sparc64 include/libopenbios
by repository service 28 Apr '12

28 Apr '12

Author: mcayland Date: Sat Apr 28 15:34:57 2012 New Revision: 1053 URL: http://tracker.coreboot.org/trac/openbios/changeset/1053 Log: Remove architecture-specific routines from ofmem.h. This cleans up the OFMEM interface by allowing us to keep all of the architecture-specific code in separate header files; in particular ofmem_sparc32.h and ofmem_sparc64.h. PPC doesn't reference the variables from ofmem.h outside of ofmem.c, so simply redefine them as static variables. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Added: trunk/openbios-devel/include/arch/sparc32/ofmem_sparc32.h trunk/openbios-devel/include/arch/sparc64/ofmem_sparc64.h Deleted: trunk/openbios-devel/arch/sparc64/ofmem_sparc64.h Modified: trunk/openbios-devel/arch/ppc/qemu/ofmem.c trunk/openbios-devel/arch/sparc32/lib.c trunk/openbios-devel/arch/sparc32/ofmem_sparc32.c trunk/openbios-devel/arch/sparc64/lib.c trunk/openbios-devel/arch/sparc64/ofmem_sparc64.c trunk/openbios-devel/drivers/iommu.c trunk/openbios-devel/include/libopenbios/ofmem.h Modified: trunk/openbios-devel/arch/ppc/qemu/ofmem.c ============================================================================== --- trunk/openbios-devel/arch/ppc/qemu/ofmem.c Sat Apr 28 15:34:52 2012 (r1052) +++ trunk/openbios-devel/arch/ppc/qemu/ofmem.c Sat Apr 28 15:34:57 2012 (r1053) @@ -75,13 +75,13 @@ return ofmem->ramsize - OF_CODE_SIZE; } -unsigned long +static unsigned long get_ram_top(void) { return get_hash_base() - (32 + 64 + 64) * 1024 - OFMEM_SIZE; } -unsigned long +static unsigned long get_ram_bottom(void) { return FREE_BASE; Modified: trunk/openbios-devel/arch/sparc32/lib.c ============================================================================== --- trunk/openbios-devel/arch/sparc32/lib.c Sat Apr 28 15:34:52 2012 (r1052) +++ trunk/openbios-devel/arch/sparc32/lib.c Sat Apr 28 15:34:57 2012 (r1053) @@ -9,7 +9,7 @@ #include "libc/vsprintf.h" #include "libopenbios/bindings.h" -#include "libopenbios/ofmem.h" +#include "arch/sparc32/ofmem_sparc32.h" #include "asm/asi.h" #include "pgtsrmmu.h" #include "openprom.h" Modified: trunk/openbios-devel/arch/sparc32/ofmem_sparc32.c ============================================================================== --- trunk/openbios-devel/arch/sparc32/ofmem_sparc32.c Sat Apr 28 15:34:52 2012 (r1052) +++ trunk/openbios-devel/arch/sparc32/ofmem_sparc32.c Sat Apr 28 15:34:57 2012 (r1053) @@ -15,7 +15,7 @@ #include "config.h" #include "libopenbios/bindings.h" #include "libc/string.h" -#include "libopenbios/ofmem.h" +#include "arch/sparc32/ofmem_sparc32.h" #include "asm/asi.h" #include "pgtsrmmu.h" Modified: trunk/openbios-devel/arch/sparc64/lib.c ============================================================================== --- trunk/openbios-devel/arch/sparc64/lib.c Sat Apr 28 15:34:52 2012 (r1052) +++ trunk/openbios-devel/arch/sparc64/lib.c Sat Apr 28 15:34:57 2012 (r1053) @@ -14,7 +14,7 @@ #include "libopenbios/sys_info.h" #include "boot.h" -#include "ofmem_sparc64.h" +#include "arch/sparc64/ofmem_sparc64.h" /* Format a string and print it on the screen, just like the libc * function printf. Modified: trunk/openbios-devel/arch/sparc64/ofmem_sparc64.c ============================================================================== --- trunk/openbios-devel/arch/sparc64/ofmem_sparc64.c Sat Apr 28 15:34:52 2012 (r1052) +++ trunk/openbios-devel/arch/sparc64/ofmem_sparc64.c Sat Apr 28 15:34:57 2012 (r1053) @@ -15,7 +15,7 @@ #include "config.h" #include "libopenbios/bindings.h" #include "libc/string.h" -#include "ofmem_sparc64.h" +#include "arch/sparc64/ofmem_sparc64.h" #include "spitfire.h" #define OF_MALLOC_BASE ((char*)OFMEM + ALIGN_SIZE(sizeof(ofmem_t), 8)) Modified: trunk/openbios-devel/drivers/iommu.c ============================================================================== --- trunk/openbios-devel/drivers/iommu.c Sat Apr 28 15:34:52 2012 (r1052) +++ trunk/openbios-devel/drivers/iommu.c Sat Apr 28 15:34:57 2012 (r1053) @@ -8,7 +8,7 @@ #include "libopenbios/bindings.h" #include "drivers/drivers.h" #include "iommu.h" -#include "libopenbios/ofmem.h" +#include "arch/sparc32/ofmem_sparc32.h" #ifdef CONFIG_DEBUG_IOMMU #define DPRINTF(fmt, args...) \ Added: trunk/openbios-devel/include/arch/sparc32/ofmem_sparc32.h ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ trunk/openbios-devel/include/arch/sparc32/ofmem_sparc32.h Sat Apr 28 15:34:57 2012 (r1053) @@ -0,0 +1,28 @@ +/* + * <ofmem_sparc32.h> + * + * OF Memory manager + * + * Copyright (C) 1999, 2002 Samuel Rydh (samuel(a)ibrium.se) + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation + * + */ + +#ifndef _H_OFMEM_SPARC32 +#define _H_OFMEM_SPARC32 + +#include "libopenbios/ofmem.h" + +struct mem; +extern struct mem cdvmem; + +extern unsigned long *l1; +extern unsigned long find_pte(unsigned long va, int alloc); + +void mem_init(struct mem *t, char *begin, char *limit); +void *mem_alloc(struct mem *t, int size, int align); + +#endif /* _H_OFMEM_SPARC32 */ \ No newline at end of file Added: trunk/openbios-devel/include/arch/sparc64/ofmem_sparc64.h ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ trunk/openbios-devel/include/arch/sparc64/ofmem_sparc64.h Sat Apr 28 15:34:57 2012 (r1053) @@ -0,0 +1,50 @@ +/* + * <ofmem_sparc64.h> + * + * OF Memory manager + * + * Copyright (C) 1999, 2002 Samuel Rydh (samuel(a)ibrium.se) + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation + * + */ + +#ifndef _H_OFMEM_SPARC64 +#define _H_OFMEM_SPARC64 + +#include "libopenbios/ofmem.h" + +#define PAGE_SIZE_4M (4 * 1024 * 1024) +#define PAGE_SIZE_512K (512 * 1024) +#define PAGE_SIZE_64K (64 * 1024) +#define PAGE_SIZE_8K (8 * 1024) +#define PAGE_MASK_4M (4 * 1024 * 1024 - 1) +#define PAGE_MASK_512K (512 * 1024 - 1) +#define PAGE_MASK_64K (64 * 1024 - 1) +#define PAGE_MASK_8K (8 * 1024 - 1) + +extern ucell *va2ttedata; +extern unsigned long find_tte(unsigned long va); + +void itlb_load2(unsigned long vaddr, unsigned long tte_data); +void itlb_load3(unsigned long vaddr, unsigned long tte_data, unsigned long tte_index); +unsigned long itlb_faultva(void); +void itlb_demap(unsigned long vaddr); +void dtlb_load2(unsigned long vaddr, unsigned long tte_data); +void dtlb_load3(unsigned long vaddr, unsigned long tte_data, unsigned long tte_index); +unsigned long dtlb_faultva(void); +void dtlb_demap(unsigned long vaddr); + +typedef int (*translation_entry_cb)(ucell phys, ucell virt, ucell size, ucell mode); + +extern void ofmem_walk_boot_map(translation_entry_cb cb); + +extern translation_t **g_ofmem_translations; + +extern void dtlb_miss_handler(void); +extern void itlb_miss_handler(void); +extern void bug(void); + +#endif /* _H_OFMEM_SPARC64 */ Modified: trunk/openbios-devel/include/libopenbios/ofmem.h ============================================================================== --- trunk/openbios-devel/include/libopenbios/ofmem.h Sat Apr 28 15:34:52 2012 (r1052) +++ trunk/openbios-devel/include/libopenbios/ofmem.h Sat Apr 28 15:34:57 2012 (r1053) @@ -129,52 +129,9 @@ /* Currently the same for all architectures */ #define PAGE_SHIFT 12 -#ifdef CONFIG_PPC -unsigned long get_ram_top( void ); -unsigned long get_ram_bottom( void ); - -#elif defined(CONFIG_SPARC32) - -/* arch/sparc32/lib.c */ -struct mem; -extern struct mem cdvmem; - -extern unsigned long *l1; -extern unsigned long find_pte(unsigned long va, int alloc); - -void mem_init(struct mem *t, char *begin, char *limit); -void *mem_alloc(struct mem *t, int size, int align); - -#elif defined(CONFIG_SPARC64) - -#define PAGE_SIZE_4M (4 * 1024 * 1024) -#define PAGE_SIZE_512K (512 * 1024) -#define PAGE_SIZE_64K (64 * 1024) -#define PAGE_SIZE_8K (8 * 1024) -#define PAGE_MASK_4M (4 * 1024 * 1024 - 1) -#define PAGE_MASK_512K (512 * 1024 - 1) -#define PAGE_MASK_64K (64 * 1024 - 1) -#define PAGE_MASK_8K (8 * 1024 - 1) - -extern ucell *va2ttedata; -extern unsigned long find_tte(unsigned long va); - -void itlb_load2(unsigned long vaddr, unsigned long tte_data); -void itlb_load3(unsigned long vaddr, unsigned long tte_data, unsigned long tte_index); -unsigned long itlb_faultva(void); -void itlb_demap(unsigned long vaddr); -void dtlb_load2(unsigned long vaddr, unsigned long tte_data); -void dtlb_load3(unsigned long vaddr, unsigned long tte_data, unsigned long tte_index); -unsigned long dtlb_faultva(void); -void dtlb_demap(unsigned long vaddr); - -#endif - -#ifdef PAGE_SHIFT #define PAGE_SIZE (1 << PAGE_SHIFT) #define PAGE_MASK (~(PAGE_SIZE - 1)) #define PAGE_ALIGN(addr) (((addr) + PAGE_SIZE - 1) & PAGE_MASK) -#endif #if defined(CONFIG_DEBUG_OFMEM) # define OFMEM_TRACE(fmt, ...) do { printk("OFMEM: " fmt, ## __VA_ARGS__); } while (0)

1 0

[commit] r1052 - in trunk/openbios-devel: arch/sparc64 include/libopenbios
by repository service 28 Apr '12

28 Apr '12

Author: mcayland Date: Sat Apr 28 15:34:52 2012 New Revision: 1052 URL: http://tracker.coreboot.org/trac/openbios/changeset/1052 Log: SPARC64: Move ofmem_arch_map_pages()/ofmem_arch_unmap_pages() into ofmem_sparc64.c with all the other architecture-specific code. Note that we also take some of the ITLB/DTLB helpers with us. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/arch/sparc64/lib.c trunk/openbios-devel/arch/sparc64/ofmem_sparc64.c trunk/openbios-devel/arch/sparc64/ofmem_sparc64.h trunk/openbios-devel/include/libopenbios/ofmem.h Modified: trunk/openbios-devel/arch/sparc64/lib.c ============================================================================== --- trunk/openbios-devel/arch/sparc64/lib.c Sat Apr 28 15:34:48 2012 (r1051) +++ trunk/openbios-devel/arch/sparc64/lib.c Sat Apr 28 15:34:52 2012 (r1052) @@ -70,15 +70,6 @@ ofmem_free(ptr); } -#define PAGE_SIZE_4M (4 * 1024 * 1024) -#define PAGE_SIZE_512K (512 * 1024) -#define PAGE_SIZE_64K (64 * 1024) -#define PAGE_SIZE_8K (8 * 1024) -#define PAGE_MASK_4M (4 * 1024 * 1024 - 1) -#define PAGE_MASK_512K (512 * 1024 - 1) -#define PAGE_MASK_64K (64 * 1024 - 1) -#define PAGE_MASK_8K (8 * 1024 - 1) - static void mmu_open(void) { @@ -180,37 +171,6 @@ PUSH(0); } -static void -dtlb_load2(unsigned long vaddr, unsigned long tte_data) -{ - asm("stxa %0, [%1] %2\n" - "stxa %3, [%%g0] %4\n" - : : "r" (vaddr), "r" (48), "i" (ASI_DMMU), - "r" (tte_data), "i" (ASI_DTLB_DATA_IN)); -} - -static void -dtlb_load3(unsigned long vaddr, unsigned long tte_data, - unsigned long tte_index) -{ - asm("stxa %0, [%1] %2\n" - "stxa %3, [%4] %5\n" - : : "r" (vaddr), "r" (48), "i" (ASI_DMMU), - "r" (tte_data), "r" (tte_index << 3), "i" (ASI_DTLB_DATA_ACCESS)); -} - -static unsigned long -dtlb_faultva(void) -{ - unsigned long faultva; - - asm("ldxa [%1] %2, %0\n" - : "=r" (faultva) - : "r" (48), "i" (ASI_DMMU)); - - return faultva; -} - /* ( index tte_data vaddr -- ? ) */ @@ -267,25 +227,6 @@ } -static void -itlb_load2(unsigned long vaddr, unsigned long tte_data) -{ - asm("stxa %0, [%1] %2\n" - "stxa %3, [%%g0] %4\n" - : : "r" (vaddr), "r" (48), "i" (ASI_IMMU), - "r" (tte_data), "i" (ASI_ITLB_DATA_IN)); -} - -static void -itlb_load3(unsigned long vaddr, unsigned long tte_data, - unsigned long tte_index) -{ - asm("stxa %0, [%1] %2\n" - "stxa %3, [%4] %5\n" - : : "r" (vaddr), "r" (48), "i" (ASI_IMMU), - "r" (tte_data), "r" (tte_index << 3), "i" (ASI_ITLB_DATA_ACCESS)); -} - /* ( index tte_data vaddr -- ? ) */ @@ -300,18 +241,6 @@ itlb_load3(vaddr, tte_data, idx); } -static unsigned long -itlb_faultva(void) -{ - unsigned long faultva; - - asm("ldxa [%1] %2, %0\n" - : "=r" (faultva) - : "r" (48), "i" (ASI_IMMU)); - - return faultva; -} - /* MMU I-TLB miss handler */ void itlb_miss_handler(void) @@ -353,49 +282,6 @@ } } -void ofmem_map_pages(phys_addr_t phys, ucell virt, ucell size, ucell mode) -{ - unsigned long tte_data, currsize; - - /* aligned to 8k page */ - size = (size + PAGE_MASK_8K) & ~PAGE_MASK_8K; - - while (size > 0) { - currsize = size; - if (currsize >= PAGE_SIZE_4M && - (virt & PAGE_MASK_4M) == 0 && - (phys & PAGE_MASK_4M) == 0) { - currsize = PAGE_SIZE_4M; - tte_data = 6ULL << 60; - } else if (currsize >= PAGE_SIZE_512K && - (virt & PAGE_MASK_512K) == 0 && - (phys & PAGE_MASK_512K) == 0) { - currsize = PAGE_SIZE_512K; - tte_data = 4ULL << 60; - } else if (currsize >= PAGE_SIZE_64K && - (virt & PAGE_MASK_64K) == 0 && - (phys & PAGE_MASK_64K) == 0) { - currsize = PAGE_SIZE_64K; - tte_data = 2ULL << 60; - } else { - currsize = PAGE_SIZE_8K; - tte_data = 0; - } - - tte_data |= phys | mode | SPITFIRE_TTE_VALID; - - if (mode & SPITFIRE_TTE_LOCKED) { - // install locked tlb entries now - itlb_load2(virt, tte_data); - dtlb_load2(virt, tte_data); - } - - size -= currsize; - phys += currsize; - virt += currsize; - } -} - /* 3.6.5 map ( phys.lo ... phys.hi virt size mode -- ) @@ -416,47 +302,6 @@ ofmem_map(phys, virt, size, mode); } -static void -itlb_demap(unsigned long vaddr) -{ - asm("stxa %0, [%0] %1\n" - : : "r" (vaddr), "i" (ASI_IMMU_DEMAP)); -} - -static void -dtlb_demap(unsigned long vaddr) -{ - asm("stxa %0, [%0] %1\n" - : : "r" (vaddr), "i" (ASI_DMMU_DEMAP)); -} - -static void -unmap_pages(ucell virt, ucell size) -{ - ucell va; - - /* align address to 8k */ - virt &= ~PAGE_MASK_8K; - - /* align size to 8k */ - size = (size + PAGE_MASK_8K) & ~PAGE_MASK_8K; - - for (va = virt; va < virt + size; va += PAGE_SIZE_8K) { - itlb_demap(va); - dtlb_demap(va); - } -} - -void ofmem_arch_unmap_pages(ucell virt, ucell size) -{ - unmap_pages(virt, size); -} - -void ofmem_arch_map_pages(phys_addr_t phys, ucell virt, ucell size, ucell mode) -{ - ofmem_map_pages(phys, virt, size, mode); -} - /* 3.6.5 unmap ( virt size -- ) Modified: trunk/openbios-devel/arch/sparc64/ofmem_sparc64.c ============================================================================== --- trunk/openbios-devel/arch/sparc64/ofmem_sparc64.c Sat Apr 28 15:34:48 2012 (r1051) +++ trunk/openbios-devel/arch/sparc64/ofmem_sparc64.c Sat Apr 28 15:34:52 2012 (r1052) @@ -135,6 +135,68 @@ availentry[i] = size; } +/* Unmap a set of pages */ +void ofmem_arch_unmap_pages(ucell virt, ucell size) +{ + ucell va; + + /* align address to 8k */ + virt &= ~PAGE_MASK_8K; + + /* align size to 8k */ + size = (size + PAGE_MASK_8K) & ~PAGE_MASK_8K; + + for (va = virt; va < virt + size; va += PAGE_SIZE_8K) { + itlb_demap(va); + dtlb_demap(va); + } +} + +/* Map a set of pages */ +void ofmem_arch_map_pages(phys_addr_t phys, ucell virt, ucell size, ucell mode) +{ + unsigned long tte_data, currsize; + + /* Install locked tlb entries now */ + if (mode & SPITFIRE_TTE_LOCKED) { + + /* aligned to 8k page */ + size = (size + PAGE_MASK_8K) & ~PAGE_MASK_8K; + + while (size > 0) { + currsize = size; + if (currsize >= PAGE_SIZE_4M && + (virt & PAGE_MASK_4M) == 0 && + (phys & PAGE_MASK_4M) == 0) { + currsize = PAGE_SIZE_4M; + tte_data = 6ULL << 60; + } else if (currsize >= PAGE_SIZE_512K && + (virt & PAGE_MASK_512K) == 0 && + (phys & PAGE_MASK_512K) == 0) { + currsize = PAGE_SIZE_512K; + tte_data = 4ULL << 60; + } else if (currsize >= PAGE_SIZE_64K && + (virt & PAGE_MASK_64K) == 0 && + (phys & PAGE_MASK_64K) == 0) { + currsize = PAGE_SIZE_64K; + tte_data = 2ULL << 60; + } else { + currsize = PAGE_SIZE_8K; + tte_data = 0; + } + + tte_data |= phys | mode | SPITFIRE_TTE_VALID; + + itlb_load2(virt, tte_data); + dtlb_load2(virt, tte_data); + + size -= currsize; + phys += currsize; + virt += currsize; + } + } +} + /************************************************************************/ /* misc */ /************************************************************************/ @@ -163,7 +225,7 @@ return SPITFIRE_TTE_CV | SPITFIRE_TTE_WRITABLE; } -/* Architecture-specific helpers */ +/* Architecture-specific OFMEM helpers */ unsigned long find_tte(unsigned long va) { @@ -194,6 +256,84 @@ return -1; } +/* ITLB handlers */ +void +itlb_load2(unsigned long vaddr, unsigned long tte_data) +{ + asm("stxa %0, [%1] %2\n" + "stxa %3, [%%g0] %4\n" + : : "r" (vaddr), "r" (48), "i" (ASI_IMMU), + "r" (tte_data), "i" (ASI_ITLB_DATA_IN)); +} + +void +itlb_load3(unsigned long vaddr, unsigned long tte_data, + unsigned long tte_index) +{ + asm("stxa %0, [%1] %2\n" + "stxa %3, [%4] %5\n" + : : "r" (vaddr), "r" (48), "i" (ASI_IMMU), + "r" (tte_data), "r" (tte_index << 3), "i" (ASI_ITLB_DATA_ACCESS)); +} + +unsigned long +itlb_faultva(void) +{ + unsigned long faultva; + + asm("ldxa [%1] %2, %0\n" + : "=r" (faultva) + : "r" (48), "i" (ASI_IMMU)); + + return faultva; +} + +void +itlb_demap(unsigned long vaddr) +{ + asm("stxa %0, [%0] %1\n" + : : "r" (vaddr), "i" (ASI_IMMU_DEMAP)); +} + +/* DTLB handlers */ +void +dtlb_load2(unsigned long vaddr, unsigned long tte_data) +{ + asm("stxa %0, [%1] %2\n" + "stxa %3, [%%g0] %4\n" + : : "r" (vaddr), "r" (48), "i" (ASI_DMMU), + "r" (tte_data), "i" (ASI_DTLB_DATA_IN)); +} + +void +dtlb_load3(unsigned long vaddr, unsigned long tte_data, + unsigned long tte_index) +{ + asm("stxa %0, [%1] %2\n" + "stxa %3, [%4] %5\n" + : : "r" (vaddr), "r" (48), "i" (ASI_DMMU), + "r" (tte_data), "r" (tte_index << 3), "i" (ASI_DTLB_DATA_ACCESS)); +} + +unsigned long +dtlb_faultva(void) +{ + unsigned long faultva; + + asm("ldxa [%1] %2, %0\n" + : "=r" (faultva) + : "r" (48), "i" (ASI_DMMU)); + + return faultva; +} + +void +dtlb_demap(unsigned long vaddr) +{ + asm("stxa %0, [%0] %1\n" + : : "r" (vaddr), "i" (ASI_DMMU_DEMAP)); +} + /************************************************************************/ /* init / cleanup */ /************************************************************************/ Modified: trunk/openbios-devel/arch/sparc64/ofmem_sparc64.h ============================================================================== --- trunk/openbios-devel/arch/sparc64/ofmem_sparc64.h Sat Apr 28 15:34:48 2012 (r1051) +++ trunk/openbios-devel/arch/sparc64/ofmem_sparc64.h Sat Apr 28 15:34:52 2012 (r1052) @@ -18,8 +18,7 @@ extern void ofmem_map_pages(ucell phys, ucell virt, ucell size, ucell mode); -typedef int (*translation_entry_cb)(ucell phys, ucell virt, - ucell size, ucell mode); +typedef int (*translation_entry_cb)(ucell phys, ucell virt, ucell size, ucell mode); extern void ofmem_walk_boot_map(translation_entry_cb cb); Modified: trunk/openbios-devel/include/libopenbios/ofmem.h ============================================================================== --- trunk/openbios-devel/include/libopenbios/ofmem.h Sat Apr 28 15:34:48 2012 (r1051) +++ trunk/openbios-devel/include/libopenbios/ofmem.h Sat Apr 28 15:34:52 2012 (r1052) @@ -147,9 +147,27 @@ #elif defined(CONFIG_SPARC64) +#define PAGE_SIZE_4M (4 * 1024 * 1024) +#define PAGE_SIZE_512K (512 * 1024) +#define PAGE_SIZE_64K (64 * 1024) +#define PAGE_SIZE_8K (8 * 1024) +#define PAGE_MASK_4M (4 * 1024 * 1024 - 1) +#define PAGE_MASK_512K (512 * 1024 - 1) +#define PAGE_MASK_64K (64 * 1024 - 1) +#define PAGE_MASK_8K (8 * 1024 - 1) + extern ucell *va2ttedata; extern unsigned long find_tte(unsigned long va); +void itlb_load2(unsigned long vaddr, unsigned long tte_data); +void itlb_load3(unsigned long vaddr, unsigned long tte_data, unsigned long tte_index); +unsigned long itlb_faultva(void); +void itlb_demap(unsigned long vaddr); +void dtlb_load2(unsigned long vaddr, unsigned long tte_data); +void dtlb_load3(unsigned long vaddr, unsigned long tte_data, unsigned long tte_index); +unsigned long dtlb_faultva(void); +void dtlb_demap(unsigned long vaddr); + #endif #ifdef PAGE_SHIFT

1 0

[commit] r1051 - in trunk/openbios-devel: arch/sparc64 include/libopenbios
by repository service 28 Apr '12

28 Apr '12

Author: mcayland Date: Sat Apr 28 15:34:48 2012 New Revision: 1051 URL: http://tracker.coreboot.org/trac/openbios/changeset/1051 Log: SPARC64: Refactor tte-data code in preparation for moving architecture-specific code to ofmem_sparc64.c. Note we also change pgmap@ so it explicitly searches for a TTE entry using architecture-specific code, plus add the code to detect whether a page is marked as locked or not into the main page mapping function. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/arch/sparc64/lib.c trunk/openbios-devel/arch/sparc64/ofmem_sparc64.c trunk/openbios-devel/include/libopenbios/ofmem.h Modified: trunk/openbios-devel/arch/sparc64/lib.c ============================================================================== --- trunk/openbios-devel/arch/sparc64/lib.c Sat Apr 28 15:34:46 2012 (r1050) +++ trunk/openbios-devel/arch/sparc64/lib.c Sat Apr 28 15:34:48 2012 (r1051) @@ -16,8 +16,6 @@ #include "ofmem_sparc64.h" -static ucell *va2ttedata = 0; - /* Format a string and print it on the screen, just like the libc * function printf. */ @@ -165,35 +163,21 @@ static void pgmap_fetch(void) { - translation_t *t = *g_ofmem_translations; - unsigned long va, tte_data; - - va = POP(); - - /* Search the ofmem linked list for this virtual address */ - while (t != NULL) { - /* Find the correct range */ - if (va >= t->virt && va < (t->virt + t->size)) { + unsigned long va, tte_data; - /* valid tte, 8k size */ - tte_data = SPITFIRE_TTE_VALID; + va = POP(); - /* mix in phys address mode */ - tte_data |= t->mode; + tte_data = find_tte(va); + if (tte_data == -1) + goto error; - /* mix in page physical address = t->phys + offset */ - tte_data |= t->phys + (va - t->virt); - - /* return tte_data */ - PUSH(tte_data); - - return; - } - t = t->next; - } + /* return tte_data */ + PUSH(tte_data); + return; - /* If we get here, there was no entry */ - PUSH(0); +error: + /* If we get here, there was no entry */ + PUSH(0); } static void @@ -270,9 +254,7 @@ } } else { /* Search the ofmem linked list for this virtual address */ - PUSH(faultva); - pgmap_fetch(); - tte_data = POP(); + tte_data = find_tte(faultva); } if (tte_data) { @@ -359,9 +341,7 @@ } } else { /* Search the ofmem linked list for this virtual address */ - PUSH(faultva); - pgmap_fetch(); - tte_data = POP(); + tte_data = find_tte(faultva); } if (tte_data) { @@ -373,16 +353,14 @@ } } -static void -map_pages(phys_addr_t phys, unsigned long virt, - unsigned long size, unsigned long mode) +void ofmem_map_pages(phys_addr_t phys, ucell virt, ucell size, ucell mode) { - unsigned long tte_data, currsize; + unsigned long tte_data, currsize; - /* aligned to 8k page */ - size = (size + PAGE_MASK_8K) & ~PAGE_MASK_8K; + /* aligned to 8k page */ + size = (size + PAGE_MASK_8K) & ~PAGE_MASK_8K; - while (size > 0) { + while (size > 0) { currsize = size; if (currsize >= PAGE_SIZE_4M && (virt & PAGE_MASK_4M) == 0 && @@ -406,20 +384,18 @@ tte_data |= phys | mode | SPITFIRE_TTE_VALID; - itlb_load2(virt, tte_data); - dtlb_load2(virt, tte_data); - + if (mode & SPITFIRE_TTE_LOCKED) { + // install locked tlb entries now + itlb_load2(virt, tte_data); + dtlb_load2(virt, tte_data); + } + size -= currsize; phys += currsize; virt += currsize; } } -void ofmem_map_pages(phys_addr_t phys, ucell virt, ucell size, ucell mode) -{ - return map_pages(phys, virt, size, mode); -} - /* 3.6.5 map ( phys.lo ... phys.hi virt size mode -- ) @@ -457,7 +433,7 @@ static void unmap_pages(ucell virt, ucell size) { - ucell va; + ucell va; /* align address to 8k */ virt &= ~PAGE_MASK_8K; @@ -478,10 +454,7 @@ void ofmem_arch_map_pages(phys_addr_t phys, ucell virt, ucell size, ucell mode) { - if (mode & SPITFIRE_TTE_LOCKED) { - // install locked tlb entries now - ofmem_map_pages(phys, virt, size, mode); - } + ofmem_map_pages(phys, virt, size, mode); } /* Modified: trunk/openbios-devel/arch/sparc64/ofmem_sparc64.c ============================================================================== --- trunk/openbios-devel/arch/sparc64/ofmem_sparc64.c Sat Apr 28 15:34:46 2012 (r1050) +++ trunk/openbios-devel/arch/sparc64/ofmem_sparc64.c Sat Apr 28 15:34:48 2012 (r1051) @@ -31,6 +31,7 @@ translation_t **g_ofmem_translations = &s_ofmem_data.ofmem.trans; +ucell *va2ttedata = 0; extern uint64_t qemu_mem_size; static inline size_t ALIGN_SIZE(size_t x, size_t a) @@ -162,6 +163,37 @@ return SPITFIRE_TTE_CV | SPITFIRE_TTE_WRITABLE; } +/* Architecture-specific helpers */ +unsigned long +find_tte(unsigned long va) +{ + translation_t *t = *g_ofmem_translations; + unsigned long tte_data; + + /* Search the ofmem linked list for this virtual address */ + while (t != NULL) { + /* Find the correct range */ + if (va >= t->virt && va < (t->virt + t->size)) { + + /* valid tte, 8k size */ + tte_data = SPITFIRE_TTE_VALID; + + /* mix in phys address mode */ + tte_data |= t->mode; + + /* mix in page physical address = t->phys + offset */ + tte_data |= t->phys + (va - t->virt); + + /* return tte_data */ + return tte_data; + } + t = t->next; + } + + /* Couldn't find tte */ + return -1; +} + /************************************************************************/ /* init / cleanup */ /************************************************************************/ Modified: trunk/openbios-devel/include/libopenbios/ofmem.h ============================================================================== --- trunk/openbios-devel/include/libopenbios/ofmem.h Sat Apr 28 15:34:46 2012 (r1050) +++ trunk/openbios-devel/include/libopenbios/ofmem.h Sat Apr 28 15:34:48 2012 (r1051) @@ -144,6 +144,12 @@ void mem_init(struct mem *t, char *begin, char *limit); void *mem_alloc(struct mem *t, int size, int align); + +#elif defined(CONFIG_SPARC64) + +extern ucell *va2ttedata; +extern unsigned long find_tte(unsigned long va); + #endif #ifdef PAGE_SHIFT

1 0

[commit] r1050 - in trunk/openbios-devel: arch/sparc32 include/libopenbios
by repository service 28 Apr '12

28 Apr '12

Author: mcayland Date: Sat Apr 28 15:34:46 2012 New Revision: 1050 URL: http://tracker.coreboot.org/trac/openbios/changeset/1050 Log: SPARC32: Move ofmem_arch_map_pages() into ofmem_sparc32.c with all the other architecture-specific code. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/arch/sparc32/lib.c trunk/openbios-devel/arch/sparc32/ofmem_sparc32.c trunk/openbios-devel/include/libopenbios/ofmem.h Modified: trunk/openbios-devel/arch/sparc32/lib.c ============================================================================== --- trunk/openbios-devel/arch/sparc32/lib.c Sat Apr 28 15:34:42 2012 (r1049) +++ trunk/openbios-devel/arch/sparc32/lib.c Sat Apr 28 15:34:46 2012 (r1050) @@ -56,8 +56,8 @@ struct mem cdvmem; /* Current device virtual memory space */ unsigned int va_shift; +unsigned long *l1; static unsigned long *context_table; -static unsigned long *l1; static ucell *mem_reg = 0; static ucell *mem_avail = 0; @@ -141,78 +141,6 @@ return p; } -static unsigned long -find_pte(unsigned long va, int alloc) -{ - uint32_t pte; - void *p; - unsigned long pa; - int ret; - - pte = l1[(va >> SRMMU_PGDIR_SHIFT) & (SRMMU_PTRS_PER_PGD - 1)]; - if ((pte & SRMMU_ET_MASK) == SRMMU_ET_INVALID) { - if (alloc) { - ret = ofmem_posix_memalign(&p, SRMMU_PTRS_PER_PMD * sizeof(int), - SRMMU_PTRS_PER_PMD * sizeof(int)); - if (ret != 0) - return ret; - pte = SRMMU_ET_PTD | ((va2pa((unsigned long)p)) >> 4); - l1[(va >> SRMMU_PGDIR_SHIFT) & (SRMMU_PTRS_PER_PGD - 1)] = pte; - /* barrier() */ - } else { - return -1; - } - } - - pa = (pte & 0xFFFFFFF0) << 4; - pa += ((va >> SRMMU_PMD_SHIFT) & (SRMMU_PTRS_PER_PMD - 1)) << 2; - pte = *(uint32_t *)pa2va(pa); - if ((pte & SRMMU_ET_MASK) == SRMMU_ET_INVALID) { - if (alloc) { - ret = ofmem_posix_memalign(&p, SRMMU_PTRS_PER_PTE * sizeof(void *), - SRMMU_PTRS_PER_PTE * sizeof(void *)); - if (ret != 0) - return ret; - pte = SRMMU_ET_PTD | ((va2pa((unsigned int)p)) >> 4); - *(uint32_t *)pa2va(pa) = pte; - } else { - return -2; - } - } - - pa = (pte & 0xFFFFFFF0) << 4; - pa += ((va >> PAGE_SHIFT) & (SRMMU_PTRS_PER_PTE - 1)) << 2; - - return pa2va(pa); -} - -static void -map_pages(phys_addr_t phys, unsigned long virt, - unsigned long size, unsigned long mode) -{ - unsigned long npages, off; - uint32_t pte; - unsigned long pa; - - DPRINTF("map_pages: va 0x%lx, pa 0x%llx, size 0x%lx\n", virt, phys, size); - - off = phys & (PAGE_SIZE - 1); - npages = (off + (size - 1) + (PAGE_SIZE - 1)) / PAGE_SIZE; - phys &= ~(uint64_t)(PAGE_SIZE - 1); - - while (npages-- != 0) { - pa = find_pte(virt, 1); - - pte = SRMMU_ET_PTE | ((phys & PAGE_MASK) >> 4); - pte |= mode; - - *(uint32_t *)pa = pte; - - virt += PAGE_SIZE; - phys += PAGE_SIZE; - } -} - /* * D5.3 pgmap@ ( va -- pte ) */ @@ -269,8 +197,7 @@ pa <<= 32; pa |= POP() & 0xffffffff; - map_pages(pa, va, size, ofmem_arch_default_translation_mode(pa)); - DPRINTF("map-page: va 0x%lx pa 0x%llx size 0x%x\n", va, pa, size); + ofmem_arch_map_pages(pa, va, size, ofmem_arch_default_translation_mode(pa)); } static void @@ -327,7 +254,7 @@ { uint64_t mpa = ((uint64_t)which_io << 32) | (uint64_t)pa; - map_pages(mpa, (unsigned long)va, size, ofmem_arch_default_translation_mode(mpa)); + ofmem_arch_map_pages(mpa, (unsigned long)va, size, ofmem_arch_default_translation_mode(mpa)); return va; } @@ -337,16 +264,6 @@ DPRINTF("obp_dumb_munmap: virta 0x%x, sz %d\n", (unsigned int)va, size); } -void ofmem_arch_unmap_pages(ucell virt, ucell size) -{ - /* Currently do nothing */ -} - -void ofmem_arch_map_pages(phys_addr_t phys, ucell virt, ucell size, ucell mode) -{ - map_pages(phys, virt, size, mode); -} - char *obp_memalloc(char *va, unsigned int size, unsigned int align) { phys_addr_t phys; @@ -483,10 +400,10 @@ va = (unsigned long)&_start; size = (unsigned long)&_end - (unsigned long)&_start; pa = va2pa(va); - map_pages(pa, va, size, ofmem_arch_default_translation_mode(pa)); + ofmem_arch_map_pages(pa, va, size, ofmem_arch_default_translation_mode(pa)); // 1:1 mapping for RAM - map_pages(0, 0, LOWMEMSZ, ofmem_arch_default_translation_mode(0)); + ofmem_arch_map_pages(0, 0, LOWMEMSZ, ofmem_arch_default_translation_mode(0)); /* * Flush cache Modified: trunk/openbios-devel/arch/sparc32/ofmem_sparc32.c ============================================================================== --- trunk/openbios-devel/arch/sparc32/ofmem_sparc32.c Sat Apr 28 15:34:42 2012 (r1049) +++ trunk/openbios-devel/arch/sparc32/ofmem_sparc32.c Sat Apr 28 15:34:46 2012 (r1050) @@ -133,12 +133,88 @@ /* Generate memory available property entry for Sparc32 */ void ofmem_arch_create_available_entry(phandle_t ph, ucell *availentry, phys_addr_t start, ucell size) { - int i = 0; + int i = 0; i += ofmem_arch_encode_physaddr(availentry, start); availentry[i] = size; } +/* Unmap a set of pages */ +void ofmem_arch_unmap_pages(ucell virt, ucell size) +{ + /* Currently do nothing */ +} + +/* Map a set of pages */ +void ofmem_arch_map_pages(phys_addr_t phys, ucell virt, ucell size, ucell mode) +{ + unsigned long npages, off; + uint32_t pte; + unsigned long pa; + + off = phys & (PAGE_SIZE - 1); + npages = (off + (size - 1) + (PAGE_SIZE - 1)) / PAGE_SIZE; + phys &= ~(uint64_t)(PAGE_SIZE - 1); + + while (npages-- != 0) { + pa = find_pte(virt, 1); + + pte = SRMMU_ET_PTE | ((phys & PAGE_MASK) >> 4); + pte |= mode; + + *(uint32_t *)pa = pte; + + virt += PAGE_SIZE; + phys += PAGE_SIZE; + } +} + +/* Architecture-specific OFMEM helpers */ +unsigned long +find_pte(unsigned long va, int alloc) +{ + uint32_t pte; + void *p; + unsigned long pa; + int ret; + + pte = l1[(va >> SRMMU_PGDIR_SHIFT) & (SRMMU_PTRS_PER_PGD - 1)]; + if ((pte & SRMMU_ET_MASK) == SRMMU_ET_INVALID) { + if (alloc) { + ret = ofmem_posix_memalign(&p, SRMMU_PTRS_PER_PMD * sizeof(int), + SRMMU_PTRS_PER_PMD * sizeof(int)); + if (ret != 0) + return ret; + pte = SRMMU_ET_PTD | ((va2pa((unsigned long)p)) >> 4); + l1[(va >> SRMMU_PGDIR_SHIFT) & (SRMMU_PTRS_PER_PGD - 1)] = pte; + /* barrier() */ + } else { + return -1; + } + } + + pa = (pte & 0xFFFFFFF0) << 4; + pa += ((va >> SRMMU_PMD_SHIFT) & (SRMMU_PTRS_PER_PMD - 1)) << 2; + pte = *(uint32_t *)pa2va(pa); + if ((pte & SRMMU_ET_MASK) == SRMMU_ET_INVALID) { + if (alloc) { + ret = ofmem_posix_memalign(&p, SRMMU_PTRS_PER_PTE * sizeof(void *), + SRMMU_PTRS_PER_PTE * sizeof(void *)); + if (ret != 0) + return ret; + pte = SRMMU_ET_PTD | ((va2pa((unsigned int)p)) >> 4); + *(uint32_t *)pa2va(pa) = pte; + } else { + return -2; + } + } + + pa = (pte & 0xFFFFFFF0) << 4; + pa += ((va >> PAGE_SHIFT) & (SRMMU_PTRS_PER_PTE - 1)) << 2; + + return pa2va(pa); +} + /************************************************************************/ /* misc */ /************************************************************************/ Modified: trunk/openbios-devel/include/libopenbios/ofmem.h ============================================================================== --- trunk/openbios-devel/include/libopenbios/ofmem.h Sat Apr 28 15:34:42 2012 (r1049) +++ trunk/openbios-devel/include/libopenbios/ofmem.h Sat Apr 28 15:34:46 2012 (r1050) @@ -139,6 +139,9 @@ struct mem; extern struct mem cdvmem; +extern unsigned long *l1; +extern unsigned long find_pte(unsigned long va, int alloc); + void mem_init(struct mem *t, char *begin, char *limit); void *mem_alloc(struct mem *t, int size, int align); #endif

1 0

[commit] r1049 - in trunk/openbios-devel: arch/ppc arch/ppc/qemu arch/sparc32 arch/sparc64 drivers include/libopenbios libopenbios
by repository service 28 Apr '12

28 Apr '12

Author: mcayland Date: Sat Apr 28 15:34:42 2012 New Revision: 1049 URL: http://tracker.coreboot.org/trac/openbios/changeset/1049 Log: Rename ofmem_arch_early_map_pages() to ofmem_arch_map_pages(). This OFMEM call does actually map the page for the architectures that require it, so let's change its name so that we now have a symmetrical ofmem_arch_map_pages() and ofmem_arch_unmap_pages() API. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/arch/ppc/ofmem.c trunk/openbios-devel/arch/ppc/qemu/ofmem.c trunk/openbios-devel/arch/sparc32/lib.c trunk/openbios-devel/arch/sparc64/lib.c trunk/openbios-devel/drivers/iommu.c trunk/openbios-devel/include/libopenbios/ofmem.h trunk/openbios-devel/libopenbios/ofmem_common.c Modified: trunk/openbios-devel/arch/ppc/ofmem.c ============================================================================== --- trunk/openbios-devel/arch/ppc/ofmem.c Sat Mar 17 17:34:21 2012 (r1048) +++ trunk/openbios-devel/arch/ppc/ofmem.c Sat Apr 28 15:34:42 2012 (r1049) @@ -121,7 +121,7 @@ /* kill page mappings in provided range */ } -void ofmem_arch_early_map_pages(ucell phys, ucell virt, ucell size, ucell mode) +void ofmem_arch_map_pages(ucell phys, ucell virt, ucell size, ucell mode) { /* none yet */ } Modified: trunk/openbios-devel/arch/ppc/qemu/ofmem.c ============================================================================== --- trunk/openbios-devel/arch/ppc/qemu/ofmem.c Sat Mar 17 17:34:21 2012 (r1048) +++ trunk/openbios-devel/arch/ppc/qemu/ofmem.c Sat Apr 28 15:34:42 2012 (r1049) @@ -129,7 +129,7 @@ /* kill page mappings in provided range */ } -void ofmem_arch_early_map_pages(phys_addr_t phys, ucell virt, ucell size, ucell mode) +void ofmem_arch_map_pages(phys_addr_t phys, ucell virt, ucell size, ucell mode) { /* none yet */ } Modified: trunk/openbios-devel/arch/sparc32/lib.c ============================================================================== --- trunk/openbios-devel/arch/sparc32/lib.c Sat Mar 17 17:34:21 2012 (r1048) +++ trunk/openbios-devel/arch/sparc32/lib.c Sat Apr 28 15:34:42 2012 (r1049) @@ -342,7 +342,7 @@ /* Currently do nothing */ } -void ofmem_arch_early_map_pages(phys_addr_t phys, ucell virt, ucell size, ucell mode) +void ofmem_arch_map_pages(phys_addr_t phys, ucell virt, ucell size, ucell mode) { map_pages(phys, virt, size, mode); } Modified: trunk/openbios-devel/arch/sparc64/lib.c ============================================================================== --- trunk/openbios-devel/arch/sparc64/lib.c Sat Mar 17 17:34:21 2012 (r1048) +++ trunk/openbios-devel/arch/sparc64/lib.c Sat Apr 28 15:34:42 2012 (r1049) @@ -476,7 +476,7 @@ unmap_pages(virt, size); } -void ofmem_arch_early_map_pages(phys_addr_t phys, ucell virt, ucell size, ucell mode) +void ofmem_arch_map_pages(phys_addr_t phys, ucell virt, ucell size, ucell mode) { if (mode & SPITFIRE_TTE_LOCKED) { // install locked tlb entries now Modified: trunk/openbios-devel/drivers/iommu.c ============================================================================== --- trunk/openbios-devel/drivers/iommu.c Sat Mar 17 17:34:21 2012 (r1048) +++ trunk/openbios-devel/drivers/iommu.c Sat Apr 28 15:34:42 2012 (r1049) @@ -68,7 +68,7 @@ */ mva = (unsigned int) va; mpa = (unsigned int) pa; - ofmem_arch_early_map_pages(mpa, mva, npages * PAGE_SIZE, ofmem_arch_io_translation_mode(mpa)); + ofmem_arch_map_pages(mpa, mva, npages * PAGE_SIZE, ofmem_arch_io_translation_mode(mpa)); /* * Map into IOMMU page table. Modified: trunk/openbios-devel/include/libopenbios/ofmem.h ============================================================================== --- trunk/openbios-devel/include/libopenbios/ofmem.h Sat Mar 17 17:34:21 2012 (r1048) +++ trunk/openbios-devel/include/libopenbios/ofmem.h Sat Apr 28 15:34:42 2012 (r1049) @@ -67,15 +67,15 @@ extern ucell ofmem_arch_get_iomem_base(void); extern ucell ofmem_arch_get_iomem_top(void); extern retain_t* ofmem_arch_get_retained(void); -extern int ofmem_arch_get_physaddr_cellsize(void); -extern int ofmem_arch_encode_physaddr(ucell *p, phys_addr_t value); +extern int ofmem_arch_get_physaddr_cellsize(void); +extern int ofmem_arch_encode_physaddr(ucell *p, phys_addr_t value); extern int ofmem_arch_get_available_entry_size(phandle_t ph); extern void ofmem_arch_create_available_entry(phandle_t ph, ucell *availentry, phys_addr_t start, ucell size); extern int ofmem_arch_get_translation_entry_size(void); extern void ofmem_arch_create_translation_entry(ucell *transentry, translation_t *t); extern ucell ofmem_arch_default_translation_mode( phys_addr_t phys ); extern ucell ofmem_arch_io_translation_mode( phys_addr_t phys ); -extern void ofmem_arch_early_map_pages(phys_addr_t phys, ucell virt, ucell size, +extern void ofmem_arch_map_pages(phys_addr_t phys, ucell virt, ucell size, ucell mode); extern void ofmem_arch_unmap_pages(ucell virt, ucell size); /* sparc64 uses this method */ Modified: trunk/openbios-devel/libopenbios/ofmem_common.c ============================================================================== --- trunk/openbios-devel/libopenbios/ofmem_common.c Sat Mar 17 17:34:21 2012 (r1048) +++ trunk/openbios-devel/libopenbios/ofmem_common.c Sat Apr 28 15:34:42 2012 (r1049) @@ -794,8 +794,8 @@ /* install translations */ ofmem_map_page_range(phys, virt, size, mode); - /* allow arch to install mappings early, e.g. for locked mappings */ - ofmem_arch_early_map_pages(phys, virt, size, mode); + /* allow arch to map the pages */ + ofmem_arch_map_pages(phys, virt, size, mode); return 0; } @@ -836,7 +836,7 @@ mode = ofmem_arch_io_translation_mode(off); ofmem_map_page_range(phys, virt, npages * PAGE_SIZE, mode); - ofmem_arch_early_map_pages(phys, virt, npages * PAGE_SIZE, mode); + ofmem_arch_map_pages(phys, virt, npages * PAGE_SIZE, mode); return (virt + off); }

1 0

[PATCH 0/8] RFC: OFMEM cleanup/memory reduction patch v2
by Mark Cave-Ayland 22 Apr '12

22 Apr '12

v2: Alter the SPARC64 video initialisation hack code so that it handles having a video memory mapping where phys_addr != virt_addr. When allocating the Forth machine memory using OFMEM, align the region on a 512K boundary on SPARC64 so that we only use 1 TLB slot for better efficiency. v1: This patchset aims to tidy up various parts of OFMEM, with the ultimate aim of reducing the image sizes. The first 4 patches perform the reorganisation, while the remainder of the patches ensure that video memory and the Forth machine memory are no longer contained within the image. Note: the resulting SPARC64 image is now approximately half of its original size - BUT because we require 512K alignment for various parts of the image because of the 512K MMU page size, our ability to claim this space back directly is limited. Any further ideas on this would be welcomed. Mark Cave-Ayland (8): Rename ofmem_arch_early_map_pages() to ofmem_arch_map_pages(). SPARC32: Move ofmem_arch_map_pages() into ofmem_sparc32.c with all the other architecture-specific code. SPARC64: Refactor tte-data code in preparation for moving architecture-specific code to ofmem_sparc64.c. SPARC64: Move ofmem_arch_map_pages()/ofmem_arch_unmap_pages() into ofmem_sparc64.c with all the other architecture-specific code. Remove architecture-specific routines from ofmem.h. SPARC64: Remove majority of the video initialisation hack. SPARC64: Swap Forth machine memory allocation over to OFMEM memory pool. SPARC32: Swap Forth machine memory allocation over to OFMEM memory pool. openbios-devel/arch/ppc/ofmem.c | 2 +- openbios-devel/arch/ppc/qemu/ofmem.c | 6 +- openbios-devel/arch/sparc32/lib.c | 95 +--------- openbios-devel/arch/sparc32/ofmem_sparc32.c | 82 ++++++++- openbios-devel/arch/sparc32/openbios.c | 27 ++- openbios-devel/arch/sparc64/ldscript | 6 - openbios-devel/arch/sparc64/lib.c | 210 ++------------------ openbios-devel/arch/sparc64/ofmem_sparc64.c | 176 ++++++++++++++++- openbios-devel/arch/sparc64/ofmem_sparc64.h | 32 --- openbios-devel/arch/sparc64/openbios.c | 30 ++- openbios-devel/drivers/iommu.c | 4 +- openbios-devel/drivers/vga_vbe.c | 9 +- .../include/arch/sparc32/ofmem_sparc32.h | 28 +++ openbios-devel/include/arch/sparc64/io.h | 2 +- .../include/arch/sparc64/ofmem_sparc64.h | 50 +++++ openbios-devel/include/libopenbios/ofmem.h | 22 +-- openbios-devel/libopenbios/ofmem_common.c | 6 +- openbios-devel/packages/video.c | 36 ++-- 18 files changed, 424 insertions(+), 399 deletions(-) delete mode 100644 openbios-devel/arch/sparc64/ofmem_sparc64.h create mode 100644 openbios-devel/include/arch/sparc32/ofmem_sparc32.h create mode 100644 openbios-devel/include/arch/sparc64/ofmem_sparc64.h -- 1.7.2.5

1 8

Re: [OpenBIOS] [PATCH 0/8] RFC: OFMEM cleanup/memory reduction patch
by Mark Cave-Ayland 22 Apr '12

22 Apr '12

On 14/04/12 13:00, Blue Swirl wrote: >> Well, the use case I'm considering at the moment is that if you build >> OpenBIOS SPARC32 with -O0 -g and then try to load it into QEMU, QEMU reports >> that the image is too large. So I'm guessing this is a limitation of the >> memory layout of the machine, rather than the space occupied by the binary. > > I'm not sure we should have this restriction on ROM size in QEMU. > Currently PROM_SIZE_MAX in QEMU is 1M, but at first the CPU is in boot > mode and so the ROM is visible for instruction access at address 0 > upwards instead of end of memory, it could be much larger. The next > device is located 16MB higher on both SS-5 and SS-20, so the max could > be easily 16MB. Oh okay - if we do actually have more space to use, then I agree that then we don't need to worry about it. Changing QEMU will be easier than writing a new set of code ;) > However, the ROM is copied to RAM soon by OpenBIOS and the RAM copy is > mapped at 0xffd00000 upwards (3MB hole). In this hole we also have to > reserve virtual address space or VA to devices esp. frame buffer > (1MB), so the available VA during run time is limited. So I don't see > how any compression would help, because after decompression the > decompressed stuff (which should actually be slightly bigger than > original because of the decompression code) must still fit to the area > available. > > It could be possible to perform some kind of bank switching to avoid > using more address space, or for example frame buffer could be > unmapped on Forth entry and remapped afterwards but this is IMHO too > tricky. > > We could also use the other VA areas mentioned in the standard, or > just blatantly use more VA than we should, probably everything would > still work because OS should not make assumptions on the what > allocations OF has made anyway. Note that this is what the patches for SPARC32/SPARC64 do at the end of my patchset (and I believe is what PPC does already) - we allocate a separate range of memory for the Forth machine using standard OFMEM calls. Since OFMEM updates the various memory/translation properties to reflect this (and various OS read these properties upon boot) then in theory everything should just work. At least I haven't seen any regressions on my test images here. I've got a new version of the patchset with some more improvements I shall post shortly. ATB, Mark.

1 0

Re: [OpenBIOS] [PATCH] pci: fix BAR setup
by Tarl Neustaedter 19 Apr '12

19 Apr '12

On 2012-Apr-19 16:29 , Artyom Tarasenko wrote: >> > >> > On an Ultra-5 this should be >> > 00000000.00000000.00000000.000001fe.01000000.00000000.01000000. >> > 01000000.00000000.00000000.000001fe.02000000.00000000.01000000. >> > 02000000.00000000.00000000.000001ff.00000000.00000001.00000000. >> > 03000000.00000000.00000000.000001ff.00000000.00000001.00000000 >> > >> > http://git.kernel.org/?p=linux/kernel/git/davem/prtconfs.git;a=blob;f=ultra… >> > >> > I guess the problem is that the properties are added by finding the >> > host bridge in the PCI bus (which btw isn't so nice), so we use the >> > pci_mem_base. Using pci_mem_base = 0 would probably fix the BAR, but >> > then VGA would get in the way. Probably something more complex is >> > needed. > Hmm. Complicated. What is actually the meaning of this property? Don't > we need the values ourselves? > If these are just BARs, can't we pass the configuration from qemu? > It's the usable address ranges on PCI - 00 is Config space, 01 is IO space, 02 is 32-bit memory and 03 is 64-bit memory. Two gotchas I know of around the memory properties. First, in Openboot, we had to hard-code never allocating address zero for memory. Too many cards out there treat a zero address in the bar as meaning "off". The other is that in the above 32-bit and 64-bit memory spaces overlap. If you try to implement this "correctly" (with a separate allocator for each), you'll end up stepping on yourself as you allocate the same address twice. But Ultra-5 doesn't support real 64-bit, so you end up pointing both 32-bit and 64-bit allocators to the same database.

1 0

Re: [OpenBIOS] [PATCH] pci: fix BAR setup
by Blue Swirl 19 Apr '12

19 Apr '12

On Thu, Apr 19, 2012 at 20:29, Artyom Tarasenko <atar4qemu(a)gmail.com> wrote: > On Thu, Apr 19, 2012 at 10:04 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote: >> On Thu, Apr 19, 2012 at 19:06, Artyom Tarasenko <atar4qemu(a)gmail.com> wrote: >>> On Sun, Mar 11, 2012 at 11:59 AM, Blue Swirl <blauwirbel(a)gmail.com> wrote: >>>> A change in QEMU on how PCI bridges are setup revealed >>>> a bug in OpenBIOS PCI setup. On Sparc64, the BARs just >>>> happened to get somewhat correct values by accident before >>>> the commit but not after the change. >>>> >>>> Don't use arch->io_base for PCI I/O port BARs. >>>> >>>> Fix Sparc64 PCI memory base. >>> >>> Could it be that the ranges property needs to be adjusted to look as >>> it did before the patch? >>> >>> This patch breaks HelenOS-0.4.3/sparc boot. But if I modify the ranges >>> property to the old value, HelenOS boots. >>> >>> 0 > cd /pci@1fe,0 ok >>> 0 > .properties >>> [...] >>> ranges -- 54 : 00 00 00 00 00 00 00 00 00 00 00 00 >>> 00 00 01 fe 01 00 00 00 00 00 00 00 02 00 00 00 01 00 00 00 00 00 00 >>> 00 00 00 00 00 00 00 01 fe 02 00 00 00 00 00 00 00 00 01 00 00 02 00 >>> 00 00 00 00 00 00 00 10 00 00 00 00 01 ff 00 00 00 00 00 00 00 00 10 >>> 00 00 00 >>> >>> Not sure about the best formatting. If I reformat it like this: >>> >>> 00000000 00000000 00000000 000001fe 01000000 00000000 02000000 >>> 01000000 00000000 00000000 000001fe 02000000 00000000 00010000 >>> 02000000 00000000 00100000 000001ff 00000000 00000000 10000000 >>> ^^^^ this one (the third) used to be 0 >>> >> >> On an Ultra-5 this should be >> 00000000.00000000.00000000.000001fe.01000000.00000000.01000000. >> 01000000.00000000.00000000.000001fe.02000000.00000000.01000000. >> 02000000.00000000.00000000.000001ff.00000000.00000001.00000000. >> 03000000.00000000.00000000.000001ff.00000000.00000001.00000000 >> >> http://git.kernel.org/?p=linux/kernel/git/davem/prtconfs.git;a=blob;f=ultra… >> >> I guess the problem is that the properties are added by finding the >> host bridge in the PCI bus (which btw isn't so nice), so we use the >> pci_mem_base. Using pci_mem_base = 0 would probably fix the BAR, but >> then VGA would get in the way. Probably something more complex is >> needed. > > Hmm. Complicated. What is actually the meaning of this property? Don't > we need the values ourselves? > If these are just BARs, can't we pass the configuration from qemu? The device drivers in OpenBIOS only want physical addresses, they should be getting correct values, otherwise they wouldn't work. But an OS must use 'ranges' to calculate them. Assistance from QEMU should not be needed, just bridge handling (maybe also PCI probing, again) should be fixed in OpenBIOS. > >>>> Signed-off-by: Blue Swirl <blauwirbel(a)gmail.com> >>>> --- >>>> >>>> I removed the bridge setup code, it's not really valid for Sparc64 APB >>>> bridges anyway and currently no devices exist behind the bridges (but >>>> that's where they really should be). >>>> >>>> Tested Sparc64 and PPC. >>>> >>>> --- >>>> arch/sparc64/openbios.c | 2 +- >>>> drivers/pci.c | 11 +++++++++-- >>>> 2 files changed, 10 insertions(+), 3 deletions(-) >>>> >>>> diff --git a/arch/sparc64/openbios.c b/arch/sparc64/openbios.c >>>> index ac709fe..ab32a8f 100644 >>>> --- a/arch/sparc64/openbios.c >>>> +++ b/arch/sparc64/openbios.c >>>> @@ -64,7 +64,7 @@ static const struct hwdef hwdefs[] = { >>>> .cfg_base = APB_SPECIAL_BASE, >>>> .cfg_len = 0x2000000, >>>> .host_mem_base = APB_MEM_BASE, >>>> - .pci_mem_base = 0, >>>> + .pci_mem_base = 0x100000, /* avoid VGA at 0xa0000 */ >>>> .mem_len = 0x10000000, >>>> .io_base = APB_SPECIAL_BASE + 0x2000000ULL, // PCI Bus I/O space >>>> .io_len = 0x10000, >>>> diff --git a/drivers/pci.c b/drivers/pci.c >>>> index f8c6414..e270a73 100644 >>>> --- a/drivers/pci.c >>>> +++ b/drivers/pci.c >>>> @@ -931,6 +931,7 @@ static void ob_pci_configure_bar(pci_addr addr, >>>> pci_config_t *config, >>>> >>>> if ((*p_omask & 0x0000000f) == 0x4) { >>>> /* 64 bits memory mapping */ >>>> + PCI_DPRINTF("Skipping 64 bit BARs for %s\n", config->path); >>>> return; >>>> } >>>> >>>> @@ -966,11 +967,17 @@ static void ob_pci_configure_bar(pci_addr addr, >>>> pci_config_t *config, >>>> size = min_align; >>>> reloc = (reloc + size -1) & ~(size - 1); >>>> if (*io_base == base) { >>>> + PCI_DPRINTF("changing io_base from 0x%lx to 0x%x\n", >>>> + *io_base, reloc + size); >>>> *io_base = reloc + size; >>>> - reloc -= arch->io_base; >>>> } else { >>>> + PCI_DPRINTF("changing mem_base from 0x%lx to 0x%x\n", >>>> + *mem_base, reloc + size); >>>> *mem_base = reloc + size; >>>> } >>>> + PCI_DPRINTF("Configuring BARs for %s: reloc 0x%x omask 0x%x " >>>> + "io_base 0x%lx mem_base 0x%lx size 0x%x\n", >>>> + config->path, reloc, *p_omask, *io_base, *mem_base, size); >>>> pci_config_write32(addr, config_addr, reloc | *p_omask); >>>> config->assigned[reg] = reloc | *p_omask; >>>> } >>>> @@ -1260,7 +1267,7 @@ int ob_pci_init(void) >>>> mem_base = arch->pci_mem_base; >>>> /* I/O ports under 0x400 are used by devices mapped at fixed >>>> location. */ >>>> - io_base = arch->io_base + 0x400; >>>> + io_base = 0x400; >>>> >>>> bus = 0; >>>> >>>> -- >>>> 1.7.9 >>>> >>>> -- >>>> OpenBIOS http://openbios.org/ >>>> Mailinglist: http://lists.openbios.org/mailman/listinfo >>>> Free your System - May the Forth be with you >>> >>> >>> >>> -- >>> Regards, >>> Artyom Tarasenko >>> >>> solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu >>> >>> -- >>> OpenBIOS http://openbios.org/ >>> Mailinglist: http://lists.openbios.org/mailman/listinfo >>> Free your System - May the Forth be with you >> >> -- >> OpenBIOS http://openbios.org/ >> Mailinglist: http://lists.openbios.org/mailman/listinfo >> Free your System - May the Forth be with you > > > > -- > Regards, > Artyom Tarasenko > > solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu > > -- > OpenBIOS http://openbios.org/ > Mailinglist: http://lists.openbios.org/mailman/listinfo > Free your System - May the Forth be with you

1 0

Re: [OpenBIOS] [PATCH] pci: fix BAR setup
by Artyom Tarasenko 19 Apr '12

19 Apr '12

On Thu, Apr 19, 2012 at 10:04 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote: > On Thu, Apr 19, 2012 at 19:06, Artyom Tarasenko <atar4qemu(a)gmail.com> wrote: >> On Sun, Mar 11, 2012 at 11:59 AM, Blue Swirl <blauwirbel(a)gmail.com> wrote: >>> A change in QEMU on how PCI bridges are setup revealed >>> a bug in OpenBIOS PCI setup. On Sparc64, the BARs just >>> happened to get somewhat correct values by accident before >>> the commit but not after the change. >>> >>> Don't use arch->io_base for PCI I/O port BARs. >>> >>> Fix Sparc64 PCI memory base. >> >> Could it be that the ranges property needs to be adjusted to look as >> it did before the patch? >> >> This patch breaks HelenOS-0.4.3/sparc boot. But if I modify the ranges >> property to the old value, HelenOS boots. >> >> 0 > cd /pci@1fe,0 ok >> 0 > .properties >> [...] >> ranges -- 54 : 00 00 00 00 00 00 00 00 00 00 00 00 >> 00 00 01 fe 01 00 00 00 00 00 00 00 02 00 00 00 01 00 00 00 00 00 00 >> 00 00 00 00 00 00 00 01 fe 02 00 00 00 00 00 00 00 00 01 00 00 02 00 >> 00 00 00 00 00 00 00 10 00 00 00 00 01 ff 00 00 00 00 00 00 00 00 10 >> 00 00 00 >> >> Not sure about the best formatting. If I reformat it like this: >> >> 00000000 00000000 00000000 000001fe 01000000 00000000 02000000 >> 01000000 00000000 00000000 000001fe 02000000 00000000 00010000 >> 02000000 00000000 00100000 000001ff 00000000 00000000 10000000 >> ^^^^ this one (the third) used to be 0 >> > > On an Ultra-5 this should be > 00000000.00000000.00000000.000001fe.01000000.00000000.01000000. > 01000000.00000000.00000000.000001fe.02000000.00000000.01000000. > 02000000.00000000.00000000.000001ff.00000000.00000001.00000000. > 03000000.00000000.00000000.000001ff.00000000.00000001.00000000 > > http://git.kernel.org/?p=linux/kernel/git/davem/prtconfs.git;a=blob;f=ultra… > > I guess the problem is that the properties are added by finding the > host bridge in the PCI bus (which btw isn't so nice), so we use the > pci_mem_base. Using pci_mem_base = 0 would probably fix the BAR, but > then VGA would get in the way. Probably something more complex is > needed. Hmm. Complicated. What is actually the meaning of this property? Don't we need the values ourselves? If these are just BARs, can't we pass the configuration from qemu? >>> Signed-off-by: Blue Swirl <blauwirbel(a)gmail.com> >>> --- >>> >>> I removed the bridge setup code, it's not really valid for Sparc64 APB >>> bridges anyway and currently no devices exist behind the bridges (but >>> that's where they really should be). >>> >>> Tested Sparc64 and PPC. >>> >>> --- >>> arch/sparc64/openbios.c | 2 +- >>> drivers/pci.c | 11 +++++++++-- >>> 2 files changed, 10 insertions(+), 3 deletions(-) >>> >>> diff --git a/arch/sparc64/openbios.c b/arch/sparc64/openbios.c >>> index ac709fe..ab32a8f 100644 >>> --- a/arch/sparc64/openbios.c >>> +++ b/arch/sparc64/openbios.c >>> @@ -64,7 +64,7 @@ static const struct hwdef hwdefs[] = { >>> .cfg_base = APB_SPECIAL_BASE, >>> .cfg_len = 0x2000000, >>> .host_mem_base = APB_MEM_BASE, >>> - .pci_mem_base = 0, >>> + .pci_mem_base = 0x100000, /* avoid VGA at 0xa0000 */ >>> .mem_len = 0x10000000, >>> .io_base = APB_SPECIAL_BASE + 0x2000000ULL, // PCI Bus I/O space >>> .io_len = 0x10000, >>> diff --git a/drivers/pci.c b/drivers/pci.c >>> index f8c6414..e270a73 100644 >>> --- a/drivers/pci.c >>> +++ b/drivers/pci.c >>> @@ -931,6 +931,7 @@ static void ob_pci_configure_bar(pci_addr addr, >>> pci_config_t *config, >>> >>> if ((*p_omask & 0x0000000f) == 0x4) { >>> /* 64 bits memory mapping */ >>> + PCI_DPRINTF("Skipping 64 bit BARs for %s\n", config->path); >>> return; >>> } >>> >>> @@ -966,11 +967,17 @@ static void ob_pci_configure_bar(pci_addr addr, >>> pci_config_t *config, >>> size = min_align; >>> reloc = (reloc + size -1) & ~(size - 1); >>> if (*io_base == base) { >>> + PCI_DPRINTF("changing io_base from 0x%lx to 0x%x\n", >>> + *io_base, reloc + size); >>> *io_base = reloc + size; >>> - reloc -= arch->io_base; >>> } else { >>> + PCI_DPRINTF("changing mem_base from 0x%lx to 0x%x\n", >>> + *mem_base, reloc + size); >>> *mem_base = reloc + size; >>> } >>> + PCI_DPRINTF("Configuring BARs for %s: reloc 0x%x omask 0x%x " >>> + "io_base 0x%lx mem_base 0x%lx size 0x%x\n", >>> + config->path, reloc, *p_omask, *io_base, *mem_base, size); >>> pci_config_write32(addr, config_addr, reloc | *p_omask); >>> config->assigned[reg] = reloc | *p_omask; >>> } >>> @@ -1260,7 +1267,7 @@ int ob_pci_init(void) >>> mem_base = arch->pci_mem_base; >>> /* I/O ports under 0x400 are used by devices mapped at fixed >>> location. */ >>> - io_base = arch->io_base + 0x400; >>> + io_base = 0x400; >>> >>> bus = 0; >>> >>> -- >>> 1.7.9 >>> >>> -- >>> OpenBIOS http://openbios.org/ >>> Mailinglist: http://lists.openbios.org/mailman/listinfo >>> Free your System - May the Forth be with you >> >> >> >> -- >> Regards, >> Artyom Tarasenko >> >> solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu >> >> -- >> OpenBIOS http://openbios.org/ >> Mailinglist: http://lists.openbios.org/mailman/listinfo >> Free your System - May the Forth be with you > > -- > OpenBIOS http://openbios.org/ > Mailinglist: http://lists.openbios.org/mailman/listinfo > Free your System - May the Forth be with you -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu

1 0

Re: [OpenBIOS] [PATCH] pci: fix BAR setup
by Blue Swirl 19 Apr '12

19 Apr '12

On Thu, Apr 19, 2012 at 19:06, Artyom Tarasenko <atar4qemu(a)gmail.com> wrote: > On Sun, Mar 11, 2012 at 11:59 AM, Blue Swirl <blauwirbel(a)gmail.com> wrote: >> A change in QEMU on how PCI bridges are setup revealed >> a bug in OpenBIOS PCI setup. On Sparc64, the BARs just >> happened to get somewhat correct values by accident before >> the commit but not after the change. >> >> Don't use arch->io_base for PCI I/O port BARs. >> >> Fix Sparc64 PCI memory base. > > Could it be that the ranges property needs to be adjusted to look as > it did before the patch? > > This patch breaks HelenOS-0.4.3/sparc boot. But if I modify the ranges > property to the old value, HelenOS boots. > > 0 > cd /pci@1fe,0 ok > 0 > .properties > [...] > ranges -- 54 : 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 01 fe 01 00 00 00 00 00 00 00 02 00 00 00 01 00 00 00 00 00 00 > 00 00 00 00 00 00 00 01 fe 02 00 00 00 00 00 00 00 00 01 00 00 02 00 > 00 00 00 00 00 00 00 10 00 00 00 00 01 ff 00 00 00 00 00 00 00 00 10 > 00 00 00 > > Not sure about the best formatting. If I reformat it like this: > > 00000000 00000000 00000000 000001fe 01000000 00000000 02000000 > 01000000 00000000 00000000 000001fe 02000000 00000000 00010000 > 02000000 00000000 00100000 000001ff 00000000 00000000 10000000 > ^^^^ this one (the third) used to be 0 > On an Ultra-5 this should be 00000000.00000000.00000000.000001fe.01000000.00000000.01000000. 01000000.00000000.00000000.000001fe.02000000.00000000.01000000. 02000000.00000000.00000000.000001ff.00000000.00000001.00000000. 03000000.00000000.00000000.000001ff.00000000.00000001.00000000 http://git.kernel.org/?p=linux/kernel/git/davem/prtconfs.git;a=blob;f=ultra… I guess the problem is that the properties are added by finding the host bridge in the PCI bus (which btw isn't so nice), so we use the pci_mem_base. Using pci_mem_base = 0 would probably fix the BAR, but then VGA would get in the way. Probably something more complex is needed. >> Signed-off-by: Blue Swirl <blauwirbel(a)gmail.com> >> --- >> >> I removed the bridge setup code, it's not really valid for Sparc64 APB >> bridges anyway and currently no devices exist behind the bridges (but >> that's where they really should be). >> >> Tested Sparc64 and PPC. >> >> --- >> arch/sparc64/openbios.c | 2 +- >> drivers/pci.c | 11 +++++++++-- >> 2 files changed, 10 insertions(+), 3 deletions(-) >> >> diff --git a/arch/sparc64/openbios.c b/arch/sparc64/openbios.c >> index ac709fe..ab32a8f 100644 >> --- a/arch/sparc64/openbios.c >> +++ b/arch/sparc64/openbios.c >> @@ -64,7 +64,7 @@ static const struct hwdef hwdefs[] = { >> .cfg_base = APB_SPECIAL_BASE, >> .cfg_len = 0x2000000, >> .host_mem_base = APB_MEM_BASE, >> - .pci_mem_base = 0, >> + .pci_mem_base = 0x100000, /* avoid VGA at 0xa0000 */ >> .mem_len = 0x10000000, >> .io_base = APB_SPECIAL_BASE + 0x2000000ULL, // PCI Bus I/O space >> .io_len = 0x10000, >> diff --git a/drivers/pci.c b/drivers/pci.c >> index f8c6414..e270a73 100644 >> --- a/drivers/pci.c >> +++ b/drivers/pci.c >> @@ -931,6 +931,7 @@ static void ob_pci_configure_bar(pci_addr addr, >> pci_config_t *config, >> >> if ((*p_omask & 0x0000000f) == 0x4) { >> /* 64 bits memory mapping */ >> + PCI_DPRINTF("Skipping 64 bit BARs for %s\n", config->path); >> return; >> } >> >> @@ -966,11 +967,17 @@ static void ob_pci_configure_bar(pci_addr addr, >> pci_config_t *config, >> size = min_align; >> reloc = (reloc + size -1) & ~(size - 1); >> if (*io_base == base) { >> + PCI_DPRINTF("changing io_base from 0x%lx to 0x%x\n", >> + *io_base, reloc + size); >> *io_base = reloc + size; >> - reloc -= arch->io_base; >> } else { >> + PCI_DPRINTF("changing mem_base from 0x%lx to 0x%x\n", >> + *mem_base, reloc + size); >> *mem_base = reloc + size; >> } >> + PCI_DPRINTF("Configuring BARs for %s: reloc 0x%x omask 0x%x " >> + "io_base 0x%lx mem_base 0x%lx size 0x%x\n", >> + config->path, reloc, *p_omask, *io_base, *mem_base, size); >> pci_config_write32(addr, config_addr, reloc | *p_omask); >> config->assigned[reg] = reloc | *p_omask; >> } >> @@ -1260,7 +1267,7 @@ int ob_pci_init(void) >> mem_base = arch->pci_mem_base; >> /* I/O ports under 0x400 are used by devices mapped at fixed >> location. */ >> - io_base = arch->io_base + 0x400; >> + io_base = 0x400; >> >> bus = 0; >> >> -- >> 1.7.9 >> >> -- >> OpenBIOS http://openbios.org/ >> Mailinglist: http://lists.openbios.org/mailman/listinfo >> Free your System - May the Forth be with you > > > > -- > Regards, > Artyom Tarasenko > > solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu > > -- > OpenBIOS http://openbios.org/ > Mailinglist: http://lists.openbios.org/mailman/listinfo > Free your System - May the Forth be with you

1 0

Re: [OpenBIOS] [PATCH] pci: fix BAR setup
by Artyom Tarasenko 19 Apr '12

19 Apr '12

On Sun, Mar 11, 2012 at 11:59 AM, Blue Swirl <blauwirbel(a)gmail.com> wrote: > A change in QEMU on how PCI bridges are setup revealed > a bug in OpenBIOS PCI setup. On Sparc64, the BARs just > happened to get somewhat correct values by accident before > the commit but not after the change. > > Don't use arch->io_base for PCI I/O port BARs. > > Fix Sparc64 PCI memory base. Could it be that the ranges property needs to be adjusted to look as it did before the patch? This patch breaks HelenOS-0.4.3/sparc boot. But if I modify the ranges property to the old value, HelenOS boots. 0 > cd /pci@1fe,0 ok 0 > .properties [...] ranges -- 54 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 fe 01 00 00 00 00 00 00 00 02 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 01 fe 02 00 00 00 00 00 00 00 00 01 00 00 02 00 00 00 00 00 00 00 00 10 00 00 00 00 01 ff 00 00 00 00 00 00 00 00 10 00 00 00 Not sure about the best formatting. If I reformat it like this: 00000000 00000000 00000000 000001fe 01000000 00000000 02000000 01000000 00000000 00000000 000001fe 02000000 00000000 00010000 02000000 00000000 00100000 000001ff 00000000 00000000 10000000 ^^^^ this one (the third) used to be 0 > Signed-off-by: Blue Swirl <blauwirbel(a)gmail.com> > --- > > I removed the bridge setup code, it's not really valid for Sparc64 APB > bridges anyway and currently no devices exist behind the bridges (but > that's where they really should be). > > Tested Sparc64 and PPC. > > --- > arch/sparc64/openbios.c | 2 +- > drivers/pci.c | 11 +++++++++-- > 2 files changed, 10 insertions(+), 3 deletions(-) > > diff --git a/arch/sparc64/openbios.c b/arch/sparc64/openbios.c > index ac709fe..ab32a8f 100644 > --- a/arch/sparc64/openbios.c > +++ b/arch/sparc64/openbios.c > @@ -64,7 +64,7 @@ static const struct hwdef hwdefs[] = { > .cfg_base = APB_SPECIAL_BASE, > .cfg_len = 0x2000000, > .host_mem_base = APB_MEM_BASE, > - .pci_mem_base = 0, > + .pci_mem_base = 0x100000, /* avoid VGA at 0xa0000 */ > .mem_len = 0x10000000, > .io_base = APB_SPECIAL_BASE + 0x2000000ULL, // PCI Bus I/O space > .io_len = 0x10000, > diff --git a/drivers/pci.c b/drivers/pci.c > index f8c6414..e270a73 100644 > --- a/drivers/pci.c > +++ b/drivers/pci.c > @@ -931,6 +931,7 @@ static void ob_pci_configure_bar(pci_addr addr, > pci_config_t *config, > > if ((*p_omask & 0x0000000f) == 0x4) { > /* 64 bits memory mapping */ > + PCI_DPRINTF("Skipping 64 bit BARs for %s\n", config->path); > return; > } > > @@ -966,11 +967,17 @@ static void ob_pci_configure_bar(pci_addr addr, > pci_config_t *config, > size = min_align; > reloc = (reloc + size -1) & ~(size - 1); > if (*io_base == base) { > + PCI_DPRINTF("changing io_base from 0x%lx to 0x%x\n", > + *io_base, reloc + size); > *io_base = reloc + size; > - reloc -= arch->io_base; > } else { > + PCI_DPRINTF("changing mem_base from 0x%lx to 0x%x\n", > + *mem_base, reloc + size); > *mem_base = reloc + size; > } > + PCI_DPRINTF("Configuring BARs for %s: reloc 0x%x omask 0x%x " > + "io_base 0x%lx mem_base 0x%lx size 0x%x\n", > + config->path, reloc, *p_omask, *io_base, *mem_base, size); > pci_config_write32(addr, config_addr, reloc | *p_omask); > config->assigned[reg] = reloc | *p_omask; > } > @@ -1260,7 +1267,7 @@ int ob_pci_init(void) > mem_base = arch->pci_mem_base; > /* I/O ports under 0x400 are used by devices mapped at fixed > location. */ > - io_base = arch->io_base + 0x400; > + io_base = 0x400; > > bus = 0; > > -- > 1.7.9 > > -- > OpenBIOS http://openbios.org/ > Mailinglist: http://lists.openbios.org/mailman/listinfo > Free your System - May the Forth be with you -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu

1 0

Re : [PATCH 0/8] RFC: OFMEM cleanup/memory reduction patch
by Olivier DANET 16 Apr '12

16 Apr '12

On 4/14/12, Artyom Tarasenko wrote: >Maybe you can tell whether this project uses SMP, or boots something-non Linux? >Of course if it's not top secret. I'm asking because I suspect qemu >and OpenBIOS have problems in these areas. Would be interesting to >know what are the field results. Sorry, nothing in that area for now. There is a lot of work remaining and no shortage of cool ideas !

1 0

Re : [PATCH 0/8] RFC: OFMEM cleanup/memory reduction patch
by Olivier DANET 14 Apr '12

14 Apr '12

>Interesting, can you tell more about this project? Did you also modify >QEMU to emulate the HW setup? The project is currently in stealth mode, so I can't give any details for now. >We should try to isolate the dependencies for QEMU, even if QEMU is >probably the most interesting use case for OpenBIOS these days. Could >you tell more about those bugs and even better, publish your changes? A few issues : - arch/sparc32/wuf.S : WIM register updates must not be immediately followed by instructions depending on WIM value (SparcV8, §B.29, page 133) : wr %twin_tmp1, 0x0, %wim /* Make window 'I' invalid */ + nop + nop + nop restore %g0, %g0, %g0 /* Restore to window 'O' */ - arc/sparc32/entry.S : The FP (frame ptr) register is never initialised. Registers are not initialized after a RESET (SparcV8, page 75). - arch/sparc32/entry.S : MMU activation is written as : set highmem, %g2 set 1, %g1 jmp %g2 sta %g1, [%g0] ASI_M_MMUREGS ! enable mmu It doesn't work because there is no precise synchronisation between MMU registers updates and instruction fetches (because of pipelining) MMU activation must be done in a area where virtual and physical adresses are equal ( VA=FF00_0000 --> PA=F_FF00_0000 ). The intial page table is modified to add this mapping and the activation sequence is : - jump from 0_ to F_something (PROM boot mode) - activate the MMU - plenty of NOPs - jump to "highmem" I also eventually disassembled Sun ROMs, and found sequences like that : sta %l1,[%l0],4 iflush nop nop nop nop nop I can post patches, but they won't change anything to QEMU (at best). The currently used version of OpenBIOS isn't the latest (SVN 1046), I may need to do some cleanup. (...and sorry for the previous message's bad formatting)

2 1

Re : [PATCH 0/8] RFC: OFMEM cleanup/memory reduction patch
by Olivier DANET 14 Apr '12

14 Apr '12

> The problem is currently OpenBIOS won't work on a bare metal, since > it's tightly coupled with qemu. So, PROM size at this point is a > purely academical question. I'm involved in a project where OpenBIOS for Sparc32 is actually used on bare metal (in a FPGA). OpenBIOS is installed in a 16MB NOR FLASH. There are a few QEMU dependencies and some small issues which don't appear in QEMU (for example, the MMU activation sequence does not work IRL, there is a small bug in wuf.S ...). Regards, and thank you all for your hard work ! Olivier

2 1

Re: [OpenBIOS] [PATCH 0/8] RFC: OFMEM cleanup/memory reduction patch
by Mark Cave-Ayland 14 Apr '12

14 Apr '12

On 10/04/12 18:41, Blue Swirl wrote: > Yes, but again, image size savings are not very interesting. Savings > in image loading time is easily lost during decompression. Well, the use case I'm considering at the moment is that if you build OpenBIOS SPARC32 with -O0 -g and then try to load it into QEMU, QEMU reports that the image is too large. So I'm guessing this is a limitation of the memory layout of the machine, rather than the space occupied by the binary. >> Secondly, if we're copying the data to an OFMEM-allocated area then why >> don't we just compress it at build time and then decompress it during the >> copy using DEFLATE (see my previous email)? Then we can further reduce the >> dictionary payload size from ~180K to around ~37K, although as you rightly >> point out there could be a small delay on startup - given the small size >> involved (and the fact we can lock the TLB entry like we do with the Forth >> machine), I don't think the penalty will be too bad. > > But only the decompressed result is what matters wrt memory usage, > isn't it? After Forth has started, there shouldn't be any difference > in RAM use, except that the decompressor code takes more space. Again for the use case above, this would not be a problem if we were to decompress and relocate the dictionary into RAM. >> I'm fairly confident I can come up with an experimental patch for this - >> would people mind if we added zlib as a build-time dependency, and puff.c to >> the OpenBIOS codebase? At the very least, if the decompression appears too >> expensive the first stage on its own would still be a good idea. > > For maximum compression, bzImage (still remember those?) style > approach could be used for whole image. I can't say I've ever looked at that. But if you're happy to at least consider a patch, then I'd like to invest some time looking at this. ATB, Mark.

2 1

Re: [OpenBIOS] Regression in booting HelenOS/sparc64
by Artyom Tarasenko 14 Apr '12

14 Apr '12

git checkout cb437e48 On 4/14/12, Artyom Tarasenko <atar4qemu(a)gmail.com> wrote: > Sorry for the top-posting, that's the only option Gmail offers for my > smartphone. > > I used the commit before the one to which there was a repairing commit > with comment "we lost OR'ing" from Blue and Jan. > > HTH, > Artyom > > > > > On 4/13/12, Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> wrote: >> On 12/04/12 18:54, Artyom Tarasenko wrote: >> >>> As of today qemu git/master and OpenBIOS/trunk can't boot >>> HelenOS-0.4.3-sparc64-ultra.iso . >>> >>> $ sparc64-softmmu/qemu-system-sparc64 -m 512 -boot d -cdrom >>> /mnt/terra/projects/sparc-images/HelenOS-0.4.3-sparc64-ultra.iso -bios >>> openbios-sparc64-trunk >>> Unassigned mem access to 000001ff00700000 from 000000000041c00c >>> ^^^Booting stops here >>> >>> It looks like the regression is coming form the OpenBIOS, because >>> older qemu versions can boot HelenOS with older OpenBIOS, but not with >>> trunk. Can't check other way around because current qemu doesn't start >>> with older OpenBIOS at all. >> >> Hmmm it's going to take a while to bisect something like this :/ Do you >> at least have a last known good combination (QEMU git commit/OpenBIOS >> SVN revision) to start working from? >> >> >> ATB, >> >> Mark. >> >> -- >> OpenBIOS http://openbios.org/ >> Mailinglist: http://lists.openbios.org/mailman/listinfo >> Free your System - May the Forth be with you >> > > > -- > Regards, > Artyom Tarasenko > > solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu > -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu

1 0

Re: [OpenBIOS] Regression in booting HelenOS/sparc64
by Mark Cave-Ayland 14 Apr '12

14 Apr '12

On 12/04/12 18:54, Artyom Tarasenko wrote: > As of today qemu git/master and OpenBIOS/trunk can't boot > HelenOS-0.4.3-sparc64-ultra.iso . > > $ sparc64-softmmu/qemu-system-sparc64 -m 512 -boot d -cdrom > /mnt/terra/projects/sparc-images/HelenOS-0.4.3-sparc64-ultra.iso -bios > openbios-sparc64-trunk > Unassigned mem access to 000001ff00700000 from 000000000041c00c > ^^^Booting stops here > > It looks like the regression is coming form the OpenBIOS, because > older qemu versions can boot HelenOS with older OpenBIOS, but not with > trunk. Can't check other way around because current qemu doesn't start > with older OpenBIOS at all. Hmmm it's going to take a while to bisect something like this :/ Do you at least have a last known good combination (QEMU git commit/OpenBIOS SVN revision) to start working from? ATB, Mark.

2 1

OT: Brooktree IC used in cg3 graphics framebuffer?
by Mark Cave-Ayland 13 Apr '12

13 Apr '12

Hi all, A slightly off-topic question, however there may be some people on the list who will know the answer to this: what was the number of the Brooktree IC used on the cg3 framebuffer? According to various sources, it looks like the BT458 was used on the cg6 - is this the same as the cg3? ATB, Mark.

5 8

Re: [OpenBIOS] [PATCH 1/8] Rename ofmem_arch_early_map_pages() to ofmem_arch_map_pages().
by Mark Cave-Ayland 13 Apr '12

13 Apr '12

On 10/04/12 18:45, Igor Kovalenko wrote: >> Well, it's more interesting than that. For SPARC, when you map the memory it >> is first added to the translation_t linked list. The TLB miss handlers >> simply iterate over this list in order to find the mapping before >> continuing. Therefore when creating a mapping, since the translation_t list >> already contains the entry created by ofmem_map_page_range(), all the >> ofmem_arch_map_pages() function has to do is update any existing TLB >> entries. >> > > The "early" variant was intended to perform one-time injection of > mapped pages that were acquired before c source code is entered so it > was not safe to call common mapping routine yet. I was afraid to > implement mapping code in assembly. I think I see this now. Okay - I think it would be possible to either merge this into the existing OFMEM code or refactor it to make use of the existing functions. It looks like I definitely need to produce a v2 of this patch, so I won't commit it so far and submit a revised version shortly. Many thanks, Mark.

1 0

Regression in booting HelenOS/sparc64
by Artyom Tarasenko 12 Apr '12

12 Apr '12

As of today qemu git/master and OpenBIOS/trunk can't boot HelenOS-0.4.3-sparc64-ultra.iso . $ sparc64-softmmu/qemu-system-sparc64 -m 512 -boot d -cdrom /mnt/terra/projects/sparc-images/HelenOS-0.4.3-sparc64-ultra.iso -bios openbios-sparc64-trunk Unassigned mem access to 000001ff00700000 from 000000000041c00c ^^^Booting stops here It looks like the regression is coming form the OpenBIOS, because older qemu versions can boot HelenOS with older OpenBIOS, but not with trunk. Can't check other way around because current qemu doesn't start with older OpenBIOS at all. -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu

1 0

Re: [OpenBIOS] [PATCH 0/8] RFC: OFMEM cleanup/memory reduction patch
by Tarl Neustaedter 10 Apr '12

10 Apr '12

On 2012-Apr-10 14:53 , Artyom Tarasenko wrote: > The problem is currently OpenBIOS won't work on a bare metal, since > it's tightly coupled with qemu. So, PROM size at this point is a > purely academical question. Gotcha. I thought there was some ability to run on bare metal, in which case prom limitations might have had meaning. > So, basically, if OpenBIOS has to support FCode "dropin" images, it > must support the compression type (s?) used in OBP? Only if you want to "borrow" dropins from an existing Openboot image. It's straight "/usr/bin/compress" used to compress them. I mentioned it only to let you know that we did have to resort to such methods to fit our proms :-)

1 0

Re: [OpenBIOS] [PATCH 0/8] RFC: OFMEM cleanup/memory reduction patch
by Tarl Neustaedter 10 Apr '12

10 Apr '12

On 2012-Apr-10 13:41 , Blue Swirl wrote: > Yes, but again, image size savings are not very interesting. Savings > in image loading time is easily lost during decompression. > Why do you think image size saving aren't interesting? Certainly in the past couple of decades of Openboot development, we've several times been severely squeezed by prom sizes - in some cases, we had to rip out functionality to be able to fit in our PROM. For what it's worth, Openboot currently compresses the "dropin" images (FCode standalone images for devices) before assembling them into the PROM image, and decompresses those when they are brought in with find-dropin.

3 2

[PATCH 0/8] RFC: OFMEM cleanup/memory reduction patch
by Mark Cave-Ayland 10 Apr '12

10 Apr '12

This patchset aims to tidy up various parts of OFMEM, with the ultimate aim of reducing the image sizes. The first 4 patches perform the reorganisation, while the remainder of the patches ensure that video memory and the Forth machine memory are no longer contained within the image. Note: the resulting SPARC64 image is now approximately half of its original size - BUT because we require 512K alignment for various parts of the image because of the 512K MMU page size, our ability to claim this space back directly is limited. Any further ideas on this would be welcomed. Mark Cave-Ayland (8): Rename ofmem_arch_early_map_pages() to ofmem_arch_map_pages(). SPARC32: Move ofmem_arch_map_pages() into ofmem_sparc32.c with all the other architecture-specific code. SPARC64: Refactor tte-data code in preparation for moving architecture-specific code to ofmem_sparc64.c. SPARC64: Move ofmem_arch_map_pages()/ofmem_arch_unmap_pages() into ofmem_sparc64.c with all the other architecture-specific code. Remove architecture-specific routines from ofmem.h. SPARC64: Remove video initialisation hack. SPARC64: Swap Forth machine memory allocation over to OFMEM memory pool. SPARC32: Swap Forth machine memory allocation over to OFMEM memory pool. openbios-devel/arch/ppc/ofmem.c | 2 +- openbios-devel/arch/ppc/qemu/ofmem.c | 6 +- openbios-devel/arch/sparc32/lib.c | 95 +--------- openbios-devel/arch/sparc32/ofmem_sparc32.c | 82 ++++++++- openbios-devel/arch/sparc32/openbios.c | 27 ++- openbios-devel/arch/sparc64/ldscript | 6 - openbios-devel/arch/sparc64/lib.c | 210 ++------------------ openbios-devel/arch/sparc64/ofmem_sparc64.c | 176 ++++++++++++++++- openbios-devel/arch/sparc64/ofmem_sparc64.h | 32 --- openbios-devel/arch/sparc64/openbios.c | 30 ++- openbios-devel/drivers/iommu.c | 4 +- openbios-devel/drivers/vga_vbe.c | 9 +- .../include/arch/sparc32/ofmem_sparc32.h | 28 +++ openbios-devel/include/arch/sparc64/io.h | 2 +- .../include/arch/sparc64/ofmem_sparc64.h | 50 +++++ openbios-devel/include/libopenbios/ofmem.h | 22 +-- openbios-devel/libopenbios/ofmem_common.c | 6 +- openbios-devel/packages/video.c | 4 +- 18 files changed, 405 insertions(+), 386 deletions(-) delete mode 100644 openbios-devel/arch/sparc64/ofmem_sparc64.h create mode 100644 openbios-devel/include/arch/sparc32/ofmem_sparc32.h create mode 100644 openbios-devel/include/arch/sparc64/ofmem_sparc64.h -- 1.7.2.5

4 12

Re: [OpenBIOS] [PATCH 0/8] RFC: OFMEM cleanup/memory reduction patch
by Mark Cave-Ayland 10 Apr '12

10 Apr '12

On 10/04/12 17:43, Blue Swirl wrote: >> Then we can dramatically reduce the dictionary usage within the file too. I >> wonder if we could incorporate a simple decompressor based upon something >> like pdlzip (http://lzip.nongnu.org/pdlzip.html) to perform LZMA >> decompression/relocation on the dictionary early within the startup process? > > ROM image size is not very interesting, but CPU cycles wasted at > startup are. I think run time memory needs would not be changed by > compression, the dictionary needs to be uncompressed to memory anyway > before it can be used. > > But we could avoid copying the dictionary when copying ROM to RAM > initially. Then the dictionary could be copied to OFMEM allocated area > before Forth start. Some large arrays (FSYS_BUF, dstack, rstack etc.) > could also be allocated before use. Would this help? Yes - perhaps I haven't explained this particularly clearly. I'm thinking of a 2 stage strategy - the first stage is to copy the dictionary to an OFMEM-allocated area on startup. This will save space because at the moment the entire dictionary (including space for all the definitions used by various bootloaders) is within the OpenBIOS image, which is currently 512K in the case of SPARC64. Hence we would only need ~180K within the image rather than 512K for this. Secondly, if we're copying the data to an OFMEM-allocated area then why don't we just compress it at build time and then decompress it during the copy using DEFLATE (see my previous email)? Then we can further reduce the dictionary payload size from ~180K to around ~37K, although as you rightly point out there could be a small delay on startup - given the small size involved (and the fact we can lock the TLB entry like we do with the Forth machine), I don't think the penalty will be too bad. I'm fairly confident I can come up with an experimental patch for this - would people mind if we added zlib as a build-time dependency, and puff.c to the OpenBIOS codebase? At the very least, if the decompression appears too expensive the first stage on its own would still be a good idea. ATB, Mark.

2 1

Re: [OpenBIOS] [PATCH 0/8] RFC: OFMEM cleanup/memory reduction patch
by Mark Cave-Ayland 10 Apr '12

10 Apr '12

On 07/04/12 12:09, Blue Swirl wrote: >> This patchset aims to tidy up various parts of OFMEM, with the ultimate aim >> of reducing the image sizes. The first 4 patches perform the reorganisation, >> while the remainder of the patches ensure that video memory and the Forth >> machine memory are no longer contained within the image. > > Patches look OK. Coding style could be adjusted while moving the code > and 'extern' is not useful in C for function prototypes. Okay great :) I know you've mentioned the extern in the past, however I'd like to focus on making the API more consistent first and then do a prototype clear-up once all of that is in place. >> Note: the resulting SPARC64 image is now approximately half of its original >> size - BUT because we require 512K alignment for various parts of the image >> because of the 512K MMU page size, our ability to claim this space back >> directly is limited. Any further ideas on this would be welcomed. > > At least FSYS_BUF in grubfs could be dynamically allocated and/or > shrunk, maybe some others also from this list: > $ nm --size --size-sort obj-sparc64/openbios-builtin.elf.nostrip | > egrep -v ' [tTrR] ' | tail > 0000000000000100 b dp2.1303 > 0000000000000100 b file_descriptors > 0000000000000100 b obio_cmdline > 0000000000000118 d main_ctx > 0000000000001000 B dstack > 0000000000001000 B rstack > 0000000000004000 b image_stack > 0000000000008000 B FSYS_BUF > 0000000000080000 d forth_dictionary > 00000000000c0000 b s_ofmem_data > > It wouldn't help here, but sections .text and .rodata could be merged, > GCC already assumes that .text is readable. This would save one TLB > entry since combined size is still< 512k. With my patchset applied, SPARC64 now looks like this: $ nm --size --size-sort obj-sparc64/openbios-builtin.elf.nostrip | egrep -v ' [tTrR] ' | tail 0000000000000100 b dp2.1302 0000000000000100 b file_descriptors 0000000000000100 b obio_cmdline 0000000000000118 d main_ctx 0000000000001000 B dstack 0000000000001000 B rstack 0000000000004000 b image_stack 0000000000008000 B FSYS_BUF 0000000000020000 b s_ofmem_data 0000000000080000 d forth_dictionary So by reducing s_ofmem_data, the main component is now the size of the Forth dictionary. Hmmm I've had an idea though - we could compress the dictionary, and then decompress/relocate into another set of OFMEM-allocated memory in a similar way so that the entire dictionary doesn't have to be part of the image. For example: $ ls -l obj-sparc64/openbios-sparc64.dict -rw-r--r-- 1 build build 181560 Apr 10 15:08 obj-sparc64/openbios-sparc64.dict Now we need to allocate 512K in total within the image in order to allow for new entries created by bootloaders etc. If we compress the image aswell, e.g. using gzip: $ ls -l obj-sparc64/openbios-sparc64.dict.gz -rw-r--r-- 1 build build 37933 Apr 10 15:08 obj-sparc64/openbios-sparc64.dict.gz Then we can dramatically reduce the dictionary usage within the file too. I wonder if we could incorporate a simple decompressor based upon something like pdlzip (http://lzip.nongnu.org/pdlzip.html) to perform LZMA decompression/relocation on the dictionary early within the startup process? ATB, Mark.

2 2

OT: Brooktree IC used in cg3 graphics framebuffer?
by Mark Cave-Ayland 10 Apr '12

10 Apr '12

Hi all, A slightly off-topic question, however there may be some people on the list who will know the answer to this: what was the number of the Brooktree IC used on the cg3 framebuffer? According to various sources, it looks like the BT458 was used on the cg6 - is this the same as the cg3? ATB, Mark.

1 0

Re: [OpenBIOS] sun4u interrupt-map
by Tarl Neustaedter 09 Apr '12

09 Apr '12

On 2012-Apr-5 17:37 , Artyom Tarasenko wrote: > I gave the following shot: > > 0> show-devs > ffe1a2b0 / > ( ... ) > ffe29140 /pci@1fe,0 (pci) > ffe299a8 /pci@1fe,0/pci@1 (pci) > ffe2a060 /pci@1fe,0/pci@1,1 (pci) > ffe2aeb8 /pci@1fe,0/ebus@3 > ffe2bb00 /pci@1fe,0/ebus@3/su@0,1 (serial) > ( ... ) > > ok > cd /pci@1fe,0/ebus > 000001fe encode-int 020003f8 encode-int encode+ 1 encode-int encode+ > ffe29140 encode-int encode+ 2b encode-int encode+ " interrupt-map" property > > 0000001f encode-int 00ffffff encode-int encode+ 00000003 encode-int encode+ > " interrupt-map-mask" property > > cd /pci@1fe,0/ebus@3/su > 1 encode-int " interrupts" property > device-end > > And Linux's of_device_64 interprets it the following way: > > /pci@1f,0: direct translate 7f0 --> 1 > /pci@1f,0: direct translate 7ee --> 1 > /pci@1f,0: direct translate 7ef --> 1 > /pci@1f,0: direct translate 7e5 --> 1 > > ^^^^^ This is strange but is the same regardless my interrupt-map try above. > > /pci@1f,0/ebus@3/su@1fe,20003f8: Apply [/pci@1f,0/ebus@3:1] imap --> [NULL:1] > > ^^^^^ Have I done something wrong, or more interrupt mappings is needed? Well, it looks like Linux is correctly identifying that you want to translate interrupt 1 from ebus to something else. That something else is where it's getting hung up - what are your #address-cells and #interrupt-cells? Although I don't think you're using the right numbers.... It looks like you set up a property containing: 1fe, 200.03f8, 1, ffe2.9140, 2b The two cells at the front look wrong. I think you want the contents of the reg property of the su node, and I'm pretty sure that doesn't have "1fe". I recall ebus only has a one-cell address property, in which case that should be: 20003f8, 1, ffe2.9140, 2b The interrupt mask property should probably be 00ff.ffff, ff .

2 1

Re: [OpenBIOS] sun4u interrupt-map
by Tarl Neustaedter 05 Apr '12

05 Apr '12

On 2012-Apr-4 18:15 , Artyom Tarasenko wrote: >> > Evidently on the Ultra-5, we aren't using three cells to identify the child, >> > only two. So we probably skip child.mid in both of the above specifications. > And what are child.hi and child.lo? Is it the physical address, stored > in the reg property? Yes. It's bus-binding specific. I don't remember what the parent bus of the PCI node was on an Ultra-5, but presumably <3c,0> indicates the PCI root complex. It should be from the reg property of that same PCI node. > But then the filter (address& 0x3e) == 0x3c can potentially hit > really a lot of devices? In this case, the mask of 0x3e (0011.1110) presumably indicates there are only five meaningful bits in the child address that should be used for comparison. Interestingly, by having a zero in the intrspec field, presumably it only allows one interrupt (zero) to be mapped in this case.

2 1

[PATCH] Support any build directory
by Kristen Eisenberg 05 Apr '12

05 Apr '12

On Sat, Sep 3, 2011 at 10:58 AM, Andreas Färber <andreas.faerber at web.de> wrote: > Am 28.08.2011 um 17:28 schrieb Blue Swirl: > >> Detect source path from switch-arch call path. Always use absolute >> paths. Fix bootstrap.c so that for absolute paths, in addition to >> include directives (-I), the bare path is checked. Kristen Eisenberg Billige Flüge Marketing GmbH Emanuelstr. 3, 10317 Berlin Deutschland Telefon: +49 (33) 5310967 Email: utebachmeier at gmail.com Site: http://flug.airego.de - Billige Flüge vergleichen

1 0

Re: [OpenBIOS] sun4u interrupt-map
by Tarl Neustaedter 05 Apr '12

05 Apr '12

On 2012-Apr-4 13:30 , Artyom Tarasenko wrote: > Could it be that OpenBIOS is missing interrupt-map and > interrupt-map-mask properties for the PCI bus? > > On a real Ultra-5 it looks like this: > interrupt-map 0000003c 00000000 00000000 f005fa24 80000033 > interrupt-map-mask 0000003e 00000000 00000000 > > What is mapped to what? > > I couldn't find any documentation how these properties work, except > for Linux and OpenSolaris sources. Thought I ask here before trying to > reconstruct the picture from them. These are documented at least as far back as the Safari binding, in section 5.2.1.4 (assuming that spec got published). They are used to route interrupts differently than the data interconnects for devices - specifically, when hardware has taken the interrupt pins from a device and brought them in to the CPU through a path which bypasses all the intervening bridges. The specification for interrupt-map is: child.hi child.mid child.lo child.intrspec intr-parent.phandle intr-parent.intrspec Basically, it defines the child, the child's interrupt then points to the parent where the interrupt appears and what interrupt it appears as. In the above Ultra-5 spec, it looks like the first three cells are defining the child (3c?), and the interrupt from that child (presumably zero), saying that this interrupt appears under node f005fa24 as interrupt 33. The interrupt-map-mask is simply a mask applied to the child information it's defined as child.hi child.mid child.lo child.intrspec Evidently on the Ultra-5, we aren't using three cells to identify the child, only two. So we probably skip child.mid in both of the above specifications.

3 2

Re: [OpenBIOS] sun4u interrupt-map
by Blue Swirl 04 Apr '12

04 Apr '12

On Wed, Apr 4, 2012 at 20:15, Artyom Tarasenko <atar4qemu(a)gmail.com> wrote: > On Wed, Apr 4, 2012 at 9:58 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote: >> On Wed, Apr 4, 2012 at 17:59, Tarl Neustaedter <tarl-b2(a)tarl.net> wrote: >>> On 2012-Apr-4 13:30 , Artyom Tarasenko wrote: >>>> >>>> Could it be that OpenBIOS is missing interrupt-map and >>>> interrupt-map-mask properties for the PCI bus? >>>> >>>> On a real Ultra-5 it looks like this: >>>> interrupt-map 0000003c 00000000 00000000 f005fa24 80000033 >>>> interrupt-map-mask 0000003e 00000000 00000000 >>>> >>>> What is mapped to what? >>>> >>>> I couldn't find any documentation how these properties work, except >>>> for Linux and OpenSolaris sources. Thought I ask here before trying to >>>> reconstruct the picture from them. >>> >>> >>> These are documented at least as far back as the Safari binding, in section >>> 5.2.1.4 (assuming that spec got published). They are used to route >>> interrupts differently than the data interconnects for devices - >>> specifically, when hardware has taken the interrupt pins from a device and >>> brought them in to the CPU through a path which bypasses all the intervening >>> bridges. The specification for interrupt-map is: >>> >>> child.hi child.mid child.lo child.intrspec intr-parent.phandle >>> intr-parent.intrspec >>> >>> Basically, it defines the child, the child's interrupt then points to the >>> parent where the interrupt appears and what interrupt it appears as. In the >>> above Ultra-5 spec, it looks like the first three cells are defining the >>> child (3c?), and the interrupt from that child (presumably zero), saying >>> that this interrupt appears under node f005fa24 as interrupt 33. > > So, basically, without these properties, software would have no way to > tell what CPU interrupt is pulled when the device irq becomes active, > right? > >>> The interrupt-map-mask is simply a mask applied to the child information >>> it's defined as >>> >>> child.hi child.mid child.lo child.intrspec >>> >>> Evidently on the Ultra-5, we aren't using three cells to identify the child, >>> only two. So we probably skip child.mid in both of the above specifications. >> >> Nice explanation. I read the Open Firmware draft interrupt mapping >> document (http://www.openfirmware.org/1275/practice/imap/imap0_9d.pdf), >> but I was more confused after reading it than before. > > Hm. Since it's a part of a standard specification, the other machines > (i.e. PPC) might need these properties as well? Probably. There used to be PPC OF device tree dumps in this site but it's no longer there: http://penguinppc.org/historical/dev-trees-html/ > > Artyom > > -- > Regards, > Artyom Tarasenko > > solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu > > -- > OpenBIOS http://openbios.org/ > Mailinglist: http://lists.openbios.org/mailman/listinfo > Free your System - May the Forth be with you

1 0

Re: [OpenBIOS] sun4u interrupt-map
by Tarl Neustaedter 04 Apr '12

04 Apr '12

On 2012-Apr-4 16:15 , Artyom Tarasenko wrote: > So, basically, without these properties, software would have no way to > tell what CPU interrupt is pulled when the device irq becomes active, > right? That's correct. The normal, default, cases work fine - where the interrupts are routed along the same paths as the data. These properties let us work around the cases where hardware engineers decided to wire things differently. >> >> > >> > Nice explanation. I read the Open Firmware draft interrupt mapping >> > document (http://www.openfirmware.org/1275/practice/imap/imap0_9d.pdf), >> > but I was more confused after reading it than before. > Hm. Since it's a part of a standard specification, the other machines > (i.e. PPC) might need these properties as well? Only if they have hardware where interrupts are routed in strange ways. This originally came about when we wanted separate interrupts for a bunch of small devices which were all connected through the same bridge - and normal behaviour would have muxed several of these interrupts onto overlapping A/B/C/D interrupt lines. By routing the interrupts directly into pins giving us unique interrupts, we avoided having OS software having to poll each of several devices on every interrupt. Note that these interrupt properties aren't actually used by Openboot - they're just passed along to make life easier on Solaris (and other clients).

1 0

Re: [OpenBIOS] sun4u interrupt-map
by Artyom Tarasenko 04 Apr '12

04 Apr '12

On Wed, Apr 4, 2012 at 9:58 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote: > On Wed, Apr 4, 2012 at 17:59, Tarl Neustaedter <tarl-b2(a)tarl.net> wrote: >> On 2012-Apr-4 13:30 , Artyom Tarasenko wrote: >>> >>> Could it be that OpenBIOS is missing interrupt-map and >>> interrupt-map-mask properties for the PCI bus? >>> >>> On a real Ultra-5 it looks like this: >>> interrupt-map 0000003c 00000000 00000000 f005fa24 80000033 >>> interrupt-map-mask 0000003e 00000000 00000000 >>> >>> What is mapped to what? >>> >>> I couldn't find any documentation how these properties work, except >>> for Linux and OpenSolaris sources. Thought I ask here before trying to >>> reconstruct the picture from them. >> >> >> These are documented at least as far back as the Safari binding, in section >> 5.2.1.4 (assuming that spec got published). They are used to route >> interrupts differently than the data interconnects for devices - >> specifically, when hardware has taken the interrupt pins from a device and >> brought them in to the CPU through a path which bypasses all the intervening >> bridges. The specification for interrupt-map is: >> >> child.hi child.mid child.lo child.intrspec intr-parent.phandle >> intr-parent.intrspec >> >> Basically, it defines the child, the child's interrupt then points to the >> parent where the interrupt appears and what interrupt it appears as. In the >> above Ultra-5 spec, it looks like the first three cells are defining the >> child (3c?), and the interrupt from that child (presumably zero), saying >> that this interrupt appears under node f005fa24 as interrupt 33. So, basically, without these properties, software would have no way to tell what CPU interrupt is pulled when the device irq becomes active, right? >> The interrupt-map-mask is simply a mask applied to the child information >> it's defined as >> >> child.hi child.mid child.lo child.intrspec >> >> Evidently on the Ultra-5, we aren't using three cells to identify the child, >> only two. So we probably skip child.mid in both of the above specifications. > > Nice explanation. I read the Open Firmware draft interrupt mapping > document (http://www.openfirmware.org/1275/practice/imap/imap0_9d.pdf), > but I was more confused after reading it than before. Hm. Since it's a part of a standard specification, the other machines (i.e. PPC) might need these properties as well? Artyom -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu

1 0

sun4u interrupt-map
by Artyom Tarasenko 04 Apr '12

04 Apr '12

Could it be that OpenBIOS is missing interrupt-map and interrupt-map-mask properties for the PCI bus? On a real Ultra-5 it looks like this: interrupt-map 0000003c 00000000 00000000 f005fa24 80000033 interrupt-map-mask 0000003e 00000000 00000000 What is mapped to what? I couldn't find any documentation how these properties work, except for Linux and OpenSolaris sources. Thought I ask here before trying to reconstruct the picture from them. Artyom -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu

1 0

Re: [OpenBIOS] [Qemu-devel] [Bug 965133] [NEW] Sparc64 crash on start
by Blue Swirl 29 Mar '12

29 Mar '12

On Mon, Mar 26, 2012 at 10:27, Tiziano Vecchi <t.vecchi(a)softjam.it> wrote: > Public bug reported: > > qemu version 1.0.1 compiled on a Ubuntu live on a HP laptop win a x64 > architecture. > > With more than 4G of memory sparc64 machine crash on start. > > command line: qemu-system-sparc64 -m 4G > > output: > VNC server running on `127.0.0.1:5900' > qemu: fatal: Trap 0x0064 while trap level (5) >= MAXTL (5), Error state > pc: 00000000ffd04c80 npc: 00000000ffd04c84 > General Registers: > %g0-3: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > %g4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > > Current Register Window: > %o0-3: 00000000ffd00000 0000000000080000 0000000000080000 0000000000000000 > %o4-7: 0000000000000000 0000000000000000 00000000fff754e1 00000000ffd144d4 > %l0-3: 0000000100000000 00000000fff75c4d 0000000000000000 0000000000000000 > %l4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > %i0-3: 0000000000000000 0000000000000000 0000000100000000 0000000000000036 > %i4-7: 00000000ffe87418 00000000ffe87648 00000000fff75591 00000000ffd0bf54 > > Floating Point Registers: > %f00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > %f08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > %f16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > %f24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > %f32: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > %f40: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > %f48: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > %f56: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > pstate: 00000414 ccr: 99 (icc: N--C xcc: N--C) asi: 00 tl: 5 pil: 0 > cansave: 5 canrestore: 1 otherwin: 0 wstate: 0 cleanwin: 6 cwp: 3 > fsr: 0000000000000000 y: 0000000000000000 fprs: 0000000000000000 > Aborted (core dumped) This is actually a bug in OpenBIOS. It is mapped at 0xffd00000 (below 4G) for compatibility with 32 bit code, but the code does not handle this case where top of RAM overlaps OpenBIOS. > > ** Affects: qemu > Importance: Undecided > Status: New > > -- > You received this bug notification because you are a member of qemu- > devel-ml, which is subscribed to QEMU. > https://bugs.launchpad.net/bugs/965133 > > Title: > Sparc64 crash on start > > Status in QEMU: > New > > Bug description: > qemu version 1.0.1 compiled on a Ubuntu live on a HP laptop win a x64 > architecture. > > With more than 4G of memory sparc64 machine crash on start. > > command line: qemu-system-sparc64 -m 4G > > output: > VNC server running on `127.0.0.1:5900' > qemu: fatal: Trap 0x0064 while trap level (5) >= MAXTL (5), Error state > pc: 00000000ffd04c80 npc: 00000000ffd04c84 > General Registers: > %g0-3: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > %g4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > > Current Register Window: > %o0-3: 00000000ffd00000 0000000000080000 0000000000080000 0000000000000000 > %o4-7: 0000000000000000 0000000000000000 00000000fff754e1 00000000ffd144d4 > %l0-3: 0000000100000000 00000000fff75c4d 0000000000000000 0000000000000000 > %l4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > %i0-3: 0000000000000000 0000000000000000 0000000100000000 0000000000000036 > %i4-7: 00000000ffe87418 00000000ffe87648 00000000fff75591 00000000ffd0bf54 > > Floating Point Registers: > %f00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > %f08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > %f16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > %f24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > %f32: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > %f40: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > %f48: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > %f56: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > pstate: 00000414 ccr: 99 (icc: N--C xcc: N--C) asi: 00 tl: 5 pil: 0 > cansave: 5 canrestore: 1 otherwin: 0 wstate: 0 cleanwin: 6 cwp: 3 > fsr: 0000000000000000 y: 0000000000000000 fprs: 0000000000000000 > Aborted (core dumped) > > To manage notifications about this bug go to: > https://bugs.launchpad.net/qemu/+bug/965133/+subscriptions >

1 0

Re: [OpenBIOS] Adding to a definition
by Programmingkid 29 Mar '12

29 Mar '12

> On 2012-Mar-22 00:09 , Programmingkid wrote: > > Is there a way to add words to the end of a definition? If my word is declared like this: > > > > : myword > > firstWord > > secondWord > > ; > > > > is there a way to append a word to the end of this word so it looks like this: > > > > : myword > > firstWord > > secondWord > > thirdWord > > ; > > The usual way I'd do something like that if I had to patch a live system > would be as follows: > > ok : anotherWord secondWord thirdWord ; > ok patch anotherWord secondWord myword > ok The patch word is an empty definition in OpenBIOS. What is it suppose to do?

2 1

Re: [OpenBIOS] SPARC64 device tree model - SBUS or PCI?
by Dave Simonson 18 Mar '12

18 Mar '12

prtconf doesn't give you the same detail as prtpicl, however, especially for PCI bus detail. That was the point of my email. Dave On 3/18/2012 8:52 AM, Blue Swirl wrote: > On Sun, Feb 26, 2012 at 20:15, Dave Simonson<dave(a)mail.simonsontech.net> wrote: >> Here's output from prtpicl -v for an Ultra-10. this might give you the >> detail that you want. It's the best command for hardware detail in Solaris. >> Dave > Dave S. Miller maintains a tree with prtconfs, here's Ultra 5: > http://git.kernel.org/?p=linux/kernel/git/davem/prtconfs.git;a=blob;f=ultra… > >> >> On 2/26/2012 1:22 PM, Mark Cave-Ayland wrote: >> >> On 26/02/12 17:52, Andreas Färber wrote: >> >> Am 26.02.2012 13:13, schrieb Mark Cave-Ayland: >> >> If QEMU is going to continue to >> use a PCI-based system, does anyone have a copy of the prtconf output >> for such a system? >> >> >> Here's prtconf output from my PCI-based SunFire V480: >> >> >> Hi Andreas, >> >> Thanks for this, although it seems to be lacking much detail compared to the >> Linux prtconf output which was very useful with SPARC32 :( Do you have >> access to a Linux installation running on that same hardware at all? For >> example, the output for an Ultra 2 as included in the examples directory of >> the Debian sparc-utils package looks like the attached file. >> >> >> Many thanks, >> >> Mark. >> >> >> >> >> -- >> OpenBIOS http://openbios.org/ >> Mailinglist: http://lists.openbios.org/mailman/listinfo >> Free your System - May the Forth be with you

1 0

SPARC64 device tree model - SBUS or PCI?
by Mark Cave-Ayland 18 Mar '12

18 Mar '12

Hi all, I've been spending some time recently trying to figure out why the SPARC64 serial console doesn't appear to work outside of OpenBIOS under QEMU, and so was looking at the example device trees in the Debian sparc-utils package. Now AFAICT the examples/ultra2 file represents an Ultra 2 SBUS which is different from QEMU which I believe is attempting to emulate an Ultra 2 PCI (Sabre) system. I know there was some talk previously on the mailing list about which device model to use moving forward, but I don't remember a definite decision being made. If QEMU is going to continue to use a PCI-based system, does anyone have a copy of the prtconf output for such a system? ATB, Mark.

5 9

HelenOS regression in QEMU implies OpenBIOS VGA issue
by Mark Cave-Ayland 17 Mar '12

17 Mar '12

Hi all, Whilst looking at Jakub's bug report here https://bugs.launchpad.net/qemu/+bug/942299, I've been working on a patch to correct the QEMU interrupt handler on qemu-ppc. Now that this bug is close to being fixed, I've had a look at OpenBIOS to find out why newer versions of OpenBIOS freeze before the HelenOS loading screen. A local git bisect shows that the culprit is actually this commit: commit b6de01a59394f1fafbfb2c65cb784c9d23067fa2 Author: laurent <laurent@f158a5a8-5612-0410-a976-696ce0be7e32> Date: Tue Aug 4 21:08:37 2009 +0000 Allows to configure screen size from Qemu command line options using FW_CFG interface. Only enabled for PPC/QEMU and VGA/VBE. git-svn-id: svn://openbios.org/openbios/trunk@538 f158a5a8-5612-0410-a976-696ce0be7e32 Having stepped through vga_vbe_init() in drivers/vga_vbe.c, the only difference is that reading the display depth from the QEMU FW CFG interface returns 15 instead of the in-built OpenBIOS default of 8. So is a bit-depth of 15 supported by OpenBIOS? This seems quite unusual given that it is not a power of 2; however if I use GDB to override the value to 16 then HelenOS boots but with a blue screen BIOS on VGA so I'm not sure that is the correct solution either. Does anyone know what the default bit-depth is in Apple's firmware? ATB, Mark.

2 2

[commit] r1048 - in trunk/openbios-devel: arch/sparc64 drivers
by repository service 17 Mar '12

17 Mar '12

Author: blueswirl Date: Sat Mar 17 17:34:21 2012 New Revision: 1048 URL: http://tracker.coreboot.org/trac/openbios/changeset/1048 Log: pci: fix BAR setup A change in QEMU on how PCI bridges are setup revealed a bug in OpenBIOS PCI setup. On Sparc64, the BARs just happened to get somewhat correct values by accident before the commit but not after the change. Don't use arch->io_base for PCI I/O port BARs. Fix Sparc64 PCI memory base. Signed-off-by: Blue Swirl <blauwirbel(a)gmail.com> Modified: trunk/openbios-devel/arch/sparc64/openbios.c trunk/openbios-devel/drivers/pci.c Modified: trunk/openbios-devel/arch/sparc64/openbios.c ============================================================================== --- trunk/openbios-devel/arch/sparc64/openbios.c Sat Aug 20 14:10:07 2011 (r1047) +++ trunk/openbios-devel/arch/sparc64/openbios.c Sat Mar 17 17:34:21 2012 (r1048) @@ -64,7 +64,7 @@ .cfg_base = APB_SPECIAL_BASE, .cfg_len = 0x2000000, .host_mem_base = APB_MEM_BASE, - .pci_mem_base = 0, + .pci_mem_base = 0x100000, /* avoid VGA at 0xa0000 */ .mem_len = 0x10000000, .io_base = APB_SPECIAL_BASE + 0x2000000ULL, // PCI Bus I/O space .io_len = 0x10000, Modified: trunk/openbios-devel/drivers/pci.c ============================================================================== --- trunk/openbios-devel/drivers/pci.c Sat Aug 20 14:10:07 2011 (r1047) +++ trunk/openbios-devel/drivers/pci.c Sat Mar 17 17:34:21 2012 (r1048) @@ -931,6 +931,7 @@ if ((*p_omask & 0x0000000f) == 0x4) { /* 64 bits memory mapping */ + PCI_DPRINTF("Skipping 64 bit BARs for %s\n", config->path); return; } @@ -966,11 +967,17 @@ size = min_align; reloc = (reloc + size -1) & ~(size - 1); if (*io_base == base) { + PCI_DPRINTF("changing io_base from 0x%lx to 0x%x\n", + *io_base, reloc + size); *io_base = reloc + size; - reloc -= arch->io_base; } else { + PCI_DPRINTF("changing mem_base from 0x%lx to 0x%x\n", + *mem_base, reloc + size); *mem_base = reloc + size; } + PCI_DPRINTF("Configuring BARs for %s: reloc 0x%x omask 0x%x " + "io_base 0x%lx mem_base 0x%lx size 0x%x\n", + config->path, reloc, *p_omask, *io_base, *mem_base, size); pci_config_write32(addr, config_addr, reloc | *p_omask); config->assigned[reg] = reloc | *p_omask; } @@ -1260,7 +1267,7 @@ mem_base = arch->pci_mem_base; /* I/O ports under 0x400 are used by devices mapped at fixed location. */ - io_base = arch->io_base + 0x400; + io_base = 0x400; bus = 0;

1 0

[PATCH] pci: fix BAR setup
by Blue Swirl 11 Mar '12

11 Mar '12

A change in QEMU on how PCI bridges are setup revealed a bug in OpenBIOS PCI setup. On Sparc64, the BARs just happened to get somewhat correct values by accident before the commit but not after the change. Don't use arch->io_base for PCI I/O port BARs. Fix Sparc64 PCI memory base. Signed-off-by: Blue Swirl <blauwirbel(a)gmail.com> --- I removed the bridge setup code, it's not really valid for Sparc64 APB bridges anyway and currently no devices exist behind the bridges (but that's where they really should be). Tested Sparc64 and PPC. --- arch/sparc64/openbios.c | 2 +- drivers/pci.c | 11 +++++++++-- 2 files changed, 10 insertions(+), 3 deletions(-) diff --git a/arch/sparc64/openbios.c b/arch/sparc64/openbios.c index ac709fe..ab32a8f 100644 --- a/arch/sparc64/openbios.c +++ b/arch/sparc64/openbios.c @@ -64,7 +64,7 @@ static const struct hwdef hwdefs[] = { .cfg_base = APB_SPECIAL_BASE, .cfg_len = 0x2000000, .host_mem_base = APB_MEM_BASE, - .pci_mem_base = 0, + .pci_mem_base = 0x100000, /* avoid VGA at 0xa0000 */ .mem_len = 0x10000000, .io_base = APB_SPECIAL_BASE + 0x2000000ULL, // PCI Bus I/O space .io_len = 0x10000, diff --git a/drivers/pci.c b/drivers/pci.c index f8c6414..e270a73 100644 --- a/drivers/pci.c +++ b/drivers/pci.c @@ -931,6 +931,7 @@ static void ob_pci_configure_bar(pci_addr addr, pci_config_t *config, if ((*p_omask & 0x0000000f) == 0x4) { /* 64 bits memory mapping */ + PCI_DPRINTF("Skipping 64 bit BARs for %s\n", config->path); return; } @@ -966,11 +967,17 @@ static void ob_pci_configure_bar(pci_addr addr, pci_config_t *config, size = min_align; reloc = (reloc + size -1) & ~(size - 1); if (*io_base == base) { + PCI_DPRINTF("changing io_base from 0x%lx to 0x%x\n", + *io_base, reloc + size); *io_base = reloc + size; - reloc -= arch->io_base; } else { + PCI_DPRINTF("changing mem_base from 0x%lx to 0x%x\n", + *mem_base, reloc + size); *mem_base = reloc + size; } + PCI_DPRINTF("Configuring BARs for %s: reloc 0x%x omask 0x%x " + "io_base 0x%lx mem_base 0x%lx size 0x%x\n", + config->path, reloc, *p_omask, *io_base, *mem_base, size); pci_config_write32(addr, config_addr, reloc | *p_omask); config->assigned[reg] = reloc | *p_omask; } @@ -1260,7 +1267,7 @@ int ob_pci_init(void) mem_base = arch->pci_mem_base; /* I/O ports under 0x400 are used by devices mapped at fixed location. */ - io_base = arch->io_base + 0x400; + io_base = 0x400; bus = 0; -- 1.7.9

1 0

Re: [OpenBIOS] [PATCH] pci: fix BAR setup
by Mark Cave-Ayland 05 Mar '12

05 Mar '12

On 04/03/12 19:55, Blue Swirl wrote: > A change in QEMU on how PCI bridges are setup revealed > a bug in OpenBIOS PCI setup. On Sparc64, the BARs just > happened to get somewhat correct values by accident before > the commit but not after the change. > > Avoid to set up BARs for host bridge. Fix bridge > check, this lead to setting up 6 BARs instead of more > correct 2. If a bridge doesn't have any devices behind it, > disable it entirely. Fix Sparc64 PCI memory base. > > Signed-off-by: Blue Swirl<blauwirbel(a)gmail.com> I confirm that this patch appears to fix the problem for me, although I guess there may be some further related bridge changes based on the current thread with Michael? ATB, Mark.

2 1

Re: [OpenBIOS] [Qemu-ppc] qemu -cpu 7455 doesn't work
by Jörg Sommer 05 Mar '12

05 Mar '12

Blue Swirl hat am Sat 03. Mar, 16:00 (+0000) geschrieben: > On Thu, Mar 1, 2012 at 15:42, Jörg Sommer <joerg(a)alea.gnuu.de> wrote: > > I don't get an Open Firmware prompt with this command: > > > > qemu-system-ppc -M mac99 -cpu 7455 -prom-env 'auto-boot?=false' > > > > With -cpu G4 or 7448 it works. My host CPU is a 7455 and I can't use -cpu > > host with KVM. Is there something broken? > > Boot crashes when MMU is enabled in OpenBIOS > (arch/ppc/qemu/init.c:527, setup_mmu()): > mtmsr(mfmsr() | MSR_IR | MSR_DR); > > I suppose 7455 has a different MMU model compared to 7448 and the > different setup needed has not been implemented in OpenBIOS yet. It also happens when I use -kernel. Is OpenBIOS involved when a kernel gets started directly? # qemu-system-ppc -enable-kvm -M g3beige -cpu 7455 -k de -nographic >> ============================================================= >> OpenBIOS 1.0 [Jan 8 2012 13:43] >> Configuration device id QEMU version 1 machine id 2 >> CPUs: 1 >> Memory: 128M >> UUID: 00000000-0000-0000-0000-000000000000 >> Unknown cpu (pvr 80010000), freezing! QEMU 1.0 monitor - type 'help' for more information (qemu) stop (qemu) info cpus * CPU #0: nip=0x00000000fff09330 thread_id=13276 (qemu) info registers NIP fff09330 LR fff09330 CTR 00000000 XER 00000000 MSR 40000030 HID0 00000000 HF 00000000 idx 1 TB 00000000 00000000 DECR 00000000 GPR00 00000000fff09330 0000000007df7e90 0000000000000000 0000000000000026 GPR04 000000000000000d 0000000000000000 0000000000000000 0000000000000000 GPR08 0000000000000000 0000000000000004 0000000000000000 0000000007df7e90 GPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR20 0000000000000000 00000000fff2ef70 00000000fff2ef5e 00000000fff2eede GPR24 00000000fff2ef66 00000000fffb3630 0000000000000000 0000000000000000 GPR28 00000000fff2e656 00000000fff2f5e5 0000000008000000 00000000fff260e0 CR 42000042 [ G E - - - - G E ] RES ffffffff FPR00 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPSCR 00000000 SRR0 fff24c50 SRR1 40000030 PVR 80010302 VRSAVE 00000000 SPRG0 07e00000 SPRG1 07df7e10 SPRG2 22000042 SPRG3 00000000 SPRG4 00000000 SPRG5 00000000 SPRG6 00000000 SPRG7 00000000 SDR1 07e00000 (qemu) xp /4i 0x00000000fff09328 0xfff09328: addi r3,r3,-5738 0xfff0932c: bl 0xfff086e8 0xfff09330: b 0xfff09330 0xfff09334: lis r3,-13 (qemu) quit > Perhaps you could try? ;-) What should I try? Bye, Jörg. -- „Wer im Usenet gelesen werden will, sollte leserorientiert schreiben. Wer nur für sich schreiben will, dem ist mit einem Tagebuch vielleicht besser geholfen. Gelesen zu werden ist kein Recht, sondern ein Privileg.“ Thore Tams in <90tfv8$49b$1(a)keks.kruemel.dyndns.org>

1 0

[PATCH] pci: fix BAR setup
by Blue Swirl 04 Mar '12

04 Mar '12

A change in QEMU on how PCI bridges are setup revealed a bug in OpenBIOS PCI setup. On Sparc64, the BARs just happened to get somewhat correct values by accident before the commit but not after the change. Avoid to set up BARs for host bridge. Fix bridge check, this lead to setting up 6 BARs instead of more correct 2. If a bridge doesn't have any devices behind it, disable it entirely. Fix Sparc64 PCI memory base. Signed-off-by: Blue Swirl <blauwirbel(a)gmail.com> --- arch/sparc64/openbios.c | 2 +- drivers/pci.c | 67 ++++++++++++++++++++++++++++++++++------------ drivers/pci.h | 7 +++++ 3 files changed, 57 insertions(+), 19 deletions(-) diff --git a/arch/sparc64/openbios.c b/arch/sparc64/openbios.c index ac709fe..a1544a8 100644 --- a/arch/sparc64/openbios.c +++ b/arch/sparc64/openbios.c @@ -64,7 +64,7 @@ static const struct hwdef hwdefs[] = { .cfg_base = APB_SPECIAL_BASE, .cfg_len = 0x2000000, .host_mem_base = APB_MEM_BASE, - .pci_mem_base = 0, + .pci_mem_base = 0x10000000, .mem_len = 0x10000000, .io_base = APB_SPECIAL_BASE + 0x2000000ULL, // PCI Bus I/O space .io_len = 0x10000, diff --git a/drivers/pci.c b/drivers/pci.c index f8c6414..6ed0c03 100644 --- a/drivers/pci.c +++ b/drivers/pci.c @@ -966,11 +966,18 @@ static void ob_pci_configure_bar(pci_addr addr, pci_config_t *config, size = min_align; reloc = (reloc + size -1) & ~(size - 1); if (*io_base == base) { + PCI_DPRINTF("changing io_base from 0x%lx to 0x%x\n", + *io_base, reloc + size); *io_base = reloc + size; reloc -= arch->io_base; } else { + PCI_DPRINTF("changing mem_base from 0x%lx to 0x%x\n", + *mem_base, reloc + size); *mem_base = reloc + size; } + PCI_DPRINTF("Configuring BARs for %s: reloc 0x%x omask 0x%x " + "io_base 0x%lx mem_base 0x%lx\n", + config->path, reloc, *p_omask, *io_base, *mem_base); pci_config_write32(addr, config_addr, reloc | *p_omask); config->assigned[reg] = reloc | *p_omask; } @@ -1021,26 +1028,30 @@ ob_pci_configure(pci_addr addr, pci_config_t *config, int num_regs, int rom_bar, pci_config_write16(addr, PCI_COMMAND, cmd); } -static void ob_configure_pci_device(const char* parent_path, - int *bus_num, unsigned long *mem_base, unsigned long *io_base, - int bus, int devnum, int fn, int *p_is_multi); +static int ob_configure_pci_device(const char* parent_path, + int *bus_num, unsigned long *mem_base, + unsigned long *io_base, int bus, int devnum, + int fn, int *p_is_multi); -static void ob_scan_pci_bus(int *bus_num, unsigned long *mem_base, - unsigned long *io_base, const char *path, - int bus) +static int ob_scan_pci_bus(int *bus_num, unsigned long *mem_base, + unsigned long *io_base, const char *path, + int bus) { - int devnum, fn, is_multi; + int devnum, fn, is_multi, ndevices = 0; PCI_DPRINTF("\nScanning bus %d at %s...\n", bus, path); for (devnum = 0; devnum < 32; devnum++) { is_multi = 0; for (fn = 0; fn==0 || (is_multi && fn<8); fn++) { - ob_configure_pci_device(path, bus_num, mem_base, io_base, - bus, devnum, fn, &is_multi); + ndevices += ob_configure_pci_device(path, bus_num, + mem_base, io_base, + bus, devnum, fn, + &is_multi); } } + return ndevices; } static void ob_configure_pci_bridge(pci_addr addr, @@ -1048,6 +1059,9 @@ static void ob_configure_pci_bridge(pci_addr addr, unsigned long *io_base, int primary_bus, pci_config_t *config) { + int ndevices; + uint8_t command; + config->primary_bus = primary_bus; pci_config_write8(addr, PCI_PRIMARY_BUS, config->primary_bus); @@ -1062,16 +1076,30 @@ static void ob_configure_pci_bridge(pci_addr addr, /* make pci bridge parent device, prepare for recursion */ - ob_scan_pci_bus(bus_num, mem_base, io_base, - config->path, config->secondary_bus); + ndevices = ob_scan_pci_bus(bus_num, mem_base, io_base, + config->path, config->secondary_bus); + if (!ndevices) { + /* no devices, disable bridging */ + PCI_DPRINTF("disabling bridge %s\n", config->path); + command = pci_config_read8(addr, PCI_COMMAND); + command &= ~(PCI_COMMAND_IO | PCI_COMMAND_MEMORY | + PCI_COMMAND_VGA_PALETTE | PCI_COMMAND_MASTER); + pci_config_write8(addr, PCI_COMMAND, command); + pci_config_write8(addr, PCI_IO_BASE, 0); + pci_config_write8(addr, PCI_IO_LIMIT, 0); + pci_config_write8(addr, PCI_MEMORY_BASE, 0); + pci_config_write8(addr, PCI_MEMORY_LIMIT, 0); + return; + } /* bus scan updates *bus_num to last revealed pci bus number */ config->subordinate_bus = *bus_num; pci_config_write8(addr, PCI_SUBORDINATE_BUS, config->subordinate_bus); - PCI_DPRINTF("bridge %s PCI bus primary=%d secondary=%d subordinate=%d\n", - config->path, config->primary_bus, config->secondary_bus, - config->subordinate_bus); + PCI_DPRINTF("bridge %s PCI bus primary=%d secondary=%d subordinate=%d" + " ndev=%d\n", + config->path, config->primary_bus, config->secondary_bus, + config->subordinate_bus, ndevices); pci_set_bus_range(config); } @@ -1117,7 +1145,7 @@ static int ob_pci_read_identification(int bus, int devnum, int fn, return 1; } -static void ob_configure_pci_device(const char* parent_path, +static int ob_configure_pci_device(const char* parent_path, int *bus_num, unsigned long *mem_base, unsigned long *io_base, int bus, int devnum, int fn, int *p_is_multi) { @@ -1133,7 +1161,7 @@ static void ob_configure_pci_device(const char* parent_path, int is_host_bridge = 0; if (!ob_pci_read_identification(bus, devnum, fn, &vid, &did, &class, &subclass)) { - return; + return 0; } addr = PCI_ADDR(bus, devnum, fn); @@ -1195,16 +1223,18 @@ static void ob_configure_pci_device(const char* parent_path, if (get_property(phandle, "vendor-id", NULL)) { PCI_DPRINTF("host bridge already configured\n"); - return; + return 0; } } activate_dev(phandle); - if (htype & PCI_HEADER_TYPE_BRIDGE) { + if (htype & PCI_HEADER_TYPE_BRIDGE || (class == PCI_BASE_CLASS_BRIDGE)) { + PCI_DPRINTF("Bridge 2 bars, htype %x\n", htype); num_bars = 2; rom_bar = PCI_ROM_ADDRESS1; } else { + PCI_DPRINTF("Device 6 bars, htype %x\n", htype); num_bars = 6; rom_bar = PCI_ROM_ADDRESS; } @@ -1240,6 +1270,7 @@ static void ob_configure_pci_device(const char* parent_path, ob_configure_pci_bridge(addr, bus_num, mem_base, io_base, bus, &config); } + return 1; } int ob_pci_init(void) diff --git a/drivers/pci.h b/drivers/pci.h index 0f6ae1f..4314507 100644 --- a/drivers/pci.h +++ b/drivers/pci.h @@ -7,6 +7,8 @@ #define PCI_COMMAND 0x04 #define PCI_COMMAND_IO 0x01 #define PCI_COMMAND_MEMORY 0x02 +#define PCI_COMMAND_MASTER 0x4 /* Enable bus mastering */ +#define PCI_COMMAND_VGA_PALETTE 0x20 /* Enable palette snooping */ #define PCI_STATUS 0x06 /* 16 bits */ #define PCI_STATUS_CAP_LIST 0x10 /* Support Capability List */ @@ -44,6 +46,11 @@ #define PCI_BASE_ADDR_4 0x20 #define PCI_BASE_ADDR_5 0x24 +#define PCI_IO_BASE 0x1c /* I/O range behind the bridge */ +#define PCI_IO_LIMIT 0x1d +#define PCI_MEMORY_BASE 0x20 /* Memory range behind */ +#define PCI_MEMORY_LIMIT 0x22 + #define PCI_SUBSYSTEM_VENDOR_ID 0x2c #define PCI_SUBSYSTEM_ID 0x2e -- 1.7.9

1 0

Re: [OpenBIOS] [Qemu-ppc] qemu -cpu 7455 doesn't work
by Blue Swirl 03 Mar '12

03 Mar '12

On Thu, Mar 1, 2012 at 15:42, Jörg Sommer <joerg(a)alea.gnuu.de> wrote: > Hi, > > I don't get an Open Firmware prompt with this command: > > qemu-system-ppc -M mac99 -cpu 7455 -prom-env 'auto-boot?=false' > > With -cpu G4 or 7448 it works. My host CPU is a 7455 and I can't use -cpu > host with KVM. Is there something broken? Boot crashes when MMU is enabled in OpenBIOS (arch/ppc/qemu/init.c:527, setup_mmu()): mtmsr(mfmsr() | MSR_IR | MSR_DR); I suppose 7455 has a different MMU model compared to 7448 and the different setup needed has not been implemented in OpenBIOS yet. Perhaps you could try? ;-) > % qemu-system-ppc --version > QEMU emulator version 1.0 (Debian 1.0+dfsg-3), Copyright (c) 2003-2008 Fabrice Bellard > % cat /proc/cpuinfo > processor : 0 > cpu : 7455, altivec supported > clock : 606.000000MHz > revision : 3.3 (pvr 8001 0303) > bogomips : 36.86 > timebase : 18432000 > platform : PowerMac > model : PowerBook6,3 > machine : PowerBook6,3 > motherboard : PowerBook6,3 MacRISC3 Power Macintosh > detected as : 287 (iBook G4) > pmac flags : 0000001b > L2 cache : 256K unified > pmac-generation : NewWorld > Memory : 640 MB > > Bye, Jörg. > -- > A valid expression in Java: x = new A().new B();

1 0

building openfirmware
by Programmingkid 27 Feb '12

27 Feb '12

I was wondering if openfirmware could be made easier to build. I suggest that it use the configure-make strategy that most unix programs use. The configure command should be at the top level of the openfirmware folder and would allow the user to set the architecture and other options from there. This change would make things a lot easier for developers since they wouldn't have to hunt for the make file.

1 0

Re: [OpenBIOS] SPARC64 device tree model - SBUS or PCI?
by Artyom Tarasenko 27 Feb '12

27 Feb '12

On 2/26/12, Blue Swirl <blauwirbel(a)gmail.com> wrote: > On Sun, Feb 26, 2012 at 12:13, Mark Cave-Ayland > <mark.cave-ayland(a)ilande.co.uk> wrote: >> Hi all, >> >> I've been spending some time recently trying to figure out why the SPARC64 >> serial console doesn't appear to work outside of OpenBIOS under QEMU, and >> so >> was looking at the example device trees in the Debian sparc-utils package. > > Maybe on the real machine, serial console isn't using the 'su' devices > (PC serial) but 'se' device which does not exist in QEMU? Yes, at least Ultra-5 uses "se" ports for ttya and ttyb. Linux, Solaris and NetBSD are able to handle zs, se and su ports. But since qemu-sparc64 doesn't have a compatible IRQ controller, the serial ports under qemu can be used only in polling mode. Or perhaps via promlib. >> Now AFAICT the examples/ultra2 file represents an Ultra 2 SBUS which is >> different from QEMU which I believe is attempting to emulate an Ultra 2 >> PCI >> (Sabre) system. I know there was some talk previously on the mailing list >> about which device model to use moving forward, but I don't remember a >> definite decision being made. If QEMU is going to continue to use a >> PCI-based system, does anyone have a copy of the prtconf output for such a >> system? > > IIRC we discussed earlier about using Ultra 5 which doesn't have a SBus. > >> ATB, >> >> Mark. -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu

1 0

Re: [OpenBIOS] OpenFirmware Documentation
by Jason Hooper 15 Feb '12

15 Feb '12

Hi, Not trying to pretend I know much about this but you can try http://web.archive.org to find old pages or http://www.openfirmware.org. Good luck! Rob Ballantyne <robballantyne3(a)gmail.com> wrote: >Hello, > > OpenFirmware docs seem to have disappeared from the web since I last >looked at them. > > Apple had a few Tech Notes that were helpful -- those are no longer available. > > Sun, I think, had the actual standard document and supplements -- >playground.sun.com now doesn't seem to be around. > > Is there a new repository for these kinds of docs? > > Thanks, > >Rob > >-- >OpenBIOS http://openbios.org/ >Mailinglist: http://lists.openbios.org/mailman/listinfo >Free your System - May the Forth be with you

1 0

Re: [OpenBIOS] OpenFirmware Documentation
by Mike Erwin 15 Feb '12

15 Feb '12

Oh no! I have a few of those docs stored locally (mostly related to graphics devices), and might be able to dig up some more. The wayback machine at archive.org is one option for the Sun stuff. Loads of information still at firmworks.com and openfirmware.org... what is missing besides the Apple TNs? Mike Erwin musician, naturalist, pixel pusher, hacker extraordinaire On Tue, Feb 14, 2012 at 2:45 PM, Rob Ballantyne <robballantyne3(a)gmail.com> wrote: > Hello, > > OpenFirmware docs seem to have disappeared from the web since I last > looked at them. > > Apple had a few Tech Notes that were helpful -- those are no longer available. > > Sun, I think, had the actual standard document and supplements -- > playground.sun.com now doesn't seem to be around. > > Is there a new repository for these kinds of docs? > > Thanks, > > Rob > > -- > OpenBIOS http://openbios.org/ > Mailinglist: http://lists.openbios.org/mailman/listinfo > Free your System - May the Forth be with you

1 0

OpenFirmware Documentation
by Rob Ballantyne 14 Feb '12

14 Feb '12

Hello, OpenFirmware docs seem to have disappeared from the web since I last looked at them. Apple had a few Tech Notes that were helpful -- those are no longer available. Sun, I think, had the actual standard document and supplements -- playground.sun.com now doesn't seem to be around. Is there a new repository for these kinds of docs? Thanks, Rob

1 0

Could BIOS execute some Lines of code ?
by Mustapha Adib 03 Jan '12

03 Jan '12

Hello everybody, I would like to know if some one could help me to make a BIOS which can : 1- Do a Checksum to (E:) and (F:) partitions and compare result with fixed value that BIOS contains in ROM/EPROM. 2- Show result to user and ask him if he want to copy (F:) to (E:) Partitions with formatting (E:), or just boot normally ?. 3-a- Copy (F:) to (E:) Partitions And then boot on (C:) partition where Linux is already installed. 3-b- Or just boot on (C:) partition where Linux is already installed. E, F and C fixed size partitions of 80 Go each one. Is there any easy tutorial or compressible book to do this ? Thank you very much. Mustapha. VoIP/ToIP project manager.

1 0

Re: [OpenBIOS] Friends are to help each other! Dude, visit this shop!
by Jimmy Pan 22 Nov '11

22 Nov '11

Sorry for the spam here, my email account was stolen. On Mon, Nov 21, 2011 at 11:22 PM, Jimmy Pan <dspjm1(a)gmail.com> wrote: > ...Are you still here? Visit this site right now. This is special for > you! http://jacunart.com.br/p.g.php?uten_yahoo=39t8 >

1 0

OpenBOOT builds?
by Nathan Kunkee 24 Oct '11

24 Oct '11

Hi all, I've checked out the Sun OpenBOOT code they provided, and gotten a little lost. I was curious if anyone else has reviewed or built the firmware? I've found the two key Makefiles: ./obp/arch/sun4v/ontario/release/Makefile ./tools/Makefile I figured out that a 'make' from the latter works on building the tools for constructing the firmware, while the former uses them to build a firmware image. I've gotten stuck trying to build this since it causes a SIGSEGV in libc on my Ultra60. Would anyone else be interested if I start trying to patch it to have debug symbols and use gcc as well as Oracle Solaris Studio (SUNWpro)? Nathan

2 1

How to check if it's a PReP partition
by Paulo Flabiano Smorigo 21 Oct '11

21 Oct '11

Hi, How can I know if a partition is securely a PReP partition? Besides check the partition type (41), is there another test that I can do to confirm that? At the page bellow are two other codes used for the same code of PReP (41): http://www.win.tue.nl/~aeb/partitions/partition_types-1.html 41 Linux/MINIX (sharing disk with DRDOS) 41 Personal RISC Boot 41 PPC PReP (Power PC Reference Platform) Boot What kind of checks can I do? Can I use the partition size or if it's the first of the disk as parameters to check it? Thanks, Paulo Flabiano Smorigo Linux Technology Center Brazil Software Engineer IBM Systems & Technology Group

2 1

Re: [OpenBIOS] Solaris anyone? Solaris 9 04/04
by Nathan Kunkee 12 Sep '11

12 Sep '11

On 09/10/11 01:45 AM, Blue Swirl wrote: > >> I don't know enough about SPARC32 architecture to know if that gives more >> useful information... I don't see the 0x4c value in my log file. I tried >> turning on DEBUG_MMU, but stopped when my log file hit 4GB and I hadn't hit >> the stopping point yet. >> >> Any ideas for other things to try or set for more debugging? > Since this is repeatable, you could try something like this (untested): > diff --git a/target-sparc/op_helper.c b/target-sparc/op_helper.c > index d1a8dd9..2594bbd 100644 > --- a/target-sparc/op_helper.c > +++ b/target-sparc/op_helper.c > @@ -1836,6 +1836,11 @@ uint64_t helper_ld_asi(target_ulong addr, int > asi, int size, int sign) > ret = mmu_probe(env, addr, mmulev); > DPRINTF_MMU("mmu_probe: 0x%08x (lev %d) -> 0x%08" PRIx64 "\n", > addr, mmulev, ret); > + if (addr == 0xf5901400) { > + printf("mmu_probe: 0x%08x (lev %d) -> 0x%08" PRIx64 "\n", > + addr, mmulev, ret); > + dump_mmu(stdout, fprintf, env); > + } > } > break; > case 4: /* read MMU regs */ Tweaking that a little, I now find myself at pc=0xf01850c8, because that is the current instruction when the page tables write out. (qemu) info cpus * CPU #0: pc=0xf01850c8 npc=0xf01850cc thread_id=3483 (qemu) info registers pc: f01850c8 npc: f01850cc General Registers: %g0-7: 00000000 f024dc00 00000003 f5a6b104 00000004 fbf45b80 f0041000 f5dd0500 Current Register Window: %o0-7: 00000000 f026a2d8 f5901000 f5901200 f026a2dc f018505c f026a270 f005c5a4 %l0-7: 04001fc5 f00436ac 000003a6 00000020 00000000 00000009 00000000 00000001 %i0-7: f026a6c0 f026a40c f5901000 000003a6 00000002 f026a384 f026a2e8 f005cefc Floating Point Registers: %f00: 000000000.000000 000000000.000000 -NaN -NaN %f04: -NaN -NaN -NaN -NaN .... %f28: -NaN -NaN -NaN -NaN psr: 04401fe5 (icc: -Z-- SPE: SPE) wim: 00000002 fsr: 00080000 y: 00000000 (qemu) x /30i 0xf01850a0 0xf01850a0: and %o0, 3, %o3 0xf01850a4: cmp %o3, 2 0xf01850a8: bne 0xf01850c0 0xf01850ac: srl %o2, 0xc, %o3 0xf01850b0: and %o3, 0x3f, %o3 0xf01850b4: sll %o3, 8, %o3 0xf01850b8: b 0xf01850c8 0xf01850bc: add %o0, %o3, %o0 0xf01850c0: mov %o2, %o3 0xf01850c4: lda [ %o3 ] #ASI_M_FLUSH_PROBE, %o0 0xf01850c8: srl %o0, 0x18, %o3 0xf01850cc: andcc %o3, 7, %o3 0xf01850d0: be 0xf01850dc 0xf01850d4: nop 0xf01850d8: sta %g0, [ %o2 ] #ASI_M_FLUSH_PROBE 0xf01850dc: mov 0x300, %o2 0xf01850e0: cmp %o1, 0 0xf01850e4: be 0xf01850f0 0xf01850e8: lda [ %o2 ] #ASI_M_MMUREGS, %o2 0xf01850ec: st %o2, [ %o1 ] 0xf01850f0: retl 0xf01850f4: nop 0xf01850f8: sethi %hi(0x10003000), %o2 0xf01850fc: or %o2, 0x18, %o2 ! 0x10003018 0xf0185100: retl 0xf0185104: lda [ %o2 ] #ASI_M_BYPASS, %o0 0xf0185108: unimp 0 0xf018510c: unimp 0 0xf0185110: unimp 0 0xf0185114: unimp 0 Now I know reading fragments of assembly are lots of fun, so I've attached the dump_mmu results, which will hopefully also be useful. Does that help point to a next step? Thanks! Nathan

2 1

Re: [OpenBIOS] Solaris anyone?
by Nick Couchman 12 Sep '11

12 Sep '11

> Hi Nick, > > Thanks again for testing this. The issue with Solaris not detecting the > disks is a known one - the following guide should point you in the right > direction: > > http://virtuallyfun.blogspot.com/2010/10/formatting-disks-for-solaris.html > > Also don't forget the "set scsi_options" part from Artyom's SPARC/QEMU > howto here: http://tyom.blogspot.com/2009/12/solaris-under-qemu-how-to.html > > I think it may actually be possible to come up with a patch for OpenBIOS > so that the scsi_options change isn't required - let me know how you get > on with the above links, and if it all seems to work I'll look at > creating the patch for you. > > Okay, I got passed the issue with formatting the root filesystem. Apparently there are some limitations on the C/H/S parameters you use for the disk that correspond with how UFS wants to format a new filesystem. I'm not sure what exactly those limitations are at this point, but, by adjusting a couple of the C/H/S settings when using format to set up the disk I was able to get it to work correctly. So, I now have Solaris 9 installed on qemu-system-sparc with OpenBIOS! I'll probably go back to Solaris 8 as that one has a free binary license while Solaris 9 is a commercial license, IIRC. I do own a Solaris 9 commercial license, but I like the free idea, better. Anyway, now I'm on to an issue with networking - I've used the following two qemu network parameter combinations: -net nic -net tap,ifname=tap0 -net nic -net user In the first instance, tap0 was configured on my Linux box and added to my bridge br0. In both cases the Solaris system is unable to obtain a DHCP address - the DHCP client times out. Not sure if I should be using a different parameter set, or if this is another area that needs some work either for OpenBIOS or qemu? -Nick -------- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.

8 34

Re: [OpenBIOS] [PATCH 10/10] Adding filll Forth primitive (v2)
by Stefan Reinauer 12 Sep '11

12 Sep '11

On 8/21/11 8:14 PM, William Hahne wrote: > This is a forth word that is required by BootX. It just fills some > specified memory address and length with 32 bit integers. It is a > non-standard addition and therefore isn't documented. Thanks to Segher > Boessenkool for the corrected for loop. This should be written in Forth and not added as a primitive.

1 0

Re: [OpenBIOS] Openbios rely on other lower-level firmware
by Blue Swirl 10 Sep '11

10 Sep '11

On Fri, Sep 9, 2011 at 1:51 AM, Jianmin Pan <dspjm1(a)gmail.com> wrote: > I want to study the openbios project, while there is a question, I read > that, open bios rely on other firmware, such as coreboot, in my knowledge, > coreboot is a bios system itself, isn't there a conflict? Coreboot is not used on Sparc and PPC, only on x86 this is possible. Hardware init could be moved to coreboot also on Sparc/PPC but nobody has bothered yet. This could be a nice, well-defined project and the person doing it would gain insight to design of both projects.

1 0

Re: [OpenBIOS] Openbios rely on other lower-level firmware
by Mark Cave-Ayland 09 Sep '11

09 Sep '11

On 09/09/11 02:51, Jianmin Pan wrote: > I want to study the openbios project, while there is a question, I read > that, open bios rely on other firmware, such as coreboot, in my > knowledge, coreboot is a bios system itself, isn't there a conflict? Welcome to the OpenBIOS project :) Probably the best way to think about it is that coreboot performs the low level hardware initialisation for various chipsets and then executes a (generally ELF) payload in order to handle the boot process. In the past I've managed to successfully build CoreBoot with an OpenBIOS payload for testing under x86 on QEMU which I think is a good way to help get yourself familiar with the process. BTW as a matter of interest, do you have any interesting projects in mind for OpenBIOS? ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

1 0

Openbios rely on other lower-level firmware
by Jianmin Pan 09 Sep '11

09 Sep '11

I want to study the openbios project, while there is a question, I read that, open bios rely on other firmware, such as coreboot, in my knowledge, coreboot is a bios system itself, isn't there a conflict?

1 0

Re: [OpenBIOS] [PATCH] Support any build directory
by Andreas Färber 03 Sep '11

03 Sep '11

Am 28.08.2011 um 17:28 schrieb Blue Swirl: > Detect source path from switch-arch call path. Always use absolute > paths. Fix bootstrap.c so that for absolute paths, in addition to > include directives (-I), the bare path is checked. > > Signed-off-by: Blue Swirl <blauwirbel(a)gmail.com> > --- > The motivation is to integrate OpenBIOS to QEMU build system. Are we going to switch to Git at that opportunity? Andreas

2 1

[PATCH] Support any build directory
by Blue Swirl 28 Aug '11

28 Aug '11

Detect source path from switch-arch call path. Always use absolute paths. Fix bootstrap.c so that for absolute paths, in addition to include directives (-I), the bare path is checked. Signed-off-by: Blue Swirl <blauwirbel(a)gmail.com> --- The motivation is to integrate OpenBIOS to QEMU build system. --- Makefile | 3 +- Makefile.target | 3 +- config/scripts/switch-arch | 107 ++++++++++++++++++++++--------------------- kernel/bootstrap.c | 53 +++++++++++++-------- 4 files changed, 91 insertions(+), 75 deletions(-) diff --git a/Makefile b/Makefile index 74e462c..d7c0422 100644 --- a/Makefile +++ b/Makefile @@ -1,5 +1,4 @@ -ODIRS=$(wildcard obj-*) -TARGETS=$(subst obj-,,$(ODIRS)) +include config.mak all: requirements info build diff --git a/Makefile.target b/Makefile.target index 934b95a..ecb9ad4 100644 --- a/Makefile.target +++ b/Makefile.target @@ -3,10 +3,11 @@ # (C) 2004-2009 by the OpenBIOS team # +include ../config.mak include config.mak ODIR := . -SRCDIR := .. + HOSTCC := gcc HOSTCFLAGS+= -O2 -g -DFCOMPILER -DBOOTSTRAP $(CROSSCFLAGS) diff --git a/config/scripts/switch-arch b/config/scripts/switch-arch index 1e630da..883de42 100755 --- a/config/scripts/switch-arch +++ b/config/scripts/switch-arch @@ -117,21 +117,18 @@ config_set_boolean() echo "<option name=\"$option\" type=\"boolean\" value=\"true\" />" } -if ! test -f utils/dist/debian/rules; then - echo "switch-arch must be run from the top-level source directory" >&2 - exit 1 -fi -# This is needed because viewvc messes with the permissions of executables: -chmod 755 utils/dist/debian/rules -chmod 755 config/scripts/switch-arch -chmod 755 config/scripts/reldir +SRCDIR=`dirname "$0"`/../.. +BUILDDIR=`pwd` + +# make source path absolute +SRCDIR=`cd "$SRCDIR"; pwd` if test "x$HOSTARCH" = "x"; then archname fi -VERSION=`head VERSION` +VERSION=`head $SRCDIR/VERSION` echo "Configuring OpenBIOS on $HOSTARCH for $*" @@ -156,8 +153,8 @@ done arch_list="" for target in $target_list; do arch=`echo $target | sed s/.*-//g` - if ! test -f config/examples/${arch}_config.xml; then - echo "Cannot find config/examples/${arch}_config.xml" >&2 + if ! test -f $SRCDIR/config/examples/${arch}_config.xml; then + echo "Cannot find $SRCDIR/config/examples/${arch}_config.xml" >&2 exit 1 fi if ! echo $arch_list | grep -q "$arch"; then @@ -268,7 +265,8 @@ for ARCH in $arch_list; do cross="yes" fi crosscflags $HOSTARCH $ARCH - OBJDIR=obj-$ARCH + OBJDIR=$BUILDDIR/obj-$ARCH + ODIRS="$ODIRS $OBJDIR" printf "Initializing build tree $OBJDIR..." rm -rf "$OBJDIR" @@ -293,9 +291,9 @@ for ARCH in $arch_list; do mkdir -p $OBJDIR/host/include mkdir -p $OBJDIR/host/kernel mkdir -p $OBJDIR/forth - ln -s ../../../include/arch/$BASEARCH $OBJDIR/target/include/asm + ln -s $SRCDIR/include/arch/$BASEARCH $OBJDIR/target/include/asm #compile the host binary with target settings instead - #ln -s ../../../include/arch/$HOSTARCH $OBJDIR/host/include/asm + #ln -s $SRCDIR/include/arch/$HOSTARCH $OBJDIR/host/include/asm if [ "$mol" = "yes" ]; then printf "\nUsing MOL path $MOLPATH...\n" mkdir -p $OBJDIR/target/arch/ppc/mol @@ -323,73 +321,78 @@ for ARCH in $arch_list; do fi echo "ok." - cd $OBJDIR - SRCDIR=.. - ODIR=. - - printf "Creating target Makefile..." - echo "ARCH=$ARCH" > $ODIR/config.mak + printf "Creating target config.mak..." + echo "ARCH=$ARCH" > $OBJDIR/config.mak if [ "$cross" = "yes" ]; then - echo "TARGET=$TARGET" >> $ODIR/config.mak + echo "TARGET=$TARGET" >> $OBJDIR/config.mak fi - echo "CFLAGS=$CFLAGS" >> $ODIR/config.mak - echo "AS_FLAGS=$AS_FLAGS" >> $ODIR/config.mak - echo "HOSTARCH?=$HOSTARCH" >> $ODIR/config.mak - echo "CROSSCFLAGS=$CROSSCFLAGS" >> $ODIR/config.mak - echo "VERSION=\"$VERSION\"" >> $ODIR/config.mak - - ln -s $SRCDIR/config/xml/rules.xml $ODIR/rules.xml - echo "<?xml version=\"1.0\"?><config>" > $ODIR/config.xml + echo "CFLAGS=$CFLAGS" >> $OBJDIR/config.mak + echo "AS_FLAGS=$AS_FLAGS" >> $OBJDIR/config.mak + echo "HOSTARCH?=$HOSTARCH" >> $OBJDIR/config.mak + echo "CROSSCFLAGS=$CROSSCFLAGS" >> $OBJDIR/config.mak + echo "VERSION=\"$VERSION\"" >> $OBJDIR/config.mak + echo "ok." + + printf "Creating target rules.mak..." + ln -s $SRCDIR/config/xml/rules.xml $OBJDIR/rules.xml + echo "<?xml version=\"1.0\"?><config>" > $OBJDIR/config.xml # Generic - config_set_boolean CONFIG_$ARCH >> $ODIR/config.xml + config_set_boolean CONFIG_$ARCH >> $OBJDIR/config.xml if [ "$BASEARCH" != "$ARCH" ]; then - config_set_boolean CONFIG_$BASEARCH >> $ODIR/config.xml + config_set_boolean CONFIG_$BASEARCH >> $OBJDIR/config.xml fi if [ "$mol" = "yes" ]; then - config_set_boolean CONFIG_MOL >> $ODIR/config.xml + config_set_boolean CONFIG_MOL >> $OBJDIR/config.xml fi if [ "$briq" = "yes" ]; then - config_set_boolean CONFIG_BRIQ >> $ODIR/config.xml + config_set_boolean CONFIG_BRIQ >> $OBJDIR/config.xml fi if [ "$pearpc" = "yes" ]; then - config_set_boolean CONFIG_PEARPC >> $ODIR/config.xml + config_set_boolean CONFIG_PEARPC >> $OBJDIR/config.xml fi if [ "$qemu" = "yes" ]; then - config_set_boolean CONFIG_QEMU >> $ODIR/config.xml + config_set_boolean CONFIG_QEMU >> $OBJDIR/config.xml fi if [ "$xbox" = "yes" ]; then - config_set_boolean CONFIG_XBOX >> $ODIR/config.xml + config_set_boolean CONFIG_XBOX >> $OBJDIR/config.xml fi if [ "$targetbigendian" = "yes" ]; then - config_set_boolean CONFIG_BIG_ENDIAN >> $ODIR/config.xml + config_set_boolean CONFIG_BIG_ENDIAN >> $OBJDIR/config.xml else - config_set_boolean CONFIG_LITTLE_ENDIAN >> $ODIR/config.xml + config_set_boolean CONFIG_LITTLE_ENDIAN >> $OBJDIR/config.xml fi # Kernel binaries if [ "$plain" = "yes" ]; then - config_set_boolean CONFIG_IMAGE_ELF >> $ODIR/config.xml + config_set_boolean CONFIG_IMAGE_ELF >> $OBJDIR/config.xml fi if [ "$builtin" = "yes" ]; then - config_set_boolean CONFIG_IMAGE_ELF_EMBEDDED >> $ODIR/config.xml + config_set_boolean CONFIG_IMAGE_ELF_EMBEDDED >> $OBJDIR/config.xml fi # Build hosted Unix binary? if [ "$unix" = "yes" ]; then - config_set_boolean CONFIG_HOST_UNIX >> $ODIR/config.xml - #config_set_boolean CONFIG_UNIX_QT >> $ODIR/config.xml - #config_set_boolean CONFIG_PLUGINS >> $ODIR/config.xml + config_set_boolean CONFIG_HOST_UNIX >> $OBJDIR/config.xml + #config_set_boolean CONFIG_UNIX_QT >> $OBJDIR/config.xml + #config_set_boolean CONFIG_PLUGINS >> $OBJDIR/config.xml fi - cat $SRCDIR/config/examples/${ARCH}_config.xml >> $ODIR/config.xml + cat $SRCDIR/config/examples/${ARCH}_config.xml >> $OBJDIR/config.xml - echo "</config>" >> $ODIR/config.xml - ln -s ../Makefile.target $ODIR/Makefile - xsltproc $SRCDIR/config/xml/xinclude.xsl $SRCDIR/build.xml > $ODIR/build-full.xml - xsltproc $SRCDIR/config/xml/makefile.xsl $ODIR/build-full.xml > $ODIR/rules.mak + cd $OBJDIR + echo "</config>" >> $OBJDIR/config.xml + ln -s $SRCDIR/Makefile.target $OBJDIR/Makefile + xsltproc $SRCDIR/config/xml/xinclude.xsl $SRCDIR/build.xml > $OBJDIR/build-full.xml + xsltproc $SRCDIR/config/xml/makefile.xsl $OBJDIR/build-full.xml > $OBJDIR/rules.mak echo "ok." printf "Creating config files..." - xsltproc $SRCDIR/config/xml/config-c.xsl $ODIR/config.xml > $ODIR/host/include/autoconf.h - xsltproc $SRCDIR/config/xml/config-c.xsl $ODIR/config.xml > $ODIR/target/include/autoconf.h - xsltproc $SRCDIR/config/xml/config-forth.xsl $ODIR/config.xml > $ODIR/forth/config.fs + xsltproc $SRCDIR/config/xml/config-c.xsl $OBJDIR/config.xml > $OBJDIR/host/include/autoconf.h + xsltproc $SRCDIR/config/xml/config-c.xsl $OBJDIR/config.xml > $OBJDIR/target/include/autoconf.h + xsltproc $SRCDIR/config/xml/config-forth.xsl $OBJDIR/config.xml > $OBJDIR/forth/config.fs echo "ok." - cd $SRCDIR + cd $BUILDDIR done + +ln -s $SRCDIR/Makefile $BUILDDIR + +echo "SRCDIR=$SRCDIR" > $BUILDDIR/config.mak +echo "ODIRS=$ODIRS" >> $BUILDDIR/config.mak +echo "TARGETS=$arch_list" >> $BUILDDIR/config.mak diff --git a/kernel/bootstrap.c b/kernel/bootstrap.c index 546ffee..59f504f 100644 --- a/kernel/bootstrap.c +++ b/kernel/bootstrap.c @@ -499,6 +499,25 @@ static void add_includepath(char *path) newpath->next = NULL; } +static FILE *try_path(const char *file) +{ + FILE *ret; + + ret = fopen(file, "r"); + if (ret != NULL) { +#ifdef CONFIG_DEBUG_INTERPRETER + printk("Including '%s'\n", file); +#endif + srcfilenames[cursrc] = strdup(file); + srclines[cursrc] = 1; + srcfiles[cursrc++] = ret; + + if (depfile) { + fprintf(depfile, " %s", file); + } + } + return ret; +} static FILE *fopen_include(const char *fil) { @@ -506,28 +525,22 @@ static FILE *fopen_include(const char *fil) FILE *ret; include *incl = &includes; - while (incl) { - snprintf(fullpath, sizeof(fullpath), "%s/%s", incl->path, fil); - - ret = fopen(fullpath, "r"); - if (ret != NULL) { + while (incl) { + snprintf(fullpath, sizeof(fullpath), "%s/%s", incl->path, fil); -#ifdef CONFIG_DEBUG_INTERPRETER - printk("Including '%s'\n", name ); -#endif - srcfilenames[cursrc] = strdup(fil); - srclines [ cursrc ] = 1; - srcfiles [ cursrc++ ] = ret; - - if (depfile) { - fprintf(depfile, " %s", fullpath); - } - - return ret; - } + ret = try_path(fullpath); + if (ret) { + return ret; + } - incl = incl->next; - } + incl = incl->next; + } + if (fil[0] == '/') { + ret = try_path(fil); + if (ret) { + return ret; + } + } return NULL; } -- 1.6.2.4

1 0

[PATCH, RFC] Introduce tracing system from QEMU
by Blue Swirl 26 Aug '11

26 Aug '11

Instead of traditional debugging printf statements, which have the bad habit of suffering from bit rot, introduce tracepoints based on similar system in QEMU. Only stderr (printk) and simpletrace (output via fw_cfg device to QEMU) back ends are supported. Signed-off-by: Blue Swirl <blauwirbel(a)gmail.com> --- Default trace method should be stderr, this should be equivalent to current DPRINTF/printk. Simpletrace method feeds the tracepoint data to QEMU trace system via fw_cfg. Each tracepoint can be controlled run time with QEMU trace series monitor commands. Use of simpletrace needs a patch to QEMU. All tracepoints are controlled by editing 'trace-events' file instead of .c or *_config.xml files. I've only tested Sparc64. --- config/examples/amd64_config.xml | 3 +- config/examples/ppc64_config.xml | 3 +- config/examples/ppc_config.xml | 3 +- config/examples/sparc32_config.xml | 3 +- config/examples/sparc64_config.xml | 3 +- config/scripts/tracetool | 692 ++++++++++++++++++++++++++++++++++++ drivers/esp.c | 3 +- drivers/fw_cfg.c | 22 ++ drivers/ide.c | 6 +- include/arch/common/fw_cfg.h | 9 +- include/libopenbios/simpletrace.h | 31 ++ libopenbios/build.xml | 33 ++ libopenbios/simpletrace.c | 76 ++++ trace-events | 3 + 14 files changed, 879 insertions(+), 11 deletions(-) create mode 100644 config/scripts/tracetool create mode 100644 include/libopenbios/simpletrace.h create mode 100644 libopenbios/simpletrace.c create mode 100644 trace-events diff --git a/config/examples/amd64_config.xml b/config/examples/amd64_config.xml index 33d4267..ba3838b 100644 --- a/config/examples/amd64_config.xml +++ b/config/examples/amd64_config.xml @@ -14,7 +14,8 @@ <option name="CONFIG_SERIAL_PORT" type="boolean" value="true"/> <option name="CONFIG_SERIAL_SPEED" type="integer" value="115200"/> <option name="CONFIG_DEBUG_CONSOLE_VGA" type="boolean" value="true"/> - + <option name="CONFIG_TRACE_SIMPLETRACE" type="boolean" value="false"/> + <option name="CONFIG_TRACE_STDERR" type="boolean" value="true"/>  <option name="CONFIG_CMDLINE" type="boolean" value="true"/> diff --git a/config/examples/ppc64_config.xml b/config/examples/ppc64_config.xml index 5f79c21..bca5cc5 100644 --- a/config/examples/ppc64_config.xml +++ b/config/examples/ppc64_config.xml @@ -12,7 +12,8 @@ <option name="CONFIG_SERIAL_SPEED" type="integer" value="115200"/> <option name="CONFIG_DEBUG_CONSOLE_VGA" type="boolean" value="true"/> <option name="CONFIG_DEBUG_OFMEM" type="boolean" value="false"/> - + <option name="CONFIG_TRACE_SIMPLETRACE" type="boolean" value="false"/> + <option name="CONFIG_TRACE_STDERR" type="boolean" value="true"/>  <option name="CONFIG_CMDLINE" type="boolean" value="true"/> diff --git a/config/examples/ppc_config.xml b/config/examples/ppc_config.xml index 352cb57..a338d56 100644 --- a/config/examples/ppc_config.xml +++ b/config/examples/ppc_config.xml @@ -12,7 +12,8 @@ <option name="CONFIG_SERIAL_SPEED" type="integer" value="115200"/> <option name="CONFIG_DEBUG_CONSOLE_VGA" type="boolean" value="true"/> <option name="CONFIG_DEBUG_OFMEM" type="boolean" value="false"/> - + <option name="CONFIG_TRACE_SIMPLETRACE" type="boolean" value="false"/> + <option name="CONFIG_TRACE_STDERR" type="boolean" value="true"/>  <option name="CONFIG_CMDLINE" type="boolean" value="true"/> diff --git a/config/examples/sparc32_config.xml b/config/examples/sparc32_config.xml index f2d6afc..2b449cc 100644 --- a/config/examples/sparc32_config.xml +++ b/config/examples/sparc32_config.xml @@ -19,7 +19,8 @@ <option name="CONFIG_SERIAL_PORT" type="integer" value="0"/> <option name="CONFIG_SERIAL_SPEED" type="integer" value="9600"/> <option name="CONFIG_DEBUG_OFMEM" type="boolean" value="false"/> - + <option name="CONFIG_TRACE_SIMPLETRACE" type="boolean" value="true"/> + <option name="CONFIG_TRACE_STDERR" type="boolean" value="false"/>  <option name="CONFIG_CMDLINE" type="boolean" value="true"/> diff --git a/config/examples/sparc64_config.xml b/config/examples/sparc64_config.xml index a4e1336..40fb7a6 100644 --- a/config/examples/sparc64_config.xml +++ b/config/examples/sparc64_config.xml @@ -16,7 +16,8 @@ <option name="CONFIG_SERIAL_SPEED" type="integer" value="115200"/> <option name="CONFIG_DEBUG_CONSOLE_VGA" type="boolean" value="true"/> <option name="CONFIG_DEBUG_OFMEM" type="boolean" value="false"/> - + <option name="CONFIG_TRACE_SIMPLETRACE" type="boolean" value="true"/> + <option name="CONFIG_TRACE_STDERR" type="boolean" value="false"/>  <option name="CONFIG_CMDLINE" type="boolean" value="true"/> diff --git a/config/scripts/tracetool b/config/scripts/tracetool new file mode 100644 index 0000000..5c0534f --- /dev/null +++ b/config/scripts/tracetool @@ -0,0 +1,692 @@ +#!/bin/sh +# +# Code generator for trace events +# +# Copyright IBM, Corp. 2010 +# +# This work is licensed under the terms of the GNU GPL, version 2. See +# the COPYING file in the top-level directory. + +# Disable pathname expansion, makes processing text with '*' characters simpler +set -f + +usage() +{ + cat >&2 <<EOF +usage: $0 [--nop | --simple | --stderr | --ust | --dtrace] [-h | -c | -d | -g] +Generate tracing code for a file on stdin. + +Backends: + --nop Tracing disabled + --simple Simple built-in backend + --stderr Stderr built-in backend + --ust LTTng User Space Tracing backend + --dtrace DTrace/SystemTAP backend + +Output formats: + -h Generate .h file + -c Generate .c file + -d Generate .d file (DTrace only) + -g Generate guest trace .c file + --stap Generate .stp file (DTrace with SystemTAP only) + +Options: + --binary [path] Full path to QEMU binary + --target-arch [arch] QEMU emulator target arch + --target-type [type] QEMU emulator target type ('system' or 'user') + --probe-prefix [prefix] Prefix for dtrace probe names + (default: qemu-\$targettype-\$targetarch) + --guest-trace Generate guest trace function + +EOF + exit 1 +} + +# Get the name of a trace event +get_name() +{ + echo ${1%%$*} +} + +# Get the argument list of a trace event, including types and names +get_args() +{ + local args + args=${1#*\(} + args=${args%%$*} + echo "$args" +} + +# Get the argument name list of a trace event +get_argnames() +{ + local nfields field name sep + nfields=0 + sep="$2" + for field in $(get_args "$1"); do + nfields=$((nfields + 1)) + + # Drop pointer star + field=${field#\*} + + # Only argument names have commas at the end + name=${field%,} + test "$field" = "$name" && continue + + printf "%s%s " $name $sep + done + + # Last argument name + if [ "$nfields" -gt 1 ] + then + printf "%s" "$name" + fi +} + +# Get the number of arguments to a trace event +get_argc() +{ + local name argc + argc=0 + for name in $(get_argnames "$1", ","); do + argc=$((argc + 1)) + done + echo $argc +} + +# Get the format string for a trace event +get_fmt() +{ + local fmt + fmt=${1#*\"} + fmt=${fmt%\"*} + echo "$fmt" +} + +# Get the state of a trace event +get_state() +{ + local str disable state + str=$(get_name "$1") + disable=${str##disable } + if [ "$disable" = "$str" ] ; then + state=1 + else + state=0 + fi + echo "$state" +} + +linetoh_begin_nop() +{ + return +} + +linetoh_nop() +{ + local name args + name=$(get_name "$1") + args=$(get_args "$1") + + # Define an empty function for the trace event + cat <<EOF +static inline void trace_$name($args) +{ +} +EOF +} + +linetoh_end_nop() +{ + return +} + +linetoc_begin_nop() +{ + return +} + +linetoc_nop() +{ + # No need for function definitions in nop backend + return +} + +linetoc_end_nop() +{ + return +} + +linetoh_begin_simple() +{ + cat <<EOF +#include "libopenbios/simpletrace.h" +EOF + + simple_event_num=0 +} + +cast_args_to_uint64_t() +{ + local arg + for arg in $(get_argnames "$1", ","); do + printf "%s" "(uint64_t)(uintptr_t)$arg" + done +} + +linetoh_simple() +{ + local name args argc trace_args state + name=$(get_name "$1") + args=$(get_args "$1") + argc=$(get_argc "$1") + state=$(get_state "$1") + if [ "$state" = "0" ]; then + name=${name##disable } + fi + + trace_args="$simple_event_num" + if [ "$argc" -gt 0 ] + then + trace_args="$trace_args, $(cast_args_to_uint64_t "$1")" + fi + + cat <<EOF +static inline void trace_$name($args) +{ + trace$argc($trace_args); +} +EOF + + simple_event_num=$((simple_event_num + 1)) +} + +linetoh_end_simple() +{ + cat <<EOF +#define NR_TRACE_EVENTS $simple_event_num +extern TraceEvent trace_list[NR_TRACE_EVENTS]; +EOF +} + +linetoc_begin_simple() +{ + cat <<EOF +#include "trace.h" + +TraceEvent trace_list[] = { +EOF + simple_event_num=0 + +} + +linetoc_simple() +{ + local name state + name=$(get_name "$1") + state=$(get_state "$1") + if [ "$state" = "0" ] ; then + name=${name##disable } + fi + cat <<EOF +{.tp_name = "$name", .state=$state}, +EOF + simple_event_num=$((simple_event_num + 1)) +} + +linetoc_end_simple() +{ + cat <<EOF +}; +EOF +} + +#STDERR +linetoh_begin_stderr() +{ + cat <<EOF +#include "libc/vsprintf.h" +EOF +} + +linetoh_stderr() +{ + local name args argnames argc fmt + name=$(get_name "$1") + args=$(get_args "$1") + argnames=$(get_argnames "$1" ",") + argc=$(get_argc "$1") + fmt=$(get_fmt "$1") + + if [ "$argc" -gt 0 ]; then + argnames=", $argnames" + fi + + cat <<EOF +static inline void trace_$name($args) +{ + printk("$name $fmt\n" $argnames); +} +EOF +} + +linetoh_end_stderr() +{ +return +} + +linetoc_begin_stderr() +{ +return +} + +linetoc_stderr() +{ +return +} + +linetoc_end_stderr() +{ +return +} +#END OF STDERR + +# Clean up after UST headers which pollute the namespace +ust_clean_namespace() { + cat <<EOF +#undef mutex_lock +#undef mutex_unlock +#undef inline +#undef wmb +EOF +} + +linetoh_begin_ust() +{ + echo "#include <ust/tracepoint.h>" + ust_clean_namespace +} + +linetoh_ust() +{ + local name args argnames + name=$(get_name "$1") + args=$(get_args "$1") + argnames=$(get_argnames "$1", ",") + + cat <<EOF +DECLARE_TRACE(ust_$name, TP_PROTO($args), TP_ARGS($argnames)); +#define trace_$name trace_ust_$name +EOF +} + +linetoh_end_ust() +{ + return +} + +linetoc_begin_ust() +{ + cat <<EOF +#include <ust/marker.h> +$(ust_clean_namespace) +#include "trace.h" +EOF +} + +linetoc_ust() +{ + local name args argnames fmt + name=$(get_name "$1") + args=$(get_args "$1") + argnames=$(get_argnames "$1", ",") + [ -z "$argnames" ] || argnames=", $argnames" + fmt=$(get_fmt "$1") + + cat <<EOF +DEFINE_TRACE(ust_$name); + +static void ust_${name}_probe($args) +{ + trace_mark(ust, $name, "$fmt"$argnames); +} +EOF + + # Collect names for later + names="$names $name" +} + +linetoc_end_ust() +{ + cat <<EOF +static void __attribute__((constructor)) trace_init(void) +{ +EOF + + for name in $names; do + cat <<EOF + register_trace_ust_$name(ust_${name}_probe); +EOF + done + + echo "}" +} + +linetoh_begin_dtrace() +{ + cat <<EOF +#include "trace-dtrace.h" +EOF +} + +linetoh_dtrace() +{ + local name args argnames state nameupper + name=$(get_name "$1") + args=$(get_args "$1") + argnames=$(get_argnames "$1", ",") + state=$(get_state "$1") + if [ "$state" = "0" ] ; then + name=${name##disable } + fi + + nameupper=`echo $name | tr '[:lower:]' '[:upper:]'` + + # Define an empty function for the trace event + cat <<EOF +static inline void trace_$name($args) { + if (QEMU_${nameupper}_ENABLED()) { + QEMU_${nameupper}($argnames); + } +} +EOF +} + +linetoh_end_dtrace() +{ + return +} + +linetoc_begin_dtrace() +{ + return +} + +linetoc_dtrace() +{ + # No need for function definitions in dtrace backend + return +} + +linetoc_end_dtrace() +{ + return +} + +linetod_begin_dtrace() +{ + cat <<EOF +provider qemu { +EOF +} + +linetod_dtrace() +{ + local name args state + name=$(get_name "$1") + args=$(get_args "$1") + state=$(get_state "$1") + if [ "$state" = "0" ] ; then + name=${name##disable } + fi + + # DTrace provider syntax expects foo() for empty + # params, not foo(void) + if [ "$args" = "void" ]; then + args="" + fi + + # Define prototype for probe arguments + cat <<EOF + probe $name($args); +EOF +} + +linetod_end_dtrace() +{ + cat <<EOF +}; +EOF +} + +linetostap_begin_dtrace() +{ + return +} + +linetostap_dtrace() +{ + local i arg name args arglist state + name=$(get_name "$1") + args=$(get_args "$1") + arglist=$(get_argnames "$1", "") + state=$(get_state "$1") + if [ "$state" = "0" ] ; then + name=${name##disable } + fi + + # Define prototype for probe arguments + cat <<EOF +probe $probeprefix.$name = process("$binary").mark("$name") +{ +EOF + + i=1 + for arg in $arglist + do + # 'limit' is a reserved keyword + if [ "$arg" = "limit" ]; then + arg="_limit" + fi + cat <<EOF + $arg = \$arg$i; +EOF + i="$((i+1))" + done + + cat <<EOF +} +EOF +} + +linetostap_end_dtrace() +{ + return +} + +linetog_begin_all() +{ + id=0 + cat <<EOF +#include "trace.h" +#include "guest-trace.h" + +void guest_trace(uint64_t event_id, uint64_t arg1, uint64_t arg2, + uint64_t arg3, uint64_t arg4, uint64_t arg5, uint64_t arg6) + +{ + switch (event_id) { +EOF +} + +linetog_all() +{ + local name args argc arg + name=$(get_name "$1") + argc=$(get_argc "$1") + fieldno=1 + args= + for arg in $(get_argnames "$1", ","); do + args="${args}arg$fieldno" + [ "$fieldno" = "$argc" ] || args="$args, " + fieldno="$((fieldno + 1))" + done + cat <<EOF + case $id: + trace_$name($args); + break; +EOF + id="$((id + 1))" +} + +linetog_end_all() +{ + cat <<EOF + default: + break; + } +} +EOF +} + +# Process stdin by calling begin, line, and end functions for the backend +convert() +{ + local begin process_line end str disable + begin="lineto$1_begin_$backend" + process_line="lineto$1_$backend" + end="lineto$1_end_$backend" + + "$begin" + + while read -r str; do + # Skip comments and empty lines + test -z "${str%%#*}" && continue + + # Process the line. The nop backend handles disabled lines. + disable=${str%%disable *} + echo + if test -z "$disable"; then + # Pass the disabled state as an arg for the simple + # or DTrace backends which handle it dynamically. + # For all other backends, call lineto$1_nop() + if [ $backend = "simple" -o "$backend" = "dtrace" ]; then + "$process_line" "$str" + else + "lineto$1_nop" "${str##disable }" + fi + else + "$process_line" "$str" + fi + done + + echo + "$end" +} + +tracetoh() +{ + cat <<EOF +#ifndef TRACE_H +#define TRACE_H + +/* This file is autogenerated by tracetool, do not edit. */ + +EOF + convert h + echo "#endif /* TRACE_H */" +} + +tracetoc() +{ + echo "/* This file is autogenerated by tracetool, do not edit. */" + convert c +} + +tracetog() +{ + echo "/* This file is autogenerated by tracetool, do not edit. */" + backend=all + convert g +} + +tracetod() +{ + if [ $backend != "dtrace" ]; then + echo "DTrace probe generator not applicable to $backend backend" + exit 1 + fi + echo "/* This file is autogenerated by tracetool, do not edit. */" + convert d +} + +tracetostap() +{ + if [ $backend != "dtrace" ]; then + echo "SystemTAP tapset generator not applicable to $backend backend" + exit 1 + fi + if [ -z "$binary" ]; then + echo "--binary is required for SystemTAP tapset generator" + exit 1 + fi + if [ -z "$probeprefix" -a -z "$targettype" ]; then + echo "--target-type is required for SystemTAP tapset generator" + exit 1 + fi + if [ -z "$probeprefix" -a -z "$targetarch" ]; then + echo "--target-arch is required for SystemTAP tapset generator" + exit 1 + fi + if [ -z "$probeprefix" ]; then + probeprefix="qemu.$targettype.$targetarch"; + fi + echo "/* This file is autogenerated by tracetool, do not edit. */" + convert stap +} + + +backend= +output= +binary= +targettype= +targetarch= +probeprefix= +guesttrace= + + +until [ -z "$1" ] +do + case "$1" in + "--nop" | "--simple" | "--stderr" | "--ust" | "--dtrace") backend="${1#--}" ;; + + "--binary") shift ; binary="$1" ;; + "--target-arch") shift ; targetarch="$1" ;; + "--target-type") shift ; targettype="$1" ;; + "--probe-prefix") shift ; probeprefix="$1" ;; + "--guest-trace") guesttrace="yes" ;; + + "-h" | "-c" | "-d" | "-g") output="${1#-}" ;; + "--stap") output="${1#--}" ;; + + "--check-backend") exit 0 ;; # used by ./configure to test for backend + + "--list-backends") # used by ./configure to list available backends + echo "nop simple stderr ust dtrace" + exit 0 + ;; + + *) + usage;; + esac + shift +done + +if [ "$backend" = "" -o "$output" = "" ]; then + usage +fi + +gen="traceto$output" +"$gen" + +exit 0 diff --git a/drivers/esp.c b/drivers/esp.c index 41e0394..0ab1893 100644 --- a/drivers/esp.c +++ b/drivers/esp.c @@ -25,6 +25,7 @@ #include "asm/dma.h" #include "esp.h" #include "libopenbios/ofmem.h" +#include "trace.h" #define BUFSIZE 4096 @@ -106,7 +107,7 @@ do_command(esp_private_t *esp, sd_private_t *sd, int cmdlen, int replylen) // Clear interrupts to avoid guests seeing spurious interrupts (void)esp->ll->regs[ESP_INTRPT]; - DPRINTF("do_command: id %d, cmd[0] 0x%x, status 0x%x\n", sd->id, esp->buffer[0], status); + trace_esp_do_command(sd->id, esp->buffer[0], status); /* Target didn't want all command data? */ if ((status & ESP_STAT_TCNT) != ESP_STAT_TCNT) { diff --git a/drivers/fw_cfg.c b/drivers/fw_cfg.c index 4027570..caaab3b 100644 --- a/drivers/fw_cfg.c +++ b/drivers/fw_cfg.c @@ -18,6 +18,17 @@ fw_cfg_read(uint16_t cmd, char *buf, unsigned int nbytes) for (i = 0; i < nbytes; i++) buf[i] = *fw_cfg_data; } + +void +fw_cfg_write(uint16_t cmd, char *buf, unsigned int nbytes) +{ + unsigned int i; + + *fw_cfg_cmd = cmd; + for (i = 0; i < nbytes; i++) { + *fw_cfg_data = buf[i]; + } +} #else // XXX depends on PCI bus location, should be removed void @@ -29,6 +40,17 @@ fw_cfg_read(uint16_t cmd, char *buf, unsigned int nbytes) for (i = 0; i < nbytes; i++) buf[i] = inb(CONFIG_FW_CFG_ADDR + 1); } + +void +fw_cfg_write(uint16_t cmd, char *buf, unsigned int nbytes) +{ + unsigned int i; + + outw(cmd, CONFIG_FW_CFG_ADDR); + for (i = 0; i < nbytes; i++) { + outb(buf[i], CONFIG_FW_CFG_ADDR + 1); + } +} #endif uint64_t diff --git a/drivers/ide.c b/drivers/ide.c index 0d09bcd..e4f68f4 100644 --- a/drivers/ide.c +++ b/drivers/ide.c @@ -23,6 +23,7 @@ #include "ide.h" #include "hdreg.h" #include "timer.h" +#include "trace.h" #ifdef CONFIG_DEBUG_IDE #define IDE_DPRINTF(fmt, args...) \ @@ -161,7 +162,7 @@ ob_ide_pio_insw(struct ide_drive *drive, unsigned int offset, struct ide_channel *chan = drive->channel; if (len & 1) { - IDE_DPRINTF("%d: command not word aligned\n", drive->nr); + trace_ob_ide_pio_insw(drive->nr); return; } @@ -1193,8 +1194,7 @@ ob_ide_read_blocks(int *idx) unsigned char *dest = (unsigned char *)cell2pointer(POP()); struct ide_drive *drive = *(struct ide_drive **)idx; - IDE_DPRINTF("ob_ide_read_blocks %lx block=%ld n=%ld\n", - (unsigned long)dest, (unsigned long)blk, (long)n); + trace_ob_ide_read_blocks((unsigned long)dest, (unsigned long)blk, (long)n); while (n) { int len = n; diff --git a/include/arch/common/fw_cfg.h b/include/arch/common/fw_cfg.h index b0a23cd..1448961 100644 --- a/include/arch/common/fw_cfg.h +++ b/include/arch/common/fw_cfg.h @@ -1,6 +1,9 @@ #ifndef FW_CFG_H #define FW_CFG_H +#define FW_CFG_WRITE_CHANNEL 0x4000 +#define FW_CFG_ARCH_LOCAL 0x8000 + #define FW_CFG_SIGNATURE 0x00 #define FW_CFG_ID 0x01 #define FW_CFG_UUID 0x02 @@ -30,10 +33,11 @@ #define FW_CFG_FILE_FIRST 0x20 #define FW_CFG_FILE_SLOTS 0x10 + +#define FW_CFG_GUEST_TRACE (FW_CFG_WRITE_CHANNEL | (FW_CFG_FILE_FIRST+FW_CFG_FILE_SLOTS)) + #define FW_CFG_MAX_ENTRY (FW_CFG_FILE_FIRST+FW_CFG_FILE_SLOTS) -#define FW_CFG_WRITE_CHANNEL 0x4000 -#define FW_CFG_ARCH_LOCAL 0x8000 #define FW_CFG_ENTRY_MASK ~(FW_CFG_WRITE_CHANNEL | FW_CFG_ARCH_LOCAL) #define FW_CFG_PPC_WIDTH (FW_CFG_ARCH_LOCAL + 0x00) @@ -78,6 +82,7 @@ FWCfgState *fw_cfg_init(uint32_t ctl_port, uint32_t data_port, #ifndef NO_OPENBIOS_PROTOS void fw_cfg_read(uint16_t cmd, char *buf, unsigned int nbytes); +void fw_cfg_write(uint16_t cmd, char *buf, unsigned int nbytes); uint64_t fw_cfg_read_i64(uint16_t cmd); uint32_t fw_cfg_read_i32(uint16_t cmd); uint16_t fw_cfg_read_i16(uint16_t cmd); diff --git a/include/libopenbios/simpletrace.h b/include/libopenbios/simpletrace.h new file mode 100644 index 0000000..aa98ee3 --- /dev/null +++ b/include/libopenbios/simpletrace.h @@ -0,0 +1,31 @@ +/* + * Simple trace backend + * + * Copyright IBM, Corp. 2010 + * + * This work is licensed under the terms of the GNU GPL, version 2. See + * the COPYING file in the top-level directory. + * + */ + +#ifndef SIMPLETRACE_H +#define SIMPLETRACE_H + +#include "asm/types.h" + +typedef uint64_t TraceEventID; + +typedef struct { + const char *tp_name; + int state; +} TraceEvent; + +void trace0(TraceEventID event); +void trace1(TraceEventID event, uint64_t x1); +void trace2(TraceEventID event, uint64_t x1, uint64_t x2); +void trace3(TraceEventID event, uint64_t x1, uint64_t x2, uint64_t x3); +void trace4(TraceEventID event, uint64_t x1, uint64_t x2, uint64_t x3, uint64_t x4); +void trace5(TraceEventID event, uint64_t x1, uint64_t x2, uint64_t x3, uint64_t x4, uint64_t x5); +void trace6(TraceEventID event, uint64_t x1, uint64_t x2, uint64_t x3, uint64_t x4, uint64_t x5, uint64_t x6); + +#endif /* SIMPLETRACE_H */ diff --git a/libopenbios/build.xml b/libopenbios/build.xml index 04e3800..b16cd35 100644 --- a/libopenbios/build.xml +++ b/libopenbios/build.xml @@ -19,6 +19,39 @@ <object source="linuxbios_info.c" condition="LINUXBIOS"/> <object source="ofmem_common.c" condition="OFMEM"/> <object source="xcoff_load.c" condition="LOADER_XCOFF"/> + <object source="simpletrace.c" condition="TRACE_SIMPLETRACE"/> + <executable name="target/include/trace.h" condition="TRACE_SIMPLETRACE"> + <rule><![CDATA[ $(ODIR)/target/include/trace.h-timestamp + +$(ODIR)/target/include/trace.h-timestamp: $(SRCDIR)/trace-events + $(call quiet-command,sh $(SRCDIR)/config/scripts/tracetool --simple -h < $< > $@," GEN trace.h") + @cmp -s $@ $(ODIR)/target/include/trace.h || cp $@ $(ODIR)/target/include/trace.h]]></rule> + </executable> + <executable name="target/libopenbios/trace.c" condition="TRACE_SIMPLETRACE"> + <rule><![CDATA[ $(ODIR)/target/libopenbios/trace.c-timestamp + +$(ODIR)/target/libopenbios/trace.c-timestamp: $(SRCDIR)/trace-events + $(call quiet-command,sh $(SRCDIR)/config/scripts/tracetool --simple -c < $< > $@," GEN trace.c") + @cmp -s $@ $(ODIR)/target/libopenbios/trace.c || cp $@ $(ODIR)/target/libopenbios/trace.c]]></rule> + </executable> + <executable name="target/include/trace.h" condition="TRACE_STDERR"> + <rule><![CDATA[ $(ODIR)/target/include/trace.h-timestamp + +$(ODIR)/target/include/trace.h-timestamp: $(SRCDIR)/trace-events + $(call quiet-command,sh $(SRCDIR)/config/scripts/tracetool --stderr -h < $< > $@," GEN trace.h") + @cmp -s $@ $(ODIR)/target/include/trace.h || cp $@ $(ODIR)/target/include/trace.h]]></rule> + </executable> + <executable name="target/libopenbios/trace.c" condition="TRACE_STDERR"> + <rule><![CDATA[ $(ODIR)/target/libopenbios/trace.c-timestamp + +$(ODIR)/target/libopenbios/trace.c-timestamp: $(SRCDIR)/trace-events + $(call quiet-command,sh $(SRCDIR)/config/scripts/tracetool --stderr -c < $< > $@," GEN trace.c") + @cmp -s $@ $(ODIR)/target/libopenbios/trace.c || cp $@ $(ODIR)/target/libopenbios/trace.c]]></rule> + </executable> + <executable name="target/libopenbios/trace.o"> + <rule><![CDATA[ $(ODIR)/target/libopenbios/trace.c $(ODIR)/target/include/trace.h + $(call quiet-command,$(CC) $$EXTRACFLAGS $(CFLAGS) $(INCLUDES) -c -o $@ $<, " CC $(TARGET_DIR)$@")]]></rule> + </executable> </library> <dictionary name="openbios" target="forth"> diff --git a/libopenbios/simpletrace.c b/libopenbios/simpletrace.c new file mode 100644 index 0000000..8795b81 --- /dev/null +++ b/libopenbios/simpletrace.c @@ -0,0 +1,76 @@ +/* + * Simple trace backend + * + * Copyright IBM, Corp. 2010 + * + * This work is licensed under the terms of the GNU GPL, version 2. See + * the COPYING file in the top-level directory. + * + */ + +#include "libopenbios/simpletrace.h" +#include "trace.h" +#include "libc/byteorder.h" +#define NO_QEMU_PROTOS +#include "arch/common/fw_cfg.h" + +/** Trace buffer entry, without timestamp */ +typedef struct { + uint64_t event; + uint64_t x1; + uint64_t x2; + uint64_t x3; + uint64_t x4; + uint64_t x5; + uint64_t x6; +} TraceRecord; + +static void trace(TraceEventID event, uint64_t x1, uint64_t x2, uint64_t x3, + uint64_t x4, uint64_t x5, uint64_t x6) +{ + TraceRecord tmp = (TraceRecord){ + .event = __cpu_to_le64(event), + .x1 = __cpu_to_le64(x1), + .x2 = __cpu_to_le64(x2), + .x3 = __cpu_to_le64(x3), + .x4 = __cpu_to_le64(x4), + .x5 = __cpu_to_le64(x5), + .x6 = __cpu_to_le64(x6), + }; + fw_cfg_write(FW_CFG_GUEST_TRACE, (char *)&tmp, sizeof(tmp)); +} + +void trace0(TraceEventID event) +{ + trace(event, 0, 0, 0, 0, 0, 0); +} + +void trace1(TraceEventID event, uint64_t x1) +{ + trace(event, x1, 0, 0, 0, 0, 0); +} + +void trace2(TraceEventID event, uint64_t x1, uint64_t x2) +{ + trace(event, x1, x2, 0, 0, 0, 0); +} + +void trace3(TraceEventID event, uint64_t x1, uint64_t x2, uint64_t x3) +{ + trace(event, x1, x2, x3, 0, 0, 0); +} + +void trace4(TraceEventID event, uint64_t x1, uint64_t x2, uint64_t x3, uint64_t x4) +{ + trace(event, x1, x2, x3, x4, 0, 0); +} + +void trace5(TraceEventID event, uint64_t x1, uint64_t x2, uint64_t x3, uint64_t x4, uint64_t x5) +{ + trace(event, x1, x2, x3, x4, x5, 0); +} + +void trace6(TraceEventID event, uint64_t x1, uint64_t x2, uint64_t x3, uint64_t x4, uint64_t x5, uint64_t x6) +{ + trace(event, x1, x2, x3, x4, x5, x6); +} diff --git a/trace-events b/trace-events new file mode 100644 index 0000000..0fbb853 --- /dev/null +++ b/trace-events @@ -0,0 +1,3 @@ +esp_do_command(int id, int cmd, int status) "id %d, cmd[0] 0x%x, status 0x%x" +ob_ide_pio_insw(int drive) "%d: command not word aligned" +ob_ide_read_blocks(unsigned long dest, unsigned long blk, long n) "%lx block=%ld n=%ld" -- 1.6.2.4

1 0

Moving an FCode dropin to a new server?
by Dave Simonson 26 Aug '11

26 Aug '11

I've got FCode routines living as a dropin in a 4.x OBP. The dropin is fine, does its job supporting the card, but I need to install it in a new server and no one can find the original. Is there a way to extract the dropin so I can move it? Once I get it, I know I can install the binary image using "add-dropin /location/" Can I also stick it in the card's PROM? Then I wouldn't have it add it as a drop-in to each system I want to use the card in. How would I do that? Thanks! Dave

2 1

Re: [OpenBIOS] [PATCH 7/10] Apple local variables implementation in Forth
by Mark Cave-Ayland 24 Aug '11

24 Aug '11

On 10/08/11 16:43, William Hahne wrote: > Very interesting. I think this needs someone with quite strong > Forth-fu (Stefan) to review this one. Also I can't see any related > documentation with this patch related to locals support? > > > This is an Apple specific thing. See > http://www.openfirmware.info/How_Local_Variables_in_Forth_Work_---_Using_Ap… Right I understand this, but I'm fairly sure there is an official spec for Forth local variables somewhere. For something to be committed, I'd expect the commit reference to contain a link to the source specification and comments in the code giving an indication as to what the level of implementation actually is (I absolutely understand that it can be impractical to implement everything within the time available). ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

3 6

Re: [OpenBIOS] [PATCH 10/10] Adding filll Forth primitive (v2)
by Andreas Färber 24 Aug '11

24 Aug '11

William, Am 22.08.2011 um 05:14 schrieb William Hahne: > This is a forth word that is required by BootX. It just fills some > specified memory address and length with 32 bit integers. It is a > non-standard addition and therefore isn't documented. Thanks to Segher > Boessenkool for the corrected for loop. This is still missing a Signed-off-by line! Compare QEMU's http://wiki.qemu.org/Contribute/SubmitAPatch I'd like to compile-test and commit the patch(es), but I cannot copy&paste this from my mailer (leading spaces get stripped). Best use git-am compatible email format or please supply me with the patch as an attachment or download. Thanks! Andreas $ git am ../mac_10.eml Applying: Adding filll Forth primitive (v2) error: ppc/qemu/init.c (working copy): does not exist in index Patch failed at 0001 Adding filll Forth primitive (v2) When you have resolved this problem run "git am --resolved". If you would prefer to skip this patch, instead run "git am --skip". To restore the original branch and stop patching run "git am --abort". > Index: arch/ppc/qemu/init.c > =================================================================== > --- arch/ppc/qemu/init.c (revision 1047) > +++ arch/ppc/qemu/init.c (working copy) > @@ -539,6 +539,7 @@ > } > > static void go(void); > +static void filll(void); > > static void > go(void) > @@ -551,6 +552,23 @@ > call_elf(0, 0, addr); > } > > +/* This is an Apple specific word that fills a specified location > and length > + of memory with 32bit integers. > + > + ( dest count value -- ) */ > +static void > +filll(void) > +{ > + uint32_t value = POP(); > + int count = POP(); > + uint32_t *dest = (uint32_t*)cell2pointer(POP()); > + > + int i; > + for (i = count; i > 0; i -= sizeof(uint32_t)) { > + *dest++ = value; > + } > +} > + > static void kvm_of_init(void) > { > char hypercall[4 * 4]; > @@ -879,4 +897,5 @@ > > bind_func("platform-boot", boot); > bind_func("(go)", go); > + bind_func("filll", filll); > } > > -- > OpenBIOS http://openbios.org/ > Mailinglist: http://lists.openbios.org/mailman/listinfo > Free your System - May the Forth be with you

2 1

Re: [OpenBIOS] [PATCH 2/10] Ignore extraneous partitions
by Natalia Portillo 24 Aug '11

24 Aug '11

One detail William. Documentation clearly state that drivers, even if present on the partition map, ARE NOT PARTITIONS. (I.M. Vol. 2, and a document I've forgot the name that describes the boot process extensively, present on Apple Support archives -even describes how Rhapsody boots-) Have you checked the count does not include _FREE and _VOID in BootX? El 22/08/2011, a las 03:15, William Hahne escribió: > Updated commit message: > > Currently every entry in the Apple Partition Map is counted as a > partition. This behavior prevents BootX from finding the boot > partition since BootX will only check the first few partitions before > giving up. This patch skips over entries that do not specify > partitions such as void entries and drivers. While documentation > doesn't say specifically that these partitions should be skipped, it > can be inferred from BootX behavior as well as how the documentation > doesn't refer to drivers as partitions. > > -- > OpenBIOS http://openbios.org/ > Mailinglist: http://lists.openbios.org/mailman/listinfo > Free your System - May the Forth be with you

1 0

Re: [OpenBIOS] [PATCH 3/10] Don't stop at APPLE_VOID partition
by Natalia Portillo 24 Aug '11

24 Aug '11

APPLE_VOID partition is just a partition entry holder, so you don't have to resize the partition table but it occupies no space on disk. APPLE_FREE however, indicates free space on disk. This is, if my memory don't fail, on Inside Macintosh books, Volume 2 or 4. Sorry no link I have the books in paper :p El 10/08/2011, a las 16:28, William Hahne escribió: > > > On Wed, Aug 10, 2011 at 5:50 AM, Mark Cave-Ayland <mark.cave-ayland(a)siriusit.co.uk> wrote: > On 09/08/11 22:54, William Hahne wrote: > > The void partitions can be occasionally found on Mac OS discs (10.2 for > example.) Previously mac-parts would just stop at the first void > partition meaning it would never try to boot from the HFS partition. > > Index: packages/mac-parts.c > =================================================================== > --- packages/mac-parts.c (revision 1041) > +++ packages/mac-parts.c (working copy) > @@ -165,9 +165,12 @@ > for (parnum = 1; parnum <= __be32_to_cpu(par.pmMapBlkCnt); parnum++) { > SEEK( bs * parnum ); > READ( &par, sizeof(par) ); > - if( __be16_to_cpu(par.pmSig) != DESC_PART_SIGNATURE || > - !__be32_to_cpu(par.pmPartBlkCnt) ) > + if( __be16_to_cpu(par.pmSig) != DESC_PART_SIGNATURE) { > break; > + } > + if ( !__be32_to_cpu(par.pmPartBlkCnt) ) { > + continue; /* Just a void partition, ignore it. */ > + } > DPRINTF("found partition type: %s with status %x\n", par.pmPartType, > __be32_to_cpu(par.pmPartStatus)); > > Same as my comment for patch 2/10. > > > This was also found through testing although I would assume it is documented. If you have a 10.2 disc (or I would assume most other early Mac OS X discs) lying around you can look at the partition table and see the void partitions. > > William Hahne > > > ATB, > > Mark. > > -- > Mark Cave-Ayland - Senior Technical Architect > PostgreSQL - PostGIS > Sirius Corporation plc - control through freedom > http://www.siriusit.co.uk > t: +44 870 608 0063 > > Sirius Labs: http://www.siriusit.co.uk/labs > > -- > OpenBIOS http://openbios.org/ > Mailinglist: http://lists.openbios.org/mailman/listinfo > Free your System - May the Forth be with you > > > > > -- > OpenBIOS http://openbios.org/ > Mailinglist: http://lists.openbios.org/mailman/listinfo > Free your System - May the Forth be with you

2 2

Re: [OpenBIOS] Grand Unified Tracing
by Blue Swirl 23 Aug '11

23 Aug '11

On Tue, Aug 23, 2011 at 2:54 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote: > On Tue, Aug 23, 2011 at 2:45 PM, Stefan Hajnoczi <stefanha(a)gmail.com> wrote: >> On Tue, Aug 23, 2011 at 3:34 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote: >>> On Tue, Aug 23, 2011 at 5:35 AM, Stefan Hajnoczi <stefanha(a)gmail.com> wrote: >>>> On Mon, Aug 22, 2011 at 9:59 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote: >>>>> On Mon, Aug 22, 2011 at 8:23 PM, Stefan Hajnoczi <stefanha(a)gmail.com> wrote: >>>>>> On Mon, Aug 22, 2011 at 7:14 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote: >>>>>>> OpenBIOS uses traditional DPRINTFs for debugging. I was considering >>>>>>> replacing those with tracepoints, which would output to serial device >>>>>>> or whatever DPRINTFs are using currently. This would not be extremely >>>>>>> useful by itself, except maybe that configuration for debugging would >>>>>>> be concentrated to single 'trace-events' file, but this would not be a >>>>>>> major improvement over current XML configuration. >>>>>>> >>>>>>> But developing this further, maybe OpenBIOS could also pass the >>>>>>> tracepoint data back to QEMU? Then all tracepoint data would be >>>>>>> synchronized, coherent and all gathered to single place. >>>>>>> >>>>>>> The implementation could be that fw_cfg would be used to pass >>>>>>> simpletrace style data. An offset should be added to event IDs and >>>>>>> data would then be output as usual. On OpenBIOS side, the >>>>>>> implementation would be pretty similar to current QEMU tracepoints but >>>>>>> in place of file output there would be fw_cfg output. >>>>>>> >>>>>>> Syntax for trace-events file should be augmented with include >>>>>>> directive, so that QEMU knows also OpenBIOS tracepoints. I think the >>>>>>> only change to simpletrace.py would be to parse this directive. >>>>>>> >>>>>>> Controlling OpenBIOS tracepoints from QEMU monitor would be cool too. >>>>>>> >>>>>>> Going even further, other targets like kernels could use something >>>>>>> similar, probably not using fw_cfg though. >>>>>>> >>>>>>> What do you think? >>>>>> >>>>>> Dhaval showed me a demo of unified host/guest Linux tracing last week. >>>>>> He is doing something similar except using a hypercall to pass a >>>>>> string to the host kernel. In his case kvm.ko handles the hypercall >>>>>> and qemu is not involved. >>>>> >>>>> So the events flow directly from guest kernel to host kernel? >>>> >>>> Yes. >>> >>> How is that used then, with dmesg? >> >> When the host processes the trace hypercall it simply forwards the >> trace event on to host Linux's trace. It currently logs the string >> from the guest and prefixes it with the guest program counter, I >> believe. You can dump out the trace using the usual Linux ftrace >> debugfs files. >> >> But the longer term goal, I believe, is to really integrate guest and >> host tracing so that host userspace (e.g. perf(1)) can pull out trace >> events from the guest and just sees them tagged as belonging to a >> particular qemu-kvm process. >> >>> >>>>>> One issue with QEMU tracing is that trace call sites are static. You >>>>>> need to compile in a trace_*() call, which means that there are two >>>>>> choices for how to tunnel OpenBIOS trace events: >>>>>> >>>>>> 1. Define a tunnel trace event: >>>>>> openbios_event(uint64_t event_id, uint64_t arg1, uint64_t arg2, ...) >>>>>> >>>>>> QEMU only has one trace event to tunnel OpenBIOS trace events. Then >>>>>> the host is unable to pretty-print OpenBIOS traces automatically and >>>>>> the max arguments becomes 6 - 1 (for the openbios_event tunnel event >>>>>> id). >>>>>> >>>>>> 2. Generate a switch statement to demultiplex trace events: >>>>>> void hypercall(uint64_t event_id, uint64_t arg1, ...) >>>>>> { >>>>>> /* This is auto-generated by tracetool */ >>>>>> switch (event_id) { >>>>>> case TRACE_EVENT_OPENBIOS_FOO: >>>>>> trace_openbios_foo(arg1, arg2, arg3); >>>>>> break; >>>>>> case TRACE_EVENT_OPENBIOS_BAR: >>>>>> trace_openbios_bar(arg1); >>>>>> break; >>>>>> ... >>>>>> } >>>>>> } >>>>>> >>>>>> With this approach the user can toggle trace events at runtime and it >>>>>> works out much nicer. >>>>> >>>>> Maybe I'm missing something, but why would we have to multiplex >>>>> anything? Since the trace IDs are 64 bits, we can easily allocate a >>>>> static range (starting from 0x8000000000000000) to non-native events >>>>> so that QEMU IDs and OpenBIOS IDs do not overlap. QEMU would add this >>>>> offset to IDs coming from fw_cfg. Then QEMU would just pass the data >>>>> (8*64 bit words) to tracing back end. There obviously something needs >>>>> to be changed so that OpenBIOS messages can be generated. For >>>>> simpletrace this should be easy, for stderr and other back ends that >>>>> may be more complicated. >>>> >>>> I meant that the interface generated by tracetool is a header file >>>> with trace_*() functions. If you want to support any tracing backend >>>> then you need to use this interface and cannot call simpletrace.c >>>> trace0(), trace1(), ... directly. >>>> >>>> Are you thinking of only supporting the simple trace backend? >>> >>> That would be simplest, then fw_cfg.c (or some intermediate entity) >>> could just call trace6(). >>> >>> But stderr would be useful too. I think that could be done by adding >>> code to read trace-events file to grab the format string. Then a >>> modified vfprintf would parse it but instead of va_arg(args, type) it >>> would just grab the uint64_t arg. Your approach would be much simpler. >> >> I see. I think we should avoid introducing dependencies on specific >> trace backends, so I would go for the generated switch statement >> above. That way you can even use DTrace/SystemTap or other backends. >> Also if we called traceX() directly we'd have to duplicate the logic >> to check whether the trace event is enabled/disabled, so it becomes a >> bit messy. > > I see. I'll try the switch approach then. Here's a work in progress version for the guest tracepoints. Both QEMU and OpenBIOS compile (stderr and simpletrace backends), but because of the recent breakage, I couldn't test the patches. At least the event from OpenBIOS is visible to QEMU monitor: esp_do_command [Event ID 322] : state 1 QEMU must be configured with '--with-guest-trace-file=/src/openbios-devel/trace-events'. There's some danger of namespace collisions. One way to avoid those would be that the event names could be prefixed, with prefix given during configure time.

1 0

Re: [OpenBIOS] Grand Unified Tracing
by Blue Swirl 23 Aug '11

23 Aug '11

On Tue, Aug 23, 2011 at 2:45 PM, Stefan Hajnoczi <stefanha(a)gmail.com> wrote: > On Tue, Aug 23, 2011 at 3:34 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote: >> On Tue, Aug 23, 2011 at 5:35 AM, Stefan Hajnoczi <stefanha(a)gmail.com> wrote: >>> On Mon, Aug 22, 2011 at 9:59 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote: >>>> On Mon, Aug 22, 2011 at 8:23 PM, Stefan Hajnoczi <stefanha(a)gmail.com> wrote: >>>>> On Mon, Aug 22, 2011 at 7:14 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote: >>>>>> OpenBIOS uses traditional DPRINTFs for debugging. I was considering >>>>>> replacing those with tracepoints, which would output to serial device >>>>>> or whatever DPRINTFs are using currently. This would not be extremely >>>>>> useful by itself, except maybe that configuration for debugging would >>>>>> be concentrated to single 'trace-events' file, but this would not be a >>>>>> major improvement over current XML configuration. >>>>>> >>>>>> But developing this further, maybe OpenBIOS could also pass the >>>>>> tracepoint data back to QEMU? Then all tracepoint data would be >>>>>> synchronized, coherent and all gathered to single place. >>>>>> >>>>>> The implementation could be that fw_cfg would be used to pass >>>>>> simpletrace style data. An offset should be added to event IDs and >>>>>> data would then be output as usual. On OpenBIOS side, the >>>>>> implementation would be pretty similar to current QEMU tracepoints but >>>>>> in place of file output there would be fw_cfg output. >>>>>> >>>>>> Syntax for trace-events file should be augmented with include >>>>>> directive, so that QEMU knows also OpenBIOS tracepoints. I think the >>>>>> only change to simpletrace.py would be to parse this directive. >>>>>> >>>>>> Controlling OpenBIOS tracepoints from QEMU monitor would be cool too. >>>>>> >>>>>> Going even further, other targets like kernels could use something >>>>>> similar, probably not using fw_cfg though. >>>>>> >>>>>> What do you think? >>>>> >>>>> Dhaval showed me a demo of unified host/guest Linux tracing last week. >>>>> He is doing something similar except using a hypercall to pass a >>>>> string to the host kernel. In his case kvm.ko handles the hypercall >>>>> and qemu is not involved. >>>> >>>> So the events flow directly from guest kernel to host kernel? >>> >>> Yes. >> >> How is that used then, with dmesg? > > When the host processes the trace hypercall it simply forwards the > trace event on to host Linux's trace. It currently logs the string > from the guest and prefixes it with the guest program counter, I > believe. You can dump out the trace using the usual Linux ftrace > debugfs files. > > But the longer term goal, I believe, is to really integrate guest and > host tracing so that host userspace (e.g. perf(1)) can pull out trace > events from the guest and just sees them tagged as belonging to a > particular qemu-kvm process. > >> >>>>> One issue with QEMU tracing is that trace call sites are static. You >>>>> need to compile in a trace_*() call, which means that there are two >>>>> choices for how to tunnel OpenBIOS trace events: >>>>> >>>>> 1. Define a tunnel trace event: >>>>> openbios_event(uint64_t event_id, uint64_t arg1, uint64_t arg2, ...) >>>>> >>>>> QEMU only has one trace event to tunnel OpenBIOS trace events. Then >>>>> the host is unable to pretty-print OpenBIOS traces automatically and >>>>> the max arguments becomes 6 - 1 (for the openbios_event tunnel event >>>>> id). >>>>> >>>>> 2. Generate a switch statement to demultiplex trace events: >>>>> void hypercall(uint64_t event_id, uint64_t arg1, ...) >>>>> { >>>>> /* This is auto-generated by tracetool */ >>>>> switch (event_id) { >>>>> case TRACE_EVENT_OPENBIOS_FOO: >>>>> trace_openbios_foo(arg1, arg2, arg3); >>>>> break; >>>>> case TRACE_EVENT_OPENBIOS_BAR: >>>>> trace_openbios_bar(arg1); >>>>> break; >>>>> ... >>>>> } >>>>> } >>>>> >>>>> With this approach the user can toggle trace events at runtime and it >>>>> works out much nicer. >>>> >>>> Maybe I'm missing something, but why would we have to multiplex >>>> anything? Since the trace IDs are 64 bits, we can easily allocate a >>>> static range (starting from 0x8000000000000000) to non-native events >>>> so that QEMU IDs and OpenBIOS IDs do not overlap. QEMU would add this >>>> offset to IDs coming from fw_cfg. Then QEMU would just pass the data >>>> (8*64 bit words) to tracing back end. There obviously something needs >>>> to be changed so that OpenBIOS messages can be generated. For >>>> simpletrace this should be easy, for stderr and other back ends that >>>> may be more complicated. >>> >>> I meant that the interface generated by tracetool is a header file >>> with trace_*() functions. If you want to support any tracing backend >>> then you need to use this interface and cannot call simpletrace.c >>> trace0(), trace1(), ... directly. >>> >>> Are you thinking of only supporting the simple trace backend? >> >> That would be simplest, then fw_cfg.c (or some intermediate entity) >> could just call trace6(). >> >> But stderr would be useful too. I think that could be done by adding >> code to read trace-events file to grab the format string. Then a >> modified vfprintf would parse it but instead of va_arg(args, type) it >> would just grab the uint64_t arg. Your approach would be much simpler. > > I see. I think we should avoid introducing dependencies on specific > trace backends, so I would go for the generated switch statement > above. That way you can even use DTrace/SystemTap or other backends. > Also if we called traceX() directly we'd have to duplicate the logic > to check whether the trace event is enabled/disabled, so it becomes a > bit messy. I see. I'll try the switch approach then.

1 0

Re: [OpenBIOS] Grand Unified Tracing
by Stefan Hajnoczi 23 Aug '11

23 Aug '11

On Tue, Aug 23, 2011 at 3:34 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote: > On Tue, Aug 23, 2011 at 5:35 AM, Stefan Hajnoczi <stefanha(a)gmail.com> wrote: >> On Mon, Aug 22, 2011 at 9:59 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote: >>> On Mon, Aug 22, 2011 at 8:23 PM, Stefan Hajnoczi <stefanha(a)gmail.com> wrote: >>>> On Mon, Aug 22, 2011 at 7:14 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote: >>>>> OpenBIOS uses traditional DPRINTFs for debugging. I was considering >>>>> replacing those with tracepoints, which would output to serial device >>>>> or whatever DPRINTFs are using currently. This would not be extremely >>>>> useful by itself, except maybe that configuration for debugging would >>>>> be concentrated to single 'trace-events' file, but this would not be a >>>>> major improvement over current XML configuration. >>>>> >>>>> But developing this further, maybe OpenBIOS could also pass the >>>>> tracepoint data back to QEMU? Then all tracepoint data would be >>>>> synchronized, coherent and all gathered to single place. >>>>> >>>>> The implementation could be that fw_cfg would be used to pass >>>>> simpletrace style data. An offset should be added to event IDs and >>>>> data would then be output as usual. On OpenBIOS side, the >>>>> implementation would be pretty similar to current QEMU tracepoints but >>>>> in place of file output there would be fw_cfg output. >>>>> >>>>> Syntax for trace-events file should be augmented with include >>>>> directive, so that QEMU knows also OpenBIOS tracepoints. I think the >>>>> only change to simpletrace.py would be to parse this directive. >>>>> >>>>> Controlling OpenBIOS tracepoints from QEMU monitor would be cool too. >>>>> >>>>> Going even further, other targets like kernels could use something >>>>> similar, probably not using fw_cfg though. >>>>> >>>>> What do you think? >>>> >>>> Dhaval showed me a demo of unified host/guest Linux tracing last week. >>>> He is doing something similar except using a hypercall to pass a >>>> string to the host kernel. In his case kvm.ko handles the hypercall >>>> and qemu is not involved. >>> >>> So the events flow directly from guest kernel to host kernel? >> >> Yes. > > How is that used then, with dmesg? When the host processes the trace hypercall it simply forwards the trace event on to host Linux's trace. It currently logs the string from the guest and prefixes it with the guest program counter, I believe. You can dump out the trace using the usual Linux ftrace debugfs files. But the longer term goal, I believe, is to really integrate guest and host tracing so that host userspace (e.g. perf(1)) can pull out trace events from the guest and just sees them tagged as belonging to a particular qemu-kvm process. > >>>> One issue with QEMU tracing is that trace call sites are static. You >>>> need to compile in a trace_*() call, which means that there are two >>>> choices for how to tunnel OpenBIOS trace events: >>>> >>>> 1. Define a tunnel trace event: >>>> openbios_event(uint64_t event_id, uint64_t arg1, uint64_t arg2, ...) >>>> >>>> QEMU only has one trace event to tunnel OpenBIOS trace events. Then >>>> the host is unable to pretty-print OpenBIOS traces automatically and >>>> the max arguments becomes 6 - 1 (for the openbios_event tunnel event >>>> id). >>>> >>>> 2. Generate a switch statement to demultiplex trace events: >>>> void hypercall(uint64_t event_id, uint64_t arg1, ...) >>>> { >>>> /* This is auto-generated by tracetool */ >>>> switch (event_id) { >>>> case TRACE_EVENT_OPENBIOS_FOO: >>>> trace_openbios_foo(arg1, arg2, arg3); >>>> break; >>>> case TRACE_EVENT_OPENBIOS_BAR: >>>> trace_openbios_bar(arg1); >>>> break; >>>> ... >>>> } >>>> } >>>> >>>> With this approach the user can toggle trace events at runtime and it >>>> works out much nicer. >>> >>> Maybe I'm missing something, but why would we have to multiplex >>> anything? Since the trace IDs are 64 bits, we can easily allocate a >>> static range (starting from 0x8000000000000000) to non-native events >>> so that QEMU IDs and OpenBIOS IDs do not overlap. QEMU would add this >>> offset to IDs coming from fw_cfg. Then QEMU would just pass the data >>> (8*64 bit words) to tracing back end. There obviously something needs >>> to be changed so that OpenBIOS messages can be generated. For >>> simpletrace this should be easy, for stderr and other back ends that >>> may be more complicated. >> >> I meant that the interface generated by tracetool is a header file >> with trace_*() functions. If you want to support any tracing backend >> then you need to use this interface and cannot call simpletrace.c >> trace0(), trace1(), ... directly. >> >> Are you thinking of only supporting the simple trace backend? > > That would be simplest, then fw_cfg.c (or some intermediate entity) > could just call trace6(). > > But stderr would be useful too. I think that could be done by adding > code to read trace-events file to grab the format string. Then a > modified vfprintf would parse it but instead of va_arg(args, type) it > would just grab the uint64_t arg. Your approach would be much simpler. I see. I think we should avoid introducing dependencies on specific trace backends, so I would go for the generated switch statement above. That way you can even use DTrace/SystemTap or other backends. Also if we called traceX() directly we'd have to duplicate the logic to check whether the trace event is enabled/disabled, so it becomes a bit messy. Stefan

1 0

Re: [OpenBIOS] Grand Unified Tracing
by Blue Swirl 23 Aug '11

23 Aug '11

On Tue, Aug 23, 2011 at 5:35 AM, Stefan Hajnoczi <stefanha(a)gmail.com> wrote: > On Mon, Aug 22, 2011 at 9:59 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote: >> On Mon, Aug 22, 2011 at 8:23 PM, Stefan Hajnoczi <stefanha(a)gmail.com> wrote: >>> On Mon, Aug 22, 2011 at 7:14 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote: >>>> OpenBIOS uses traditional DPRINTFs for debugging. I was considering >>>> replacing those with tracepoints, which would output to serial device >>>> or whatever DPRINTFs are using currently. This would not be extremely >>>> useful by itself, except maybe that configuration for debugging would >>>> be concentrated to single 'trace-events' file, but this would not be a >>>> major improvement over current XML configuration. >>>> >>>> But developing this further, maybe OpenBIOS could also pass the >>>> tracepoint data back to QEMU? Then all tracepoint data would be >>>> synchronized, coherent and all gathered to single place. >>>> >>>> The implementation could be that fw_cfg would be used to pass >>>> simpletrace style data. An offset should be added to event IDs and >>>> data would then be output as usual. On OpenBIOS side, the >>>> implementation would be pretty similar to current QEMU tracepoints but >>>> in place of file output there would be fw_cfg output. >>>> >>>> Syntax for trace-events file should be augmented with include >>>> directive, so that QEMU knows also OpenBIOS tracepoints. I think the >>>> only change to simpletrace.py would be to parse this directive. >>>> >>>> Controlling OpenBIOS tracepoints from QEMU monitor would be cool too. >>>> >>>> Going even further, other targets like kernels could use something >>>> similar, probably not using fw_cfg though. >>>> >>>> What do you think? >>> >>> Dhaval showed me a demo of unified host/guest Linux tracing last week. >>> He is doing something similar except using a hypercall to pass a >>> string to the host kernel. In his case kvm.ko handles the hypercall >>> and qemu is not involved. >> >> So the events flow directly from guest kernel to host kernel? > > Yes. How is that used then, with dmesg? >>> One issue with QEMU tracing is that trace call sites are static. You >>> need to compile in a trace_*() call, which means that there are two >>> choices for how to tunnel OpenBIOS trace events: >>> >>> 1. Define a tunnel trace event: >>> openbios_event(uint64_t event_id, uint64_t arg1, uint64_t arg2, ...) >>> >>> QEMU only has one trace event to tunnel OpenBIOS trace events. Then >>> the host is unable to pretty-print OpenBIOS traces automatically and >>> the max arguments becomes 6 - 1 (for the openbios_event tunnel event >>> id). >>> >>> 2. Generate a switch statement to demultiplex trace events: >>> void hypercall(uint64_t event_id, uint64_t arg1, ...) >>> { >>> /* This is auto-generated by tracetool */ >>> switch (event_id) { >>> case TRACE_EVENT_OPENBIOS_FOO: >>> trace_openbios_foo(arg1, arg2, arg3); >>> break; >>> case TRACE_EVENT_OPENBIOS_BAR: >>> trace_openbios_bar(arg1); >>> break; >>> ... >>> } >>> } >>> >>> With this approach the user can toggle trace events at runtime and it >>> works out much nicer. >> >> Maybe I'm missing something, but why would we have to multiplex >> anything? Since the trace IDs are 64 bits, we can easily allocate a >> static range (starting from 0x8000000000000000) to non-native events >> so that QEMU IDs and OpenBIOS IDs do not overlap. QEMU would add this >> offset to IDs coming from fw_cfg. Then QEMU would just pass the data >> (8*64 bit words) to tracing back end. There obviously something needs >> to be changed so that OpenBIOS messages can be generated. For >> simpletrace this should be easy, for stderr and other back ends that >> may be more complicated. > > I meant that the interface generated by tracetool is a header file > with trace_*() functions. If you want to support any tracing backend > then you need to use this interface and cannot call simpletrace.c > trace0(), trace1(), ... directly. > > Are you thinking of only supporting the simple trace backend? That would be simplest, then fw_cfg.c (or some intermediate entity) could just call trace6(). But stderr would be useful too. I think that could be done by adding code to read trace-events file to grab the format string. Then a modified vfprintf would parse it but instead of va_arg(args, type) it would just grab the uint64_t arg. Your approach would be much simpler.

1 0

Re: [OpenBIOS] [PATCH 10/10] Adding filll Forth primitive (v2)
by Segher Boessenkool 23 Aug '11

23 Aug '11

>> This isn't going to work with -fstrict-aliasing, but I guess >> openbios has that disabled anyway? > I don't think it breaks strict aliasing rules. A cell is defined as a > 32bit integer on 32bit architectures and this code will only be > compiled on ppc32. I just wrote it as a uint32_t for clarity. It breaks aliasing rules if whatever reads the data you write does not read it as a type compatible with the type you wrote it as. If everything reads it as a 32-bit int, a cell, or a character type, it is fine; if not, not. Don't worry about it too much, I'm sure there are hundreds of other places in openbios that do icky things like this. It's in the nature of emulators/ interpreters :-) Segher

1 0

Re: [OpenBIOS] [PATCH 10/10] Adding filll Forth primitive (v2)
by Andreas Färber 23 Aug '11

23 Aug '11

Am 23.08.2011 um 04:45 schrieb William Hahne: > On Mon, Aug 22, 2011 at 7:19 AM, Segher Boessenkool > <segher(a)kernel.crashing.org> wrote: >> This isn't going to work with -fstrict-aliasing, but I guess >> openbios has that disabled anyway? >> > > I don't think it breaks strict aliasing rules. A cell is defined as a > 32bit integer on 32bit architectures and this code will only be > compiled on ppc32. ppc64? Andreas > I just wrote it as a uint32_t for clarity. > > William Hahne

1 0

Re: [OpenBIOS] Grand Unified Tracing
by Stefan Hajnoczi 23 Aug '11

23 Aug '11

On Mon, Aug 22, 2011 at 9:59 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote: > On Mon, Aug 22, 2011 at 8:23 PM, Stefan Hajnoczi <stefanha(a)gmail.com> wrote: >> On Mon, Aug 22, 2011 at 7:14 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote: >>> OpenBIOS uses traditional DPRINTFs for debugging. I was considering >>> replacing those with tracepoints, which would output to serial device >>> or whatever DPRINTFs are using currently. This would not be extremely >>> useful by itself, except maybe that configuration for debugging would >>> be concentrated to single 'trace-events' file, but this would not be a >>> major improvement over current XML configuration. >>> >>> But developing this further, maybe OpenBIOS could also pass the >>> tracepoint data back to QEMU? Then all tracepoint data would be >>> synchronized, coherent and all gathered to single place. >>> >>> The implementation could be that fw_cfg would be used to pass >>> simpletrace style data. An offset should be added to event IDs and >>> data would then be output as usual. On OpenBIOS side, the >>> implementation would be pretty similar to current QEMU tracepoints but >>> in place of file output there would be fw_cfg output. >>> >>> Syntax for trace-events file should be augmented with include >>> directive, so that QEMU knows also OpenBIOS tracepoints. I think the >>> only change to simpletrace.py would be to parse this directive. >>> >>> Controlling OpenBIOS tracepoints from QEMU monitor would be cool too. >>> >>> Going even further, other targets like kernels could use something >>> similar, probably not using fw_cfg though. >>> >>> What do you think? >> >> Dhaval showed me a demo of unified host/guest Linux tracing last week. >> He is doing something similar except using a hypercall to pass a >> string to the host kernel. In his case kvm.ko handles the hypercall >> and qemu is not involved. > > So the events flow directly from guest kernel to host kernel? Yes. > >> One issue with QEMU tracing is that trace call sites are static. You >> need to compile in a trace_*() call, which means that there are two >> choices for how to tunnel OpenBIOS trace events: >> >> 1. Define a tunnel trace event: >> openbios_event(uint64_t event_id, uint64_t arg1, uint64_t arg2, ...) >> >> QEMU only has one trace event to tunnel OpenBIOS trace events. Then >> the host is unable to pretty-print OpenBIOS traces automatically and >> the max arguments becomes 6 - 1 (for the openbios_event tunnel event >> id). >> >> 2. Generate a switch statement to demultiplex trace events: >> void hypercall(uint64_t event_id, uint64_t arg1, ...) >> { >> /* This is auto-generated by tracetool */ >> switch (event_id) { >> case TRACE_EVENT_OPENBIOS_FOO: >> trace_openbios_foo(arg1, arg2, arg3); >> break; >> case TRACE_EVENT_OPENBIOS_BAR: >> trace_openbios_bar(arg1); >> break; >> ... >> } >> } >> >> With this approach the user can toggle trace events at runtime and it >> works out much nicer. > > Maybe I'm missing something, but why would we have to multiplex > anything? Since the trace IDs are 64 bits, we can easily allocate a > static range (starting from 0x8000000000000000) to non-native events > so that QEMU IDs and OpenBIOS IDs do not overlap. QEMU would add this > offset to IDs coming from fw_cfg. Then QEMU would just pass the data > (8*64 bit words) to tracing back end. There obviously something needs > to be changed so that OpenBIOS messages can be generated. For > simpletrace this should be easy, for stderr and other back ends that > may be more complicated. I meant that the interface generated by tracetool is a header file with trace_*() functions. If you want to support any tracing backend then you need to use this interface and cannot call simpletrace.c trace0(), trace1(), ... directly. Are you thinking of only supporting the simple trace backend? Stefan

1 0

Re: [OpenBIOS] [PATCH 10/10] Adding filll Forth primitive (v2)
by Segher Boessenkool 23 Aug '11

23 Aug '11

> +static void > +filll(void) > +{ > + uint32_t value = POP(); > + int count = POP(); > + uint32_t *dest = (uint32_t*)cell2pointer(POP()); > + > + int i; > + for (i = count; i > 0; i -= sizeof(uint32_t)) { > + *dest++ = value; > + } > +} This isn't going to work with -fstrict-aliasing, but I guess openbios has that disabled anyway? Segher

2 1

Re: [OpenBIOS] Grand Unified Tracing
by Blue Swirl 22 Aug '11

22 Aug '11

On Mon, Aug 22, 2011 at 8:23 PM, Stefan Hajnoczi <stefanha(a)gmail.com> wrote: > On Mon, Aug 22, 2011 at 7:14 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote: >> OpenBIOS uses traditional DPRINTFs for debugging. I was considering >> replacing those with tracepoints, which would output to serial device >> or whatever DPRINTFs are using currently. This would not be extremely >> useful by itself, except maybe that configuration for debugging would >> be concentrated to single 'trace-events' file, but this would not be a >> major improvement over current XML configuration. >> >> But developing this further, maybe OpenBIOS could also pass the >> tracepoint data back to QEMU? Then all tracepoint data would be >> synchronized, coherent and all gathered to single place. >> >> The implementation could be that fw_cfg would be used to pass >> simpletrace style data. An offset should be added to event IDs and >> data would then be output as usual. On OpenBIOS side, the >> implementation would be pretty similar to current QEMU tracepoints but >> in place of file output there would be fw_cfg output. >> >> Syntax for trace-events file should be augmented with include >> directive, so that QEMU knows also OpenBIOS tracepoints. I think the >> only change to simpletrace.py would be to parse this directive. >> >> Controlling OpenBIOS tracepoints from QEMU monitor would be cool too. >> >> Going even further, other targets like kernels could use something >> similar, probably not using fw_cfg though. >> >> What do you think? > > Dhaval showed me a demo of unified host/guest Linux tracing last week. > He is doing something similar except using a hypercall to pass a > string to the host kernel. In his case kvm.ko handles the hypercall > and qemu is not involved. So the events flow directly from guest kernel to host kernel? > One issue with QEMU tracing is that trace call sites are static. You > need to compile in a trace_*() call, which means that there are two > choices for how to tunnel OpenBIOS trace events: > > 1. Define a tunnel trace event: > openbios_event(uint64_t event_id, uint64_t arg1, uint64_t arg2, ...) > > QEMU only has one trace event to tunnel OpenBIOS trace events. Then > the host is unable to pretty-print OpenBIOS traces automatically and > the max arguments becomes 6 - 1 (for the openbios_event tunnel event > id). > > 2. Generate a switch statement to demultiplex trace events: > void hypercall(uint64_t event_id, uint64_t arg1, ...) > { > /* This is auto-generated by tracetool */ > switch (event_id) { > case TRACE_EVENT_OPENBIOS_FOO: > trace_openbios_foo(arg1, arg2, arg3); > break; > case TRACE_EVENT_OPENBIOS_BAR: > trace_openbios_bar(arg1); > break; > ... > } > } > > With this approach the user can toggle trace events at runtime and it > works out much nicer. Maybe I'm missing something, but why would we have to multiplex anything? Since the trace IDs are 64 bits, we can easily allocate a static range (starting from 0x8000000000000000) to non-native events so that QEMU IDs and OpenBIOS IDs do not overlap. QEMU would add this offset to IDs coming from fw_cfg. Then QEMU would just pass the data (8*64 bit words) to tracing back end. There obviously something needs to be changed so that OpenBIOS messages can be generated. For simpletrace this should be easy, for stderr and other back ends that may be more complicated. > Remember that QEMU tracing also supports DTrace (SystemTap) and LTTng > Userspace Tracer. Simpletrace would be the interface between the > guest and the host for passing trace records. In Dhaval's case we > were talking about passing binary Linux tracing events to the host and > quickly realized there are host/guest ABI compatibility issues to > consider. For OpenBIOS debugging you may be able to get away with > demanding that the OpenBIOS is built for this particular QEMU binary > though :). I'd expect that OpenBIOS needs to be compiled so that it can pass the data to QEMU in a format that both understand and that its trace-events file should be #included by QEMU's trace-events file. This binds both together. In case simpletrace backend is used, I think any QEMU would do except monitor needs event names.

1 0

Re: [OpenBIOS] Grand Unified Tracing
by Stefan Hajnoczi 22 Aug '11

22 Aug '11

On Mon, Aug 22, 2011 at 7:14 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote: > OpenBIOS uses traditional DPRINTFs for debugging. I was considering > replacing those with tracepoints, which would output to serial device > or whatever DPRINTFs are using currently. This would not be extremely > useful by itself, except maybe that configuration for debugging would > be concentrated to single 'trace-events' file, but this would not be a > major improvement over current XML configuration. > > But developing this further, maybe OpenBIOS could also pass the > tracepoint data back to QEMU? Then all tracepoint data would be > synchronized, coherent and all gathered to single place. > > The implementation could be that fw_cfg would be used to pass > simpletrace style data. An offset should be added to event IDs and > data would then be output as usual. On OpenBIOS side, the > implementation would be pretty similar to current QEMU tracepoints but > in place of file output there would be fw_cfg output. > > Syntax for trace-events file should be augmented with include > directive, so that QEMU knows also OpenBIOS tracepoints. I think the > only change to simpletrace.py would be to parse this directive. > > Controlling OpenBIOS tracepoints from QEMU monitor would be cool too. > > Going even further, other targets like kernels could use something > similar, probably not using fw_cfg though. > > What do you think? Dhaval showed me a demo of unified host/guest Linux tracing last week. He is doing something similar except using a hypercall to pass a string to the host kernel. In his case kvm.ko handles the hypercall and qemu is not involved. One issue with QEMU tracing is that trace call sites are static. You need to compile in a trace_*() call, which means that there are two choices for how to tunnel OpenBIOS trace events: 1. Define a tunnel trace event: openbios_event(uint64_t event_id, uint64_t arg1, uint64_t arg2, ...) QEMU only has one trace event to tunnel OpenBIOS trace events. Then the host is unable to pretty-print OpenBIOS traces automatically and the max arguments becomes 6 - 1 (for the openbios_event tunnel event id). 2. Generate a switch statement to demultiplex trace events: void hypercall(uint64_t event_id, uint64_t arg1, ...) { /* This is auto-generated by tracetool */ switch (event_id) { case TRACE_EVENT_OPENBIOS_FOO: trace_openbios_foo(arg1, arg2, arg3); break; case TRACE_EVENT_OPENBIOS_BAR: trace_openbios_bar(arg1); break; ... } } With this approach the user can toggle trace events at runtime and it works out much nicer. Remember that QEMU tracing also supports DTrace (SystemTap) and LTTng Userspace Tracer. Simpletrace would be the interface between the guest and the host for passing trace records. In Dhaval's case we were talking about passing binary Linux tracing events to the host and quickly realized there are host/guest ABI compatibility issues to consider. For OpenBIOS debugging you may be able to get away with demanding that the OpenBIOS is built for this particular QEMU binary though :). Stefan

1 0

Grand Unified Tracing
by Blue Swirl 22 Aug '11

22 Aug '11

OpenBIOS uses traditional DPRINTFs for debugging. I was considering replacing those with tracepoints, which would output to serial device or whatever DPRINTFs are using currently. This would not be extremely useful by itself, except maybe that configuration for debugging would be concentrated to single 'trace-events' file, but this would not be a major improvement over current XML configuration. But developing this further, maybe OpenBIOS could also pass the tracepoint data back to QEMU? Then all tracepoint data would be synchronized, coherent and all gathered to single place. The implementation could be that fw_cfg would be used to pass simpletrace style data. An offset should be added to event IDs and data would then be output as usual. On OpenBIOS side, the implementation would be pretty similar to current QEMU tracepoints but in place of file output there would be fw_cfg output. Syntax for trace-events file should be augmented with include directive, so that QEMU knows also OpenBIOS tracepoints. I think the only change to simpletrace.py would be to parse this directive. Controlling OpenBIOS tracepoints from QEMU monitor would be cool too. Going even further, other targets like kernels could use something similar, probably not using fw_cfg though. What do you think?

1 0

[PATCH] sparc32: add sbus-intr>cpu for sun4m
by Bob Breuer 22 Aug '11

22 Aug '11

Add an implementation of sbus-intr>cpu for sun4m to map sbus interrupt levels (1 to 7) into cpu interrupts, and make use of it for bpp. Assumes false is the same as -1. Signed-off-by: Bob Breuer <breuerr(a)mc.net> --- Index: arch/sparc32/tree.fs =================================================================== --- arch/sparc32/tree.fs (revision 1046) +++ arch/sparc32/tree.fs (working copy) @@ -1,4 +1,16 @@ +\ map sbus intr level to cpu intr +: sun4m-sbus-intr>cpu + \ map 1 2 3 4 5 6 7 other + \ to 32 33 35 37 39 3b 3d 0 + dup 1 7 between if + 2* dup 2 <> + h# 30 + + else + drop 0 + then + ; +['] sun4m-sbus-intr>cpu to sbus-intr>cpu + " /" find-device 2 encode-int " #address-cells" property 1 encode-int " #size-cells" property @@ -61,7 +73,7 @@ new-device " SUNW,bpp" device-name h# 4 encode-int h# 0c800000 encode-int encode+ h# 0000001c encode-int encode+ " reg" property - h# 33 encode-int 0 encode-int encode+ " intr" property + h# 2 sbus-intr>cpu encode-int 0 encode-int encode+ " intr" property finish-device [THEN]

3 5

sbus slot probing
by Bob Breuer 22 Aug '11

22 Aug '11

Here's a preliminary patch for sbus slot probing. This can be used for the preliminary dbri device patch, see my dbri-pre1 branch at github: https://github.com/breuerr/qemu/tree/dbri-pre1 That branch also has a rewritten fcode rom to avoid the use of the obsolete intr forth word. Use the SS-20 machine to get the dbri device. Todo: non-faulting reads so that an empty slot can be probed extend to probe other (all?) slots as well only add the slot E range for SS-20, but not SS-10 Is there any existing code for sparc32 which does a non-faulting read? It looks like even cpeek doesn't try to catch any faults. Bob Index: drivers/sbus.c =================================================================== --- drivers/sbus.c (revision 1046) +++ drivers/sbus.c (working copy) @@ -451,11 +451,36 @@ static void sbus_probe_slot_ss10(unsigned int slot, uint64_t base) { + ucell fcode; + unsigned char start; + // OpenBIOS and Qemu don't know how to do Sbus probing switch(slot) { case 2: // SUNW,tcx ob_tcx_init(slot, "/iommu/sbus/SUNW,tcx"); break; + case 0xe: // dbri + fcode = ofmem_map_io(base, 0x1000); + // TODO: non-faulting read + start = *(unsigned char*)fcode; + if (start == 0xfd || start == 0xf1) { + push_str("/iommu/sbus"); + fword("select-dev"); + fword("new-device"); + push_str(NULL); + PUSH(0); // offset + PUSH(slot); // space + push_str("encode-unit"); + fword("$call-parent"); + fword("set-args"); + PUSH(fcode); + PUSH(1); + fword("byte-load"); + fword("finish-device"); + fword("unselect-dev"); + } + ofmem_unmap(fcode, 0x1000); + break; case 0xf: // le, esp, bpp, power-management ob_macio_init(slot, base, 0); // Power management (APC) XXX should not exist @@ -534,6 +559,7 @@ { 1, 0, 0xe10000000ULL, 0x10000000,}, { 2, 0, 0xe20000000ULL, 0x10000000,}, { 3, 0, 0xe30000000ULL, 0x10000000,}, + [0xe] = { 0xe, 0, 0xee0000000ULL, 0x10000000,}, [0xf] = { 0xf, 0, 0xef0000000ULL, 0x10000000,}, };

3 3

[PATCH 10/10] Adding filll Forth primitive (v2)
by William Hahne 22 Aug '11

22 Aug '11

This is a forth word that is required by BootX. It just fills some specified memory address and length with 32 bit integers. It is a non-standard addition and therefore isn't documented. Thanks to Segher Boessenkool for the corrected for loop. Index: arch/ppc/qemu/init.c =================================================================== --- arch/ppc/qemu/init.c (revision 1047) +++ arch/ppc/qemu/init.c (working copy) @@ -539,6 +539,7 @@ } static void go(void); +static void filll(void); static void go(void) @@ -551,6 +552,23 @@ call_elf(0, 0, addr); } +/* This is an Apple specific word that fills a specified location and length + of memory with 32bit integers. + + ( dest count value -- ) */ +static void +filll(void) +{ + uint32_t value = POP(); + int count = POP(); + uint32_t *dest = (uint32_t*)cell2pointer(POP()); + + int i; + for (i = count; i > 0; i -= sizeof(uint32_t)) { + *dest++ = value; + } +} + static void kvm_of_init(void) { char hypercall[4 * 4]; @@ -879,4 +897,5 @@ bind_func("platform-boot", boot); bind_func("(go)", go); + bind_func("filll", filll); }

1 0

Re: [OpenBIOS] [PATCH 2/10] Ignore extraneous partitions
by William Hahne 22 Aug '11

22 Aug '11

Updated commit message: Currently every entry in the Apple Partition Map is counted as a partition. This behavior prevents BootX from finding the boot partition since BootX will only check the first few partitions before giving up. This patch skips over entries that do not specify partitions such as void entries and drivers. While documentation doesn't say specifically that these partitions should be skipped, it can be inferred from BootX behavior as well as how the documentation doesn't refer to drivers as partitions.

1 0

Re: [OpenBIOS] [PATCH 3/10] Don't stop at APPLE_VOID partition
by William Hahne 22 Aug '11

22 Aug '11

Updated commit message: This patch modifies mac-parts to continue reading partitions even when encountering an APPLE_VOID entry. An APPLE_VOID entry is just place holder allowing another partition to be inserted without rewriting the whole partition table (see Inside Macintosh books, Volume 2 or 4). So it can be safely ignored, meaning there is no reason to stop at an APPLE_VOID entry.

1 0

Re: [OpenBIOS] [PATCH 6/10] Wrapped HFS+ incorrectly recognized
by William Hahne 22 Aug '11

22 Aug '11

Updated commit message: The code for checking for a wrapped HFS+ volume looks at the wrong offset. The offset of the magic number for the wrapped volume is 0x7c, but vol is declared as a uint16 meaning the correct array index to check is 0x3e (see http://developer.apple.com/library/mac/#technotes/tn/tn1150.html)

1 0

[commit] r1047 - trunk/openbios-devel/drivers
by repository service 20 Aug '11

20 Aug '11

Author: blueswirl Date: Sat Aug 20 14:10:07 2011 New Revision: 1047 URL: http://tracker.coreboot.org/trac/openbios/changeset/1047 Log: ESP: clear Unit Attention condition after reset In recent QEMU, SCSI devices are in Unit Attention condition after reset and this made Read Capacity command fail. Fix by sending a Test Unit Ready command to the devices first. Also avoid division by zero if block size is 0 when Read Capacity fails. Thanks to Paolo Bonzini for analysis. Signed-off-by: Blue Swirl <blauwirbel(a)gmail.com> Modified: trunk/openbios-devel/drivers/esp.c Modified: trunk/openbios-devel/drivers/esp.c ============================================================================== --- trunk/openbios-devel/drivers/esp.c Mon Aug 8 14:33:10 2011 (r1046) +++ trunk/openbios-devel/drivers/esp.c Sat Aug 20 14:10:07 2011 (r1047) @@ -108,11 +108,17 @@ DPRINTF("do_command: id %d, cmd[0] 0x%x, status 0x%x\n", sd->id, esp->buffer[0], status); - // Target didn't want all command data or went to status phase - // instead of data phase? - if ((status & ESP_STAT_TCNT) != ESP_STAT_TCNT - || (status & ESP_STAT_PMASK) == ESP_STATP) + /* Target didn't want all command data? */ + if ((status & ESP_STAT_TCNT) != ESP_STAT_TCNT) { return status; + } + if (replylen == 0) { + return 0; + } + /* Target went to status phase instead of data phase? */ + if ((status & ESP_STAT_PMASK) == ESP_STATP) { + return status; + } // Get reply // Set DMA address @@ -176,12 +182,31 @@ if (do_command(esp, sd, 11, 8)) { sd->sectors = 0; sd->bs = 0; - + DPRINTF("read_capacity id %d failed\n", sd->id); return 0; } sd->bs = (esp->buffer[4] << 24) | (esp->buffer[5] << 16) | (esp->buffer[6] << 8) | esp->buffer[7]; sd->sectors = ((esp->buffer[0] << 24) | (esp->buffer[1] << 16) | (esp->buffer[2] << 8) | esp->buffer[3]) * (sd->bs / 512); + DPRINTF("read_capacity id %d bs %d sectors %d\n", sd->id, sd->bs, + sd->sectors); + return 1; +} + +static unsigned int +test_unit_ready(esp_private_t *esp, sd_private_t *sd) +{ + /* Setup command = Test Unit Ready */ + memset(esp->buffer, 0, 6); + esp->buffer[0] = 0x80; + esp->buffer[1] = TEST_UNIT_READY; + + if (do_command(esp, sd, 6, 0)) { + DPRINTF("test_unit_ready id %d failed\n", sd->id); + return 0; + } + + DPRINTF("test_unit_ready id %d success\n", sd->id); return 1; } @@ -234,6 +259,10 @@ DPRINTF("ob_sd_read_blocks id %d %lx block=%d n=%d\n", (*sd)->id, (unsigned long)dest, blk, n ); + if ((*sd)->bs == 0) { + PUSH(0); + return; + } spb = (*sd)->bs / 512; while (n) { sect_offset = blk / spb; @@ -438,6 +467,7 @@ int id, diskcount = 0, cdcount = 0, *counter_ptr; char nodebuff[256], aliasbuff[256]; esp_private_t *esp; + unsigned int i; DPRINTF("Initializing SCSI..."); @@ -476,8 +506,21 @@ for (id = 0; id < 8; id++) { esp->sd[id].id = id; - if (!inquiry(esp, &esp->sd[id])) + if (!inquiry(esp, &esp->sd[id])) { + DPRINTF("Unit %d not present\n", id); continue; + } + /* Clear Unit Attention condition from reset */ + for (i = 0; i < 5; i++) { + if (test_unit_ready(esp, &esp->sd[id])) { + break; + } + } + if (i == 5) { + DPRINTF("Unit %d present but won't become ready\n", id); + continue; + } + DPRINTF("Unit %d present\n", id); read_capacity(esp, &esp->sd[id]); #ifdef CONFIG_DEBUG_ESP

1 0

Re: [OpenBIOS] [PATCH 5/10] Add draw-rectangle to the display package
by Mark Cave-Ayland 19 Aug '11

19 Aug '11

On 16/08/11 02:25, William Hahne wrote: > On Mon, Aug 15, 2011 at 6:57 AM, Mark Cave-Ayland > <mark.cave-ayland(a)siriusit.co.uk> wrote: >> Ah I see - so the real bug is that OpenBIOS can't add the word correctly? Do >> you have any DEBUG_CIF traces so we can determine the Forth being sent to >> OpenBIOS and come up with a fix for that? > > I would recommend looking at the BootX source directly for this. If > you look at http://opensource.apple.com/source/BootX/BootX-45/bootx.tproj/sl.subproj/di… > line 403. You can see that it just throws the phandle directly into > active-package. The device package implementation in OpenBIOS expects > active-package to only be set by calling the active-package! word. If > it is set directly then it doesn't actually change the active-package. So looking at the OpenBIOS code I can see that active-package! not only changes the active-package value, but also switches in the private wordlist for that package. I wonder how OBP does it? I can only assume that there is a hook in the dictionary search routine which interrogates the private wordlist first based upon the current value of active-package. I have a feeling in the back of my mind that I've seen Fcode elsewhere that does a similar thing in some of my SPARC investigations, so it seems like a strong assumption held by various developers. Perhaps it may be possible to alter the $find word to search the active-package wordlist first if set to a non-zero value? > I would like to note that this particular patch is optional for > booting Mac OS X. It is just nice since it allows the Apple logo to be > displayed. Understood. ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

2 1

Re: [OpenBIOS] [PATCH 10/10] Adding filll Forth primitive
by Segher Boessenkool 19 Aug '11

19 Aug '11

> +static void filll(void) > +{ > + ucell value = POP(); > + ucell count = POP(); > + ucell *dest = (ucell *)cell2pointer(POP()); > + > + int i; > + for (i = 0; i <= count / 4; i++) { > + dest[i] = value; > + } > +} Apple's code does: int *dest ... ; for (i = count; i > 0; i -= 4) *dest++ = value; which is not the same thing for huge count, or for count a multiple of four (like all callers I have seen use; you write a word too many). Segher

2 2

Re: [OpenBIOS] [PATCH 10/10] Adding filll Forth primitive
by Andreas Färber 17 Aug '11

17 Aug '11

Am 16.08.2011 um 04:04 schrieb William Hahne: > On 8/15/11, Andreas Färber <andreas.faerber(a)web.de> wrote: >> Am 09.08.2011 um 23:55 schrieb William Hahne: >> >>> This is a forth primitive that is required by BootX. It just fills >>> some specified memory address and length with longs. >>> >>> >>> Index: kernel/forth.c >>> =================================================================== >>> --- kernel/forth.c (revision 1041) >>> +++ kernel/forth.c (working copy) >>> @@ -1610,6 +1616,20 @@ >>> memset(src, value, count); >>> } >>> >>> +/* >>> + * filll ( addr len byte -- ) >>> + */ >>> +static void filll(void) >>> +{ >>> + ucell value = POP(); >>> + ucell count = POP(); >>> + ucell *dest = (ucell *)cell2pointer(POP()); >>> + >>> + int i; >>> + for (i = 0; i <= count / 4; i++) { >>> + dest[i] = value; >>> + } >>> +} >> >> This word puzzles me: The extra l in filll seems to be for "long" >> according to the patch description. But there's a hardcoded >> arithmetic >> with 4 and the parameter is documented as byte yet is being written >> ucell-wide. That strikes me as inconsistent. > > Honestly, my problem is I was unable to find documentation on filll. > This suggests that it may be an non-standard addition by Apple. You > are right about the inconsistency. I will make a revised version of > the patch to address this. > >> Either 4 needs to be replaced with sizeof(ucell) to fit sparc64, or >> the division by 4 dropped and uint8_t* written len times. > > It seems likely that it is supposed to fill with 32bit integers, but > this would have to be checked on a 64bit platform which I do not have > access to. I have access to both Apple and IBM ppc64 machines and could check if you provide paste'able Forth code. :) > This may not be applicable to sparc at all but again > someone with access to the hardware would have to confirm. In its present form, the patch seems in no way limited to ppc - you might want to look at the [IFDEF word or so if that's your intent. Also note, your division by 4 leaves up to three trailing bytes un- filled for unaligned lengths. If intentional, you should add a comment saying so. Further, it was suggested we use QEMU coding style for new contributions - the above function uses an inconsistent indentation. Andreas

2 1

Re: [OpenBIOS] [PATCH 10/10] Adding filll Forth primitive
by Segher Boessenkool 17 Aug '11

17 Aug '11

>> This word puzzles me: The extra l in filll seems to be for "long" >> according to the patch description. But there's a hardcoded >> arithmetic >> with 4 and the parameter is documented as byte yet is being written >> ucell-wide. That strikes me as inconsistent. "l" in OF refers to 32-bit memory, like in "la1+" and "rl@" for example. 64-bit is "x". > Honestly, my problem is I was unable to find documentation on filll. > This suggests that it may be an non-standard addition by Apple. It is. Segher

1 0

Re: [OpenBIOS] [PATCH 10/10] Adding filll Forth primitive
by Tarl Neustaedter 16 Aug '11

16 Aug '11

On 2011-Aug-15 23:16 , William Hahne wrote: > Well, the point of these patches is to allow Mac OS to be booted from > OpenBIOS. So actually in this case using Apple's implementation as a > reference is exactly what should be done. > Right. Just be careful of busting everything else in the name of making MacOS work.

1 0

Re: [OpenBIOS] [PATCH 10/10] Adding filll Forth primitive
by Tarl Neustaedter 16 Aug '11

16 Aug '11

On 2011-Aug-15 22:04 , William Hahne wrote: > [...] This suggests that it may be an non-standard addition by Apple. You > are right about the inconsistency. [...] I will comment that back when 1275 was still active, we noted that Apple's implementation had sufficiently diverged from Sun's, Firmworks and IBM's implementations (and the standard) that PCI card vendors who did FCode ended up shipping two different versions - an Apple version and a Sun version. I just mention this in terms of being careful not to take Apple's implementation as a reference standard.

2 1

Re: [OpenBIOS] [PATCH 10/10] Adding filll Forth primitive
by Andreas Färber 16 Aug '11

16 Aug '11

Am 09.08.2011 um 23:55 schrieb William Hahne: > This is a forth primitive that is required by BootX. It just fills > some specified memory address and length with longs. > > > Index: kernel/forth.c > =================================================================== > --- kernel/forth.c (revision 1041) > +++ kernel/forth.c (working copy) > @@ -1610,6 +1616,20 @@ > memset(src, value, count); > } > > +/* > + * filll ( addr len byte -- ) > + */ > +static void filll(void) > +{ > + ucell value = POP(); > + ucell count = POP(); > + ucell *dest = (ucell *)cell2pointer(POP()); > + > + int i; > + for (i = 0; i <= count / 4; i++) { > + dest[i] = value; > + } > +} This word puzzles me: The extra l in filll seems to be for "long" according to the patch description. But there's a hardcoded arithmetic with 4 and the parameter is documented as byte yet is being written ucell-wide. That strikes me as inconsistent. Either 4 needs to be replaced with sizeof(ucell) to fit sparc64, or the division by 4 dropped and uint8_t* written len times. Andreas

2 1

Re: [OpenBIOS] [PATCH 5/10] Add draw-rectangle to the display package
by Mark Cave-Ayland 16 Aug '11

16 Aug '11

On 10/08/11 16:35, William Hahne wrote: > I am not sure if it is officially part of any specification. BootX > doesn't even assume that it was there and attempted to add its own > "draw-rectangle" word, but unfortunately the method it uses to add words > to packages doesn't work with OpenBIOS. Just adding draw-rectangle > seemed like a much simpler and safer solution than changing the way > device packages work. Also from what I could see it looked like a > serious rewrite might be necessary just to get one small edge case to work. Ah I see - so the real bug is that OpenBIOS can't add the word correctly? Do you have any DEBUG_CIF traces so we can determine the Forth being sent to OpenBIOS and come up with a fix for that? ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

2 1

Re: [OpenBIOS] [PATCH 7/10] Apple local variables implementation in Forth
by Programmingkid 16 Aug '11

16 Aug '11

On Aug 15, 2011, at 11:01 AM, openbios-request(a)openbios.org wrote: > Message: 2 > Date: Mon, 15 Aug 2011 13:03:29 +0100 > From: Mark Cave-Ayland <mark.cave-ayland(a)siriusit.co.uk> > To: openbios(a)openbios.org > Subject: Re: [OpenBIOS] [PATCH 7/10] Apple local variables > implementation in Forth > Message-ID: <4E490B11.2040806(a)siriusit.co.uk> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 10/08/11 16:43, William Hahne wrote: > >> Very interesting. I think this needs someone with quite strong >> Forth-fu (Stefan) to review this one. Also I can't see any related >> documentation with this patch related to locals support? >> >> >> This is an Apple specific thing. See >> http://www.openfirmware.info/How_Local_Variables_in_Forth_Work_---_Using_Ap… > > Right I understand this, but I'm fairly sure there is an official spec > for Forth local variables somewhere. For something to be committed, I'd > expect the commit reference to contain a link to the source > specification and comments in the code giving an indication as to what > the level of implementation actually is (I absolutely understand that it > can be impractical to implement everything within the time available). > > > ATB, > > Mark. There doesn't appear to be any official specification to local variables in Forth. From what I remember, the very creator of Forth was against them. It looks like the only way to understand Apple's local variables support is to see how their own code behaves in OpenFirmware. I have found suggestions on how to add local variables support to forth, but never any thing "official".

1 0

Help with libopenbios/ofmem_common.c line 175 "insert in the freelist"
by Kenneth Salerno 15 Aug '11

15 Aug '11

Hi, I finally got around to running QEMU in gdb to debug the AIX V6.1 boot hang and was able to get past where I got stuck previously: ------------------------------------------------------------------------------- Welcome to AIX. boot image timestamp: 00:39 35/2D NULL ihandle The current time and date: 00:00:00 228784/00/0008 processor count: 1; memory size: 1024MB; kernel size: 2293829 boot device: cd:\ppc\chrp\bootfile.exe Validation failed: the "/rtas" device node does not exist. EXIT It used to hang after "boot device: cd:\ppc\chrp\bootfile.exe" with OpenBIOS stuck at line 175 of libopenbios/ofmem_common.c: for( pp=&ofmem->mfree; *pp && (**pp).size < d->size ; pp = &(**pp).next ) { } I made the following hack to get it to progress to the RTAS validation: --- ofmem_common.c.ORIG 2011-08-08 17:04:25.375000000 -0400 +++ ofmem_common.c 2011-08-08 17:04:45.875000000 -0400 @@ -172,8 +172,9 @@ d->next = ofmem->mfree; /* insert in the (sorted) freelist */ - for( pp=&ofmem->mfree; *pp && (**pp).size < d->size ; pp = &(**pp).next ) { - } +/* for( pp=&ofmem->mfree; *pp && (**pp).size < d->size ; pp = &(**pp).next ) { + } */ + pp=&ofmem->mfree; d->next = *pp; *pp = d; Before I made the above change, the following is what I saw in gdb and qemu console: (qemu) info cpus * CPU #0: nip=0x00000000fff91a84 thread_id=6828 (gdb) 0x00000000fff91a84 in ofmem_free (ptr=0x3fca1774) at ../libopenbios/ofmem_common.c:175 175 for( pp=&ofmem->mfree; *pp && (**pp).size < d->size ; pp = &(**pp).next ) { (gdb) print /x pp $1 = 0x3fc9e0ac The value 0x3fc9e0ac can be found in register GPR08: (qemu) info registers NIP 00000000fff91a84 LR 00000000fff91a58 CTR 00000000fff93784 XER 000000002000 0000 MSR 0000000000003032 HID0 0000000060000000 HF 0000000000002000 idx 1 TB 00000001 7638146663 DECR 951787926 GPR00 000000003fca1764 000000003fdf69e0 00000000fffc68e8 000000003fc9e0ac GPR04 00000000fffc0088 000000003fc5bc68 00000000fffc0860 0000000000044200 GPR08 0000000000000002 000000003fc9e0ac 0000000000000024 0000000000000810 GPR12 00000000000088ac 0000000000000000 00000000fffb6703 00000000fffb7b65 GPR16 00000000fffb8331 00000000fffb6706 0000000004000000 00000000fffbf6b8 GPR20 00000000fffbf634 00000000fffc68e8 00000000fffbf634 00000000fffb650a GPR24 00000000fffb64f8 00000000fffb6478 00000000fffb6500 00000000fffb6505 GPR28 00000000fffb707e 0000000000000027 0000000000000027 000000003fca1774 CR 48000084 [ G L - - - - L G ] RES ffffffffffffffff FPR00 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPSCR 00000000 SRR0 00000000fffaa590 SRR1 0000000000003032 PVR 00000000003c0301 VRSAVE 000 0000000000000 SPRG0 000000003fe00000 SPRG1 000000003fdf6630 SPRG2 0000000000000000 SPRG3 000 0000000000000 SPRG4 0000000000000000 SPRG5 0000000000000000 SPRG6 0000000000000000 SPRG7 000 0000000000000 SDR1 000000003fe00000 Here is my QEMU command: ./testing/qemu/ppc64-softmmu/qemu-system-ppc64 \ -L ./testing/qemu/pc-bios \ -m 1024 \ -bios ./testing/openbios-devel/obj-ppc64/openbios-qemu.elf -drive file=images/aix.img,index=0,media=disk,cache=writeback -cdrom images/ibmaix.iso \ -boot d \ -nographic \ -rtc base=localtime,clock=host \ -uuid 17202d0a-45f8-4159-a8e1-78b866f50aa7 \ -serial tcp::9979,server,nowait \ -monitor tcp::9980,server,nowait \ -gdb tcp::1234 powerpc64-unknown-linux-gnu-gdb testing/openbios-devel/obj-ppc64/openbios-qemu.elf-nostrip I don't really know what I'm doing so any help explaining this function in ofmem_common.c would be appreciated. Thank you, Ken

2 3

Re: [OpenBIOS] [PATCH 6/10] Wrapped HFS+ incorrectly recognized
by Natalia Portillo 15 Aug '11

15 Aug '11

I confirm the patch is correct. As of Apple TechNote 1150 at http://developer.apple.com/library/mac/#technotes/tn/tn1150.html the wrapper address is at byte 0x07c. vol is declared as UInt16 and so the offset advanced two bytes each step, then correct offset is 0x3e in 16-bit words. El 10/08/2011, a las 16:41, William Hahne escribió: > > > On Wed, Aug 10, 2011 at 5:56 AM, Mark Cave-Ayland <mark.cave-ayland(a)siriusit.co.uk> wrote: > On 09/08/11 22:54, William Hahne wrote: > > The code for checking for a wrapped HFS+ volume looks at the wrong offset. > > Index: fs/hfsplus/hfsp_volume.c > =================================================================== > --- fs/hfsplus/hfsp_volume.c (revision 1041) > +++ fs/hfsplus/hfsp_volume.c (working copy) > @@ -302,7 +302,7 @@ > os_read(fd, vol, 2, HFSP_BLOCKSZ_BITS); > if (__be16_to_cpu(vol[0]) == HFS_VOLHEAD_SIG && > - __be16_to_cpu(vol[0x7c]) == HFSP_VOLHEAD_SIG) { > + __be16_to_cpu(vol[0x3e]) == HFSP_VOLHEAD_SIG) { > ret = -1; > } else if (__be16_to_cpu(vol[0]) == HFSP_VOLHEAD_SIG) { > ret = -1; > > Same comment as for patch 2/10. > > > Actually I think this one is not contrary to the specification but is just a mix up between a 8bit and 16bit array. The original value seems to assume that vol is an array of 8bit integers while it is an array of 16bit integers. If you notice the corrected value is half of the original value. I can look up the documentation but it seems unnecessary in this case. > > > ATB, > > Mark. > > -- > Mark Cave-Ayland - Senior Technical Architect > PostgreSQL - PostGIS > Sirius Corporation plc - control through freedom > http://www.siriusit.co.uk > t: +44 870 608 0063 > > Sirius Labs: http://www.siriusit.co.uk/labs > > -- > OpenBIOS http://openbios.org/ > Mailinglist: http://lists.openbios.org/mailman/listinfo > Free your System - May the Forth be with you > > William Hahne > > -- > OpenBIOS http://openbios.org/ > Mailinglist: http://lists.openbios.org/mailman/listinfo > Free your System - May the Forth be with you

2 1

Re: [OpenBIOS] [PATCH 2/10] Ignore extraneous partitions
by Natalia Portillo 15 Aug '11

15 Aug '11

Hi, There is no documentation saying that but you may freely interpret as those things are NOT partitions in apple speaking, they are ALWAYS called just drivers. El 10/08/2011, a las 16:23, William Hahne escribió: > On Wed, Aug 10, 2011 at 5:48 AM, Mark Cave-Ayland <mark.cave-ayland(a)siriusit.co.uk> wrote: > On 09/08/11 22:54, William Hahne wrote: > > BootX will only check the first few partitions from mac-parts to find > the Mac OS partition. So it must expect drivers and void partitions to > be ignored. This patch makes it so that if you specify the partition > cd:1 and partition 1 is a driver it will keep checking partitions until > reaching the first non-driver and non-void partition. > > Index: packages/mac-parts.c > =================================================================== > --- packages/mac-parts.c (revision 1041) > +++ packages/mac-parts.c (working copy) > @@ -200,15 +203,26 @@ > } else { > /* Another partition was explicitly requested */ > - SEEK( bs * parnum ); > - READ( &par, sizeof(par) ); > + > + /* We have to find the first valid partition corresponding to the > given number. > + This is because Apple sometimes includes a bunch of extra partitions > that > + BootX expects to be ignored */ > + while (parnum < par.pmMapBlkCnt) { > + SEEK( bs * parnum ); > + READ( &par, sizeof(par) ); > - if( (__be32_to_cpu(par.pmPartStatus) & kPartitionAUXIsValid) && > - (__be32_to_cpu(par.pmPartStatus) & kPartitionAUXIsAllocated) && > - (__be32_to_cpu(par.pmPartStatus) & kPartitionAUXIsReadable) ) { > + /* Check if valid, also device driver partitions are expected to be > ignored */ > + if( (__be32_to_cpu(par.pmPartStatus) & kPartitionAUXIsValid) && > + (__be32_to_cpu(par.pmPartStatus) & kPartitionAUXIsAllocated) && > + (__be32_to_cpu(par.pmPartStatus) & kPartitionAUXIsReadable) && > + !(__be32_to_cpu(par.pmPartStatus) & kPartitionIsRealDeviceDriver)) { > - offs = (long long)__be32_to_cpu(par.pmPyPartStart) * bs; > - size = (long long)__be32_to_cpu(par.pmPartBlkCnt) * bs; > + offs = (long long)__be32_to_cpu(par.pmPyPartStart) * bs; > + size = (long long)__be32_to_cpu(par.pmPartBlkCnt) * bs; > + break; > + } > + > + parnum++; > } > } > > I remember last time I reworked this, I had to spend a lot of time reading the Apple HFS documentation with regard to this. Could you add a link to the documentation on the Apple site into the commit message, and confirm whether this is something I missed which is documented or it's new behaviour that you have discoverd through testing. > > This is something I discovered through testing and carefully looking through the BootX source code. I don't know if there is documentation on this or not. > > William Hahne > > > ATB, > > Mark. > > -- > Mark Cave-Ayland - Senior Technical Architect > PostgreSQL - PostGIS > Sirius Corporation plc - control through freedom > http://www.siriusit.co.uk > t: +44 870 608 0063 > > Sirius Labs: http://www.siriusit.co.uk/labs > > -- > OpenBIOS http://openbios.org/ > Mailinglist: http://lists.openbios.org/mailman/listinfo > Free your System - May the Forth be with you > > -- > OpenBIOS http://openbios.org/ > Mailinglist: http://lists.openbios.org/mailman/listinfo > Free your System - May the Forth be with you

2 1

Re: [OpenBIOS] [PATCH 10/10] Adding filll Forth primitive
by Mark Cave-Ayland 15 Aug '11

15 Aug '11

On 10/08/11 16:50, William Hahne wrote: > This looks reasonably straightforward - again, can you add a > reference to the documentation for this word as part of the commit > message? > > I wish I could. I had to do reverse engineer it from Apple's OF > implementation. I don't believe it is an official OF word. Right that makes sense. Looking closer at the code, it strikes me that this particular word should be written in Forth rather than C (i.e. we don't really want to have to drop into C unless we really have to). After that I can't think there would be much else the PPC maintainers would object to. ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

1 0

Re: [OpenBIOS] [PATCH 8/10] Check that stdout variable is not null
by Mark Cave-Ayland 15 Aug '11

15 Aug '11

On 10/08/11 16:44, William Hahne wrote: > Hmmm isn't this just hiding another bug which is that the stdout > variable/defer is being set? > > I think it is a bug in BootX (at least I would call it a bug.) Modifying > BootX isn't a particularly realistic option so the workaround is necessary. Right so it definitely looks as if BootX is overriding the default value in arch/ppc/qemu/init.c. Do you have any suitable DEBUG_CIF traces for us to look at? ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

1 0

Re: [OpenBIOS] [Qemu-devel] [PATCH] hw/scsi-bus.c: Fix use of uninitialised variable
by Paolo Bonzini 14 Aug '11

14 Aug '11

On 08/13/2011 07:29 PM, Blue Swirl wrote: > On Fri, Aug 12, 2011 at 7:22 PM, Blue Swirl<blauwirbel(a)gmail.com> wrote: >> On Fri, Aug 12, 2011 at 4:49 PM, Peter Maydell<peter.maydell(a)linaro.org> wrote: >>> Don't use req before it has been initialised in scsi_req_new(). >>> This fixes a compile failure due to gcc complaining about this. >> >> It fixes a crash if the warning is ignored: >> Configuration device id QEMU version 1 machine id 32 Please apply it. > This is due to division by zero in OpenBIOS drivers/esp.c. Bisecting > reveals that this is due to c7b488721d6aafe32994ac63f8d690ae6d4729fa, > SCSI devices now report Unit Attention status after reset. OpenBIOS > does not handle this case and fails (block size is 0). > > First OpenBIOS issues Inquiry command, then if a device is present, > Read Capacity. I tried adding Request Sense command after Inquiry, but > then QEMU crashes: Thanks, I'll look into this. However, not that Inquiry will not report unit attention. The right fix is to send a Test Unit Ready after Inquiry and until it passes (and fail after 3/4 tries). Paolo

1 0

Re: [OpenBIOS] [Qemu-devel] [PATCH] hw/scsi-bus.c: Fix use of uninitialised variable
by Blue Swirl 13 Aug '11

13 Aug '11

On Fri, Aug 12, 2011 at 7:22 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote: > On Fri, Aug 12, 2011 at 4:49 PM, Peter Maydell <peter.maydell(a)linaro.org> wrote: >> Don't use req before it has been initialised in scsi_req_new(). >> This fixes a compile failure due to gcc complaining about this. > > It fixes a crash if the warning is ignored: > Configuration device id QEMU version 1 machine id 32 > > Program received signal SIGSEGV, Segmentation fault. > scsi_req_new (d=0x15e46b0, tag=0x0, lun=0x0, buf=0x7fffffffde41 "\022", > hba_private=<value optimized out>) at /src/qemu/hw/scsi-bus.c:375 > 375 if (req->cmd.lba != -1) { > (gdb) bt > #0 scsi_req_new (d=0x15e46b0, tag=0x0, lun=0x0, buf=0x7fffffffde41 "\022", > hba_private=<value optimized out>) at /src/qemu/hw/scsi-bus.c:375 > #1 0x000000000052c6ef in do_busid_cmd (s=0x15e2790, buf=0x0, > busid=<value optimized out>) at /src/qemu/hw/esp.c:247 > #2 0x000000000052cc5d in do_cmd (s=0x15e2790) at /src/qemu/hw/esp.c:270 > #3 handle_satn (s=0x15e2790) at /src/qemu/hw/esp.c:284 > #4 0x000000000052d174 in esp_mem_writeb (opaque=0x15e2790, > addr=<value optimized out>, val=0xc2) at /src/qemu/hw/esp.c:640 > #5 0x000000004003d1f5 in ?? () > #6 0x0000000001632330 in ?? () > #7 0x0000000001632280 in ?? () > #8 0x00007fffffffe180 in ?? () > #9 0x3d3d87e90d932400 in ?? () > #10 0x00007ffff7eefd00 in ?? () > #11 0x00000000004dc558 in tb_reset_jump_recursive2 (tb=0xffee100c) > at /src/qemu/exec.c:1389 > #12 tb_reset_jump_recursive (tb=0xffee100c) at /src/qemu/exec.c:1395 > #13 0x000000000040bdea in qemu_notify_event () at /src/qemu/cpus.c:616 > #14 <signal handler called> > #15 0x00000000004de681 in cpu_sparc_exec (env=0x1059600) > at /src/qemu/cpu-exec.c:528 > #16 0x000000000040c1fc in tcg_cpu_exec () at /src/qemu/cpus.c:1064 > #17 cpu_exec_all () at /src/qemu/cpus.c:1105 > #18 0x0000000000519497 in main_loop (argc=<value optimized out>, > argv=<value optimized out>, envp=<value optimized out>) > at /src/qemu/vl.c:1392 > #19 main (argc=<value optimized out>, argv=<value optimized out>, > envp=<value optimized out>) at /src/qemu/vl.c:3356 > (gdb) p req > $1 = <value optimized out> > (gdb) p req->cmd > Cannot access memory at address 0x28 > (gdb) p req->cmd.lba > Cannot access memory at address 0x48 > >> Signed-off-by: Peter Maydell <peter.maydell(a)linaro.org> >> --- >> hw/scsi-bus.c | 2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/hw/scsi-bus.c b/hw/scsi-bus.c >> index f2af6cd..559d5a4 100644 >> --- a/hw/scsi-bus.c >> +++ b/hw/scsi-bus.c >> @@ -372,7 +372,7 @@ SCSIRequest *scsi_req_new(SCSIDevice *d, uint32_t tag, uint32_t lun, >> } else { >> trace_scsi_req_parsed(d->id, lun, tag, buf[0], >> cmd.mode, cmd.xfer); >> - if (req->cmd.lba != -1) { >> + if (cmd.lba != -1) { >> trace_scsi_req_parsed_lba(d->id, lun, tag, buf[0], >> cmd.lba); >> } Something is very wrong with SCSI. OpenBIOS can't boot anymore: Configuration device id QEMU version 1 machine id 32 CPUs: 1 x FMI,MB86904 UUID: 00000000-0000-0000-0000-000000000000 Welcome to OpenBIOS v1.0 built on Jul 20 2011 21:16 Type 'help' for detailed information Trying cdrom:d... Unhandled Exception 0x0000002a PC = 0xffd10bdc NPC = 0xffd10be0 Stopping execution This is due to division by zero in OpenBIOS drivers/esp.c. Bisecting reveals that this is due to c7b488721d6aafe32994ac63f8d690ae6d4729fa, SCSI devices now report Unit Attention status after reset. OpenBIOS does not handle this case and fails (block size is 0). First OpenBIOS issues Inquiry command, then if a device is present, Read Capacity. I tried adding Request Sense command after Inquiry, but then QEMU crashes: Configuration device id QEMU version 1 machine id 32 Initializing SCSI...dma1: Revision 2 ESP at 0xffdaa230, buffer va 0xffdab000 dva 0xfe000000 done Initializing SCSI devices...do_command: id 0, cmd[0] 0x80, status 0x80 do_command: id 1, cmd[0] 0x80, status 0x80 do_command: id 2, cmd[0] 0x80, status 0x91 do_command_reply: status 0x93 do_command: id 2, cmd[0] 0x80, status 0x93 request_sense id 2 failed request_sense id 2 sense key 128 do_command: id 2, cmd[0] 0x80, status 0x91 do_command_reply: status 0x93 read_capacity id 2 bs 2048 sectors 1295228 do_command: id 2, cmd[0] 0x80, status 0x91 *** glibc detected *** /src/qemu/obj-amd64/sparc-softmmu/qemu-system-sparc: double free or corruption (out): 0x00000000016407e0 *** ======= Backtrace: ========= /lib/libc.so.6(+0x71ad6)[0x7ffff3de1ad6] /lib/libc.so.6(cfree+0x6c)[0x7ffff3de684c] /src/qemu/obj-amd64/sparc-softmmu/qemu-system-sparc[0x46b41e] /src/qemu/obj-amd64/sparc-softmmu/qemu-system-sparc[0x46b7cf] /src/qemu/obj-amd64/sparc-softmmu/qemu-system-sparc[0x46a037] /src/qemu/obj-amd64/sparc-softmmu/qemu-system-sparc[0x46b4ad] /src/qemu/obj-amd64/sparc-softmmu/qemu-system-sparc[0x52f057] /src/qemu/obj-amd64/sparc-softmmu/qemu-system-sparc[0x52f331] /src/qemu/obj-amd64/sparc-softmmu/qemu-system-sparc[0x52f95d] [0x4004113b] ======= Memory map: ======== 00400000-005fa000 r-xp 00000000 08:13 3827028 /src/qemu/obj-amd64/sparc-softmmu/qemu-system-sparc 007fa000-0080f000 rw-p 001fa000 08:13 3827028 /src/qemu/obj-amd64/sparc-softmmu/qemu-system-sparc 0080f000-00ff6000 rw-p 00000000 00:00 0 00ff6000-00ff7000 rwxp 00000000 00:00 0 00ff7000-01299000 rw-p 00000000 00:00 0 [heap] 01299000-0129a000 rw-p 00000000 00:00 0 [heap] 0129a000-012a0000 rw-p 00000000 00:00 0 [heap] 012a0000-012a1000 rw-p 00000000 00:00 0 [heap] 012a1000-01682000 rw-p 00000000 00:00 0 [heap] 40000000-40100000 rwxp 00000000 00:00 0 7fffe0000000-7fffe0021000 rw-p 00000000 00:00 0 7fffe0021000-7fffe4000000 ---p 00000000 00:00 0 7fffe708b000-7fffe70a1000 r-xp 00000000 08:11 89618 /lib/libgcc_s.so.1 7fffe70a1000-7fffe72a0000 ---p 00016000 08:11 89618 /lib/libgcc_s.so.1 7fffe72a0000-7fffe72a1000 rw-p 00015000 08:11 89618 /lib/libgcc_s.so.1 7fffe72a1000-7fffe75a2000 rw-p 00000000 00:00 0 7fffe76cf000-7fffe76d0000 rw-p 00000000 00:00 0 7fffe76d0000-7fffe7fd0000 rw-p 00000000 00:00 0 7fffe7fd0000-7fffe7fd1000 rw-p 00000000 00:00 0 7fffe81b3000-7fffe81b4000 rw-p 00000000 00:00 0 7fffe81b4000-7fffe82b4000 rw-p 00000000 00:00 0 7fffe82b4000-7fffe82b6000 rw-p 00000000 00:00 0 7fffe82b6000-7ffff02b6000 rw-p 00000000 00:00 0 7ffff02b6000-7ffff02b7000 rw-p 00000000 00:00 0 7ffff02b7000-7ffff02b8000 ---p 00000000 00:00 0 7ffff02b8000-7ffff0ab8000 rw-p 00000000 00:00 0 7ffff0ab8000-7ffff0abd000 r-xp 00000000 08:11 316801 /usr/lib/libXdmcp.so.6.0.0 7ffff0abd000-7ffff0cbc000 ---p 00005000 08:11 316801 /usr/lib/libXdmcp.so.6.0.0 7ffff0cbc000-7ffff0cbd000 rw-p 00004000 08:11 316801 /usr/lib/libXdmcp.so.6.0.0 7ffff0cbd000-7ffff0cbf000 r-xp 00000000 08:11 315723 /usr/lib/libXau.so.6.0.0 7ffff0cbf000-7ffff0ebf000 ---p 00002000 08:11 315723 /usr/lib/libXau.so.6.0.0 7ffff0ebf000-7ffff0ec0000 rw-p 00002000 08:11 315723 /usr/lib/libXau.so.6.0.0 7ffff0ec0000-7ffff0edf000 r-xp 00000000 08:11 89944 /lib/libx86.so.1 7ffff0edf000-7ffff10df000 ---p 0001f000 08:11 89944 /lib/libx86.so.1 7ffff10df000-7ffff10e1000 rw-p 0001f000 08:11 89944 /lib/libx86.so.1 7ffff10e1000-7ffff10e2000 rw-p 00000000 00:00 0 7ffff10e2000-7ffff10e5000 r-xp 00000000 08:11 312446 /usr/lib/libgpg-error.so.0.4.0 7ffff10e5000-7ffff12e4000 ---p 00003000 08:11 312446 /usr/lib/libgpg-error.so.0.4.0 7ffff12e4000-7ffff12e5000 rw-p 00002000 08:11 312446 /usr/lib/libgpg-error.so.0.4.0 7ffff12e5000-7ffff12e7000 r-xp 00000000 08:11 89690 /lib/libkeyutils.so.1.3 7ffff12e7000-7ffff14e6000 ---p 00002000 08:11 89690 /lib/libkeyutils.so.1.3 7ffff14e6000-7ffff14e7000 rw-p 00001000 08:11 89690 /lib/libkeyutils.so.1.3 7ffff14e7000-7ffff14ee000 r-xp 00000000 08:11 311226 /usr/lib/libkrb5support.so.0.1 7ffff14ee000-7ffff16ee000 ---p 00007000 08:11 311226 /usr/lib/libkrb5support.so.0.1 7ffff16ee000-7ffff16ef000 rw-p 00007000 08:11 311226 /usr/lib/libkrb5support.so.0.1 7ffff16ef000-7ffff16f2000 r-xp 00000000 08:11 89655 /lib/libcom_err.so.2.1 7ffff16f2000-7ffff18f1000 ---p 00003000 08:11 89655 /lib/libcom_err.so.2.1 7ffff18f1000-7ffff18f2000 rw-p 00002000 08:11 89655 /lib/libcom_err.so.2.1 7ffff18f2000-7ffff1917000 r-xp 00000000 08:11 311218 /usr/lib/libk5crypto.so.3.1 7ffff1917000-7ffff1b16000 ---p 00025000 08:11 311218 /usr/lib/libk5crypto.so.3.1 7ffff1b16000-7ffff1b18000 rw-p 00024000 08:11 311218 /usr/lib/libk5crypto.so.3.1 7ffff1b18000-7ffff1bd6000 r-xp 00000000 08:11 311223 /usr/lib/libkrb5.so.3.3 7ffff1bd6000-7ffff1dd5000 ---p 000be000 08:11 311223 /usr/lib/libkrb5.so.3.3 7ffff1dd5000-7ffff1de0000 rw-p 000bd000 08:11 311223 /usr/lib/libkrb5.so.3.3 7ffff1de0000-7ffff1dfc000 r-xp 00000000 08:11 312097 /usr/lib/libxcb.so.1.1.0 7ffff1dfc000-7ffff1ffb000 ---p 0001c000 08:11 312097 /usr/lib/libxcb.so.1.1.0 7ffff1ffb000-7ffff1ffc000 rw-p 0001b000 08:11 312097 /usr/lib/libxcb.so.1.1.0 7ffff1ffc000-7ffff2049000 r-xp 00000000 08:11 203809 /usr/lib/libvga.so.1.4.3 7ffff2049000-7ffff2248000 ---p 0004d000 08:11 203809 /usr/lib/libvga.so.1.4.3 7ffff2248000-7ffff2251000 rw-p 0004c000 08:11 203809 /usr/lib/libvga.so.1.4.3 7ffff2251000-7ffff225a000 rw-p 00000000 00:00 0 7ffff225a000-7ffff2270000 r-xp 00000000 08:11 311386 /usr/lib/libdirect-1.2.so.9.0.1 7ffff2270000-7ffff246f000 ---p 00016000 08:11 311386 /usr/lib/libdirect-1.2.so.9.0.1 7ffff246f000-7ffff2471000 rw-p 00015000 08:11 311386 /usr/lib/libdirect-1.2.so.9.0.1 7ffff2471000-7ffff247a000 r-xp 00000000 08:11 311381 /usr/lib/libfusion-1.2.so.9.0.1 7ffff247a000-7ffff267a000 ---p 00009000 08:11 311381 /usr/lib/libfusion-1.2.so.9.0.1 7ffff267a000-7ffff267b000 rw-p 00009000 08:11 311381 /usr/lib/libfusion-1.2.so.9.0.1 7ffff267b000-7ffff26fa000 r-xp 00000000 08:11 311384 /usr/lib/libdirectfb-1.2.so.9.0.1 7ffff26fa000-7ffff28f9000 ---p 0007f000 08:11 311384 /usr/lib/libdirectfb-1.2.so.9.0.1 7ffff28f9000-7ffff28fd000 rw-p 0007e000 08:11 311384 /usr/lib/libdirectfb-1.2.so.9.0.1 Program received signal SIGABRT, Aborted. 0x00007ffff3da2165 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. in ../nptl/sysdeps/unix/sysv/linux/raise.c (gdb) bt #0 0x00007ffff3da2165 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00007ffff3da4f70 in *__GI_abort () at abort.c:92 #2 0x00007ffff3dd827b in __libc_message (do_abort=<value optimized out>, fmt=<value optimized out>) at ../sysdeps/unix/sysv/linux/libc_fatal.c:189 #3 0x00007ffff3de1ad6 in malloc_printerr (action=0x3, str=0x7ffff3e98aa8 "double free or corruption (out)", ptr=<value optimized out>) at malloc.c:6267 #4 0x00007ffff3de684c in *__GI___libc_free (mem=<value optimized out>) at malloc.c:3739 #5 0x000000000046b41e in scsi_req_unref (req=0x16407e0) at /src/qemu/hw/scsi-bus.c:1017 #6 0x000000000046b7cf in scsi_req_complete (req=0x16407e0, status=0x0) at /src/qemu/hw/scsi-bus.c:1095 #7 0x000000000046a037 in scsi_target_read_data (req=0x16407e0) at /src/qemu/hw/scsi-bus.c:324 #8 0x000000000046b4ad in scsi_req_continue (req=0x16407e0) at /src/qemu/hw/scsi-bus.c:1029 #9 0x000000000052f057 in esp_do_dma (s=0x15e6220) at /src/qemu/hw/esp.c:385 #10 0x000000000052f331 in handle_ti (s=0x15e6220) at /src/qemu/hw/esp.c:458 #11 0x000000000052f95d in esp_mem_writeb (opaque=0x15e6220, addr=0xc, val=0x90) at /src/qemu/hw/esp.c:610 #12 0x000000004004113b in ?? () #13 0x00007ffff7f0f880 in ?? () #14 0x00000000004de6f8 in tb_reset_jump_recursive2 (tb=0xffee200c) at /src/qemu/exec.c:1389 #15 tb_reset_jump_recursive (tb=0xffee200c) at /src/qemu/exec.c:1395 #16 0x00000000004de6f8 in tb_reset_jump_recursive2 (tb=0x7ffff7f0f810) at /src/qemu/exec.c:1389 #17 tb_reset_jump_recursive (tb=0x7ffff7f0f810) at /src/qemu/exec.c:1395 #18 0x000000000040beba in qemu_notify_event () at /src/qemu/cpus.c:616 #19 <signal handler called> #20 cpu_sparc_exec (env=0x105d0a0) at /src/qemu/cpu-exec.c:558 #21 0x000000000040c2cc in tcg_cpu_exec () at /src/qemu/cpus.c:1064 #22 cpu_exec_all () at /src/qemu/cpus.c:1105 #23 0x000000000051b637 in main_loop (argc=<value optimized out>, argv=<value optimized out>, envp=<value optimized out>) at /src/qemu/vl.c:1392 #24 main (argc=<value optimized out>, argv=<value optimized out>, envp=<value optimized out>) at /src/qemu/vl.c:3356 (gdb) up #1 0x00007ffff3da4f70 in *__GI_abort () at abort.c:92 92 abort.c: No such file or directory. in abort.c (gdb) #2 0x00007ffff3dd827b in __libc_message (do_abort=<value optimized out>, fmt=<value optimized out>) at ../sysdeps/unix/sysv/linux/libc_fatal.c:189 189 ../sysdeps/unix/sysv/linux/libc_fatal.c: No such file or directory. in ../sysdeps/unix/sysv/linux/libc_fatal.c (gdb) #3 0x00007ffff3de1ad6 in malloc_printerr (action=0x3, str=0x7ffff3e98aa8 "double free or corruption (out)", ptr=<value optimized out>) at malloc.c:6267 6267 malloc.c: No such file or directory. in malloc.c (gdb) #4 0x00007ffff3de684c in *__GI___libc_free (mem=<value optimized out>) at malloc.c:3739 3739 in malloc.c (gdb) #5 0x000000000046b41e in scsi_req_unref (req=0x16407e0) at /src/qemu/hw/scsi-bus.c:1017 1017 qemu_free(req); (gdb) p *req $1 = {bus = 0x15e7888, dev = 0x15e8140, ops = 0x800f20, refcount = 0x0, tag = 0x0, lun = 0x0, status = 0x0, cmd = { buf = "\003\000\000\000\374\b\000\000\260\335\377\377\000\000\000", len = 0x6, xfer = 0xfc, lba = 0x0, mode = SCSI_XFER_FROM_DEV}, aiocb = 0x0, sense = '\000' <repeats 95 times>, sense_len = 0x0, enqueued = 0x0, hba_private = 0x0, next = {tqe_next = 0x0, tqe_prev = 0x15e8250}} The same patched OpenBIOS boots nicely with 4333979e3d8c129953bba36ed87ce543d33cbea1: Configuration device id QEMU version 1 machine id 32 Initializing SCSI...dma1: Revision 2 ESP at 0xffdaa230, buffer va 0xffdab000 dva 0xfe000000 done Initializing SCSI devices...do_command: id 0, cmd[0] 0x80, status 0x80 do_command: id 1, cmd[0] 0x80, status 0x80 do_command: id 2, cmd[0] 0x80, status 0x91 do_command_reply: status 0x93 do_command: id 2, cmd[0] 0x80, status 0x91 do_command_reply: status 0x93 request_sense id 2 sense key 240 do_command: id 2, cmd[0] 0x80, status 0x91 do_command_reply: status 0x93 read_capacity id 2 bs 2048 sectors 1295228 do_command: id 2, cmd[0] 0x80, status 0x91 do_command_reply: status 0x93 request_sense id 2 sense key 240 SCSI DRIVE @ffdaa2c0: id: 2 media: cdrom media: cd model: QEMU CD-ROM sectors: 1295228 present: 1 bs: 2048 do_command: id 3, cmd[0] 0x80, status 0x80 do_command: id 4, cmd[0] 0x80, status 0x80 do_command: id 5, cmd[0] 0x80, status 0x80 do_command: id 6, cmd[0] 0x80, status 0x80 do_command: id 7, cmd[0] 0x80, status 0x80 add_alias dev "/iommu/sbus/espdma/esp/sd@2,0" = alias "cdrom" add_alias dev "/iommu/sbus/espdma/esp/sd@2,0" = alias "cd" add_alias dev "/iommu/sbus/espdma/esp/sd@2,0" = alias "cdrom0" add_alias dev "/iommu/sbus/espdma/esp/sd@2,0" = alias "cd0" add_alias dev "/iommu/sbus/espdma/esp/sd@2,0" = alias "sd(0,2,0)" add_alias dev "/iommu/sbus/espdma/esp/sd@2,0" = alias "sd(0,2,0)@0,0" done CPUs: 1 x FMI,MB86904 UUID: 00000000-0000-0000-0000-000000000000 Welcome to OpenBIOS v1.0 built on Jul 20 2011 21:16 Type 'help' for detailed information Trying cdrom:d... opening drive 2 args d ob_sd_read_blocks id 2 ffdefb60 block=0 n=1 ob_sd_read_sector id 2 sector=0 [New Thread 0x7fffe72a0700 (LWP 12653)] do_command: id 2, cmd[0] 0x80, status 0x91 do_command_reply: status 0x93 ob_sd_read_blocks id 2 ffdefb60 block=0 n=1 ob_sd_read_sector id 2 sector=0 do_command: id 2, cmd[0] 0x80, status 0x91 do_command_reply: status 0x93 Trying cdrom... opening drive 2 args <NULL> ob_sd_read_blocks id 2 ffdefb60 block=0 n=1 ob_sd_read_sector id 2 sector=0 do_command: id 2, cmd[0] 0x80, status 0x91 do_command_reply: status 0x93 ob_sd_read_blocks id 2 ffdefb60 block=0 n=1 ob_sd_read_sector id 2 sector=0 do_command: id 2, cmd[0] 0x80, status 0x91 do_command_reply: status 0x93 ob_sd_read_blocks id 2 ffdc32c0 block=2 n=2 ob_sd_read_sector id 2 sector=0 etc. Here's the patch (WIP) to OpenBIOS if someone wants to try: diff --git a/drivers/esp.c b/drivers/esp.c index 78478f6..2766e87 100644 --- a/drivers/esp.c +++ b/drivers/esp.c @@ -28,6 +28,7 @@ #define BUFSIZE 4096 +#define CONFIG_DEBUG_ESP #ifdef CONFIG_DEBUG_ESP #define DPRINTF(fmt, args...) \ do { printk(fmt , ##args); } while (0) @@ -176,12 +177,14 @@ read_capacity(esp_private_t *esp, sd_private_t *sd) if (do_command(esp, sd, 11, 8)) { sd->sectors = 0; sd->bs = 0; - + DPRINTF("read_capacity id %d failed\n", sd->id); return 0; } sd->bs = (esp->buffer[4] << 24) | (esp->buffer[5] << 16) | (esp->buffer[6] << 8) | esp->buffer[7]; sd->sectors = ((esp->buffer[0] << 24) | (esp->buffer[1] << 16) | (esp->buffer[2] << 8) | esp->buffer[3]) * (sd->bs / 512); + DPRINTF("read_capacity id %d bs %d sectors %d\n", sd->id, sd->bs, + sd->sectors); return 1; } @@ -224,6 +227,26 @@ inquiry(esp_private_t *esp, sd_private_t *sd) } +static unsigned int +request_sense(esp_private_t *esp, sd_private_t *sd) +{ + /* Setup command = Request Sense */ + memset(esp->buffer, 0, 6); + esp->buffer[0] = 0x80; + esp->buffer[1] = REQUEST_SENSE; + + esp->buffer[5] = 252; + + if (do_command(esp, sd, 7, 252)) { + DPRINTF("request_sense id %d failed\n", sd->id); + DPRINTF("request_sense id %d sense key %d\n", sd->id, esp->buffer[0]); + return 0; + } + + DPRINTF("request_sense id %d sense key %d\n", sd->id, esp->buffer[0]); + return 1; +} + static void ob_sd_read_blocks(sd_private_t **sd) { @@ -478,7 +501,9 @@ ob_esp_init(unsigned int slot, uint64_t base, unsigned long espoffset, esp->sd[id].id = id; if (!inquiry(esp, &esp->sd[id])) continue; + request_sense(esp, &esp->sd[id]); read_capacity(esp, &esp->sd[id]); + request_sense(esp, &esp->sd[id]); #ifdef CONFIG_DEBUG_ESP dump_drive(&esp->sd[id]);

1 0

[PATCH v2] [RFC] More complete PowerPC OpenFirmware emulation -- adding bus-frequency
by Alexander von Gluck 10 Aug '11

10 Aug '11

The patch from before with everything extra stripped due to the push back: Thanks! -- Alexander von Gluck Index: include/arch/common/fw_cfg.h =================================================================== --- include/arch/common/fw_cfg.h (revision 1046) +++ include/arch/common/fw_cfg.h (working copy) @@ -44,6 +44,7 @@ #define FW_CFG_PPC_IS_KVM (FW_CFG_ARCH_LOCAL + 0x05) #define FW_CFG_PPC_KVM_HC (FW_CFG_ARCH_LOCAL + 0x06) #define FW_CFG_PPC_KVM_PID (FW_CFG_ARCH_LOCAL + 0x07) +#define FW_CFG_PPC_BUSFREQ (FW_CFG_ARCH_LOCAL + 0x08) #define FW_CFG_INVALID 0xffff Index: arch/ppc/qemu/init.c =================================================================== --- arch/ppc/qemu/init.c (revision 1046) +++ arch/ppc/qemu/init.c (working copy) @@ -260,6 +260,11 @@ push_str("clock-frequency"); fword("property"); + PUSH(fw_cfg_read_i32(FW_CFG_PPC_BUSFREQ)); + fword("encode-int"); + push_str("bus-frequency"); + fword("property"); + push_str("running"); fword("encode-string"); push_str("state");

1 0

Re: [OpenBIOS] [PATCH 1/10] Dummy get-key-map in keyboard device package
by Andreas Färber 10 Aug '11

10 Aug '11

Am 10.08.2011 um 19:53 schrieb Blue Swirl: > On Tue, Aug 9, 2011 at 9:54 PM, William Hahne <will07c5(a)gmail.com> > wrote: >> "get-key-map" is a Forth word that provides a map of all the keys >> currently >> pressed on the keyboard. Since it is only used by BootX to >> determine if one >> of the shortcuts for verbose or single user mode is pressed. It is >> a waste >> of time to provide a full implementation. This just hands out a >> dummy key >> map which specifies verbose mode. >> Index: drivers/adb_kbd.c >> =================================================================== >> --- drivers/adb_kbd.c (revision 1041) >> +++ drivers/adb_kbd.c (working copy) >> @@ -566,3 +569,18 @@ >> } >> PUSH(i); >> } >> + >> +static unsigned char fake_keymap[32] = { > > Can this be 'const'? > >> + 0x00, 0x00, 0x00, 0x40, 0x00, 0x00, 0x00, 0x00, >> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, >> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, >> + 0x00, 0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00 >> +}; >> + >> +static void keyboard_get_key_map(void) >> +{ >> + /* This is a bit of a hack since BootX requires a get-key-map word. >> + In the future this should be changed to give the actual current >> keymap, >> + but since this only effects keyboard input in BootX it isn't a >> priority. */ >> + PUSH( (int)fake_keymap ); > > 'long' would not truncate on 64 bit host with 64 bit cells. pointer2cell() or so would be even better. :) Andreas

1 0

Re: [OpenBIOS] [PATCH 1/10] Dummy get-key-map in keyboard device package
by William Hahne 10 Aug '11

10 Aug '11

On Wed, Aug 10, 2011 at 12:53 PM, Blue Swirl <blauwirbel(a)gmail.com> wrote: > On Tue, Aug 9, 2011 at 9:54 PM, William Hahne <will07c5(a)gmail.com> wrote: > > "get-key-map" is a Forth word that provides a map of all the keys > currently > > pressed on the keyboard. Since it is only used by BootX to determine if > one > > of the shortcuts for verbose or single user mode is pressed. It is a > waste > > of time to provide a full implementation. This just hands out a dummy key > > map which specifies verbose mode. > > Index: drivers/adb_kbd.c > > =================================================================== > > --- drivers/adb_kbd.c (revision 1041) > > +++ drivers/adb_kbd.c (working copy) > > @@ -43,10 +43,13 @@ > > > > static void keyboard_read(void); > > > > +static void keyboard_get_key_map(void); > > + > > NODE_METHODS( keyboard ) = { > > { "open", keyboard_open }, > > { "close", keyboard_close }, > > { "read", keyboard_read }, > > + { "get-key-map", keyboard_get_key_map }, > > }; > > > > /* VT100 escape sequences */ > > @@ -566,3 +569,18 @@ > > } > > PUSH(i); > > } > > + > > +static unsigned char fake_keymap[32] = { > > Can this be 'const'? > Yes > > > + 0x00, 0x00, 0x00, 0x40, 0x00, 0x00, 0x00, 0x00, > > + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > > + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > > + 0x00, 0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00 > > +}; > > + > > +static void keyboard_get_key_map(void) > > +{ > > + /* This is a bit of a hack since BootX requires a get-key-map word. > > + In the future this should be changed to give the actual current > > keymap, > > + but since this only effects keyboard input in BootX it isn't a > > priority. */ > > + PUSH( (int)fake_keymap ); > > 'long' would not truncate on 64 bit host with 64 bit cells. > > Oops, thanks for catching that. :) Revised patch at the bottom. > > +} > > -- > > OpenBIOS http://openbios.org/ > > Mailinglist: http://lists.openbios.org/mailman/listinfo > > Free your System - May the Forth be with you > > > > -- > OpenBIOS http://openbios.org/ > Mailinglist: http://lists.openbios.org/mailman/listinfo > Free your System - May the Forth be with you > Index: drivers/adb_kbd.c =================================================================== --- drivers/adb_kbd.c (revision 1046) +++ drivers/adb_kbd.c (working copy) @@ -43,10 +43,13 @@ static void keyboard_read(void); +static void keyboard_get_key_map(void); + NODE_METHODS( keyboard ) = { { "open", keyboard_open }, { "close", keyboard_close }, { "read", keyboard_read }, + { "get-key-map", keyboard_get_key_map }, }; /* VT100 escape sequences */ @@ -566,3 +569,18 @@ } PUSH(i); } + +static const unsigned char fake_keymap[32] = { + 0x00, 0x00, 0x00, 0x40, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00 +}; + +static void keyboard_get_key_map(void) +{ + /* This is a bit of a hack since BootX requires a get-key-map word. + In the future this should be changed to give the actual current keymap, + but since this only effects keyboard input in BootX it isn't a priority. */ + PUSH( (ucell)fake_keymap ); +}

1 0

[PATCH] More complete PowerPC OpenFirmware emulation -- adding bus-frequency
by Alexander von Gluck 10 Aug '11

10 Aug '11

Below is a quick patch to introduce the bus-frequency field for each CPU. This exists on every Apple OpenFirmware i've seen and is expected on Haiku OS. The change to config/scripts/switch-arch isn't required but lets you compile openbios using Haiku's PowerPC cross-compiler. Also included is a extra tracing line for troubleshooting MMU issues. Index: include/arch/common/fw_cfg.h =================================================================== --- include/arch/common/fw_cfg.h (revision 1046) +++ include/arch/common/fw_cfg.h (working copy) @@ -41,9 +41,10 @@ #define FW_CFG_PPC_DEPTH (FW_CFG_ARCH_LOCAL + 0x02) #define FW_CFG_PPC_TBFREQ (FW_CFG_ARCH_LOCAL + 0x03) #define FW_CFG_PPC_CPUFREQ (FW_CFG_ARCH_LOCAL + 0x04) -#define FW_CFG_PPC_IS_KVM (FW_CFG_ARCH_LOCAL + 0x05) -#define FW_CFG_PPC_KVM_HC (FW_CFG_ARCH_LOCAL + 0x06) -#define FW_CFG_PPC_KVM_PID (FW_CFG_ARCH_LOCAL + 0x07) +#define FW_CFG_PPC_IS_KVM (FW_CFG_ARCH_LOCAL + 0x05) +#define FW_CFG_PPC_KVM_HC (FW_CFG_ARCH_LOCAL + 0x06) +#define FW_CFG_PPC_KVM_PID (FW_CFG_ARCH_LOCAL + 0x07) +#define FW_CFG_PPC_BUSFREQ (FW_CFG_ARCH_LOCAL + 0x08) #define FW_CFG_INVALID 0xffff Index: config/scripts/switch-arch =================================================================== --- config/scripts/switch-arch (revision 1046) +++ config/scripts/switch-arch (working copy) @@ -97,7 +97,7 @@ select_prefix() { - for TARGET in ${1}-linux-gnu- ${1}-linux- ${1}-elf- ${1}-eabi- + for TARGET in ${1}-linux-gnu- ${1}-linux- ${1}-elf- ${1}-eabi- ${1}-apple-haiku- do if type ${TARGET}gcc > /dev/null 2>&1 then Index: arch/ppc/qemu/init.c =================================================================== --- arch/ppc/qemu/init.c (revision 1046) +++ arch/ppc/qemu/init.c (working copy) @@ -260,6 +260,11 @@ push_str("clock-frequency"); fword("property"); + PUSH(fw_cfg_read_i32(FW_CFG_PPC_BUSFREQ)); + fword("encode-int"); + push_str("bus-frequency"); + fword("property"); + push_str("running"); fword("encode-string"); push_str("state"); Index: drivers/iommu.c =================================================================== --- drivers/iommu.c (revision 1046) +++ drivers/iommu.c (working copy) @@ -129,6 +129,7 @@ /* Tremendous alignment causes great waste... */ ptsize = (vasize / PAGE_SIZE) * sizeof(int); ret = ofmem_posix_memalign((void *)&ptab, ptsize, ptsize); + DPRINTF("Allocated IOMMU @ %p\n", (void *)&ptab); if (ret != 0) { DPRINTF("Cannot allocate IOMMU table [0x%x]\n", ptsize); for (;;) { }

6 9

Re: [OpenBIOS] [PATCH 1/10] Dummy get-key-map in keyboard device package
by Blue Swirl 10 Aug '11

10 Aug '11

On Tue, Aug 9, 2011 at 9:54 PM, William Hahne <will07c5(a)gmail.com> wrote: > "get-key-map" is a Forth word that provides a map of all the keys currently > pressed on the keyboard. Since it is only used by BootX to determine if one > of the shortcuts for verbose or single user mode is pressed. It is a waste > of time to provide a full implementation. This just hands out a dummy key > map which specifies verbose mode. > Index: drivers/adb_kbd.c > =================================================================== > --- drivers/adb_kbd.c (revision 1041) > +++ drivers/adb_kbd.c (working copy) > @@ -43,10 +43,13 @@ > > static void keyboard_read(void); > > +static void keyboard_get_key_map(void); > + > NODE_METHODS( keyboard ) = { > { "open", keyboard_open }, > { "close", keyboard_close }, > { "read", keyboard_read }, > + { "get-key-map", keyboard_get_key_map }, > }; > > /* VT100 escape sequences */ > @@ -566,3 +569,18 @@ > } > PUSH(i); > } > + > +static unsigned char fake_keymap[32] = { Can this be 'const'? > + 0x00, 0x00, 0x00, 0x40, 0x00, 0x00, 0x00, 0x00, > + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > + 0x00, 0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00 > +}; > + > +static void keyboard_get_key_map(void) > +{ > + /* This is a bit of a hack since BootX requires a get-key-map word. > + In the future this should be changed to give the actual current > keymap, > + but since this only effects keyboard input in BootX it isn't a > priority. */ > + PUSH( (int)fake_keymap ); 'long' would not truncate on 64 bit host with 64 bit cells. > +} > -- > OpenBIOS http://openbios.org/ > Mailinglist: http://lists.openbios.org/mailman/listinfo > Free your System - May the Forth be with you >

1 0

Re: [OpenBIOS] [PATCH 9/10] Divide by zero check
by Andreas Färber 10 Aug '11

10 Aug '11

Am 10.08.2011 um 17:48 schrieb William Hahne: > On Wed, Aug 10, 2011 at 6:00 AM, Mark Cave-Ayland <mark.cave-ayland(a)siriusit.co.uk > > wrote: >> On 09/08/11 22:55, William Hahne wrote: >> >>> It is possible for BootX to purposefully divide by zero expecting >>> 0 as >>> the result. >>> >>> Index: kernel/forth.c >>> =================================================================== >>> --- kernel/forth.c (revision 1041) >>> +++ kernel/forth.c (working copy) >>> @@ -1157,6 +1157,12 @@ >>> { >>> const ucell b = POP(); >>> const ducell a = DPOP(); >>> + >>> + if (b == 0) { // can't divide by zero >>> + PUSH(0); >>> + DPUSH(0); >>> + return; >>> + } >>> #ifdef NEED_FAKE_INT128_T >>> if (a.hi != 0) { >>> fprintf(stderr, "mudivmod called (0x%016llx %016llx / >>> 0x%016llx)\n", >> >> There is something wrong here: nothing will purposefully divide by >> zero as it will invoke a trap somewhere. Again, I think this is >> hiding another bug somewhere and is not necessarily the correct fix. > > You would be surprised then, if you type "0 0 /" into a OF mac you > will get 0. I thought it was a bug as well at first but after > carefully looking at the source code for BootX I found that it > wasn't. This is probably just a peculiarity of Apple's OF > implementation. I'd rather think this is an architectural difference: On ppc, divwo sets the OV bit in XER but divw doesn't, PowerISA 2.06B saying that the result of the division is undefined in both cases. On POWER5 I do get zero as well, so it's not just Apple. 0 > 0 0 / ok 1 > . 0 ok I'd suggest to stick the new code fragment into an appropriate ppc #ifdef if sparc does it differently. Andreas

2 1

Re: [OpenBIOS] [PATCH 5/10] Add draw-rectangle to the display package
by Mark Cave-Ayland 10 Aug '11

10 Aug '11

On 09/08/11 22:54, William Hahne wrote: > While not necessary for BootX to function this allows the Apple logo to > be displayed during boot time. > > Index: packages/video.c > =================================================================== > --- packages/video.c (revision 1041) > +++ packages/video.c (working copy) > @@ -281,6 +281,42 @@ > fill_rect( color_ind, x, y, w, h ); > } > +static void > +video_draw_rect( void ) > +{ > + int h = POP(); > + int w = POP(); > + int y = POP(); > + int x = POP(); > + unsigned char* img = (unsigned char*)cell2pointer(POP()); > + char *pp; > + > + if (!video.has_video || x < 0 || y < 0 || w <= 0 || h <= 0 || > + x + w > video.fb.w || y + h > video.fb.h) > + return; > + > + pp = (char*)video.fb.mphys + video.fb.rb * y; > + for( ; h--; pp += video.fb.rb ) { > + int ww = w; > + > + if( video.fb.depth == 24 || video.fb.depth == 32 ) { > + unsigned long *p = (unsigned long*)pp + x; > + while( ww-- ) > + *p++ = get_color(*img++); > + } else if( video.fb.depth == 16 || video.fb.depth == 15 ) { > + unsigned short *p = (unsigned short*)pp + x; > + while( ww-- ) > + *p++ = get_color(*img++); > + } else { > + char *p = (char *)((unsigned short*)pp + x); > + > + while( ww-- ) > + *p++ = get_color(*img++); > + } > + } > + > +} > + > /* ( addr len -- actual ) */ > static void > video_write(void) > @@ -299,6 +335,7 @@ > {"dimensions", video_dimensions }, > {"set-colors", video_set_colors }, > {"fill-rectangle", video_fill_rect }, > + {"draw-rectangle", video_draw_rect }, > {"color!", video_color_bang }, > {"write", video_write }, > }; This is interesting, since although I can't find draw-rectangle in the OF specification, neither can I find fill-rectangle which is already there. Perhaps there is part of the OF PPC supplement? ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

3 2

Re: [OpenBIOS] [PATCH 10/10] Adding filll Forth primitive
by Mark Cave-Ayland 10 Aug '11

10 Aug '11

On 09/08/11 22:55, William Hahne wrote: > This is a forth primitive that is required by BootX. It just fills some > specified memory address and length with longs. > > > Index: kernel/forth.c > =================================================================== > --- kernel/forth.c (revision 1041) > +++ kernel/forth.c (working copy) > @@ -1610,6 +1616,20 @@ > memset(src, value, count); > } > +/* > + * filll ( addr len byte -- ) > + */ > +static void filll(void) > +{ > + ucell value = POP(); > + ucell count = POP(); > + ucell *dest = (ucell *)cell2pointer(POP()); > + > + int i; > + for (i = 0; i <= count / 4; i++) { > + dest[i] = value; > + } > +} > /* > * unaligned-w@ ( addr -- w ) > @@ -1963,4 +1983,5 @@ > do_encode_file, /* $encode-file */ > do_debug_xt, /* (debug */ > do_debug_off, /* (debug-off) */ > + filll /* filll */ > }; > Index: kernel/bootstrap.c > =================================================================== > --- kernel/bootstrap.c (revision 1041) > +++ kernel/bootstrap.c (working copy) > @@ -89,7 +89,7 @@ > "here", "here!", "dobranch", "do?branch", "unaligned-w@", > "unaligned-w!", "unaligned-l@", "unaligned-l!", "ioc@", "iow@", > "iol@", "ioc!", "iow!", "iol!", "i", "j", "call", "sys-debug", > - "$include", "$encode-file", "(debug", "(debug-off)" > + "$include", "$encode-file", "(debug", "(debug-off)", "filll" > }; > /* This looks reasonably straightforward - again, can you add a reference to the documentation for this word as part of the commit message? ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

2 1

Re: [OpenBIOS] [PATCH 9/10] Divide by zero check
by Mark Cave-Ayland 10 Aug '11

10 Aug '11

On 09/08/11 22:55, William Hahne wrote: > It is possible for BootX to purposefully divide by zero expecting 0 as > the result. > > Index: kernel/forth.c > =================================================================== > --- kernel/forth.c (revision 1041) > +++ kernel/forth.c (working copy) > @@ -1157,6 +1157,12 @@ > { > const ucell b = POP(); > const ducell a = DPOP(); > + > + if (b == 0) { // can't divide by zero > + PUSH(0); > + DPUSH(0); > + return; > + } > #ifdef NEED_FAKE_INT128_T > if (a.hi != 0) { > fprintf(stderr, "mudivmod called (0x%016llx %016llx / > 0x%016llx)\n", There is something wrong here: nothing will purposefully divide by zero as it will invoke a trap somewhere. Again, I think this is hiding another bug somewhere and is not necessarily the correct fix. ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

2 1

Re: [OpenBIOS] [PATCH 8/10] Check that stdout variable is not null
by Mark Cave-Ayland 10 Aug '11

10 Aug '11

On 09/08/11 22:55, William Hahne wrote: > BootX will sometimes set the stdout variable to null and then > subsequently call io-emit which can eventually result in an infinite loop. > > Index: forth/admin/iocontrol.fs > =================================================================== > --- forth/admin/iocontrol.fs (revision 1041) > +++ forth/admin/iocontrol.fs (working copy) > @@ -80,6 +80,7 @@ > ; > : io-emit ( char -- ) > + stdout @ 0= if drop exit then \ make sure stdout pointer is not null > io-out-char c! > io-out-char 1 " write" stdout @ $call-method drop > ; Hmmm isn't this just hiding another bug which is that the stdout variable/defer is being set? ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

2 1

Re: [OpenBIOS] [PATCH 7/10] Apple local variables implementation in Forth
by Mark Cave-Ayland 10 Aug '11

10 Aug '11

On 09/08/11 22:55, William Hahne wrote: > This is an implementation of Apple local variables which is required to > execute the Forth scripts in BootX > > Index: forth/bootstrap/bootstrap.fs > =================================================================== > --- forth/bootstrap/bootstrap.fs (revision 1041) > +++ forth/bootstrap/bootstrap.fs (working copy) > @@ -1413,10 +1413,135 @@ > here last @ , latest ! \ write backlink and set latest > ; > +\ > +\ Defer required by BootX > +\ > +defer spin > + > +\ > +\ Local Variables (Apple specific) > +\ > + > +\ > +: has-locals ( -- true/false ) > + skipws > + ib >in @ + c@ 7b <> > + if false exit then > + ib >in @ + 1+ c@ 20 > > + if false exit then > + > + true > + ; > + > +: comp-str-char ( str len char -- true/false ) > + swap 1 <> if 2drop false exit then > + swap c@ <> if false exit then > + true > + ; > + > +variable locals_wordlist > +variable locals_state \ 0 - reading args > + \ 1 - ; > + \ 2 - reading vars > +: read-locals ( -- addr0 .. addrN addrCount ) > + has-locals > + not if 0 false exit then \ no locals > + > + 0 locals_state ! > + 0 >r > + > + s" get-current" $find drop execute > + s" wordlist" $find drop execute > + dup locals_wordlist ! > + s" set-current" $find drop execute > + > + parse-word 2drop \ ditch the { > + > + begin > + parse-word > + > + 2dup 3b comp-str-char \ check for ; > + if 1 locals_state ! then > + > + 2dup 7d comp-str-char \ check for } > + not > + while > + locals_state @ 1 <> if \ the ; is not a local variable so ignore it > + header > + > + locals_state @ 0= if \ only save the address if it is an arg > + r> > + here na1+ >r > + 1+ >r > + then > + > + 3 , 0 , > + reveal > + else \ if we hit a ; then move to next state > + 2drop > + 2 locals_state ! > + then > + repeat > + > + 2drop > + > + s" set-current" $find drop execute > + > + r> 0 > + begin > + 2dup > + > > + while > + r> -rot > + 1+ > + repeat > + > + drop > + > + true > + ; > + > +: begin-locals ( addr0 .. addrN count hasLocals -- ) > + not if drop exit then > + > + dup 0> if > + 0 do > + ['] (lit) , , ['] ! , > + loop > + else drop then > + > + s" get-order" $find drop execute > + locals_wordlist @ > + swap 1+ > + s" set-order" $find drop execute > + ; > + > +: end-locals ( -- ) > + locals_wordlist @ 0= if exit then > + > + 0 locals_wordlist ! > + > + s" get-order" $find drop execute > + swap drop 1- > + s" set-order" $find drop execute > + ; > + > +: -> parse-word $find drop na1+ > + ['] (lit) , , ['] ! , > + ; immediate > + > +\ > +\ 7.3.9.1 Defining words > +\ > + > : : > - parse-word header > - 1 , ] > + parse-word >r >r > + read-locals > + r> r> header > + 1 , > + begin-locals > + ] > ; > : :noname > @@ -1426,6 +1551,7 @@ > ; > : ; > + end-locals > ['] (semis) , reveal ['] [ execute > ; immediate > Very interesting. I think this needs someone with quite strong Forth-fu (Stefan) to review this one. Also I can't see any related documentation with this patch related to locals support? ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

2 1

Re: [OpenBIOS] [PATCH 6/10] Wrapped HFS+ incorrectly recognized
by Mark Cave-Ayland 10 Aug '11

10 Aug '11

On 09/08/11 22:54, William Hahne wrote: > The code for checking for a wrapped HFS+ volume looks at the wrong offset. > > Index: fs/hfsplus/hfsp_volume.c > =================================================================== > --- fs/hfsplus/hfsp_volume.c (revision 1041) > +++ fs/hfsplus/hfsp_volume.c (working copy) > @@ -302,7 +302,7 @@ > os_read(fd, vol, 2, HFSP_BLOCKSZ_BITS); > if (__be16_to_cpu(vol[0]) == HFS_VOLHEAD_SIG && > - __be16_to_cpu(vol[0x7c]) == HFSP_VOLHEAD_SIG) { > + __be16_to_cpu(vol[0x3e]) == HFSP_VOLHEAD_SIG) { > ret = -1; > } else if (__be16_to_cpu(vol[0]) == HFSP_VOLHEAD_SIG) { > ret = -1; Same comment as for patch 2/10. ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

2 1

Re: [OpenBIOS] [PATCH 3/10] Don't stop at APPLE_VOID partition
by Mark Cave-Ayland 10 Aug '11

10 Aug '11

On 09/08/11 22:54, William Hahne wrote: > The void partitions can be occasionally found on Mac OS discs (10.2 for > example.) Previously mac-parts would just stop at the first void > partition meaning it would never try to boot from the HFS partition. > > Index: packages/mac-parts.c > =================================================================== > --- packages/mac-parts.c (revision 1041) > +++ packages/mac-parts.c (working copy) > @@ -165,9 +165,12 @@ > for (parnum = 1; parnum <= __be32_to_cpu(par.pmMapBlkCnt); parnum++) { > SEEK( bs * parnum ); > READ( &par, sizeof(par) ); > - if( __be16_to_cpu(par.pmSig) != DESC_PART_SIGNATURE || > - !__be32_to_cpu(par.pmPartBlkCnt) ) > + if( __be16_to_cpu(par.pmSig) != DESC_PART_SIGNATURE) { > break; > + } > + if ( !__be32_to_cpu(par.pmPartBlkCnt) ) { > + continue; /* Just a void partition, ignore it. */ > + } > DPRINTF("found partition type: %s with status %x\n", par.pmPartType, > __be32_to_cpu(par.pmPartStatus)); Same as my comment for patch 2/10. ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

2 1

Re: [OpenBIOS] [PATCH 2/10] Ignore extraneous partitions
by Mark Cave-Ayland 10 Aug '11

10 Aug '11

On 09/08/11 22:54, William Hahne wrote: > BootX will only check the first few partitions from mac-parts to find > the Mac OS partition. So it must expect drivers and void partitions to > be ignored. This patch makes it so that if you specify the partition > cd:1 and partition 1 is a driver it will keep checking partitions until > reaching the first non-driver and non-void partition. > > Index: packages/mac-parts.c > =================================================================== > --- packages/mac-parts.c (revision 1041) > +++ packages/mac-parts.c (working copy) > @@ -200,15 +203,26 @@ > } else { > /* Another partition was explicitly requested */ > - SEEK( bs * parnum ); > - READ( &par, sizeof(par) ); > + > + /* We have to find the first valid partition corresponding to the > given number. > + This is because Apple sometimes includes a bunch of extra partitions > that > + BootX expects to be ignored */ > + while (parnum < par.pmMapBlkCnt) { > + SEEK( bs * parnum ); > + READ( &par, sizeof(par) ); > - if( (__be32_to_cpu(par.pmPartStatus) & kPartitionAUXIsValid) && > - (__be32_to_cpu(par.pmPartStatus) & kPartitionAUXIsAllocated) && > - (__be32_to_cpu(par.pmPartStatus) & kPartitionAUXIsReadable) ) { > + /* Check if valid, also device driver partitions are expected to be > ignored */ > + if( (__be32_to_cpu(par.pmPartStatus) & kPartitionAUXIsValid) && > + (__be32_to_cpu(par.pmPartStatus) & kPartitionAUXIsAllocated) && > + (__be32_to_cpu(par.pmPartStatus) & kPartitionAUXIsReadable) && > + !(__be32_to_cpu(par.pmPartStatus) & kPartitionIsRealDeviceDriver)) { > - offs = (long long)__be32_to_cpu(par.pmPyPartStart) * bs; > - size = (long long)__be32_to_cpu(par.pmPartBlkCnt) * bs; > + offs = (long long)__be32_to_cpu(par.pmPyPartStart) * bs; > + size = (long long)__be32_to_cpu(par.pmPartBlkCnt) * bs; > + break; > + } > + > + parnum++; > } > } I remember last time I reworked this, I had to spend a lot of time reading the Apple HFS documentation with regard to this. Could you add a link to the documentation on the Apple site into the commit message, and confirm whether this is something I missed which is documented or it's new behaviour that you have discoverd through testing. ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

2 1

Re: [OpenBIOS] [PATCH 1/10] Dummy get-key-map in keyboard device package
by Mark Cave-Ayland 10 Aug '11

10 Aug '11

On 09/08/11 22:54, William Hahne wrote: > "get-key-map" is a Forth word that provides a map of all the keys > currently pressed on the keyboard. Since it is only used by BootX to > determine if one of the shortcuts for verbose or single user mode is > pressed. It is a waste of time to provide a full implementation. This > just hands out a dummy key map which specifies verbose mode. > > Index: drivers/adb_kbd.c > =================================================================== > --- drivers/adb_kbd.c (revision 1041) > +++ drivers/adb_kbd.c (working copy) > @@ -43,10 +43,13 @@ > static void keyboard_read(void); > +static void keyboard_get_key_map(void); > + > NODE_METHODS( keyboard ) = { > { "open", keyboard_open }, > { "close", keyboard_close }, > { "read", keyboard_read }, > + { "get-key-map", keyboard_get_key_map }, > }; > /* VT100 escape sequences */ > @@ -566,3 +569,18 @@ > } > PUSH(i); > } > + > +static unsigned char fake_keymap[32] = { > + 0x00, 0x00, 0x00, 0x40, 0x00, 0x00, 0x00, 0x00, > + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > + 0x00, 0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00 > +}; > + > +static void keyboard_get_key_map(void) > +{ > + /* This is a bit of a hack since BootX requires a get-key-map word. > + In the future this should be changed to give the actual current > keymap, > + but since this only effects keyboard input in BootX it isn't a > priority. */ > + PUSH( (int)fake_keymap ); > +} Can you add a reference in the commit message to the documentation for the keymap layout? It's not clear how you generated the contents of the keymap blob. ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

2 1

Re: [OpenBIOS] [PATCH 4/10] Place framebuffer address in frame-buffer-adr
by Mark Cave-Ayland 10 Aug '11

10 Aug '11

On 09/08/11 22:54, William Hahne wrote: > BootX gets the framebuffer address to provide to Mac OS from the > frame-buffer-adr value. This value was previously just set to null. > > Index: packages/video.c > =================================================================== > --- packages/video.c (revision 1041) > +++ packages/video.c (working copy) > @@ -332,6 +369,9 @@ > video.has_video = 1; > video.pal = malloc( 256 * sizeof(unsigned long) ); > + PUSH(video.fb.mphys); > + feval("to frame-buffer-adr"); > + > #ifdef CONFIG_PPC > s = (video.fb.mphys & 0xfff); > size = ((video.fb.h * video.fb.rb + s) + 0xfff) & ~0xfff; > I think this looks sensible, but will defer to the PPC maintainers. ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

1 0

Re: [OpenBIOS] [PATCH 0/10] Patches for booting Mac OS X
by Mark Cave-Ayland 10 Aug '11

10 Aug '11

On 09/08/11 22:54, William Hahne wrote: > Hello, > > I apologize for my earlier post which I failed to break up. I have not > done much posting to mailing lists. These 10 patches it all relate to > getting OpenBIOS able to boot Mac OS X on Qemu. While Mac OS does not > yet fully boot, with these patches I have gotten the Mac OS 10.2 kernel > to load and begin booting. The rest of the work will mostly be in Qemu. > > William Hahne > > M kernel/forth.c > M kernel/bootstrap.c > M forth/admin/iocontrol.fs > M forth/bootstrap/bootstrap.fs > M fs/hfsplus/hfsp_volume.c > M arch/ppc/qemu/init.c > M packages/video.c > M packages/mac-parts.c > M drivers/adb_kbd.c Hi William, Thanks for this - this looks like a very interesting patch series. Comments to follow shortly. ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

1 0

Re: [OpenBIOS] [PATCH 9/10] Divide by zero check
by Artyom Tarasenko 10 Aug '11

10 Aug '11

On Tue, Aug 9, 2011 at 11:55 PM, William Hahne <will07c5(a)gmail.com> wrote: > It is possible for BootX to purposefully divide by zero expecting 0 as the > result. OBP behaves differently. It puts the result only if there was no devision by zero: ok showstack ok 0 0 / Trap 3e ok 1 0 / Trap 3e ok 10 8 / 2 ok Maybe it has to be done platform-dependent. > Index: kernel/forth.c > =================================================================== > --- kernel/forth.c (revision 1041) > +++ kernel/forth.c (working copy) > @@ -1157,6 +1157,12 @@ > { > const ucell b = POP(); > const ducell a = DPOP(); > + > + if (b == 0) { // can't divide by zero > + PUSH(0); > + DPUSH(0); > + return; > + } > #ifdef NEED_FAKE_INT128_T > if (a.hi != 0) { > fprintf(stderr, "mudivmod called (0x%016llx %016llx / > 0x%016llx)\n", > -- > OpenBIOS http://openbios.org/ > Mailinglist: http://lists.openbios.org/mailman/listinfo > Free your System - May the Forth be with you > -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/

1 0

Re: [OpenBIOS] [RFC] PowerPC Mac OS on Qemu
by William Hahne 10 Aug '11

10 Aug '11

Please disregard this post. I failed to properly split it up and I have reposted everything in it. William Hahne On Tue, Aug 9, 2011 at 2:46 PM, William Hahne <will07c5(a)gmail.com> wrote: > Hello, > > I am a Google Summer of Code student working on getting PowerPC Mac OS > running on Qemu. While I am not finished I need to upstream what I currently > have before the end of Summer of Code. My patch is for OpenBIOS but I am > cross-posting to both Qemu and OpenBIOS mailing lists since it is useful to > get feedback from both. > > One part of the patch I am particularly concerned about is the patch to > arch/ppc/qemu/init.c to provide a CPU and Timebase frequency. Qemu doesn't > report a CPU frequency and the reported Timebase frequency is too high and > causes the Mac OS scheduler to break. I hard-coded values that work but this > seems like an unacceptable long-term solution to me. A simple test for CPU > frequency might be the best solution here but seems a little redundant as > Mac OS later runs its own test, seemingly only relying on these values > during initialization (I am not 100% sure of this since it crashes before > reaching that point.) Feedback here would be especially appreciated. > > Another thing to note is in drivers/adb_kbd.c. "get-key-map" which returns > a map of the current pressed keys on the keyboard just returns a dummy > value. I felt it was a waste of time making a full implementation when all > it really gets you is the ability to use keyboard shortcuts for verbose or > single user mode. > > Other than those specific concerns I welcome general feedback on the patch, > since as I said I am hoping to get it in before the end of Summer of Code. > > Thanks, > William Hahne >

1 0

[RFC] Incorrect CPU timebase-frequency and clock-frequency in OpenBIOS
by William Hahne 10 Aug '11

10 Aug '11

Hello, I would like to apologize for not splitting up my last post. I am a Google Summer of Code student working on getting Mac OS X to work in Qemu. Currently the cpu device in OpenBIOS has incorrect timebase-frequency and clock-frequency properties. The Mac OS X scheduler relies on these values to calculate the length of a timeslice. Both values are taken from fw_cfg by OpenBIOS. The problem with timebase-frequency is that the value is far too high. Mac OS X depends on this value being sufficiently smaller than clock-frequency. The value for clock-frequency no longer even exists in fw_cfg and is therefore reported as 0. Mac OS X needs some value here even if it doesn't indicate an actual cpu frequency. The patch below for OpenBIOS provides some fake values that work, but since the values are hard-coded into OpenBIOS, it isn't a very nice solution. The best solutions I can think of are to either compute clock-frequency in OpenBIOS or have Qemu provide a value even if its purpose is only to appease Mac OS X or any other OS that depends on the value. If the timebase frequency is correct than it can be lowered otherwise it can be corrected. I am posting this RFC to get thoughts more on what to do with clock-frequency. For reference the timebase frequency is from the fw_cfg value FW_CFG_PPC_TBFREQ and clock frequency is from FW_CFG_PPC_CPUFREQ. Thanks, William Hahne Index: arch/ppc/qemu/init.c =================================================================== --- arch/ppc/qemu/init.c (revision 1041) +++ arch/ppc/qemu/init.c (working copy) @@ -250,12 +250,14 @@ push_str("icache-block-size"); fword("property"); - PUSH(fw_cfg_read_i32(FW_CFG_PPC_TBFREQ)); + /* XXX - Mac OS X needs valid values for timebase-frequency and clock-frequency + for scheduling to work. These are just temporary values and shouldn't be hardcoded here. */ + PUSH(16600000); fword("encode-int"); push_str("timebase-frequency"); fword("property"); - PUSH(fw_cfg_read_i32(FW_CFG_PPC_CPUFREQ)); + PUSH(266000000); fword("encode-int"); push_str("clock-frequency"); fword("property");

1 0

[PATCH 10/10] Adding filll Forth primitive
by William Hahne 09 Aug '11

09 Aug '11

This is a forth primitive that is required by BootX. It just fills some specified memory address and length with longs. Index: kernel/forth.c =================================================================== --- kernel/forth.c (revision 1041) +++ kernel/forth.c (working copy) @@ -1610,6 +1616,20 @@ memset(src, value, count); } +/* + * filll ( addr len byte -- ) + */ +static void filll(void) +{ + ucell value = POP(); + ucell count = POP(); + ucell *dest = (ucell *)cell2pointer(POP()); + + int i; + for (i = 0; i <= count / 4; i++) { + dest[i] = value; + } +} /* * unaligned-w@ ( addr -- w ) @@ -1963,4 +1983,5 @@ do_encode_file, /* $encode-file */ do_debug_xt, /* (debug */ do_debug_off, /* (debug-off) */ + filll /* filll */ }; Index: kernel/bootstrap.c =================================================================== --- kernel/bootstrap.c (revision 1041) +++ kernel/bootstrap.c (working copy) @@ -89,7 +89,7 @@ "here", "here!", "dobranch", "do?branch", "unaligned-w@", "unaligned-w!", "unaligned-l@", "unaligned-l!", "ioc@", "iow@", "iol@", "ioc!", "iow!", "iol!", "i", "j", "call", "sys-debug", - "$include", "$encode-file", "(debug", "(debug-off)" + "$include", "$encode-file", "(debug", "(debug-off)", "filll" }; /*

1 0

[PATCH 9/10] Divide by zero check
by William Hahne 09 Aug '11

09 Aug '11

It is possible for BootX to purposefully divide by zero expecting 0 as the result. Index: kernel/forth.c =================================================================== --- kernel/forth.c (revision 1041) +++ kernel/forth.c (working copy) @@ -1157,6 +1157,12 @@ { const ucell b = POP(); const ducell a = DPOP(); + + if (b == 0) { // can't divide by zero + PUSH(0); + DPUSH(0); + return; + } #ifdef NEED_FAKE_INT128_T if (a.hi != 0) { fprintf(stderr, "mudivmod called (0x%016llx %016llx / 0x%016llx)\n",

1 0

[PATCH 8/10] Check that stdout variable is not null
by William Hahne 09 Aug '11

09 Aug '11

BootX will sometimes set the stdout variable to null and then subsequently call io-emit which can eventually result in an infinite loop. Index: forth/admin/iocontrol.fs =================================================================== --- forth/admin/iocontrol.fs (revision 1041) +++ forth/admin/iocontrol.fs (working copy) @@ -80,6 +80,7 @@ ; : io-emit ( char -- ) + stdout @ 0= if drop exit then \ make sure stdout pointer is not null io-out-char c! io-out-char 1 " write" stdout @ $call-method drop ;

1 0

[PATCH 7/10] Apple local variables implementation in Forth
by William Hahne 09 Aug '11

09 Aug '11

This is an implementation of Apple local variables which is required to execute the Forth scripts in BootX Index: forth/bootstrap/bootstrap.fs =================================================================== --- forth/bootstrap/bootstrap.fs (revision 1041) +++ forth/bootstrap/bootstrap.fs (working copy) @@ -1413,10 +1413,135 @@ here last @ , latest ! \ write backlink and set latest ; +\ +\ Defer required by BootX +\ +defer spin + +\ +\ Local Variables (Apple specific) +\ + +\ +: has-locals ( -- true/false ) + skipws + ib >in @ + c@ 7b <> + if false exit then + ib >in @ + 1+ c@ 20 > + if false exit then + + true + ; + +: comp-str-char ( str len char -- true/false ) + swap 1 <> if 2drop false exit then + swap c@ <> if false exit then + true + ; + +variable locals_wordlist +variable locals_state \ 0 - reading args + \ 1 - ; + \ 2 - reading vars +: read-locals ( -- addr0 .. addrN addrCount ) + has-locals + not if 0 false exit then \ no locals + + 0 locals_state ! + 0 >r + + s" get-current" $find drop execute + s" wordlist" $find drop execute + dup locals_wordlist ! + s" set-current" $find drop execute + + parse-word 2drop \ ditch the { + + begin + parse-word + + 2dup 3b comp-str-char \ check for ; + if 1 locals_state ! then + + 2dup 7d comp-str-char \ check for } + not + while + locals_state @ 1 <> if \ the ; is not a local variable so ignore it + header + + locals_state @ 0= if \ only save the address if it is an arg + r> + here na1+ >r + 1+ >r + then + + 3 , 0 , + reveal + else \ if we hit a ; then move to next state + 2drop + 2 locals_state ! + then + repeat + + 2drop + + s" set-current" $find drop execute + + r> 0 + begin + 2dup + > + while + r> -rot + 1+ + repeat + + drop + + true + ; + +: begin-locals ( addr0 .. addrN count hasLocals -- ) + not if drop exit then + + dup 0> if + 0 do + ['] (lit) , , ['] ! , + loop + else drop then + + s" get-order" $find drop execute + locals_wordlist @ + swap 1+ + s" set-order" $find drop execute + ; + +: end-locals ( -- ) + locals_wordlist @ 0= if exit then + + 0 locals_wordlist ! + + s" get-order" $find drop execute + swap drop 1- + s" set-order" $find drop execute + ; + +: -> parse-word $find drop na1+ + ['] (lit) , , ['] ! , + ; immediate + +\ +\ 7.3.9.1 Defining words +\ + : : - parse-word header - 1 , ] + parse-word >r >r + read-locals + r> r> header + 1 , + begin-locals + ] ; : :noname @@ -1426,6 +1551,7 @@ ; : ; + end-locals ['] (semis) , reveal ['] [ execute ; immediate

1 0

[PATCH 6/10] Wrapped HFS+ incorrectly recognized
by William Hahne 09 Aug '11

09 Aug '11

The code for checking for a wrapped HFS+ volume looks at the wrong offset. Index: fs/hfsplus/hfsp_volume.c =================================================================== --- fs/hfsplus/hfsp_volume.c (revision 1041) +++ fs/hfsplus/hfsp_volume.c (working copy) @@ -302,7 +302,7 @@ os_read(fd, vol, 2, HFSP_BLOCKSZ_BITS); if (__be16_to_cpu(vol[0]) == HFS_VOLHEAD_SIG && - __be16_to_cpu(vol[0x7c]) == HFSP_VOLHEAD_SIG) { + __be16_to_cpu(vol[0x3e]) == HFSP_VOLHEAD_SIG) { ret = -1; } else if (__be16_to_cpu(vol[0]) == HFSP_VOLHEAD_SIG) { ret = -1;

1 0

[PATCH 5/10] Add draw-rectangle to the display package
by William Hahne 09 Aug '11

09 Aug '11

While not necessary for BootX to function this allows the Apple logo to be displayed during boot time. Index: packages/video.c =================================================================== --- packages/video.c (revision 1041) +++ packages/video.c (working copy) @@ -281,6 +281,42 @@ fill_rect( color_ind, x, y, w, h ); } +static void +video_draw_rect( void ) +{ + int h = POP(); + int w = POP(); + int y = POP(); + int x = POP(); + unsigned char* img = (unsigned char*)cell2pointer(POP()); + char *pp; + + if (!video.has_video || x < 0 || y < 0 || w <= 0 || h <= 0 || + x + w > video.fb.w || y + h > video.fb.h) + return; + + pp = (char*)video.fb.mphys + video.fb.rb * y; + for( ; h--; pp += video.fb.rb ) { + int ww = w; + + if( video.fb.depth == 24 || video.fb.depth == 32 ) { + unsigned long *p = (unsigned long*)pp + x; + while( ww-- ) + *p++ = get_color(*img++); + } else if( video.fb.depth == 16 || video.fb.depth == 15 ) { + unsigned short *p = (unsigned short*)pp + x; + while( ww-- ) + *p++ = get_color(*img++); + } else { + char *p = (char *)((unsigned short*)pp + x); + + while( ww-- ) + *p++ = get_color(*img++); + } + } + +} + /* ( addr len -- actual ) */ static void video_write(void) @@ -299,6 +335,7 @@ {"dimensions", video_dimensions }, {"set-colors", video_set_colors }, {"fill-rectangle", video_fill_rect }, + {"draw-rectangle", video_draw_rect }, {"color!", video_color_bang }, {"write", video_write }, };

1 0

[PATCH 4/10] Place framebuffer address in frame-buffer-adr
by William Hahne 09 Aug '11

09 Aug '11

BootX gets the framebuffer address to provide to Mac OS from the frame-buffer-adr value. This value was previously just set to null. Index: packages/video.c =================================================================== --- packages/video.c (revision 1041) +++ packages/video.c (working copy) @@ -332,6 +369,9 @@ video.has_video = 1; video.pal = malloc( 256 * sizeof(unsigned long) ); + PUSH(video.fb.mphys); + feval("to frame-buffer-adr"); + #ifdef CONFIG_PPC s = (video.fb.mphys & 0xfff); size = ((video.fb.h * video.fb.rb + s) + 0xfff) & ~0xfff;

1 0

[PATCH 3/10] Don't stop at APPLE_VOID partition
by William Hahne 09 Aug '11

09 Aug '11

The void partitions can be occasionally found on Mac OS discs (10.2 for example.) Previously mac-parts would just stop at the first void partition meaning it would never try to boot from the HFS partition. Index: packages/mac-parts.c =================================================================== --- packages/mac-parts.c (revision 1041) +++ packages/mac-parts.c (working copy) @@ -165,9 +165,12 @@ for (parnum = 1; parnum <= __be32_to_cpu(par.pmMapBlkCnt); parnum++) { SEEK( bs * parnum ); READ( &par, sizeof(par) ); - if( __be16_to_cpu(par.pmSig) != DESC_PART_SIGNATURE || - !__be32_to_cpu(par.pmPartBlkCnt) ) + if( __be16_to_cpu(par.pmSig) != DESC_PART_SIGNATURE) { break; + } + if ( !__be32_to_cpu(par.pmPartBlkCnt) ) { + continue; /* Just a void partition, ignore it. */ + } DPRINTF("found partition type: %s with status %x\n", par.pmPartType, __be32_to_cpu(par.pmPartStatus));

1 0

[PATCH 2/10] Ignore extraneous partitions
by William Hahne 09 Aug '11

09 Aug '11

BootX will only check the first few partitions from mac-parts to find the Mac OS partition. So it must expect drivers and void partitions to be ignored. This patch makes it so that if you specify the partition cd:1 and partition 1 is a driver it will keep checking partitions until reaching the first non-driver and non-void partition. Index: packages/mac-parts.c =================================================================== --- packages/mac-parts.c (revision 1041) +++ packages/mac-parts.c (working copy) @@ -200,15 +203,26 @@ } else { /* Another partition was explicitly requested */ - SEEK( bs * parnum ); - READ( &par, sizeof(par) ); + + /* We have to find the first valid partition corresponding to the given number. + This is because Apple sometimes includes a bunch of extra partitions that + BootX expects to be ignored */ + while (parnum < par.pmMapBlkCnt) { + SEEK( bs * parnum ); + READ( &par, sizeof(par) ); - if( (__be32_to_cpu(par.pmPartStatus) & kPartitionAUXIsValid) && - (__be32_to_cpu(par.pmPartStatus) & kPartitionAUXIsAllocated) && - (__be32_to_cpu(par.pmPartStatus) & kPartitionAUXIsReadable) ) { + /* Check if valid, also device driver partitions are expected to be ignored */ + if( (__be32_to_cpu(par.pmPartStatus) & kPartitionAUXIsValid) && + (__be32_to_cpu(par.pmPartStatus) & kPartitionAUXIsAllocated) && + (__be32_to_cpu(par.pmPartStatus) & kPartitionAUXIsReadable) && + !(__be32_to_cpu(par.pmPartStatus) & kPartitionIsRealDeviceDriver)) { - offs = (long long)__be32_to_cpu(par.pmPyPartStart) * bs; - size = (long long)__be32_to_cpu(par.pmPartBlkCnt) * bs; + offs = (long long)__be32_to_cpu(par.pmPyPartStart) * bs; + size = (long long)__be32_to_cpu(par.pmPartBlkCnt) * bs; + break; + } + + parnum++; } }

1 0

[PATCH 1/10] Dummy get-key-map in keyboard device package
by William Hahne 09 Aug '11

09 Aug '11

"get-key-map" is a Forth word that provides a map of all the keys currently pressed on the keyboard. Since it is only used by BootX to determine if one of the shortcuts for verbose or single user mode is pressed. It is a waste of time to provide a full implementation. This just hands out a dummy key map which specifies verbose mode. Index: drivers/adb_kbd.c =================================================================== --- drivers/adb_kbd.c (revision 1041) +++ drivers/adb_kbd.c (working copy) @@ -43,10 +43,13 @@ static void keyboard_read(void); +static void keyboard_get_key_map(void); + NODE_METHODS( keyboard ) = { { "open", keyboard_open }, { "close", keyboard_close }, { "read", keyboard_read }, + { "get-key-map", keyboard_get_key_map }, }; /* VT100 escape sequences */ @@ -566,3 +569,18 @@ } PUSH(i); } + +static unsigned char fake_keymap[32] = { + 0x00, 0x00, 0x00, 0x40, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00 +}; + +static void keyboard_get_key_map(void) +{ + /* This is a bit of a hack since BootX requires a get-key-map word. + In the future this should be changed to give the actual current keymap, + but since this only effects keyboard input in BootX it isn't a priority. */ + PUSH( (int)fake_keymap ); +}

1 0

[PATCH 0/10] Patches for booting Mac OS X
by William Hahne 09 Aug '11

09 Aug '11

Hello, I apologize for my earlier post which I failed to break up. I have not done much posting to mailing lists. These 10 patches it all relate to getting OpenBIOS able to boot Mac OS X on Qemu. While Mac OS does not yet fully boot, with these patches I have gotten the Mac OS 10.2 kernel to load and begin booting. The rest of the work will mostly be in Qemu. William Hahne M kernel/forth.c M kernel/bootstrap.c M forth/admin/iocontrol.fs M forth/bootstrap/bootstrap.fs M fs/hfsplus/hfsp_volume.c M arch/ppc/qemu/init.c M packages/video.c M packages/mac-parts.c M drivers/adb_kbd.c

1 0

Re: [OpenBIOS] [Qemu-devel] [RFC] PowerPC Mac OS on Qemu
by Natalia Portillo 09 Aug '11

09 Aug '11

Please, a) separate the patch in pieces, I suggest you checking how other patches are split, there have been a lot of patches today to get insight. b) use inline signed-by patch Regards, Natalia Portillo El 09/08/2011, a las 20:46, William Hahne escribió: > Hello, > > I am a Google Summer of Code student working on getting PowerPC Mac OS running on Qemu. While I am not finished I need to upstream what I currently have before the end of Summer of Code. My patch is for OpenBIOS but I am cross-posting to both Qemu and OpenBIOS mailing lists since it is useful to get feedback from both. > > One part of the patch I am particularly concerned about is the patch to arch/ppc/qemu/init.c to provide a CPU and Timebase frequency. Qemu doesn't report a CPU frequency and the reported Timebase frequency is too high and causes the Mac OS scheduler to break. I hard-coded values that work but this seems like an unacceptable long-term solution to me. A simple test for CPU frequency might be the best solution here but seems a little redundant as Mac OS later runs its own test, seemingly only relying on these values during initialization (I am not 100% sure of this since it crashes before reaching that point.) Feedback here would be especially appreciated. > > Another thing to note is in drivers/adb_kbd.c. "get-key-map" which returns a map of the current pressed keys on the keyboard just returns a dummy value. I felt it was a waste of time making a full implementation when all it really gets you is the ability to use keyboard shortcuts for verbose or single user mode. > > Other than those specific concerns I welcome general feedback on the patch, since as I said I am hoping to get it in before the end of Summer of Code. > > Thanks, > William Hahne > <PowerPC_Mac_OS.patch>

1 0

[RFC] PowerPC Mac OS on Qemu
by William Hahne 09 Aug '11

09 Aug '11

Hello, I am a Google Summer of Code student working on getting PowerPC Mac OS running on Qemu. While I am not finished I need to upstream what I currently have before the end of Summer of Code. My patch is for OpenBIOS but I am cross-posting to both Qemu and OpenBIOS mailing lists since it is useful to get feedback from both. One part of the patch I am particularly concerned about is the patch to arch/ppc/qemu/init.c to provide a CPU and Timebase frequency. Qemu doesn't report a CPU frequency and the reported Timebase frequency is too high and causes the Mac OS scheduler to break. I hard-coded values that work but this seems like an unacceptable long-term solution to me. A simple test for CPU frequency might be the best solution here but seems a little redundant as Mac OS later runs its own test, seemingly only relying on these values during initialization (I am not 100% sure of this since it crashes before reaching that point.) Feedback here would be especially appreciated. Another thing to note is in drivers/adb_kbd.c. "get-key-map" which returns a map of the current pressed keys on the keyboard just returns a dummy value. I felt it was a waste of time making a full implementation when all it really gets you is the ability to use keyboard shortcuts for verbose or single user mode. Other than those specific concerns I welcome general feedback on the patch, since as I said I am hoping to get it in before the end of Summer of Code. Thanks, William Hahne

1 0

Re: [OpenBIOS] OpenBios Sparc64
by Tarl Neustaedter 08 Aug '11

08 Aug '11

On 2011-Aug-5 14:23 , Ghitulete Razvan wrote: > This is a wild > guess, but is the openboot CIF influenced in any way by the processor > state register? Shouldn't be. It's just forth code manipulating the device tree. Doesn't do anything exotic with the processor. On the other hand, it does need to have the client interface initialized, which happens automatically during startup. If you're somehow bypassing that, you'd expect to have trouble. > Also as a last option, do you know how i could get hold of a > binary for 3.13.1 so i can disassemble it and inspect the code easier > as i find it pretty difficult using the dis command over and over. > heh. I certainly can't send you one, Oracle is much more retentive on exporting code than Sun ever was. However, if you have hardware, you've got the binary. My recollection is that older versions of Solaris (pre Solaris-10) just leave the prom mapped in kernel space, starting at 0xf020.0000 . If not, you'll have to figure out how to use /dev/physmem to map in the prom so you can dump it out. Another possibility is the version of Openboot that was opensourced by Sun several years ago - 4.21, I think. See: http://openboot.sourceforge.net/

2 1

[PATCH v2] make select-dev and unselect-dev compatible with OBP
by Bob Breuer 08 Aug '11

08 Aug '11

>From the 1275 errata for section H.8, select-dev and unselect-dev are pre Open Firmware, but not the same as open-dev/device-end. Make them Sun OBP compatible by pulling the functionality for select-dev/ unselect-dev out of (and simplifying) begin-package/end-package. For the Sun OBP definition of begin-package/end-package, along with descriptions and example usage, see the "Debugging and Testing FCode Programs" chapter of "Writing FCode 3.x Programs". Signed-off-by: Bob Breuer <breuerr(a)mc.net> --- v2: updated commit message and comments to mention the 1275 errata, moved the words to forth/admin/devices.fs, begin-package/end-package followed along to avoid "unknown word" errors while building the dictionary. forth/admin/devices.fs | 26 +++++++++++++++++++++++++- forth/debugging/fcode.fs | 16 ---------------- forth/device/pathres.fs | 4 ---- 3 files changed, 25 insertions(+), 21 deletions(-) Index: forth/device/pathres.fs =================================================================== --- forth/device/pathres.fs (revision 1045) +++ forth/device/pathres.fs (working copy) @@ -471,10 +471,6 @@ ( ihandle ) ; -: select-dev ( dev-str dev-len -- ihandle | 0 ) - open-dev -; - : execute-device-method ( ... dev-str dev-len met-str met-len -- ... false | ?? true ) 2swap Index: forth/admin/devices.fs =================================================================== --- forth/admin/devices.fs (revision 1045) +++ forth/admin/devices.fs (working copy) @@ -46,10 +46,34 @@ 0 active-package! ; +\ Open selected device node and make it the current instance +\ section H.8 errata: pre OpenFirmware, but Sun OBP compatible +: select-dev ( -- ) + open-dev dup 0= abort" failed opening parent." + dup to my-self + ihandle>phandle active-package! +; + +\ Close current node, deselect active package and current instance, +\ leaving no instance selected +\ section H.8 errata: pre OpenFirmware, but Sun OBP compatible : unselect-dev ( -- ) + my-self close-dev device-end + 0 to my-self ; - + +: begin-package ( arg-str arg-len reg-str reg-len dev-str dev-len -- ) + select-dev + new-device + set-args +; + +: end-package ( -- ) + finish-device + unselect-dev +; + : ?active-package ( -- phandle ) active-package dup 0= abort" no active device" ; Index: forth/debugging/fcode.fs =================================================================== --- forth/debugging/fcode.fs (revision 1045) +++ forth/debugging/fcode.fs (working copy) @@ -10,21 +10,5 @@ : headers ( -- ) ; -: begin-package ( arg-str arg-len reg-str reg-len dev-str dev-len -- ) - open-dev dup 0= abort" failed opening parent." - dup to my-self - ihandle>phandle active-package! - new-device - set-args -; - -: end-package ( -- ) - my-parent >r - finish-device - 0 active-package! - 0 to my-self - r> close-dev -; - : apply ( ... "method-name< >device-specifier< >" -- ??? ) ;

2 1

[commit] r1046 - in trunk/openbios-devel/forth: admin debugging device
by repository service 08 Aug '11

08 Aug '11

Author: mcayland Date: Mon Aug 8 14:33:10 2011 New Revision: 1046 URL: http://tracker.coreboot.org/trac/openbios/changeset/1046 Log: Make select-dev and unselect-dev compatible with OBP. >From the 1275 errata for section H.8, select-dev and unselect-dev are pre Open Firmware, but not the same as open-dev/device-end. Make them Sun OBP compatible by pulling the functionality for select-dev/ unselect-dev out of (and simplifying) begin-package/end-package. For the Sun OBP definition of begin-package/end-package, along with descriptions and example usage, see the "Debugging and Testing FCode Programs" chapter of "Writing FCode 3.x Programs". Signed-off-by: Bob Breuer <breuerr(a)mc.net> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)siriusit.co.uk> Modified: trunk/openbios-devel/forth/admin/devices.fs trunk/openbios-devel/forth/debugging/fcode.fs trunk/openbios-devel/forth/device/pathres.fs Modified: trunk/openbios-devel/forth/admin/devices.fs ============================================================================== --- trunk/openbios-devel/forth/admin/devices.fs Thu Jul 14 16:37:34 2011 (r1045) +++ trunk/openbios-devel/forth/admin/devices.fs Mon Aug 8 14:33:10 2011 (r1046) @@ -46,10 +46,34 @@ 0 active-package! ; +\ Open selected device node and make it the current instance +\ section H.8 errata: pre OpenFirmware, but Sun OBP compatible +: select-dev ( -- ) + open-dev dup 0= abort" failed opening parent." + dup to my-self + ihandle>phandle active-package! +; + +\ Close current node, deselect active package and current instance, +\ leaving no instance selected +\ section H.8 errata: pre OpenFirmware, but Sun OBP compatible : unselect-dev ( -- ) + my-self close-dev device-end + 0 to my-self +; + +: begin-package ( arg-str arg-len reg-str reg-len dev-str dev-len -- ) + select-dev + new-device + set-args +; + +: end-package ( -- ) + finish-device + unselect-dev ; - + : ?active-package ( -- phandle ) active-package dup 0= abort" no active device" ; Modified: trunk/openbios-devel/forth/debugging/fcode.fs ============================================================================== --- trunk/openbios-devel/forth/debugging/fcode.fs Thu Jul 14 16:37:34 2011 (r1045) +++ trunk/openbios-devel/forth/debugging/fcode.fs Mon Aug 8 14:33:10 2011 (r1046) @@ -10,21 +10,5 @@ : headers ( -- ) ; -: begin-package ( arg-str arg-len reg-str reg-len dev-str dev-len -- ) - open-dev dup 0= abort" failed opening parent." - dup to my-self - ihandle>phandle active-package! - new-device - set-args -; - -: end-package ( -- ) - my-parent >r - finish-device - 0 active-package! - 0 to my-self - r> close-dev -; - : apply ( ... "method-name< >device-specifier< >" -- ??? ) ; Modified: trunk/openbios-devel/forth/device/pathres.fs ============================================================================== --- trunk/openbios-devel/forth/device/pathres.fs Thu Jul 14 16:37:34 2011 (r1045) +++ trunk/openbios-devel/forth/device/pathres.fs Mon Aug 8 14:33:10 2011 (r1046) @@ -471,10 +471,6 @@ ( ihandle ) ; -: select-dev ( dev-str dev-len -- ihandle | 0 ) - open-dev -; - : execute-device-method ( ... dev-str dev-len met-str met-len -- ... false | ?? true ) 2swap

1 0

Re: [OpenBIOS] OpenBios Sparc64
by Tarl Neustaedter 05 Aug '11

05 Aug '11

On 2011-Aug-5 08:56 , Ghitulete Razvan wrote: > I meant OpenBOOT, as I am trying to write something for a V9 and qemu > doesn't have full suport for the V9 arch. But as far as i've noticed > the openbios implementation resembles the openboot one. Anywho I > managed to get passed this. It seems it was because I had the > processor in a wrong state. But now I ran into some other problems, as > it seems if I call the "finddevice" CIF command for any node, instead > of getting a valid phandle, or an -1 in case i ask for gibberish(which > i did). The CIF keeps returning the address to the string I passed as > an argument (said device that i am searching). Hmm. I'm not seeing it. Granted, this is a newer openboot than you are using, but I don't remember any bugs in this area since god was young. T5240, No Keyboard Copyright (c) 1998, 2011, Oracle and/or its affiliates. All rights reserved. OpenBoot 4.34.0.build_01, 16384 MB memory available, Serial #71716124. [tarl usb3 #948] Ethernet address 0:14:4f:46:4d:1c, Host ID: 84464d1c. {0} ok cd /openprom/client-services {0} ok " /pci@400" 4000 swap move {0} ok 4000 10 dump \/ 1 2 3 4 5 6 7 8 9 a b c d e f v123456789abcdef 4000 2f 70 63 69 40 34 30 30 00 00 00 00 00 00 00 00 /pci@400........ {0} ok 4000 finddevice {0} ok showstack f0288e28 {0} ok clear {0} ok " gabblebletch" 4000 swap move {0} ok 4000 20 dump \/ 1 2 3 4 5 6 7 8 9 a b c d e f v123456789abcdef 4000 67 61 62 62 6c 65 62 6c 65 74 63 68 00 00 00 00 gabblebletch.... 4010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ {0} ok 4000 finddevice ffffffffffffffff {0} ok

2 1

Re: [OpenBIOS] OpenBios Sparc64
by Tarl Neustaedter 05 Aug '11

05 Aug '11

On 2011-Aug-5 08:56 , Ghitulete Razvan wrote: > I meant OpenBOOT, as I am trying to write something for a V9 and qemu > doesn't have full suport for the V9 arch. But as far as i've noticed > the openbios implementation resembles the openboot one. Anywho I > managed to get passed this. It seems it was because I had the > processor in a wrong state. But now I ran into some other problems, as > it seems if I call the "finddevice" CIF command for any node, instead > of getting a valid phandle, or an -1 in case i ask for gibberish(which > i did). The CIF keeps returning the address to the string I passed as > an argument (said device that i am searching). Hmm. That's interesting. I'll try that at work today. Out of curiosity, which version of OpenBoot are you working with?

1 0

[PATCH] make select-dev and unselect-dev compatible with OBP
by Bob Breuer 05 Aug '11

05 Aug '11

select-dev and unselect-dev are pre Open Firmware, and not the same as open-dev/device-end. Make them Sun OBP compatible by pulling the functionality for select-dev/unselect-dev out of (and simplifying) begin-package/end-package. Signed-off-by: Bob Breuer <breuerr(a)mc.net> --- forth/admin/devices.fs | 4 ---- forth/debugging/fcode.fs | 22 +++++++++++++++++----- forth/device/pathres.fs | 4 ---- 3 files changed, 17 insertions(+), 13 deletions(-) Index: forth/device/pathres.fs =================================================================== --- forth/device/pathres.fs (revision 1045) +++ forth/device/pathres.fs (working copy) @@ -471,10 +471,6 @@ ( ihandle ) ; -: select-dev ( dev-str dev-len -- ihandle | 0 ) - open-dev -; - : execute-device-method ( ... dev-str dev-len met-str met-len -- ... false | ?? true ) 2swap Index: forth/admin/devices.fs =================================================================== --- forth/admin/devices.fs (revision 1045) +++ forth/admin/devices.fs (working copy) @@ -46,10 +46,6 @@ 0 active-package! ; -: unselect-dev ( -- ) - device-end -; - : ?active-package ( -- phandle ) active-package dup 0= abort" no active device" ; Index: forth/debugging/fcode.fs =================================================================== --- forth/debugging/fcode.fs (revision 1045) +++ forth/debugging/fcode.fs (working copy) @@ -10,21 +10,33 @@ : headers ( -- ) ; -: begin-package ( arg-str arg-len reg-str reg-len dev-str dev-len -- ) +\ Open specified device node and make it the current instance. +\ pre Open Firmware, but Sun OBP compatible +: select-dev ( dev-str dev-len -- ) open-dev dup 0= abort" failed opening parent." dup to my-self ihandle>phandle active-package! +; + +: begin-package ( arg-str arg-len reg-str reg-len dev-str dev-len -- ) + select-dev new-device set-args ; -: end-package ( -- ) - my-parent >r - finish-device +\ Close current node, deselect active package and current instance, +\ leaving no instance selected +\ pre Open Firmware, but Sun OBP compatible +: unselect-dev ( -- ) + my-self close-dev 0 active-package! 0 to my-self - r> close-dev ; +: end-package ( -- ) + finish-device + unselect-dev +; + : apply ( ... "method-name< >device-specifier< >" -- ??? ) ;

2 3

Re: [OpenBIOS] OpenBios Sparc64
by Mark Cave-Ayland 05 Aug '11

05 Aug '11

On 04/08/11 15:39, Ghitulete Razvan wrote: > I've written several lines of code in C in which I am trying to access > the OpenBoot CIF to execute an instruction. But immediately after I do > the call to the CIF interface address the PROM freezes. Does anyone > have any ideas why is this so. I'm getting the CIF address from the > %o4 register passed by SILO Do you really mean OpenBoot or do you mean OpenBIOS? There was a bug in earlier versions of OpenBIOS where the CIF arguments were being read in the wrong order which is now fixed. Basically as you read the IEEE 1275 specification, left -> right maps to bottom -> top of stack so it may just be that you need to reverse the order of your arguments. Also if you are using OpenBIOS, you can enable DEBUG_CIF in libopenbios/client.c which will output all the CIF calls and their arguments on the console to help you. HTH, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

2 1

Re: [OpenBIOS] OpenBios Sparc64
by Blue Swirl 04 Aug '11

04 Aug '11

On Thu, Aug 4, 2011 at 2:39 PM, Ghitulete Razvan <razvan.ghitulete(a)gmail.com> wrote: > I've written several lines of code in C in which I am trying to access > the OpenBoot CIF to execute an instruction. But immediately after I do > the call to the CIF interface address the PROM freezes. Does anyone > have any ideas why is this so. I'm getting the CIF address from the > %o4 register passed by SILO Impossible to say without sources. Perhaps you should compare your CIF code to what SILO, Linux or *BSD are doing.

1 0

Re: [OpenBIOS] OpenBios Sparc64
by Tarl Neustaedter 04 Aug '11

04 Aug '11

On 2011-Jul-19 09:45 , Ghitulete Razvan wrote: > So I kinda got rid of that MMU Miss error, but now, when i try and > open-dev the display adapter i get a 0 return code on the stack. The > output being something like this. > > ok showstack > ok " /pci/SUNW,m64B " open-dev > 0 ok > That usually means the "open" method of your driver didn't succeed. For whatever reason, the SUNW,m64B driver returned a failure at open - either some allocation failed or it decided it didn't like the hardware it found.

2 1

Re: [OpenBIOS] [Qemu-devel] OpenBSD/macppc and sparc64 failing to boot with similar error.
by Brad 03 Aug '11

03 Aug '11

On 01/08/11 5:35 PM, Blue Swirl wrote: > On Mon, Aug 1, 2011 at 12:33 AM, Brad<brad(a)comstyle.com> wrote: >> I know sparc64 had little chance of actually working but >> I thought I'd take it for a spin with 0.15.0-rc1 and >> see how it fared in addition to macppc which has a good >> chance of working nowdays with modern QEMU. Lets see >> what QEMU and related bugs are left.. >> >> I noticed the bootblocks for each respective arch are >> failing in a very similar manner. I would guess that >> this is most likely a bug with the OpenBIOS Open Firmware >> implementation? >> >> Any assistance with this? Blue? After a little playing around I have found this is definitely a bug in QEMU. Turning on the OpenBSD malloc S flag which is what I run on all of my systems triggered this behavior in QEMU and trying to narrow it down further since S is a combination of other flags I found it was the J flag specifically that is triggering this behavior. From malloc(3).. J ``Junk''. Fill some junk into the area allocated. Currently junk is bytes of 0xd0 when allocating; this is pronounced ``Duh''. :-) Freed chunks are filled with 0xdf. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

1 0

Re: [OpenBIOS] Reducing CPU usage
by Programmingkid 02 Aug '11

02 Aug '11

> > On Mon, Aug 1, 2011 at 2:11 AM, Programmingkid > <programmingkidx(a)gmail.com> wrote: >> Is there a way to make OpenBIOS not use so much CPU time when running in QEMU? My laptop becomes very hot when I do anything in OpenBIOS. > > I've noticed that too. The input device (keyboard/serial) is scanned > in a tight busy loop. With some effort, this could be changed to > interrupt driven. I was thinking the exact same thing. > But the same thing happens also when lots of Forth is executed, maybe > the Forth interpreter and QEMU code fits in the CPU cache nicely and > this then maximizes CPU throughput and power consumption. Maybe we should give the user the option to reduce cpu usage. A compile-time or runtime option might do. My idea is set the interrupt controller to run code that makes the currently running code sleep for 10 milliseconds. That would take care of both problems. We would finally have computers that don't feel like space heaters after doing some Forth programming on them.

1 0

Reducing CPU usage
by Programmingkid 01 Aug '11

01 Aug '11

Is there a way to make OpenBIOS not use so much CPU time when running in QEMU? My laptop becomes very hot when I do anything in OpenBIOS.

2 1

Re: [OpenBIOS] [Qemu-devel] OpenBSD/macppc and sparc64 failing to boot with similar error.
by Blue Swirl 01 Aug '11

01 Aug '11

On Mon, Aug 1, 2011 at 12:33 AM, Brad <brad(a)comstyle.com> wrote: > I know sparc64 had little chance of actually working but > I thought I'd take it for a spin with 0.15.0-rc1 and > see how it fared in addition to macppc which has a good > chance of working nowdays with modern QEMU. Lets see > what QEMU and related bugs are left.. > > I noticed the bootblocks for each respective arch are > failing in a very similar manner. I would guess that > this is most likely a bug with the OpenBIOS Open Firmware > implementation? > > Any assistance with this? Blue? > > > $ qemu-system-ppc -nographic -cdrom cd50.iso -boot d > >>> ============================================================= >>> OpenBIOS 1.0 [Jun 16 2011 08:02] >>> Configuration device id QEMU version 1 machine id 2 >>> CPUs: 1 >>> Memory: 128M >>> UUID: 00000000-0000-0000-0000-000000000000 >>> CPU type PowerPC,750 > Welcome to OpenBIOS v1.0 built on Jun 16 2011 08:02 > Trying cd:,\\:tbxi... >>> OpenBSD/macppc BOOT 1.1 > open(cd:/etc/boot.conf): Unknown error: code 24 > boot> ? > > > $ qemu-system-sparc64 -nographic -cdrom cd50.iso -boot d > OpenBIOS for Sparc64 > Configuration device id QEMU version 1 machine id 0 > kernel cmdline > CPUs: 1 x SUNW,UltraSPARC-IIi > UUID: 00000000-0000-0000-0000-000000000000 > Welcome to OpenBIOS v1.0 built on Jul 20 2011 21:17 > Type 'help' for detailed information > Trying cdrom:f... > Not a bootable ELF image > Not a bootable a.out image > > Loading FCode image... > Loaded 4829 bytes > entry point is 0x4000 > OpenBSD IEEE 1275 Bootblock 1.3 > .. > Jumping to entry point 0000000000100000 for type 0000000000000001... > switching to new context: entry point 0x100000 stack 0x00000000ffe86b49 >>> OpenBSD BOOT 1.4 > Trying bsd... > open ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????: Unknown error: code 24 > > Boot: I get this with OpenBSD 4.3: OpenBIOS for Sparc64 Configuration device id QEMU version 1 machine id 0 kernel cmdline CPUs: 1 x SUNW,UltraSPARC-IIi UUID: 00000000-0000-0000-0000-000000000000 Welcome to OpenBIOS v1.0 built on Jul 20 2011 21:17 Type 'help' for detailed information Trying cdrom:f... Not a bootable ELF image Not a bootable a.out image Loading FCode image... Loaded 4893 bytes entry point is 0x4000 OpenBSD IEEE 1275 Bootblock 1.1 .. Jumping to entry point 0000000000800000 for type 0000000000000001... switching to new context: entry point 0x800000 stack 0x00000000ffe86b49 >> OpenBSD BOOT 1.2 Trying bsd... Booting cdrom:f/bsd 2590536@0x1000000+3236576@0x1800000+957728@0x1b162e0 symbols @ 0xffcda1c0 36 start=0x1000000 CHAINprom_get_msgbuf: test failed prom_get_msgbuf: allocated new buf at 00000000 prom_get_msgbuf: claiming new buf at 00000000

1 0

Re: [OpenBIOS] [Qemu-devel] [Bug 818645] [NEW] Unhandled OF service in FreeBSD loader - "unimplemented service milliseconds"
by Blue Swirl 31 Jul '11

31 Jul '11

On Sat, Jul 30, 2011 at 9:03 PM, Wojciech Koszek <818645(a)bugs.launchpad.net> wrote: > Public bug reported: > > wkoszek@wkoszek:~/bin/qemu/qemu$ git log | head -1 > commit c886edfb851c0c590d4e77f058f2ec8ed95ad1b5 > > built with default settings. > > Run like that: > /home/wkoszek/bin/qemu-dynamic/bin/qemu-system-sparc64 -m 1024 -cdrom ~/Pulpit/iso/FreeBSD-7.4-RELEASE-sparc64-bootonly.iso -hda ~/Pulpit/iso/freebsd_sparc64.qcow2 -nographic -boot d > > Configuration device id QEMU version 1 machine id 0 > kernel cmdline > CPUs: 1 x SUNW,UltraSPARC-IIi > UUID: 00000000-0000-0000-0000-000000000000 > Welcome to OpenBIOS v1.0 built on Jul 20 2011 21:17 > Type 'help' for detailed information > Trying cdrom:f... > Not a bootable ELF image > Loading a.out image... > Loaded 7680 bytes > entry point is 0x4000 > > Jumping to entry point 0000000000004000 for type 0000000000000005... > switching to new context: entry point 0x4000 stack 0x00000000ffe86b49 > >>> FreeBSD/sparc64 boot block > Boot path: cdrom:f > Boot loader: /boot/loader > Consoles: Open Firmware console > > Booting with sun4u support. > Boot path set to cdrom:a > > FreeBSD/sparc64 bootstrap loader, Revision 1.0 > (root(a)warner.cse.buffalo.edu, Fri Feb 18 05:38:31 UTC 2011) > bootpath="cdrom:a" > Loading /boot/defaults/loader.conf > /boot/kernel/kernel data=0x8d1f48+0x82f88 syms=[0x8+0x88ec0+0x8+0x76966] > | > Unimplemented service milliseconds ([0] -- [1]) > Hit [Enter] to boot immediately, or any other key for command prompt. > Unimplemented service milliseconds ([0] -- [1]) > Unimplemented service milliseconds ([0] -- [1]) > Unimplemented service milliseconds ([0] -- [1]) > Unimplemented service milliseconds ([0] -- [1]) > Unimplemented service milliseconds ([0] -- [1]) > > This basically loops here unless I press CTRL+C. > > Was there any OpenBIOS release that didn't have this problem? "milliseconds" has not implemented for Sparc, but there is a similar service for PPC machines which could be used as a starting point. > > ** Affects: qemu > Importance: Undecided > Status: New > > > ** Tags: freebsd > > -- > You received this bug notification because you are a member of qemu- > devel-ml, which is subscribed to QEMU. > https://bugs.launchpad.net/bugs/818645 > > Title: > Unhandled OF service in FreeBSD loader - "unimplemented service > milliseconds" > > Status in QEMU: > New > > Bug description: > wkoszek@wkoszek:~/bin/qemu/qemu$ git log | head -1 > commit c886edfb851c0c590d4e77f058f2ec8ed95ad1b5 > > built with default settings. > > Run like that: > /home/wkoszek/bin/qemu-dynamic/bin/qemu-system-sparc64 -m 1024 -cdrom ~/Pulpit/iso/FreeBSD-7.4-RELEASE-sparc64-bootonly.iso -hda ~/Pulpit/iso/freebsd_sparc64.qcow2 -nographic -boot d > > Configuration device id QEMU version 1 machine id 0 > kernel cmdline > CPUs: 1 x SUNW,UltraSPARC-IIi > UUID: 00000000-0000-0000-0000-000000000000 > Welcome to OpenBIOS v1.0 built on Jul 20 2011 21:17 > Type 'help' for detailed information > Trying cdrom:f... > Not a bootable ELF image > Loading a.out image... > Loaded 7680 bytes > entry point is 0x4000 > > Jumping to entry point 0000000000004000 for type 0000000000000005... > switching to new context: entry point 0x4000 stack 0x00000000ffe86b49 > > >> FreeBSD/sparc64 boot block > Boot path: cdrom:f > Boot loader: /boot/loader > Consoles: Open Firmware console > > Booting with sun4u support. > Boot path set to cdrom:a > > FreeBSD/sparc64 bootstrap loader, Revision 1.0 > (root(a)warner.cse.buffalo.edu, Fri Feb 18 05:38:31 UTC 2011) > bootpath="cdrom:a" > Loading /boot/defaults/loader.conf > /boot/kernel/kernel data=0x8d1f48+0x82f88 syms=[0x8+0x88ec0+0x8+0x76966] > | > Unimplemented service milliseconds ([0] -- [1]) > Hit [Enter] to boot immediately, or any other key for command prompt. > Unimplemented service milliseconds ([0] -- [1]) > Unimplemented service milliseconds ([0] -- [1]) > Unimplemented service milliseconds ([0] -- [1]) > Unimplemented service milliseconds ([0] -- [1]) > Unimplemented service milliseconds ([0] -- [1]) > > This basically loops here unless I press CTRL+C. > > Was there any OpenBIOS release that didn't have this problem? > > To manage notifications about this bug go to: > https://bugs.launchpad.net/qemu/+bug/818645/+subscriptions > >

1 0

OpenBIOS PowerPC missing open firmware commands
by Alexander von Gluck 20 Jul '11

20 Jul '11

Just a few things I noticed while hacking away at Haiku on PowerPC: The following OpenFirmware commands aren't implemented: erase-screen toggle-cursor The following paths are missing essential information: cpu node -> clock-frequency cpu node -> timebase-frequency cpu node -> bus-frequency Example: cd / cd cpus cd PowerPC,750@0 .properties These properties are present on real PowerPC hardware, but are set to 0 (or missing in the case of bus-frequency) on the qemu OpenBIOS. Thoughts? Thanks! -- Alex

3 10

Re: [OpenBIOS] OpenBios Sparc64
by Ghitulete Razvan 19 Jul '11

19 Jul '11

> I started playing with the OpenFirmware(I got a SunBlade in the > meanwhile). But i'm not able to get an instance of the SUNW,m64B, and > as a matter of fact of nothing, as I get a Fast Data Access MMU Miss > every time i try the open-dev command. I know I don't need an instance > to get the .properties of the device, but I think that MUU miss > couldn't be a good thing... > So I kinda got rid of that MMU Miss error, but now, when i try and open-dev the display adapter i get a 0 return code on the stack. The output being something like this. ok showstack ok " /pci/SUNW,m64B " open-dev 0 ok Is there anything wrong with this approach. I mean a reason for the 0 return code? -- Razvan Ghitulete Universitatea Politehnica Bucuresti

1 0

Re: [OpenBIOS] OpenBios Sparc64
by Tarl Neustaedter 19 Jul '11

19 Jul '11

On 2011-Jul-18 03:09 , Ghitulete Razvan wrote: >> > Ah - on SPARCs, the video is not at a fixed address. The "display" >> > device tree node will tell you what the physical address is (which >> > varies from platform to platform) with the "reg" property, and you have >> > to "map-in" that physical address to a virtual address. > Do you happen to know/have any books/papers on this aspect of the > sparc architecture. On the oracle web site I only found the V9, and it > doesn't mention anything about this stuff, as far as i've read. > Mostly in the IEEE 1275 specification. Look at the "reg" and "assigned-address" properties, and the semantics of "map-in". On SBus machines, the FCode of the SBus cards would created these properties indicating where the PIO space of video card would be, on PCI machines, the BARs will do this and be reflected in the "reg" and "assigned-address" properties.

2 1

Re: [OpenBIOS] OpenBios Sparc64
by Ghitulete Razvan 18 Jul '11

18 Jul '11

> ./configure --target-list=sparc64-softmmu > Mark. Thanks I'll give this a try. > Ah - on SPARCs, the video is not at a fixed address. The "display" > device tree node will tell you what the physical address is (which > varies from platform to platform) with the "reg" property, and you have > to "map-in" that physical address to a virtual address. Do you happen to know/have any books/papers on this aspect of the sparc architecture. On the oracle web site I only found the V9, and it doesn't mention anything about this stuff, as far as i've read. Thanks, -- Razvan Ghitulete Universitatea Politehnica Bucuresti

1 0

fcode rom loading
by Bob Breuer 14 Jul '11

14 Jul '11

I'm trying to get the sparc32 OpenBIOS to load an fcode rom, but it's not working. After byte-load, it reports out of memory. Here's the steps I'm using to setup a simple rom which just sets the device name to "QEMU,test", and then trying to run it: fd000000 1000 l! 00000020 1004 l! 12095145 1008 l! 4d552c74 100c l! 65737401 1010 l! 1412046e 1014 l! 616d6501 1018 l! 10000000 101c l! cd /iommu/sbus " /iommu/sbus" select-dev new-device 1000 1 byte-load Here, OpenBIOS will report out of memory. Bob

2 11

[commit] r1045 - trunk/openbios-devel/arch/sparc32
by repository service 14 Jul '11

14 Jul '11

Author: mcayland Date: Thu Jul 14 16:37:34 2011 New Revision: 1045 URL: http://tracker.coreboot.org/trac/openbios/changeset/1045 Log: Fix Fcode table initialisation on SPARC32. Increase the Forth machine memory to 128K (also requiring a corresponding increase in OFMEM to 384K) to allow enough space for the Fcode tables to be initialised, and hence allow Fcode to be executed under SPARC32. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)siriusit.co.uk> Acked-by: Bob Breuer <breuerr(a)mc.net> Modified: trunk/openbios-devel/arch/sparc32/ofmem_sparc32.c trunk/openbios-devel/arch/sparc32/openbios.c Modified: trunk/openbios-devel/arch/sparc32/ofmem_sparc32.c ============================================================================== --- trunk/openbios-devel/arch/sparc32/ofmem_sparc32.c Fri Jun 17 02:55:04 2011 (r1044) +++ trunk/openbios-devel/arch/sparc32/ofmem_sparc32.c Thu Jul 14 16:37:34 2011 (r1045) @@ -21,7 +21,7 @@ #define OF_MALLOC_BASE ((char*)OFMEM + ALIGN_SIZE(sizeof(ofmem_t), 8)) -#define MEMSIZE (256 * 1024) +#define MEMSIZE (384 * 1024) static union { char memory[MEMSIZE]; ofmem_t ofmem; Modified: trunk/openbios-devel/arch/sparc32/openbios.c ============================================================================== --- trunk/openbios-devel/arch/sparc32/openbios.c Fri Jun 17 02:55:04 2011 (r1044) +++ trunk/openbios-devel/arch/sparc32/openbios.c Thu Jul 14 16:37:34 2011 (r1045) @@ -27,7 +27,7 @@ #include "arch/common/fw_cfg.h" #include "libopenbios/ofmem.h" -#define MEMORY_SIZE (16*1024) /* 16K ram for hosted system */ +#define MEMORY_SIZE (128*1024) /* 128K ram for hosted system */ #define UUID_FMT "%02x%02x%02x%02x-%02x%02x-%02x%02x-%02x%02x-%02x%02x%02x%02x%02x%02x" #define FW_CFG_SUN4M_DEPTH (FW_CFG_ARCH_LOCAL + 0x00)

1 0

Re: [OpenBIOS] OpenBios Sparc64
by Tarl Neustaedter 12 Jul '11

12 Jul '11

On 2011-Jul-12 07:51 , Ghitulete Razvan wrote: > Also, if anyone has any ideea whatsoever, could i write directly to > the video memory on a sparc, and if so at what address does the video > card mapping starts? Ah - on SPARCs, the video is not at a fixed address. The "display" device tree node will tell you what the physical address is (which varies from platform to platform) with the "reg" property, and you have to "map-in" that physical address to a virtual address.

1 0

Re: [OpenBIOS] OpenBios Sparc64
by Mark Cave-Ayland 12 Jul '11

12 Jul '11

On 12/07/11 12:51, Ghitulete Razvan wrote: > Well, I compiled openbios using the script for cross-compiling with > cross-sparc64. As far as the error messages go, during compilation > there are none whatsoever. And I'm running qemu without any arguments > for now, just plain qemu-system-sparc as i just want to see if it > works. Ah wait - if you are trying to run a 64-bit SPARC binary then you need to run qemu-system-sparc64 instead of qemu-system-sparc which is 32-bit only. IIRC you need to explicitly enable the SPARC64 target at QEMU compile-time by doing something like: ./configure --target-list=sparc64-softmmu HTH, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

1 0

OpenBios Sparc64
by Ghitulete Razvan 12 Jul '11

12 Jul '11

> Hi, > > I think you'll need to give a bit more information as to what command > lines you are using for QEMU, any error messages you see during > compilation and details of how you built your cross-compilation > environment (e.g. compiler versions etc.). > >M-D. Well, I compiled openbios using the script for cross-compiling with cross-sparc64. As far as the error messages go, during compilation there are none whatsoever. And I'm running qemu without any arguments for now, just plain qemu-system-sparc as i just want to see if it works. The cross-compiling toolchains i tried consisted of a gcc 4.1.1 and binutils 2.16.1 and a gcc 4.4.3 and binutils 2.20. I switched to 4.4.3 and 2.20 as for the 4.1.1 i modified several binutils source-files to be able to compile it, so i figured this might have something to do with it. Also, if anyone has any ideea whatsoever, could i write directly to the video memory on a sparc, and if so at what address does the video card mapping starts? -- Razvan Ghitulete Universitatea Politehnica Bucuresti

1 0

Re: [OpenBIOS] OpenBios Sparc64
by Mark Cave-Ayland 11 Jul '11

11 Jul '11

On 08/07/11 14:15, Ghitulete Razvan wrote: > Hi, > I am trying to do a cross-compiler for a sparc64 machine, and I > thought of testing it with the openbios-sparc64 for qemu. But for some > reason I keep getting qemu errors. Does anyone know how the initial > openbios-sparc64 that comes with the qemu binaries was compiled. I am > working at a bigger project and for now i don't have acces to a > physical sparc machine to test whether the cross works well, so this > is kinda my only way of having a hint, plus doing some work on the > project until i get the real deal on my desk. Any ideas would be > welcome Hi, I think you'll need to give a bit more information as to what command lines you are using for QEMU, any error messages you see during compilation and details of how you built your cross-compilation environment (e.g. compiler versions etc.). M-D. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

1 0

OpenBios Sparc64
by Ghitulete Razvan 08 Jul '11

08 Jul '11

Hi, I am trying to do a cross-compiler for a sparc64 machine, and I thought of testing it with the openbios-sparc64 for qemu. But for some reason I keep getting qemu errors. Does anyone know how the initial openbios-sparc64 that comes with the qemu binaries was compiled. I am working at a bigger project and for now i don't have acces to a physical sparc machine to test whether the cross works well, so this is kinda my only way of having a hint, plus doing some work on the project until i get the real deal on my desk. Any ideas would be welcome Sincerely, -- Razvan Ghitulete Universitatea Politehnica Bucuresti

1 0

Re: [OpenBIOS] SS-10 and SS-20
by Brian Vandenberg 20 Jun '11

20 Jun '11

I'm curious whether support exists for sparcstation's 10 & 20 yet. Any comments? -Brian

6 8

[commit] r1043 - trunk/openbios-devel/arch/ppc/qemu
by repository service 18 Jun '11

18 Jun '11

Author: agraf Date: Fri Jun 17 02:55:02 2011 New Revision: 1043 URL: http://tracker.coreboot.org/trac/openbios/changeset/1043 Log: ppc: fix mtmsr for SF setting When running openbios-ppc32 on a ppc64 VM, we need to unset SF on every interrupt to ensure that things still work. So far we've been using mtmsr for this operation, but according to the spec mtmsr doesn't set any bit above 32bit, so we were merely exploiting a bug in qemu before. This patch adds a runtime check on MSR_SF to see if we're running on a 64-bit capable CPU. If so, we use mtmsrd, which can set the high 32bits of MSR. CC: Andreas Färber <andreas.faerber(a)web.de> CC: Segher Boessenkool <segher(a)kernel.crashing.org> Signed-off-by: Alexander Graf <agraf(a)suse.de> --- v1 -> v2: - use segher's awesome MSR_SF detection Modified: trunk/openbios-devel/arch/ppc/qemu/start.S Modified: trunk/openbios-devel/arch/ppc/qemu/start.S ============================================================================== --- trunk/openbios-devel/arch/ppc/qemu/start.S Fri Jun 17 02:55:00 2011 (r1042) +++ trunk/openbios-devel/arch/ppc/qemu/start.S Fri Jun 17 02:55:02 2011 (r1043) @@ -37,9 +37,16 @@ #define EXCEPTION_PREAMBLE_TEMPLATE \ mtsprg1 r1 ; /* scratch */ \ + mfcr r1 ; \ + mtsprg2 r1 ; /* scratch */ \ + lis r1, 0x8000 ; /* r1=0x80000000 */ \ + add. r1,r1,r1 ; /* r1=r1+r1 (high 32bit !0) */ \ + beq 1f; \ + \ mfmsr r1 ; /* unset MSR_SF */ \ clrlwi r1,r1,0 ; \ - mtmsr r1 ; \ + mtmsrd r1 ; \ +1: \ mfsprg0 r1 ; /* exception stack in sprg0 */ \ .ifc ULONG_SIZE, 8 ; \ addi r1,r1,-(40 * ULONG_SIZE) ; /* push exception frame */ \ @@ -85,7 +92,7 @@ \ mflr r0 ; \ stl r0,(13 * ULONG_SIZE)(r1) ; \ - mfcr r0 ; \ + mfsprg2 r0 ; \ stl r0,(14 * ULONG_SIZE)(r1) ; \ mfctr r0 ; \ stl r0,(15 * ULONG_SIZE)(r1) ; \ @@ -301,14 +308,12 @@ ILLEGAL_VECTOR( 0x200 ) VECTOR( 0x300, "DSI" ): - EXCEPTION_PREAMBLE - b call_dsi_exception + b real_dsi ILLEGAL_VECTOR( 0x380 ) VECTOR( 0x400, "ISI" ): - EXCEPTION_PREAMBLE - b call_isi_exception + b real_isi ILLEGAL_VECTOR( 0x480 ) @@ -359,6 +364,14 @@ #endif +real_dsi: + EXCEPTION_PREAMBLE + b call_dsi_exception + +real_isi: + EXCEPTION_PREAMBLE + b call_isi_exception + GLOBL(__vectors_end): /************************************************************************/ @@ -368,10 +381,21 @@ GLOBL(_entry): #ifdef CONFIG_PPC_64BITSUPPORT - /* clear MSR, disable MMU */ - li r0,0 + + lis r3, 0x8000 /* r1=0x80000000 */ + add. r3,r3,r3 /* r1=r1+r1 (high 32bit !0) */ + beq no_64bit /* only true when !MSR_SF */ + + /* clear MSR, disable MMU, SF */ + mtmsrd r0 + b real_entry + +no_64bit: + /* clear MSR, disable MMU */ mtmsr r0 + +real_entry: #endif /* copy exception vectors */

3 4

[commit] r1042 - trunk/openbios-devel/arch/ppc/qemu
by repository service 18 Jun '11

18 Jun '11

Author: agraf Date: Fri Jun 17 02:55:00 2011 New Revision: 1042 URL: http://tracker.coreboot.org/trac/openbios/changeset/1042 Log: ppc: add POWER4 cpu description So far, we only supported the 970fx CPU type inside guests. Unfortunately, that CPU supports Altivec. Not all KVM capable host CPUs do have altivec though, so they're left out in the rain when running openbios in the guest. This patch adds POWER4 CPU description, allowing users to specify at least one CPU type that does not require Altivec, but is still 64-bit capable. Signed-off-by: Alexander Graf <agraf(a)suse.de> Modified: trunk/openbios-devel/arch/ppc/qemu/init.c Modified: trunk/openbios-devel/arch/ppc/qemu/init.c ============================================================================== --- trunk/openbios-devel/arch/ppc/qemu/init.c Mon May 23 00:29:33 2011 (r1041) +++ trunk/openbios-devel/arch/ppc/qemu/init.c Fri Jun 17 02:55:00 2011 (r1042) @@ -507,6 +507,18 @@ .clock_frequency = 0x1dcd6500, .initfn = cpu_970_init, }, + { + .iu_version = 0x00350000, + .name = "PowerPC,POWER4", + .icache_size = 0x10000, + .dcache_size = 0x8000, + .icache_sets = 0x100, + .dcache_sets = 0x40, + .icache_block_size = 0x80, + .dcache_block_size = 0x80, + .clock_frequency = 0x629b4940, + .initfn = cpu_970_init, + }, }; static const struct cpudef *

3 2

[PATCH] ppc: fix mtmsr for SF setting
by Alexander Graf 18 Jun '11

18 Jun '11

When running openbios-ppc32 on a ppc64 VM, we need to unset SF on every interrupt to ensure that things still work. So far we've been using mtmsr for this operation, but according to the spec mtmsr doesn't set any bit above 32bit, so we were merely exploiting a bug in qemu before. This patch adds a runtime check on PVR to see if we're running on a 64-bit capable CPU. If so, we use mtmsrd, which can set the high 32bits of MSR. CC: Andreas Färber <andreas.faerber(a)web.de> Signed-off-by: Alexander Graf <agraf(a)suse.de> --- arch/ppc/qemu/start.S | 50 +++++++++++++++++++++++++++++++++++++++++------- 1 files changed, 42 insertions(+), 8 deletions(-) diff --git a/arch/ppc/qemu/start.S b/arch/ppc/qemu/start.S index 0d64568..70a4f92 100644 --- a/arch/ppc/qemu/start.S +++ b/arch/ppc/qemu/start.S @@ -37,9 +37,21 @@ #define EXCEPTION_PREAMBLE_TEMPLATE \ mtsprg1 r1 ; /* scratch */ \ + mfcr r1 ; \ + mtsprg2 r1 ; /* scratch */ \ + mtsprg3 r2 ; /* scratch */ \ + mfpvr r1 ; \ + lis r2, 0x330000@h ; /* lowest 64-bit PVR */ \ + cmplw r1, r2 ; \ + blt 1f; \ + oris r2, r2, 0x70000000@h ; /* highest 64-bit PVR */ \ + cmplw r1, r2 ; \ + bge 1f; \ + \ mfmsr r1 ; /* unset MSR_SF */ \ clrlwi r1,r1,0 ; \ - mtmsr r1 ; \ + mtmsrd r1 ; \ +1: \ mfsprg0 r1 ; /* exception stack in sprg0 */ \ .ifc ULONG_SIZE, 8 ; \ addi r1,r1,-(40 * ULONG_SIZE) ; /* push exception frame */ \ @@ -50,6 +62,7 @@ stl r0,(0 * ULONG_SIZE)(r1) ; /* save r0 */ \ mfsprg1 r0 ; \ stl r0,(1 * ULONG_SIZE)(r1) ; /* save r1 */ \ + mfsprg3 r2 ; \ stl r2,(2 * ULONG_SIZE)(r1) ; /* save r2 */ \ stl r3,(3 * ULONG_SIZE)(r1) ; /* save r3 */ \ stl r4,(4 * ULONG_SIZE)(r1) ; \ @@ -85,7 +98,7 @@ \ mflr r0 ; \ stl r0,(13 * ULONG_SIZE)(r1) ; \ - mfcr r0 ; \ + mfsprg2 r0 ; \ stl r0,(14 * ULONG_SIZE)(r1) ; \ mfctr r0 ; \ stl r0,(15 * ULONG_SIZE)(r1) ; \ @@ -301,14 +314,12 @@ VECTOR( 0x100, "SRE" ): ILLEGAL_VECTOR( 0x200 ) VECTOR( 0x300, "DSI" ): - EXCEPTION_PREAMBLE - b call_dsi_exception + b real_dsi ILLEGAL_VECTOR( 0x380 ) VECTOR( 0x400, "ISI" ): - EXCEPTION_PREAMBLE - b call_isi_exception + b real_isi ILLEGAL_VECTOR( 0x480 ) @@ -359,6 +370,14 @@ VECTOR( 0x2200, "ISI_64" ): #endif +real_dsi: + EXCEPTION_PREAMBLE + b call_dsi_exception + +real_isi: + EXCEPTION_PREAMBLE + b call_isi_exception + GLOBL(__vectors_end): /************************************************************************/ @@ -368,10 +387,25 @@ GLOBL(__vectors_end): GLOBL(_entry): #ifdef CONFIG_PPC_64BITSUPPORT - /* clear MSR, disable MMU */ - li r0,0 + + mfpvr r3 + lis r4, 0x330000@h /* lowest 64-bit PVR */ + cmplw r3, r4 + blt no_64bit + oris r4, r4, 0x70000000@h /* highest 64-bit PVR */ + cmplw r3, r4 + bge no_64bit + + /* clear MSR, disable MMU, SF */ + mtmsrd r0 + b real_entry + +no_64bit: + /* clear MSR, disable MMU */ mtmsr r0 + +real_entry: #endif /* copy exception vectors */ -- 1.6.0.2

2 2

[commit] r1044 - trunk/openbios-devel/arch/ppc/qemu
by repository service 17 Jun '11

17 Jun '11

Author: agraf Date: Fri Jun 17 02:55:04 2011 New Revision: 1044 URL: http://tracker.coreboot.org/trac/openbios/changeset/1044 Log: ppc: only clear MSR_SF when clearing high MSR bits We are pretty aggressive now with how we clear the high MSR bits, clearing all of them when we find a 64-bit CPU. As Segher points out, this is not always a good idea though. There might be bits set that can be crucial for operation. Hence we should only clear MSR_SF, as that's the bit we're interested in. Reported-by: Segher Boessenkool <segher(a)kernel.crashing.org> Signed-off-by: Alexander Graf <agraf(a)suse.de> Modified: trunk/openbios-devel/arch/ppc/qemu/start.S Modified: trunk/openbios-devel/arch/ppc/qemu/start.S ============================================================================== --- trunk/openbios-devel/arch/ppc/qemu/start.S Fri Jun 17 02:55:02 2011 (r1043) +++ trunk/openbios-devel/arch/ppc/qemu/start.S Fri Jun 17 02:55:04 2011 (r1044) @@ -44,7 +44,7 @@ beq 1f; \ \ mfmsr r1 ; /* unset MSR_SF */ \ - clrlwi r1,r1,0 ; \ + clrldi r1,r1,1 ; \ mtmsrd r1 ; \ 1: \ mfsprg0 r1 ; /* exception stack in sprg0 */ \

1 0

[PATCH] ppc: fix mtmsr for SF setting
by Alexander Graf 17 Jun '11

17 Jun '11

When running openbios-ppc32 on a ppc64 VM, we need to unset SF on every interrupt to ensure that things still work. So far we've been using mtmsr for this operation, but according to the spec mtmsr doesn't set any bit above 32bit, so we were merely exploiting a bug in qemu before. This patch adds a runtime check on PVR to see if we're running on a 64-bit capable CPU. If so, we use mtmsrd, which can set the high 32bits of MSR. CC: Andreas Färber <andreas.faerber(a)web.de> Signed-off-by: Alexander Graf <agraf(a)suse.de> --- arch/ppc/qemu/start.S | 50 +++++++++++++++++++++++++++++++++++++++++------- 1 files changed, 42 insertions(+), 8 deletions(-) diff --git a/arch/ppc/qemu/start.S b/arch/ppc/qemu/start.S index 0d64568..70a4f92 100644 --- a/arch/ppc/qemu/start.S +++ b/arch/ppc/qemu/start.S @@ -37,9 +37,21 @@ #define EXCEPTION_PREAMBLE_TEMPLATE \ mtsprg1 r1 ; /* scratch */ \ + mfcr r1 ; \ + mtsprg2 r1 ; /* scratch */ \ + mtsprg3 r2 ; /* scratch */ \ + mfpvr r1 ; \ + lis r2, 0x330000@h ; /* lowest 64-bit PVR */ \ + cmplw r1, r2 ; \ + blt 1f; \ + oris r2, r2, 0x70000000@h ; /* highest 64-bit PVR */ \ + cmplw r1, r2 ; \ + bge 1f; \ + \ mfmsr r1 ; /* unset MSR_SF */ \ clrlwi r1,r1,0 ; \ - mtmsr r1 ; \ + mtmsrd r1 ; \ +1: \ mfsprg0 r1 ; /* exception stack in sprg0 */ \ .ifc ULONG_SIZE, 8 ; \ addi r1,r1,-(40 * ULONG_SIZE) ; /* push exception frame */ \ @@ -50,6 +62,7 @@ stl r0,(0 * ULONG_SIZE)(r1) ; /* save r0 */ \ mfsprg1 r0 ; \ stl r0,(1 * ULONG_SIZE)(r1) ; /* save r1 */ \ + mfsprg3 r2 ; \ stl r2,(2 * ULONG_SIZE)(r1) ; /* save r2 */ \ stl r3,(3 * ULONG_SIZE)(r1) ; /* save r3 */ \ stl r4,(4 * ULONG_SIZE)(r1) ; \ @@ -85,7 +98,7 @@ \ mflr r0 ; \ stl r0,(13 * ULONG_SIZE)(r1) ; \ - mfcr r0 ; \ + mfsprg2 r0 ; \ stl r0,(14 * ULONG_SIZE)(r1) ; \ mfctr r0 ; \ stl r0,(15 * ULONG_SIZE)(r1) ; \ @@ -301,14 +314,12 @@ VECTOR( 0x100, "SRE" ): ILLEGAL_VECTOR( 0x200 ) VECTOR( 0x300, "DSI" ): - EXCEPTION_PREAMBLE - b call_dsi_exception + b real_dsi ILLEGAL_VECTOR( 0x380 ) VECTOR( 0x400, "ISI" ): - EXCEPTION_PREAMBLE - b call_isi_exception + b real_isi ILLEGAL_VECTOR( 0x480 ) @@ -359,6 +370,14 @@ VECTOR( 0x2200, "ISI_64" ): #endif +real_dsi: + EXCEPTION_PREAMBLE + b call_dsi_exception + +real_isi: + EXCEPTION_PREAMBLE + b call_isi_exception + GLOBL(__vectors_end): /************************************************************************/ @@ -368,10 +387,25 @@ GLOBL(__vectors_end): GLOBL(_entry): #ifdef CONFIG_PPC_64BITSUPPORT - /* clear MSR, disable MMU */ - li r0,0 + + mfpvr r3 + lis r4, 0x330000@h /* lowest 64-bit PVR */ + cmplw r3, r4 + blt no_64bit + oris r4, r4, 0x70000000@h /* highest 64-bit PVR */ + cmplw r3, r4 + bge no_64bit + + /* clear MSR, disable MMU, SF */ + mtmsrd r0 + b real_entry + +no_64bit: + /* clear MSR, disable MMU */ mtmsr r0 + +real_entry: #endif /* copy exception vectors */ -- 1.6.0.2

3 5

[PATCH] ppc: only clear MSR_SF when clearing high MSR bits
by Alexander Graf 17 Jun '11

17 Jun '11

We are pretty aggressive now with how we clear the high MSR bits, clearing all of them when we find a 64-bit CPU. As Segher points out, this is not always a good idea though. There might be bits set that can be crucial for operation. Hence we should only clear MSR_SF, as that's the bit we're interested in. Reported-by: Segher Boessenkool <segher(a)kernel.crashing.org> Signed-off-by: Alexander Graf <agraf(a)suse.de> --- arch/ppc/qemu/start.S | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/ppc/qemu/start.S b/arch/ppc/qemu/start.S index f06f6d5..aa582e2 100644 --- a/arch/ppc/qemu/start.S +++ b/arch/ppc/qemu/start.S @@ -44,7 +44,7 @@ beq 1f; \ \ mfmsr r1 ; /* unset MSR_SF */ \ - clrlwi r1,r1,0 ; \ + clrldi r1,r1,1 ; \ mtmsrd r1 ; \ 1: \ mfsprg0 r1 ; /* exception stack in sprg0 */ \ -- 1.6.0.2

1 0

Re: [OpenBIOS] Solaris anyone?
by Kenneth Salerno 06 Jun '11

06 Jun '11

Really. Who has a sound card on a sparc server anyway? (I can feel the offended stares of the Sun Blade100 users)

1 0

[PATCH 1/3] Introduce PRI*CELL macros
by Andreas Färber 04 Jun '11

04 Jun '11

As done for prom_arg_t, introduce POSIX-like PRI* macros for [u]cell. Signed-off-by: Andreas Färber <andreas.faerber(a)web.de> --- include/arch/amd64/types.h | 6 +++++- include/arch/ia64/types.h | 5 +++++ include/arch/ppc/types.h | 12 ++++++++---- include/arch/sparc32/types.h | 12 ++++++++---- include/arch/sparc64/types.h | 12 ++++++++---- include/arch/x86/types.h | 12 ++++++++---- 6 files changed, 42 insertions(+), 17 deletions(-) diff --git a/include/arch/amd64/types.h b/include/arch/amd64/types.h index 83fd3e1..74503b9 100644 --- a/include/arch/amd64/types.h +++ b/include/arch/amd64/types.h @@ -29,7 +29,11 @@ typedef uint64_t ucell; typedef __int128_t dcell; typedef __uint128_t ducell; -#define FMT_ucellx "%016" PRIx64 +#define PRIdCELL PRId64 +#define PRIuCELL PRIu64 +#define PRIxCELL PRIx64 +#define PRIXCELL PRIX64 +#define FMT_ucellx "%016" PRIxCELL typedef int64_t prom_arg_t; typedef uint64_t prom_uarg_t; diff --git a/include/arch/ia64/types.h b/include/arch/ia64/types.h index cb09cda..5334027 100644 --- a/include/arch/ia64/types.h +++ b/include/arch/ia64/types.h @@ -30,6 +30,11 @@ typedef uint64_t ucell; typedef __int128_t dcell; typedef __uint128_t ducell; +#define PRIdCELL PRId64 +#define PRIuCELL PRIu64 +#define PRIxCELL PRIx64 +#define PRIXCELL PRIX64 + typedef int64_t prom_arg_t; typedef uint64_t prom_uarg_t; diff --git a/include/arch/ppc/types.h b/include/arch/ppc/types.h index cb1cc28..cd71a62 100644 --- a/include/arch/ppc/types.h +++ b/include/arch/ppc/types.h @@ -55,10 +55,14 @@ typedef uint32_t ucell; typedef int64_t dcell; typedef uint64_t ducell; -#define FMT_cell "%" PRId32 -#define FMT_ucell "%" PRIu32 -#define FMT_ucellx "%08" PRIx32 -#define FMT_ucellX "%08" PRIX32 +#define PRIdCELL PRId32 +#define PRIuCELL PRIu32 +#define PRIxCELL PRIx32 +#define PRIXCELL PRIX32 +#define FMT_cell "%" PRIdCELL +#define FMT_ucell "%" PRIuCELL +#define FMT_ucellx "%08" PRIxCELL +#define FMT_ucellX "%08" PRIXCELL typedef int32_t prom_arg_t; typedef uint32_t prom_uarg_t; diff --git a/include/arch/sparc32/types.h b/include/arch/sparc32/types.h index f765874..363650e 100644 --- a/include/arch/sparc32/types.h +++ b/include/arch/sparc32/types.h @@ -52,10 +52,14 @@ typedef uint32_t ucell; typedef long long dcell; typedef unsigned long long ducell; -#define FMT_cell "%" PRId32 -#define FMT_ucell "%" PRIu32 -#define FMT_ucellx "%08" PRIx32 -#define FMT_ucellX "%08" PRIX32 +#define PRIdCELL PRId32 +#define PRIuCELL PRIu32 +#define PRIxCELL PRIx32 +#define PRIXCELL PRIX32 +#define FMT_cell "%" PRIdCELL +#define FMT_ucell "%" PRIuCELL +#define FMT_ucellx "%08" PRIxCELL +#define FMT_ucellX "%08" PRIXCELL typedef int32_t prom_arg_t; typedef uint32_t prom_uarg_t; diff --git a/include/arch/sparc64/types.h b/include/arch/sparc64/types.h index 8784331..268b78a 100644 --- a/include/arch/sparc64/types.h +++ b/include/arch/sparc64/types.h @@ -48,10 +48,14 @@ typedef uint64_t phys_addr_t; typedef int64_t cell; typedef uint64_t ucell; -#define FMT_cell "%" PRId64 -#define FMT_ucell "%" PRIu64 -#define FMT_ucellx "%016" PRIx64 -#define FMT_ucellX "%016" PRIX64 +#define PRIdCELL PRId64 +#define PRIuCELL PRIu64 +#define PRIxCELL PRIx64 +#define PRIXCELL PRIX64 +#define FMT_cell "%" PRIdCELL +#define FMT_ucell "%" PRIuCELL +#define FMT_ucellx "%016" PRIxCELL +#define FMT_ucellX "%016" PRIXCELL typedef int64_t prom_arg_t; typedef uint64_t prom_uarg_t; diff --git a/include/arch/x86/types.h b/include/arch/x86/types.h index e06ab9b..7ea1831 100644 --- a/include/arch/x86/types.h +++ b/include/arch/x86/types.h @@ -30,10 +30,14 @@ typedef uint32_t ucell; typedef int64_t dcell; typedef uint64_t ducell; -#define FMT_cell "%" PRId32 -#define FMT_ucell "%" PRIu32 -#define FMT_ucellx "%08" PRIx32 -#define FMT_ucellX "%08" PRIX32 +#define PRIdCELL PRId32 +#define PRIuCELL PRIu32 +#define PRIxCELL PRIx32 +#define PRIXCELL PRIX32 +#define FMT_cell "%" PRIdCELL +#define FMT_ucell "%" PRIuCELL +#define FMT_ucellx "%08" PRIxCELL +#define FMT_ucellX "%08" PRIXCELL typedef int32_t prom_arg_t; typedef uint32_t prom_uarg_t; -- 1.7.3.4

5 18

solaris 8 on sparc, webstart launcher crashing
by Brian Vandenberg 31 May '11

31 May '11

Greetings, I'm unsure whether the issue I'm running into is related to OpenBios, qemu, something buggy in this solaris distribution, or some combination thereof. Feel free to redirect me as appropriate. I'm able to install Solaris 8 (02/04) from the "Solaris 8 Software disk 1" disk. I see a few different behaviors depending on what I try: 1) boot from disk0:a without any special options: After specifying a root password, it says "Starting Web Start Launcher in Command Line Mode" and shortly thereafter says "The Webstart launcher has terminated unexpectedly." with no further details, except to say the machine will reboot after pressing enter. 2) Do the same thing, but with -v: The result doesn't seem predictable. Sometimes it just hangs after the "Starting ..." line, other times it dies with a variety of errors. I'll try to summarize below: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Starting Web Start Launcher in Command Line Mode. SIGSEGV 11 segmentation violation si_signo [11]: SEGV si_errno [0]: si_code [1]: SEGV_MAPPER [addr: 0x1000100 stackpointer=EE73E578 Inconsistent thread : best efforts attempt (may fail) "Thread-1" (TID:0x34c470, sys_thread_t:0x34c3a8, state:R, thread_t: t@12, threadID:0xee74098, stack_bottom:0xee740d98, stack_size:0x1fd98) prio=5 *current thread* [1] java.util.ResourceBundle.getBundle(ResourceBundle.java:346) [2] java.awt.Toolkit$3.run(Toolkit.java:887) [3] java.security.AccessController.doPriveleged(Native Method) [4] java.awt.Toolkit.<clinit>(Toolkit.java:882) [5] java.awt.Component.<clinit>(Component.java:336) [6] com.sun.wizards.core.WizardTreeManager.createWizardPanel(WizardTreeManager.java:801) [7] com.sun.wizards.core.WizardTreeManager.<init>(WizardTreeManager.java:265) [8] com.sun.wizards.core.CommandLineConsole.java:78) [9] java.lang.Thread.run(Thread.java:479) ------------------------------ Inconsistent thread : best efforts attempt (may fail) "process reaper" (TID:0x2c4600, sys_thread_t:0x2c4538, state:R, thread_t: t@10, threadID:0xee7b0d98, stack_bottom:0xee7b0d98, stack_size:0x1fd98) prio=5 [1] java.lang.UNIXProcess.waitForProcessExit(Native Method) [2] java.lang.UNIXProcess.access$10(UNIXProcess.java:30) [3] java.lang.UNIXProcess$3.run(UNIXProcess.java:74) -------------------------- Inconsistent thread : best efforts attempt (may fail) "Finalizer" (TID:0x156d80, sys_thread_t:0x156cb8, state:CW, thread_t: t&2, threadID:0xee890d98, stack_bottom:0xee890d98, stack_size:0x1fd98) prio=8 [1] java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:145) [2] java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:167) [3] java.lang.ref.Finalizer$FinalizerWorker$FinalizerThread.run(Finalizer.java:117) ------------------------- Inconsistent thread : best efforts attempt (may fail) "Reference Handler" (TID:0x155e20, sys_thread_t:0x155d58, state:CW, thread_t: t@6, threadID:0xee8c0d98, stack_bottom:0xee8c0d98, stack_size:0x1fd98) prio=10 [1] java.lang.Object.wait(Object.java:417) [2] java.lang.ref.Reference$ReferenceHandler.run(Reference.java:129) ------------------------- Inconsistent thread : best efforts attempt (may fail) "Signal dispatcher" (TID:0x135278, sys_thread_t:0x1351b0, state:MW, thread_t: t@5, threadID:0xee8f0d98, stack_bottom:0xee8f0d98, stack_size:0x1fd98) prio=10 (note the lack of stack trace here) ------------------------ Inconsistent thread : best efforts attempt (may fail) "main" (TID:0x390d0, sys_thread_t:0x39008, state:R, thread_t: t@1, threadID:0x251d0, stack_bottom:0xf0000000, stack_size:0x800000) prio=5 [1] java.io.ObjectInputStream.loadClassO(Native Method) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ... after which the VM stopped responding. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Starting Web Start Launcher in Command Line Mode. signal fault in critical section signal number: 11, signal code: 1, fault address: 0xe9ff0de8, pc: 0xef40d4a8, sp: 0xee7a2c78 libthread panic: fault in libthread critical section : dumping core (PID: 327 LWP 10) stacktrace: ef40d49c ef40f134 ef408c48 0 Abort - core dumped The Webstart launcher has terminated unexpectedly. (some stuff about the machine rebooting on <enter>) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- As a side-note, seemingly at random I see the following message a lot (including during that last bit I quoted): Assertion failed: MUTEX_HELD(&svc_thr_mutex), file ../rpc/svc_run.c, line 757 3) Boot in single-user mode -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Starting Web Start Launcher in Command Line Mode. signal fault in critical section signal number: 11, signal code: 1, fault address: 0xee82005c, pc: 0xef7c7248, sp: 0xee73e198 libthread panic: fault in libthread critical section : dumping core (PID: 330 LWP 9) stacktrace: (...) Segmentation Fault - core dumped (terminated unexpectedly, yada yada) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ... where (...) is a huge stack trace. I have to copy this by hand ... ya, I really hope you don't need that. Lemme know if you do, though. I was able to get the exact same error & stack trace as the sig11 one from (2) above. Addresses were the same, only diferences were the PID, LWP, and sp (330, 9, 0xee752c78) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Starting Web Start Launcher in Command Line Mode. Fri May 27 15:29:19 2011 fatal: mounting of "/vol" failed signal fault in critical section signal number: 11, signal code: 1, fault address: 0xee780de8, pc: 0xef40d4a8, sp: 0xeb1b2c78 libthread panic: fault in libthread critical section : dumping core (PID: 330 LWP 12) stacktrace: ef40d49c ef40f134 ef408c48 0 Abort - core dumped (blahdy blah) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- For reference, I'm using a 3g qcow2 image. I originally formatted it as a "SUN2.9G" in the format utility, but I let it autoconfigure the partitions. partition '0' is root (1.18G), '1' is swap (149m), '2' is backup (2.71g), and '7' is home (1.39g). There's overlap in the cylinder ranges specified and the total size between those partitions is larger than 3g ... but, I have no idea whether that's just a Sun-ism, or whether I need to partition manually. I don't think it's my partitions, though. The 'vol' directory doesn't exist in my root before I try to get the webstart stuff to run, so I think it's creating that directory and trying to mount an image to it. Additionally, I'm starting qemu with: ./qemu_system_sparc -nographic -bios /imgpath/openbios-sparc32_artyom.bin -hda /imgpath/solaris2.8-img3.qcow2 -m 256 -net nic -net user -cdrom /imgpath/solaris2.8/software_1of2.iso prom-env 'auto-boot?=false' -snapshot If anyone has a good idea, I'm all ears ... (or is it eyes?) -Brian

3 4

Getting Closer With Booting AIX? I Would Like to Help Please.
by Kenneth Salerno 27 May '11

27 May '11

Hello, I would like to help debug booting AIX with qemu-system-ppc. Here is what I have so far, please let me know what further information I should provide to aid in pinpointing where the following hang occurs: ==================================================== Booting AIX in QEMU+OpenBIOS (CPU type PowerPC,750) ==================================================== ------------------------------------------------------------------------------- Welcome to AIX. boot image timestamp: 00:39 35/2D The current time and date: 01:10:58 04/25/2011 processor count: 1; memory size: 2047MB; kernel size: 2293829 boot device: cd:\ppc\chrp\bootfile.exe [hangs here...] ============ Environment ============ OpenBIOS: SVN snapshot as of 2011-04-25 QEMU: Git snapshot as of 2011-04-25 Host OS: GNU/Linux x86_64 Guest OS: AIX V6.1 Cross-Compiler: powerpc-unknown-linux-gnu-gcc (GCC) 4.6.0 ================= OpenBIOS config =================  <option name="CONFIG_DEBUG" type="boolean" value="true"/> <option name="CONFIG_DEBUG_BOOT" type="boolean" value="false"/> <option name="CONFIG_DEBUG_DSTACK" type="boolean" value="false"/> <option name="CONFIG_DEBUG_RSTACK" type="boolean" value="false"/> <option name="CONFIG_DEBUG_DICTIONARY" type="boolean" value="false"/> <option name="CONFIG_DEBUG_INTERNAL" type="boolean" value="false"/> <option name="CONFIG_DEBUG_INTERPRETER" type="boolean" value="false"/> <option name="CONFIG_DEBUG_CONSOLE" type="boolean" value="true"/> <option name="CONFIG_DEBUG_CONSOLE_SERIAL" type="boolean" value="true"/> <option name="CONFIG_SERIAL_PORT" type="integer" value="0"/> <option name="CONFIG_SERIAL_SPEED" type="integer" value="115200"/> <option name="CONFIG_DEBUG_CONSOLE_VGA" type="boolean" value="true"/> <option name="CONFIG_DEBUG_OFMEM" type="boolean" value="false"/>  <option name="CONFIG_CMDLINE" type="boolean" value="true"/> <option name="CONFIG_DEBLOCKER" type="boolean" value="true"/> <option name="CONFIG_FONT_8X8" type="boolean" value="true"/> <option name="CONFIG_FONT_8X16" type="boolean" value="false"/> <option name="CONFIG_OFMEM" type="boolean" value="true"/> <option name="CONFIG_OFMEM_MALLOC_ALIGN" type="integer" value="4"/> <option name="CONFIG_VGA_WIDTH" type="integer" value="800"/> <option name="CONFIG_VGA_HEIGHT" type="integer" value="600"/> <option name="CONFIG_VGA_DEPTH" type="integer" value="8"/> <option name="CONFIG_LOADER_AOUT" type="boolean" value="false"/> <option name="CONFIG_LOADER_BOOTINFO" type="boolean" value="true"/> <option name="CONFIG_LOADER_ELF" type="boolean" value="true"/> <option name="CONFIG_LOADER_FCODE" type="boolean" value="false"/> <option name="CONFIG_LOADER_FORTH" type="boolean" value="false"/> <option name="CONFIG_LOADER_XCOFF" type="boolean" value="true"/>  <option name="CONFIG_DISK_LABEL" type="boolean" value="true"/> <option name="CONFIG_PART_SUPPORT" type="boolean" value="true"/> <option name="CONFIG_MAC_PARTS" type="boolean" value="true"/> <option name="CONFIG_DEBUG_MAC_PARTS" type="boolean" value="false"/> <option name="CONFIG_PC_PARTS" type="boolean" value="true"/> <option name="CONFIG_HFS" type="boolean" value="true"/> <option name="CONFIG_HFSP" type="boolean" value="true"/> <option name="CONFIG_ISO9660" type="boolean" value="true"/> <option name="CONFIG_EXT2" type="boolean" value="true"/> <option name="CONFIG_GRUBFS" type="boolean" value="true"/> <option name="CONFIG_FSYS_EXT2FS" type="boolean" value="false"/> <option name="CONFIG_FSYS_FAT" type="boolean" value="false"/> <option name="CONFIG_FSYS_JFS" type="boolean" value="true"/> <option name="CONFIG_FSYS_MINIX" type="boolean" value="false"/> <option name="CONFIG_FSYS_REISERFS" type="boolean" value="false"/> <option name="CONFIG_FSYS_XFS" type="boolean" value="false"/> <option name="CONFIG_FSYS_UFS" type="boolean" value="false"/> <option name="CONFIG_FSYS_ISO9660" type="boolean" value="false"/> <option name="CONFIG_FSYS_FFS" type="boolean" value="false"/> <option name="CONFIG_FSYS_VSTAFS" type="boolean" value="false"/> <option name="CONFIG_FSYS_NTFS" type="boolean" value="false"/> <option name="CONFIG_FSYS_AFFS" type="boolean" value="false"/> <option name="CONFIG_DEBUG_FS" type="boolean" value="false"/>  <option name="CONFIG_PPC_64BITSUPPORT" type="boolean" value="true"/> <option name="CONFIG_LINUXBIOS" type="boolean" value="false"/> <option name="CONFIG_RTAS" type="boolean" value="true"/>  <option name="CONFIG_DRIVER_PCI" type="boolean" value="true"/> <option name="CONFIG_DEBUG_PCI" type="boolean" value="false"/> <option name="CONFIG_DRIVER_IDE" type="boolean" value="true"/> <option name="CONFIG_IDE_NUM_CHANNELS" type="integer" value="2"/> <option name="CONFIG_IDE_FIRST_UNIT" type="integer" value="1"/> <option name="CONFIG_IDE_DEV_NAME" type="string" value="ata-%d"/> <option name="CONFIG_IDE_DEV_TYPE" type="string" value="ata"/> <option name="CONFIG_DEBUG_IDE" type="boolean" value="false"/> <option name="CONFIG_DRIVER_ADB" type="boolean" value="true"/> <option name="CONFIG_DRIVER_VGA" type="boolean" value="true"/> <option name="CONFIG_DRIVER_MACIO" type="boolean" value="true"/> <option name="CONFIG_DRIVER_ESCC" type="boolean" value="true"/> <option name="CONFIG_DRIVER_FW_CFG" type="boolean" value="true"/> <option name="CONFIG_FW_CFG_ADDR" type="integer" value="0xf0000510"/> =========================================== OpenBIOS debug (built with CONFIG_DEBUG_*) =========================================== >> >R: 7fb5bc80 >> >R: 7fb5bc24 >> >R: 7fb5bba0 >> >R: 7fb5bbd8 >> IDE - ob_ide_read_blocks: ob_ide_read_blocks 7fb9f0a8 block=0 n=1 >> IDE - ob_ide_read_sectors: ob_ide_read_sectors: block=0 sectors=1 >> IDE - ob_ide_atapi_drive_ready: ob_ide_atapi_drive_ready >> R>: 7fb5bbd8 >> R>: 7fb5bba0 >> R>: 7fb5bc24 >> R>: 7fb5bc80 >> R>: 0 >> R>: 14 >> R>: 4 >> R>: 0 >> >R: fff5648c >> >R: b >> R>: b >> R>: fff5648c >> >R: fff5646c >> >R: 9 >> R>: 9 >> R>: fff5646c >> >R: fff56344 >> >R: c >> R>: c >> R>: fff56344 >> >R: fff56324 >> >R: 7 >> R>: 7 >> R>: fff56324 >> >R: fff4fd44 >> >R: b >> R>: b >> R>: fff4fd44 >> >R: fff4fd14 >> >R: 4 >> R>: 4 >> R>: fff4fd14 >> >R: fff4fcd4 >> >R: 9 >> R>: 9 >> R>: fff4fcd4 >> >R: fff4fca8 >> >R: c >> R>: c >> R>: fff4fca8 >> >R: fff4fc1c >> >R: 9 >> R>: 9 >> R>: fff4fc1c >> >R: fff4fbf0 >> >R: 5 >> R>: 5 >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> R>: fff3df68 >> R>: 1 >> R>: 5 >> >R: fff3df68 >> R>: fff4fbf0 >> >R: fff4fbc8 >> >R: 5 >> R>: 5 >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> R>: fff3df68 >> R>: 0 >> R>: 5 >> >R: fff3df68 >> R>: fff4fbc8 >> >R: fff4fba4 >> >R: 4 >> R>: 4 >> R>: fff4fba4 >> >R: fff4fb50 >> >R: 7 >> R>: 7 >> R>: fff4fb50 >> >R: fff4faf4 >> >R: 5 >> R>: 5 >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> R>: fff3df68 >> R>: 2 >> R>: 5 >> >R: fff3df68 >> R>: fff4faf4 >> >R: fff4faa4 >> >R: 4 >> R>: 4 >> R>: fff4faa4 >> >R: fff4fa44 >> >R: 5 >> R>: 5 >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> R>: fff3df68 >> R>: 0 >> R>: 5 >> >R: fff3df68 >> R>: fff4fa44 >> >R: fff4f9e8 >> >R: 4 >> R>: 4 >> R>: fff4f9e8 >> >R: fff4f9d0 >> >R: 5 >> R>: 5 >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> R>: fff4f9d0 >> >R: 0 >> >R: 2 >> >R: 14 >> R>: fff440e4 >> >R: fff440f0 >> >R: 0 >> >R: 6 >> >R: 28 >> >R: 7fb5bc80 >> >R: fff52d18 >> >R: 5 >> R>: 5 >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> R>: fff52d18 >> R>: 7fb5bc80 >> >R: 0 >> R>: 0 >> R>: 28 >> R>: 6 >> R>: 0 >> >R: 7fb980ac >> R>: 7fb980ac >> >R: 0 >> R>: 0 >> R>: fff3d44c >> R>: fff440e4 >> >R: fff440f0 >> >R: 0 >> >R: 6 >> >R: 28 >> >R: 7fb5bc24 >> >R: fff51cb0 >> >R: 3 >> R>: 3 >> R>: fff51cb0 >> >R: fff51c84 >> >R: 4 >> R>: 4 >> R>: fff51c84 >> >R: fff51c58 >> >R: 4 >> R>: 4 >> R>: fff51c58 >> >R: fff51c2c >> >R: 5 >> R>: 5 >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> R>: fff3df68 >> R>: 0 >> R>: 5 >> >R: fff3df68 >> R>: fff51c2c >> >R: fff51c00 >> >R: 4 >> R>: 4 >> R>: fff51c00 >> >R: fff51bd4 >> >R: 4 >> R>: 4 >> R>: fff51bd4 >> >R: fff51ba8 >> >R: 5 >> R>: 5 >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> R>: fff51ba8 >> R>: 7fb5bc24 >> >R: 0 >> R>: 0 >> R>: 28 >> R>: 6 >> R>: 0 >> >R: 7fb980ac >> R>: 7fb980ac >> >R: 0 >> R>: 0 >> R>: fff3d614 >> R>: fff3d44c >> R>: fff440e4 >> >R: fff440f0 >> >R: 0 >> >R: 6 >> >R: 28 >> >R: 7fb5bba0 >> >R: fff54120 >> >R: c >> R>: c >> R>: fff54120 >> >R: fff540ec >> >R: a >> R>: a >> R>: fff540ec >> >R: fff540bc >> >R: b >> R>: b >> R>: fff540bc >> >R: fff54088 >> >R: 5 >> R>: 5 >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> R>: fff54088 >> R>: 7fb5bba0 >> >R: 0 >> R>: fff440e4 >> >R: fff440f0 >> >R: 7fb5bba0 >> >R: 7 >> >R: 30 >> >R: 7fb5bbd8 >> >R: fff51b10 >> >R: 4 >> R>: 4 >> R>: fff51b10 >> >R: fff51ae4 >> >R: 4 >> R>: 4 >> R>: fff51ae4 >> >R: fff51ab8 >> >R: 5 >> R>: 5 >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> R>: fff3df68 >> R>: 0 >> R>: 5 >> >R: fff3df68 >> R>: fff51ab8 >> >R: fff51a8c >> >R: 4 >> R>: 4 >> R>: fff51a8c >> >R: fff51a60 >> >R: 5 >> R>: 5 >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> >R: 7b >> R>: 7b >> R>: fff51a60 >> R>: 7fb5bbd8 >> >R: 7fb5bba0 ====================== QEMU debug ====================== (qemu) info registers info registers NIP fff1086c LR fff10844 CTR fff122bc XER 00000000 MSR 00003032 HID0 00000000 HF 00002000 idx 1 TB 00000000 3720793498 DECR 574173816 GPR00 000000007fb9f0a0 000000007fcf7790 0000000000000000 000000007fba29b4 GPR04 000000000000000d 0000000000000000 0000000000000000 0000000000000000 GPR08 0000000000000000 000000007fba29b4 000000000000000c 0000000000000820 GPR12 0000000000000000 0000000000000000 00000000fff393aa 00000000fff3a137 GPR16 00000000fff3741e 0000000004000000 00000000fffbc6cc 00000000fffbcecc GPR20 00000000000030ec 00000000fff37204 00000000fff371f2 00000000fff37172 GPR24 00000000fff371fa 00000000fffbc630 0000000000000001 00000000000444a0 GPR28 0000000000000036 00000000fffc0000 00000000fffc0000 000000007fb9f0a8 CR 48000084 [ G L - - - - L G ] RES ffffffff FPR00 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPSCR 00000000 SRR0 fff2bdcc SRR1 00003032 SDR1 7fd00000 (qemu) info cpus info cpus * CPU #0: nip=0xfff1086c thread_id=7838 (qemu) x/20i $pc-4 x/20i $pc-4 0xfff10710: beq- cr7,0xfff10724 0xfff10714: lwz r10,4(r9) 0xfff10718: lwz r11,-4(r31) 0xfff1071c: cmplw cr7,r10,r11 0xfff10720: blt+ cr7,0xfff10704 0xfff10724: stw r9,-8(r31) 0xfff10728: stw r0,0(r3) 0xfff1072c: addi r11,r1,16 0xfff10730: b 0xfff2cb10 0xfff10734: stwu r1,-32(r1) 0xfff10738: mflr r0 0xfff1073c: stmw r29,20(r1) 0xfff10740: mr. r30,r3 0xfff10744: mr r29,r4 0xfff10748: stw r0,36(r1) 0xfff1074c: bne+ 0xfff10760 0xfff10750: mr r3,r4 0xfff10754: bl 0xfff08498 0xfff10758: mr r31,r3 0xfff1075c: b 0xfff107ac IN: deblk_close 0xfff122bc: stwu r1,-16(r1) 0xfff122c0: mflr r0 0xfff122c4: stw r0,20(r1) 0xfff122c8: lwz r3,24(r3) 0xfff122cc: bl 0xfff084b8 OP: ---- 0xfff122bc movi_i32 access_type,$0x20 movi_i32 tmp1,$0xfffffff0 add_i32 tmp0,r1,tmp1 qemu_st32 r1,tmp0,$0x1 mov_i32 r1,tmp0 ---- 0xfff122c0 mov_i32 r0,lr ---- 0xfff122c4 movi_i32 tmp1,$0x14 add_i32 tmp0,r1,tmp1 qemu_st32 r0,tmp0,$0x1 ---- 0xfff122c8 movi_i32 tmp1,$0x18 add_i32 tmp0,r3,tmp1 qemu_ld32 r3,tmp0,$0x1 ---- 0xfff122cc movi_i32 lr,$0xfff122d0 movi_i32 nip,$0xfff084b8 exit_tb $0x0 OP after liveness analysis: ---- 0xfff122bc movi_i32 access_type,$0x20 movi_i32 tmp1,$0xfffffff0 add_i32 tmp0,r1,tmp1 qemu_st32 r1,tmp0,$0x1 mov_i32 r1,tmp0 ---- 0xfff122c0 mov_i32 r0,lr ---- 0xfff122c4 movi_i32 tmp1,$0x14 add_i32 tmp0,r1,tmp1 qemu_st32 r0,tmp0,$0x1 ---- 0xfff122c8 movi_i32 tmp1,$0x18 add_i32 tmp0,r3,tmp1 qemu_ld32 r3,tmp0,$0x1 ---- 0xfff122cc movi_i32 lr,$0xfff122d0 movi_i32 nip,$0xfff084b8 exit_tb $0x0 end OUT: [size=252] 0x400eb320: mov 0x4(%r14),%ebp 0x400eb324: lea -0x10(%rbp),%ebx 0x400eb327: mov $0x20,%r12d 0x400eb32d: mov %r12d,0x260(%r14) 0x400eb334: mov %ebx,%esi 0x400eb336: mov %ebx,%edi 0x400eb338: shr $0x7,%esi 0x400eb33b: and $0xfffff003,%edi 0x400eb341: and $0x1fe0,%esi 0x400eb347: lea 0x228c(%r14,%rsi,1),%rsi 0x400eb34f: cmp (%rsi),%edi 0x400eb351: mov %ebx,%edi 0x400eb353: jne 0x400eb361 0x400eb355: add 0xc(%rsi),%rdi 0x400eb359: mov %ebp,%esi 0x400eb35b: bswap %esi 0x400eb35d: mov %esi,(%rdi) 0x400eb35f: jmp 0x400eb36d 0x400eb361: mov %ebp,%esi 0x400eb363: mov $0x1,%edx 0x400eb368: callq 0x57ffa9 0x400eb36d: mov 0x100(%r14),%ebp 0x400eb374: lea 0x14(%rbx),%r12d 0x400eb378: mov %ebp,(%r14) 0x400eb37b: mov %ebx,0x4(%r14) 0x400eb37f: mov %r12d,%esi 0x400eb382: mov %r12d,%edi 0x400eb385: shr $0x7,%esi 0x400eb388: and $0xfffff003,%edi 0x400eb38e: and $0x1fe0,%esi 0x400eb394: lea 0x228c(%r14,%rsi,1),%rsi 0x400eb39c: cmp (%rsi),%edi 0x400eb39e: mov %r12d,%edi 0x400eb3a1: jne 0x400eb3af 0x400eb3a3: add 0xc(%rsi),%rdi 0x400eb3a7: mov %ebp,%esi 0x400eb3a9: bswap %esi 0x400eb3ab: mov %esi,(%rdi) 0x400eb3ad: jmp 0x400eb3bb 0x400eb3af: mov %ebp,%esi 0x400eb3b1: mov $0x1,%edx 0x400eb3b6: callq 0x57ffa9 0x400eb3bb: mov 0xc(%r14),%ebp 0x400eb3bf: lea 0x18(%rbp),%ebx 0x400eb3c2: mov %ebx,%esi 0x400eb3c4: mov %ebx,%edi 0x400eb3c6: shr $0x7,%esi 0x400eb3c9: and $0xfffff003,%edi 0x400eb3cf: and $0x1fe0,%esi 0x400eb3d5: lea 0x2288(%r14,%rsi,1),%rsi 0x400eb3dd: cmp (%rsi),%edi 0x400eb3df: mov %ebx,%edi 0x400eb3e1: jne 0x400eb3ed 0x400eb3e3: add 0x10(%rsi),%rdi 0x400eb3e7: mov (%rdi),%ebp 0x400eb3e9: bswap %ebp 0x400eb3eb: jmp 0x400eb3f9 0x400eb3ed: mov $0x1,%esi 0x400eb3f2: callq 0x57fb92 0x400eb3f7: mov %eax,%ebp 0x400eb3f9: mov %ebp,0xc(%r14) 0x400eb3fd: mov $0xfff084b8,%ebp 0x400eb402: mov %ebp,0x25c(%r14) 0x400eb409: mov $0xfff122d0,%ebp 0x400eb40e: mov %ebp,0x100(%r14) 0x400eb415: xor %eax,%eax 0x400eb417: jmpq 0x11c2bce ============================================= gdb: qemu vl.c ============================================= 1946 const char *gdbstub_dev = NULL; 1947 int i; 1948 int snapshot, linux_boot; 1949 const char *icount_option = NULL; 1950 const char *initrd_filename; 1951 const char *kernel_filename, *kernel_cmdline; 1952 char boot_devices[33] = "cad"; /* default to HD->floppy->CD-ROM */ 1953 DisplayState *ds; 1954 DisplayChangeListener *dcl; 1955 int cyls, heads, secs, translation; 1956 QemuOpts *hda_opts = NULL, *opts; 1957 QemuOptsList *olist; 1958 int optind; 1959 const char *optarg; 1960 const char *loadvm = NULL; 1961 QEMUMachine *machine; 1962 const char *cpu_model; 1963 int tb_size; 1964 const char *pid_file = NULL; 1965 const char *incoming = NULL; Thank you! Ken

5 15

Re: [OpenBIOS] Solaris anyone?
by Nick Couchman 24 May '11

24 May '11

> > Nick - do you think you could do a quick test on this one? > This patch for the scsi_options seems to work fine - system boots with the patch applied and with the line removed from /etc/system. -Nick -------- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.

9 26

[commit] r1041 - trunk/openbios-devel/arch/ppc/qemu
by repository service 23 May '11

23 May '11

Author: afaerber Date: Mon May 23 00:29:33 2011 New Revision: 1041 URL: http://tracker.coreboot.org/trac/openbios/changeset/1041 Log: ppc64: Don't set Kp bit on SLB Since QEMU 81762d6dd0d430d87024f2c83e9c4dcc4329fb7d (Clean up PowerPC SLB handling code) we never got to the ppc64 OpenBIOS banner. According to Alex' debugging this is due to the Kp bit being set. The code was supposed to be a 1:1 translation of the old mtsrin code, which did not set Kp bit. So don't set Kp bit with slbmte. Introduce a define for the shift, suggested by Alex. Signed-off-by: Andreas Färber <andreas.faerber(a)web.de> Acked-by: Alexander Graf <agraf(a)suse.de> Modified: trunk/openbios-devel/arch/ppc/qemu/ofmem.c Modified: trunk/openbios-devel/arch/ppc/qemu/ofmem.c ============================================================================== --- trunk/openbios-devel/arch/ppc/qemu/ofmem.c Sun May 22 18:39:48 2011 (r1040) +++ trunk/openbios-devel/arch/ppc/qemu/ofmem.c Mon May 23 00:29:33 2011 (r1041) @@ -25,6 +25,8 @@ #define BIT(n) (1U << (31 - (n))) +#define SLB_VSID_SHIFT 12 + /* called from assembly */ extern void dsi_exception(void); extern void isi_exception(void); @@ -497,7 +499,7 @@ slbia(); /* Invalidate all SLBs except SLB 0 */ for (i = 0; i < 16; i++) { - unsigned long rs = ((0x400 + i) << 12) | (0x10 << 7); + unsigned long rs = (0x400 + i) << SLB_VSID_SHIFT; unsigned long rb = ((unsigned long)i << 28) | (1 << 27) | i; slbmte(rs, rb); }

1 0

[PATCH] ppc64: Don't set Kp bit on SLB
by Andreas Färber 22 May '11

22 May '11

Since QEMU 81762d6dd0d430d87024f2c83e9c4dcc4329fb7d (Clean up PowerPC SLB handling code) we never got to the ppc64 OpenBIOS banner. According to Alex' debugging this is due to the Kp bit being set. The code was supposed to be a 1:1 translation of the old mtsrin code, which did not set Kp bit. So don't set Kp bit with slbmte. Cc: Alexander Graf <agraf(a)suse.de> Cc: David Gibson <david(a)gibson.dropbear.id.au> Signed-off-by: Andreas Färber <andreas.faerber(a)web.de> --- arch/ppc/qemu/ofmem.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/ppc/qemu/ofmem.c b/arch/ppc/qemu/ofmem.c index 297e685..514d129 100644 --- a/arch/ppc/qemu/ofmem.c +++ b/arch/ppc/qemu/ofmem.c @@ -497,7 +497,7 @@ setup_mmu(unsigned long ramsize) slbia(); /* Invalidate all SLBs except SLB 0 */ for (i = 0; i < 16; i++) { - unsigned long rs = ((0x400 + i) << 12) | (0x10 << 7); + unsigned long rs = ((0x400 + i) << 12) | (0x0 << 7); unsigned long rb = ((unsigned long)i << 28) | (1 << 27) | i; slbmte(rs, rb); } -- 1.7.3.4

2 3

[commit] r1040 - trunk/openbios-devel/config/scripts
by repository service 22 May '11

22 May '11

Author: blueswirl Date: Sun May 22 18:39:48 2011 New Revision: 1040 URL: http://tracker.coreboot.org/trac/openbios/changeset/1040 Log: switch-arch: remove non-standard "local" keyword Remove the non-standard "local" keyword from within the crosscflags() function. This was not necessary since the variables "host" and "target" were not clobbered anywhere outside of the function, but the real motivation is to support shells such as ksh93 that do not have the "local" builtin like bash. Signed-off-by: Kenneth Salerno <kennethsalerno(a)yahoo.com> Signed-off-by: Blue Swirl <blauwirbel(a)gmail.com> Modified: trunk/openbios-devel/config/scripts/switch-arch Modified: trunk/openbios-devel/config/scripts/switch-arch ============================================================================== --- trunk/openbios-devel/config/scripts/switch-arch Sun May 8 17:36:59 2011 (r1039) +++ trunk/openbios-devel/config/scripts/switch-arch Sun May 22 18:39:48 2011 (r1040) @@ -19,8 +19,8 @@ crosscflags() { - local host=$1 - local target=$2 + host=$1 + target=$2 if test "$host" = "powerpc" -o "$host" = "ppc" \ -o "$host" = "mips" -o "$host" = "s390" \

1 0

Re: [OpenBIOS] [Qemu-devel] [PATCH 01/27] Clean up PowerPC SLB handling code
by Andreas Färber 20 May '11

20 May '11

QEMU HEAD still uses a 32-bit binary for both 32-bit and 64-bit. That one uses mtsrin so will need the compatibility, it seemed affected, too. OpenBIOS SVN HEAD (blob) uses slb* as linked to. We're in the preparation of 1.1 and I need to test it before we can update the QEMU binary. ;) Sorry for top-posting, Android sucks. Andreas David Gibson <david(a)gibson.dropbear.id.au> schrieb: >On Thu, May 19, 2011 at 08:00:53AM +0200, Andreas Färber wrote: >> Am 19.05.2011 um 07:39 schrieb David Gibson: >> >> >On Thu, May 19, 2011 at 07:35:30AM +0200, Andreas Färber wrote: >> >>Am 25.03.2011 um 04:21 schrieb David Gibson: >> >> >> >>>Currently the SLB information when emulating a PowerPC 970 is >> >>>storeed in a structure with the unhelpfully named fields 'tmp' >> >>>and 'tmp64'. While the layout in these fields does match the >> >>>description of the SLB in the architecture document, it is not >> >>>convenient either for looking up the SLB, or for emulating the >> >>>slbmte instruction. >> >>> >> >>>This patch, therefore, reorganizes the SLB entry structure to be >> >>>divided in the the "ESID related" and "VSID related" fields as >> >>>they are divided in instructions accessing the SLB. >> >>> >> >>>In addition to making the code smaller and more readable, this will >> >>>make it easier to implement for the 1TB segments used in more >> >>>recent PowerPC chips. >> >>> >> >>>Signed-off-by: David Gibson <dwg(a)au1.ibm.com> >> >> >> >>According to my bisect, this patch broke ppc64 OpenBIOS. >> >> >> >>David, would you please take a look? >> > >> >Uh, sure. can you describe the symptoms of the breakage, and the >> >exact qemu setup you've observed the problem with? >> >> $ uname -a >> Darwin PMG5-3.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 >> 16:57:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_PPC Power Macintosh >> # Mac OS X 10.5.8 on dual-core G5 >> >> $ gcc-4.2 --version >> powerpc-apple-darwin9-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5577) >> Copyright (C) 2007 Free Software Foundation, Inc. >> This is free software; see the source for copying conditions. There >> is NO >> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR >> PURPOSE. >> >> ../qemu/configure --prefix=/Users/andreas/QEMU/latest64 \ >> --target-list=ppc-softmmu,ppc64-softmmu \ >> --extra-cflags="-arch ppc64" --extra-ldflags="-arch ppc64" --cc=gcc-4.2 >> --host-cc=gcc-4.2 \ >> --enable-cocoa --disable-kvm --disable-strip --disable-docs >> --enable-io-thread $* >> # I/O thread doesn't matter >> >> /Users/andreas/QEMU/qemu64/ppc64-softmmu/qemu-system-ppc64 -boot d -cdrom >> /Users/andreas/QEMU/AIX/dvd.1022A4_OBETA_710.iso \ >> -bios /Users/andreas/QEMU/OpenBIOS/openbios/obj-ppc64/openbios-qemu.elf >> -m 1024 \ >> -M mac99 -prom-env 'auto-boot?=false' -nographic >> >> CD should be irrelevant, -boot c -hda /dev/null should work the same. > >Um, yeah, I thought putting an AIX dvd into a Mac was a bit odd. > >> Expected: OpenBIOS banner and > prompt >> Observed: DSI exception on mtmsrd, no serial output > >Does this happen only with your openbios image, or does it also happen >with the one included in qemu? > >My working theory is that openbios is using the old 32-64 bridge stuff >where segment register accesses are emulated to populate certain SLB >slots. I have a vague recollection that I saw the code implementing >that when I was doing the cleanup and convinced myself it was not >necessary. More information as I investigate further. > >> (The regression on ppc32 AIX observed by Kenneth seems to be a >> different issue, introduced earlier.) > >I don't know what that regression is; I don't read qemu-devel >exhaustively. If you want my attention, best to CC me directly. > >-- >David Gibson | I'll have my music baroque, and my code >david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ > | _way_ _around_! >http://www.ozlabs.org/~dgibson

3 2

Re: [OpenBIOS] [Qemu-devel] [PATCH 01/27] Clean up PowerPC SLB handling code
by Andreas Färber 19 May '11

19 May '11

Am 25.03.2011 um 04:21 schrieb David Gibson: > Currently the SLB information when emulating a PowerPC 970 is > storeed in a structure with the unhelpfully named fields 'tmp' > and 'tmp64'. While the layout in these fields does match the > description of the SLB in the architecture document, it is not > convenient either for looking up the SLB, or for emulating the > slbmte instruction. > > This patch, therefore, reorganizes the SLB entry structure to be > divided in the the "ESID related" and "VSID related" fields as > they are divided in instructions accessing the SLB. > > In addition to making the code smaller and more readable, this will > make it easier to implement for the 1TB segments used in more > recent PowerPC chips. > > Signed-off-by: David Gibson <dwg(a)au1.ibm.com> According to my bisect, this patch broke ppc64 OpenBIOS. David, would you please take a look? Thanks, Andreas ## bad: 3964f535c35c08470ac69bd553282af500bc8bb0 Merge remote-tracking branch 'mst/for_anthony' into staging ## bad: 8500e3a91292f253002783da267f3b08aead86c1 Clean up slb_lookup() function # good: [a0843a68c4e79df801342ec37347dfebc591082e] vnc: fix build error from VNC_DIRTY_WORDS git bisect good a0843a68c4e79df801342ec37347dfebc591082e # good: [5256d8bfad9b0113dc2f9b57706eaad26b008987] pci: use devfn for pci_find_device() instead of (slot, fn) pair git bisect good 5256d8bfad9b0113dc2f9b57706eaad26b008987 # good: [fcda98630b121a63c9de0705df02e59f4dc2fecc] lm32: rename raise opcode to scall git bisect good fcda98630b121a63c9de0705df02e59f4dc2fecc # bad: [d569956eaff4be808419f1f259a5c388d8789db4] Add a hook to allow hypercalls to be emulated on PowerPC git bisect bad d569956eaff4be808419f1f259a5c388d8789db4 # good: [17d9b3af5b7f93e43d7fbdcb6f14cad54de9f1ae] target-ppc: ext32u instead of andi with constant git bisect good 17d9b3af5b7f93e43d7fbdcb6f14cad54de9f1ae # bad: [c48974903051ceb7cfbda23c22c159ea4b482d93] Allow qemu_devtree_setprop() to take arbitrary values git bisect bad c48974903051ceb7cfbda23c22c159ea4b482d93 # bad: [81762d6dd0d430d87024f2c83e9c4dcc4329fb7d] Clean up PowerPC SLB handling code git bisect bad 81762d6dd0d430d87024f2c83e9c4dcc4329fb7d > --- > target-ppc/cpu.h | 29 +++++++- > target-ppc/helper.c | 178 +++++++++++++ > +---------------------------------- > target-ppc/helper.h | 1 - > target-ppc/op_helper.c | 9 +-- > 4 files changed, 80 insertions(+), 137 deletions(-) > > diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h > index deb8d7c..124bbbf 100644 > --- a/target-ppc/cpu.h > +++ b/target-ppc/cpu.h > @@ -43,6 +43,8 @@ > # define TARGET_VIRT_ADDR_SPACE_BITS 64 > #endif > > +#define TARGET_PAGE_BITS_16M 24 > + > #else /* defined (TARGET_PPC64) */ > /* PowerPC 32 definitions */ > #define TARGET_LONG_BITS 32 > @@ -359,10 +361,31 @@ union ppc_tlb_t { > > typedef struct ppc_slb_t ppc_slb_t; > struct ppc_slb_t { > - uint64_t tmp64; > - uint32_t tmp; > + uint64_t esid; > + uint64_t vsid; > }; > > +/* Bits in the SLB ESID word */ > +#define SLB_ESID_ESID 0xFFFFFFFFF0000000ULL > +#define SLB_ESID_V 0x0000000008000000ULL /* valid */ > + > +/* Bits in the SLB VSID word */ > +#define SLB_VSID_SHIFT 12 > +#define SLB_VSID_SSIZE_SHIFT 62 > +#define SLB_VSID_B 0xc000000000000000ULL > +#define SLB_VSID_B_256M 0x0000000000000000ULL > +#define SLB_VSID_VSID 0x3FFFFFFFFFFFF000ULL > +#define SLB_VSID_KS 0x0000000000000800ULL > +#define SLB_VSID_KP 0x0000000000000400ULL > +#define SLB_VSID_N 0x0000000000000200ULL /* no-execute > */ > +#define SLB_VSID_L 0x0000000000000100ULL > +#define SLB_VSID_C 0x0000000000000080ULL /* class */ > +#define SLB_VSID_LP 0x0000000000000030ULL > +#define SLB_VSID_ATTR 0x0000000000000FFFULL > + > +#define SEGMENT_SHIFT_256M 28 > +#define SEGMENT_MASK_256M (~((1ULL << SEGMENT_SHIFT_256M) - 1)) > + > / > *****************************************************************************/ > /* Machine state register bits > definition */ > #define MSR_SF 63 /* Sixty-four-bit > mode hflags */ > @@ -755,7 +778,7 @@ void ppc_store_sdr1 (CPUPPCState *env, > target_ulong value); > void ppc_store_asr (CPUPPCState *env, target_ulong value); > target_ulong ppc_load_slb (CPUPPCState *env, int slb_nr); > target_ulong ppc_load_sr (CPUPPCState *env, int sr_nr); > -void ppc_store_slb (CPUPPCState *env, target_ulong rb, target_ulong > rs); > +int ppc_store_slb (CPUPPCState *env, target_ulong rb, target_ulong > rs); > #endif /* defined(TARGET_PPC64) */ > void ppc_store_sr (CPUPPCState *env, int srnum, target_ulong value); > #endif /* !defined(CONFIG_USER_ONLY) */ > diff --git a/target-ppc/helper.c b/target-ppc/helper.c > index 4b49101..2094ca3 100644 > --- a/target-ppc/helper.c > +++ b/target-ppc/helper.c > @@ -672,85 +672,36 @@ static inline int find_pte(CPUState *env, > mmu_ctx_t *ctx, int h, int rw, > } > > #if defined(TARGET_PPC64) > -static ppc_slb_t *slb_get_entry(CPUPPCState *env, int nr) > -{ > - ppc_slb_t *retval = &env->slb[nr]; > - > -#if 0 // XXX implement bridge mode? > - if (env->spr[SPR_ASR] & 1) { > - target_phys_addr_t sr_base; > - > - sr_base = env->spr[SPR_ASR] & 0xfffffffffffff000; > - sr_base += (12 * nr); > - > - retval->tmp64 = ldq_phys(sr_base); > - retval->tmp = ldl_phys(sr_base + 8); > - } > -#endif > - > - return retval; > -} > - > -static void slb_set_entry(CPUPPCState *env, int nr, ppc_slb_t *slb) > -{ > - ppc_slb_t *entry = &env->slb[nr]; > - > - if (slb == entry) > - return; > - > - entry->tmp64 = slb->tmp64; > - entry->tmp = slb->tmp; > -} > - > -static inline int slb_is_valid(ppc_slb_t *slb) > -{ > - return (int)(slb->tmp64 & 0x0000000008000000ULL); > -} > - > -static inline void slb_invalidate(ppc_slb_t *slb) > -{ > - slb->tmp64 &= ~0x0000000008000000ULL; > -} > - > static inline int slb_lookup(CPUPPCState *env, target_ulong eaddr, > target_ulong *vsid, target_ulong > *page_mask, > int *attr, int *target_page_bits) > { > - target_ulong mask; > - int n, ret; > + uint64_t esid; > + int n; > > - ret = -5; > LOG_SLB("%s: eaddr " TARGET_FMT_lx "\n", __func__, eaddr); > - mask = 0x0000000000000000ULL; /* Avoid gcc warning */ > + > + esid = (eaddr & SEGMENT_MASK_256M) | SLB_ESID_V; > + > for (n = 0; n < env->slb_nr; n++) { > - ppc_slb_t *slb = slb_get_entry(env, n); > - > - LOG_SLB("%s: seg %d %016" PRIx64 " %08" > - PRIx32 "\n", __func__, n, slb->tmp64, slb->tmp); > - if (slb_is_valid(slb)) { > - /* SLB entry is valid */ > - mask = 0xFFFFFFFFF0000000ULL; > - if (slb->tmp & 0x8) { > - /* 16 MB PTEs */ > - if (target_page_bits) > - *target_page_bits = 24; > - } else { > - /* 4 KB PTEs */ > - if (target_page_bits) > - *target_page_bits = TARGET_PAGE_BITS; > - } > - if ((eaddr & mask) == (slb->tmp64 & mask)) { > - /* SLB match */ > - *vsid = ((slb->tmp64 << 24) | (slb->tmp >> 8)) & > 0x0003FFFFFFFFFFFFULL; > - *page_mask = ~mask; > - *attr = slb->tmp & 0xFF; > - ret = n; > - break; > + ppc_slb_t *slb = &env->slb[n]; > + > + LOG_SLB("%s: slot %d %016" PRIx64 " %016" > + PRIx64 "\n", __func__, n, slb->esid, slb->vsid); > + if (slb->esid == esid) { > + *vsid = (slb->vsid & SLB_VSID_VSID) >> SLB_VSID_SHIFT; > + *page_mask = ~SEGMENT_MASK_256M; > + *attr = slb->vsid & SLB_VSID_ATTR; > + if (target_page_bits) { > + *target_page_bits = (slb->vsid & SLB_VSID_L) > + ? TARGET_PAGE_BITS_16M > + : TARGET_PAGE_BITS; > } > + return n; > } > } > > - return ret; > + return -5; > } > > void ppc_slb_invalidate_all (CPUPPCState *env) > @@ -760,11 +711,10 @@ void ppc_slb_invalidate_all (CPUPPCState *env) > do_invalidate = 0; > /* XXX: Warning: slbia never invalidates the first segment */ > for (n = 1; n < env->slb_nr; n++) { > - ppc_slb_t *slb = slb_get_entry(env, n); > + ppc_slb_t *slb = &env->slb[n]; > > - if (slb_is_valid(slb)) { > - slb_invalidate(slb); > - slb_set_entry(env, n, slb); > + if (slb->esid & SLB_ESID_V) { > + slb->esid &= ~SLB_ESID_V; > /* XXX: given the fact that segment size is 256 MB or 1TB, > * and we still don't have a tlb_flush_mask(env, n, > mask) > * in Qemu, we just invalidate all TLBs > @@ -781,68 +731,44 @@ void ppc_slb_invalidate_one (CPUPPCState *env, > uint64_t T0) > target_ulong vsid, page_mask; > int attr; > int n; > + ppc_slb_t *slb; > > n = slb_lookup(env, T0, &vsid, &page_mask, &attr, NULL); > - if (n >= 0) { > - ppc_slb_t *slb = slb_get_entry(env, n); > - > - if (slb_is_valid(slb)) { > - slb_invalidate(slb); > - slb_set_entry(env, n, slb); > - /* XXX: given the fact that segment size is 256 MB or > 1TB, > - * and we still don't have a tlb_flush_mask(env, > n, mask) > - * in Qemu, we just invalidate all TLBs > - */ > - tlb_flush(env, 1); > - } > + if (n < 0) { > + return; > } > -} > > -target_ulong ppc_load_slb (CPUPPCState *env, int slb_nr) > -{ > - target_ulong rt; > - ppc_slb_t *slb = slb_get_entry(env, slb_nr); > + slb = &env->slb[n]; > > - if (slb_is_valid(slb)) { > - /* SLB entry is valid */ > - /* Copy SLB bits 62:88 to Rt 37:63 (VSID 23:49) */ > - rt = slb->tmp >> 8; /* 65:88 => 40:63 */ > - rt |= (slb->tmp64 & 0x7) << 24; /* 62:64 => 37:39 */ > - /* Copy SLB bits 89:92 to Rt 33:36 (KsKpNL) */ > - rt |= ((slb->tmp >> 4) & 0xF) << 27; > - } else { > - rt = 0; > - } > - LOG_SLB("%s: %016" PRIx64 " %08" PRIx32 " => %d " > - TARGET_FMT_lx "\n", __func__, slb->tmp64, slb->tmp, > slb_nr, rt); > + if (slb->esid & SLB_ESID_V) { > + slb->esid &= ~SLB_ESID_V; > > - return rt; > + /* XXX: given the fact that segment size is 256 MB or 1TB, > + * and we still don't have a tlb_flush_mask(env, n, > mask) > + * in Qemu, we just invalidate all TLBs > + */ > + tlb_flush(env, 1); > + } > } > > -void ppc_store_slb (CPUPPCState *env, target_ulong rb, target_ulong > rs) > +int ppc_store_slb (CPUPPCState *env, target_ulong rb, target_ulong > rs) > { > - ppc_slb_t *slb; > - > - uint64_t vsid; > - uint64_t esid; > - int flags, valid, slb_nr; > - > - vsid = rs >> 12; > - flags = ((rs >> 8) & 0xf); > + int slot = rb & 0xfff; > + uint64_t esid = rb & ~0xfff; > + ppc_slb_t *slb = &env->slb[slot]; > > - esid = rb >> 28; > - valid = (rb & (1 << 27)); > - slb_nr = rb & 0xfff; > + if (slot >= env->slb_nr) { > + return -1; > + } > > - slb = slb_get_entry(env, slb_nr); > - slb->tmp64 = (esid << 28) | valid | (vsid >> 24); > - slb->tmp = (vsid << 8) | (flags << 3); > + slb->esid = esid; > + slb->vsid = rs; > > LOG_SLB("%s: %d " TARGET_FMT_lx " - " TARGET_FMT_lx " => %016" > PRIx64 > - " %08" PRIx32 "\n", __func__, slb_nr, rb, rs, slb->tmp64, > - slb->tmp); > + " %016" PRIx64 "\n", __func__, slot, rb, rs, > + slb->esid, slb->vsid); > > - slb_set_entry(env, slb_nr, slb); > + return 0; > } > #endif /* defined(TARGET_PPC64) */ > > @@ -860,24 +786,22 @@ static inline int get_segment(CPUState *env, > mmu_ctx_t *ctx, > { > target_phys_addr_t sdr, hash, mask, sdr_mask, htab_mask; > target_ulong sr, vsid, vsid_mask, pgidx, page_mask; > -#if defined(TARGET_PPC64) > - int attr; > -#endif > int ds, vsid_sh, sdr_sh, pr, target_page_bits; > int ret, ret2; > > pr = msr_pr; > #if defined(TARGET_PPC64) > if (env->mmu_model & POWERPC_MMU_64) { > + int attr; > + > LOG_MMU("Check SLBs\n"); > ret = slb_lookup(env, eaddr, &vsid, &page_mask, &attr, > &target_page_bits); > if (ret < 0) > return ret; > - ctx->key = ((attr & 0x40) && (pr != 0)) || > - ((attr & 0x80) && (pr == 0)) ? 1 : 0; > + ctx->key = !!(pr ? (attr & SLB_VSID_KP) : (attr & > SLB_VSID_KS)); > ds = 0; > - ctx->nx = attr & 0x10 ? 1 : 0; > + ctx->nx = !!(attr & SLB_VSID_N); > ctx->eaddr = eaddr; > vsid_mask = 0x00003FFFFFFFFF80ULL; > vsid_sh = 7; > diff --git a/target-ppc/helper.h b/target-ppc/helper.h > index 2bf9283..d512cb0 100644 > --- a/target-ppc/helper.h > +++ b/target-ppc/helper.h > @@ -340,7 +340,6 @@ DEF_HELPER_1(74xx_tlbi, void, tl) > DEF_HELPER_FLAGS_0(tlbia, TCG_CALL_CONST, void) > DEF_HELPER_FLAGS_1(tlbie, TCG_CALL_CONST, void, tl) > #if defined(TARGET_PPC64) > -DEF_HELPER_FLAGS_1(load_slb, TCG_CALL_CONST, tl, tl) > DEF_HELPER_FLAGS_2(store_slb, TCG_CALL_CONST, void, tl, tl) > DEF_HELPER_FLAGS_0(slbia, TCG_CALL_CONST, void) > DEF_HELPER_FLAGS_1(slbie, TCG_CALL_CONST, void, tl) > diff --git a/target-ppc/op_helper.c b/target-ppc/op_helper.c > index 17e070a..bf41627 100644 > --- a/target-ppc/op_helper.c > +++ b/target-ppc/op_helper.c > @@ -3746,14 +3746,11 @@ void helper_store_sr (target_ulong sr_num, > target_ulong val) > > /* SLB management */ > #if defined(TARGET_PPC64) > -target_ulong helper_load_slb (target_ulong slb_nr) > -{ > - return ppc_load_slb(env, slb_nr); > -} > - > void helper_store_slb (target_ulong rb, target_ulong rs) > { > - ppc_store_slb(env, rb, rs); > + if (ppc_store_slb(env, rb, rs) < 0) { > + helper_raise_exception_err(POWERPC_EXCP_PROGRAM, > POWERPC_EXCP_INVAL); > + } > } > > void helper_slbia (void) > -- > 1.7.1 > >

2 3

Re: [OpenBIOS] Solaris anyone?
by Nick Couchman 13 May '11

13 May '11

On Fri, 2011-05-13 at 23:57 +0300, Blue Swirl wrote: > On Fri, May 13, 2011 at 11:46 PM, Tarl Neustaedter <tarl-b2(a)tarl.net> wrote: > > On 2011-May-13 16:43 , Blue Swirl wrote: > >>> > >>> > Out of curiosity, how likely is it that qemu-sparc32 could be used to > >>> > run a > >>> > solaris-based statically-linked user-mode application? > >> > >> This would be implemented within QEMU only, so this does not concern > >> OpenBIOS much, but I gave a shot at it once: > >> http://article.gmane.org/gmane.comp.emulators.qemu/41437 > >> > >> It may be possible to make a Solaris user emulator which would allow > >> running Solaris/Sparc binaries on Solaris/x86 or vice versa, but there > >> are license compatibility issues and some technical issues to be > >> solved. > > > > Wouldn't it be easier to simply boot the Solaris 9 under qemu, copy the > > user-mode application into the environment and run it under that Solaris 9? > > Maybe, but it would be nice to be able to run applications seamlessly > in the host environment. With user emulator, for example host file > system would be available to the emulated executable just like to a > native one. > Not to mention performance benefits - not necessarily of the application itself, but the Qemu emulator eats host CPU even when the guest O/S is idling, which wouldn't be the case if you ran it in a user-mode emulator. -------- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.

1 0

Re: [OpenBIOS] Solaris anyone?
by Brian Vandenberg 13 May '11

13 May '11

(sorry for the duplicate mark) > Excellent :) In fact, latest OpenBIOS SVN has a fix for the scsi-options > part (it adds an extra property which gets picked up by the Solaris ESP > driver) and so you shouldn't have to do this any more. Any testing > gratefully received though! Yes - there is currently an issue with the Sun shell which causes OpenBIOS to select the wrong build settings. See Nathan's second thread here: http://lists.openbios.org/pipermail/openbios/2011-April/006389.html. If you could test the fix suggested at the end of the thread and report back to the mailing list, that would be greatly appreciated :) As soon as I can test this I'll report back. Unfortunately, I won't be able to copy logs & the like as it's on an air-gapped network, but I'll do what I can to give pertinent details. That's interesting, since the guest should have no knowledge of the >> underlying storage mechanism being using in the host. Can you point to any >> more specific error messages (again, back on the list) to help people work >> out what is happening? > > Not a problem. In return, thank you for testing. It really is exciting to be close to the > point where QEMU can run SPARC Solaris out of the box - I have already used > it to great effect here and I know other people are excited to be able to > move applications of legacy hardware onto something a lot more modern. > Out of curiosity, how likely is it that qemu-sparc32 could be used to run a solaris-based statically-linked user-mode application? -Brian

3 5

Re: [OpenBIOS] Solaris anyone?
by Brian Vandenberg 13 May '11

13 May '11

> > Hi Nick, > > Thanks again for testing this. The issue with Solaris not detecting the > disks is a known one - the following guide should point you in the right > direction: > http://virtuallyfun.blogspot.com/2010/10/formatting-disks-for-solaris.html > > Also don't forget the "set scsi_options" part from Artyom's SPARC/QEMU > howto here: http://tyom.blogspot.com/2009/12/solaris-under-qemu-how-to.html > > I think it may actually be possible to come up with a patch for OpenBIOS > so that the scsi_options change isn't required - let me know how you get > on with the above links, and if it all seems to work I'll look at > creating the patch for you. > > > ATB, > > Mark. > > Mark, Is the information on the blogspot link available at another location (perhaps on this mailing list)? Where I work we have a fairly tight internet policy, so most blogs are inaccessible (both artyom's and the virtuallyfun one). -Brian

2 1

Call for version 1.1?
by Mark Cave-Ayland 10 May '11

10 May '11

Hi all, With the exception of the patch just posted to the list to fix the boot word under SPARC32, I have no outstanding patches left for OpenBIOS. Since we are now able to boot some 32-bit Solaris kernels, it seems as good an excuse as any to put out a 1.1 release :) We also get the satisfaction of closing this bug here: http://tracker.coreboot.org/trac/openbios/ticket/4. Does anyone else have any other outstanding patches they feel should go in before another release? Andreas? ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

2 3

[commit] r1039 - trunk/openbios-devel/arch/sparc32
by repository service 08 May '11

08 May '11

Author: mcayland Date: Sun May 8 17:36:59 2011 New Revision: 1039 URL: http://tracker.coreboot.org/trac/openbios/changeset/1039 Log: Fix the Forth boot word if the current package is not /chosen under SPARC32. Ensure that we deselect the current package before defining the platform-specific boot words so that they are created in the global dictionary and not the current instance dictionary. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)siriusit.co.uk> Modified: trunk/openbios-devel/arch/sparc32/openbios.c Modified: trunk/openbios-devel/arch/sparc32/openbios.c ============================================================================== --- trunk/openbios-devel/arch/sparc32/openbios.c Sat May 7 00:35:59 2011 (r1038) +++ trunk/openbios-devel/arch/sparc32/openbios.c Sun May 8 17:36:59 2011 (r1039) @@ -922,13 +922,15 @@ push_str("boot-device"); fword("property"); + device_end(); + + bind_func("platform-boot", boot ); + bind_func("(go)", go ); + /* Set up other properties */ push_str("/chosen"); fword("find-device"); - bind_func("platform-boot", boot ); - bind_func("(go)", go ); - setup_uuid(); }

1 0

[PATCH] Fix the Forth boot word if the current package is not /chosen under SPARC32.
by Mark Cave-Ayland 08 May '11

08 May '11

Ensure that we deselect the current package before defining the platform-specific boot words so that they are created in the global dictionary and not the current instance dictionary. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)siriusit.co.uk> --- openbios-devel/arch/sparc32/openbios.c | 7 +++++-- 1 files changed, 5 insertions(+), 2 deletions(-) diff --git a/openbios-devel/arch/sparc32/openbios.c b/openbios-devel/arch/sparc32/openbios.c index 1d8842a..a87d2ad 100644 --- a/openbios-devel/arch/sparc32/openbios.c +++ b/openbios-devel/arch/sparc32/openbios.c @@ -922,12 +922,15 @@ arch_init( void ) push_str("boot-device"); fword("property"); + device_end(); + + bind_func("platform-boot", boot ); + bind_func("(go)", go ); + /* Set up other properties */ push_str("/chosen"); fword("find-device"); - bind_func("platform-boot", boot ); - bind_func("(go)", go ); setup_uuid(); } -- 1.7.2.5

2 1

[PATCH] Disable mixing of DMA and FIFO messages in the Solaris ESP kernel module.
by Mark Cave-Ayland 07 May '11

07 May '11

QEMU's ESP emulation currently does not support the mixing of DMA and FIFO messages. Setting the scsi-options property prevents the Solaris ESP kernel module from trying to use this feature by default, which otherwise would cause boot to fail. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)siriusit.co.uk> --- openbios-devel/drivers/esp.c | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/openbios-devel/drivers/esp.c b/openbios-devel/drivers/esp.c index 2dfc2bd..78478f6 100644 --- a/openbios-devel/drivers/esp.c +++ b/openbios-devel/drivers/esp.c @@ -383,6 +383,14 @@ ob_esp_initialize(__attribute__((unused)) esp_private_t **esp) push_str("scsi"); fword("device-type"); + /* QEMU's ESP emulation does not support mixing DMA and FIFO messages. By + setting this attribute, we prevent the Solaris ESP kernel driver from + trying to use this feature when booting a disk image (and failing) */ + PUSH(0x58); + fword("encode-int"); + push_str("scsi-options"); + fword("property"); + PUSH(0x24); fword("encode-int"); PUSH(0); -- 1.7.2.5

3 5

[commit] r1038 - trunk/openbios-devel/drivers
by repository service 07 May '11

07 May '11

Author: mcayland Date: Sat May 7 00:35:59 2011 New Revision: 1038 URL: http://tracker.coreboot.org/trac/openbios/changeset/1038 Log: Disable mixing of DMA and FIFO messages in the Solaris ESP kernel module. QEMU's ESP emulation currently does not support the mixing of DMA and FIFO messages. Setting the scsi-options property prevents the Solaris ESP kernel module from trying to use this feature by default, which otherwise would cause boot to fail. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)siriusit.co.uk> Modified: trunk/openbios-devel/drivers/esp.c Modified: trunk/openbios-devel/drivers/esp.c ============================================================================== --- trunk/openbios-devel/drivers/esp.c Wed Apr 27 21:20:10 2011 (r1037) +++ trunk/openbios-devel/drivers/esp.c Sat May 7 00:35:59 2011 (r1038) @@ -383,6 +383,14 @@ push_str("scsi"); fword("device-type"); + /* QEMU's ESP emulation does not support mixing DMA and FIFO messages. By + setting this attribute, we prevent the Solaris ESP kernel driver from + trying to use this feature when booting a disk image (and failing) */ + PUSH(0x58); + fword("encode-int"); + push_str("scsi-options"); + fword("property"); + PUSH(0x24); fword("encode-int"); PUSH(0);

1 0

[PATCH] RFC: Change ofmem_common.c to set memory translation properties by reference
by Mark Cave-Ayland 04 May '11

04 May '11

Hi folks, The attached patch changes OFMEM so that instead of allocating new space within the Forth dictionary every time the /memory and /virtual-memory available/translations nodes are updated, we simply change the property to point directly to a static buffer. This has the effect of saving substantial amounts of memory during OpenSolaris 10 boot (in fact the final dictionary size after boot is now < 256K once again). Blue/Andreas: please could you take a look at this patch and make sure it doesn't break anything in your SPARC64/PPC tests? On the plus side, with this patch applied Milax gets to the end of its natural boot without crashing giving the following output: OpenBIOS for Sparc64 Configuration device id QEMU version 1 machine id 0 kernel cmdline CPUs: 1 x SUNW,UltraSPARC-IIi UUID: 00000000-0000-0000-0000-000000000000 Welcome to OpenBIOS v1.0 built on Oct 14 2010 20:18 Type 'help' for detailed information Trying cdrom:f... Not a bootable ELF image Not a bootable a.out image Loading FCode image... Loaded 7084 bytes entry point is 0x4000 Ignoring failed claim for va 1000000 memsz bf34e! Ignoring failed claim for va 1402000 memsz 303b3! Ignoring failed claim for va 1800000 memsz 60a30! Jumping to entry point 00000000010071d8 for type 0000000000000001... switching to new context: entry point 0x10071d8 stack 0x00000000ffe06b49 warning:interpret: exception -13 caught SunOS Release 5.11 Version MilaX_0.3.2 64-bit Copyright 1983-2008 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. spacex@:interpret: exception -13 caught kdbg-words:interpret: exception -13 caught cb-r/w:interpret: exception -13 caught (Can't load tod module) EXIT -1 > Does anyone know what the tod modules does? Is it Time Of Day (i.e. we are missing some kind of hardware clock emulation?) ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

4 14

[PATCH] Fix the Forth boot word if the current package is not /chosen.
by Mark Cave-Ayland 01 May '11

01 May '11

Make sure that we explicitly state the /chosen package for the words in the boot process that require it. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)siriusit.co.uk> --- openbios-devel/forth/admin/userboot.fs | 6 ++++-- openbios-devel/forth/debugging/client.fs | 11 ++++++----- 2 files changed, 10 insertions(+), 7 deletions(-) diff --git a/openbios-devel/forth/admin/userboot.fs b/openbios-devel/forth/admin/userboot.fs index dd76958..e6ff9ab 100644 --- a/openbios-devel/forth/admin/userboot.fs +++ b/openbios-devel/forth/admin/userboot.fs @@ -12,8 +12,10 @@ then \ Execute platform-specific boot code, e.g. kernel - s" platform-boot" $find if - execute + s" platform-boot" s" /chosen" find-package if + find-method if + execute + then then (encode-bootpath) \ Setup bootpath/bootargs diff --git a/openbios-devel/forth/debugging/client.fs b/openbios-devel/forth/debugging/client.fs index f964ed0..45a931e 100644 --- a/openbios-devel/forth/debugging/client.fs +++ b/openbios-devel/forth/debugging/client.fs @@ -147,11 +147,12 @@ variable file-size then \ Call the architecture-specific code to launch the client image - s" (go)" $find if - execute - else - ." go is not yet implemented" - 2drop + s" (go)" s" /chosen" find-package if + find-method if + execute + else + ." go is not yet implemented" + then then ; -- 1.7.2.5

1 0

Re: [OpenBIOS] Solaris anyone?
by Nick Couchman 28 Apr '11

28 Apr '11

On Fri, 2011-04-22 at 08:08 +0100, Mark Cave-Ayland wrote: > With my previously posted patched applied: > > Wow. All I can say is thank you so much to everyone who helped me get > this far - in particular Blue, Artyom and Tarl. Does anyone know if we > are the first non-Sun firmware to be able to boot a Solaris kernel? > > Blue - I think you owe me that 1.1 release soon! > > > Happy Easter everyone! > > Mark. > Thanks, again, Mark - this is fantastic! After booting the install successfully from the Solaris ISO/CDROM and getting through the initial configuration (on both Solaris 8 and 9), the install fails trying to label the hard drive. First, I see the following during the installer boot: WARNING: /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@0,0 (sd0): corrupt label - wrong magic number Then, after doing the system identification, I get the following: One or more disks are found, but one of the following problems exists: > Hardware failure > Unformatted disk. At which point I get dropped to a shell. If I try to use the format command from the shell, format cannot auto-configure the disk. Even if I try manually setting C/H/S parameters (either at qemu run time or in the format command), it does not seem to want to use the disk. This seems to happen whether I'm using an LVM volume or a file-based disk. Also, seems as though all changes are lost on the disk when I exit format and then immediately go back in. Ideas? Any further help/input/debugging I could provide? -Nick -------- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.

6 14

[commit] r1037 - in trunk/openbios-devel: config/examples drivers
by repository service 27 Apr '11

27 Apr '11

Author: mcayland Date: Wed Apr 27 21:20:10 2011 New Revision: 1037 URL: http://tracker.coreboot.org/trac/openbios/changeset/1037 Log: Fix up LANCE ethernet DMA mapping under Solaris 8 on SPARC32. It seems that Solaris doesn't set up a DMA mapping for the LANCE DMA buffers and hence must inherit this from OpenBIOS. To make things more complicated, Solaris appears to assume that the buffers are fixed at 0xff000000 rather than detecting this information from the OpenBIOS IOMMU pagetable before switching. Mimicking this behaviour with a fixed location allows Solaris 8 to correctly use the network card under QEMU. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)siriusit.co.uk> Modified: trunk/openbios-devel/config/examples/sparc32_config.xml trunk/openbios-devel/drivers/sbus.c Modified: trunk/openbios-devel/config/examples/sparc32_config.xml ============================================================================== --- trunk/openbios-devel/config/examples/sparc32_config.xml Wed Apr 27 21:20:06 2011 (r1036) +++ trunk/openbios-devel/config/examples/sparc32_config.xml Wed Apr 27 21:20:10 2011 (r1037) @@ -63,6 +63,7 @@  <option name="CONFIG_DRIVER_SBUS" type="boolean" value="true"/> + <option name="CONFIG_DEBUG_SBUS" type="boolean" value="false"/> <option name="CONFIG_DRIVER_OBIO" type="boolean" value="true"/> <option name="CONFIG_DRIVER_ESP" type="boolean" value="true"/> <option name="CONFIG_DRIVER_FLOPPY" type="boolean" value="true"/> Modified: trunk/openbios-devel/drivers/sbus.c ============================================================================== --- trunk/openbios-devel/drivers/sbus.c Wed Apr 27 21:20:06 2011 (r1036) +++ trunk/openbios-devel/drivers/sbus.c Wed Apr 27 21:20:10 2011 (r1037) @@ -29,6 +29,20 @@ #define SS600MP_ESPDMA 0x00081000ULL #define SS600MP_ESP 0x00080000ULL #define SS600MP_LEBUFFER (SS600MP_ESPDMA + 0x10) // XXX should be 0x40000 +#define LEDMA_REGS 0x4 +#define LE_REGS 0x20 + +#ifdef CONFIG_DEBUG_SBUS +#define DPRINTF(fmt, args...) \ + do { printk(fmt , ##args); } while (0) +#else +#define DPRINTF(fmt, args...) +#endif + +typedef struct le_private { + uint32_t *dmaregs; + uint32_t *regs; +} le_private_t; static void ob_sbus_node_init(uint64_t base) @@ -57,8 +71,36 @@ } static void -ob_le_init(unsigned int slot, unsigned long leoffset, unsigned long dmaoffset) +ob_le_init(unsigned int slot, uint64_t base, unsigned long leoffset, unsigned long dmaoffset) { + le_private_t *le; + + le = malloc(sizeof(le_private_t)); + if (!le) { + DPRINTF("Can't allocate LANCE private structure\n"); + return; + } + + /* Get the IO region for DMA registers */ + le->dmaregs = (void *)ofmem_map_io(base + (uint64_t)dmaoffset, LEDMA_REGS); + if (le->dmaregs == NULL) { + DPRINTF("Can't map LANCE DMA registers\n"); + return; + } + + /* Now it appears that the Solaris kernel forgets to set up the LANCE DMA mapping + and so it must inherit the one from OpenBIOS. The symptom of this is that the + LANCE DMA base addr register is still zero, and so we start sending network + packets containing random areas of memory. + + The correct fix for this should be to use dvma_alloc() to grab a section of + memory and point the LANCE DMA buffers to use that instead; this gets + slightly further but still crashes. Time-consuming investigation on various + hacked versions of QEMU seems to indicate that Solaris always assumes the LANCE + DMA base address is fixed 0xff000000 when setting up the IOMMU for the LANCE + card. Hence we imitate this behaviour here. */ + le->dmaregs[3] = 0xff000000; + push_str("/iommu/sbus/ledma"); fword("find-device"); PUSH(slot); @@ -72,6 +114,13 @@ push_str("reg"); fword("property"); + /* Get the IO region for Lance registers */ + le->regs = (void *)ofmem_map_io(base + (uint64_t)leoffset, LE_REGS); + if (le->regs == NULL) { + DPRINTF("Can't map LANCE registers\n"); + return; + } + push_str("/iommu/sbus/ledma/le"); fword("find-device"); PUSH(slot); @@ -371,7 +420,7 @@ #endif // NCR 92C990, Am7990, Lance. See http://www.amd.com - ob_le_init(slot, offset + 0x00c00000, offset + 0x00400010); + ob_le_init(slot, base, offset + 0x00c00000, offset + 0x00400010); // Parallel port //ob_bpp_init(base); @@ -430,7 +479,7 @@ ob_esp_init(slot, base, SS600MP_ESP, SS600MP_ESPDMA); #endif // NCR 92C990, Am7990, Lance. See http://www.amd.com - ob_le_init(slot, 0x00060000, SS600MP_LEBUFFER); + ob_le_init(slot, base, 0x00060000, SS600MP_LEBUFFER); // Power management (APC) XXX should not exist ob_apc_init(slot, APC_OFFSET); break;

1 0

[commit] r1036 - trunk/openbios-devel/drivers
by repository service 27 Apr '11

27 Apr '11

Author: mcayland Date: Wed Apr 27 21:20:06 2011 New Revision: 1036 URL: http://tracker.coreboot.org/trac/openbios/changeset/1036 Log: Set properties to disable carrier detection on the serial ports for SPARC32. This prevents the Solaris 8 kernel from freezing during boot after detecting the serial ports. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)siriusit.co.uk> Modified: trunk/openbios-devel/drivers/escc.c Modified: trunk/openbios-devel/drivers/escc.c ============================================================================== --- trunk/openbios-devel/drivers/escc.c Fri Apr 22 02:13:53 2011 (r1035) +++ trunk/openbios-devel/drivers/escc.c Wed Apr 27 21:20:06 2011 (r1036) @@ -342,6 +342,16 @@ ob_intr(intr); + PUSH(0); + PUSH(0); + push_str("port-a-ignore-cd"); + fword("property"); + + PUSH(0); + PUSH(0); + push_str("port-b-ignore-cd"); + fword("property"); + fword("finish-device"); snprintf(nodebuff, sizeof(nodebuff), "/obio/zs@0,%x",

1 0

Re: [OpenBIOS] [PATCH] Fix up LANCE ethernet DMA mapping under Solaris 8 on SPARC32.
by Blue Swirl 26 Apr '11

26 Apr '11

On Mon, Apr 25, 2011 at 7:48 PM, Mark Cave-Ayland <mark.cave-ayland(a)siriusit.co.uk> wrote: > It seems that Solaris doesn't set up a DMA mapping for the LANCE DMA buffers > and hence must inherit this from OpenBIOS. To make things more complicated, > Solaris appears to assume that the buffers are fixed at 0xff000000 rather > than detecting this information from the OpenBIOS IOMMU pagetable before > switching. Mimicking this behaviour with a fixed location allows Solaris > 8 to correctly use the network card under QEMU. > > Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)siriusit.co.uk> Would it make any difference if IOMMU region were 16M so that the base would start at 0xff000000? Otherwise the patch looks OK.

2 4

Re: [OpenBIOS] [PATCH] Fix up LANCE ethernet DMA mapping under Solaris 8 on SPARC32.
by Andreas Färber 25 Apr '11

25 Apr '11

Am 25.04.2011 um 18:48 schrieb Mark Cave-Ayland: > It seems that Solaris doesn't set up a DMA mapping for the LANCE DMA > buffers > and hence must inherit this from OpenBIOS. To make things more > complicated, > Solaris appears to assume that the buffers are fixed at 0xff000000 > rather > than detecting this information from the OpenBIOS IOMMU pagetable > before > switching. Mimicking this behaviour with a fixed location allows > Solaris > 8 to correctly use the network card under QEMU. > > Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)siriusit.co.uk> > --- > openbios-devel/drivers/sbus.c | 55 ++++++++++++++++++++++++++++++++ > ++++++-- > 1 files changed, 52 insertions(+), 3 deletions(-) > > diff --git a/openbios-devel/drivers/sbus.c b/openbios-devel/drivers/ > sbus.c > index f4a6d66..1107c1d 100644 > --- a/openbios-devel/drivers/sbus.c > +++ b/openbios-devel/drivers/sbus.c > @@ -29,6 +29,20 @@ > #define SS600MP_ESPDMA 0x00081000ULL > #define SS600MP_ESP 0x00080000ULL > #define SS600MP_LEBUFFER (SS600MP_ESPDMA + 0x10) // XXX should be > 0x40000 > +#define LEDMA_REGS 0x4 > +#define LE_REGS 0x20 > + > +#ifdef CONFIG_DEBUG_SBUS Missing a corresponding sparc32_config.xml patch? > +#define DPRINTF(fmt, args...) \ > + do { printk(fmt , ##args); } while (0) > +#else > +#define DPRINTF(fmt, args...) > +#endif Andreas

2 3

Re: [OpenBIOS] Solaris anyone?
by Nick Couchman 25 Apr '11

25 Apr '11

> In terms of graphics, there is definitely some work that needs to be > done. For example, if I try and run the Solaris installer from the VNC > viewer then rather than launching the installer it outputs "Starting > OpenWindows" and then freezes. Then again, this is not something that is > really on my priority list (as my aim was to virtualise a headless > server) so it's unlikely to happen in the short term. Yeah, I knew there were some challenges with graphics, and it's great just to have a working emulated Sparc platform, so, don't get me wrong, this is not a complaint! > > For running QEMU in this way, have you seen Artyom's post here? > http://tyom.blogspot.com/2010/04/ultimate-way-of-starting-qemu-under.html. > Aha - that's what I was looking for. I'll have to spend some more time reading through Artyom's blog so that I don't have to ask questions like this that he's already answered. > > Did the serial port patch ever get checked off and pushed to SVN? > > No, not yet. Once Blue has approved both patches then I'll send them up > to the SVN repository. > Cool - sounds good. -Nick -------- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.

1 0

Re: [OpenBIOS] Solaris anyone?
by Nick Couchman 25 Apr '11

25 Apr '11

On Mon, 2011-04-25 at 19:03 +0100, Mark Cave-Ayland wrote: > On 25/04/11 18:10, Nick Couchman wrote: > > > Awesome - seems to work, at least it has picked up a DHCP address! I'm > > going to play with it and see if I can get a few other things (NFS > > client, SSH, etc.) to work correctly! > > Great - let us know how you get on :D > > SSH and NFS are working. I'm going to try to test out one of the applications - an ADA debugger - that we routinely run on the Solaris/Sparc platform to see how that works. Also, just a note - graphical console does not want to start, so I have to start with the -nographic option to boot correctly. This is fine, except that it pretty much precludes running qemu in the background, unless someone wants to give me a hint or two on a background-friendly method of running that doesn't cause the Solaris instance to lock-up. VNC did not work so well. Maybe there's something I could add to the boot prompt to force Solaris into a serial/text-only mode? Did the serial port patch ever get checked off and pushed to SVN? -Nick -------- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.

2 1

Solaris anyone?
by Mark Cave-Ayland 25 Apr '11

25 Apr '11

With my previously posted patched applied: ./qemu-system-sparc -cdrom /home/build/src/qemu/sparcimage/sol8-cd1.iso -boot d -nographic -prom-env 'auto-boot?=false' Configuration device id QEMU version 1 machine id 32 CPUs: 1 x FMI,MB86904 UUID: 00000000-0000-0000-0000-000000000000 Welcome to OpenBIOS v1.0 built on Apr 20 2011 18:52 Type 'help' for detailed information 0 > boot cdrom:d -v Not a bootable ELF image Loading a.out image... Loaded 7680 bytes entry point is 0x4000 bootpath: /iommu/sbus/espdma/esp/sd@2,0:d Jumping to entry point 00004000 for type 00000005... switching to new context: Size: 259040+54154+47486 Bytes SunOS Release 5.8 Version Generic_108528-09 32-bit Copyright 1983-2001 Sun Microsystems, Inc. All rights reserved. Ethernet address = 52:54:0:12:34:56 Using default device instance data vac: enabled in write through mode mem = 131072K (0x8000000) avail mem = 110260224 root nexus = SUNW,SPARCstation-5 iommu0 at root: obio 0x10000000 sbus0 at iommu0: obio 0x10001000 dma0 at sbus0: SBus slot 5 0x8400000 dma0 is /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000 /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000 (esp0): esp-options=0x46 esp0 at dma0: SBus slot 5 0x8800000 sparc ipl 4 esp0 is /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000 sd2 at esp0: target 2 lun 0 sd2 is /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@2,0 root on /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@2,0:b fstype ufs obio0 at root obio0 at obio0: obio 0x100000, sparc ipl 12 zs0 is /obio/zs@0,100000 obio1 at obio0: obio 0x0, sparc ipl 12 zs1 is /obio/zs@0,0 cpu0: FMI,MB86904 (mid 0 impl 0x0 ver 0x5 clock 170 MHz) Configuring /dev and /devices pseudo-device: devinfo0 devinfo0 is /pseudo/devinfo@0 tcx0 at sbus0: SBus slot 3 0x800000 and SBus slot 3 0x2000000 and SBus slot 3 0x4000000 and SBus slot 3 0x6000000 and SBus slot 3 0xa000000 and SBus slot 3 0xc000000 and SBus slot 3 0xe000000 and SBus slot 3 0x700000 and SBus slot 3 0x200000 and SBus slot 3 0x300000 and SBus slot 3 0x0 and SBus slot 3 0x240000 and SBus slot 3 0x280000 SBus level 5 sparc ipl 9 tcx0 is /iommu@0,10000000/sbus@0,10001000/SUNW,tcx@3,800000 tcx0: revision 0, screen 1024x768 ledma0 at sbus0: SBus slot 5 0x8400010 le0 at ledma0: SBus slot 5 0x8c00000 sparc ipl 6 le0 is /iommu@0,10000000/sbus@0,10001000/ledma@5,8400010/le@5,8c00000 sbusmem0 at sbus0: SBus slot 0 0x0 sbusmem0 is /iommu@0,10000000/sbus@0,10001000/sbusmem@0,0 sbusmem1 at sbus0: SBus slot 1 0x0 sbusmem1 is /iommu@0,10000000/sbus@0,10001000/sbusmem@1,0 sbusmem2 at sbus0: SBus slot 2 0x0 sbusmem2 is /iommu@0,10000000/sbus@0,10001000/sbusmem@2,0 sbusmem3 at sbus0: SBus slot 3 0x0 sbusmem3 is /iommu@0,10000000/sbus@0,10001000/sbusmem@3,0 sbusmem4 at sbus0: SBus slot 4 0x0 sbusmem4 is /iommu@0,10000000/sbus@0,10001000/sbusmem@4,0 sbusmem5 at sbus0: SBus slot 5 0x0 sbusmem5 is /iommu@0,10000000/sbus@0,10001000/sbusmem@5,0 pseudo-device: winlock0 winlock0 is /pseudo/winlock@0 pseudo-device: llc10 llc10 is /pseudo/llc1@0 pseudo-device: lofi0 lofi0 is /pseudo/lofi@0 pseudo-device: fcp0 fcp0 is /pseudo/fcp@0 Using RPC Bootparams for network configuration information. Skipping interface le0 Searching for configuration file(s)... Select a Language 0. English 1. French 2. German 3. Italian 4. Japanese 5. Korean 6. Simplified Chinese 7. Spanish 8. Swedish 9. Traditional Chinese Please make a choice (0 - 9), or press h or ? for help: Wow. All I can say is thank you so much to everyone who helped me get this far - in particular Blue, Artyom and Tarl. Does anyone know if we are the first non-Sun firmware to be able to boot a Solaris kernel? Blue - I think you owe me that 1.1 release soon! Happy Easter everyone! Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

2 2

[PATCH] Set properties to disable carrier detection on the serial ports for SPARC32.
by Mark Cave-Ayland 25 Apr '11

25 Apr '11

This prevents the Solaris 8 kernel from freezing during boot after detecting the serial ports. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)siriusit.co.uk> --- openbios-devel/drivers/escc.c | 10 ++++++++++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/openbios-devel/drivers/escc.c b/openbios-devel/drivers/escc.c index ef431b2..892dc8c 100644 --- a/openbios-devel/drivers/escc.c +++ b/openbios-devel/drivers/escc.c @@ -342,6 +342,16 @@ ob_zs_init(phys_addr_t base, uint64_t offset, int intr, int slave, int keyboard) ob_intr(intr); + PUSH(0); + PUSH(0); + push_str("port-a-ignore-cd"); + fword("property"); + + PUSH(0); + PUSH(0); + push_str("port-b-ignore-cd"); + fword("property"); + fword("finish-device"); snprintf(nodebuff, sizeof(nodebuff), "/obio/zs@0,%x", -- 1.7.2.5

3 2

Re: [OpenBIOS] Solaris anyone?
by Nick Couchman 25 Apr '11

25 Apr '11

> Okay - I now have a patch which appears to solve the issue here after > numerous of hours debugging. I'll clean it up and post it to the list in > a few minutes for you to test. > > Awesome - seems to work, at least it has picked up a DHCP address! I'm going to play with it and see if I can get a few other things (NFS client, SSH, etc.) to work correctly! -Nick -------- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.

2 1

[PATCH] Fix up LANCE ethernet DMA mapping under Solaris 8 on SPARC32.
by Mark Cave-Ayland 25 Apr '11

25 Apr '11

It seems that Solaris doesn't set up a DMA mapping for the LANCE DMA buffers and hence must inherit this from OpenBIOS. To make things more complicated, Solaris appears to assume that the buffers are fixed at 0xff000000 rather than detecting this information from the OpenBIOS IOMMU pagetable before switching. Mimicking this behaviour with a fixed location allows Solaris 8 to correctly use the network card under QEMU. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)siriusit.co.uk> --- openbios-devel/drivers/sbus.c | 55 ++++++++++++++++++++++++++++++++++++++-- 1 files changed, 52 insertions(+), 3 deletions(-) diff --git a/openbios-devel/drivers/sbus.c b/openbios-devel/drivers/sbus.c index f4a6d66..1107c1d 100644 --- a/openbios-devel/drivers/sbus.c +++ b/openbios-devel/drivers/sbus.c @@ -29,6 +29,20 @@ #define SS600MP_ESPDMA 0x00081000ULL #define SS600MP_ESP 0x00080000ULL #define SS600MP_LEBUFFER (SS600MP_ESPDMA + 0x10) // XXX should be 0x40000 +#define LEDMA_REGS 0x4 +#define LE_REGS 0x20 + +#ifdef CONFIG_DEBUG_SBUS +#define DPRINTF(fmt, args...) \ + do { printk(fmt , ##args); } while (0) +#else +#define DPRINTF(fmt, args...) +#endif + +typedef struct le_private { + uint32_t *dmaregs; + uint32_t *regs; +} le_private_t; static void ob_sbus_node_init(uint64_t base) @@ -57,8 +71,36 @@ ob_sbus_node_init(uint64_t base) } static void -ob_le_init(unsigned int slot, unsigned long leoffset, unsigned long dmaoffset) +ob_le_init(unsigned int slot, uint64_t base, unsigned long leoffset, unsigned long dmaoffset) { + le_private_t *le; + + le = malloc(sizeof(le_private_t)); + if (!le) { + DPRINTF("Can't allocate LANCE private structure\n"); + return; + } + + /* Get the IO region for DMA registers */ + le->dmaregs = (void *)ofmem_map_io(base + (uint64_t)dmaoffset, LEDMA_REGS); + if (le->dmaregs == NULL) { + DPRINTF("Can't map LANCE DMA registers\n"); + return; + } + + /* Now it appears that the Solaris kernel forgets to set up the LANCE DMA mapping + and so it must inherit the one from OpenBIOS. The symptom of this is that the + LANCE DMA base addr register is still zero, and so we start sending network + packets containing random areas of memory. + + The correct fix for this should be to use dvma_alloc() to grab a section of + memory and point the LANCE DMA buffers to use that instead; this gets + slightly further but still crashes. Time-consuming investigation on various + hacked versions of QEMU seems to indicate that Solaris always assumes the LANCE + DMA base address is fixed 0xff000000 when setting up the IOMMU for the LANCE + card. Hence we imitate this behaviour here. */ + le->dmaregs[3] = 0xff000000; + push_str("/iommu/sbus/ledma"); fword("find-device"); PUSH(slot); @@ -72,6 +114,13 @@ ob_le_init(unsigned int slot, unsigned long leoffset, unsigned long dmaoffset) push_str("reg"); fword("property"); + /* Get the IO region for Lance registers */ + le->regs = (void *)ofmem_map_io(base + (uint64_t)leoffset, LE_REGS); + if (le->regs == NULL) { + DPRINTF("Can't map LANCE registers\n"); + return; + } + push_str("/iommu/sbus/ledma/le"); fword("find-device"); PUSH(slot); @@ -371,7 +420,7 @@ ob_macio_init(unsigned int slot, uint64_t base, unsigned long offset) #endif // NCR 92C990, Am7990, Lance. See http://www.amd.com - ob_le_init(slot, offset + 0x00c00000, offset + 0x00400010); + ob_le_init(slot, base, offset + 0x00c00000, offset + 0x00400010); // Parallel port //ob_bpp_init(base); @@ -430,7 +479,7 @@ sbus_probe_slot_ss600mp(unsigned int slot, uint64_t base) ob_esp_init(slot, base, SS600MP_ESP, SS600MP_ESPDMA); #endif // NCR 92C990, Am7990, Lance. See http://www.amd.com - ob_le_init(slot, 0x00060000, SS600MP_LEBUFFER); + ob_le_init(slot, base, 0x00060000, SS600MP_LEBUFFER); // Power management (APC) XXX should not exist ob_apc_init(slot, APC_OFFSET); break; -- 1.7.2.5

1 0

Re: [OpenBIOS] Solaris anyone?
by Nick Couchman 25 Apr '11

25 Apr '11

> Awesome! If you can make a note of what you had to do in order to get it > to work and post it to the list, I'm sure lots of people will be very > grateful :) > Okay, so, if you set up, for example, an LVM disk that's 10G in size on Linux, and you do an "fdisk -l" on the LVM volume, you see the following: linux:~ # fdisk -l /dev/local/Solaris8 Disk /dev/local/Solaris8: 10.7 GB, 10737418240 bytes 255 heads, 63 sectors/track, 1305 cylinders, total 20971520 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000 Disk /dev/local/Solaris8 doesn't contain a valid partition table This shows C/H/S parameters of 1305/255/63. Seems reasonable enough, so, we boot the install disk in single user mode (boot cdrom:d -s) and use the format command to configure the disk with these settings. (Note: Solaris 9 accepts the heads value of 255 - Solaris 8 seems to choke on even this.) After format is finished configuring the disk, we use the "newfs /dev/rdsk/c0t0d0s0" command to try to create a new filesystem, and we get this: # newfs /dev/rdsk/c0t0d0s0 newfs: construct a new file system /dev/rdsk/c0t0d0s0: (y/n)? y With a block size of 8192 minimum bytes per inode is 5884 Minimum bytes per inode is 5884 With 16065 sectors per cylinder, minimum cylinders per group is 16 This requires the fragment size to be changed from 1024 to 4096 Please re-run mkfs with corrected parameters So, apparently there's some limitation on the C/H/S parameters and how those interact with the UFS volume you're trying to create. Obviously one solution is to run mkfs with the suggested fragment size change; however, this is hard to do during the install, and the installer isn't very forgiving about letter you tweak things and continue on with the install. So, what I did is recalculate the C/H/S parameters to reduce the Heads value and increase the Cylinders value. I stuck with the 63 sectors/track number and just recalculated the Cylinders and Heads value. So, if you multiply 1305 * 255, you get 332775. You can then reduce one of the numbers to something more sane - I, for example, reduced Heads to 16, then divide that into 332775 = 20798 (rounded down), which is your new Cylinders value. Reconfigure the disk in format with these new parameters (don't forget to label!), then use newfs, again: # newfs /dev/rdsk/c0t0d0s0 newfs: construct a new file system /dev/rdsk/c0t0d0s0: (y/n)? y /dev/rdsk/c0t0d0s0: 263088 sectors in 261 cylinders of 16 tracks, 63 sectors 128.5MB in 17 cyl groups (16 c/g, 7.88MB/g, 3776 i/g) super-block backups (for fsck -F ufs -o b=#) at: 32, 16224, 32416, 48608, 64800, 80992, 97184, 113376, 129568, 145760, 161952, 178144, 194336, 210528, 226720, 242912, 258080, Success! Now we can actually go through the installer and it will partition and format correctly during the install process! Let me know if anything looks amiss with my calculations - I haven't done any extensive testing to verify that the C/H/S values work at the disk boundaries. -Nick -------- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.

1 0