Re: again 2.3.28

Re: again 2.3.28

[Benjamin Herrenschmidt]

On Wed, Nov 17, 1999, David N. Welton <davidw@linuxcare.com> wrote:

>So, we can't use prom_print to print checkpoints and we can't use
>printk yet.

if using BootX, you can use prom_print after mmu_init provided that you
make sure the fb is mapped (look at the function in prom.c for that, it's
called by xmon initialisation).

If you are not using BootX, then you can grab code that make prom_print
available the same way it does with BootX, but with OF. (Basically, it
fills a fake boot_info structure for use by the display code from infos
returned by OF). The code for that is in my iBook patches, look at the
prom.c patches.

In both case, you have to take care of mapping the fb.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

again 2.3.28

[Andreas Tobler]

Hi,

my investigation brought me to the point, where I think the break must
be between 
prom_init (in prom.c called from Head.S) and identify_machine (in
setup.c called from Head.S)
This is my interpretation of the code in Head.S? I certainly could be wrong.....
Any ideas?

Thanks,
Andreas
-- 
| Andreas Tobler				
| CH-8004 Zuerich 							
| E-Mail: andreas.tobler@alcatel.ch	  a.tobler@schweiz.ch
-----------------------------------------------------------


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: again 2.3.28

[David N. Welton]

On Wed, Nov 17, 1999 at 07:53:34PM +0100, Andreas Tobler wrote:

> my investigation brought me to the point, where I think the break
> must be between prom_init (in prom.c called from Head.S) and
> identify_machine (in setup.c called from Head.S) This is my
> interpretation of the code in Head.S? I certainly could be
> wrong.....  Any ideas?

Not really... I have the same problem, and no one seems to have any
idea what is causing it:-( I traced it to the same place, but the
problem is that you can't really even print anything, (at least not
with my limited knowledge), because of the following in head.S:

/*
 * Use the first pair of BAT registers to map the 1st 16MB
 * of RAM to KERNELBASE.  From this point on we can't safely
 * call OF any more.
 */
 lis	r11,KERNELBASE@h
.
.
.

So, we can't use prom_print to print checkpoints and we can't use
printk yet.

Ciao,
-- 
David N. Welton, Developer, Linuxcare, Inc.
415.354.4878 x241 tel, 415.701.7457 fax
davidw@linuxcare.com, http://www.linuxcare.com/
Linuxcare. At the center of Linux.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: again 2.3.28

[Ani Joshi]

On Wed, 17 Nov 1999, David N. Welton wrote:

> So, we can't use prom_print to print checkpoints and we can't use
> printk yet.

	you can use prom_print to print until start_kernel, then you can
use printk because console_init() is done very early (unless its dieing
before that which would really suck), but i'm pretty sure you should be
able to prom_print until then.  how are you calling your prints?

btw, what machine is this?


ani


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: again 2.3.28

[David N. Welton]

On Wed, Nov 17, 1999 at 11:43:40AM -0800, Ani Joshi wrote:

> On Wed, 17 Nov 1999, David N. Welton wrote:

> > So, we can't use prom_print to print checkpoints and we can't use
> > printk yet.
 
> you can use prom_print to print until start_kernel, 

This is from arch/ppc/kernel/prom.c :

 * Because OF may have mapped I/O devices into the area starting at
 * KERNELBASE, particularly on CHRP machines, we can't safely call
 * OF once the kernel has been mapped to KERNELBASE.  Therefore all
 * OF calls should be done within prom_init(), and prom_init()
 * and all routines called within it must be careful to relocate
 * references as necessary.

This is indeed a CHRP machine, an RS6K F50, to be precise.

So, according to the people who wrote this code, you cannot do that.

> then you can use printk because console_init() is done very early
> (unless its dieing before that which would really suck), but i'm
> pretty sure you should be able to prom_print until then.  how are
> you calling your prints?

I was calling them with 'bl myfunc', which was defined as void myfunc
() and contained a call to prom_print.

Thanks,
-- 
David N. Welton, Developer, Linuxcare, Inc.
415.354.4878 x241 tel, 415.701.7457 fax
davidw@linuxcare.com, http://www.linuxcare.com/
Linuxcare. At the center of Linux.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: again 2.3.28

[Ani Joshi]

On Wed, 17 Nov 1999, David N. Welton wrote:

> This is indeed a CHRP machine, an RS6K F50, to be precise.


	ahh, i assumed you were on a pmac using bootx text console, well
yes, in that case you're
right, you cannot use prom_print there, *but*, benh has recently done
something about this, check his ibook patches or somewhere on this page
for this.  he said he wanted to get this done, but i'm not sure if he has
finished it yet.


ani


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: again 2.3.28

[David N. Welton]

Ok... hmmm, this may mean something, but I'll leave it to others to
tell me if I've found something or if I'm just on crack.

copy_and_flush:
	addi	r5,r5,-4
	addi	r6,r6,-4
4:	li	r0,8
	mtctr	r0
3:	addi	r6,r6,4			/* copy a cache line */
	lwzx	r0,r6,r4
	stwx	r0,r6,r3
	bdnz	3b
	dcbst	r6,r3			/* write it to memory */
	sync
	icbi	r6,r3			/* flush the icache line */
	cmplw	0,r6,r5
	bl	davidw_debug	   <<<<<<<<< POSITION 1	
	blt	4b
	bl	davidw_debug	   <<<<<<<<< POSITION 2
	isync
	addi	r5,r5,4
	addi	r6,r6,4
	blr

When davidw_debug is in position 1, it actually exits the boot load
back into the firmware with a 'default catch' or something like that.
If it is in position 2, it just hangs and does nothing (possibly
continuing with this loop forever?).

Is this significant?  Or am I just messing up something else?

Ciao,
-- 
David N. Welton, Developer, Linuxcare, Inc.
415.354.4878 x241 tel, 415.701.7457 fax
davidw@linuxcare.com, http://www.linuxcare.com/
Linuxcare. At the center of Linux.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: again 2.3.28

[David Edelsohn]

	You're just messing with something.  Most likely you are
disrupting the condition register bits being used by the "blt" branch.

David

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: again 2.3.28

[David N. Welton]

On Wed, Nov 17, 1999 at 11:26:39PM -0500, David Edelsohn wrote:
 
> 	You're just messing with something.  Most likely you are
> disrupting the condition register bits being used by the "blt"
> branch.

Hmm... well, the 'davidw_debug' is supposed to crap out.  It's a
function that calls printk, which I have been told is not really
available at that point in the game.  I have noticed that I get a nice
'default catch' when it hits the printk, whereas, if I move the
function further down the list of things that happens, it apparently
isn't reached (or at least nothing is printed), as nothing crashes.

Maybe I should use a function that is guaranteed to crash?

Anyway, by moving this 'bomb' function around and rebooting way too
much, I narrowed down a region of code that I don't get the crash
after (meaning it hasn't reached my crash function or that it is
suddently ok to call it).  That's what I posted...

It's been quite time consuming, and not very elegant, but lacking
anything else, it's all I have really (supposedly, someone is getting
me a null modem cable tommorow so that I can try and connect to the
serial port).

Thanks,
-- 
David N. Welton, Developer, Linuxcare, Inc.
415.354.4878 x241 tel, 415.701.7457 fax
davidw@linuxcare.com, http://www.linuxcare.com/
Linuxcare. At the center of Linux.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: again 2.3.28

[Ani Joshi]

	i messed aroudn with .28 last night and it seems to die *after*
mmu_init but before start_kernel, you can test this by making and export a
function which simply prom_print("got here\n");'s and then calling it from
head.S with the asm "bl	my_got_here_function".  it also gets passed
loading the new hash table.

thats all i could do last nite cause i left my serial cable at work :(
what i would suggest is that you first apply my arch/ppc/mm/init.c fix and
then use a serial debug console (make sure you have this in your kernel),
and use kernel arg "console=ttyS0" and have a machine with a terminal
running nearby.  it could be dieing early in start_kernel...


ani


On Wed, 17 Nov 1999, Andreas Tobler wrote:

> 
> Hi,
> 
> my investigation brought me to the point, where I think the break must
> be between 
> prom_init (in prom.c called from Head.S) and identify_machine (in
> setup.c called from Head.S)
> This is my interpretation of the code in Head.S? I certainly could be wrong.....
> Any ideas?
> 
> Thanks,
> Andreas
> -- 
> | Andreas Tobler				
> | CH-8004 Zuerich 							
> | E-Mail: andreas.tobler@alcatel.ch	  a.tobler@schweiz.ch
> -----------------------------------------------------------
> 
> 


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: again 2.3.28

[Geert Uytterhoeven]

On Wed, 17 Nov 1999, Ani Joshi wrote:
> 	i messed aroudn with .28 last night and it seems to die *after*
> mmu_init but before start_kernel, you can test this by making and export a
> function which simply prom_print("got here\n");'s and then calling it from
> head.S with the asm "bl	my_got_here_function".  it also gets passed
> loading the new hash table.

Probably it depends on the machine, since I get up to free_all_bootmem(), which
is called by mem_init() in start_kernel(). OK, I have a different box (CHRP)
and was actually speaking about 2.3.27, but the 2.3.28 patch doesn't contain
relevant changes.

Gr{oetje,eeting}s,
--
Geert Uytterhoeven -- Linux/{m68k~Amiga,PPC~CHRP} -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: again 2.3.28

[Ani Joshi]

On Wed, 17 Nov 1999, Geert Uytterhoeven wrote:

> Probably it depends on the machine, since I get up to free_all_bootmem(), which
> is called by mem_init() in start_kernel(). OK, I have a different box (CHRP)
> and was actually speaking about 2.3.27, but the 2.3.28 patch doesn't contain
> relevant changes.

	could your problem in free_all_bootmem() be caused by
"if(!bootmem_map) BUG();"?  because in do_init_bootmem()
it frees the bootmem bitmap (which is called very early).  
is it trying to free something thats already been free'd?

its possible this is happening on pmacs also...


ani


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: again 2.3.28

[Geert Uytterhoeven]

On Wed, 17 Nov 1999, Ani Joshi wrote:
> On Wed, 17 Nov 1999, Geert Uytterhoeven wrote:
> > Probably it depends on the machine, since I get up to free_all_bootmem(), which
> > is called by mem_init() in start_kernel(). OK, I have a different box (CHRP)
> > and was actually speaking about 2.3.27, but the 2.3.28 patch doesn't contain
> > relevant changes.
> 
> 	could your problem in free_all_bootmem() be caused by
> "if(!bootmem_map) BUG();"?  because in do_init_bootmem()
> it frees the bootmem bitmap (which is called very early).  
> is it trying to free something thats already been free'd?
> 
> its possible this is happening on pmacs also...

As I posted before (last Friday), it gets further than that.

I'll try Paul's tree...

Gr{oetje,eeting}s,
--
Geert Uytterhoeven -- Linux/{m68k~Amiga,PPC~CHRP} -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/