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