Re: kernel startup

Re: kernel startup

[Kumar Gala]

On Sat, 11 Feb 2006, dibacco@inwind.it wrote:

> Normally is it the uboot that uncompresses the kernel or the kernel uncompress itself? 

How would something compressed uncompress itself?  If u-boot is being used 
it will uncompress a compressed kernel and put the image at physical 0.

> The function called by uboot when I type boot is _start?

Are you asking about u-boot's _start or the kernel's?
 
> What does it mean that the load address is 0x00000000? 

its the address u-boot's going to jump to and start executing kernel code 
from.

- kumar

kernel startup

[dibacco]

Normally is it the uboot that uncompresses the kernel or the kernel uncom=
press itself? 

The function called by uboot when I type boot is _start?

What does it mean that the load address is 0x00000000? 

RE: kernel startup

[Kumar Gala]

> > Normally is it the uboot that uncompresses the kernel or the kernel
> uncompress itself? 
> 
> >>How would something compressed uncompress itself?  If u-boot is being
> used 
> >>it will uncompress a compressed kernel and put the image at physical
> 0.
> 
> Small correction. Just like a self extracting binary, a kernel can have
> a decompression code prepended to the start of kernel which can
> decompress the 
> Kernel.  This is how redboot for xscale is structured or syslinux /lilo
> for x86. 

This also happens with the boot wrapper that is in arch/{ppc,powerpc}/boot

> 
> Although u-boot has simplified this step by doing the CRC checksum of
> the
> uiMage header as well as data and also decompress the kernel. Based on
> load
> address, entry point, the kernel can start executing.  
> 
> Now, whether cache is enable or not, MMU is enabled/disabled depends on
> the
> Developer. In current u-boot, the MMU is not used. I-Cache is On and
> D-cache
> is off.

I'm not sure what sub-arch we are talking about, but some do have the MMU 
on.

- kumar

RE: kernel startup

[atul.sabharwal]

> Normally is it the uboot that uncompresses the kernel or the kernel
uncompress itself?=20

>>How would something compressed uncompress itself?  If u-boot is being
used=20
>>it will uncompress a compressed kernel and put the image at physical
0.

Small correction. Just like a self extracting binary, a kernel can have
a decompression code prepended to the start of kernel which can
decompress the=20
Kernel.  This is how redboot for xscale is structured or syslinux /lilo
for x86.=20

Although u-boot has simplified this step by doing the CRC checksum of
the
uiMage header as well as data and also decompress the kernel. Based on
load
address, entry point, the kernel can start executing. =20

Now, whether cache is enable or not, MMU is enabled/disabled depends on
the
Developer. In current u-boot, the MMU is not used. I-Cache is On and
D-cache
is off.

Best Regards,

Atul

RE: kernel startup

[atul.sabharwal]

>>I'm not sure what sub-arch we are talking about, but some do have the
MMU=20
on.

I am using PPC 870 and u-boot 1.1.2.  Which architecture should I look
for as a reference example.  On my system, the RAM is not at address 0x0
but at
0x10000000. Since the exception table does not take full 32 bit address,
I am not sure how to tell the processor about the relocated location.

On this custom board with 870, is it necessary to have RAM at address
0x0
(or shadow it) or the 870 supports configuration for different base
addresses for memory. =20

Thanks,

Atul

RE: kernel startup

[Kumar Gala]

On Fri, 10 Feb 2006 atul.sabharwal@exgate.tek.com wrote:

> Since I have set IIP to 1, reset vector is at 0xfff00100.  IMMR is
> 0x00f00000. So, putting RAM at address 0x0 allows only 15MB of RAM
> at address 0x0 (ISA style). 

I'm not that familiar with 8xx, but can't you move IMMR?

- kumar

Re: kernel startup

[Wolfgang Denk]

In message <Pine.LNX.4.44.0602101730210.31619-100000@gate.crashing.org> you wrote:
> 
> > What does it mean that the load address is 0x00000000? 
> 
> its the address u-boot's going to jump to and start executing kernel code 
> from.

No. U-Boot will load (copy) the image to the load address  but  start
executing  kernel  code  at  the  entry  point  address  which may be
different.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"Am besten betrachten Sie Fehlermeldungen als eine  Art  Psycho-Test,
mit  dem  herausgefunden  werden soll, wie belastbar Sie sind."
 - Dr. R. Wonneberger, Kompaktführer LaTeX, Kap. 1.6: Fehlermeldungen

Re: kernel startup

[Wolfgang Denk]

In message <4A062D477D842B4C8FC48EA5AF2D41F201BA207A@us-bv-m23.global.tektronix.net> you wrote:
> 
> >>How would something compressed uncompress itself?  If u-boot is being used 
> >>it will uncompress a compressed kernel and put the image at physical 0.
> 
> Small correction. Just like a self extracting binary, a kernel can have
> a decompression code prepended to the start of kernel which can decompress the 
> Kernel.  This is how redboot for xscale is structured or syslinux /lilo

No, this is not the kernel,  but  some  additional  component,  often
called "bootstrap loader" or so, which wraps the kernel as payload in
it's own image.

> Now, whether cache is enable or not, MMU is enabled/disabled depends on the
> Developer. In current u-boot, the MMU is not used. I-Cache is On and D-cache
> is off.

This may be correct on  some  specific  boards,  but  it's  wrong  on
others.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
The existence of god implies a violation of causality.

RE: kernel startup

[atul.sabharwal]

Since I have set IIP to 1, reset vector is at 0xfff00100.  IMMR is
0x00f00000. So, putting RAM at address 0x0 allows only 15MB of RAM
at address 0x0 (ISA style).=20

As memory and internal processor registers would conflict, I would have
a memory hole.  Hence, the logical choice of putting RAM at a different
location. So, if MMU allows shadowing (which I have not read), it could
solve my problem.

Regards,

Atul

Re: kernel startup

[Wolfgang Denk]

In message <4A062D477D842B4C8FC48EA5AF2D41F201BA2081@us-bv-m23.global.tektronix.net> you wrote:
> 
> I am using PPC 870 and u-boot 1.1.2.  Which architecture should I look
> for as a reference example.  On my system, the RAM is not at address 0x0 but at
> 0x10000000. Since the exception table does not take full 32 bit address,

The phrase "the RAM is at address 0x10000000" is bogus.

The RAM "is" where you map it. The mapping is done in  software.  The
software is implementing your design.

In other words, your design is broken when you put the RAM at such  a
strange adress instead of the natural location, starting from 0x0000.

> I am not sure how to tell the processor about the relocated location.

You don't; just fix your memory map.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
If God had a beard, he'd be a UNIX programmer.

RE: kernel startup

[atul.sabharwal]

>>The RAM "is" where you map it. The mapping is done in  software.  The
>>software is implementing your design.

>>In other words, your design is broken when you put the RAM at such  a
>>strange address instead of the natural location, starting from 0x0000.

Memory is not on the local bus but across a third party memory
controller.
Two processors loosely coupled.  So, the RAM is at non zero address.

This seems to be the critical problem in this design but need to
convince
the design engineers.  I don't know the reason why they want memory at
non zero address but that's the requirement.

--
Atul

RE: kernel startup

[Kumar Gala]

On Fri, 10 Feb 2006 atul.sabharwal@exgate.tek.com wrote:

> >>I'm not that familiar with 8xx, but can't you move IMMR?
> 
> Not much choice with IMMR as it can be 0x0 or 0x00f00000 or 0xFF000000
> Or 0xFFF00000.  
> 
> Flash is from 0xfe000000 thru 0xffffffff.  Now on POR,
> Processor goes to offset 0x100 on CS0.  So, if IMMR is overlapping with
> flash, it might not boot.
> 
> On 870, it seems that reset value for BR0/OR0 is undefined.
> Data fetch goes on CS0 and then in cpu_init_f BR0 & OR0
> Are remapped.  So, I could put flash at a non-standard address like
> 0xDE000000 and move IMMR to 0xFF000000.
> 
> The problem this creates is that I can set IIP to 0 or 1. So, exception
> Vector prefix can be 0 or 0xfff.  Since no flash at 0xfff00000 base 
> Address I cannot have any exceptions in my code till the u-boot code
> has relocated to RAM.  Which should be acceptable as what can I do
> if there is exception so early in the system. 
> 
> Unless there is a better design ?

It sounds like you should move this discussion to the u-boot list since it 
has very little to do with the kernel.

- k

RE: kernel startup

[atul.sabharwal]

>>I'm not that familiar with 8xx, but can't you move IMMR?

Not much choice with IMMR as it can be 0x0 or 0x00f00000 or 0xFF000000
Or 0xFFF00000. =20

Flash is from 0xfe000000 thru 0xffffffff.  Now on POR,
Processor goes to offset 0x100 on CS0.  So, if IMMR is overlapping with
flash, it might not boot.

On 870, it seems that reset value for BR0/OR0 is undefined.
Data fetch goes on CS0 and then in cpu_init_f BR0 & OR0
Are remapped.  So, I could put flash at a non-standard address like
0xDE000000 and move IMMR to 0xFF000000.

The problem this creates is that I can set IIP to 0 or 1. So, exception
Vector prefix can be 0 or 0xfff.  Since no flash at 0xfff00000 base=20
Address I cannot have any exceptions in my code till the u-boot code
has relocated to RAM.  Which should be acceptable as what can I do
if there is exception so early in the system.=20

Unless there is a better design ?

Thanks,

Atul

Re: kernel startup

[Wolfgang Denk]

In message <4A062D477D842B4C8FC48EA5AF2D41F201BA2084@us-bv-m23.global.tektronix.net> you wrote:
> Since I have set IIP to 1, reset vector is at 0xfff00100.  IMMR is
> 0x00f00000. So, putting RAM at address 0x0 allows only 15MB of RAM
> at address 0x0 (ISA style). 

Please do yourself a favour and read some docs and FAQ's first.  With
a  low mapping ogf the IMMR like 0x00f00000 you will never be able to
run Linux.

And as mentioned before: the whole memory map is just software. If  it
doesn't fit your needs just change it.

> As memory and internal processor registers would conflict, I would have

Then CHANGE it! It's just a few bits in some registers.

> a memory hole.  Hence, the logical choice of putting RAM at a different

This is not a logical choice, but just another error.

> location. So, if MMU allows shadowing (which I have not read), it could
> solve my problem.

Please forget it. Just fix your memory map.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Why don't you have a Linux partition installed so you can be  working
in  a  programmer-friendly environment instead of a keep-gates'-bank-
account-happy one? :-)                            -- Tom Christiansen

Re: kernel startup

[Wolfgang Denk]

In message <Pine.LNX.4.44.0602101802590.31619-100000@gate.crashing.org> you wrote:
>
> I'm not that familiar with 8xx, but can't you move IMMR?

Of course you can.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
We, the unwilling, led by the unknowing, are doing the impossible for
the ungrateful. We have done so much, for so long, with so little, we
are now qualified to do anything with nothing.

Re: kernel startup

[Wolfgang Denk]

In message <4A062D477D842B4C8FC48EA5AF2D41F201BA2089@us-bv-m23.global.tektronix.net> you wrote:
> 
> Not much choice with IMMR as it can be 0x0 or 0x00f00000 or 0xFF000000
> Or 0xFFF00000.  

Initially. But you can change it.

> Flash is from 0xfe000000 thru 0xffffffff.  Now on POR,
> Processor goes to offset 0x100 on CS0.  So, if IMMR is overlapping with
> flash, it might not boot.

Just fix your memory map.

> On 870, it seems that reset value for BR0/OR0 is undefined.

Please RTFM. The steps how the processor  comes  up  from  reset  are
documented  in  great  detail.  Especially  the  handling of the boot
device chip select.

> Data fetch goes on CS0 and then in cpu_init_f BR0 & OR0
> Are remapped.  So, I could put flash at a non-standard address like
> 0xDE000000 and move IMMR to 0xFF000000.

There is no such thing as a "non-standard" address, as  there  is  no
"standard" address either.

> The problem this creates is that I can set IIP to 0 or 1. So, exception
> Vector prefix can be 0 or 0xfff.  Since no flash at 0xfff00000 base 
> Address I cannot have any exceptions in my code till the u-boot code
> has relocated to RAM.  Which should be acceptable as what can I do
> if there is exception so early in the system. 

In most cases it is useful to configure a system for low-boot, i.  e.
let  it  start  at  0x0100.  Then  just set up your memory map as you
like...

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
You don't need a weatherman to know which way the wind blows.
                                                          - Bob Dylan

RE: kernel startup

[atul.sabharwal]

> I'm not that familiar with 8xx, but can't you move IMMR?

Of course you can.

That's correct but on 8540, it did not work.  I was using u-boot
And BDI had mapped it to 0xe0000000 and u-boot had mapped it to
0x40000000. So, it was a problem as serial interface did not work.

It was easier to keep IMMR value same in the BDI configuration and the
processor. Just did not find it necessary to relocate it.

Most of the time, it's a question between conceptual and factual(does it
work ?).
--
Atul

RE: kernel startup

[atul.sabharwal]

>>Please do yourself a favour and read some docs and FAQ's first.  With
>>a  low mapping ogf the IMMR like 0x00f00000 you will never be able to
>>run Linux.

I know that the processor does not allow setting up a base address for
the
exception vectors. In this situation, it would never be able to handle
TLB or system call exceptions. =20

Just don't know if this is feasible so scrambling for any other docs. I
have the instruction reference and development manual.

Seems to be a bad requirement to not have RAM at address 0x0. Would have
to change that. Rest should just fall in place by booting low. This
would allow exception handling from flash as well as RAM.

Best Regards,

Atul

RE: kernel startup

[atul.sabharwal]

Actually, it would be great if PPC would allow the exception handlers to
execute from DPRAM.  The handler would run faster than coming from a
RAM/flash or some EEPROM.  Don't know all the implications but should be
a useful speedup.

--
Atul

RE: kernel startup

[atul.sabharwal]

More efficient would be to lock the exception handlers in L1 cache.  I
don't know the access rate of DPRAM on 870? Should be bus speed? So,
DPRAM and external memory would be same access time unless the
electrical characteristics of RAM vs. DPRAM technology is different.
--
Atul

Re: kernel startup

[Wolfgang Denk]

In message <4A062D477D842B4C8FC48EA5AF2D41F201BA209B@us-bv-m23.global.tektronix.net> you wrote:
> >>Please do yourself a favour and read some docs and FAQ's first.  With
> >>a  low mapping ogf the IMMR like 0x00f00000 you will never be able to
> >>run Linux.
> 
> I know that the processor does not allow setting up a base address for the
> exception vectors. In this situation, it would never be able to handle

This has nothing to do with that. Please *read* the FAQ!

> Just don't know if this is feasible so scrambling for any other docs. I
> have the instruction reference and development manual.

You can reinvent the wheel, or  read  the  documented  experience  of
others who went the same way long time ago.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
The perversity of nature is nowhere better demonstrated by  the  fact
that,  when  exposed to the same atmosphere, bread becomes hard while
crackers become soft.