OpenBIOS June 2010

openbios@openbios.org

14 participants
30 discussions

/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

when I push the enter button...
by Programmingkid 07 Jun '10

07 Jun '10

What code starts executing when I push the enter key in an OpenBIOS session? I thought it was interpret, but it isn't.

2 1

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

07 Jun '10

Laurent Vivier wrote: > Yes, I have: I added them last year to be able to manage the "dir" command... (*squints at the code*). Right, I see - the grubfs APIs aren't really designed for directory listings. Okay, I'll leave as it is at the moment. I did have a quick look at whether it would be worth re-syncing with GRUB2, but I think we'd have a licensing issue since GRUB 2 is GPLv3 whereas OpenBIOS is GPLv2. 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] ofmem_claim_phys - out of space
by Nick Couchman 04 Jun '10

04 Jun '10

Hmmm...when I start with -boot d, I get exactly the same output... -Nick >>> Igor Kovalenko 06/03/10 2:12 PM >>> On Thu, Jun 3, 2010 at 6:06 PM, Nick Couchman wrote: > Well, I've followed the traffic on the list quietly for a few months, updating qemu and openbios along the way as things have developed. I figured I'd throw out the error I'm getting, now, when I try to boot Milax 0.3.2 with qemu-system-sparc64 and see if this is expected, something that's in the works, or something that should be fixed. I start with the following command: > > sparc64-softmmu/qemu-system-sparc64 -hda disk0 -cdrom /misc/iso/Solaris/milax032sparc.iso -bios ../openbios-devel/obj-sparc64/openbios-builtin.elf.nostrip -nographic > > and then do a "boot cdrom" at the prompt. Here's the output (no debugging, verbosity, etc. - just normal output): > > OpenBIOS for Sparc64 > Configuration device id QEMU version 1 machine id 0 > kernel cmdline > CPUs: 1 x SUNW,UltraSPARC-IIi > UUID: 00000000-0000-0000-0000-000000000000 > Welcome to OpenBIOS v1.0 built on May 27 2010 20:47 > Type 'help' for detailed information > > [sparc64] Booting file 'disk' with parameters '' > Not a bootable ELF image > Not a Linux kernel image > Not a bootable a.out image > Not a bootable FCode image > Not a bootable ELF image > Not a Linux kernel image > Not a bootable a.out image > Not a bootable FCode image > Unsupported image format > > 0 > boot cdrom > [sparc64] Booting file 'cdrom' with parameters '' > Not a bootable ELF image > Not a Linux kernel image > Not a bootable a.out image > Loading FCode image... > Loaded 7084 bytes > entry point is 0x4000 > > Jumping to entry point 0000000000004000 for type 0000000000000010... > Evaluating FCode... > ofmem_claim_phys - out of space (failed request for 0000000000000000 bytes) > Unhandled Exception 0x0000000008000000 > PC = 0x00000000ffd1020c NPC = 0x00000000ffd10210 > Stopping execution > > Any hints? Any debugging I should turn on to provide more information? Or is there another Solaris-type O/S I should try? That's a bug. Adding "-boot d" to command line helps getting a bit further, whereas in fact there should be no difference between that and "boot cdrom" -- Kind regards, Igor V. Kovalenko -- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you -------- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.

1 0

ofmem_claim_phys - out of space
by Nick Couchman 03 Jun '10

03 Jun '10

Well, I've followed the traffic on the list quietly for a few months, updating qemu and openbios along the way as things have developed. I figured I'd throw out the error I'm getting, now, when I try to boot Milax 0.3.2 with qemu-system-sparc64 and see if this is expected, something that's in the works, or something that should be fixed. I start with the following command: sparc64-softmmu/qemu-system-sparc64 -hda disk0 -cdrom /misc/iso/Solaris/milax032sparc.iso -bios ../openbios-devel/obj-sparc64/openbios-builtin.elf.nostrip -nographic and then do a "boot cdrom" at the prompt. Here's the output (no debugging, verbosity, etc. - just normal output): OpenBIOS for Sparc64 Configuration device id QEMU version 1 machine id 0 kernel cmdline CPUs: 1 x SUNW,UltraSPARC-IIi UUID: 00000000-0000-0000-0000-000000000000 Welcome to OpenBIOS v1.0 built on May 27 2010 20:47 Type 'help' for detailed information [sparc64] Booting file 'disk' with parameters '' Not a bootable ELF image Not a Linux kernel image Not a bootable a.out image Not a bootable FCode image Not a bootable ELF image Not a Linux kernel image Not a bootable a.out image Not a bootable FCode image Unsupported image format 0 > boot cdrom [sparc64] Booting file 'cdrom' with parameters '' Not a bootable ELF image Not a Linux kernel image Not a bootable a.out image Loading FCode image... Loaded 7084 bytes entry point is 0x4000 Jumping to entry point 0000000000004000 for type 0000000000000010... Evaluating FCode... ofmem_claim_phys - out of space (failed request for 0000000000000000 bytes) Unhandled Exception 0x0000000008000000 PC = 0x00000000ffd1020c NPC = 0x00000000ffd10210 Stopping execution Any hints? Any debugging I should turn on to provide more information? Or is there another Solaris-type O/S I should try? Thanks! -Nick -------- This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.

2 1

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

03 Jun '10

>Laurent Vivier wrote: > >> This one compiles and works (on ppc). I have tested with some ISOs >> (Yaboot based, *BSD, haiku, morphos) and some disk images (Quik based >> debians). >> >> Please, test it with your disks. Don't forget: >> >> <option name="CONFIG_ISO9660" type="boolean" value="true"/> >> <option name="CONFIG_FSYS_ISO9660" type="boolean" value="false"/> >> >> Regards, >> Laurent > >Thanks for this Laurent. > >Since most of my testing is currently on SPARC64, I had to fiddle a >little bit with these options enabled as CONFIG_ISO9660 clashes with the >default CONFIG_GRUBFS and CONFIG_FSYS_ISO9660 options. > >Once I managed to build it, I had more of a play and found the in-built >ISO9660 module to be sadly lacking. In particular, it is case-sensitive >with respect to filenames, doesn't handle trailing periods correctly and >has no knowledge of RockRidge extensions compared to the grubfs version >which I fixed in r777. > >Given that the grubfs code also supports a wider variety of filesystems, >I'm quite tempted to rip out ALL the standard OpenBIOS fs drivers and >make use of the grubfs ones instead. Would anyone have any major >objections to this? > Yes, I have: I added them last year to be able to manage the "dir" command... 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

1 0

bug report
by Programmingkid 03 Jun '10

03 Jun '10

Sorry, I meant I had to delete the files in obj-x86/target/kernel.

4 5

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

Bug report
by Programmingkid 01 Jun '10

01 Jun '10

When I make changes to the file kernel/forth.c, the changes don't take effect until I manually delete the files in the folder obj-x86/host/kernel. Any changes make to forth.c should take place immediately after compilation.

1 0