Re: [gentoo-sparc] Problem booting SPARC64 installcd on Blade2500 systems

[Hacking Network Solutions - Gentoo List Subscriptions]

Hi,

Further to my previous message I believe I have narrowed the problem
down to the following (see text below) commit.

I am basing this diagnosis on the fact that I can boot any kernel before
version 2.6.14, which was when this change was merged, with all more
recent kernels (up to git-sources-2.6.19_rc1-r3) failing with similar
but random error messages.  Whilst there were other changes which could
have caused this issue it seems like more than a coincidence to me that
this problem appeared in the same version as a re-write of the SPARC64
boot-up sequence.  

Unfortunately I know absolutely no SPARC64 assembler (and what I can
intuit from my, now woefully poorly, recollected knowledge of 6502 is
limited ;-) so I am unable to pursue this issue much further, other than
by filing a simple bug report obviously.

I generally like to be a bit more helpful than that when I file a bug
report though...  Anyone have any ideas?

Max

----------------------------------------------------------------------

commit bff06d552240ba7f5b49482a4865871d7bc03dc2
Author: David S. Miller
Date:   Thu Sep 22 20:11:33 2005 -0700

    [SPARC64]: Rewrite bootup sequence.
    
    Instead of all of this cpu-specific code to remap the kernel
    to the correct location, use portable firmware calls to do
    this instead.
    
    What we do now is the following in position independant
    assembler:
    
        chosen_node = prom_finddevice("/chosen");
        prom_mmu_ihandle_cache = prom_getint(chosen_node, "mmu");
        vaddr = 4MB_ALIGN(current_text_addr());
        prom_translate(vaddr, &paddr_high, &paddr_low, &mode);
        prom_boot_mapping_mode = mode;
        prom_boot_mapping_phys_high = paddr_high;
        prom_boot_mapping_phys_low = paddr_low;
        prom_map(-1, 8 * 1024 * 1024, KERNBASE, paddr_low);
    
    and that replaces the massive amount of by-hand TLB probing and
    programming we used to do here.
    
    The new code should also handle properly the case where the kernel
    is mapped at the correct address already (think: future kexec
    support).
    
    Consequently, the bulk of remap_kernel() dies as does the entirety
    of arch/sparc64/prom/map.S
    
    We try to share some strings in the PROM library with the ones used
    at bootup, and while we're here mark input strings to oplib.h routines
    with "const" when appropriate.
    
    There are many more simplifications now possible.  For one thing, we
    can consolidate the two copies we now have of a lot of cpu setup code
    sitting in head.S and trampoline.S.
    
    This is a significant step towards CONFIG_DEBUG_PAGEALLOC support.
    
    Signed-off-by: David S. Miller

----------------------------------------------------------------------
On Fri, 2006-10-13 at 11:19 +0200, Martin Andersen wrote:
> > Hi,
> >
> >
> > I'm trying to get the latest 2006.1 Sparc Universal bootcd (downloaded
> > yesterday) to run on some Blade2500 machines, without much success. I've tried
> > the Silver & Non-Silver models, and both the provided kernels (2.6.16 & 2.6.17)
> >
> > Some basic info regarding the specs (a prtdiag -v is also attached) --
> >
> > OpenBoot v4.17.1
> > 4096 Mb RAM
> > XVR-1200 GFX module (SUNW,375-3101)
> > Dual UltraSPARC IIIi 1280 Mhz CPUs
> > Broadcom NIC (bge0 in Solaris)
> >
> > Some have both a XVR-1200 and a XVR-100 module installed (I've tested on both)
> > The problem however seems to be related to the initial ramdisk --
> >
> >
> > <..begin BootPROM output..>
> >
> > Loading initial ramdisk (644214 bytes at 0x133F802000 phys, 0x40C00000 virt)...
> >
> > 	ERROR: Last Trap: Illegal Instruction
> >
> > Error -256
> >
> > 	ERROR: Last Trap: Memory Address not Aligned
> >
> >
> > <..end BootPROM output..>
> >
> > And then it throws you back to the ok prompt.  Any suggestions?  I'll be happy
> > to test any experimental livecd's and/or possible BootPROM fixes (env. settings,
> > disabling mem, etc.) I didn't do an asr-disable, as the previous problems seemed
> > to have to do with having more than 4Gb mem, which isn't the issue here.
> >
> >
> > Regards,
> >
>
> Hi,
>
> I have a similar problem trying to boot any kernel more recent than
> 2.6.11.  I am currently net-booting a 2.6.11-r8 kernel which works fine.
>
> The errors which I have experienced so far include:
>
> Illegal Instruction
> Memory Address not Aligned
> Data Access Exception
> Fast Instruction Access MMU Miss
> IDPROM: Warning, unknown format type!
>
> They seem to change depending on the size of the kernel image which I am
> attempting to boot and the version from which it was built.  Other than
> that there is no obvious rhyme nor reason.
>
> There is a forum post with similar (unresolved) issues here:
> http://forums.gentoo.org/viewtopic-p-3642405.html
>
> If 2.6.11 was still in portage I would suggest that you tried that but
> as it isn't....