>
> Well seems to me that if the movement toward "according to the spec"
> is causes a problem then the project as a whole has an issue that
> ought to be worked out.
Actually thinking about this more... I can probally see thier point.
They don't have hardware so implementation of all the flags
>
> they also get kind of sensitive when the fixes for real hardware does not
> quite work right on their virtual hardware.. after all windows xp
> works for them so for them it is "it ain't broke, don't fix" issue.
Well seems to me that if the movement toward "according to the spec"
is caus
now all we need someone to fix the code :-)
Pehaps we could get the bochs people to do it. Some e-mail to them
with our modified routines from ADLO would at least generate some
feeback on what they thought the most "correct" setup is.
better communication between developers of LB and BOCHS would
>
> I still remmber an IDE code that would work with Samsung HDD's but not IBM
> hdd's. So it is possible to have disk/chipset specific code.
Thats buggy IDE hardware either the host chipset or the drive. I've
written lowlevel IDE routines for another project that do direct LBA
sector reads and
So there you go. Bochs shoud be able to be made generic. I think it
is generic right now but I seem to remember that it did some stuff
with delays rather than checking the busy flag and that was the
difference between the ADLO that worked and the latest stuff.
I still remmber an IDE code that wou
> > I don't think so. FILO does it right. Is it chipset specific?
>
> It just uses the generic IDE io interface. No chipset specifics are
> needed for IDE. Booting USB or PCMCIA is a bit trickier though.
>
So there you go. Bochs shoud be able to be made generic. I think it
is generic right
* Richard Smith <[EMAIL PROTECTED]> [050131 17:20]:
> > something I have been wondering. Suppose someone starts working on that
> > IDE driver to fix it for once in bochs bios. Won't we find out that
> > getting it work right is chip-set specific thing?
> >
> > curently bochs bios is based on inte
> something I have been wondering. Suppose someone starts working on that
> IDE driver to fix it for once in bochs bios. Won't we find out that
> getting it work right is chip-set specific thing?
>
> curently bochs bios is based on intel 440fx chipset or some such.
I don't think so. FILO does it
Yes you can do that with ELF.
The big gotcha is going to be that there are pirq tables current
stored at 0xf that you are not going to want to stomp.
Actually thats not that much of an issue. It currently stomps it already
ADLO has that table broken out into a single binary file. All I do is
c
Richard Smith <[EMAIL PROTECTED]> writes:
> > Yes you can do that with ELF.
> >
> > The big gotcha is going to be that there are pirq tables current
> > stored at 0xf that you are not going to want to stomp.
>
> Actually thats not that much of an issue. It currently stomps it already
>
> AD
> Yes you can do that with ELF.
>
> The big gotcha is going to be that there are pirq tables current
> stored at 0xf that you are not going to want to stomp.
Actually thats not that much of an issue. It currently stomps it already
ADLO has that table broken out into a single binary file. Al
Adam Sulmicki <[EMAIL PROTECTED]> writes:
> On Wed, 26 Jan 2005, Richard Smith wrote:
> > I wonder if we could not just set things up where the ELF loader just
> > loas it into the right spot in the first place. Perhaps that
> > overwrites where the ELF code lives?
>
> if the ram/shadowing was s
But I actually think that is overkill. v2 by default and design
enables all of the shadow ranges as memory. So we just need to
use those ranges. That should be much easier having to patch
ADLO each time. It is fairly unlikely a writable ROM segment is
going to break anything.
FWIW, I actually d
On Wed, 26 Jan 2005, Richard Smith wrote:
http://cvs.sourceforge.net/viewcvs.py/freebios/freebios/util/ADLO/loader.s?rev=1.1&view=auto
it mentions sources as 0x8000 and 0x18000, so I guess they have been
aready copied out of rom into the the low memory by linuxbios ???
(i think that's part
>
> http://cvs.sourceforge.net/viewcvs.py/freebios/freebios/util/ADLO/loader.s?rev=1.1&view=auto
>
> it mentions sources as 0x8000 and 0x18000, so I guess they have been
> aready copied out of rom into the the low memory by linuxbios ???
>
> (i think that's part of the ELF header specs t
On Wed, 26 Jan 2005, Richard Smith wrote:
On Wed, 26 Jan 2005 13:12:27 -0600, Richard Smith <[EMAIL PROTECTED]> wrote:
But I actually think that is overkill. v2 by default and design
enables all of the shadow ranges as memory. So we just need to
use those ranges. That should be much easier having
On Wed, 26 Jan 2005, Eric W. Biederman wrote:
But I actually think that is overkill. v2 by default and design
enables all of the shadow ranges as memory. So we just need to
use those ranges. That should be much easier having to patch
ADLO each time. It is fairly unlikely a writable ROM segment i
> But I actually think that is overkill. v2 by default and design
> enables all of the shadow ranges as memory. So we just need to
> use those ranges. That should be much easier having to patch
> ADLO each time. It is fairly unlikely a writable ROM segment is
Ok.. Well when you put it that way
On Wed, 26 Jan 2005 13:12:27 -0600, Richard Smith <[EMAIL PROTECTED]> wrote:
> > But I actually think that is overkill. v2 by default and design
> > enables all of the shadow ranges as memory. So we just need to
> > use those ranges. That should be much easier having to patch
> > ADLO each time.
Richard Smith <[EMAIL PROTECTED]> writes:
> Thinking about ADLO and the shadow enable/disable got some wheels turning.
>
> I've been spending lots of time in V2 and I was wondering if the same
> type of methodology can't work for ADLO.
>
> In V2 there are specifc .c files that do thing in a chip
20 matches
Mail list logo
