Re: Boot of 1.0.9 fails on Sun Ultra 1 (actually, Ultra 30)

Re: Boot of 1.0.9 fails on Sun Ultra 1 (actually, Ultra 30)

[Rick Richardson]

Rick Richardson writes...
> Dear UltraPenguins:
> 
> We dug up an UltraSparc machine here that identifies itself on
> the boot screen as:
> 
> 	Sun Ultra 1 UPA/PCI (UltraSPARC-II 248 Mhz)
> 
> It has 128 MB's of RAM in it.
> 

[snip]

> At the "ok" prompt, we booted off the network using the following
> command.  The machine sucked down the boot image from the tftp server,
> and then ended with an error message "Couldn't get translation
> property".  Here is what is on the screen:
> 
> 	ok boot /pci@1f,4000/pci@4/SUNW,hme@0,1
> 	Boot device: /pci@1f,4000/pci@4/SUNW,hme@0,1      File and args:
> 	27a800 TILO
> 
> 	Couldn't get translation property
> 	Program terminated
> 	ok
> 
> 
> Does anybody know what this means and how to correct the problem?


Hmm.  The silence on this problem is, well, scary.  Maybe
nobody is actually working on UltraPenguin anymore?

I did find out that the machine in question is an Ultra-30, if
that helps.  Also, the message is apparently coming from Linux
itself:

/usr/src/linux-2.1.107/linux/arch/sparc64/mm/init.c:

...


#define MAX_TRANSLATIONS 64
static inline void inherit_prom_mappings(void)
{
        struct linux_prom_translation transl[MAX_TRANSLATIONS];
        pgd_t *pgdp;
        pmd_t *pmdp;
        pte_t *ptep;
        int node, n, i;

        node = prom_finddevice("/virtual-memory");
        if ((n = prom_getproperty(node, "translations", (char *) transl,
                                  sizeof(transl))) = -1) {
                prom_printf("Couldn't get translation property\n");
                prom_halt();
        }


I have no real experience with Ultra's, but if somebody could
give me the low down on what this code is trying to do, I could
investigate it further.

-Rick

-- 
Rick Richardson        Sr. Techno-something   Its 1993 again, and I don't have
Digi Intl.             Email: rick@dgii.com   a Web page.
11001 Bren Rd. East    Fax:   (612) 912-4955  
Minnetonka, MN 55343   Tel:   (612) 912-3212  

Re: Boot of 1.0.9 fails on Sun Ultra 1 (actually, Ultra 30)

[Jakub Jelinek]

> Hmm.  The silence on this problem is, well, scary.  Maybe
> nobody is actually working on UltraPenguin anymore?

No, the issue is:
the problem is already solved in the CVS kernel, at least I think it is one
of the bugs that were fixed.
Those kernels are already in 2.1.106 rpms, but not yet in tftpboot.img, as a
couple of problems arised with rpm 2.5 and so some things in the installer
should be fixed first.
As 2.1.107 merged fbcon, we have to get that working first (as currently CVS
tree does not even compile for SPARC), after that we'll make new
tftpboot.img...

Cheers,
    Jakub
___________________________________________________________________
Jakub Jelinek | jj@sunsite.mff.cuni.cz | http://sunsite.mff.cuni.cz
Administrator of SunSITE Czech Republic, MFF, Charles University
___________________________________________________________________
Ultralinux - first 64bit OS to take full power of the UltraSparc
Linux version 2.1.106 on a sparc64 machine (498.80 BogoMips).
___________________________________________________________________

Re: Boot of 1.0.9 fails on Sun Ultra 1 (actually, Ultra 30)

[Rick Richardson]

Greg Onufer writes...
> On Fri, 26 Jun 1998 16:01:17 -0500 (CDT)  Rick Richardson wrote:
> > #define MAX_TRANSLATIONS 64
> > static inline void inherit_prom_mappings(void)
> > {
> >         struct linux_prom_translation transl[MAX_TRANSLATIONS];
> >         pgd_t *pgdp;
> >         pmd_t *pmdp;
> >         pte_t *ptep;
> >         int node, n, i;
> > 
> >         node = prom_finddevice("/virtual-memory");
> >         if ((n = prom_getproperty(node, "translations", (char *) transl,
> >                                   sizeof(transl))) = -1) {
> >                 prom_printf("Couldn't get translation property\n");
> >                 prom_halt();
> >         }
> > 
> > 
> > I have no real experience with Ultra's, but if somebody could
> > give me the low down on what this code is trying to do, I could
> > investigate it further.
> 
> It's simply trying to read the "translations" property of the
> virtual-memory node in the OpenBoot device tree.  When it "crashes",
> type "cd /virtual-memory" at the "ok" prompt and then type
> ".properties".  See how big the translations property is and increase
> MAX_TRANSLATIONS accordingly.  64 seems way too small and having a
> fixed-sized buffer like that isn't very robust.

OK, here is what we found out:

With Solaris running, I looked at .properties as stated above.
The translations property seemed to list about 150 lines looking like

...
00000000 6001c000 00000000 00002000 80000000 67ea4036
00000000 6001a000 00000000 00002000 80000000 67ea6036 ...


So the number needs to be at least 150, if not unlimited??

-Rick


-- 
Rick Richardson        Sr. Techno-something   Its 1993 again, and I don't have
Digi Intl.             Email: rick@dgii.com   a Web page.
11001 Bren Rd. East    Fax:   (612) 912-4955  
Minnetonka, MN 55343   Tel:   (612) 912-3212