[U-Boot] Implementing the uBoot SYSCALL interface for MIPS

[Daniel Schwierzeck]

Hi Matthew,

On 17.12.2014 01:07, Matthew Fortune wrote:
> Hi Daniel,
> 
> I'm looking for a bit of feedback on my query below.  Unless there is a
> major problem I'll start to organise an implementation for review.
> 
> Thanks,
> Matthew
> 
>> -----Original Message-----
>> From: Matthew Fortune
>> Sent: 08 December 2014 12:43
>> To: 'u-boot at lists.denx.de'
>> Subject: Implementing the uBoot SYSCALL interface for MIPS
>>
>> Hi all,
>>
>> I've been recently working on and promoting a common bare-metal semi-
>> hosting interface for the MIPS architecture. The main goal of this is to
>> allow a bare-metal MIPS application to run on the maximum number of
>> simulation and hardware platforms without (much/any) modification. The
>> interface uses the MIPS SYSCALL interface and a custom ABI to request
>> operations from an OS or monitor.

do you have publicly available documents somewhere? I guess the syscalls
will be routed through a handler for the MIPS debug exception?

>>
>> As far as I can see uBoot's new(ish) API as not yet been mapped onto the
>> MIPS architecture. I would like to find out if it will be acceptable to
>> access some map some of the operations from the semi-hosting interface
>> onto the uBoot API.

Of course it is acceptable as long as the code is configurable and
optional. Also I can see that ARM already implementes a minimal
semihosting mapping.

>>
>> In particular I'd like to get: open, read, write, close, fstat
>> implemented such that FD 0/1 behave as if attached to a serial port.
>> Open/close and fstat wouldn't do anything special as they would just say
>> that FD 0/1 exist.
>> Read and write would map to getc and putc for FD 0 and FD 1
>> respectively.

as noted above ARM already has all such syscalls (except fstat)
implemented in arch/arm/lib/semihosting.c which can serve as an example

>>
>> The interface is being implemented directly in qemu, and as part of
>> libgloss on the consumer side (not upstream yet). I will be promoting
>> its use in any other open source simulators and hosting libraries too as
>> I find them. I'm also boldly trying to abstract away from any ABI issues
>> (O32/N32/N64) to potentially allow the consumer and producer side of the
>> interface to have different ABIs to some extent. I am also trying to
>> create a well-defined entry-point interface to reduce the variance in
>> how arguments are passed from bootloader to application, at least one
>> person has shown interest in this from the kernel list.
>>
>> If it sounds like it will be acceptable then I'll send more details of
>> the interface as a follow up but I would really like to include uBoot in
>> the list of supported environments. There is of course scope to add any
>> number of extra operations to the interface to cover more of the uBoot
>> API but I generally agree with the principle that exploiting too much of
>> uBoot is bad form if an application is non-GPL.
>>
>> Thanks,
>> Matthew

-- 
- Daniel