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,

[SeaBIOS] non-emulated AHCI hardware

2011-02-12 Thread Jonathan A. Kollasch
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, SeaBIOS's AHCI driver just falls into a dead loop waiting for commands to complete.