[SeaBIOS] non-emulated AHCI hardware

Kevin O'Connor kevin at koconnor.net
Tue Apr 26 01:38:33 CEST 2011


On Mon, Apr 25, 2011 at 05:31:36PM -0500, Scott Duplichan wrote:
> Peter Stuge wrote:
> 
> ]Still it's not nice to write outside the callers buffer. Another OS
> ]might call same function and SeaBIOS would end up corrupting some
> ]variable. Ungood. I guess memmove() is the only choice?
> 
> ]//Peter
> 
> I had a couple of ideas for a more sound solution.

This came up for DMA on IDE too.  What I did there was just fallback
to PIO if the buffer was not aligned.

Out of curiosity, can you see what happens if you return
DISK_RET_EBOUNDARY in the unaligned case?

>Debugging them is
> a challenge for me because I am new to seabios development and its
> method for writing code that works correctly in both 16-bit and
> 32-bit mode. Anyway, the first method I tried was to allocate a 
> temporary I/O buffer that has the proper alignment. While that
> creates overhead, it would only be invoked in the rare case of
> unaligned request. But then there is the possibility that the
> allocation function will not be able to satisfy the request.

It's not currently possible to dynamically allocate memory during
runtime.  However, it is possible to allocate a buffer at init and
keep it around for later.  How big of a buffer would you need?

Since several devices require DMA buffers, I had thought of adding
code for a low-memory dma pool.  I never got around to it though.

> Another possibility is splitting the request. The caller's buffer
> could handle the bigger part, and a stack buffer could be used for
> the remaining part.

The stack is only 512 bytes (for disk ops) so you don't have that much
space.

>Yet another possibility is to backup the byte
> that gets overwritten by the current patch method and restore it
> afterwards. While that is an unreliable method for paged code, it
> might work here. The only danger I can think of is if the caller's
> buffer is at the end of a physical DRAM range.

That seems fragile.

Thanks,
-Kevin



More information about the SeaBIOS mailing list