[OpenBIOS] [commit] r832 - in trunk/openbios-devel: arch/sparc32 drivers

[Blue Swirl]

On Wed, Aug 4, 2010 at 4:47 PM, Artyom Tarasenko
<atar4qemu at googlemail.com> wrote:
> 2010/8/4 Blue Swirl <blauwirbel at gmail.com>:
>> On Wed, Aug 4, 2010 at 10:32 AM, Mark Cave-Ayland
>> <mark.cave-ayland at siriusit.co.uk> wrote:
>>> repository service wrote:
>>>
>>>> Log:
>>>> sparc32: fix pre-loaded kernel command line
>>>>
>>>> Fix more breakage from r828:
>>>>
>>>> For some reason, QEMU/Sparc32 does not set FW_CFG_CMDLINE_SIZE, so
>>>> we have to use FW_CFG_KERNEL_CMDLINE instead.
>>>>
>>>> Setup romvec obp_arg.argv[1] and "boot-file" property.
>>>>
>>>> Remove obsolete command line setup code from obio.c.
>>>
>>> Looks good to me.
>>>
>>> Just for the record, with r828 the way that bootpath/bootargs should now
>>> work is as follows:
>>>
>>> - All Qemu configuration should now take place in the arch_init() (or
>>> equivalent) function only
>>>
>>> - arch_init() should read the Qemu firmware device and setup the NVRAM
>>> variables boot-device and boot-file (boot-device can now take a list of
>>> space-separated devices to search - see ppc/qemu for an example of this)
>>>
>>> - Everything else is now magically handled by Forth in (encode-bootpath)
>>> based upon the following rules from the IEEE-1275 spec:
>>>
>>>    - If either "load" or "boot" are issued on their own, search through
>>>    each boot-device in order until open returns a valid ihandle, then
>>>    load/boot from this. bootargs is set to the contents of boot-file.
>>
>> Does not work:
>> Trying cdrom...
>> Not a bootable ELF image
>> Not a bootable a.out image
>> No valid state has been set by load or init-program
>>
>> 0 > printenv
>> name                      "options"
>> boot-from                 "disk"
>> boot-args                 ""
>> boot-device               "cdrom cdrom:d"
>> use-generic?              "false"
>> boot-script               ""
>> boot-screen               ""
>> ttyb-rts-dtr-off          "false"
>> ttyb-ignore-cd            "true"
>> ttyb-mode                 "9600,8,n,1,-"
>> ttya-rts-dtr-off          "false"
>> ttya-ignore-cd            "true"
>> ttya-mode                 "9600,8,n,1,-"
>> tpe-link-test?            "true"
>> load-base                 "4000"
>> scroll-lock               "true"
>> skip-netboot?             "false"
>> default-mac-address       "false"
>> pci-probe-mask            "-1"
>> selftest-#megs            "0"
>> screen-#rows              "24"
>> screen-#columns           "80"
>> output-device             "ttya"
>> input-device              "ttya"
>> use-nvramrc?              "false"
>> oem-logo?                 "false"
>> oem-banner                ""
>> oem-banner?               "false"
>> nvramrc                   ""
>> fcode-debug?              "false"
>> diag-switch?              "false"
>> boot-file                 ""
>> boot-command              "boot"
>> auto-boot?                "true"
>>  ok
>> 0 > boot
>> Trying cdrom...
>> Not a bootable ELF image
>> Not a bootable a.out image
>> No valid state has been set by load or init-program
>>  ok
>> 0 > boot cdrom:d
>> Not a bootable ELF image
>> Loading a.out image...
>> Loaded 65536 bytes
>> entry point is 0x4000
>> bootpath: /iommu/sbus/espdma/esp/sd at 2,0:d
>>
>> Jumping to entry point 00004000 for type 00000005...
>> switching to new context:
>>>> NetBSD/sparc Secondary Boot, Revision 1.12
>>>> (autobuild at tgm.daemon.org, Wed Apr  9 02:46:11 UTC 2003)
>> Booting netbsd
>>
>> I changed the boot-device like this:
>> diff --git a/arch/sparc32/openbios.c b/arch/sparc32/openbios.c
>> index 60ee180..3624269 100644
>> --- a/arch/sparc32/openbios.c
>> +++ b/arch/sparc32/openbios.c
>> @@ -187,11 +187,11 @@ arch_init( void )
>>                push_str("floppy");
>>                break;
>>        case 'c':
>> -               push_str("disk");
>> +                push_str("disk disk:d");
>>                break;
>>        default:
>>        case 'd':
>> -               push_str("cdrom");
>> +                push_str("cdrom cdrom:d");
>
> Why not make cdrom an alias to the slice d, as OBP does?

IIRC that approach had other problems. I'll try if this is no longer the case.