command line parameters

[nir levy]

Thanks for the info. it was really helpful.
The address of 0x2000 was not the correct one but i used your trick ( 
which i should think of myself :) )  to scan the memory
and locat the correct address where grub puts the program name and the 
command line parameters.

Thanks again,
Nir

Till Straumann wrote:
> IIRC, GRUB stores the command line at physical address 0x2000
> which (again, IIRC) is not touched by RTEMS so you can do the
> ugly trick:
>
> const char *grub_cmdline_hack = (const char *)0x2000;
>
> Beware, it is probably not \0 terminated and I don't remember
> if it is an 'official' feature...
>
> I don't remember if GRUB supports multiboot. A cleaner method
> lets early BSP startup code use info from the multiboot record
> (small mod to start.S and bspstart.c required). This works for me
> in combination with etherboot. I can provide a patch if anyone is
> interested.
>
> HTH
> -- Till
>
> Joel Sherrill wrote:
>> nir levy wrote:
>>  
>>> Hi All,
>>>
>>> I am running RTEMS on QEMU emulator and i am using grub for booting 
>>> ( similar to most descriptions on the net for doing so).
>>> However, i could not find a way to send command line parameters for 
>>> the RTEMS applications i am running.
>>> I have tried to specified them in the GRUB configuration file ( 
>>> after the program name) but they don't seem to be pass to the 
>>> application in the Init procedure ( i have checked the c_rtems_main 
>>> and the procedure in the boot_card and they don't get there as 
>>> well). I assume the problem might be in the grub but if anyone ever 
>>> succeed doing it and can help me with that or advice on the issue it 
>>> will be nice.
>>>       
>> There is no main() in an RTEMS application.  So the idea of
>> what to do with command line parameters is a bit vague.
>>
>> Some boot loaders pass in a pointer to a data structure which
>> is used by the BSP.  U-Boot comes to mind in this case.
>>
>> Right now, it is the responsibility of the BSP early start
>> code (usually named start.S) to invoke boot_card() with
>> argc, argv, and environ.  Right now, this information disappears
>> in boot_card() because there is no defined way to make it
>> available to the application.
>>
>> I looked at this a while back and didn't have any real
>> example invoking environments to test with so left it
>> alone.  My thoughts were:
>>
>> + conditional compile argc, argv support in bootcard.c
>>     since it is unused baggage for most BSPs.  BSPs which
>>     want to and can support argc, argv can enable it.
>>
>> + Define a set of public variables which are the
>>    bsp or boot argc, argv, and environ values.
>>
>> Getting the info from grub to pc386's start code
>> and to boot_card() makes it possible to address the
>> more general issue of what to do with them when they
>> are available.
>>
>> I hope this has encouraged you to modify the BSP
>> to transfer the info from grub through start.S to
>> boot_card and help define the mechanism. :-D
>>
>> FWIW another way I have seen is to prompt a user
>> for command line arguments.  Then convert that
>> string into argc/argv format to pass into a
>> main that was renamed to XXX_main().  This is a
>> relatively painless way to port UNIX main()'s to
>> RTEMS especially for testing purposes.  I am
>> thinking that since at least ttcp has code already
>> to do this and I have copied it at least once, that
>> is makes sense to generalize it and make it
>> part of libmisc.
>>
>> --joel
>>
>>  
>>> Thanks in advance.
>>>
>>> Best,
>>> Nir
>>>
>>> _______________________________________________
>>> rtems-users mailing list
>>> rtems-users at rtems.com
>>> http://rtems.rtems.org/mailman/listinfo/rtems-users
>>>       
>>
>> _______________________________________________
>> rtems-users mailing list
>> rtems-users at rtems.com
>> http://rtems.rtems.org/mailman/listinfo/rtems-users
>>   
>
>
>