I'm starting up the learning curve....
Whats the mapping between the various CPU models in the intel directory and marketing cpu names as I know them like Pentium III, P3 celeron, Pentuim 4, etc.
I don't completely grok the fallback and normal stuff. I know the theory but not practice. I know this is a FAQ. Explain it to me and I'll document it for the next guy.
Why are all the payloads out of tree? Be nice if there was a payloads directory with some known good payloads.
On Thu, 20 Jan 2005, Richard Smith wrote:
Whats the mapping between the various CPU models in the intel directory and marketing cpu names as I know them like Pentium III, P3 celeron, Pentuim 4, etc.
At this point I believe the marketing names are going away as they are not specific enough, so you have to use the full name. That's about it.
I don't completely grok the fallback and normal stuff. I know the theory but not practice. I know this is a FAQ. Explain it to me and I'll document it for the next guy.
fallback always runs the first few instructions, and it makes a decision about whether to continue running or jump to normal.
Why are all the payloads out of tree? Be nice if there was a payloads directory with some known good payloads.
well, I am supposed to put my filo in there RSN, should I do that? My mistake ...
I would still prefer to get people to build out of the tree, but ...
ron
* Ronald G. Minnich rminnich@lanl.gov [050120 16:41]:
Why are all the payloads out of tree? Be nice if there was a payloads directory with some known good payloads.
well, I am supposed to put my filo in there RSN, should I do that? My mistake ...
What about fs_stream?
I would still prefer to get people to build out of the tree, but ...
We could pack a script that downloads a given etherboot version, asks some questions and compiles. But then again, packing a good documentation might help further.
Stefan
Whats the mapping between the various CPU models in the intel directory and marketing cpu names as I know them like Pentium III, P3 celeron, Pentuim 4, etc.
At this point I believe the marketing names are going away as they are not specific enough, so you have to use the full name. That's about it.
I still need to know the mapping. I don't see any of thie model stuff in my documentation. Granted there's a bunch of stuff I probally haven't looked at.
I have a PIII celeron. Where do I go loook to find what model that is so I know what to add into my config?
I don't completely grok the fallback and normal stuff. I know the theory but not practice. I know this is a FAQ. Explain it to me and I'll document it for the next guy.
fallback always runs the first few instructions, and it makes a decision about whether to continue running or jump to normal.
Well I was hoping for a bit more detail. *grin* Like how do you enable and disable it and what do all the options do.
Why are all the payloads out of tree? Be nice if there was a payloads directory with some known good payloads.
well, I am supposed to put my filo in there RSN, should I do that? My mistake ...
Well when I got the build error I was unsure if you _had_ to have a payload specified and there weren't any. So I just created a blank file and tried that.
I would still prefer to get people to build out of the tree, but ...
Out of tree makes it a bit more difficult for me to keep all my stuff under one roof when I go to check it into my internal CVS. Why do you like out of tree?
well, I am supposed to put my filo in there RSN, should I do that? My mistake ...
What about fs_stream?
What's fs_stream?
some questions and compiles. But then again, packing a good documentation might help further.
That's why I'm asking all these questions. I'm documenting as I go. I'll feed that back when I'm done.
On Thu, 20 Jan 2005, Richard Smith wrote:
I have a PIII celeron. Where do I go loook to find what model that is so I know what to add into my config?
That was a PGA370, right? I am guessing it is not in there, looking at the tree.
Well I was hoping for a bit more detail. *grin* Like how do you enable and disable it and what do all the options do.
Currently, it's always enabled, but if you build a fallback-only payload, then 'normal' won't get run. This is hokey, I know.
Well when I got the build error I was unsure if you _had_ to have a payload specified and there weren't any. So I just created a blank file and tried that.
For testing a build I do: payload /etc/hosts
Out of tree makes it a bit more difficult for me to keep all my stuff under one roof when I go to check it into my internal CVS. Why do you like out of tree?
What I mean is, the .o and other objects out of the tree.
ron
I have a PIII celeron. Where do I go loook to find what model that is so I know what to add into my config?
That was a PGA370, right? I am guessing it is not in there, looking at the tree.
Right. I created it. And really all it needs is the right cpu/intel/model_xxx in the config file. Currently I'm using model_6xx which is what the slot_2 used.
Currently, it's always enabled, but if you build a fallback-only payload, then 'normal' won't get run. This is hokey, I know.
So if I just remove all the normal stuff? What about all the reset16 and entry16 stuff? Looks to me like I pretty much have to re-write my MB config.lb
Out of tree makes it a bit more difficult for me to keep all my stuff under one roof when I go to check it into my internal CVS. Why do you like out of tree?
What I mean is, the .o and other objects out of the tree.
Since you haven't really said specificlly what you don't like about in-tree builds I say what I do like. Having everything under one roof make it much easier for me to just take a snapshot of things. CVS is great but there are still loads of time when I'ts just more of a hassle. Sweet and simple. I can't tell you how many times I've had to go back to a snapshot and snag a binary that I wasn't able to reproduce due do some wierdness going on. Or just as a sanity check when wierdness is going on.
Having things in seperate trees makes that harder. I do understand that having them differnt though does offer a lot of advantages in other areas.
But I would say that what you really want is the ability to do it either way.
My original point was though that it would be nice from a new board porters view if there was some kind of reference payload for each known good board and it was included.
* Richard Smith smithbone@gmail.com [050120 18:05]:
Currently, it's always enabled, but if you build a fallback-only payload, then 'normal' won't get run. This is hokey, I know.
So if I just remove all the normal stuff? What about all the reset16 and entry16 stuff? Looks to me like I pretty much have to re-write my MB config.lb
Start with building a rom that only has a fallback image, leaving failover.c intact and strip it down once everything else is working. You'll never have to touch the reset16 and entry16 code.
Stefan
* Richard Smith smithbone@gmail.com [050120 17:19]:
What about fs_stream?
What's fs_stream?
If you set CONFIG_FS_STREAM 1 you can load a payload from an IDE disk with a filesystem on it. It's basically filo directly integrated.
Stefan
On Thu, 20 Jan 2005, Richard Smith wrote:
So if I just remove all the normal stuff? What about all the reset16 and entry16 stuff? Looks to me like I pretty much have to re-write my MB config.lb
no, not at all. It's the target/bitworks/richard/Config.lb that determines normal/fallback or fallback-only configuration, and that in turn will drive how the thing gets built
Since you haven't really said specificlly what you don't like about in-tree builds I say what I do like. Having everything under one roof make it much easier for me to just take a snapshot of things. CVS is great but there are still loads of time when I'ts just more of a hassle. Sweet and simple. I can't tell you how many times I've had to go back to a snapshot and snag a binary that I wasn't able to reproduce due do some wierdness going on. Or just as a sanity check when wierdness is going on.
good point. The only reason I like seperate trees is that if things get too weird I like to rm -rf freebios cvs blah blah co freebios and not affect any of my targets. That's all.
My original point was though that it would be nice from a new board porters view if there was some kind of reference payload for each known good board and it was included.
good point.
ron
no, not at all. It's the target/bitworks/richard/Config.lb that determines normal/fallback or fallback-only configuration, and that in turn will drive how the thing gets built
Ok. I think I see now that I've looked a bit more closely.
So if I set the HAVE_FALLBACK to 0 then it will only build the fallback image but include everything that would have been in the normal image?
good point. The only reason I like seperate trees is that if things get too weird I like to rm -rf freebios cvs blah blah co freebios and not affect any of my targets. That's all.
Thats a good point as well. I usually find though that when things get flaky. I've always been under the hood working on things. So blowing away my tree would blow away any changes I've been working on.
Plus I can simulate what you are talking about by just checking out a clean copy into another directory and building that.
-
Greg Watson -
Richard Smith -
Ronald G. Minnich -
Stefan Reinauer