Author: afaerber
Date: Fri Dec 17 15:25:14 2010
New Revision: 985
URL: http://tracker.coreboot.org/trac/openbios/changeset/985
Log:
ppc: unexpected_excep() needs an absolute branch
When called from address 0x700, trap_error must not use a relative branch
to unexpected_excep() since that is beyond __vectors_end.
Signed-off-by: Andreas Färber <andreas.faerber(a)web.de>
Modified:
trunk/openbios-devel/arch/ppc/qemu/start.S
Modified: trunk/openbios-devel/arch/ppc/qemu/start.S
==========…
[View More]====================================================================
--- trunk/openbios-devel/arch/ppc/qemu/start.S Sun Dec 12 21:09:49 2010 (r984)
+++ trunk/openbios-devel/arch/ppc/qemu/start.S Fri Dec 17 15:25:14 2010 (r985)
@@ -288,7 +288,9 @@
_GLOBAL(__divide_error):
trap_error:
mflr r3
- b BRANCH_LABEL(unexpected_excep)
+ LOAD_REG_FUNC(r4, unexpected_excep)
+ mtctr r4
+ bctr
VECTOR( 0x100, "SRE" ):
b _entry
[View Less]
On Wed, Dec 8, 2010 at 11:34 AM, Gleb Natapov <gleb(a)redhat.com> wrote:
> Forget to save a couple of buffers before sending version 7 :(
>
> Anthony, Blue can this be applied now?
I made some more tests, this time with PPC. I modified OpenBIOS to
print out the boot device list:
$ qemu-system-ppc -drive if=none,id=hda,file=/dev/null -device
ide-drive,drive=hda,bootindex=1 -drive if=none,id=cd,file=/dev/null
-device ide-drive,drive=cd,bootindex=0 -nographic -prom-env
'auto-boot?=…
[View More]false' -L .
qemu-system-ppc: pci_add_option_rom: failed to find romfile "vgabios-stdvga.bin"
Could not open option rom 'pxe-ne2k_pci.bin': No such file or directory
>> =============================================================
>> OpenBIOS 1.0 [Nov 28 2010 19:37]
>> Configuration device id QEMU version 1 machine id 2
>> CPUs: 1
>> Memory: 128M
>> UUID: 00000000-0000-0000-0000-000000000000
>> CPU type PowerPC,750
>> bootindex /grackle@fec00000/ide@3/drive@1/disk@1
>> /grackle@fec00000/ide@3/drive@1/disk@0
Welcome to OpenBIOS v1.0 built on Nov 28 2010 19:37
0 > show-devs
7be6324 /
7be6440 /aliases
7be64e4 /openprom (BootROM)
7bebfa0 /openprom/client-services
7be668c /options
7be6704 /chosen
7be67e8 /builtin
7be688c /builtin/console
7bebcac /packages
7becda8 /packages/cmdline
7becee8 /packages/disk-label
7bedb58 /packages/terminal-emulator
7bee548 /packages/deblocker
7bee89c /packages/hfsplus-files
7beeb3c /packages/hfs-files
7beedd8 /packages/ext2-files
7bef010 /packages/iso9660-files
7bef248 /packages/grubfs-files
7bef480 /packages/mac-parts
7bef6b8 /packages/pc-parts
7bef8ec /packages/xcoff-loader
7bef9b8 /packages/elf-loader
7befa80 /packages/bootinfo-loader
7bed958 /cpus
7bf2fe8 /cpus/PowerPC,750@0 (cpu)
7beda58 /memory@0 (memory)
7befb4c /pci@80000000 (pci)
7beff64 /pci@80000000/QEMU,VGA@1 (display)
7bf0438 /pci@80000000/NE2000@2 (network)
7bf0814 /pci@80000000/pci-ata@3 (pci-ide)
7bf0c50 /pci@80000000/pci-ata@3/ata-1@500 (ata)
7bf0dd0 /pci@80000000/pci-ata@3/ata-2@600 (ata)
7bf0f50 /pci@80000000/pci-ata@3/ata-2@600/disk@1 (block)
7bf131c /pci@80000000/pci-ata@3/ata-2@600/disk@0 (block)
7bf1674 /pci@80000000/mac-io@4 (mac-io)
7bf1b54 /pci@80000000/mac-io@4/via-cuda@16000 (via-cuda)
7bf1d70 /pci@80000000/mac-io@4/via-cuda@16000/adb (adb)
7bf1ed8 /pci@80000000/mac-io@4/via-cuda@16000/adb/keyboard@8 (keyboard)
7bf2080 /pci@80000000/mac-io@4/via-cuda@16000/adb/mouse@9 (mouse)
7bf220c /pci@80000000/mac-io@4/via-cuda@16000/rtc (rtc)
7bf23f4 /pci@80000000/mac-io@4/nvram@60000 (nvram)
7bf2614 /pci@80000000/mac-io@4/escc@13000 (escc)
7bf271c /pci@80000000/mac-io@4/escc@13000/ch-a@13020 (serial)
7bf29b4 /pci@80000000/mac-io@4/escc@13000/ch-b@13000 (serial)
7bf2c20 /pci@80000000/mac-io@4/ata-3@20000 (ata)
ok
/grackle@fec00000/ide@3/drive@1/disk@1 does not match
/pci@80000000/pci-ata@3/ata-2@600/disk@1.
I wonder where '@80000000' comes from. A dump of original g3beige
device tree is here:
http://penguinppc.org/historical/dev-trees-html/g3_beige_300.html
But actually the tree generated by OpenBIOS looks more like g3bw one:
http://penguinppc.org/historical/dev-trees-html/g3bw_400.html
How can we get the names to be more compatible? At least
s/grackle/pci/ is easy to do in QEMU, but which instance (QEMU or
OpenBIOS) should handle pci-ata vs ide change? What should we do with
ata-2@600 vs drive@1?
[View Less]
Hello,
With or without the pending ofmem patches, ppc64 boot currently hangs
after "Trying cd:,\\:tbxi..." (before "Trying cd:,\ppc\chrp
\bootfile.exe...").
Symptom is, 0x700 program exception vector (not 0xfff00700) is being
called with SRR1 pointing to some address that's neither in the low
vectors range nor in OpenBIOS itself apparently.
I noticed that branching relatively to unexpected_excep from there is
wrong and patched it to bctr there (which unfortunately appears to
break …
[View More]32-bit ppc64), but usually it does not manage to properly do the
printk()
Here's what I found out so far:
* a breakpoint for bootinfo_loader_init() or so is not reached
* The "Trying" comes from (encode-bootpath) in forth/debugging/client.fs
* `debug (encode-bootpath) boot` does not return from open-dev
* `debug open-dev` does not return from path-resolution
* path-resolution gets called "endlessly" (5+ times single-stepping
it), the hang occurred after successfully returning from some instance
(after having successfully done so for a previous instance)
Does anyone have a hunch what might be going wrong? Or tips how to
further debug?
Thanks,
Andreas
[View Less]
Display one MMU translation per row for .properties command.
Signed-off-by: Andreas Färber <andreas.faerber(a)web.de>
---
forth/admin/devices.fs | 28 ++++++++++++++++++++++++++++
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/forth/admin/devices.fs b/forth/admin/devices.fs
index 7a5b693..00b4f55 100644
--- a/forth/admin/devices.fs
+++ b/forth/admin/devices.fs
@@ -326,6 +326,30 @@
3drop drop
;
+\ Print the value of the MMU translations property
+: .p-…
[View More]translations ( data len -- )
+ 2dup + -rot ( data+len data len )
+ >r >r [IFDEF] CONFIG_PPC
+ [IFDEF] CONFIG_PPC64 5 [ELSE] 4 [THEN]
+ [ELSE]
+ 3
+ [THEN] 4 * dup ( data+len #bytes #bytes R: len data ) r> r>
+ bounds ( data+len #bytes #bytes data+len data ) ?do
+ 2dup <> if \ non-first byte in row
+ dup 3 and 0= if space then \ make numbers more readable
+ then
+ i c@ 2 0.r \ print byte
+ 1- dup 0= if \ end of row
+ 2 pick i 1+ > if \ non-last byte
+ cr \ start new line
+ d# 26 spaces \ indentation
+ then
+ drop dup \ update counter
+ then
+ loop
+ 2drop drop
+;
+
\ This function hardwires data formats to particular node properties
: (.property-by-name) ( name-str name-len data len -- )
2over " reg" strcmp 0= if
@@ -346,6 +370,10 @@
1 1 2swap .p-reg
2drop exit
then
+ 2over " translations" strcmp 0= if
+ .p-translations
+ 2drop exit
+ then
then
then
then
--
1.7.3
[View Less]
Author: afaerber
Date: Sun Dec 12 21:09:49 2010
New Revision: 984
URL: http://tracker.coreboot.org/trac/openbios/changeset/984
Log:
forth: Fix MMU available pretty-printing for sparc64
On sparc64 a virtual address or size value is contained within one stack cell
but that makes two property cells. The columns for the /virtual-memory
"available" property thus looked wrong.
Do read the number of cells from #address-cells but make sure the size is
at least one to not break ppc.
Cc: Tarl …
[View More]Neustaedter <tarl-b2(a)tarl.net>
Signed-off-by: Andreas Färber <andreas.faerber(a)web.de>
Modified:
trunk/openbios-devel/forth/admin/devices.fs
Modified: trunk/openbios-devel/forth/admin/devices.fs
==============================================================================
--- trunk/openbios-devel/forth/admin/devices.fs Sun Dec 12 21:08:25 2010 (r983)
+++ trunk/openbios-devel/forth/admin/devices.fs Sun Dec 12 21:09:49 2010 (r984)
@@ -408,7 +408,7 @@
" mmu" rot get-package-property 0= if
decode-int nip nip ihandle>phandle active-package = if
2over " available" strcmp 0= if
- 1 1 2swap .p-reg
+ my-#acells my-#scells 1 max 2swap .p-reg
2drop exit
then
2over " translations" strcmp 0= if
[View Less]
Hi all,
Here is my first attempt at switching over OFMEM to use phys_addr_t for
physical addresses. It was mainly a case of going through all of the
OFMEM APIs by hand and then updating the definitions used to hold
physical addresses, along with swapping over range_t to use phys_addr_t
on the assumption that sizeof(phys_addr_t) >= sizeof(ucell).
Andreas - note I've not touched anything in ppc64 as I figure this is
still experimental and I don't really have anything to test it with.
…
[View More]This patch seems to work on my SPARC64/PPC tests here, but since it
touches a core part of OpenBIOS I'd like to get a little more feedback
before committing it.
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
[View Less]