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