April 2013 - OpenBIOS - mail.coreboot.org

Re: [OpenBIOS] [PATCH 2/2] Don't map the page 0 to make NULL-dereferencing more obvious
by Tarl Neustaedter April 8, 2013

April 8, 2013

On 2013-Apr-8 15:00 , Artyom Tarasenko wrote: > I guess ihandle>phandle shouldn't be called for the root entry. What > do you think? You're probably calling ihandle>phandle with a phandle. I would expect the return from active-package to be a phandle, not an ihandle.

2 1

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Mark Cave-Ayland April 8, 2013

April 8, 2013

On 07/04/13 21:10, Artyom Tarasenko wrote: >> Artyom - can you confirm whether reducing MEMORY_SIZE to 128K is enough for >> kadb to work in your SunOS image? If that works, I'll create another patch >> series for you to test. > > You mean, instead of modifying ofmem_arch_get_virt_top, right? > Yes, this seems to be enough, kadb starts. Actually both are needed as I discovered that the virtual memory allocator starts at the top of the Forth machine RAM and works down, so at some point it would end up clobbering some Forth internals :/ Can you try the revised patchset I'm about to post on top of SVN trunk and http://www.openfirmware.info/pipermail/openbios/2013-April/007572.html and confirm that your kadb still loads? This works for me on my current SPARC32 test suite of Linux, Solaris 8 and NetBSD. Many thanks, Mark.

2 1

Re: [OpenBIOS] [PATCH 2/2] Don't map the page 0 to make NULL-dereferencing more obvious
by Artyom Tarasenko April 8, 2013

April 8, 2013

On Sat, Apr 6, 2013 at 3:57 AM, Artyom Tarasenko <atar4qemu(a)gmail.com> wrote: > > Signed-off-by: Artyom Tarasenko <atar4qemu(a)gmail.com> > --- > arch/sparc32/lib.c | 5 ++++- > 1 files changed, 4 insertions(+), 1 deletions(-) > > diff --git a/arch/sparc32/lib.c b/arch/sparc32/lib.c > index 483069c..215ddcc 100644 > --- a/arch/sparc32/lib.c > +++ b/arch/sparc32/lib.c > @@ -19,6 +19,8 @@ > > #define NCTX_SWIFT 0x100 > #define LOWMEMSZ 32 * 1024 * 1024 > +/* Avoid mapping the first page to make NULL-dereferencing more obvious */ > +#define LOWMEM_START PAGE_SIZE > > #ifdef CONFIG_DEBUG_MEM > #define DPRINTF(fmt, args...) \ > @@ -403,7 +405,8 @@ init_mmu_swift(void) > ofmem_arch_map_pages(pa, va, size, ofmem_arch_default_translation_mode(pa)); > > // 1:1 mapping for RAM > - ofmem_arch_map_pages(0, 0, LOWMEMSZ, ofmem_arch_default_translation_mode(0)); > + ofmem_arch_map_pages(LOWMEM_START, LOWMEM_START, LOWMEMSZ, > + ofmem_arch_default_translation_mode(LOWMEM_START)); > > /* > * Flush cache Found one bug in Forth code using this patch: 0 > debug (.property-by-name) Stepper keys: <space>/<enter> Up Down Trace Rstack Forth ok 0 > cd / ok 0 > .properties name : (.property-by-name) ( ffd2e398 4 ffd2e398 4 ffd3872c 14 ) ffd30c00: 2over ( ffd2e398 4 ffd2e398 4 ffd3872c 14 ffd2e398 4 ) ffd30c04: (") ( ffd2e398 4 ffd2e398 4 ffd3872c 14 ffd2e398 4 ffd30c0c 3 ) ffd30c10: strcmp ( ffd2e398 4 ffd2e398 4 ffd3872c 14 1 ) ffd30c14: 0= ( ffd2e398 4 ffd2e398 4 ffd3872c 14 0 ) ffd30c18: do?branch ( ffd2e398 4 ffd2e398 4 ffd3872c 14 ) ffd30c38: active-package ( ffd2e398 4 ffd2e398 4 ffd3872c 14 ffd2e318 ) ffd30c3c: get-nodename ( ffd2e398 4 ffd2e398 4 ffd3872c 14 ffd3872c 13 ) ffd30c40: (") ( ffd2e398 4 ffd2e398 4 ffd3872c 14 ffd3872c 13 ffd30c48 6 ) ffd30c50: strcmp ( ffd2e398 4 ffd2e398 4 ffd3872c 14 1 ) ffd30c54: 0= ( ffd2e398 4 ffd2e398 4 ffd3872c 14 0 ) ffd30c58: do?branch ( ffd2e398 4 ffd2e398 4 ffd3872c 14 ) ffd30ca0: (") ( ffd2e398 4 ffd2e398 4 ffd3872c 14 ffd30ca8 7 ) ffd30cb0: find-dev ( ffd2e398 4 ffd2e398 4 ffd3872c 14 ffd2e6f8 ffffffff ) ffd30cb4: do?branch ( ffd2e398 4 ffd2e398 4 ffd3872c 14 ffd2e6f8 ) ffd30cbc: (") ( ffd2e398 4 ffd2e398 4 ffd3872c 14 ffd2e6f8 ffd30cc4 3 ) ffd30cc8: rot ( ffd2e398 4 ffd2e398 4 ffd3872c 14 ffd30cc4 3 ffd2e6f8 ) ffd30ccc: get-package-property ( ffd2e398 4 ffd2e398 4 ffd3872c 14 ffd2e7c4 4 0 ) ffd30cd0: 0= ( ffd2e398 4 ffd2e398 4 ffd3872c 14 ffd2e7c4 4 ffffffff ) ffd30cd4: do?branch ( ffd2e398 4 ffd2e398 4 ffd3872c 14 ffd2e7c4 4 ) ffd30cdc: decode-int ( ffd2e398 4 ffd2e398 4 ffd3872c 14 ffd2e7c8 0 0 ) ffd30ce0: nip ( ffd2e398 4 ffd2e398 4 ffd3872c 14 ffd2e7c8 0 ) ffd30ce4: nip ( ffd2e398 4 ffd2e398 4 ffd3872c 14 0 ) ^^^^ here we have a null-pointer de-referencing. ffd30ce8: ihandle>phandle Unhandled Exception 0x00000009 PC = 0xffd07f74 NPC = 0xffd07f78 I guess ihandle>phandle shouldn't be called for the root entry. What do you think? -- Regards, Artyom Tarasenko linux/sparc and solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu

1 0

[PATCH 1/2] SPARC32: Fix OFMEM mappings for OpenBIOS so that they show up in the translations property.
by Mark Cave-Ayland April 8, 2013

April 8, 2013

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- openbios-devel/arch/sparc32/lib.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/openbios-devel/arch/sparc32/lib.c b/openbios-devel/arch/sparc32/lib.c index 483069c..c0df654 100644 --- a/openbios-devel/arch/sparc32/lib.c +++ b/openbios-devel/arch/sparc32/lib.c @@ -401,9 +401,11 @@ init_mmu_swift(void) size = (unsigned long)&_end - (unsigned long)&_start; pa = va2pa(va); ofmem_arch_map_pages(pa, va, size, ofmem_arch_default_translation_mode(pa)); + ofmem_map_page_range(pa, va, size, ofmem_arch_default_translation_mode(pa)); // 1:1 mapping for RAM ofmem_arch_map_pages(0, 0, LOWMEMSZ, ofmem_arch_default_translation_mode(0)); + ofmem_map_page_range(0, 0, LOWMEMSZ, ofmem_arch_default_translation_mode(0)); /* * Flush cache -- 1.7.10.4

1 1

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Mark Cave-Ayland April 7, 2013

April 7, 2013

On 06/04/13 20:34, Artyom Tarasenko wrote: > Unfortunately not: > > OFMEM: ofmem_map_page_range ffdd3000 -> 050800000 000c0000 mode 0000003c > OFMEM: mapping altered virt=ffdd3000) > OFMEM: ofmem_map_page_range ffe93000 -> 050200000 00001000 mode 0000003c > OFMEM: ofmem_map_page_range ffe94000 -> 071000000 00001000 mode 0000003c > > OFMEM: ofmem_claim phys=ffffffffffffffff size=00080000 align=00001000 > OFMEM: ofmem_claim_virt virt=ffc80000 size=00080000 align=00000000 > > ^^^^ this one > > OFMEM: ofmem_map_page_range ffc80000 -> 006f80000 00080000 mode 000000bc > OFMEM: ofmem_map_page_range ffe95000 -> d00000000 00001000 mode 0000003c > Configuration device id QEMU version 1 machine id 32 > OFMEM: ofmem_map_page_range ffe96000 -> 010000000 00001000 mode 0000003c > OFMEM: ofmem_map_page_range ffe97000 -> 071100000 00001000 mode 0000003c > OFMEM: ofmem_map_page_range ffe98000 -> 071000000 00001000 mode 0000003c > OFMEM: ofmem_map_page_range ffe99000 -> 071200000 00002000 mode 0000003c > OFMEM: ofmem_map_page_range ffe9b000 -> 071400000 00001000 mode 0000003c > OFMEM: ofmem_map_page_range ffe9c000 -> 071900000 00001000 mode 0000003c > OFMEM: ofmem_map_page_range ffe9d000 -> 071910000 00001000 mode 0000003c > OFMEM: ofmem_map_page_range ffe9e000 -> 071f00000 00001000 mode 0000003c > OFMEM: ofmem_map_page_range ffe9f000 -> 071d00000 00011000 mode 0000003c > OFMEM: ofmem_map_page_range ffeb0000 -> 071e00000 00011000 mode 0000003c > OFMEM: ofmem_map_page_range ffec1000 -> 007fff000 00001000 mode 0000003c > OFMEM: ofmem_map_page_range ffec2000 -> 010001000 00001000 mode 0000003c > OFMEM: ofmem_map_page_range ffec3000 -> 078400000 00001000 mode 0000003c > OFMEM: ofmem_map_page_range ffec4000 -> 078800000 00001000 mode 0000003c > OFMEM: ofmem_map_page_range ffec5000 -> 078400000 00001000 mode 0000003c > OFMEM: ofmem_map_page_range ffec6000 -> 078c00000 00001000 mode 0000003c > CPUs: 1 x FMI,MB86904 > UUID: 00000000-0000-0000-0000-000000000000 > Welcome to OpenBIOS v1.0 built on Mar 28 2013 13:34 > Type 'help' for detailed information > > > 0> boot disk kadb -kdvs Not a bootable ELF image > Loading a.out image... > Loaded 7680 bytes > entry point is 0x4000 > bootpath: /iommu/sbus/espdma/esp/sd@0,0 > > Jumping to entry point 00004000 for type 00000005... > switching to new context: > OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000 align=00001000 > OFMEM: ofmem_claim_virt virt=00000000 size=00001000 align=00001000 > OFMEM: ofmem_map_page_range fefff000 -> 006f7f000 00001000 mode 000000bc > OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000 align=00001000 > OFMEM: ofmem_claim_virt virt=00000000 size=00001000 align=00001000 > OFMEM: ofmem_map_page_range feffe000 -> 006f7e000 00001000 mode 000000bc > OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000 align=00001000 > OFMEM: ofmem_claim_virt virt=00000000 size=00001000 align=00001000 > OFMEM: ofmem_map_page_range feffd000 -> 006f7d000 00001000 mode 000000bc > OFMEM: ofmem_claim phys=ffffffffffffffff size=00014000 align=00020000 > OFMEM: ofmem_claim_virt virt=00000000 size=00014000 align=00002000 > OFMEM: ofmem_map_page_range fefe8000 -> 006f60000 00014000 mode 000000bc > Boot Release 4.1.4 (sun4m) #2: Fri Oct 14 11:07:52 PDT 1994 > Copyright (c) 1983-1990, Sun Microsystems, Inc. > Boot: Romvec version 3. > OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000 align=00001000 > OFMEM: ofmem_claim_virt virt=00000000 size=00001000 align=00001000 > OFMEM: ofmem_map_page_range feffc000 -> 006f7c000 00001000 mode 000000bc > root on /iommu/sbus/espdma/esp/sd@0,0 fstype 4.2 > Boot: kadb > OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000 align=00001000 > OFMEM: ofmem_claim_virt virt=00000000 size=00001000 align=00001000 > OFMEM: ofmem_map_page_range fefe7000 -> 006f7b000 00001000 mode 000000bc > .Size: 121296............................+103120+14200 bytes > Statistics: > OFMEM: ofmem_claim phys=ffffffffffffffff size=0003c000 align=00040000 > OFMEM: ofmem_claim_virt virt=ffc00000 size=0003c000 align=00000000 > OFMEM: ofmem_map_page_range ffc00000 -> 006f00000 0003c000 mode 000000bc > OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000 align=00001000 > OFMEM: ofmem_claim_virt virt=00000000 size=00001000 align=00001000 > OFMEM: ofmem_map_page_range fefe6000 -> 006f7a000 00001000 mode 000000bc > kadb: > kadb: vmunix > .Size: 1548288......................................................................................................................................................................................................................................................+463688+225704 > bytes > OFMEM: ofmem_claim phys=ffffffffffffffff size=00003000 align=00004000 > OFMEM: ofmem_claim_virt virt=ffc3c000 size=00003000 align=00000000 > OFMEM: ofmem_map_page_range ffc3c000 -> 006f74000 00003000 mode 000000bc > OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000 align=00001000 > OFMEM: ofmem_claim_virt virt=ffc3f000 size=00001000 align=00000000 > OFMEM: ofmem_map_page_range ffc3f000 -> 006f79000 00001000 mode 000000bc > .OFMEM: ofmem_claim phys=ffffffffffffffff size=0001c000 align=00020000 > OFMEM: ofmem_claim_virt virt=ffc40000 size=0001c000 align=00000000 > OFMEM: ofmem_map_page_range ffc40000 -> 006f40000 0001c000 mode 000000bc > ................OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000 > align=00001000 > OFMEM: ofmem_claim_virt virt=ffc5c000 size=00001000 align=00000000 > OFMEM: ofmem_map_page_range ffc5c000 -> 006f78000 00001000 mode 000000bc > OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 > OFMEM: ofmem_claim_virt virt=ffc5d000 size=00002000 align=00000000 > OFMEM: ofmem_map_page_range ffc5d000 -> 006f5e000 00002000 mode 000000bc > ...OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 > OFMEM: ofmem_claim_virt virt=ffc5f000 size=00002000 align=00000000 > OFMEM: ofmem_map_page_range ffc5f000 -> 006f5c000 00002000 mode 000000bc > .....OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 > OFMEM: ofmem_claim_virt virt=ffc61000 size=00002000 align=00000000 > OFMEM: ofmem_map_page_range ffc61000 -> 006f3e000 00002000 mode 000000bc > ...OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 > OFMEM: ofmem_claim_virt virt=ffc63000 size=00002000 align=00000000 > OFMEM: ofmem_map_page_range ffc63000 -> 006f3c000 00002000 mode 000000bc > ..OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 > OFMEM: ofmem_claim_virt virt=ffc65000 size=00002000 align=00000000 > OFMEM: ofmem_map_page_range ffc65000 -> 006efe000 00002000 mode 000000bc > ..OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 > OFMEM: ofmem_claim_virt virt=ffc67000 size=00002000 align=00000000 > OFMEM: ofmem_map_page_range ffc67000 -> 006efc000 00002000 mode 000000bc > ..OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 > OFMEM: ofmem_claim_virt virt=ffc69000 size=00002000 align=00000000 > OFMEM: ofmem_map_page_range ffc69000 -> 006efa000 00002000 mode 000000bc > ..OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 > OFMEM: ofmem_claim_virt virt=ffc6b000 size=00002000 align=00000000 > OFMEM: ofmem_map_page_range ffc6b000 -> 006ef8000 00002000 mode 000000bc > ..OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 > OFMEM: ofmem_claim_virt virt=ffc6d000 size=00002000 align=00000000 > OFMEM: ofmem_map_page_range ffc6d000 -> 006ef6000 00002000 mode 000000bc > ..OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 > OFMEM: ofmem_claim_virt virt=ffc6f000 size=00002000 align=00000000 > OFMEM: ofmem_map_page_range ffc6f000 -> 006ef4000 00002000 mode 000000bc > ..OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 > OFMEM: ofmem_claim_virt virt=ffc71000 size=00002000 align=00000000 > OFMEM: ofmem_map_page_range ffc71000 -> 006ef2000 00002000 mode 000000bc > ..OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 > OFMEM: ofmem_claim_virt virt=ffc73000 size=00002000 align=00000000 > OFMEM: ofmem_map_page_range ffc73000 -> 006ef0000 00002000 mode 000000bc > ....OFMEM: ofmem_claim phys=ffffffffffffffff size=00003000 align=00004000 > OFMEM: ofmem_claim_virt virt=ffc75000 size=00003000 align=00000000 > OFMEM: ofmem_map_page_range ffc75000 -> 006eec000 00003000 mode 000000bc > ...OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 > OFMEM: ofmem_claim_virt virt=ffc78000 size=00002000 align=00000000 > OFMEM: ofmem_map_page_range ffc78000 -> 006eea000 00002000 mode 000000bc > ..OFMEM: ofmem_claim phys=ffffffffffffffff size=00003000 align=00004000 > OFMEM: ofmem_claim_virt virt=ffc7a000 size=00003000 align=00000000 > OFMEM: ofmem_map_page_range ffc7a000 -> 006ee4000 00003000 mode 000000bc > ....OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 > OFMEM: ofmem_claim_virt virt=ffc7d000 size=00002000 align=00000000 > OFMEM: ofmem_map_page_range ffc7d000 -> 006ee8000 00002000 mode 000000bc > ..OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000 > OFMEM: ofmem_claim_virt virt=ffc7f000 size=00002000 align=00000000 > OFMEM: Non-free virtual memory claimed! > > ^^^^^ overlaps with this one. Hmmm so a quick look at the Linux source code (and some dumps from QEMU's "info tlb") showed me what has happening here. The problem is that Linux doesn't read the value of the "translations" property from OpenBIOS when taking over the MMU page table - instead it performs a manual scan of the existing page table between a range of addresses. It looks as if the range is from 0xfe400000 to 0xfff00000, however the lower ends of these ranges seem to be repurposed for debuggers and I/O memory - so it means that if we keep anything too far outside of the PROM range 0xffd00000 to 0xfff00000 then we're going to be in trouble. Unfortunately because we map the entire framebuffer directly then we don't have much memory to play with :( I think the only solution is to reduce the amount of memory for the Forth machine for SPARC32 by changing MEMORY_SIZE in arch/sparc32/openbios.c, and then tucking it underneath 0xffd00000 as per my last patchset. So far I can get away with reducing it to 128K, and Bob's original test case for increasing the Forth machine memory (because of lack of memory for the Fcode table) still runs, e.g. 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 Artyom - can you confirm whether reducing MEMORY_SIZE to 128K is enough for kadb to work in your SunOS image? If that works, I'll create another patch series for you to test. ATB, Mark.

2 1

Re: [OpenBIOS] [PATCH 1/2] Fix NULL-dereferencing in sunparts_open
by Mark Cave-Ayland April 6, 2013

April 6, 2013

On 06/04/13 18:42, Artyom Tarasenko wrote: >> Thanks - this is a similar bug to the one that was in mac-parts.c so I've >> applied it. > > I've found it after applying the patch preventing mapping of the page > 0 and looking what breaks. > It may be a good idea not to map the page 0 on other architectures too. Yeah I'd be quite tempted to make this the default (and it's probably why load-base is often set to 0x4000 so page 0 can be unmapped). Blue - what do you think? ATB, Mark.

2 1

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Mark Cave-Ayland April 6, 2013

April 6, 2013

On 06/04/13 10:46, Artyom Tarasenko wrote: >> Yes! In kadb I get! >> >> FMEM: ofmem_map_page_range ffcb0000 -> 006ea0000 00008000 mode 000000bc >> .vmunix loaded - 0x7c000 bytes used >> >> Unfortunately it's not as helpful as it became under Solaris 2.6+ : > > Especially when someone hasn't use it for the long time. Actually it's > pretty good: > > kadb> :c > OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000 align=00001000 > OFMEM: ofmem_claim_virt virt=00000000 size=00001000 align=00001000 > OFMEM: ofmem_map_page_range fef65000 -> 006f77000 00001000 mode 000000bc > Begin traceback... sp = f0186b20 > Called from ffc017cc, fp=f0186b80, args=9 f013f870 f013f874 0 200 0 > Called from f013f83c, fp=f0186c08, args=f01e4000 1 f01e2bf0 fd020000 > f0186d88 f01e2ff4 > Called from f0140a38, fp=f0186c68, args=f01e563c 1cc5 f01e5652 > ff000008 ff000008 4400fe1 > Called from f0054f44, fp=f0186cc8, args=f0186d8c 22 ffffffff a f0186d8c 22 > Called from f0054724, fp=f0186d28, args=f0186d8c 22 5 0 ffffffff 0 > Called from f0054494, fp=f0186e18, args=f01e2173 f0186ec0 5 0 f0186e10 0 > Called from f0132e7c, fp=f0186e78, args=f01e2173 0 0 0 f0186e98 f0186ec0 > Called from f01375e0, fp=f0186ef8, args=f01e43c2 ffd2e31c f01e28f4 0 > f01e2b1c ffffffff > Called from f0005250, fp=f0186f58, args=400 f01aa000 f9fbe000 0 200 f0178570 > Called from ffc11c94, fp=0, args=4000 3ffb78 0 ffc37570 ffc259d0 1 > End traceback... > fault and calling cmd: trap 9 sp f0186b20 pc f013f870 npc f013f874 > stopped at 0: unimp 0x0 > kadb> $c > PR_BASE() + 0 > kadb> f0054f44?ai > _writekmsg+0x68: _writekmsg+0x68: call > _mpprom_write_nl7 > kadb> f0005250?ai > _firsthighinstr+0xd8: _firsthighinstr+0xd8: call > _early_startup > kadb> > > Woo-hoo! Hi Artyom, I've just posted a patchset to lower the virtual memory allocation range - can you test with that patchset applied, plus my patch in http://www.openfirmware.info/pipermail/openbios/2013-April/007572.html means that you can still load kadb on your image? If that works, I'll put together a patch to move the alignment rounding up behaviour in core OFMEM, as detailed in the specification. ATB, Mark.

2 1

Re: [OpenBIOS] Booting SunOS from OpenBIOS
by Artyom Tarasenko April 6, 2013

April 6, 2013

On Sat, Apr 6, 2013 at 11:07 AM, Blue Swirl <blauwirbel(a)gmail.com> wrote: > On Sat, Apr 6, 2013 at 1:50 AM, Artyom Tarasenko <atar4qemu(a)gmail.com> wrote: >> On Fri, Apr 5, 2013 at 10:08 PM, Tarl Neustaedter <tarl-b2(a)tarl.net> wrote: >>> On 2013-Apr-5 15:40 , Artyom Tarasenko wrote: >>>> >>>> [...] >>> You might change that patch rather than rounding up to the next 2^n, don't >>> bother aligning to anything more than 0x2000. >> >> You mean >> >> } else if ( align > 0x2000) { >> align = 0x2000; >> } else { > > This would probably break allocation for IOMMU table, it needs to be > aligned (physically) to table size (like 32MB). The patch actually changes only the virtual alignment. It seems to work without this part though. -- Regards, Artyom Tarasenko linux/sparc and solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu

1 0

[PATCH 1/3] SPARC32: Fix OpenBIOS ROM in RAM copy mapping.
by Mark Cave-Ayland April 6, 2013

April 6, 2013

This ensures that the physical and virtual addresses for OpenBIOS itself are marked as in use, and also appear in the translations property so they can be maintained by client programs. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- openbios-devel/arch/sparc32/ofmem_sparc32.c | 6 ++++-- openbios-devel/include/arch/sparc32/ofmem_sparc32.h | 4 +++- 2 files changed, 7 insertions(+), 3 deletions(-) diff --git a/openbios-devel/arch/sparc32/ofmem_sparc32.c b/openbios-devel/arch/sparc32/ofmem_sparc32.c index e2f4159..a6557df 100644 --- a/openbios-devel/arch/sparc32/ofmem_sparc32.c +++ b/openbios-devel/arch/sparc32/ofmem_sparc32.c @@ -241,6 +241,8 @@ void ofmem_init( void ) /* Claim reserved physical addresses at top of RAM */ ofmem_claim_phys(ofmem_arch_get_phys_top(), s_ofmem_data.ofmem.ramsize - ofmem_arch_get_phys_top(), 0); - /* Claim OpenBIOS reserved space */ - ofmem_claim_virt(0xffd00000, 0x300000, 0); + /* Map OpenBIOS ROM in RAM copy */ + ofmem_claim_phys(va2pa(OF_CODE_START), s_ofmem_data.ofmem.ramsize - va2pa(OF_CODE_START), 0); + ofmem_claim_virt(OF_CODE_START, (ucell)-1, 0); + ofmem_map_page_range(va2pa(OF_CODE_START), OF_CODE_START, s_ofmem_data.ofmem.ramsize - va2pa(OF_CODE_START), ofmem_arch_default_translation_mode(OF_CODE_START)); } diff --git a/openbios-devel/include/arch/sparc32/ofmem_sparc32.h b/openbios-devel/include/arch/sparc32/ofmem_sparc32.h index 7a35b44..6ffa172 100644 --- a/openbios-devel/include/arch/sparc32/ofmem_sparc32.h +++ b/openbios-devel/include/arch/sparc32/ofmem_sparc32.h @@ -16,6 +16,8 @@ #include "libopenbios/ofmem.h" +#define OF_CODE_START 0xffd00000 + struct mem; extern struct mem cdvmem; @@ -25,4 +27,4 @@ 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 +#endif /* _H_OFMEM_SPARC32 */ -- 1.7.10.4

1 2

Re: [OpenBIOS] [PATCH 1/2] Fix NULL-dereferencing in sunparts_open
by Mark Cave-Ayland April 6, 2013

April 6, 2013

On 06/04/13 02:57, Artyom Tarasenko wrote: > Signed-off-by: Artyom Tarasenko<atar4qemu(a)gmail.com> > --- > packages/sun-parts.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/packages/sun-parts.c b/packages/sun-parts.c > index 2ee9613..272f7c0 100644 > --- a/packages/sun-parts.c > +++ b/packages/sun-parts.c > @@ -109,7 +109,7 @@ sunparts_open( sunparts_info_t *di ) > [(id)][,][filespec] > */ > > - if ( strlen(str) ) { > + if ( str&& strlen(str) ) { > /* Detect the arguments */ > if ((*str>= '0'&& *str<= '9') || (*str>= 'a'&& *str< ('a' + 8)) || (*str == ',')) { > push_str(str); Thanks - this is a similar bug to the one that was in mac-parts.c so I've applied it. ATB, Mark.

2 1