Loongson 2E boot failure

Loongson 2E boot failure

[Colin Watson]

(I'm proxying this for Andreas Barth, who owns the machine in question.)

A build of current trunk on mips-loongson with the addition of
http://pastebin.com/download.php?i=uzXkNBTP fails to boot on a Loongson
2E system as follows:

  PMON> ifaddr rtl0 192.168.114.37
  bootp=8000b968
  PMON> load tftp://192.168.114.32/nephele/vmlinux
  Loading file: tftp://192.168.114.32/nephele/vmlinux (elf)
  0x801ffb60/538744 +
  Entry address is 801ffb60
  PMON> g
     zero      at       v0       v1       a0       a1       a2       a3
   00000000 00000000 00000000 00000000 00000001 aff7fd10 aff7fd18 80095ad0
      t0       t1       t2       t3       t4       t5       t6       t7
   00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      s0       s1       s2       s3       s4       s5       s6       s7
   00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      t8       t9       k0       k1       gp       sp       s8       ra
   00000000 00000000 00000000 00000000 00000000 aff7fcf0 00000000 80063f90
  80215244 7091101e .word   7091101e      # ...p

While I'm in the same city as the machine, is there anything I can do to
help debug this?

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

Re: Loongson 2E boot failure

[Colin Watson]

On Tue, Jul 26, 2011 at 02:12:30PM +0100, Colin Watson wrote:
> A build of current trunk on mips-loongson with the addition of
> http://pastebin.com/download.php?i=uzXkNBTP fails to boot on a Loongson
> 2E system as follows:
> 
>   PMON> ifaddr rtl0 192.168.114.37
>   bootp=8000b968
>   PMON> load tftp://192.168.114.32/nephele/vmlinux
>   Loading file: tftp://192.168.114.32/nephele/vmlinux (elf)
>   0x801ffb60/538744 +
>   Entry address is 801ffb60
>   PMON> g
>      zero      at       v0       v1       a0       a1       a2       a3
>    00000000 00000000 00000000 00000000 00000001 aff7fd10 aff7fd18 80095ad0
>       t0       t1       t2       t3       t4       t5       t6       t7
>    00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>       s0       s1       s2       s3       s4       s5       s6       s7
>    00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>       t8       t9       k0       k1       gp       sp       s8       ra
>    00000000 00000000 00000000 00000000 00000000 aff7fcf0 00000000 80063f90

It looks like this register dump may be irrelevant; it seems to appear
even on successful boots.

Given the lack of output, we've been narrowing down the problem by
inserting infinite loops at strategic points and testing whether we get
back to a PMON prompt or not.  So far it looks as though the failure is
somewhere in grub_font_init.

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

Re: Loongson 2E boot failure

[David Kuehling]

[-- Attachment #1: Type: text/plain, Size: 1031 bytes --]

>>>>> "Colin" == Colin Watson <cjwatson@ubuntu.com> writes:

> On Tue, Jul 26, 2011 at 02:12:30PM +0100, Colin Watson wrote:
[..]
> Given the lack of output, we've been narrowing down the problem by
> inserting infinite loops at strategic points and testing whether we
> get back to a PMON prompt or not.  So far it looks as though the
> failure is somewhere in grub_font_init.

I'm not too knowledgeable about grub, but have been messing around with
font configuration myself yesterday.  Just an idea: AFAICS
'grub-mkconfig' (i.e. 'update-grub') will set grub.cfg to load fonts
From /usr/{local/,}/share, not /boot, which failed in my case, and may
be causing trouble for you.  What happens if you put your fonts to /boot
and update grub.cfg accordingly?

I.e. add to (/usr/local)/etc/default/grub the line

GRUB_FONT=/boot/grub/fonts/euro.pf2

and run update-grub, 

David
-- 
GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk.gpg
Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Loongson 2E boot failure

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 1271 bytes --]

On 26.07.2011 17:53, David Kuehling wrote:
>>>>>> "Colin" == Colin Watson <cjwatson@ubuntu.com> writes:
>> On Tue, Jul 26, 2011 at 02:12:30PM +0100, Colin Watson wrote:
> [..]
>> Given the lack of output, we've been narrowing down the problem by
>> inserting infinite loops at strategic points and testing whether we
>> get back to a PMON prompt or not.  So far it looks as though the
>> failure is somewhere in grub_font_init.
> I'm not too knowledgeable about grub, but have been messing around with
> font configuration myself yesterday.  Just an idea: AFAICS
> 'grub-mkconfig' (i.e. 'update-grub') will set grub.cfg to load fonts
> From /usr/{local/,}/share, not /boot, which failed in my case, and may
> be causing trouble for you.  What happens if you put your fonts to /boot
> and update grub.cfg accordingly?
>
> I.e. add to (/usr/local)/etc/default/grub the line
>
> GRUB_FONT=/boot/grub/fonts/euro.pf2
>
> and run update-grub, 
The failure seemingly is at initing the subsystem, way before loading
any fonts.
> David
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

Re: Loongson 2E boot failure

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 1663 bytes --]

On 26.07.2011 17:25, Colin Watson wrote:
> On Tue, Jul 26, 2011 at 02:12:30PM +0100, Colin Watson wrote:
>> A build of current trunk on mips-loongson with the addition of
>> http://pastebin.com/download.php?i=uzXkNBTP fails to boot on a Loongson
>> 2E system as follows:
>>
>>   PMON> ifaddr rtl0 192.168.114.37
>>   bootp=8000b968
>>   PMON> load tftp://192.168.114.32/nephele/vmlinux
>>   Loading file: tftp://192.168.114.32/nephele/vmlinux (elf)
>>   0x801ffb60/538744 +
>>   Entry address is 801ffb60
>>   PMON> g
>>      zero      at       v0       v1       a0       a1       a2       a3
>>    00000000 00000000 00000000 00000000 00000001 aff7fd10 aff7fd18 80095ad0
>>       t0       t1       t2       t3       t4       t5       t6       t7
>>    00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>>       s0       s1       s2       s3       s4       s5       s6       s7
>>    00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>>       t8       t9       k0       k1       gp       sp       s8       ra
>>    00000000 00000000 00000000 00000000 00000000 aff7fcf0 00000000 80063f90
> It looks like this register dump may be irrelevant; it seems to appear
> even on successful boots.
>
> Given the lack of output, we've been narrowing down the problem by
> inserting infinite loops at strategic points and testing whether we get
> back to a PMON prompt or not.  So far it looks as though the failure is
> somewhere in grub_font_init.
>
Looks like memory allocations are wrong. Try hardcoding heap at e.g.
81000000-82000000


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

Re: Loongson 2E boot failure

[Colin Watson]

On Tue, Jul 26, 2011 at 06:04:44PM +0200, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> On 26.07.2011 17:25, Colin Watson wrote:
> > Given the lack of output, we've been narrowing down the problem by
> > inserting infinite loops at strategic points and testing whether we get
> > back to a PMON prompt or not.  So far it looks as though the failure is
> > somewhere in grub_font_init.
> 
> Looks like memory allocations are wrong. Try hardcoding heap at e.g.
> 81000000-82000000

Sorry, I've not had to mess with this before.  Can you point me to what
I'd need to change to hardcode a specific heap region?

Thanks,

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

Re: Loongson 2E boot failure

[Robert Millan]

2011/7/26 Colin Watson <cjwatson@ubuntu.com>:
>> Looks like memory allocations are wrong. Try hardcoding heap at e.g.
>> 81000000-82000000
>
> Sorry, I've not had to mess with this before.  Can you point me to what
> I'd need to change to hardcode a specific heap region?

Try replacing grub_machine_mmap_iterate() with something like:

grub_err_t
grub_machine_mmap_iterate (grub_memory_hook_t hook)
{
  hook (0x81000000, 82000000, GRUB_MEMORY_AVAILABLE);
  return GRUB_ERR_NONE;
}

-- 
Robert Millan

Re: Loongson 2E boot failure

[Andreas Barth]

* Robert Millan (rmh@gnu.org) [110811 19:10]:
> 2011/7/26 Colin Watson <cjwatson@ubuntu.com>:
> >> Looks like memory allocations are wrong. Try hardcoding heap at e.g.
> >> 81000000-82000000
> >
> > Sorry, I've not had to mess with this before.  Can you point me to what
> > I'd need to change to hardcode a specific heap region?
> 
> Try replacing grub_machine_mmap_iterate() with something like:
> 
> grub_err_t
> grub_machine_mmap_iterate (grub_memory_hook_t hook)
> {
>   hook (0x81000000, 82000000, GRUB_MEMORY_AVAILABLE);
>   return GRUB_ERR_NONE;
> }

done so, but the failure is still the same. (I'm happy to try
different variants, but please tell me how I should produce them.)



Andi

Re: Loongson 2E boot failure

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 1050 bytes --]

On 03.08.2011 13:21, Robert Millan wrote:
> 2011/7/26 Colin Watson <cjwatson@ubuntu.com>:
>>> Looks like memory allocations are wrong. Try hardcoding heap at e.g.
>>> 81000000-82000000
>> Sorry, I've not had to mess with this before.  Can you point me to what
>> I'd need to change to hardcode a specific heap region?
> Try replacing grub_machine_mmap_iterate() with something like:
>
> grub_err_t
> grub_machine_mmap_iterate (grub_memory_hook_t hook)
> {
>   hook (0x81000000, 82000000, GRUB_MEMORY_AVAILABLE);
>   return GRUB_ERR_NONE;
> }
>
This code is wrong for at least 4 reasons:
1) 0x8.... is just to access kseg0, it's not part of physical address
2) second argument is a size, not end
3) and it's lacking 0x
4) on yeeloong memory init doesn't use mmap.
Correct way is to replace:
  grub_mm_init_region ((void *) modend, (grub_arch_memsize << 20)
               - (modend - GRUB_ARCH_LOWMEMVSTART));
with:
  grub_mm_init_region (0x81000000, 16 << 20);



-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

Re: Loongson 2E boot failure

[Andreas Barth]

* Vladimir 'φ-coder/phcoder' Serbinenko (phcoder@gmail.com) [110812 15:15]:
> On 03.08.2011 13:21, Robert Millan wrote:
> > 2011/7/26 Colin Watson <cjwatson@ubuntu.com>:
> >>> Looks like memory allocations are wrong. Try hardcoding heap at e.g.
> >>> 81000000-82000000
> >> Sorry, I've not had to mess with this before.  Can you point me to what
> >> I'd need to change to hardcode a specific heap region?
> > Try replacing grub_machine_mmap_iterate() with something like:
> >
> > grub_err_t
> > grub_machine_mmap_iterate (grub_memory_hook_t hook)
> > {
> >   hook (0x81000000, 82000000, GRUB_MEMORY_AVAILABLE);
> >   return GRUB_ERR_NONE;
> > }
> >
> This code is wrong for at least 4 reasons:
> 1) 0x8.... is just to access kseg0, it's not part of physical address
> 2) second argument is a size, not end
> 3) and it's lacking 0x
> 4) on yeeloong memory init doesn't use mmap.
> Correct way is to replace:
>   grub_mm_init_region ((void *) modend, (grub_arch_memsize << 20)
>                - (modend - GRUB_ARCH_LOWMEMVSTART));
> with:
>   grub_mm_init_region (0x81000000, 16 << 20);

No real behaviour change - still fails within grub_font_init (using
the for(;;);-method).

Only change compared with
http://lists.gnu.org/archive/html/grub-devel/2011-07/msg00085.html is
that the last line on the vga console is now
80211ebc 7091181e .word   7091181e     # ...p



Andi

Loongson 2E support available (was Re: Loongson 2E boot failure)

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 281 bytes --]

As a followup: we fixed the issues on IRC and now it's committed upstream.

> No real behaviour change - still fails within grub_font_init (using
> the for(;;);-method).
>
Was bad compile option (-march=loongson2f)

-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]