RE: Linux on PPC

RE: Linux on PPC

[Rune Torgersen]

=20
> From:  David Hawkins
> Sent: Friday, March 03, 2006 10:53
> To: Wolfgang Denk
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Linux on PPC
>=20
> Right, thats I made sure to say; Physical Memory Map.
>=20
> For example, on the Artesyn manual on their PrPMC they give a
> physical memory map, and in the Yosemite board, there is a
> physical memory map. I know many of the memory areas can be
> redefined in hardware to have a different memory location, but
> its still a physical address.
>=20

Still not right. Even the physical memory is software settable. What
matters is what chip-select things are hooked up to, and then map those
chip selects correctly (size, base address, access with and so on)

Re: Linux on PPC

[David Hawkins]

>>Right, thats I made sure to say; Physical Memory Map.
>>
>>For example, on the Artesyn manual on their PrPMC they give a
>>physical memory map, and in the Yosemite board, there is a
>>physical memory map. I know many of the memory areas can be
>>redefined in hardware to have a different memory location, but
>>its still a physical address.
>>
> 
> Still not right. Even the physical memory is software settable. What
> matters is what chip-select things are hooked up to, and then map those
> chip selects correctly (size, base address, access with and so on)

Hi Rune,

Thanks for responding.

Thats what I meant with 'redefined in hardware'. But yes, redefined
up to the limit of the wiring on the board of course (chip-selects
and bus widths). That's where having the board schematic is
invaluable.

But ok, I'm pretty sure I get the point, and hopefully the
original poster understands a bit more too.

Given a board that you expect to run Linux on, I would imagine
you would select hardware settings consistent with making
Linux happy, i.e., defining 'in software' (the bootloader)
the physical address map (eg. like the Embedded Planet reference
manual for the 440EP Yosemite board), and then setup U-Boot and
Linux to program the TLBs to translate to those same addresses.

When looking at the Yosemite board, I booted U-Boot and compared
device dcr settings to the recommended ones in the EP manual. Then
when I booted Linux, I took a look and found that on the whole, Linux
didn't touch too much of the things setup by U-Boot, i.e., the
responsibility for setting up the Linux environment was mainly
the job of the bootloader.

So, if I had a board with a custom bootloader, I would be
concerned that the bootloader might not know enough about
Linux, to setup the hardware correctly.

Does that sound right?

Dave

Re: Linux on PPC

[Wolfgang Denk]

In message <4408A1D3.8010506@ovro.caltech.edu> you wrote:
> 
> > Still not right. Even the physical memory is software settable. What
> > matters is what chip-select things are hooked up to, and then map those
> > chip selects correctly (size, base address, access with and so on)
> 
> Thats what I meant with 'redefined in hardware'. But yes, redefined
> up to the limit of the wiring on the board of course (chip-selects
> and bus widths). That's where having the board schematic is
> invaluable.

You don't get it. You can map - for example - your flash to  physical
address  0x0000 or 0x04000000 or 0x40000000 or 0xFFF00000 as you like
- without any changes to the hardware, and  without  using  the  MMU.
Mind: that's all *physical* addresses.

> manual for the 440EP Yosemite board), and then setup U-Boot and
> Linux to program the TLBs to translate to those same addresses.

No. U-Boot does not use the MMU.

> when I booted Linux, I took a look and found that on the whole, Linux
> didn't touch too much of the things setup by U-Boot, i.e., the
> responsibility for setting up the Linux environment was mainly
> the job of the bootloader.

Wrong  again.  Linux  completely  re-initializes  the  whole   memory
management.

> So, if I had a board with a custom bootloader, I would be
> concerned that the bootloader might not know enough about
> Linux, to setup the hardware correctly.
> 
> Does that sound right?

No, it's wrong.

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
"Language shapes the way we think, and determines what we  can  think
about."                                                 - B. L. Whorf

Re: Linux on PPC

[David Hawkins]

Hi Wolfgang,

> You don't get it.

Ok, I'll read-up and try to 'get it'.

Thanks
Dave

RE: Linux on PPC

[Rune Torgersen]

> From: David Hawkins [mailto:dwh@ovro.caltech.edu]=20
> Sent: Friday, March 03, 2006 14:07
> To: Rune Torgersen
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Linux on PPC
>=20
>=20
> >>Right, thats I made sure to say; Physical Memory Map.
> >>
> >>For example, on the Artesyn manual on their PrPMC they give a
> >>physical memory map, and in the Yosemite board, there is a
> >>physical memory map. I know many of the memory areas can be
> >>redefined in hardware to have a different memory location, but
> >>its still a physical address.
> >>
> >=20
> > Still not right. Even the physical memory is software settable. What
> > matters is what chip-select things are hooked up to, and=20
> then map those
> > chip selects correctly (size, base address, access with and so on)
>=20
> Hi Rune,
>=20
> Thanks for responding.
>=20
> Thats what I meant with 'redefined in hardware'. But yes, redefined
> up to the limit of the wiring on the board of course (chip-selects
> and bus widths). That's where having the board schematic is
> invaluable.

> Does that sound right?

Yes.

RE: Linux on PPC

[Steve Strublic]

> -----Original Message-----
> From: linuxppc-embedded-bounces+sstrublic=3Dhypercom.com@ozlabs.org
> [mailto:linuxppc-embedded-bounces+sstrublic=3Dhypercom.com@ozlabs.org]
On
> Behalf Of David Hawkins
> Sent: Friday, March 03, 2006 1:07 PM
> To: Rune Torgersen
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Linux on PPC
>=20
>=20
> >>Right, thats I made sure to say; Physical Memory Map.
> >>
> >>For example, on the Artesyn manual on their PrPMC they give a
> >>physical memory map, and in the Yosemite board, there is a
> >>physical memory map. I know many of the memory areas can be
> >>redefined in hardware to have a different memory location, but
> >>its still a physical address.
> >>
> >
> > Still not right. Even the physical memory is software settable. What
> > matters is what chip-select things are hooked up to, and then map
those
> > chip selects correctly (size, base address, access with and so on)
>=20
> Hi Rune,
>=20
> Thanks for responding.
>=20
> Thats what I meant with 'redefined in hardware'. But yes, redefined
> up to the limit of the wiring on the board of course (chip-selects
> and bus widths). That's where having the board schematic is
> invaluable.
>=20
> But ok, I'm pretty sure I get the point, and hopefully the
> original poster understands a bit more too.
>=20
> Given a board that you expect to run Linux on, I would imagine
> you would select hardware settings consistent with making
> Linux happy, i.e., defining 'in software' (the bootloader)
> the physical address map (eg. like the Embedded Planet reference
> manual for the 440EP Yosemite board), and then setup U-Boot and
> Linux to program the TLBs to translate to those same addresses.
>=20
> When looking at the Yosemite board, I booted U-Boot and compared
> device dcr settings to the recommended ones in the EP manual. Then
> when I booted Linux, I took a look and found that on the whole, Linux
> didn't touch too much of the things setup by U-Boot, i.e., the
> responsibility for setting up the Linux environment was mainly
> the job of the bootloader.
>=20
> So, if I had a board with a custom bootloader, I would be
> concerned that the bootloader might not know enough about
> Linux, to setup the hardware correctly.

The boot loader should, ideally, NOT know anything about Linux except
for knowing that since a Linux is being loaded, it requires some
information at boot time, and the format in which to provide said
information.

Steve

>=20
> Does that sound right?
>=20
> Dave
>=20
>=20
>=20
>=20
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Linux on PPC

[rtos]

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

Hi,

We have a customized board running on IBM PPC 750. The customer boot loader
is provided by the vendor.
Also, the vendor has provided the BSP on vxworks.

We are planning to use linux on this processor. What are the steps involved
in booting the board with linux.
Which linux to be used and what are the procedures involved. I dint come
across a documents which had these details.

I am new to the linux front. So any help is highly appreciated.

thanks

[-- Attachment #2: Type: text/html, Size: 615 bytes --]

Re: Linux on PPC

[Frank]

--- rtosrtososrtosgmaigmail> wrote:

> Hi,
> 
> We have a customized board running on IBM PPC PPC. The
> customer boot loader
> is provided by the vendor.
> Also, the vendor has provided the BSP BSPvxwovxworks 
> We are planning to use linulinuxthis processor. What are the
> steps involved
> in booting the board with linulinux Which linulinuxbe used and
what are the procedures involved. I
> dint come
> across a documents which had these details.
> 
> I am new to the linulinuxnt. So any help is highly
> appreciated.
> 
> thanks

I recommend using u-boot and the ELDK from denx.de

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: Linux on PPC

[nreddy]

You can easily migrate to linux environment.

 1. You can use u-boot as a boot loader.
 2. You can choose any standard linux kernel but you may have to do some
R&D on it to port to your board.
 Insted you can buy Montavista Linux, so that you can get support also.

 And also there are many mailing lists where yo ucan get tremendous help
on linux.


Thanks,
Nagi



> Hi,
>
> We have a customized board running on IBM PPC 750. The customer boot
> loader
> is provided by the vendor.
> Also, the vendor has provided the BSP on vxworks.
>
> We are planning to use linux on this processor. What are the steps
> involved
> in booting the board with linux.
> Which linux to be used and what are the procedures involved. I dint come
> across a documents which had these details.
>
> I am new to the linux front. So any help is highly appreciated.
>
> thanks
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: Linux on PPC

[Wolfgang Denk]

In message <2611.61.95.208.2.1141362572.squirrel@61.95.208.2> you wrote:
> 
>  1. You can use u-boot as a boot loader.
>  2. You can choose any standard linux kernel but you may have to do some
> R&D on it to port to your board.
>  Insted you can buy Montavista Linux, so that you can get support also.

Commercial support is available not only from MV, but also from  many
other companies.

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 one who says it cannot be done should never interrupt the one who
is doing it.

Re: Linux on PPC

[David Hawkins]

Hiya,

I'm no expert in this, but here's the basics;

> We have a customized board running on IBM PPC 750. The customer boot 
> loader is provided by the vendor. Also, the vendor has provided
> the BSP on vxworks.

The PPC 750 is a fairly old processor, so there will be Linux
support for it. For example, I picked up a couple of Artesyn
PrPMC boards that contain a PPC 750, and this board can run
Linux, though I have not had time to try booting it yet.

If the vendor provided the VxWorks BSP, then hopefully they
also provided you with the physical memory map of the board.
This is what you really need to get another bootloader (eg. U-Boot)
and Linux up-and-running. If the vendor will provide schematics
for the board, that would also help (hey, it never hurts to
ask for them).

> We are planning to use linux on this processor. What are the steps 
> involved in booting the board with linux.
> Which linux to be used and what are the procedures involved. I dint come 
> across a documents which had these details.
>  
> I am new to the linux front. So any help is highly appreciated.
>  

Step 1. Get the memory map of the board.

Step 2. Find a PPC 750 port in the Linux source.

      For example, in the 2.6 series kernel, the place to start
      looking is under arch/ppc/platforms. grep -Ie 750 shows
      up some of the PPC 750 based systems.

      chestnut.c 750FX/GX evaluation board
      katana.c   Looks like one too
      prpmc750.c Looks like a Motorola board

      Look at the comments in the code, look at the memory map
      of the reference board versus your custom board. There is
      a very good chance that the custom board is based on a
      reference design - thats the whole point of them.

Step 3. Build a minimal kernel

Step 4. Boot

Step 5. Purchase a BDI2000 JTAG debugger and use it to figure
         out why Step 4 didn't work.

         Repeat at Step 3.

When I get time to play with my Artesyn board, I'll go back to
the katana.c file, the grep above had some comments about Artesyn
boards. If it fails to boot, I'll use the BDI2000 to see where it
dies and go from there.

Once you can boot Linux, you might decide that the custom bootloader
on the board is inflexible. The U-Boot bootloader is very nice
and will have support for other 750-based boards, it shouldn't
take too much to port that too. But first, try to get a Linux
kernel booted, even if it has a hard-wired command line.

Also take a look over on the Freescale web site, search for
'porting linux', it'll show up AN2145, AN2222, AN2579, and
a bunch of other application notes. They'll give you an idea
of what it takes to port to a new processor.

 > I am new to the linux front. So any help is highly appreciated.

So it depends how much time you have versus how much you
want to spend.

There are also commercial companies that will do the job for you.
If you can come up with the memory map and hardware details of
the board, you could always post a request on this list, and
I am sure there are people reading this list that would
respond. (I'm not one of them though, so I'm not trying to
drum up business ok)

Regards,
Dave

Re: Linux on PPC

[Adrian Cox]

On Thu, 2006-03-02 at 21:10 -0800, David Hawkins wrote:
> Step 2. Find a PPC 750 port in the Linux source.
> 
>       For example, in the 2.6 series kernel, the place to start
>       looking is under arch/ppc/platforms. grep -Ie 750 shows
>       up some of the PPC 750 based systems.
> 
>       chestnut.c 750FX/GX evaluation board
>       katana.c   Looks like one too
>       prpmc750.c Looks like a Motorola board
> 
>       Look at the comments in the code, look at the memory map
>       of the reference board versus your custom board. There is
>       a very good chance that the custom board is based on a
>       reference design - thats the whole point of them.

I'd add the caution that within the 6xx, 7xx, and 7xxx family of
processors, the north-bridge makes a much greater difference than the
processor core. Within that family of processors Linux will auto-detect
the processor specific features at boot time. It will be easier to port
from a board using a 7450 with the same north-bridge, than from a board
using a 750 with a different north-bridge.

-- 
Adrian Cox <adrian@humboldt.co.uk>

Re: Linux on PPC

[Wolfgang Denk]

In message <4407CFD3.4060206@ovro.caltech.edu> you wrote:
> 
> If the vendor provided the VxWorks BSP, then hopefully they
> also provided you with the physical memory map of the board.
> This is what you really need to get another bootloader (eg. U-Boot)

This is *NOT* corect, and actually dangerous.

> Step 1. Get the memory map of the board.

Never use any given memory map unreflected. At least *check* if  it's
usable with Linux.

Many memory maps (especially those provides with some eval boards for
demonstration purpose) will NOT work with Linux.  Remember  that  the
memory  map  is  usually  not  cast  in  silicon,  but implemented in
software, so you can change it as needed.


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
C++ was an interesting and valuable experiment, but we've learned its
lessons and it's time to move on.
                            - Peter Curran in <DCqM4z.BxB@isgtec.com>

Re: Linux on PPC

[David Hawkins]

>>If the vendor provided the VxWorks BSP, then hopefully they
>>also provided you with the physical memory map of the board.
>>This is what you really need to get another bootloader (eg. U-Boot)
>  
> This is *NOT* corect, and actually dangerous.

Thanks Wolfgang!

I did start the email with "I'm not an expert on this ...".

>>Step 1. Get the memory map of the board.
> 
> Never use any given memory map unreflected. At least *check* if  it's
> usable with Linux.
> 
> Many memory maps (especially those provides with some eval boards for
> demonstration purpose) will NOT work with Linux.  Remember  that  the
> memory  map  is  usually  not  cast  in  silicon,  but implemented in
> software, so you can change it as needed.

Right, thats I made sure to say; Physical Memory Map.

For example, on the Artesyn manual on their PrPMC they give a
physical memory map, and in the Yosemite board, there is a
physical memory map. I know many of the memory areas can be
redefined in hardware to have a different memory location, but
its still a physical address.

Now, when the bootloader loads, eg. U-Boot, it sets up the
memory management. Now this is where my understanding gets
shakey, since I haven't looked at much of the code, so perhaps
you can clarify. The translation unit (TLB) maps virtual addresses
(or should that be MMU output addresses) into physical addresses,
and for the Yosemite port the default translation
addresses appear to be identical to the physical addresses,
though obviously this doesn't have to be the case. Then on
top of that there is virtual memory addresses generated by
the core (input to the MMU if its enabled?), that then go
through the MMU/TLB and get mapped to physical addresses. If
I was going to do a port, obviously I'd take the time to
understand this fully :)  (I think the Linux Kernel Internals
book has a description, but its usually meaningless to me until
I play with the code).

What are the basic requirements for a Linux memory map then?

Cheers
Dave

Re: Linux on PPC

[Wolfgang Denk]

In message <44087473.6020905@ovro.caltech.edu> you wrote:
> 
> > Many memory maps (especially those provides with some eval boards for
> > demonstration purpose) will NOT work with Linux.  Remember  that  the
> > memory  map  is  usually  not  cast  in  silicon,  but implemented in
> > software, so you can change it as needed.
> 
> Right, thats I made sure to say; Physical Memory Map.

That's what I mean: the physical memory map  is  usually  set  up  in
software, so it can be changed to your needs.

> For example, on the Artesyn manual on their PrPMC they give a
> physical memory map, and in the Yosemite board, there is a
> physical memory map. I know many of the memory areas can be
> redefined in hardware to have a different memory location, but
> its still a physical address.

...which usually can be reprogrammed in software.

> Now, when the bootloader loads, eg. U-Boot, it sets up the
> memory management. Now this is where my understanding gets
> shakey, since I haven't looked at much of the code, so perhaps
> you can clarify. The translation unit (TLB) maps virtual addresses
> (or should that be MMU output addresses) into physical addresses,

U-Boot usually does not use the MMU. 

> What are the basic requirements for a Linux memory map then?

See the FAQ.

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
It is surely a great calamity for  a  human  being  to  have  no  ob-
sessions.                                                - Robert Bly