Re: [U-Boot] bdi3000 configurtio file for mpc8308RDB
Dear Avner Flesch,
In message 4A6F885E2BDE12468EC281BA9F1CB58F09067363@DBXPRD0610MB359.eurprd06.prod.outlook.com you wrote:
I need bdi3000 reg file and u-boot configuration file for MPB8308RDB Where can I find those fies?
The register files provided with the Abatron firmware are generic enough. We used the reg8313e.def with the MPC7308RDB.
As for the config file, see the attachment.
Hope this helps.
Best regards,
Wolfgang Denk
Hi Wolfgang and Avner (and the Freescale developers),
I need bdi3000 reg file and u-boot configuration file for MPB8308RDB Where can I find those fies?
The register files provided with the Abatron firmware are generic enough. We used the reg8313e.def with the MPC7308RDB.
As for the config file, see the attachment.
I've just purchased a couple of these boards, so thanks for the configuration file Wolfgang.
I'm planning on using this processor as a PCIe end-point in a CompactPCI Serial (CPCI-S.0) board.
I used the MPC8349EA on the CompactPCI incarnation of this type of hardware (based on Wolfgang's recommendation of the part):
http://www.ovro.caltech.edu/~dwh/carma_board/
Ira Snyder worked on the U-Boot and PowerPC code, and he's pushed all the work we've done into the mainline U-Boot and Linux trees, i.e., we give back to the community :)
The MPC8308 processor will essentially act as a PCI Express bridge to some data processing FPGAs.
Grazing through the MPC8308 errata, there don't appear to be any major 'gotchas' with this part. The local bus is not multiplexed, so I'll need some minor changes to my UPM bridge logic, but other than that it looks very similar to the MPC8349EA.
Has anyone had any bad experiences with this part, or is there some 'feature' of the part I should be aware of?
Just looking for comments/feedback.
Thanks!
Cheers, Dave
On Thu, 26 Jul 2012 10:05:46 -0700 David Hawkins dwh@ovro.caltech.edu wrote:
Has anyone had any bad experiences with this part, or is there some 'feature' of the part I should be aware of?
it has a different DMA engine than the rest of the mpc8xxx parts. Ilya Yanok added support for it - see Linux commit ba2eea2, drivers/dma/mpc512x_dma.c.
Kim
Hi Kim,
Has anyone had any bad experiences with this part, or is there some 'feature' of the part I should be aware of?
it has a different DMA engine than the rest of the mpc8xxx parts. Ilya Yanok added support for it - see Linux commit ba2eea2, drivers/dma/mpc512x_dma.c.
Thanks.
I'd noted that it did not have the external DMA pins that the MPC8349EA has. However, I believe that I can live with that. We had used those pins for flow control with an FPGA configuration controller. However, I can do that with an interrupt if need be.
Ira - could you please take a look at the DMA controller and see if you think it'll work for us.
Cheers, Dave
Dear David Hawkins,
In message 501178EA.6050701@ovro.caltech.edu you wrote:
Grazing through the MPC8308 errata, there don't appear to be any major 'gotchas' with this part. ...
... not unless you try to use USB device mode.
Has anyone had any bad experiences with this part, or is there some 'feature' of the part I should be aware of?
USB device mode doesn't work reliably, and FSL was never able or willing to come up with a solution. When this issue happens, the USB device controller not only returns a truncated packet to the gadget driver, but doesn't report URB completion to the host either. The host never gets an URB complete event, so you will see first a delay, and then the host resets the device. The issue can be reproduced with massive writes to a mass-storage device.
Best regards,
Wolfgang Denk
Hi Wolfgang,
Grazing through the MPC8308 errata, there don't appear to be any major 'gotchas' with this part. ...
... not unless you try to use USB device mode.
Ah, that is a gotcha then.
Has anyone had any bad experiences with this part, or is there some 'feature' of the part I should be aware of?
USB device mode doesn't work reliably, and FSL was never able or willing to come up with a solution. When this issue happens, the USB device controller not only returns a truncated packet to the gadget driver, but doesn't report URB completion to the host either. The host never gets an URB complete event, so you will see first a delay, and then the host resets the device. The issue can be reproduced with massive writes to a mass-storage device.
The CPCI-S.0 specification defines USB, Ethernet, and PCIe over the backplane.
We're going to use Ethernet for monitor/control traffic, and PCIe for data transfers.
I had planned on using the PowerPC USB interface to implement at least some form of 'USB device' communication with the board, eg., something like USB-to-Serial or CDC class.
In your opinion, is MPC8308 USB Device Mode completely broken?
If that is the case, then if I want a UART over CPCI-S.0 USB, I can use an FTDI FT245/FT232 on the CPCI-S.0 USB interface and wire it into either a PowerPC UART or the system control FPGA.
How about USB Host mode? The board will communicate with a rear transition module (another board plugged in from the rear side of the chassis). If MPC8308 USB Host Mode is reliable, then I can wire the USB interface through the backplane for use on the RTM, eg., for talking to an FT245/232 device or a USB microcontroller.
Thanks for the valuable feedback.
Cheers, Dave
Dear David Hawkins,
In message 50118FE1.2000806@ovro.caltech.edu you wrote:
In your opinion, is MPC8308 USB Device Mode completely broken?
Define completely...
When acting as a mass storage device, we saw some ~14 MB/s throughput to the device when the bug did not trigger; when it did, we got 1.8 MB/s and less, and many device reset messages in the system logs.
How about USB Host mode? The board will communicate with a rear transition module (another board plugged in from the rear side of the chassis). If MPC8308 USB Host Mode is reliable, then I can wire the USB interface through the backplane for use on the RTM, eg., for talking to an FT245/232 device or a USB microcontroller.
Host mode workes fine.
Best regards,
Wolfgang Denk
Hi Wolfgang,
In your opinion, is MPC8308 USB Device Mode completely broken?
Define completely...
:)
When acting as a mass storage device, we saw some ~14 MB/s throughput to the device when the bug did not trigger; when it did, we got 1.8 MB/s and less, and many device reset messages in the system logs.
Ok, that sounds annoying enough that I won't bother to support the MPC8308 device mode down the backplane.
How about USB Host mode? The board will communicate with a rear transition module (another board plugged in from the rear side of the chassis). If MPC8308 USB Host Mode is reliable, then I can wire the USB interface through the backplane for use on the RTM, eg., for talking to an FT245/232 device or a USB microcontroller.
Host mode works fine.
Great! I'll put a USB3300 PHY on the board, and run the USB over to the RTM.
Thanks for sharing your experiences, its much appreciated.
Cheers, Dave
participants (3)
-
David Hawkins -
Kim Phillips -
Wolfgang Denk