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 -- - Daniel _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
