starting
by G 3
I have begun doing work with OpenBIOS. I was wondering if it is
possible to compile OpenBIOS for PowerPC on Mac OS X? If not, what
Linux distro should I use? Any advice would really help.
9 years, 8 months
- 6
- 17
Solaris 9: failed boot with strange device names
by Mark Cave-Ayland
Hi all,
So given that the Fcode evaluator is sorted for Solaris 10, I thought
I'd try my original Solaris 9 disk image again and was surprised to find
that it didn't boot.
Further investigation seems to show that strangely encoded device names
are being passed into cif-open which is failing:
: get-file ( 6000 ffe35870 27 )
00000000ffe36378: fname>devname$
3 > 2dup type /platform/OpenBiosTeam,OpenBIOS/ufsboot ok
3 > resume ok
( 6000 ffe35870 27 )
00000000ffe36378: fname>devname$ ( 6000 ffe35ee8 2f )
00000000ffe36380: ufs-fopen
3 > 2dup type cdrom:a,|platform|OpenBiosTeam,OpenBIOS|ufsboot ok
3 > resume ok
( 6000 ffe35ee8 2f )
00000000ffe36380: ufs-fopen
: ufs-fopen ( 6000 ffe35ee8 2f )
00000000ffe360e8: drop ( 6000 ffe35ee8 )
00000000ffe360f0: cif-open ( 6000 0 )
00000000ffe360f8: (semis)
: get-file ( 6000 ffe35870 17 )
00000000ffe36378: fname>devname$
3 > 2dup type /platform/sun4u/ufsboot ok
3 > resume ok
( 6000 ffe35870 17 )
00000000ffe36378: fname>devname$ ( 6000 ffe35ee8 1f )
00000000ffe36380: ufs-fopen
3 > 2dup type cdrom:a,|platform|sun4u|ufsboot ok
3 > resume ok
( 6000 ffe35ee8 1f )
00000000ffe36380: ufs-fopen
: ufs-fopen ( 6000 ffe35ee8 1f )
00000000ffe360e8: drop ( 6000 ffe35ee8 )
00000000ffe360f0: cif-open OFMEM: ofmem_claim_virt virt=ffffffffffffffff
size=0000000000000200 align=0000000000000001
( 6000 0 )
00000000ffe360f8: (semis)
It looks as if a special type of device-specifier is being passed into
cif-open consisting of a device and argument, a comma, then the actual
filename required with /s replaced by |s.
Is this some kind of special syntax that needs to be taught to the dev
word and/or cif-open words?
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
9 years, 10 months
- 3
- 10
/packages/disk-label, /packages/sun-parts and /packages/misc-files
by Mark Cave-Ayland
Hi folks,
Is there some kind of specification for the above packages or are we
free to design the interface as we choose? The reason I ask is that the
current interposition order doesn't seem to be particularly logical. At
the moment, the order goes like this for a CDROM:
cdrom -> deblocker -> disk-label -> (misc-files or sun-parts or pc-parts)
But I think it makes more sense to do this:
cdrom -> deblocker -> disk-label -> (sun-parts or pc-parts) -> misc-files
The reason for suggesting a change is because by placing misc-files
directly after disk-label, all partition offsets have to be bubbled back
up the chain using a series of get-info words to the device. If this
could be reordered, it should be possible to remove most of this logic
and simply pass the read/seeks back up to the parent.
Otherwise, like at the moment, there is lots of code in misc-files that
has to work out whether you are accessing a file or a partition directly
and act differently which can't be a good thing.
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
10 years
- 2
- 4
Re: [OpenBIOS] /packages/disk-label, /packages/sun-parts and /packages/misc-files
by Laurent Vivier
>Mark Cave-Ayland wrote:
>
>> Hi folks,
>>
>> Is there some kind of specification for the above packages or are we
>> free to design the interface as we choose? The reason I ask is that the
>> current interposition order doesn't seem to be particularly logical. At
>> the moment, the order goes like this for a CDROM:
>>
>> cdrom -> deblocker -> disk-label -> (misc-files or sun-parts or pc-parts)
>>
>> But I think it makes more sense to do this:
>>
>> cdrom -> deblocker -> disk-label -> (sun-parts or pc-parts) -> misc-files
>>
Moreover, I think ext2, hfs, hfsplus, iso9660 can be moved to their own packages (as it is done on macintosh new world openfirmware). I have a patch on my disk doing this for ISO9660 (not sure) but it is 7 months old and I don't know if it applies (and works) anymore.
Regards,
Laurent
--
--------------------- Laurent(a)vivier.eu ---------------------
"Tout ce qui est impossible reste à accomplir" Jules Verne
"Things are only impossible until they're not" Jean-Luc Picard
10 years, 1 month
- 3
- 4
[PATCH 0/3] sparc64 cleanups v1
by Igor V. Kovalenko
One code cleanup and another pci host bridge remap change,
the latter requires qemu update with patch already posted to qemu list.
v0->v1: added missing patch moving asi.h to arch includes
---
Igor V. Kovalenko (3):
sparc64: move asi.h to arch includes
sparc64: replace ASI numbers with macros
sparc64: fix pci host bridge offsets
arch/sparc64/asi.h | 145 --------------------------------------------
arch/sparc64/entry.S | 2 -
arch/sparc64/openbios.c | 12 ++--
arch/sparc64/spitfire.h | 2 -
arch/sparc64/switch.S | 2 -
arch/sparc64/vectors.S | 2 -
include/arch/sparc64/asi.h | 145 ++++++++++++++++++++++++++++++++++++++++++++
include/arch/sparc64/io.h | 61 ++++++++++++-------
8 files changed, 196 insertions(+), 175 deletions(-)
delete mode 100644 arch/sparc64/asi.h
create mode 100644 include/arch/sparc64/asi.h
--
Signature
10 years, 1 month
- 6
- 15
Re: [OpenBIOS] /packages/disk-label, /packages/sun-parts and /packages/misc-files
by Mark Cave-Ayland
Laurent Vivier wrote:
> In this cas are you able to manage disk with no partition table ?
In my current patch set, if no partition table is found then all I do is
interpose misc-files under disk-label. As long as we bubble back up the
packages methods, no changes are required.
> Could you have a look to "CHRP binding" document, I think it describes some behaviors about this ?
No, this is great! According to p.59 or thereabouts, disk-label
conditionally interposes the filesystem package depending upon what it
finds. This was the main part of the patch I was unsure about. I notice
there is no mention of the sun-parts or pc-parts packages though; does
anyone know where there is a copy of the SPARC platform bindings for
more information?
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
10 years, 1 month
- 1
- 0
Re: [OpenBIOS] [PATCH 0/3] sparc64 cleanups v1
by Mark Cave-Ayland
Igor Kovalenko wrote:
> Atomic quad ldda is indeed implemented by separate helper_ldda_asi not
> helper_ld_asi as I expected.
> With a bit more debugging it turns out that issue happens if MMU
> primary context is not zero!
>
> IN:
> 0x0000000000424d18: ldda [ %g1 ] #ASI_NUCLEUS_QUAD_LDD, %g4
> 0x0000000000424d1c: cmp %g4, %g6
> 0x0000000000424d20: bne,pn %xcc, 0x4076c0
> 0x0000000000424d24: mov 2, %g3
>
> MMU: get_physical_address DATA tl=5 mmu_idx=2 primary context=1
> secondary context=1 address=8000000
> MMU: DMISS at 8000000 context 1
> --- do_interrupt tl=5
> 948404: Data Access MMU Miss (v=0068) pc=0000000000424d18
> npc=0000000000424d1c SP=00000000ffba1ef0
> pc: 0000000000424d18 npc: 0000000000424d1c
> General Registers:
> %g0-3: 0000000000000000 0000000008000000 0000000000004000 0000000000000002
> %g4-7: 00000000000003fe 0000000000000001 0000000000000020 0000000000004000
>
> So helper_ldda_asi must be changed to do loads from NUCLEUS (0) context.
> I'll post a patch now but with that applied I see no crash but not
> that much progress either.
Okay; I've just tried your patch and the crash is gone :)
However, the boot now seems to freeze with "su: Cannot register IRQ 0"
which didn't happen before the recent PCI fixes. I think that maybe
another bug is being triggered somewhere now that the PCI bus is being
handled more correctly.
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
10 years, 1 month
- 1
- 0
[PATCH 00/10] encode-int related changes and pci bus scan amendment
by Igor V. Kovalenko
These mostly are cleanups up to pci bus scan amendment changes.
The pci bus scan is reworked, now we start with pci host bridge which will
initiate primary bus scan. PCI-to-PCI bridges do the same.
Although bridges are still mostly unusable in qemu due to missing address space
remappings one can now put e.g. ide and vga on sun4u behind secondary bus and
see it is found correctly and can be configured.
With these applied my debian etch ppc installation still boots to shell,
and helenos can get to video screen (with appropriate QEMU,VGA driver.)
Another bonus point that on sparc64 recent linux "btext" boot console works
(colors are a bit off though.)
---
Igor V. Kovalenko (10):
ebus: set addressing to 2 address cells and 1 size cells
ide: fix property data size
video: framebuffer properties must be 32bit values
pci: property encoding helpers
pci: debug printk macros
pci: bus scan amendment
new style arch declarations for ppc/qemu
pci: add host memory base to pci_arch_t
pci: allow BARs with zero assigned address
pci: assign relocatable address ranges
arch/ppc/qemu/init.c | 96 ++++--
arch/sparc64/openbios.c | 3
drivers/ide.c | 22 +
drivers/pci.c | 652 +++++++++++++++++++++++++++-------------
drivers/pci.h | 4
drivers/pci_database.c | 2
drivers/pci_database.h | 3
drivers/vga_vbe.c | 8
include/drivers/pci.h | 3
include/libopenbios/bindings.h | 8
libopenbios/bindings.c | 6
packages/video.c | 10 -
12 files changed, 549 insertions(+), 268 deletions(-)
--
10 years, 1 month
- 5
- 19
[commit] r790 - trunk/openbios-devel/drivers
by repository service
Author: blueswirl
Date: Thu May 27 22:12:26 2010
New Revision: 790
URL: http://tracker.coreboot.org/trac/openbios/changeset/790
Log:
pci: assign relocatable address ranges
Signed-off-by: Igor V. Kovalenko <igor.v.kovalenko(a)gmail.com>
Signed-off-by: Blue Swirl <blauwirbel(a)gmail.com>
Modified:
trunk/openbios-devel/drivers/pci.c
Modified: trunk/openbios-devel/drivers/pci.c
==============================================================================
--- trunk/openbios-devel/drivers/pci.c Thu May 27 22:12:23 2010 (r789)
+++ trunk/openbios-devel/drivers/pci.c Thu May 27 22:12:26 2010 (r790)
@@ -546,24 +546,24 @@
static inline void pci_decode_pci_addr(pci_addr addr, int *flags,
int *space_code, uint32_t *mask)
{
- if (addr & 0x01) {
+ *flags = 0;
+ if (addr & 0x01) {
*space_code = IO_SPACE;
- *flags = 0;
*mask = 0x00000001;
-
- } else if (addr & 0x04) {
-
- *flags = IS_NOT_RELOCATABLE;
- *space_code = MEMORY_SPACE_64;
- *mask = 0x0000000F;
-
} else {
+ if (addr & 0x04) {
+ *space_code = MEMORY_SPACE_64;
+ *flags |= IS_NOT_RELOCATABLE; /* XXX: why not relocatable? */
+ } else {
+ *space_code = MEMORY_SPACE_32;
+ }
+
+ if (addr & 0x08) {
+ *flags |= IS_PREFETCHABLE;
+ }
- *space_code = MEMORY_SPACE_32;
- *flags = IS_NOT_RELOCATABLE;
- *mask = 0x0000000F;
-
+ *mask = 0x0000000F;
}
}
10 years, 1 month
- 1
- 0
[commit] r789 - trunk/openbios-devel/drivers
by repository service
Author: blueswirl
Date: Thu May 27 22:12:23 2010
New Revision: 789
URL: http://tracker.coreboot.org/trac/openbios/changeset/789
Log:
pci: allow BARs with zero assigned address
- consider only PCI BARs with non-zero region size when pupulating
"reg" and "assigned-addresses" properties
Signed-off-by: Igor V. Kovalenko <igor.v.kovalenko(a)gmail.com>
Signed-off-by: Blue Swirl <blauwirbel(a)gmail.com>
Modified:
trunk/openbios-devel/drivers/pci.c
Modified: trunk/openbios-devel/drivers/pci.c
==============================================================================
--- trunk/openbios-devel/drivers/pci.c Thu May 27 22:12:19 2010 (r788)
+++ trunk/openbios-devel/drivers/pci.c Thu May 27 22:12:23 2010 (r789)
@@ -603,7 +603,8 @@
ncells = 0;
for (i = 0; i < num_bars; i++) {
- if (!config->assigned[i] || !config->sizes[i])
+ /* consider only bars with non-zero region size */
+ if (!config->sizes[i])
continue;
pci_decode_pci_addr(config->assigned[i],
&flags, &space_code, &mask);
@@ -662,7 +663,8 @@
ncells += pci_encode_size(props + ncells, 0);
for (i = 0; i < num_bars; i++) {
- if (!config->assigned[i] || !config->sizes[i])
+ /* consider only bars with non-zero region size */
+ if (!config->sizes[i])
continue;
pci_decode_pci_addr(config->regions[i],
10 years, 1 month
- 1
- 0