OpenBIOS March 2012

openbios@openbios.org

10 participants
12 discussions

by Programmingkid

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 ;

8 years, 8 months

Re: [OpenBIOS] [Qemu-devel] [Bug 965133] [NEW] Sparc64 crash on start

by Blue Swirl

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 >

8 years, 10 months

Re: [OpenBIOS] Adding to a definition

by Programmingkid

> 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?

8 years, 10 months

Re: [OpenBIOS] SPARC64 device tree model - SBUS or PCI?

by Dave Simonson

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

8 years, 10 months

SPARC64 device tree model - SBUS or PCI?

by Mark Cave-Ayland

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.

8 years, 10 months

HelenOS regression in QEMU implies OpenBIOS VGA issue

by Mark Cave-Ayland

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.

8 years, 10 months

[commit] r1048 - in trunk/openbios-devel: arch/sparc64 drivers

by repository service

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;

8 years, 10 months

[PATCH] pci: fix BAR setup

by Blue Swirl

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

8 years, 10 months

Re: [OpenBIOS] [PATCH] pci: fix BAR setup

by Mark Cave-Ayland

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.

8 years, 10 months

Re: [OpenBIOS] [Qemu-ppc] qemu -cpu 7455 doesn't work

by Jörg Sommer

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>

8 years, 10 months