[OpenBIOS] [SOLVED] ppc64 boot issues

Andreas Färber andreas.faerber at web.de
Mon Dec 13 10:27:33 CET 2010


Hi,

Am 09.12.2010 um 11:30 schrieb Mark Cave-Ayland:

> Andreas Färber wrote:
>
>> Here's what I found out so far:
>> * a breakpoint for bootinfo_loader_init() or so is not reached
>> * The "Trying" comes from (encode-bootpath) in forth/debugging/ 
>> client.fs
>> * `debug (encode-bootpath) boot` does not return from open-dev
>> * `debug open-dev` does not return from path-resolution
>> * path-resolution gets called "endlessly" (5+ times single-stepping  
>> it), the hang occurred after successfully returning from some  
>> instance (after having successfully done so for a previous instance)
>> Does anyone have a hunch what might be going wrong? Or tips how to  
>> further debug?
>
> Do you mean path-resolution or (path-resolution)? IIRC (path- 
> resolution) is called recursively for each level of the device so  
> this could potentially happen depending upon the device tree.

path-resolution.

> The "cd:,\\:tbxi" device is a reference to finding a file on a HFS  
> file system with a particular filesystem label/type in the MacOS  
> System folder to boot. So given that CONFIG_HFS and CONFIG_HFSP are  
> set for PPC64, if you're trying to access a HFS file system then it  
> should be hitting hfs_fs.c::hfs_files_open() or  
> hfsp_fs.c::hfsp_files_open() - maybe there are some 64-bit related  
> errors in the code there? Tracing through libopenbios/load.c may  
> help here too.

I did end up in iso9660_files_open() and did get into  
iso9660_opendir() to the "return NULL;" for the iso9660_get_node() ==  
NULL case and then hit an error seemingly during the epilogue  
(restgpr...).

So I tried using the grubfs implementation instead and get to "Trying  
cd:,\ppc\chrp\bootfile.exe..." (got that once during single-stepping  
through Forth, too, though).

I get to start.s:call_elf() and applied some fixes there. Same for  
start.S:of_client_callback. client.c carelessly assumed that the  
prom_args_t struct can hold char* and long but for ppc64 both need to  
be int. I've drafted an accessor function, the DEBUG_CIF code still  
does not compile due to lots of format string assumptions that now  
break - I'm considering a FMT_prom_argx to fix that. A prom_arg_t  
typedef for the int vs. long thing also sounds intriguing.

load.c:load() is not called.

> Alternatively if this is not the case, you may be hitting some  
> generic memory corruption. I had a similar error on SPARC64 with  
> strange behaviour caused by the dictionary being accidentally  
> overwritten.

Yeah, same thing here. When called back from the client, r2 was not  
set up as TOC pointer so that client.c:of_client_interface() would  
cause 'unpredictable' damage to memory.

The following branch boots AIX as before (not finding /rtas). Debian  
starts to boot but serial complains ">> out of malloc memory  
(11d28)!" (same if increased to -m 1024) and it appears to stop  
shortly after, last line is "returning from prom_init".

http://repo.or.cz/w/openbios/afaerber.git/shortlog/refs/heads/ppc64-boot

Thanks for pointing me in the right direction! I'll try to clean this  
up, but it'll take some days.

Andreas


More information about the OpenBIOS mailing list