Re: [SeaBIOS] non-emulated AHCI hardware

2011-05-26 Thread Gerd Hoffmann
Hi, Attached is a two part version of the previous patch. Stage1 is enough to get through most OS installs. Stage2 adds unaligned buffer support needed for MS-DOS. Hmm, patch #1 is still a collection of multiple changes, looks a bit like trying this and that until it somehow worked,

Re: [SeaBIOS] non-emulated AHCI hardware

2011-05-26 Thread Scott Duplichan
Gerd Hoffmann wrote: ] Hi, ] ] Attached is a two part version of the previous patch. Stage1 is enough ] to get through most OS installs. Stage2 adds unaligned buffer support ] needed for MS-DOS. ] ]Hmm, patch #1 is still a collection of multiple changes, looks a bit ]like trying this and that

Re: [SeaBIOS] non-emulated AHCI hardware

2011-05-25 Thread Gerd Hoffmann
Thanks Scott, I'd like to commit these fixes. Is there any chance you could break them up into separate patches - one per fix? That would be great for review too. thanks, Gerd ___ SeaBIOS mailing list SeaBIOS@seabios.org

Re: [SeaBIOS] non-emulated AHCI hardware

2011-04-28 Thread Kevin O'Connor
On Tue, Apr 26, 2011 at 09:15:04PM -0500, Scott Duplichan wrote: Kevin O'Connor wrote: ]Out of curiosity, can you see what happens if you return ]DISK_RET_EBOUNDARY in the unaligned case? DOS tries the same request 10 times then ignores the error and continues. Thanks for testing. ]It's

Re: [SeaBIOS] non-emulated AHCI hardware

2011-04-25 Thread Scott Duplichan
Scott Duplichan wrote: ]1) When booting a DOS drive, a disk read error occurs at some point ]after autoexec executes. The revised patch (attached) overcomes this problem. It turns out in the latter stage of booting, DOS makes a couple of INT13 read requests with a buffer that is not word

Re: [SeaBIOS] non-emulated AHCI hardware

2011-04-25 Thread Peter Stuge
Scott Duplichan wrote: ]1) When booting a DOS drive, a disk read error occurs at some point ]after autoexec executes. The revised patch (attached) overcomes this problem. It turns out in the latter stage of booting, DOS makes a couple of INT13 read requests with a buffer that is not word

Re: [SeaBIOS] non-emulated AHCI hardware

2011-04-25 Thread Scott Duplichan
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. Debugging them is a

Re: [SeaBIOS] non-emulated AHCI hardware

2011-04-25 Thread Peter Stuge
Scott Duplichan wrote: 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. I think this idea is by far the best! //Peter ___ SeaBIOS mailing list

Re: [SeaBIOS] non-emulated AHCI hardware

2011-02-17 Thread Jonathan A. Kollasch
On Sat, Feb 12, 2011 at 11:43:24PM +, Jonathan A. Kollasch wrote: Hi, I've been trying SeaBIOS's AHCI driver on AMD SB710 hardware under coreboot. Both AMD's AHCI BIOS and NetBSD's ahcisata(4) drivers are happy enough with the hardware's state after coreboot/SeaBIOS. However,