[LinuxBIOS] PATCH: lx car that returns from disable_car

[ron minnich]

This patch set allows disable_car to return. Comments welcome.

Thanks to Carl-Daniel and Stefan for not accepting my earlier patches,
and arguing me into the ground. They were right.

[I hope :-) we still have not solved opteron.]

This discussion began quite some time ago. I thought it would never
end. But I think we're there.

Sometimes, no matter how much sense you think you are making, you've
got to listen to other people to get it right ... and it doesn't
always get done as soon as you might wish.

thanks

ron

[Marc Jones]

ron minnich wrote:
> This patch set allows disable_car to return. Comments welcome.
>
> Thanks to Carl-Daniel and Stefan for not accepting my earlier patches,
> and arguing me into the ground. They were right.
>
> [I hope :-) we still have not solved opteron.]
>
> This discussion began quite some time ago. I thought it would never
> end. But I think we're there.
>
> Sometimes, no matter how much sense you think you are making, you've
> got to listen to other people to get it right ... and it doesn't
> always get done as soon as you might wish.
>
> thanks
>
> ron

The copy over and then wbinvd was a good idea. This should be fast and 
better than copy and then copy back.... It is fine to move the cache. I 
only used 0xC0000 because that is what K8 uses. For LX is doesn't matter 
where the stack is located.

I don't like taking the hlt() out of die(). Can you describe when you 
where having issues? It could be coherency issues in CAR with die(). In 
FS2 check your config and set Coherent to off. You need it on/auto in 
normal operation.

Marc

[ron minnich]

On Jan 7, 2008 2:18 PM, Marc Jones  wrote:
> I don't like taking the hlt() out of die(). Can you describe when you
> where having issues?

In the early days of LinuxBIOS, using an American Arium JTAG debugger,
I found that I could not examine memory or, in fact, do much of
anything on JTAG once the CPU halts. It's a real hassle to get to a
hlt() and know that the info you need is in memory, and you can't get
to it.

I'd really prefer not to have a hlt instruction in there, but if it is
a problem, I guess we can put it back.

As for the UART, similar issue: I had problems years ago where I had
to intuit what got sent to the UART because it did not make it out --
it could get stuck in the FIFO or other intermediate places at times.
I have found it handy to push a gazillion NULLS out to make sure I see
all that is there (Actually, this is a decades old OS hacking trick
... dating back to, well, I'm embarrassed to say it).
> It could be coherency issues in CAR with die(). In
> FS2 check your config and set Coherent to off. You need it on/auto in
> normal operation.

It's not just an FS2 issue. I don't even have one any more -- it seems
to have gotten lost in the move :-(

ron

[Marc Jones]

ron minnich wrote:
> On Jan 7, 2008 2:18 PM, Marc Jones  wrote:
> > I don't like taking the hlt() out of die(). Can you describe when you
> > where having issues?
>
> In the early days of LinuxBIOS, using an American Arium JTAG debugger,
> I found that I could not examine memory or, in fact, do much of
> anything on JTAG once the CPU halts. It's a real hassle to get to a
> hlt() and know that the info you need is in memory, and you can't get
> to it.
>
> I'd really prefer not to have a hlt instruction in there, but if it is
> a problem, I guess we can put it back.
>
> As for the UART, similar issue: I had problems years ago where I had
> to intuit what got sent to the UART because it did not make it out --
> it could get stuck in the FIFO or other intermediate places at times.
> I have found it handy to push a gazillion NULLS out to make sure I see
> all that is there (Actually, this is a decades old OS hacking trick
> ... dating back to, well, I'm embarrassed to say it).
> > It could be coherency issues in CAR with die(). In
> > FS2 check your config and set Coherent to off. You need it on/auto in
> > normal operation.
>
> It's not just an FS2 issue. I don't even have one any more -- it seems
> to have gotten lost in the move :-(
>
> ron

The hlt is really the right thing to do and I would rather it be in 
there. Correctly behaving jtag should be able to handle it. I understand 
clearing the fifo so do it before the hlt.

Marc

[ron minnich]

On Jan 7, 2008 3:57 PM, Marc Jones  wrote:
> The hlt is really the right thing to do and I would rather it be in
> there. Correctly behaving jtag should be able to handle it. I understand
> clearing the fifo so do it before the hlt.

OK. How about we do a bunch of  outs and a hlt().

I'll ack any patch you want to make.

ron

[Marc Jones]

ron minnich wrote:
> On Jan 7, 2008 3:57 PM, Marc Jones  wrote:
> > The hlt is really the right thing to do and I would rather it be in
> > there. Correctly behaving jtag should be able to handle it. I understand
> > clearing the fifo so do it before the hlt.
>
> OK. How about we do a bunch of  outs and a hlt().
>
> I'll ack any patch you want to make.
>
> ron

How about this?
Marc

[Peter Stuge]

On Tue, Jan 08, 2008 at 04:54:29PM -0700, Marc Jones wrote:
> How about this?
> Marc
> Add hlt() back into the die() function and update the comments.
>
> Signed-off-by: Marc Jones

Acked-by: Peter Stuge
> Index: LinuxBIOSv3/lib/console.c
>
> --- LinuxBIOSv3.orig/lib/console.c	2008-01-08 16:32:28.000000000 -0700
> +++ LinuxBIOSv3/lib/console.c	2008-01-08 16:48:52.000000000 -0700
> @@ -83,30 +83,37 @@
>  }
>
> /**
> Halt and loop due to a fatal error.
> There have been several iterations of this function.
> Halt and loop due to a fatal error.
> There have been several iterations of this function.
> The first simply did a hlt(). Doing a hlt() can make jtag debugging
> very difficult as one can not break into a hlt instruction on some CPUs.
> Second was to do a console_tx_byte of a NULL character.
> A number of concerns were raised about doing this idea.
> Third idea was to do an inb from port 0x80, the POST port. That design
> makes us very CPU-specific.
> very difficult as one can not break into a hlt instruction on some CPUs.
> Second was to do a console_tx_byte of a NULL character.
> A number of concerns were raised about doing this idea.
> Third idea was to do an inb from port 0x80, the POST port. That design
> makes us very CPU-specific.
> The fourth idea was just POSTING the same
> code over and over. That would erase the most recent POST code,
> hindering diagnosis.
> code over and over. That would erase the most recent POST code,
> hindering diagnosis.
> For now, for lack of a good alternative,
> we will continue to call console_tx_byte. We call with a NULL since
> it will clear any FIFOs in the path and won't clutter up the output,
> since NULL doesn't print a visible character on most terminal
> emulators.
> For now, for lack of a better alternative,
> we will call console_tx_byte ten times and then halt.
> Some CPU JTAG debbuggers might have problems but it is the right thing
> to do. We call with a NULL since it will clear any FIFOs in the path and
> won't clutter up the output, since NULL doesn't print a visible character
> on most terminal emulators.
> @param str A string to print for the error
> */
>
> void die(const char *str)
>  {
> int i;
> printk(BIOS_EMERG, str);
> while (1)
> console_tx_byte(0, (void *)0);
> while (1) {
> for (i = 0; i < 10; i++)
> 	console_tx_byte(0, (void *)0);
> hlt();
> }
>
> }

[Marc Jones]

Peter Stuge wrote:
> On Tue, Jan 08, 2008 at 04:54:29PM -0700, Marc Jones wrote:
> > How about this?
> > Marc
> > Add hlt() back into the die() function and update the comments.
> >
> > Signed-off-by: Marc Jones
>
> Acked-by: Peter Stuge

r550

[ron minnich]

Marc, here are the register dumps.

As a reminder, we seem to have no memory above 1M.

For the other discussion, iterate over the flash to find all the
headers is taking 2-3 seconds. Sorry, that's just too long. We need
the terminator in LAR; iterate over all of FLASH even once is just not
going to work. Even if you turn caching on, the initial load is going
to kill you.

Thanks

ron

[LinuxBIOS] [PATCH] v3: add a check for a termination member

[Peter Stuge]

On Fri, Jan 11, 2008 at 03:07:11AM +0100, Carl-Daniel Hailfinger wrote:
> > In practice, the marker is the most efficient method, but it is a
> > bit of an abomination IMO. :p
>
> Big question: Is v3 a matter of pride or speed or userfriendliness?
> I haven't decided yet. ;-)

All of the above, to me at least.
> > How do we handle the integrity issue when a single flash block
> > that contains the start of a lar file is erased at runtime? (Thus
> > breaking a link in the list.)
>
> If we really do erases at LB runtime, the person waiting for the
> erase surely has the time to rebuild the index/cache (which will
> probably need a fraction of the time needed for erase).

No matter who is erasing, the reality is that the marker is not
foolproof;

<carldani> for that to happen, power will have to fail exactly after
8 bytes of magic have been written to a sector

I think that the run-time index should always be created once we hit
the marker.

But we should try to avoid ever hitting the marker in the first
place. Perhaps by introducing certain requirements for the
"open-ended" special filenames that we currently have, ie. segment0
and any others.

On Thu, Jan 10, 2008 at 08:08:57PM -0800, ron minnich wrote:
> For the other discussion, iterate over the flash to find all the
> headers is taking 2-3 seconds. Sorry, that's just too long.

Fully agreed.
> We need the terminator in LAR; iterate over all of FLASH even once
> is just not going to work.

We should try to redesign so that it never happens in the common
case. For the corrupted flash case I think the best we can accomplish
is the runtime index, which will have to cost a bit of time, but at
least it will only be once per boot rather than once per file lookup.

Maybe it's not possible to redesign so that we can avoid the scan in
the common case. Then I would start looking at aligning members and
increasing 16 byte steps to maybe 4k or so.

//Peter

[Marc Jones]

ron minnich wrote:
> Marc, here are the register dumps.
>
> As a reminder, we seem to have no memory above 1M.

It looks like stage2 has problems. The MSRs are not setup beyond what 
stage1 did to allow stage2 to run.
Specificly, geodelx_pci_domain_phase2() is not running.

Can you send your entire output?
Marc