OpenBIOS May 2010

openbios@openbios.org

15 participants
48 discussions

starting
by G 3 18 Oct '10

18 Oct '10

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.

6 17

Solaris 9: failed boot with strange device names
by Mark Cave-Ayland 25 Aug '10

25 Aug '10

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

3 10

/packages/disk-label, /packages/sun-parts and /packages/misc-files
by Mark Cave-Ayland 08 Jun '10

08 Jun '10

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

2 4

Re: [OpenBIOS] /packages/disk-label, /packages/sun-parts and /packages/misc-files
by Laurent Vivier 03 Jun '10

03 Jun '10

>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

3 4

[PATCH 0/3] sparc64 cleanups v1
by Igor V. Kovalenko 01 Jun '10

01 Jun '10

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

6 15

Re: [OpenBIOS] /packages/disk-label, /packages/sun-parts and /packages/misc-files
by Mark Cave-Ayland 28 May '10

28 May '10

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

1 0

Re: [OpenBIOS] [PATCH 0/3] sparc64 cleanups v1
by Mark Cave-Ayland 28 May '10

28 May '10

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

1 0

[PATCH 00/10] encode-int related changes and pci bus scan amendment
by Igor V. Kovalenko 27 May '10

27 May '10

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(-) --

5 19

[commit] r790 - trunk/openbios-devel/drivers
by repository service 27 May '10

27 May '10

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; } }

1 0

[commit] r789 - trunk/openbios-devel/drivers
by repository service 27 May '10

27 May '10

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],

1 0