Re: ofwboot, why does it work?

[Frank Wille <frank%phoenix.owl.de@localhost>]

On Wed, 17 Sep 2014 17:22:43 +0200
Artyom Tarasenko <atar4qemu%gmail.com@localhost> wrote:

> The ofwboot version 1.12 doesn't work for me, but I see some reports
> that it works for other people.

Yes. It always worked on my Pegasos II, and it was also tested on an
IBM RS6000 some years ago.


> I wonder how:
> 
> in arch/ofppc/stand/ofwboot/Locore.c the stack is defined small
> int stack[8192/4 + 4] __attribute__((__aligned__ (4), __used__));
> 
> and then in arch/ofppc/stand/ofwboot/ofdev.c
> 
> int devopen() {
> ...
> /* allow disk blocks up to 65536 bytes */
>   char buf[DEV_BSIZE<<7];
> 
> This is much larger than the allocated stack,

You are right. That doesn't look good. Certainly my fault, as I didn't
think about the stack size, when extending the buffer.

The macppc ofwboot has the same small stack, but 'buf' is just DEV_BSIZE
(512 Bytes).

Does it improve your situation, when you increase th stack size, let's
say to 128K?

Locore.c:
int stack[131072/4 + 4] __attribute__((__aligned__ (4), __used__));

--- ofwstart.S  28 Apr 2008 20:23:31 -0000      1.3
+++ ofwstart.S  18 Sep 2014 09:19:23 -0000
@@ -95,9 +95,8 @@
 _start:
        sync
        isync
-       lis     %r1,stack@ha
-       addi    %r1,%r1,stack@l
-       addi    %r1,%r1,8192
+       lis     %r1,stack+131072@ha
+       addi    %r1,%r1,stack+131072@l

        mfmsr   %r8
        li      %r0,0

I will also test that on my Pegasos and commit it this weekend, when
successful.


> and on my machine I get
> (gdb) x buf
> 0x2027c <OF_open+40>:   0x48007e3d
> 
> As a result, as soon as the 'buf' is written, it smashes the OF_*
> functions.

Did you try an official ofwboot binary? The shown value for 'buf' seems
a bit high. I just compiled a 7-beta ofwboot and the symbols are:

   190: 0002e04c  8208 OBJECT  GLOBAL DEFAULT    7 stack
   192: 00020254    80 FUNC    GLOBAL DEFAULT    1 OF_open

The ofwboot ldscript defines the program start at 0x20000. With 'stack'
at 0x2e04c and an initial stack pointer at 0x2e04c+8208 = 0x3005c, the
'buf' array on the stack will be somewhere before 0x3005c-65536 = 0x2005c.
Depending on the size of the stack-frames, which are already present, I
could imagine that 'buf' points to an address between 0x1f000 and 0x20000
on my Pegasos II, so it works "by luck", when only the first part of 'buf'
is used.

Don't know why your configuration is different, but I agree that the stack
should be fixed. :)

-- 
Frank Wille