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
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
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.
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.
>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
>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
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.