SILO & Ext4

SILO & Ext4

[Alexander Beregalov]

Hi

I found that Sparc cannot boot when rootfs is Ext4 (converted from ext3).

Is anyone working on adding ext4 support to silo?
Is it hard to implement?

SILO & Ext4

[Alexander Beregalov]

Hi

I found that Sparc cannot boot when rootfs is Ext4 (converted from ext3).

Is anyone working on adding ext4 support to silo?
Is it hard to implement?

Re: SILO & Ext4

[David Miller]

From: Alexander Beregalov <a.beregalov@gmail.com>
Date: Mon, 1 Jun 2009 14:33:02 +0400

> I found that Sparc cannot boot when rootfs is Ext4 (converted from ext3).
> 
> Is anyone working on adding ext4 support to silo?
> Is it hard to implement?

I'm personally not going to work on this, that's for sure :-)
Although it shouldn't be hard.

All of my effort has been spent on adding sparc support to
grub2.

Re: SILO & Ext4

[David Miller]

From: Alexander Beregalov <a.beregalov@gmail.com>
Date: Mon, 1 Jun 2009 14:33:02 +0400

> I found that Sparc cannot boot when rootfs is Ext4 (converted from ext3).
> 
> Is anyone working on adding ext4 support to silo?
> Is it hard to implement?

I'm personally not going to work on this, that's for sure :-)
Although it shouldn't be hard.

All of my effort has been spent on adding sparc support to
grub2.

Re: SILO & Ext4

[Alex Buell]

On Mon, 01 Jun 2009 03:41:24 -0700 (PDT), I waved a wand and this
message magically appears in front of David Miller:

> All of my effort has been spent on adding sparc support to
> grub2.

That is wonderful news, can't wait to test it out in the near future!
-- 
http://www.munted.org.uk

Fearsome grindings.

Re: SILO & Ext4

[Alex Buell]

On Mon, 01 Jun 2009 03:41:24 -0700 (PDT), I waved a wand and this
message magically appears in front of David Miller:

> All of my effort has been spent on adding sparc support to
> grub2.

That is wonderful news, can't wait to test it out in the near future!
-- 
http://www.munted.org.uk

Fearsome grindings.

Re: SILO & Ext4

[Alex Buell]

On Mon, 1 Jun 2009 14:33:02 +0400, I waved a wand and this message
magically appears in front of Alexander Beregalov:

> I found that Sparc cannot boot when rootfs is Ext4 (converted from
> ext3).

I simply have Silo boot from ext3 partition before mounting ext4
partition. Works well. 

> Is anyone working on adding ext4 support to silo?

Unknown - ask on the sparc linux mailing list.
-- 
http://www.munted.org.uk

Fearsome grindings.

Re: SILO & Ext4

[Alex Buell]

On Mon, 1 Jun 2009 14:33:02 +0400, I waved a wand and this message
magically appears in front of Alexander Beregalov:

> I found that Sparc cannot boot when rootfs is Ext4 (converted from
> ext3).

I simply have Silo boot from ext3 partition before mounting ext4
partition. Works well. 

> Is anyone working on adding ext4 support to silo?

Unknown - ask on the sparc linux mailing list.
-- 
http://www.munted.org.uk

Fearsome grindings.

Re: SILO & Ext4

[Robert Reif]

David Miller wrote:
> All of my effort has been spent on adding sparc support to
> grub2.
>
>   
Will it include sparc32 support?

Will it increase the kernel size that can be loaded?

It's almost impossible to build a kernel that is small enough to load 
lately.

Re: SILO & Ext4

[David Miller]

From: Robert Reif <reif@earthlink.net>
Date: Tue, 02 Jun 2009 21:29:25 -0400

> David Miller wrote:
>> All of my effort has been spent on adding sparc support to
>> grub2.
>>
>>   
> Will it include sparc32 support?

No.

> Will it increase the kernel size that can be loaded?

The limit is now at 64MB on sparc64, isn't that enough?

Re: SILO & Ext4

[Robert Reif]

David Miller wrote:
> From: Robert Reif <reif@earthlink.net>
> Date: Tue, 02 Jun 2009 21:29:25 -0400
>
>   
>> David Miller wrote:
>>     
>>> All of my effort has been spent on adding sparc support to
>>> grub2.
>>>
>>>   
>>>       
>> Will it include sparc32 support?
>>     
>
> No.
>
>   
>> Will it increase the kernel size that can be loaded?
>>     
>
> The limit is now at 64MB on sparc64, isn't that enough?
>   
And what is the limit on sparc32?  The silo that comes
with debian etch will not load a kernel compiled with
the default configuration.  It hasn't for a long time.
Currently you have to disable virtually every option
just to get a kernel that loads.  Sparc32 has been
broken for a while because you can't load a kernel
that does anything.

Re: SILO & Ext4

[David Miller]

From: Robert Reif <reif@earthlink.net>
Date: Wed, 03 Jun 2009 07:22:36 -0400

> David Miller wrote:
>> The limit is now at 64MB on sparc64, isn't that enough?
>>   
> And what is the limit on sparc32?

I have no idea, to be honest with you.

> The silo that comes with debian etch will not load a kernel compiled
> with the default configuration.  It hasn't for a long time.
> Currently you have to disable virtually every option just to get a
> kernel that loads.  Sparc32 has been broken for a while because you
> can't load a kernel that does anything.

I'm sorry that sparc32 is effectively unmaintained, would you
like to become the maintainer and fix all of these problems?
I'm sure someone would appreciate that, yourself included :-)

Re: SILO & Ext4

[Robert Reif]

David Miller wrote:
> From: Robert Reif <reif@earthlink.net>
> Date: Wed, 03 Jun 2009 07:22:36 -0400
>
>   
>> David Miller wrote:
>>     
>>> The limit is now at 64MB on sparc64, isn't that enough?
>>>   
>>>       
>> And what is the limit on sparc32?
>>     
>
> I have no idea, to be honest with you.
>
>   
It looks like it's between 2.4 and 2.6 MB depending on
the source.

I found a 2 year old patch to silo that loads the kernel
above 4 MB like sparc64 but the sparc32 kernel is not
relocatable. It loads fine but then tries to move it down
low where it wants to be and fails because there isn't
enough space.

SILO Version 1.4.14
boot:
Allocated 64 Megs of memory at 0x3FFFC000 for kernel
Uncompressing image...
Your kernel cannot fit into the memory destination. This
can be resolved by recompiling the kernel with more devices
built as modules, or upgrading your kernel to one that
supports being loaded to higher memory areas (currently
2.6.3+ or 2.4.26+).
boot:

I'm looking at head_32.S and head_64.s to try and figure
out what's involved in making sparc32 relocatable but I'm
not sure what to look for. Any hints?

Re: SILO & Ext4

[David Miller]

From: Robert Reif <reif@earthlink.net>
Date: Thu, 04 Jun 2009 22:49:25 -0400

> I'm looking at head_32.S and head_64.s to try and figure
> out what's involved in making sparc32 relocatable but I'm
> not sure what to look for. Any hints?

You'll have to learn how to load kernel TLB entries for about 4 or 5
different major TLB/cache types on sun4c, sun4m, and sun4d systems.

This is what you need to do to relocate the kernel into a new location
then jump to it.

Re: SILO & Ext4

[Robert Reif]

David Miller wrote:
> From: Robert Reif <reif@earthlink.net>
> Date: Thu, 04 Jun 2009 22:49:25 -0400
>
>   
>> I'm looking at head_32.S and head_64.s to try and figure
>> out what's involved in making sparc32 relocatable but I'm
>> not sure what to look for. Any hints?
>>     
>
> You'll have to learn how to load kernel TLB entries for about 4 or 5
> different major TLB/cache types on sun4c, sun4m, and sun4d systems.
>   
Couldn't you do this using OBP in a HW independent way?
> This is what you need to do to relocate the kernel into a new location
> then jump to it.
>
>   
On sparc32, is the kernel always loaded in the lower 3 MB
of physical memory regardless of the amount of physical
memory and just left there?

Re: SILO & Ext4

[David Miller]

From: Robert Reif <reif@earthlink.net>
Date: Fri, 05 Jun 2009 08:12:13 -0400

> David Miller wrote:
>> You'll have to learn how to load kernel TLB entries for about 4 or 5
>> different major TLB/cache types on sun4c, sun4m, and sun4d systems.
>
> Couldn't you do this using OBP in a HW independent way?

Not really.

Only sparc64's OBP adds facilities to load locked TLB entries via the
firmware.

>> This is what you need to do to relocate the kernel into a new location
>> then jump to it.
>
> On sparc32, is the kernel always loaded in the lower 3 MB
> of physical memory regardless of the amount of physical
> memory and just left there?

I don't know, you'd have to see what SILO does.

As for direct loads such as tftpboot via the firmware, it loads
the A.OUT kernel image at 0x4000 and simply jumps there.

Re: SILO & Ext4

[Mark Fortescue]

On Fri, 5 Jun 2009, David Miller wrote:

> From: Robert Reif <reif@earthlink.net>
> Date: Fri, 05 Jun 2009 08:12:13 -0400
>
>> David Miller wrote:
>>> You'll have to learn how to load kernel TLB entries for about 4 or 5
>>> different major TLB/cache types on sun4c, sun4m, and sun4d systems.
>>
>> Couldn't you do this using OBP in a HW independent way?
>
> Not really.
>
> Only sparc64's OBP adds facilities to load locked TLB entries via the
> firmware.
>
>>> This is what you need to do to relocate the kernel into a new location
>>> then jump to it.
>>
>> On sparc32, is the kernel always loaded in the lower 3 MB
>> of physical memory regardless of the amount of physical
>> memory and just left there?

Last time I looked at this, the primary problem was not where the kernel 
was loaded but that it only relocated the first 3 MB of kernel thus 
restricting the kernel to a maximum size of 3 MB (.text+.data). It is a 
relativly simple patch to head.S to change this to 8 MB which sould be 
enough to provide a usable kernel.

>
> I don't know, you'd have to see what SILO does.
>
> As for direct loads such as tftpboot via the firmware, it loads
> the A.OUT kernel image at 0x4000 and simply jumps there.
> --
> To unsubscribe from this list: send the line "unsubscribe sparclinux" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: SILO & Ext4

[David Miller]

From: Mark Fortescue <mark@mtfhpc.demon.co.uk>
Date: Mon, 8 Jun 2009 01:01:00 +0100 (BST)

> Last time I looked at this, the primary problem was not where the
> kernel was loaded but that it only relocated the first 3 MB of kernel
> thus restricting the kernel to a maximum size of 3 MB
> (.text+.data). It is a relativly simple patch to head.S to change this
> to 8 MB which sould be enough to provide a usable kernel.

This is true on sun4c, and it's controlled by this constant
0x300000 loaded into %g5 in arch/sparc/kernel/head_32.S:

sun4c_remap:
		mov	0, %g3			! source base
		set	KERNBASE, %g4		! destination base
		set	0x300000, %g5		! upper bound 3MB
		mov	1, %l6
		sll	%l6, 18, %l6		! sun4c mmu segmap size

(same applies to the sun4_mutant_remap and sun4_normal_remap code)

For sun4m/sun4d SRMMU, we inherit up to 16MB of whatever is
mapped at address 0x0.  This corresponds to one PGD entry
in the PGD table for context 0, and is copied by the following
for non-Viking srmmu chips:

srmmu_nviking:
		set	AC_M_CTPR, %g1
		lda	[%g1] ASI_M_MMUREGS, %g1	! get ctx table ptr
		sll	%g1, 0x4, %g1			! make physical addr
		lda	[%g1] ASI_M_BYPASS, %g1		! ptr to level 1 pg_table
		srl	%g1, 0x4, %g1
		sll	%g1, 0x8, %g1			! make phys addr for l1 tbl

		lda	[%g1] ASI_M_BYPASS, %g2		! get level1 entry for 0x0
		add	%g1, KERNBASE >> (SRMMU_PGDIR_SHIFT - 2), %g3
		sta	%g2, [%g3] ASI_M_BYPASS		! place at KERNBASE entry

So for the sun4c case, yes, increasing the 3MB constant in the
sun4c_remap code would help us get further here.

And srmmu should already be propagating up to 16MB of mappings.

But the next issue is to make sure that the code in the memory
management initialization also is ready to handle this mapping
inheritance properly.

For SRMMU, it seems to me that arch/sparc/mm/srmmu.c:map_kernel()
is doing this (note that: KERNBASE = PAGE_OFFSET).

For SUN4C, the arch/sparc/mm/sun4c.c:sun4c_init_map_kernelprom() code
looks like it locks into the TLB everything up to symbol &_end so
that should be good too.

But of course this has been tried I guess and it doesn't work so
simply like that for whatever reason :-)