probably because the cmos checksum is wrong. You need to use cmos_util (from LNXI ftp site) to set up the cmos with good params and checksum.
the docs I could find. My cmos is now fixed up, and I'm getting in to my normal image.
Hmmmm... Our board dosent have CMOS. Well dosen't have any retainable cmos that is. There isn't a battery hooked up to the southbridge.
Guess this means that I'll never come out of fallback? Of course I'm stll a long ways off from that now....
On Thu, 20 Jan 2005, Richard Smith wrote:
Guess this means that I'll never come out of fallback? Of course I'm stll a long ways off from that now....
you can't really use fallback, I guess, unless you stash those bits somewhere else.
ron
Guess this means that I'll never come out of fallback? Of course I'm stll a long ways off from that now....
you can't really use fallback, I guess, unless you stash those bits somewhere else.
Unless I wrote them to the flash there's nothing on my board that is persistent between boots.
How is this handled on non-x86? Most of those dont have any cmos either.
On Thu, 20 Jan 2005, Richard Smith wrote:
How is this handled on non-x86? Most of those dont have any cmos either.
actually a lot of the boards have the same lovely Dallas chip you see on PCs. But, true, if you have no simple NVRAM then the fallback architecture is harder to use.
ron
Richard Smith smithbone@gmail.com writes:
probably because the cmos checksum is wrong. You need to use cmos_util (from LNXI ftp site) to set up the cmos with good params and checksum.
the docs I could find. My cmos is now fixed up, and I'm getting in to my normal image.
Hmmmm... Our board dosent have CMOS. Well dosen't have any retainable cmos that is. There isn't a battery hooked up to the southbridge.
Guess this means that I'll never come out of fallback? Of course I'm stll a long ways off from that now....
:)
Do you have any other non-volatile storage?
For all of the settings except fallback/normal storing them in the flash chip won't be a problem (it just needs a little work).
A serial eeprom might be another good choice, of a location for variables.
Anyway I understand the reasons for it and will happily work on brainstorming a solution.
Eric
:) Do you have any other non-volatile storage?
Nope.
A serial eeprom might be another good choice, of a location for variables. Anyway I understand the reasons for it and will happily work on brainstorming
By design if you want to change the boot firmware of our device (in production) you will have to de-solder the flash.
Richard Smith smithbone@gmail.com writes:
:) Do you have any other non-volatile storage?
Nope.
A serial eeprom might be another good choice, of a location for variables. Anyway I understand the reasons for it and will happily work on brainstorming
By design if you want to change the boot firmware of our device (in production) you will have to de-solder the flash.
Ok so by design you really only want a single firmware image.
It should be straight forward to remove all of the tests etc for switching from a fallback to a normal image.
For those of us who have field upgradable systems it makes a bigger difference.
Eric
Ok so by design you really only want a single firmware image.
Right.. I think Ron has me fixed up. I was unaware that there was an overall flag that enabled/disabled the fallback system.
It should be straight forward to remove all of the tests etc for switching from a fallback to a normal image.
Do I really have to remove them? Ron seemed to suggest that if I just turn off the fallback suff then I will end up with only a singel fallback image.
For those of us who have field upgradable systems it makes a bigger difference.
Yeah I would say so... Since you guys have the power to render 1000 paperweights with a single command.
Our product is going to go into Gasoline pumps. You would not believe the lengths that some store operators go to so they can cheat the consumer slightly per fillup. So our customer requires a flash update to be physical mod.
Richard Smith smithbone@gmail.com writes:
Ok so by design you really only want a single firmware image.
Right.. I think Ron has me fixed up. I was unaware that there was an overall flag that enabled/disabled the fallback system.
In the generic code yes.
It should be straight forward to remove all of the tests etc for switching from a fallback to a normal image.
Do I really have to remove them? Ron seemed to suggest that if I just turn off the fallback suff then I will end up with only a singel fallback image.
I was thinking of the per board test that make the policy decision which image you should be in.
For those of us who have field upgradable systems it makes a bigger
difference.
Yeah I would say so... Since you guys have the power to render 1000 paperweights with a single command.
Ron came insanely close to doing just that a while ago.
Our product is going to go into Gasoline pumps. You would not believe the lengths that some store operators go to so they can cheat the consumer slightly per fillup. So our customer requires a flash update to be physical mod.
Now that is a sane reason not to have field upgradable parts. :)
Eric
"Ronald G. Minnich" rminnich@lanl.gov writes:
On Thu, 20 Jan 2005, Eric W. Biederman wrote:
Yeah I would say so... Since you guys have the power to render 1000 paperweights with a single command.
Ron came insanely close to doing just that a while ago.
?? when was that? I gotta hear this story!
I remember a support call with Pink. You had built the fallback image with the a loglevel of spew and for some reason that caused the nodes not to boot.
You managed to fix it yourself so I don't know just what the fix was but I believe it involved opening cases and swapping rom chips.
Eric
On Fri, 21 Jan 2005, Eric W. Biederman wrote:
I remember a support call with Pink. You had built the fallback image with the a loglevel of spew and for some reason that caused the nodes not to boot.
that's it!
There was a motherboard bug such that the normal bios worked fine, but the fallback would fail, and it just so happened that it was fixable by not printing too much. Fun, eh? No way out when the fallback fails. Turned out to be a motherboard issue.
Luckily I was in paranoia mode and caught it before I fried too many :-)
And yes, only way out was to swap in a new rom chip.
thanks
It should be straight forward to remove all of the tests etc for switching from a fallback to a normal image.
Do I really have to remove them? Ron seemed to suggest that if I just turn off the fallback suff then I will end up with only a singel fallback image.
I was thinking of the per board test that make the policy decision which image you should be in.
Ok so now I'm confused again. Perhaps we should just go through the gory details and I'll be sure to write it up in something for the next person.
When HAVE_FALLBACK_BOOT=1 things do the normal fallback, check and jump to normal. This won't ever work fully on our board since the CMOS is not powered.
When I set that to 0 whats going to happen in the resulting build and image runtime?
I would prefer to stay as close to the framework you have already and just running fallback seems fine to me if thats all I need to do.
Richard Smith smithbone@gmail.com writes:
It should be straight forward to remove all of the tests etc for switching
from a fallback to a normal image.
Do I really have to remove them? Ron seemed to suggest that if I just turn off the fallback suff then I will end up with only a singel fallback image.
I was thinking of the per board test that make the policy decision which image you should be in.
Ok so now I'm confused again. Perhaps we should just go through the gory details and I'll be sure to write it up in something for the next person.
When HAVE_FALLBACK_BOOT=1 things do the normal fallback, check and jump to normal. This won't ever work fully on our board since the CMOS is not powered.
When I set that to 0 whats going to happen in the resulting build and image runtime?
I would prefer to stay as close to the framework you have already and just running fallback seems fine to me if thats all I need to do.
To start I added all of this framework in freebios v1.x and it caused not problems there. We just default to using it all in v2. There should be no reason to require it. Especially if you are doing your own motherboard.
Beyond that on the boards that use it I usually write a failover.c which comes before auto.c that sets things up.
As for the magic include order in auto.c that is because currently romcc does not do prototypes.
Eric
To start I added all of this framework in freebios v1.x and it caused not problems there. We just default to using it all in v2. There should be no reason to require it. Especially if you are doing your own motherboard.
I would like what I'm making to be as usefult to the next 440bx user as possible and so I wan't to keep all the fallback framework stuff in unless I just have a real remove it.
Beyond that on the boards that use it I usually write a failover.c which comes before auto.c that sets things up.
Man the waters just get deeper. I though auto.c was first. I just looked at failover.c and the fallback does a 'retun bist' so who called failover.c?
Can you list out the boot sequence for me step by step? Who calls what?
As for the magic include order in auto.c that is because currently romcc does not do prototypes.
Why does that require them to be after the big block of includes? You can't just stick them all up at the beginning of the .c file?
Richard Smith smithbone@gmail.com writes:
To start I added all of this framework in freebios v1.x and it caused not problems there. We just default to using it all in v2. There should be no reason to require it. Especially if you are doing your own motherboard.
I would like what I'm making to be as usefult to the next 440bx user as possible and so I wan't to keep all the fallback framework stuff in unless I just have a real remove it.
Just don't implement a failover.c for your mainboard. That is the only real practical difference.
Beyond that on the boards that use it I usually write a failover.c which comes before auto.c that sets things up.
Man the waters just get deeper. I though auto.c was first. I just looked at failover.c and the fallback does a 'retun bist' so who called failover.c?
Can you list out the boot sequence for me step by step? Who calls what?
It is the order they are listed in Config.lb. Or more simply the order the included files are included into crt0.S just like in freebios v1. There is just an extra step to build the assembly code now.
As for the magic include order in auto.c that is because currently romcc does not do prototypes.
Why does that require them to be after the big block of includes? You can't just stick them all up at the beginning of the .c file?
Things get interesting when you are including .c files. As has been previously mentioned auto.c defines board specific helper functions for the memory initialization code.
And since I don't have prototypes (which makes inlining easier) those functions must be defined before they are used.
So the file that uses them is included after the functions are defined.
Eric
Man the waters just get deeper. I though auto.c was first. I just looked at failover.c and the fallback does a 'retun bist' so who called failover.c?
Can you list out the boot sequence for me step by step? Who calls what?
It is the order they are listed in Config.lb. Or more simply the order the included files are included into crt0.S just like in freebios v1. There is just an extra step to build the assembly code now.
Thanks, I guess I'll just have to go through the code. What I was trying to get was a call tree detailed enough that I could document it in my write up on porting to my chipset.
Why does that require them to be after the big block of includes? You can't just stick them all up at the beginning of the .c file?
<snip>
So the file that uses them is included after the functions are defined.
I don't seem to be getting my question across properly....
Whats the difference for romcc between what I see in the code which looks like:
#include "header1.h" #include "cfile1.c"
void func1(void) {
}
#include "header2.h" #include "cfile2.c"
void func2(void) {
}
#include "header3.h" #include "cfile3.c"
void func3(void) {
}
And what I perceive as a "normal" setup of :
#include "header1.h" #include "header2.h" #include "header3.h"
#include "cfile1.c" #include "cfile2.c" #include "cfile3.c"
void func1(void) {
}
void func2(void) {
}
void func3(void) {
}
Whats the difference for romcc between what I see in the code which looks like:
Never mind.... I _finally_ get it. auto.c defines functions that are used the the #include files. So they have to be included after the definition in auto.c
And since I don't have prototypes (which makes inlining easier) those functions must be defined before they are used.
Just curious now, how does the lack of prototypes make inlining easier?
Richard Smith smithbone@gmail.com writes:
And since I don't have prototypes (which makes inlining easier) those functions must be defined before they are used.
Just curious now, how does the lack of prototypes make inlining easier?
The primary benefit comes from compiling everything in one pass.
The lack of prototypes means you can inline something as soon as you see a call to it because you have it's definition. At one point that was a pretty big help. I believe I have a second pass in there for other reasons so adding prototype support would probably not be a big deal at this point.
Eric
On Thu, 2005-01-20 at 23:21, Richard Smith wrote:
Our product is going to go into Gasoline pumps. You would not believe the lengths that some store operators go to so they can cheat the consumer slightly per fillup. So our customer requires a flash update to be physical mod.
I want to know more about their tricks. Is there any mod chip I can use to lower my fuel expense?
Ollie
Our product is going to go into Gasoline pumps. You would not believe the lengths that some store operators go to so they can cheat the consumer slightly per fillup. So our customer requires a flash update to be physical mod.
I want to know more about their tricks. Is there any mod chip I can use to lower my fuel expense?
As a consumer I think you are out of luck. Pump you gas on the coldest days when the liquid is the most dense..*grin* Actually I think all the newer pumps cal for temp as well.
Perhaps I can add a special ollie backdoor. *grin* We don't do any of that software though. Just the hardware.
Dishonest store ops will hire black hats to actually reverse engineer the boards and software that are in the dispenser and have them shave off some percentage of gas for each fill up so you think you pumped 14.9 gallons but you may have only gotten 14.8.
One interesting case was a dispenser that would correctly pump for <=5 gallons but skimp on you for larger amounts. Not coincidently the inspector that roams around and periodically checks these things used to use a special 5 gallon jug to test. So it would pass inspection but still cheat customers.
This was discovered by accident. I guess the store changed hands and the dispenser had a problem and was returned back to the mfg complete with all the mods.
The inspectors now use several different amounts that are changed frequently.
On Thu, 20 Jan 2005, Eric W. Biederman wrote:
For those of us who have field upgradable systems it makes a bigger difference.
I just always feel better knowing there is a fallback in there. Belt and suspenders ... Richard, sure you don't want this?
ron
-
ebiederman＠lnxi.com -
Li-Ta Lo -
Richard Smith -
Ronald G. Minnich