Adding to a definition
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
;
6 years, 10 months
- 4
- 6
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
>
6 years, 11 months
- 1
- 0
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?
6 years, 11 months
- 2
- 1
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=ult...
>
>>
>> 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
7 years
- 1
- 0
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.
7 years
- 5
- 9
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.
7 years
- 2
- 2
[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;
7 years
- 1
- 0
[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
7 years
- 1
- 0
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.
7 years
- 2
- 1
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>
7 years
- 1
- 0