[LinuxBIOS] r2670 - in trunk/LinuxBIOSv2/src/mainboard: asus/p2b bitworks/ims densitron/dpx114 via/epia via/epia-m
roger
roger at eskimo.com
Tue May 15 18:33:47 CEST 2007
On Tue, 2007-05-15 at 18:00 +0200, Stefan Reinauer wrote:
> * Uwe Hermann <uwe at hermann-uwe.de> [070515 17:46]:
> > On Tue, May 15, 2007 at 12:28:55PM +0200, Peter Stuge wrote:
> > > On Tue, May 15, 2007 at 10:26:54AM +0000, svn at openbios.org wrote:
> > > > static inline int spd_read_byte(unsigned device, unsigned address)
> > > > {
> > > > - uint8_t c;
> > > > - c = smbus_read_byte(device, address);
> > > > - return c;
> > > > + return smbus_read_byte(device, address);
> > >
> > > Should they return uint8_t perhaps?
> >
> > Yes, I think so. AFAIK smbus works with byte values (or at least
> > smbus_read_byte() does), and SPD data consists of bytes, too...
>
> Most other romcc functions have no sized variables, but just
> signed/unsigned.
>
> I would assume spd_read_byte should be at least unsigned though.
>
> Can anyone confirm romcc creates different code if you choose uint8_t or
> unsigned or unsigned int as a return type?
>
> Stefan
>
(wow, bounced email from linuxbios at linuxbios.org... anyways, repost and
see what happens)
I'm not sure where the above originated, but to note, the above
spd_read_byte function appears broken on my generic 440bx. As
such,
I've replaced it with code from tyan/s1846/auto.c as noted by
patch
below. This fixes the random hangs during DRAM Fill/Verify I
was
getting while executing linuxbios.
asus/p2b/auto.c
-static inline int spd_read_byte(unsigned device, unsigned
address)
+static inline int spd_read_byte(unsigned int device, unsigned
int
address)
{
- uint8_t c;
- c = smbus_read_byte(device, address);
- return c;
+ return smbus_read_byte(device, address);
}
--
Roger
http://www.eskimo.com/~roger/index.html
Key fingerprint = 8977 A252 2623 F567 70CD 1261 640F C963 1005 1D61
Tue May 15 09:33:43 PDT 2007
More information about the coreboot
mailing list