v3 and partially memory-mapped ROMs

[Carl-Daniel Hailfinger]

Hi,

this problem has been mentioned by me in the past, but I'd like to
remind people of it now that we're working on a M57SLI port to v3.

The LAR code and lots of other places can't cope with partially mapped
ROMs. There are two options:
- Rewrite the LAR+string code to use accessor functions: Ugly, makes the
code completely unreadable, severe performance penalty, people will wash
their eyes with bleach after reading it, makes sure the person writing
the code will be the only one to ever understand it.
- Require the bootblock and initram to be in the mapped area and mirror
the complete ROM into RAM after RAM is enabled: No overhead except for
stage2 and payloads, existing LAR+string code can be used after a small
audit, faster decompression for unmapped areas (up to a factor of two
for the M57SLI rev2, up to a factor of four for other chipsets),
needless copying of all unused (fallback, alternative payload) ROM areas.

Regards,
Carl-Daniel

[Stefan Reinauer]

Carl-Daniel Hailfinger wrote:
> Hi,
>
> this problem has been mentioned by me in the past, but I'd like to
> remind people of it now that we're working on a M57SLI port to v3.
>
> The LAR code and lots of other places can't cope with partially mapped
> ROMs. There are two options:

Are you talking about ROMs that can not be mapped completely at all?
Have you encountered any of these anywhere? If so I would like to know
what systems that were.

In any other case, the bootblock's duty is to enable full mapping of the
chip.

[Carl-Daniel Hailfinger]

On 04.08.2008 12:41, Stefan Reinauer wrote:
> Carl-Daniel Hailfinger wrote:
> > Hi,
> >
> > this problem has been mentioned by me in the past, but I'd like to
> > remind people of it now that we're working on a M57SLI port to v3.
> >
> > The LAR code and lots of other places can't cope with partially mapped
> > ROMs. There are two options:
>
> Are you talking about ROMs that can not be mapped completely at all?

Yes.
> Have you encountered any of these anywhere? If so I would like to know
> what systems that were.

Gigabyte M57SLI rev 2.0 uses the LPC-to-SPI translation feature of the
IT8716F which can only map the top (not a movable window!) 512 kBytes of
the SPI chip in memory space. There's an additional 128 kByte region
(from 4G-1152kB to 4G-1024kB, not movable) which is sort of a "register
space" compatibility feature. Everything outside these "standard" areas
needs to be read with explicit read commands in 3-byte chunks.

So any modded M57SLI with a chip greater than 512kB has this problem. I
tried every possible undocumented workaround to no avail, and contacted
ITE with no response.
> In any other case, the bootblock's duty is to enable full mapping of the
> chip.

Fully agreed.

Regards,
Carl-Daniel

[Ward Vandewege]

On Mon, Aug 04, 2008 at 01:58:47PM +0200, Carl-Daniel Hailfinger wrote:
> Gigabyte M57SLI rev 2.0 uses the LPC-to-SPI translation feature of the
> IT8716F which can only map the top (not a movable window!) 512 kBytes of
> the SPI chip in memory space. There's an additional 128 kByte region
> (from 4G-1152kB to 4G-1024kB, not movable) which is sort of a "register
> space" compatibility feature. Everything outside these "standard" areas
> needs to be read with explicit read commands in 3-byte chunks.
>
> So any modded M57SLI with a chip greater than 512kB has this problem. I
> tried every possible undocumented workaround to no avail, and contacted
> ITE with no response.

There is a patch by Ronald Hoogeboom with a workaround, which allows booting
from larger rom chips:

http://article.gmane.org/gmane.linux.bios/33492

I'd still like to put it in the tree.

Thanks,
Ward.

[Carl-Daniel Hailfinger]

On 04.08.2008 14:13, Ward Vandewege wrote:
> On Mon, Aug 04, 2008 at 01:58:47PM +0200, Carl-Daniel Hailfinger wrote:
> > Gigabyte M57SLI rev 2.0 uses the LPC-to-SPI translation feature of the
> > IT8716F which can only map the top (not a movable window!) 512 kBytes of
> > the SPI chip in memory space. There's an additional 128 kByte region
> > (from 4G-1152kB to 4G-1024kB, not movable) which is sort of a "register
> > space" compatibility feature. Everything outside these "standard" areas
> > needs to be read with explicit read commands in 3-byte chunks.
> >
> > So any modded M57SLI with a chip greater than 512kB has this problem. I
> > tried every possible undocumented workaround to no avail, and contacted
> > ITE with no response.
>
> There is a patch by Ronald Hoogeboom with a workaround, which allows booting
> from larger rom chips:
>
> http://article.gmane.org/gmane.linux.bios/33492
>
> I'd still like to put it in the tree.

I'm no longer opposing to put this in v2 (v2 is already complicated and
support for this will make it worse), but I shall make very sure that we
use a clean solution in v3.

Regards,
Carl-Daniel

[Ward Vandewege]

On Mon, Aug 04, 2008 at 03:33:34PM +0200, Carl-Daniel Hailfinger wrote:
> > > Gigabyte M57SLI rev 2.0 uses the LPC-to-SPI translation feature of the
> > > IT8716F which can only map the top (not a movable window!) 512 kBytes of
> > > the SPI chip in memory space. There's an additional 128 kByte region
> > > (from 4G-1152kB to 4G-1024kB, not movable) which is sort of a "register
> > > space" compatibility feature. Everything outside these "standard" areas
> > > needs to be read with explicit read commands in 3-byte chunks.
> > >
> > > So any modded M57SLI with a chip greater than 512kB has this problem. I
> > > tried every possible undocumented workaround to no avail, and contacted
> > > ITE with no response.
> >
> > There is a patch by Ronald Hoogeboom with a workaround, which allows booting
> > from larger rom chips:
> >
> > http://article.gmane.org/gmane.linux.bios/33492
> >
> > I'd still like to put it in the tree.
>
> I'm no longer opposing to put this in v2 (v2 is already complicated and
> support for this will make it worse), but I shall make very sure that we
> use a clean solution in v3.

I agree! Will test again and commit for v2.

Thanks,
Ward.