linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
* RE: kernel startup
@ 2006-02-11  0:28 atul.sabharwal
  2006-02-11  0:23 ` Kumar Gala
  2006-02-11  1:20 ` Wolfgang Denk
  0 siblings, 2 replies; 21+ messages in thread
From: atul.sabharwal @ 2006-02-11  0:28 UTC (permalink / raw)
  To: galak; +Cc: linuxppc-embedded

>>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

^ permalink raw reply	[flat|nested] 21+ messages in thread
* RE: kernel startup
@ 2006-02-11  2:10 atul.sabharwal
  0 siblings, 0 replies; 21+ messages in thread
From: atul.sabharwal @ 2006-02-11  2:10 UTC (permalink / raw)
  To: atul.sabharwal, wd; +Cc: linuxppc-embedded

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

^ permalink raw reply	[flat|nested] 21+ messages in thread
* RE: kernel startup
@ 2006-02-11  2:03 atul.sabharwal
  0 siblings, 0 replies; 21+ messages in thread
From: atul.sabharwal @ 2006-02-11  2:03 UTC (permalink / raw)
  To: atul.sabharwal, wd; +Cc: linuxppc-embedded

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

^ permalink raw reply	[flat|nested] 21+ messages in thread
* RE: kernel startup
@ 2006-02-11  1:47 atul.sabharwal
  2006-02-11 12:59 ` Wolfgang Denk
  0 siblings, 1 reply; 21+ messages in thread
From: atul.sabharwal @ 2006-02-11  1:47 UTC (permalink / raw)
  To: wd; +Cc: linuxppc-embedded

>>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

^ permalink raw reply	[flat|nested] 21+ messages in thread
* RE: kernel startup
@ 2006-02-11  1:40 atul.sabharwal
  0 siblings, 0 replies; 21+ messages in thread
From: atul.sabharwal @ 2006-02-11  1:40 UTC (permalink / raw)
  To: wd, galak; +Cc: linuxppc-embedded

> 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

^ permalink raw reply	[flat|nested] 21+ messages in thread
* RE: kernel startup
@ 2006-02-11  0:19 atul.sabharwal
  0 siblings, 0 replies; 21+ messages in thread
From: atul.sabharwal @ 2006-02-11  0:19 UTC (permalink / raw)
  To: wd; +Cc: linuxppc-embedded

>>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

^ permalink raw reply	[flat|nested] 21+ messages in thread
* RE: kernel startup
@ 2006-02-11  0:10 atul.sabharwal
  2006-02-11  0:03 ` Kumar Gala
  2006-02-11  1:12 ` Wolfgang Denk
  0 siblings, 2 replies; 21+ messages in thread
From: atul.sabharwal @ 2006-02-11  0:10 UTC (permalink / raw)
  To: atul.sabharwal, galak; +Cc: linuxppc-embedded

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

^ permalink raw reply	[flat|nested] 21+ messages in thread
* RE: kernel startup
@ 2006-02-11  0:02 atul.sabharwal
  2006-02-11  0:12 ` Wolfgang Denk
  0 siblings, 1 reply; 21+ messages in thread
From: atul.sabharwal @ 2006-02-11  0:02 UTC (permalink / raw)
  To: galak; +Cc: linuxppc-embedded



>>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

^ permalink raw reply	[flat|nested] 21+ messages in thread
* RE: kernel startup
@ 2006-02-10 23:53 atul.sabharwal
  2006-02-10 23:46 ` Kumar Gala
  2006-02-11  0:08 ` Wolfgang Denk
  0 siblings, 2 replies; 21+ messages in thread
From: atul.sabharwal @ 2006-02-10 23:53 UTC (permalink / raw)
  To: galak, dibacco; +Cc: linuxppc-embedded


> 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

^ permalink raw reply	[flat|nested] 21+ messages in thread
* kernel startup
@ 2006-02-10 23:33 dibacco
  2006-02-10 23:32 ` Kumar Gala
  0 siblings, 1 reply; 21+ messages in thread
From: dibacco @ 2006-02-10 23:33 UTC (permalink / raw)
  To: linuxppc-embedded

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? 

^ permalink raw reply	[flat|nested] 21+ messages in thread

end of thread, other threads:[~2006-02-11 12:59 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-02-11  0:28 kernel startup atul.sabharwal
2006-02-11  0:23 ` Kumar Gala
2006-02-11  1:20 ` Wolfgang Denk
  -- strict thread matches above, loose matches on Subject: below --
2006-02-11  2:10 atul.sabharwal
2006-02-11  2:03 atul.sabharwal
2006-02-11  1:47 atul.sabharwal
2006-02-11 12:59 ` Wolfgang Denk
2006-02-11  1:40 atul.sabharwal
2006-02-11  0:19 atul.sabharwal
2006-02-11  0:10 atul.sabharwal
2006-02-11  0:03 ` Kumar Gala
2006-02-11  1:13   ` Wolfgang Denk
2006-02-11  1:12 ` Wolfgang Denk
2006-02-11  0:02 atul.sabharwal
2006-02-11  0:12 ` Wolfgang Denk
2006-02-10 23:53 atul.sabharwal
2006-02-10 23:46 ` Kumar Gala
2006-02-11  0:08 ` Wolfgang Denk
2006-02-10 23:33 dibacco
2006-02-10 23:32 ` Kumar Gala
2006-02-11  0:06   ` Wolfgang Denk

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).