joe | 1 Mar 03:48 2007
Picon

Developer Docs

Hello,
I would like to make a suggestion. I am a newbie to the LinuxBios  
world. I love what I have seen so far. I am ok at C, know a little  
assembly, and would love to contribute to the LinuxBios community. But  
I am not sure how to get started. I have read just about everything I  
can get my hands on, but how do I go about developing a new bios for a  
board? In the FAQ's it talks about some things I would need to get  
started but where do I go from there. I have datasheets and all kinds  
of output from linux (dmidecode, lspci, etc.), POST card. Now what?
Do I just use the code from another board and alter it to my liking? I  
don't want to sound negative or upset anyone but I think alot more  
people would get involved if there was more developer (src)  
documentation. So, I am going to try to document my journey from point  
A to B. So the next person that comes along won't be as stumped?? Make  
sense or is it just me? Can someone tell me where I need to go from  
here?

Thanks - Joe

--

-- 
linuxbios mailing list
linuxbios <at> linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios

Corey Osgood | 1 Mar 05:19 2007
Picon
Picon

Re: Developer Docs

joe <at> smittys.pointclark.net wrote:
> Hello,
> I would like to make a suggestion. I am a newbie to the LinuxBios  
> world. I love what I have seen so far. I am ok at C, know a little  
> assembly, and would love to contribute to the LinuxBios community. But  
> I am not sure how to get started. I have read just about everything I  
> can get my hands on, but how do I go about developing a new bios for a  
> board? In the FAQ's it talks about some things I would need to get  
> started but where do I go from there. I have datasheets and all kinds  
> of output from linux (dmidecode, lspci, etc.), POST card. Now what?
> Do I just use the code from another board and alter it to my liking? I  
> don't want to sound negative or upset anyone but I think alot more  
> people would get involved if there was more developer (src)  
> documentation. So, I am going to try to document my journey from point  
> A to B. So the next person that comes along won't be as stumped?? Make  
> sense or is it just me? Can someone tell me where I need to go from  
> here?
> 
> Thanks - Joe
> 

My 2 cents, for what they're worth: grab something similar to what
you're looking at's source code, and the docs for it if you can, and
learn how it works (if you have a system you can play with it on also,
it's that much better). Then try to do the same thing, with your chips.
There are a few to avoid, such as (for the moment) i440bx, but most of
the chipsets do work. If you want an SDRAM northbridge that works and
you can get docs for, look at the via vt8601, and grab the docs from
here: http://rom.by/doki/VIA/8601A_Apollo_PLE133.rar. Either that, or
the intel e7501 has some very clean and well documented code, but you'd
(Continue reading)

Ward Vandewege | 1 Mar 06:05 2007
Picon

mcp55 flashrom problem

Hi all,

Richard and I spent most of this evening chasing a suspected hardware problem
that turned out to be not a hardware problem, but a flashrom problem.

Basically, I had made a copy of the rom with flashrom earlier today, and
Richard soldered a PLCC socket onto our board this evening. After that, the
board booted fine, but when reading out the rom image with flashrom again, it
came up as slightly different - 115 bytes of difference out of 512K.

Eventually, we realized that the image we read out *changed after every
boot*. We also diffed the image that is downloadable from Gigabyte of this
particular BIOS revision, and it's nothing like what flashrom returns. While
they are the same size, the flashrom copy looks like it is uncompressed (and
only part of the real BIOS), while the downloadable image has hardly any
recognizable strings in it - it's probably compressed somehow.

It looks like flashrom is not disabling shadow properly. This is probably
related to my patch of earlier today that added a new pci id for this
particular board's MCP55 (0x0360). Flashrom only knew about 0x0364 and 0x0367
for the MCP55.

I also saw a patch from Ed Swierk a couple of weeks ago, which added a whole
bunch of PCI ids for the MCP55 (among which the 0x0360), but was never
applied to the tree.

Can someone who knows the MCP55 have a look at the enable_flash_mcp55
function in flash_enable.c and figure out what's wrong?

Yinghai, can you tell us which board(s) you've tested the enable_flash_mcp55
(Continue reading)

Ed Swierk | 1 Mar 06:11 2007

Re: mcp55 flashrom problem

On 2/28/07, Ward Vandewege <ward <at> gnu.org> wrote:
> It looks like flashrom is not disabling shadow properly. This is probably
> related to my patch of earlier today that added a new pci id for this
> particular board's MCP55 (0x0360). Flashrom only knew about 0x0364 and 0x0367
> for the MCP55.
>
> I also saw a patch from Ed Swierk a couple of weeks ago, which added a whole
> bunch of PCI ids for the MCP55 (among which the 0x0360), but was never
> applied to the tree.
>
> Can someone who knows the MCP55 have a look at the enable_flash_mcp55
> function in flash_enable.c and figure out what's wrong?
>
> Yinghai, can you tell us which board(s) you've tested the enable_flash_mcp55
> function on?

That's odd. flashrom works fine on my DFI LANParty board, with the
patch I submitted that adds PCI ID 0x360. Maybe shadowing is enabled
only on certain vendors' BIOSes.

--Ed

--

-- 
linuxbios mailing list
linuxbios <at> linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios

Ward Vandewege | 1 Mar 06:15 2007
Picon

Re: mcp55 flashrom problem

On Wed, Feb 28, 2007 at 09:11:21PM -0800, Ed Swierk wrote:
> On 2/28/07, Ward Vandewege <ward <at> gnu.org> wrote:
> > It looks like flashrom is not disabling shadow properly. This is probably
> > related to my patch of earlier today that added a new pci id for this
> > particular board's MCP55 (0x0360). Flashrom only knew about 0x0364 and 0x0367
> > for the MCP55.
> >
> > I also saw a patch from Ed Swierk a couple of weeks ago, which added a whole
> > bunch of PCI ids for the MCP55 (among which the 0x0360), but was never
> > applied to the tree.
> >
> > Can someone who knows the MCP55 have a look at the enable_flash_mcp55
> > function in flash_enable.c and figure out what's wrong?
> >
> > Yinghai, can you tell us which board(s) you've tested the enable_flash_mcp55
> > function on?
> 
> That's odd. flashrom works fine on my DFI LANParty board, with the
> patch I submitted that adds PCI ID 0x360. Maybe shadowing is enabled
> only on certain vendors' BIOSes.

So, you've verified that the image that flashrom reads matches what you can
download from the manufacturers website (extracted)?

Flashrom doesn't crash or anything here, and it might just *write* fine (not
tested yet), but reading gives the wrong data. We know, because we got the ID
for the chip back, that at least a couple of writes to the chip succeeded.

Thanks,
Ward.
(Continue reading)

yhlu | 1 Mar 07:02 2007
Picon

Re: mcp55 flashrom problem

what is your Mem conf? 4G or 2G?

Kernel version?

YH

--

-- 
linuxbios mailing list
linuxbios <at> linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios

Hao Li | 1 Mar 07:27 2007
Picon

Questions about gx2/cs5535/vsa

Hi all,

 

I am porting olpc/rev_c which is gx2/cs5536 to gx2/cs5535. I have already had VSA image loaded. But I still get the output below:

Finding PCI configuration type.

PCI: Sanity check failed

pci_check_direct failed

And it seems there is no bridge on the bus 00.

Any ideas?

Thanks.

 

Hao Li

--

-- 
linuxbios mailing list
linuxbios <at> linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios
Ed Swierk | 1 Mar 08:12 2007

Re: mcp55 flashrom problem

On 2/28/07, Ward Vandewege <ward <at> gnu.org> wrote:
> So, you've verified that the image that flashrom reads matches what you can
> download from the manufacturers website (extracted)?
>
> Flashrom doesn't crash or anything here, and it might just *write* fine (not
> tested yet), but reading gives the wrong data. We know, because we got the ID
> for the chip back, that at least a couple of writes to the chip succeeded.

I used flashrom several months ago to read the vendor's BIOS. I did
not actually compare it against the one posted on their web site, but
I thought the contents looked plausible when I went grepping through
it for strings.

I can give it another try when I get my hands on the DFI board again next week.

--Ed

--

-- 
linuxbios mailing list
linuxbios <at> linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios

Richard Smith | 1 Mar 08:25 2007
Picon

Re: mcp55 flashrom problem

Ed Swierk wrote:
> 
> I used flashrom several months ago to read the vendor's BIOS. I did
> not actually compare it against the one posted on their web site, but
> I thought the contents looked plausible when I went grepping through
> it for strings.
> 
> I can give it another try when I get my hands on the DFI board again next week.

That's exactly what we thought as well.  The de-compressed code in RAM 
has loads of bios type strings in it.

But all most all the bios these days are compressed.  So a copy of whats 
_actually_ in the ROM should have very little in the way of strings.

-- 
Richard A. Smith
smithbone <at> gmail.com

--

-- 
linuxbios mailing list
linuxbios <at> linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios

Stefan Reinauer | 1 Mar 11:40 2007
Picon

Re: mcp55 flashrom problem

Ward Vandewege wrote:
> So, you've verified that the image that flashrom reads matches what you can
> download from the manufacturers website (extracted)?

There will often be small differences between those, too. ie. in the
"DMI area".

> Flashrom doesn't crash or anything here, and it might just *write* fine (not
> tested yet), but reading gives the wrong data. 

Don't try it unless reading works reliably. Writing "requires reading"
for the write to work. (It polls for the data to "arrive" in the chip")

> We know, because we got the ID
> for the chip back, that at least a couple of writes to the chip succeeded.

Weird. This is a pretty good sign that shadowing is disabled, normally.

Maybe not all of shadowing is disabled? only half the chip?

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info <at> coresystems.de  • http://www.coresystems.de/

--

-- 
linuxbios mailing list
linuxbios <at> linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios

Gmane