[U-Boot] [PATCH 0/2] P2020RDB Support Added
Hello All
The following patch series add P2020RDB platform support in u-boot.
1. [PATCH 1/2] Removed CONFIG_NUM_CPUS for 85xx/86xx Freescale processor series. This patch removes the compiler define for CONFIG_NUM_CPUS, instead the value is obtained dynamically by reading the SVR value and checking for it in the CPU_TYPE_ENTRY . The advantage of this is that we may be able to use the same u-boot image across the platforms where there are minor differences amongst them for example P1/P2 series of QorIQ processors. 2. [PATCH 2/2] P2020RDB Platform support added. Basic platform support has been tested along with eTSEC, NAND, NOR, I2C, PCIe etc.
Overview of P2020RDB platform ========================== - DDR DDR2 1G - NOR Flash 16MByte - NAND Flash 32MByte - Ethernet There are 3 ethernet interfaces 1) etSEC1 - RGMII - connected to a 5 port Vitesse Switch(VSC7385) - Switch is memory mapped through eLBC interface(CS#2) - IRQ1 2) etSEC2 - SGMII - connected to VSC8221 - IRQ2 3) etSEC3 - RGMII - connected to VSC8641 - IRQ3 - 2 1X PCIe interfaces - SD/MMC ,USB - SPI EEPROM - Serial I2C EEPROM
u-boot version 2009.06 prepared from http://git.denx.de/u-boot-mpc85xx.git Last 2 commits on the tree
commit 8e5e9b940cdede0debe528cdd7edccccbb3ebf2a Author: Wolfgang Denk wd@denx.de Date: Tue Jul 7 22:35:02 2009 +0200
Coding style cleanup; update CHANGELOG
Signed-off-by: Wolfgang Denk wd@denx.de
commit a48ecc969f8d2d0fe9167962e9b8b4cca52de10b Merge: bec9cab... ceb70b4... Author: Wolfgang Denk wd@denx.de Date: Tue Jul 7 22:22:05 2009 +0200
Merge branch 'master' of git://git.denx.de/u-boot-arm
Conflicts: drivers/spi/Makefile
Signed-off-by: Wolfgang Denk wd@denx.de
Regards Poonam
Dear "Aggrwal Poonam-B10812",
In message 1BD5CFC378ED0946B688E0C9BA2EF095129F32@zin33exm24.fsl.freescale.net you wrote:
The following patch series add P2020RDB platform support in u-boot.
You are probably aware thatthe merge window is closed. That means that this will have to wait for the next merge window to open (according to schedule in early September).
The responsible custodian may decide to run this thorugh his (and then my) "next" branch, though.
Which brings up the next question:
Kumar: who is supposed to be responsible custodian for QorIQ code? Should we update / reorganize the list of custodians for Freescale's processors?
Best regards,
Wolfgang Denk
On Jul 21, 2009, at 5:57 AM, Wolfgang Denk wrote:
Which brings up the next question:
Kumar: who is supposed to be responsible custodian for QorIQ code? Should we update / reorganize the list of custodians for Freescale's processors?
QorIQ products fall into one of two categories. Either they are really 85xx products like p2020 and just renamed by marketing or they are based on the new "corenet" platform like p4080. Either way Andy & I should be the custodians.
- k
Dear Kumar Gala,
In message C1E6CEBE-CA48-48ED-B28C-04F3156BB8BE@freescale.com you wrote:
Kumar: who is supposed to be responsible custodian for QorIQ code? Should we update / reorganize the list of custodians for Freescale's processors?
QorIQ products fall into one of two categories. Either they are really 85xx products like p2020 and just renamed by marketing or they are based on the new "corenet" platform like p4080. Either way Andy & I should be the custodians.
OK, thanks; updated list of custodians accordingly.
Best regards,
Wolfgang Denk
participants (3)
-
Aggrwal Poonam-B10812 -
Kumar Gala -
Wolfgang Denk