Re: ofwboot, why does it work?

On Thu, Sep 18, 2014 at 11:24 AM, Frank Wille <[email protected]> wrote:
> 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
>

Yes, changing the stack size to 128K makes it work.

> Did you try an official ofwboot binary?

Yes, and also the ones on 6.1.3 and 6.1.4 install CDs. They all hang
on getting OF properties.

>The shown value for 'buf' seems
> a bit high.

I enabled -DOFW_DEBUG. Could this be the reason?

> 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

Where can I see them? To see the addresses in the debugger, I had to
compile ofwboot without ldscript.
The binary compiled with ldscript is not recognized as a proper ELF,
so I couldn't use objdump or gdb on it:

$ file /usr/obj/sys/arch/ofppc/stand/ofwboot/ofwboot
/usr/obj/sys/arch/ofppc/stand/ofwboot/ofwboot: ERROR: ELF 32-bit MSB
executable, PowerPC or cisco 4500, (SYSV), statically linked, bad note
name size 0xffff35a8error reading (Inappropriate file type or format)
$ /usr/obj/tooldir.NetBSD-6.1.4-amd64/bin/powerpc--netbsd-objdump -f
/usr/obj/sys/arch/ofppc/stand/ofwboot/ofwboot
/usr/obj/tooldir.NetBSD-6.1.4-amd64/bin/powerpc--netbsd-objdump:
/usr/obj/sys/arch/ofppc/stand/ofwboot/ofwboot: File truncated

> 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.

This is a very interesting point. Looking at the base OFW source for
PReP (and this base was presumably used by IBM and Motorola) I see
that 'buf' will always be used as a whole. The word copy-out clears
the whole buffer before writing into it. If it works the same way on
your firmware, the 'buf' must be somewhere around 0x10000.

Can you please execute the following commands in at the OF prompt on
your Pegasos II :

dev /client-services
see getprop
see copy-out
device-end

In my case getprop is using copy-out, and

ok see copy-out
: copy-out
   dup >r 2swap swap 2dup erase rot min cmove r>
;

copy-out does 'erase' for the whole buffer.

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

Well it could be that my firmware is eating the stack. At first I put
some printfs, and the more printfs I put, the earlier ofwboot died.

That's why I consider the unfixed ofwboot as a good test case.

Do you have a suggestion how I can test whether the stack pointer
before calling printf is the same as after?

-- 
Regards,
Artyom Tarasenko

SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu