headers
Stefan Reinauer | 1 Oct 01:00
Picon

Re: [PATCH]Remove non-CBFS

Peter Stuge wrote:
>> If the m57sli is an exception and we'll never see this problem
>> again, I say we drop it. Copying all of flash into ram sounds bad.
>>     
>
> It would be unfortunate to drop support for one of the most hack
> friendly boards that we've seen in a while.
>
>   
I agree. I don't see why we should drop the board support just because
one hack does not work anymore.
(A hack nobody around seems to be using to begin with)

There is no problem with unmodified boards, and there is no problem with
modified boards with flash chips under a certain size. So unless someone
with a larger amount of m57sli boards, or motivation to come up with a
solution to get this fixed, I suggest we move on and improve life for
the other 99.99% coreboot users.

Stefan

--

-- 
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Permalink | Reply | 21 comments |
headers
ron minnich | 1 Oct 01:07
Picon

Re: [PATCH]Remove non-CBFS

Yes, I'm sorry, we keep board support, but stop worrying about huge
SPI anbd weird accessing of it.

As for fallback: we really need to bring it back at some point. I'm
speaking as someone whose life was saved because I did not destroy a
1024-node cluster with a bad bios image.

CBFS will give us a normal/fallback setup that people can understand.

ron

--

-- 
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Permalink | Reply | 20 comments |
headers
Carl-Daniel Hailfinger | 1 Oct 01:16
Picon
Gravatar

Re: [PATCH]Remove non-CBFS

On 01.10.2009 01:07, ron minnich wrote:
> Yes, I'm sorry, we keep board support, but stop worrying about huge
> SPI anbd weird accessing of it.
>
> As for fallback: we really need to bring it back at some point. I'm
> speaking as someone whose life was saved because I did not destroy a
> 1024-node cluster with a bad bios image.
>
> CBFS will give us a normal/fallback setup that people can understand.
>   

Could we simply reuse arch/x86/stage1.c from v3 and run a search+replace
lar->cbfs on that file? As a nice side benefit, we get global variables
and similar stuff.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/

--

-- 
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Permalink | Reply | 3 comments |
headers
Kevin O'Connor | 1 Oct 01:23

Re: [PATCH]Remove non-CBFS

On Thu, Oct 01, 2009 at 12:51:17AM +0200, Stefan Reinauer wrote:
> Myles Watson wrote:
> > Since normal and failover aren't supported with CBFS, can they disappear
> > too?
> 
> No, we should get that back to life with CBFS asap.. it's one of
> coreboot's key features..

What's the use case for normal/failover?  I always envisioned it as a
software implementation of a "bios savior".  If so, building in a
serialice shell might be a simpler solution.

Am I missing an important use-case?

-Kevin

--

-- 
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Permalink | Reply | 11 comments |
headers
ron minnich | 1 Oct 01:26
Picon

Re: [PATCH]Remove non-CBFS

On Wed, Sep 30, 2009 at 4:23 PM, Kevin O'Connor <kevin <at> koconnor.net> wrote:

> What's the use case for normal/failover?  I always envisioned it as a
> software implementation of a "bios savior".  If so, building in a
> serialice shell might be a simpler solution.
>
> Am I missing an important use-case?

I'm flashing 1024 machines. power fails midway through. bad.

I flash a new bios that has worked in test. It fails on 10% of the
machines, in ways that could not be predicted because 10% of my
machines
have a manufacturing defect. This is what happened to me. Fallback saved me.

There are lots of use cases. It's why many vendors ship with a fallback.

ron

--

-- 
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Permalink | Reply | 6 comments |
headers
ron minnich | 1 Oct 01:27
Picon

Re: [PATCH]Remove non-CBFS

On Wed, Sep 30, 2009 at 4:16 PM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 <at> gmx.net> wrote:

> Could we simply reuse arch/x86/stage1.c from v3 and run a search+replace
> lar->cbfs on that file? As a nice side benefit, we get global variables
> and similar stuff.

I've looked into doing just that. It's not as simple as it sounds. I'd
rather not open that can of worms just yet.

ron

--

-- 
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Permalink | Reply | 1 comment |
headers
Carl-Daniel Hailfinger | 1 Oct 01:31
Picon
Gravatar

Re: [PATCH]Remove non-CBFS

On 01.10.2009 00:32, ron minnich wrote:
> can anyone even buy an m57sli any more? Was it an unfortunate mistake
> -- never repeated -- that FLASH was not directly accessible? If the
> m57sli is an exception and we'll never see this problem again, I say
> we drop it. Copying all of flash into ram sounds bad. If we have to
> cope with this problem in future, maybe we're stuck with accessor
> functions.
>
> But FLASH is so slow I doubt that the cost of an accessor function is
> going to kill us. Function calls run in nanoseconds, and if SPI really
> is only 40 MB/sec., then that's 25 ns/byte.
>   

The accessor function has the disadvantage of ruining readability of the
code, and it also has to perform these extremely slow accesses every
time someone walks the CBFS image.

AFAIK the M57SLI worst case read performance is ~400 kB/s, and the best
case is ~855 kB/s. Each one-byte read access to flash needs at least 2.5
us (microseconds), and a three-byte read access needs at least 3.5 us.
If your flash chip can handle 33 MHz with the normal read command
(instead of the fast read command), flash access latency will be cut in
half and data rate will be doubled.

While using accessor functions look somewhat beneficial from a
performance standpoint, using accessor functions to run the lzma
decompressor is waaaaay slower (I think by at least a factor of 4) than
copying the uncompressed code to RAMand decompressing it there.

My suggestion would be to drop support for these large flash chips on
(Continue reading)

Permalink | Reply | 1 comment |
headers
Carl-Daniel Hailfinger | 1 Oct 01:42
Picon
Gravatar

Re: [PATCH]Remove non-CBFS

On 01.10.2009 01:27, ron minnich wrote:
> On Wed, Sep 30, 2009 at 4:16 PM, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006 <at> gmx.net> wrote:
>   
>> Could we simply reuse arch/x86/stage1.c from v3 and run a search+replace
>> lar->cbfs on that file? As a nice side benefit, we get global variables
>> and similar stuff.
>>     
>
> I've looked into doing just that. It's not as simple as it sounds.
>   

I'm surprised. My stage1 SMP patch was never merged IIRC, so stack
trashing is expected on any non-UP v3 boot. But other than that, v3
stage1 code worked pretty well. The ELFboot code in there should be
dropped (was default off anyway) and then we have a pretty readable startup.

> I'd rather not open that can of worms just yet.
>   

If you're talking about doing too many things at once, I fully agree.
Once the tree is CBFS-only and once Kconfig works for all actively
developed boards, we will have a mostly stable tree again and it would
be cool to look at importing stage1 (and possibly stage0) from v3.

Regards,
Carl-Daniel

--

-- 
http://www.hailfinger.org/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Stuge | 1 Oct 01:44
Picon

Re: [PATCH]Remove non-CBFS

ron minnich wrote:
> Yeah, I was going worst-case scenario (i.e. SPI is super-fast) and
> even in that case accessor functions would not hurt much if at all.

Ah!

> So if we absolutely *have* to do some sort of function interface,
> well, it won't exactly kill us.

I think it would be great to not have to deal with that in the common
case, but I think it can be useful for some boards - ie. if there is
would I think it would be best to make it optional.

//Peter

--

-- 
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Permalink | Reply | 0 comments |
headers
Stefan Reinauer | 1 Oct 01:45
Picon

Re: [PATCH]Remove non-CBFS

Carl-Daniel Hailfinger wrote:
> On 01.10.2009 01:07, ron minnich wrote:
>   
>> Yes, I'm sorry, we keep board support, but stop worrying about huge
>> SPI anbd weird accessing of it.
>>
>> As for fallback: we really need to bring it back at some point. I'm
>> speaking as someone whose life was saved because I did not destroy a
>> 1024-node cluster with a bad bios image.
>>
>> CBFS will give us a normal/fallback setup that people can understand.
>>   
>>     
>
> Could we simply reuse arch/x86/stage1.c from v3 and run a search+replace
> lar->cbfs on that file? As a nice side benefit, we get global variables
> and similar stuff.
>   

No search and replace blind copy of non-fitting code please. The least
we can use in v2 right now is a code quality drop to v3 level ..

One step after the other..

It's not enough to have one board running. If you have a solution to
safely bring over 200 boards, please do it!

Stefan

--

--
(Continue reading)

Permalink | Reply | 0 comments |

Gmane