public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Ayman M. El-Khashab <ayman@elkhashab.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] 460EX PCI Boot SUCCESS and question
Date: Wed, 3 Dec 2008 10:03:56 -0600	[thread overview]
Message-ID: <20081203160352.GA32338@crust.elkhashab.com> (raw)
In-Reply-To: <E241BBE6-46F4-4A32-960E-75B4FE0694B4@kernel.crashing.org>

As stated in the subject, we used multiple 460EXs tied together via
PCI and been able to boot the master from flash and all the slaves
are now able to boot via PCI and run linux.  There were several config
changes in u-boot that I made to get this to work (one of which I have
a question about).  BTW, this is custom hardware, not an amcc board.

Here is the general process that I used

1) boot master via the normal methods, but make sure to leave some
   RAM "unused" by linux with a parameter like mem=112M (leaving 16Mb)
   free for the "flash" image.

2) Generate a flash image that contains u-boot, kernel, ramdisk, dt
   I used perl to just make a pseudo-flash file that is 16Mb, then
   compress it.  

3) I use a userland app to read the image and load it into the 
   contiguous memory reserved in step 1 (this is the only way I
   know of to get a large, physical contiguous space).  

4) Then the app will setup the local PIM registers and remote POM
   registers, enable bus mastering in the slave CMD register and 
   finally tell the slave to go.  

5) The slave fetches addresses (and prefetches, so you have to pay
   careful attention to the logic analyzer) across PCI.  The master
   claims the transaction and then reads from its DRAM, putting what
   would normally be the flash back onto the PCI bus.  

6) At that point it is done and pretty much just works.  

A couple of things I had to do in u-boot, define CONFIG_SYS_NO_FLASH.
This resulted in a compile error for IMLS.  change the TLB to point
to the pci bus and change the CONFIG_SYS_FLASH_BASE_PHYS to point to
PCI space (not sure it was required, but I did it anyway).

The biggest question is that since the processor is used in adapter 
mode, the host is going to configure the POM registers via the PCI
bus.  This works great until u-boot overwrites those in the file 
4xx_pci.c  At this point it is running out of ram, but later it needs
to go back to get the kernel/ramdisk/dt.  So for the moment, I've
commented out the writes to POM in the file.  But what is the "right"
way to do this?

Thanks
Ayman

      reply	other threads:[~2008-12-03 16:03 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-03 15:08 [U-Boot] [PATCH] Set IVPR to kenrel entry point in second core boot page Haiying Wang
2008-12-03 15:10 ` Kumar Gala
2008-12-03 16:03   ` Ayman M. El-Khashab [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081203160352.GA32338@crust.elkhashab.com \
    --to=ayman@elkhashab.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox