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