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

[Matthew Fortune]

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