Port-ofppc archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: ofwboot, why does it work?



Artyom Tarasenko wrote:

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

Ok, great! I can also confirm that it works on my Pegasos.


>>The shown value for 'buf' seems
>> a bit high.
>
> I enabled -DOFW_DEBUG. Could this be the reason?

Quite likely. The additional debugging code will move 'stack' to a higher
address, so that 'buf' is getting inside the .text section.

But it's good that you tested it. Otherwise we wouldn't have noticed the
bug.


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

As neither nm nor objdump worked with ofwboot, I had to use readelf. It
prints some warnings but otherwise works fine.


> The binary compiled with ldscript is not recognized as a proper ELF,
> so I couldn't use objdump or gdb on it:

Yes, I had the same problem. I guess the reason is that ofwboot has a
hacked-in .note section at the beginning of .text, which confuses some
tools, but is required by certain IBM machines to boot.


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

I don't understand. Why should "copy-out" be used on 'buf'? AFAICS ofdev.c
passes 'buf' to OF_read() to read a block from disk.


> Can you please execute the following commands in at the OF prompt on
> your Pegasos II :
>
> dev /client-services
> see getprop

"getprop       func[0x1163]"


> see copy-out

"no such symbol in tables"

This word doesn't exist in SmartFirmware.


> 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 not because it is eating the stack, but because the .text section
gets larger and 'stack' is moving to a higher address, so other parts of
the main program are destroyed when accessing 'buf'.


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

Maybe something like this:

  register_t before,after;

  __asm volatile("mr %0,1" : "=r"(before));
  printf(" ... ");
  __asm volatile("mr %0,1" : "=r"(after));
  if (before != after)
    panic();

But I'm sure this isn't the case. The PPC V.4-ABI rarely uses the stack at
all, when calling a function. Up to 8 arguments can be passed in registers.

-- 
Frank Wille



Home | Main Index | Thread Index | Old Index