Are we going to move the location of the master header? I'd like to add an error to cbfstool when it overwrites code with its data.
Thanks, Myles
On 24.04.2009 22:16, Myles Watson wrote:
Are we going to move the location of the master header? I'd like to add an error to cbfstool when it overwrites code with its data.
Why do I have the feeling that every mistake we made with LAR is repeated with CBFS? One year from now CBFS and LAR will probably have evolved to an identical feature set and the same design, have equally complex code and it will be a nightmare to debug corner cases in each of them.
Regards, Carl-Daniel
On Fri, Apr 24, 2009 at 2:42 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 24.04.2009 22:16, Myles Watson wrote:
Are we going to move the location of the master header? I'd like to add an error to cbfstool when it overwrites code with its data.
Why do I have the feeling that every mistake we made with LAR is repeated with CBFS? One year from now CBFS and LAR will probably have evolved to an identical feature set and the same design, have equally complex code and it will be a nightmare to debug corner cases in each of them.
I didn't think we'd run into this one in LAR. How did we fix it?
Thanks, Myles
On Fri, Apr 24, 2009 at 1:53 PM, Myles Watson mylesgw@gmail.com wrote:
On Fri, Apr 24, 2009 at 2:42 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 24.04.2009 22:16, Myles Watson wrote:
Are we going to move the location of the master header? I'd like to add an error to cbfstool when it overwrites code with its data.
Why do I have the feeling that every mistake we made with LAR is repeated with CBFS? One year from now CBFS and LAR will probably have evolved to an identical feature set and the same design, have equally complex code and it will be a nightmare to debug corner cases in each of them.
I didn't think we'd run into this one in LAR. How did we fix it?
we never got that far. This is a new problem.
ron
On Fri, Apr 24, 2009 at 2:54 PM, ron minnich rminnich@gmail.com wrote:
On Fri, Apr 24, 2009 at 1:53 PM, Myles Watson mylesgw@gmail.com wrote:
On Fri, Apr 24, 2009 at 2:42 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 24.04.2009 22:16, Myles Watson wrote:
Are we going to move the location of the master header? I'd like to add an error to cbfstool when it overwrites code with its data.
Why do I have the feeling that every mistake we made with LAR is repeated with CBFS? One year from now CBFS and LAR will probably have evolved to an identical feature set and the same design, have equally complex code and it will be a nightmare to debug corner cases in each of them.
I didn't think we'd run into this one in LAR. How did we fix it?
../src/southbridge/nvidia/ck804/romstrap.lds: . = (_ROMBASE + ROM_IMAGE_SIZE - 0x10) - (__romstrap_end - __romstrap_start); ../src/southbridge/nvidia/mcp55/romstrap.lds: . = (_ROMBASE + ROM_IMAGE_SIZE - 0x10) - (__romstrap_end - __romstrap_start); ../src/southbridge/sis/sis966/romstrap.lds: . = (_ROMBASE + ROM_IMAGE_SIZE - 0x10) - (__romstrap_end - __romstrap_start); ../src/southbridge/via/k8t890/romstrap.lds: . = (_ROMBASE + ROM_IMAGE_SIZE - 0x2c) - (__romstrap_end - __romstrap_start);
These are all close to the end. CBFS gives us more room in flash because elfboot is gone, so I say:
1. lets pick something safe for these boards 2. Make the tool more aware 3. Document it
Myles
On Fri, Apr 24, 2009 at 2:01 PM, Myles Watson mylesgw@gmail.com wrote:
On Fri, Apr 24, 2009 at 2:54 PM, ron minnich rminnich@gmail.com wrote:
On Fri, Apr 24, 2009 at 1:53 PM, Myles Watson mylesgw@gmail.com wrote:
On Fri, Apr 24, 2009 at 2:42 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 24.04.2009 22:16, Myles Watson wrote:
Are we going to move the location of the master header? I'd like to add an error to cbfstool when it overwrites code with its data.
Why do I have the feeling that every mistake we made with LAR is repeated with CBFS? One year from now CBFS and LAR will probably have evolved to an identical feature set and the same design, have equally complex code and it will be a nightmare to debug corner cases in each of them.
I didn't think we'd run into this one in LAR. How did we fix it?
../src/southbridge/nvidia/ck804/romstrap.lds: . = (_ROMBASE + ROM_IMAGE_SIZE - 0x10) - (__romstrap_end - __romstrap_start); ../src/southbridge/nvidia/mcp55/romstrap.lds: . = (_ROMBASE + ROM_IMAGE_SIZE - 0x10) - (__romstrap_end - __romstrap_start); ../src/southbridge/sis/sis966/romstrap.lds: . = (_ROMBASE + ROM_IMAGE_SIZE - 0x10) - (__romstrap_end - __romstrap_start); ../src/southbridge/via/k8t890/romstrap.lds: . = (_ROMBASE + ROM_IMAGE_SIZE - 0x2c) - (__romstrap_end - __romstrap_start);
These are all close to the end. CBFS gives us more room in flash because elfboot is gone, so I say:
- lets pick something safe for these boards
- Make the tool more aware
- Document it
if we put the romstrap in cbfs, then this is another bit of ldscript we can remove. Another plus.
ron
On 24.04.2009 23:01, Myles Watson wrote:
On Fri, Apr 24, 2009 at 2:54 PM, ron minnich rminnich@gmail.com wrote:
On Fri, Apr 24, 2009 at 1:53 PM, Myles Watson mylesgw@gmail.com wrote:
On Fri, Apr 24, 2009 at 2:42 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 24.04.2009 22:16, Myles Watson wrote:
Are we going to move the location of the master header? I'd like to add an error to cbfstool when it overwrites code with its data.
Why do I have the feeling that every mistake we made with LAR is repeated with CBFS? One year from now CBFS and LAR will probably have evolved to an identical feature set and the same design, have equally complex code and it will be a nightmare to debug corner cases in each of them.
I didn't think we'd run into this one in LAR. How did we fix it?
../src/southbridge/nvidia/ck804/romstrap.lds: . = (_ROMBASE + ROM_IMAGE_SIZE - 0x10) - (__romstrap_end - __romstrap_start); ../src/southbridge/nvidia/mcp55/romstrap.lds: . = (_ROMBASE + ROM_IMAGE_SIZE - 0x10) - (__romstrap_end - __romstrap_start); ../src/southbridge/sis/sis966/romstrap.lds: . = (_ROMBASE + ROM_IMAGE_SIZE - 0x10) - (__romstrap_end - __romstrap_start); ../src/southbridge/via/k8t890/romstrap.lds: . = (_ROMBASE + ROM_IMAGE_SIZE - 0x2c) - (__romstrap_end - __romstrap_start);
These are all close to the end. CBFS gives us more room in flash because elfboot is gone, so I say:
- lets pick something safe for these boards
Depending on how much space we're willing to lose, sacrificing the TOP-127 to TOP-16 for chipset stuff would probably be safe. TOP-15 to TOP would contain the jump and the pointer to the master header. There's one caveat, though: Short jumps can only jump -128 bytes and not further. That may or may not be a problem for startup code.
Do we have a table where these locations are written down?
- Make the tool more aware
- Document it
Excellent idea.
Regards. Carl-Daniel
On Fri, Apr 24, 2009 at 3:51 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Depending on how much space we're willing to lose, sacrificing the TOP-127 to TOP-16 for chipset stuff would probably be safe. TOP-15 to TOP would contain the jump and the pointer to the master header. There's one caveat, though: Short jumps can only jump -128 bytes and not further. That may or may not be a problem for startup code.
if we do our jobs right, and use cbfs to hold the ROMSTRAP, we ought to be able not to do use TOP-127 to TOP-16. We can count on the hardware vendors to come up with new challenges, so I no longer believe anything is safe :-)
ron
On 24.04.2009 22:42 Uhr, Carl-Daniel Hailfinger wrote:
On 24.04.2009 22:16, Myles Watson wrote:
Are we going to move the location of the master header? I'd like to add an error to cbfstool when it overwrites code with its data.
Why do I have the feeling that every mistake we made with LAR is repeated with CBFS? One year from now CBFS and LAR will probably have evolved to an identical feature set and the same design, have equally complex code and it will be a nightmare to debug corner cases in each of them.
You keep praying this like a mantra. What's your point, Carl-Daniel?
Regards, Stefan
On 24.04.2009 23:41, Stefan Reinauer wrote:
On 24.04.2009 22:42 Uhr, Carl-Daniel Hailfinger wrote:
On 24.04.2009 22:16, Myles Watson wrote:
Are we going to move the location of the master header? I'd like to add an error to cbfstool when it overwrites code with its data.
Why do I have the feeling that every mistake we made with LAR is repeated with CBFS? One year from now CBFS and LAR will probably have evolved to an identical feature set and the same design, have equally complex code and it will be a nightmare to debug corner cases in each of them.
You keep praying this like a mantra. What's your point, Carl-Daniel?
We'd have saved lots of developer time if LAR had been changed instead of rewritten from scratch. I read through the original mails again and there were maybe 2 or 3 points in LAR which people objected to. These could have been fixed with a few dozen lines of diffs which would have been reviewed easily. Instead, code was written from scratch. I don't object to the name nor the general idea behind it. I just claim that the rewrite was unnecessary and didn't benefit from the bug fixes which went into LAR. Unless LAR developers were worse programmers than CBFS developers, the bugs-per-LOC ratio is expected to be similar. Using LAR development as a metric, this means there will be lots of corner cases we have to fix in CBFS.
That's what scares me and reminds me of the days where patchbombs were dropped on the tree, making throrough review effectively impossible due to the size of the changeset. (Fortunately, I wasn't active as developer back then, but trying to track code history for some bugs made me feel the pain.)
Regards, Carl-Daniel
The guy who wrote LAR felt that we should move to CBFS. So did the guy who wrote CBFS. That was good enough for me.
Further, I watched CBFS get debated to death in 2008. That really sucked. At some point, debate must end. The situation with v2 has improved with cbfs.
Ideally, we would do things better than we have. But that will always be the case, with any project. We don't live in an ideal world.
Thanks
ron
Stefan Reinauer wrote:
Why do I have the feeling that every mistake we made with LAR is repeated with CBFS?
You keep praying this like a mantra.
Stefan, I think that is poor choice of words. Even in disagreements, anything less than remaining courteous is unacceptable!
Please watch Numb3rs s04e16 titled Atomic No. 33.
What's your point, Carl-Daniel?
Fair question, although to me the answer is clear; Carl-Daniel's point is that several problems that were solved since the invention of LAR are now showing up also in CBFS, and that this is a waste of time. It would of course be better if all known problems could be addressed once and for all.
In practice, one way of ensuring that would be to not re-invent the wheel (CBFS) but rather improve the wheel there is (LAR).
Personally I don't think it's such a big deal if the wheel is re-invented, because the new one isn't bad, and it seems to make a lot of people happy. \o/
Both of you : Chill. It's Friday evening. Do something you enjoy more than writing email. (I'm sure there is _something_. ;)
//Peter
On Fri, Apr 24, 2009 at 3:42 PM, Peter Stuge peter@stuge.se wrote:
Fair question, although to me the answer is clear; Carl-Daniel's point is that several problems that were solved since the invention of LAR are now showing up also in CBFS, and that this is a waste of time. It would of course be better if all known problems could be addressed once and for all.
Actually, this particular problem -- the ROMSTRAP -- was something I knew I had to fix in LAR. Now we have to fix it in cbfs. But it was not really fixed.
Ah, guys, Peter is right: go have a beer and watch the leaves in the pretty spring day. Well, that's what I'm doing here in CA anyway. Except I'm still working so I don't get the beer. You live in the future from my point of view. Enjoy it!
ron
On 25.04.2009 00:42, Peter Stuge wrote:
Chill. It's Friday evening. Do something you enjoy more than writing email. (I'm sure there is _something_. ;)
Ah yes. Thanks for reminding me of the real world out there.
A happy weekend to you all!
Regards, Carl-Daniel
-
Carl-Daniel Hailfinger -
Myles Watson -
Peter Stuge -
ron minnich -
Stefan Reinauer