[U-Boot] 460EX PCI Boot SUCCESS and question
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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] pci booting 460ex seems to hang at tlb entries
Thanks for any pointers. So here is my current setup, 2 460ex parts bussed together via the PCI bus. The master boots u-boot via flash, reserves some memory, and boots linux. A user process then maps that memory and loads a "flash image" into it. The PIM and POM registers on the master and slave processor are then configured. The slave is setup to enable bus mastering and then its boot is started. I see all the instructions being fetched across the PCI bus correctly (I've made loops and things to confirm that everything is executed on the slave properly). As I follow the instructions across the PCI bus I see it start at the usual location, then jump to F000 and start going. It makes it all the way to F29C and then nothing comes across the PCI bus. When I check the code to see where that is, it is the configuration of the TLB entries in init.S (which is almost exactly the same as the init.S for canyonlands). It seems that I've got something setup wrong and that is inhibiting the CPU from any more fetches on the PCI bus. The only TLB entry that I've changed from the canyonlands is the very first one to the following: tlbentry(CONFIG_SYS_BOOT_BASE_ADDR, SZ_16M, \ CONFIG_SYS_BOOT_BASE_ADDR, 0xC, AC_R|AC_W|AC_X|SA_G) /* TLB 0 */ CONFIG_SYS_BOOT_BASE_ADDR is 0xFF00 0xC is the space that according to the datasheet is the location of the PCI space. It is the same address that I am using for the POMs so it at least behaves as expected for the initial part of the boot. I did not see anything else that I *knew* required modification but I was a little unsure about the PCI space TLB entry. Is there another place in the code I need to be modifying things? This happens early so the choices look to be a limited as to what could be wrong. I've also tried the abatron, but it seems to misbehave when using this boot mode. Thanks, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Hangs at relocation on 460EX Target
On Thu, Oct 23, 2008 at 10:39:11AM +0200, Stefan Roese wrote: > > Ayman, which module are you using and what's your reg 21 value? Does anybody > have the time to dig into those specs to find a common solution? > I am using a Kingston mini-dimm, my reg 21 value is 0x4, so 1 pll / 1 reg. For reg 20, it is reported as a Mini-Registered DIMM with 0x10 I will have time after this week to take a look if it would help. Thank you, Ayman ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Hangs at relocation on 460EX Target
On Wed, Oct 22, 2008 at 07:12:30AM +0200, Stefan Roese wrote: > > Yes, there have been issues with the "old" autocalibration code on some > boards. That's one > reason that AMCC provided a new version just a few weeks ago: > Thanks Stefan, I've got the hardware mostly working now. The new calibration code did work once I got past another issue. I'll try to describe it here b/c It *might* be a bug, but I wasn't 100% sure. First, I am using registered ecc dimms which appears to be handled in cpu/ppc4xx/44x_spd_ddr2.c However, what I found by observing the registers with the abatron was that the SDRAM_MCOPT1_RDEN was not set for the registered DIMM. Following the code, it looks like it should have been set if "registered" was set, but it does not appear that it worked correctly. So of course we were off by 1/2. I forced the bit in the mcopt1 variable and that fixed all the problems. Any thoughts or is there something I can try/contribute? Thanks Ayman ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Hangs at relocation on 460EX Target
On Tue, Oct 21, 2008 at 09:10:03PM +0200, Wolfgang Denk wrote: > > > > I should have mentioned that we have DEBUG enabled and we've also > > run the RAM test that is included in u-boot. The ram test does pass. > > Please see the FAQ, entry # 1. Passing the RAM test does not mean > anything when it comes to accessing the RAM in burst mode. Ok, makes sense I understand that the ram test is not sufficient to fully exercise the bus. In particular, it appears that it does not have lots of entropy, so shorted address/data may not be detected and the timing tolerance is much wider than would be found in normal operating conditions. > > > I am not familiar with those, I thought that once the SDRAM is operating > > you cannot alter those calibration and timing/delay registers. Is this > > calibration something that is enabled in u-boot or just via the register > > accesses to the memory controller? > > How about reading the code? (Looking at canyonlands.h) Ok, I took a look at this and the autocalibration is not obvious. It looks like there is a currently a hardcoded RQDC value of 8038. If this is undefined then the code will go into the autocalibration mode. So I've undefined it and sure enough it goes into autocalibration. The part that is odd is that the autocal does not work on the Canyonlands board. If it is enabled, then the Canyonlands fails in the same way as our hardware. I.e. right at the time of relocation, it just hangs. When set back to the hardcoded value, the canyonlands works fine. Perusing the code, the only sort of exception that I noticed was one for the Katmai. During operation I don't see the code fail to find the window, so it appears that it finds a suitable value. When examined with the abatron it looks like a value is set into the mfio_rqdc register. So I am somewhat puzzled. It is not obvious to me why the autocal is failing to work on the canyonlands. On another project we found that the window constrained slightly when operating in burst mode (via DMA) vs regular ram line reads/writes. I don't know if that could be the same issue where since the failure is just at the time the burst mode is enabled. Thanks, Ayman ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Hangs at relocation on 460EX Target
Thank you Stefan, On Tue, Oct 21, 2008 at 05:54:21PM +0200, Stefan Roese wrote: > On Tuesday 21 October 2008, Ayman M. El-Khashab wrote: > > it is stuck inside the relocation or immediately after it branches > > to the code in RAM. > > I suggest that you enable DEBUG in lib_ppc/board.c (define DEBUG before the > #includes). This will show you a little more. I should have mentioned that we have DEBUG enabled and we've also run the RAM test that is included in u-boot. The ram test does pass. > > But you may be correct that U-Boot hangs/crashes upon relocation. This is > most > likely a problem with the DDR2 configuration. You might have noticed the > latest autocalibration changes for the 4xx DDR2 controller. It's worth to > give these new methods a try. I am not familiar with those, I thought that once the SDRAM is operating you cannot alter those calibration and timing/delay registers. Is this calibration something that is enabled in u-boot or just via the register accesses to the memory controller? Thanks Ayman ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Hangs at relocation on 460EX Target
Hello, We've got our custom hardware in and are having trouble getting u-boot to start up. We've modeled our board close to the canyonlands. The main differences are no sensors, DIMM at 0x51, and a 16Mb NOR flash instead of 64Mb. We boot and get messages and we've determined it is stuck inside the relocation or immediately after it branches to the code in RAM. My first thought is that we need to make several changes to handle the 16Mb flash since there was some code to handle the movement of the 64Mb flash in early_init_r. It seems for us that is not needed. Secondly, there might be some changes needed to the EBC Setup in the config file. However I've compared those to the data sheet and not seeing anything obvious. I have disabled early_init_r and made the following changes to the configuration #define CFG_FLASH_BASE 0xFF00 * later mapped to this addr*/ #define CFG_FLASH_BASE_PHYS_H 0x0 #define CFG_FLASH_BASE_PHYS_L 0xFF00 #define CFG_FLASH_BASE_PHYS (((u64)CFG_FLASH_BASE_PHYS_H << 32) | \ (u64)CFG_FLASH_BASE_PHYS_L) #define CFG_FLASH_SIZE (16 << 20) Any tips to what else I might be missing? I don't recall having this much difficulty last time u-boot was ported to our boards. Thanks Ayman ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Problems with PCI-E Switch on 460EX
I hope somebody can shed some light on our problem. The summary is that when we use a pci-e switch, we don't see anything on the downstream side of the switch in Linux. U-Boot may or may not see the downstream side (details below). We are using the stock canyonlands (460EX) board with both original and new kernels. We have the 1L port as an end-point and the 4L as a RC. We've purchased a PLX 8509 PCI-E Switch and PLX 8612 PCI-E Switch add-in cards. Each of them fits into the 4 lane port. We also have another COTS pci-e sata controller (our control if you will). sata card to the canyonlands, everything works correctly. This tells me that pci-e, discovery, etc are configured / working. sata to the 8509 and the 8509 to the canyonlands, u-boot will detect the sata card, but for whatever reason, Linux does not see it (via lspci or our own tool). sata to the 8612 and the 8612 to the canyonlands, u-boot does not see the card (and obviously linux does not see the card either). One more data point, we have an NI PCI-E GPIB controller. It has a pci-e to pci bridge on board. U-Boot sees the bridge, but again nothing on the downstream port. We have looked at all of these cases using a lecroy pci-e analyzer. In most cases the u-boot code looks to be doing the right thing. The 8612 being the only odd case. We did notice the pci-e bus number change on the analyzer from 3 to (I think 129) -- I still cannot explain this. 1) Do I have to add anything to the device tree for the switch (I did not believe that it was required) 2) Since it appears no switch/bridge downstream device is visible, is something needed in Linux to make these go? I checked both the u-boot and kernel config and saw nothing obvious other than enabling pci-e 3) Does u-boot require any special configuration to enable all these pci-e devices 4) Anything else to try? Thanks - ame ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] canyonlands u-boot ibm-iic question
Hopefully this is on topic for this list. I am using the canyonlands with the included u-boot. I've made a change to the kernel so that I can use the iic device (namely added the 460ex to the compatibility list) with a name matching the one in canyonland.dts It seems to print out when it books Linux, but gives an error as shown here - I am unsure what I need to add to the device tree to get past this point. ibm-iic 4ef600700.i2c: no index specified ibm-iic: probe of 4ef600700.i2c failed with error -22 ibm-iic 4ef600800.i2c: no index specified ibm-iic: probe of 4ef600800.i2c failed with error -22 SEcondly, and I know this is probably not on-topic, How do you access the I2C from userspace? Or how would I read/write the eeprom? thank ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
