Re: [U-Boot] When to create a SoC directory for ARM
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Scott Wood Sent: Friday, September 27, 2013 12:53 AM To: FengHua Cc: trini; sun york-R58495; u-boot Subject: Re: [U-Boot] When to create a SoC directory for ARM On Thu, 2013-09-26 at 13:23 +0800, FengHua wrote: Date: Wed, 25 Sep 2013 20:10:13 -0500 From: Scott Wood scottw...@freescale.com Subject: Re: [U-Boot] When to create a SoC directory for ARM To: sun york-R58495 r58...@freescale.com Cc: Rini tr...@ti.com, Wood Scott-B07421 b07...@freescale.com, u-boot@lists.denx.de u-boot@lists.denx.de, Tom Message-ID: 1380157813.24959.237.ca...@snotra.buserror.net Content-Type: text/plain; charset=UTF-8 On Wed, 2013-09-25 at 20:04 -0500, sun york-R58495 wrote: On Sep 25, 2013, at 4:52 PM, Scott Wood wrote: On Wed, 2013-09-25 at 16:30 -0700, York Sun wrote: Dear Wolfgang, I failed to find the guideline, here is my question. Pardon me if this is a dump question as I am still new to ARM. As David Feng post his patch set to add ARMv8 support, I am trying to enable it for Freescale implementation. Let's name it as LS2 for this discussion. I am thinking to reuse as much as possible for existing codes, which include copying some header files from powerpc partially. I noticed the SoC field in boards.cfg file and I am wondering how to use it effectively. I want to put LS2 specific headers to arch/arm/include/asm/arch-ls2. Do I need to copy all files from arch/arm/include/asm/arch-armv8/? There aren't many but I see mmu.h is included in start.S. I have been searching case like this in ARMv7 but didn't see shared header file (maybe I missed it). Please advise. LS2 is (or perhaps more accurately, contains) an implementation of ARMv8, so you should be using arch-armv8 rather than copying it. True. But I guess LS2 won't be the only LS Freescale is going to make. Where is the best place to put the header file for chassis related registers, like CCSR we have for mpc8xxx. Anything that isn't deeply tied to the ARM architecture should probably just go in include/. I am thinking the best place is arch/arm/include/asm/ls2 (or a better name). Like other ARMv7 variants, I am thinking to put ls2 under arch/arm/cpu/armv8/ as well, to host LS-specific code. Likewise, if it's specifically tied to armv8 it should go in arch/arm/include/asm/arch-armv8, but I'm not sure what would be tied to both armv8 and ls2. Most likely anything LS-specific that needs to go under arch/arm/ should go somewhere like arch/arm/include/asm/ls/ (similar to arch/arm/include/asm/imx- common). -Scott all SOC specific include file should be in arch/arm/include/asm/arch-SOC/ or some common directory(like include/asm/imx-common). Currently, u-boot only link SOC specific(arch-SOC) include directory. You could touch a mmu.h file in arch/arm/include/asm/arch-ls2/ and include arch/arm/include/asm/arch-armv8/mmu.h. or move arch-armv8/mmu.h to arch/arm/include/asm/ to make it as a generic file. Maybe we should distinguish architecture specific include directory and SOC specific include directory. Is the XXX arch-XXX supposed to be an SoC family or a CPU family/architectutre? Usually in 'arch/arm/include/asm' we have both: - arch-armv7 (Arch specific. Houses stuff common to ARMv7 CPU, e.g. Global timer, SP805 WDT..) - arch-mx6 (SoC family specific. Houses stuff like SoC specific IOMUX pads..) We should have something similar for LayerScape. Regards, Bhupesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] When to create a SoC directory for ARM
-Original Message- From: sun york-R58495 Sent: Friday, September 27, 2013 1:19 AM To: Sharma Bhupesh-B45370; Wood Scott-B07421; 'FengHua' Cc: 'trini'; sun york-R58495; 'u-boot' Subject: Re: [U-Boot] When to create a SoC directory for ARM On 09/26/2013 12:46 PM, Sharma Bhupesh-B45370 wrote: -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Scott Wood Sent: Friday, September 27, 2013 12:53 AM To: FengHua Cc: trini; sun york-R58495; u-boot Subject: Re: [U-Boot] When to create a SoC directory for ARM On Thu, 2013-09-26 at 13:23 +0800, FengHua wrote: Date: Wed, 25 Sep 2013 20:10:13 -0500 From: Scott Wood scottw...@freescale.com Subject: Re: [U-Boot] When to create a SoC directory for ARM To: sun york-R58495 r58...@freescale.com Cc: Rini tr...@ti.com, Wood Scott-B07421 b07...@freescale.com, u-boot@lists.denx.de u-boot@lists.denx.de, Tom Message-ID: 1380157813.24959.237.ca...@snotra.buserror.net Content-Type: text/plain; charset=UTF-8 On Wed, 2013-09-25 at 20:04 -0500, sun york-R58495 wrote: On Sep 25, 2013, at 4:52 PM, Scott Wood wrote: On Wed, 2013-09-25 at 16:30 -0700, York Sun wrote: Dear Wolfgang, I failed to find the guideline, here is my question. Pardon me if this is a dump question as I am still new to ARM. As David Feng post his patch set to add ARMv8 support, I am trying to enable it for Freescale implementation. Let's name it as LS2 for this discussion. I am thinking to reuse as much as possible for existing codes, which include copying some header files from powerpc partially. I noticed the SoC field in boards.cfg file and I am wondering how to use it effectively. I want to put LS2 specific headers to arch/arm/include/asm/arch-ls2. Do I need to copy all files from arch/arm/include/asm/arch-armv8/? There aren't many but I see mmu.h is included in start.S. I have been searching case like this in ARMv7 but didn't see shared header file (maybe I missed it). Please advise. LS2 is (or perhaps more accurately, contains) an implementation of ARMv8, so you should be using arch-armv8 rather than copying it. True. But I guess LS2 won't be the only LS Freescale is going to make. Where is the best place to put the header file for chassis related registers, like CCSR we have for mpc8xxx. Anything that isn't deeply tied to the ARM architecture should probably just go in include/. I am thinking the best place is arch/arm/include/asm/ls2 (or a better name). Like other ARMv7 variants, I am thinking to put ls2 under arch/arm/cpu/armv8/ as well, to host LS-specific code. Likewise, if it's specifically tied to armv8 it should go in arch/arm/include/asm/arch-armv8, but I'm not sure what would be tied to both armv8 and ls2. Most likely anything LS-specific that needs to go under arch/arm/ should go somewhere like arch/arm/include/asm/ls/ (similar to arch/arm/include/asm/imx- common). -Scott all SOC specific include file should be in arch/arm/include/asm/arch-SOC/ or some common directory(like include/asm/imx-common). Currently, u-boot only link SOC specific(arch-SOC) include directory. You could touch a mmu.h file in arch/arm/include/asm/arch-ls2/ and include arch/arm/include/asm/arch-armv8/mmu.h. or move arch-armv8/mmu.h to arch/arm/include/asm/ to make it as a generic file. Maybe we should distinguish architecture specific include directory and SOC specific include directory. Is the XXX arch-XXX supposed to be an SoC family or a CPU family/architectutre? Usually in 'arch/arm/include/asm' we have both: - arch-armv7 (Arch specific. Houses stuff common to ARMv7 CPU, e.g. Global timer, SP805 WDT..) - arch-mx6 (SoC family specific. Houses stuff like SoC specific IOMUX pads..) We should have something similar for LayerScape. If you look closely, you will find arch-armv7 and its sub-arch including am33xx, at91, exynos, etc. I cannot find any sub-arch inside 'arch/arm/include/asm/arch-armv7' (I am referring to reference [1]) I think you are talking about 'arch/arm/cpu/arch-armv7'. That's not what I was referring to my original mail. I believe David was mentioning the same in his mail (mmu.h inside 'arch/arm/include/asm/arch-armv8') . References: [1] http://git.denx.de/?p=u-boot.git;a=tree;f=arch/arm/include/asm/arch-armv7;h=cc9d1ccedcba6881922b12ae8377627cb8632c46;hb=HEAD Regards, Bhupesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How do ARM platform initialize DDR?
Adding Vipin to the thread as he has better knowledge on this than me. Vipin can you please add your comments here as well.. As far as I can remember for the ARM based SPEAr SoCs on which we worked in the past: - At the moment the DDR initialization code for various ARM SoCs in u-boot is scattered across ARCH directories: See examples of SPEAr (based on ARM926ejs) [1] and OMAP4 (ARmv7) [2] DDR drivers. - There is no unified driver model in place for DDR driver similar to what is available for eth/serial drivers and we need to formulate a DDR model (something using the suggested framework in [3]) so that the same DDR driver can be shared across PPC and ARM SoCs. References: [1] SPEAr DDR drivers for Denali MPMC - http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/cpu/arm926ejs/spear/start.S;h=7dbd5dbf99e8c6e216cc50e789ec7f103e0ecaea;hb=HEAD#l105 http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/cpu/arm926ejs/spear/spl.c;h=b550404352b8c04f2e5d5d71df41c750c07ab1a8;hb=HEAD#l69 http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/cpu/arm926ejs/spear/spr600_mt47h128m8_3_266_cl5_async.c;h=cc45ab7016b1658eceb545c959bb1b59f33c06c7;hb=HEAD#l12 [2] OMAP4 Elpida DDR drivers - http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/cpu/armv7/omap4/sdram_elpida.c;h=67a79261f778c6afab3d0e3870eac1e18cff8411;hb=HEAD http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/cpu/armv7/omap4/emif.c;h=e89032be75dc916891ccfd70c66e19c4b7b38839;hb=HEAD [3] UDM-cores.txt - http://git.denx.de/?p=u-boot.git;a=blob;f=doc/driver-model/UDM-cores.txt;h=4e1318871a8d9f7f6f329800d6394158e42f85dd;hb=HEAD Regards, Bhupesh -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of MJ embd Sent: Tuesday, September 17, 2013 10:37 PM To: sun york-R58495 Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] How do ARM platform initialize DDR? yes, I am using uboot for arndale board. The code is written by samsung only and it is not static. The best option would be to have an eth / serial driver kind of arch which all soc vendors can share. But ddr is scattered, in absence of that, your point seems valid for fsl specific. -mj On 9/17/13, York Sun york...@freescale.com wrote: Dear MJ, Thanks for your reply. I don't see the file in my copy. Probably it is not merged yet? Anyway, you just confirmed what I found so far. Do you use static setting in dmc_init_ddr3.c? I mean does it adapt to different DDR speeds and modules (if applicable)? In my mind, I am thinking to restructure arch/powerpc/cpu/mpc8xxx/ddr/ to driver/ddr/fsl/ so the same driver can be shared as far as the DDR IP is the same (or similar). York On 09/17/2013 09:34 AM, MJ embd wrote: Hi York, There is no generic driver. AFAIK. Having worked on both mpc85xx and ARM I can tell you about samsung 5250. There are 2 uboots (one spl and other main). In case of sd/mmc boot the internal rom copies the spl uboot to iRAM and the spl boot loader initialises the DDR3. you can check for board/samsung/smdk5250/dmc_init_ddr3.c -Regards mj On 9/17/13, York Sun york...@freescale.com wrote: Albert, Pardon me if this is a dumb question. I have been working on powerpc platforms in the past. Now we (the developers I work with) are exploring ARM cores. I am searching how memory is initialized and found different solutions. Some platforms have memory ready before u-boot even starts, some simply write to a set of registers. I understand many platforms don't share the IP of DDR controller. I am wondering if there is generic DDR driver used by many ARM platforms, like the one we have for powerpc/mpc85xx SoCs. Regards, York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot -- -mj ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v9 2/5] board support of vexpress_aemv8a
Hi David, -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of feng...@phytium.com.cn Sent: Friday, September 13, 2013 2:09 PM To: u-boot@lists.denx.de Cc: tr...@ti.com; David Feng; Wood Scott-B07421 Subject: [U-Boot] [PATCH v9 2/5] board support of vexpress_aemv8a From: David Feng feng...@phytium.com.cn Signed-off-by: David Feng feng...@phytium.com.cn and Sharma Bhupesh b45...@freescale.com --- I would prefer that you add the S-o-b's in the following way (suggested in submitting patch guidelines) and also correct my S-o-b: Signed-off-by: David Feng feng...@phytium.com.cn Signed-off-by: Bhupesh Sharma bhupesh.sha...@freescale.com [snip..] Regards, Bhupesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] net: phy/vitesse: Add support for VSC8514 phy module
Hi Joe, List
-Original Message-
From: Sharma Bhupesh-B45370
Sent: Friday, August 23, 2013 8:18 PM
To: u-boot@lists.denx.de; joe.hershber...@gmail.com
Cc: Goel Arpit-B44344; Sharma Bhupesh-B45370
Subject: [PATCH 1/1] net: phy/vitesse: Add support for VSC8514 phy module
From: Arpit Goel b44...@freescale.com
This patch adds support for VSC8514 PHY module which can be found on
Freescale's T1040RDB boards.
Signed-off-by: Arpit Goel b44...@freescale.com
Signed-off-by: Bhupesh Sharma bhupesh.sha...@freescale.com
---
drivers/net/phy/vitesse.c | 69
++-
1 file changed, 68 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/vitesse.c b/drivers/net/phy/vitesse.c index
5cf103e..c555979 100644
--- a/drivers/net/phy/vitesse.c
+++ b/drivers/net/phy/vitesse.c
@@ -49,6 +49,15 @@
#define MIIM_VSC8574_18G_QSGMII 0x80e0
#define MIIM_VSC8574_18G_CMDSTAT 0x8000
+/* Vitesse VSC8514 control register */
+#define MIIM_VSC8514_GENERAL18 0x12
+#define MIIM_VSC8514_GENERAL19 0x13
+#define MIIM_VSC8514_GENERAL23 0x17
+
+/* Vitesse VSC8514 gerenal purpose register 18 */
+#define MIIM_VSC8514_18G_QSGMII 0x80e0
+#define MIIM_VSC8514_18G_CMDSTAT 0x8000
+
/* CIS8201 */
static int vitesse_config(struct phy_device *phydev) { @@ -148,7 +157,7
@@ static int vsc8601_config(struct phy_device *phydev) static int
vsc8574_config(struct phy_device *phydev) {
u32 val;
- /* configure regiser 19G for MAC */
+ /* configure register 19G for MAC */
phy_write(phydev, MDIO_DEVAD_NONE, PHY_EXT_PAGE_ACCESS,
PHY_EXT_PAGE_ACCESS_GENERAL);
@@ -188,6 +197,53 @@ static int vsc8574_config(struct phy_device *phydev)
return 0;
}
+static int vsc8514_config(struct phy_device *phydev) {
+ u32 val;
+ int timeout = 100;
+
+ /* configure register to access 19G */
+ phy_write(phydev, MDIO_DEVAD_NONE, PHY_EXT_PAGE_ACCESS,
+ PHY_EXT_PAGE_ACCESS_GENERAL);
+
+ val = phy_read(phydev, MDIO_DEVAD_NONE, MIIM_VSC8514_GENERAL19);
+ if (phydev-interface == PHY_INTERFACE_MODE_QSGMII) {
+ /* set bit 15:14 to '01' for QSGMII mode */
+ val = (val 0x3fff) | (1 14);
+ phy_write(phydev, MDIO_DEVAD_NONE,
+ MIIM_VSC8514_GENERAL19, val);
+ /* Enable 4 ports MAC QSGMII */
+ phy_write(phydev, MDIO_DEVAD_NONE, MIIM_VSC8514_GENERAL18,
+ MIIM_VSC8514_18G_QSGMII);
+ } else {
+ /*TODO Add SGMII functionality once spec sheet
+ * for VSC8514 defines complete functionality
+ */
+ }
+
+ val = phy_read(phydev, MDIO_DEVAD_NONE, MIIM_VSC8514_GENERAL18);
+ /* When bit 15 is cleared the command has completed */
+ while ((val MIIM_VSC8514_18G_CMDSTAT) timeout--)
+ val = phy_read(phydev, MDIO_DEVAD_NONE,
MIIM_VSC8514_GENERAL18);
+
+ if (0 == timeout) {
+ printf(PHY 8514 config failed\n);
+ return -1;
+ }
+
+ phy_write(phydev, MDIO_DEVAD_NONE, PHY_EXT_PAGE_ACCESS, 0);
+
+ /* configure register to access 23 */
+ val = phy_read(phydev, MDIO_DEVAD_NONE, MIIM_VSC8514_GENERAL23);
+ /* set bits 10:8 to '000' */
+ val = (val 0xf8ff);
+ phy_write(phydev, MDIO_DEVAD_NONE, MIIM_VSC8514_GENERAL23, val);
+
+ genphy_config_aneg(phydev);
+
+ return 0;
+}
+
static struct phy_driver VSC8211_driver = {
.name = Vitesse VSC8211,
.uid= 0xfc4b0,
@@ -238,6 +294,16 @@ static struct phy_driver VSC8574_driver = {
.shutdown = genphy_shutdown,
};
+static struct phy_driver VSC8514_driver = {
+ .name = Vitesse VSC8514,
+ .uid = 0x70570,
+ .mask = 0x0,
+ .features = PHY_GBIT_FEATURES,
+ .config = vsc8514_config,
+ .startup = vitesse_startup,
+ .shutdown = genphy_shutdown,
+};
+
static struct phy_driver VSC8601_driver = {
.name = Vitesse VSC8601,
.uid = 0x70420,
@@ -298,6 +364,7 @@ int phy_vitesse_init(void)
phy_register(VSC8211_driver);
phy_register(VSC8221_driver);
phy_register(VSC8574_driver);
+ phy_register(VSC8514_driver);
phy_register(VSC8662_driver);
phy_register(cis8201_driver);
phy_register(cis8204_driver);
--
1.7.11.7
Any comments on this patch?
Does it seem fine and can be taken up in Joe's 'net' repo?
Thanks,
Bhupesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] dtc: invalid option -- 'i'
Hi List, I am using a 64-bit ubuntu machine running a 12.04 LTS. I see that the DTC (Device Tree Compiler) version is 1.3.0 $ dtc -v Version: DTC 1.3.0 When I try to compile the latest u-boot 'master' branch (updated yesterday), I get the following error with dtc: dtc: invalid option -- 'i' followed by a Usage suggestion. I checked that a newer DTC version 1.4.0 is available from Linaro, but I can't find an updated version for ubuntu and apt-get returns me a message: device-tree-compiler is already the newest version Any pointers to what I could be doing wrong here? Regards, Bhupesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] dtc: invalid option -- 'i'
-Original Message- From: Tom Rini [mailto:tom.r...@gmail.com] On Behalf Of Tom Rini Sent: Thursday, August 22, 2013 6:22 PM To: Sharma Bhupesh-B45370 Cc: 'u-boot'; 'ubuntu-us...@lists.ubuntu.com'; 'ubuntu- de...@lists.ubuntu.com' Subject: Re: [U-Boot] dtc: invalid option -- 'i' On Thu, Aug 22, 2013 at 07:11:39AM +, Sharma Bhupesh-B45370 wrote: Hi List, I am using a 64-bit ubuntu machine running a 12.04 LTS. I see that the DTC (Device Tree Compiler) version is 1.3.0 $ dtc -v Version: DTC 1.3.0 When I try to compile the latest u-boot 'master' branch (updated yesterday), I get the following error with dtc: dtc: invalid option -- 'i' followed by a Usage suggestion. I checked that a newer DTC version 1.4.0 is available from Linaro, but I can't find an updated version for ubuntu and apt-get returns me a message: device-tree-compiler is already the newest version Any pointers to what I could be doing wrong here? What target are you building for as it should have run the 'checkdtc' rule and told you that you need to install DTC 1.4.0. And yes for Ubuntu you'll need to build your own. Hi Tom, I am trying to build the new support code of ARMv8 (using patches from David Fengua), using: $ make vexpress_aemv8a I will try building a DTC 1.4.0 for u-buntu by myself, but if we are saying that latest u-boot requires DTC 1.4.0 to work well, aren't we breaking u-boot compilation on older systems like ubuntu/fedora which have older DTC versions? Regards, Bhupesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] dtc: invalid option -- 'i'
-Original Message- From: Tom Rini [mailto:tom.r...@gmail.com] On Behalf Of Tom Rini Sent: Thursday, August 22, 2013 11:33 PM To: Sharma Bhupesh-B45370 Cc: 'ubuntu-us...@lists.ubuntu.com'; 'u-boot'; 'FengHua'; 'ubuntu- de...@lists.ubuntu.com' Subject: Re: [U-Boot] dtc: invalid option -- 'i' On Thu, Aug 22, 2013 at 05:55:46PM +, Sharma Bhupesh-B45370 wrote: -Original Message- From: Tom Rini [mailto:tom.r...@gmail.com] On Behalf Of Tom Rini Sent: Thursday, August 22, 2013 6:22 PM To: Sharma Bhupesh-B45370 Cc: 'u-boot'; 'ubuntu-us...@lists.ubuntu.com'; 'ubuntu- de...@lists.ubuntu.com' Subject: Re: [U-Boot] dtc: invalid option -- 'i' On Thu, Aug 22, 2013 at 07:11:39AM +, Sharma Bhupesh-B45370 wrote: Hi List, I am using a 64-bit ubuntu machine running a 12.04 LTS. I see that the DTC (Device Tree Compiler) version is 1.3.0 $ dtc -v Version: DTC 1.3.0 When I try to compile the latest u-boot 'master' branch (updated yesterday), I get the following error with dtc: dtc: invalid option -- 'i' followed by a Usage suggestion. I checked that a newer DTC version 1.4.0 is available from Linaro, but I can't find an updated version for ubuntu and apt-get returns me a message: device-tree-compiler is already the newest version Any pointers to what I could be doing wrong here? What target are you building for as it should have run the 'checkdtc' rule and told you that you need to install DTC 1.4.0. And yes for Ubuntu you'll need to build your own. Hi Tom, I am trying to build the new support code of ARMv8 (using patches from David Fengua), using: $ make vexpress_aemv8a Ah, OK, I'll make sure that it invokes the checkdtc rule as well. I will try building a DTC 1.4.0 for u-buntu by myself, but if we are saying that latest u-boot requires DTC 1.4.0 to work well, aren't we breaking u-boot compilation on older systems like ubuntu/fedora which have older DTC versions? We are, quite intentionally. I should have spelled it out in the -rc1 release notes, but certainly will in the v2013.10 release itself. We've wanted to do these changes for a while (as the rules for invoking dtc got quite complex for handling all the versions) but were able to get a new release out of upstream before changing things around. FWIW, Fedora/related has packages available. I believe some mention of this limitation in the release note would have been great. Yes, fedora has newer packages available, but ubuntu is still adding 1.4.0 DTC support (to newer versions) and I don't know what are the timelines to back-port it on LTS releases like 12.0.4 Thanks for your help. Regards, Bhupesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/5] arm64 patch
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Scott Wood Sent: Saturday, August 17, 2013 1:23 AM To: Dennis Gilmore Cc: tr...@ti.com; u-boot@lists.denx.de; feng...@phytium.com.cn Subject: Re: [U-Boot] [PATCH v3 0/5] arm64 patch On Thu, 2013-08-15 at 23:32 -0500, Dennis Gilmore wrote: On Thu, 15 Aug 2013 21:47:09 +0800 feng...@phytium.com.cn wrote: From: David Feng feng...@phytium.com.cn *** BLURB HERE *** Changes for v3: - rewrite cache.S and exception.S that partly originated from linux kernel, so the license should be ok. - according to scott wood's advice, make the fdt 64bit initrd start address support a seperate patch. David Feng (5): core support of arm64 board support of arm64 arch support 1 of arm64 arch support 2 of arm64 64bit initrd start address support nitpick but the arch is aarch64 not arm64 powerpc is Power Architecture these days but we still call it powerpc. arm64 is a sensible name that doesn't reduce the meaningful part of the name (excluding the word size suffix) down to a single character. Arm64 seems more simple and sensible and in-line with the naming convention used across linux (arch/arm64). I remember reading Linus's comments in favor of keeping a arm64 naming convention in the past (instead of Armv8 or AArch64). Here is that mail thread for reference: https://lkml.org/lkml/2012/7/15/133 Regards, Bhupesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] net: phy/realtek: Add support for RTL8211DN and RTL8211E phy modules
Hi York,
I guess with Andy no longer there as FSL u-boot maintainer, will the patch below
go through you or Joe. If no one has an objection to this patch, can I get a
Acked-by and
can we queue it up for upstream.
Regards,
Bhupesh
-Original Message-
From: Sharma Bhupesh-B45370
Sent: Tuesday, July 23, 2013 2:00 PM
To: u-boot@lists.denx.de; Fleming Andy-AFLEMING;
joe.hershber...@gmail.com
Cc: Sharma Bhupesh-B45370
Subject: RE: [PATCH 1/1] net: phy/realtek: Add support for RTL8211DN and
RTL8211E phy modules
Hi Andy, Joe,
This patch adds support for Realtek PHY modules RTL8211DN and RTL8211E
(variants: RTL8211E-VB-CG, RTL8211E-VL-CG, RTL8211EG-VB-CG), which can
be found on Freescale's T1040RDB boards.
To make the driver more generic across 8211 family, a generic name
8211x is added for macros and function names.
Signed-off-by: Bhupesh Sharma bhupesh.sha...@freescale.com
Can you please review this patch and let me know if these changes seem
suitable to you.
Thanks for your help.
Regards,
Bhupesh
---
drivers/net/phy/realtek.c | 77
+++--
--
1 file changed, 51 insertions(+), 26 deletions(-)
diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
index
b7e2753..b971456 100644
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@ -26,18 +26,18 @@
#define PHY_AUTONEGOTIATE_TIMEOUT 5000
-/* RTL8211B PHY Status Register */
-#define MIIM_RTL8211B_PHY_STATUS 0x11
-#define MIIM_RTL8211B_PHYSTAT_SPEED0xc000
-#define MIIM_RTL8211B_PHYSTAT_GBIT 0x8000
-#define MIIM_RTL8211B_PHYSTAT_100 0x4000
-#define MIIM_RTL8211B_PHYSTAT_DUPLEX 0x2000
-#define MIIM_RTL8211B_PHYSTAT_SPDDONE 0x0800
-#define MIIM_RTL8211B_PHYSTAT_LINK 0x0400
-
-
-/* RealTek RTL8211B */
-static int rtl8211b_config(struct phy_device *phydev)
+/* RTL8211x PHY Status Register */
+#define MIIM_RTL8211x_PHY_STATUS 0x11
+#define MIIM_RTL8211x_PHYSTAT_SPEED0xc000
+#define MIIM_RTL8211x_PHYSTAT_GBIT 0x8000
+#define MIIM_RTL8211x_PHYSTAT_100 0x4000
+#define MIIM_RTL8211x_PHYSTAT_DUPLEX 0x2000
+#define MIIM_RTL8211x_PHYSTAT_SPDDONE 0x0800
+#define MIIM_RTL8211x_PHYSTAT_LINK 0x0400
+
+
+/* RealTek RTL8211x */
+static int rtl8211x_config(struct phy_device *phydev)
{
phy_write(phydev, MDIO_DEVAD_NONE, MII_BMCR, BMCR_RESET);
@@ -46,20 +46,20 @@ static int rtl8211b_config(struct phy_device
*phydev)
return 0;
}
-static int rtl8211b_parse_status(struct phy_device *phydev)
+static int rtl8211x_parse_status(struct phy_device *phydev)
{
unsigned int speed;
unsigned int mii_reg;
- mii_reg = phy_read(phydev, MDIO_DEVAD_NONE,
MIIM_RTL8211B_PHY_STATUS);
+ mii_reg = phy_read(phydev, MDIO_DEVAD_NONE,
MIIM_RTL8211x_PHY_STATUS);
- if (!(mii_reg MIIM_RTL8211B_PHYSTAT_SPDDONE)) {
+ if (!(mii_reg MIIM_RTL8211x_PHYSTAT_SPDDONE)) {
int i = 0;
/* in case of timeout -link is cleared */
phydev-link = 1;
puts(Waiting for PHY realtime link);
- while (!(mii_reg MIIM_RTL8211B_PHYSTAT_SPDDONE)) {
+ while (!(mii_reg MIIM_RTL8211x_PHYSTAT_SPDDONE)) {
/* Timeout reached ? */
if (i PHY_AUTONEGOTIATE_TIMEOUT) {
puts( TIMEOUT !\n);
@@ -71,29 +71,29 @@ static int rtl8211b_parse_status(struct phy_device
*phydev)
putc('.');
udelay(1000); /* 1 ms */
mii_reg = phy_read(phydev, MDIO_DEVAD_NONE,
- MIIM_RTL8211B_PHY_STATUS);
+ MIIM_RTL8211x_PHY_STATUS);
}
puts( done\n);
udelay(50); /* another 500 ms (results in faster
booting) */
} else {
- if (mii_reg MIIM_RTL8211B_PHYSTAT_LINK)
+ if (mii_reg MIIM_RTL8211x_PHYSTAT_LINK)
phydev-link = 1;
else
phydev-link = 0;
}
- if (mii_reg MIIM_RTL8211B_PHYSTAT_DUPLEX)
+ if (mii_reg MIIM_RTL8211x_PHYSTAT_DUPLEX)
phydev-duplex = DUPLEX_FULL;
else
phydev-duplex = DUPLEX_HALF;
- speed = (mii_reg MIIM_RTL8211B_PHYSTAT_SPEED);
+ speed = (mii_reg MIIM_RTL8211x_PHYSTAT_SPEED);
switch (speed) {
- case MIIM_RTL8211B_PHYSTAT_GBIT:
+ case MIIM_RTL8211x_PHYSTAT_GBIT:
phydev-speed = SPEED_1000;
break;
- case MIIM_RTL8211B_PHYSTAT_100:
+ case MIIM_RTL8211x_PHYSTAT_100:
phydev-speed = SPEED_100;
break;
default:
@@ -103,28 +103,53 @@ static int rtl8211b_parse_status(struct
phy_device
*phydev)
return 0;
}
-static int rtl8211b_startup(struct phy_device *phydev)
+static int
Re: [U-Boot] [PATCH 1/1] net: phy/realtek: Add support for RTL8211DN and RTL8211E phy modules
-Original Message- From: sun york-R58495 Sent: Thursday, August 15, 2013 2:29 AM To: Sharma Bhupesh-B45370 Cc: 'u-boot@lists.denx.de'; 'joe.hershber...@gmail.com' Subject: Re: [PATCH 1/1] net: phy/realtek: Add support for RTL8211DN and RTL8211E phy modules On 08/14/2013 01:30 PM, Sharma Bhupesh-B45370 wrote: Hi York, I guess with Andy no longer there as FSL u-boot maintainer, will the patch below go through you or Joe. If no one has an objection to this patch, can I get a Acked-by and can we queue it up for upstream. Acked-by: York Sun york...@freescale.com This patch doesn't involve mpc85xx or mpc86xx. I don't see why it should go into 85xx tree. Do you have other patch depending on it? I believe this patch is completely independent of the mpc series. As Andy was the original author of the RTL phy module(s) driver in u-boot, I was expecting that I needed a Acked-by from him before this patch can be taken up via Andy's/Joe's tree. As far as I remember, Joe has already mentioned that this patch looks 'good' to him. Joe, if you have no objection to the patch, can you please pick the same in your tree (now that York has already Acked the same). Thanks, Bhupesh York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Query: Ethernet switch support
Hi List, I am trying to add support of a Vitesse L2 switch in u-boot (in unmanaged configuration). I was analyzing whether advanced features like flow control, link-aggregation etc are required to be supported for a L2 switch working in a u-boot bootloader level. My point-of-view is that the L2 switch, should support only bare-minimum tftp of images, ping to other ethernet entities, bootp .. type of commands on u-boot and as such the L2 switch u-boot driver doesn't need to address flow-control and other such advanced features (probably of interest for a Linux device driver). But, I am not sure about the design approaches used to support previous switch modules in u-boot. Also I had a query whether there is a common switch framework in-place/under-consideration in u-boot, similar to what is already present in OpenWrt code: https://dev.openwrt.org/browser/trunk/package/boot/uboot-lantiq/patches/0019-net-switchlib-add-framework-for-ethernet-switch-driv.patch?rev=35292 Would porting this to u-boot make sense to have a common framework for ethernet switch in-place? Can you please let me know your views on the same and point me to any reference switch drivers that support these features. Regards, Bhupesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Query: Ethernet switch support
Hi Albert, Thanks for your reply. -Original Message- From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net] Sent: Monday, July 29, 2013 10:27 PM To: Sharma Bhupesh-B45370 Cc: 'u-boot@lists.denx.de' Subject: Re: [U-Boot] Query: Ethernet switch support Hi Sharma, On Mon, 29 Jul 2013 15:33:39 +, Sharma Bhupesh-B45370 b45...@freescale.com wrote: Hi List, I am trying to add support of a Vitesse L2 switch in u-boot (in unmanaged configuration). I was analyzing whether advanced features like flow control, link-aggregation etc are required to be supported for a L2 switch working in a u-boot bootloader level. My point-of-view is that the L2 switch, should support only bare-minimum tftp of images, ping to other ethernet entities, bootp .. type of commands on u-boot and as such the L2 switch u-boot driver doesn't need to address flow-control and other such advanced features (probably of interest for a Linux device driver). But, I am not sure about the design approaches used to support previous switch modules in u-boot. Also I had a query whether there is a common switch framework in-place/under-consideration in u-boot, similar to what is already present in OpenWrt code: https://dev.openwrt.org/browser/trunk/package/boot/uboot-lantiq/patche s/0019-net-switchlib-add-framework-for-ethernet-switch-driv.patch?rev= 35292 Would porting this to u-boot make sense to have a common framework for ethernet switch in-place? Can you please let me know your views on the same and point me to any reference switch drivers that support these features. There is some support for switches in U-Boot (e.g. mv88e61xx) but no framework that I know of; and I suspect what is expected from the switch in U-Boot is that it does not hamper Ethernet operations, nothing more. for mv88e61xx, this is done through a fixed configuration. In my use-case also the L2 switch is supposed to be configured via a fixed configuration (setting up the switch in an unmanaged configuration). I will try to have a look the mv88e61xx example and then formulate something on similar lines. Regards, Bhupesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] net: phy/realtek: Add support for RTL8211DN and RTL8211E phy modules
Hi Andy, Joe,
This patch adds support for Realtek PHY modules RTL8211DN and RTL8211E
(variants: RTL8211E-VB-CG, RTL8211E-VL-CG, RTL8211EG-VB-CG), which can be
found on Freescale's T1040RDB boards.
To make the driver more generic across 8211 family, a generic name 8211x
is added for macros and function names.
Signed-off-by: Bhupesh Sharma bhupesh.sha...@freescale.com
Can you please review this patch and let me know if these changes seem suitable
to you.
Thanks for your help.
Regards,
Bhupesh
---
drivers/net/phy/realtek.c | 77 +++--
--
1 file changed, 51 insertions(+), 26 deletions(-)
diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c index
b7e2753..b971456 100644
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@ -26,18 +26,18 @@
#define PHY_AUTONEGOTIATE_TIMEOUT 5000
-/* RTL8211B PHY Status Register */
-#define MIIM_RTL8211B_PHY_STATUS 0x11
-#define MIIM_RTL8211B_PHYSTAT_SPEED0xc000
-#define MIIM_RTL8211B_PHYSTAT_GBIT 0x8000
-#define MIIM_RTL8211B_PHYSTAT_100 0x4000
-#define MIIM_RTL8211B_PHYSTAT_DUPLEX 0x2000
-#define MIIM_RTL8211B_PHYSTAT_SPDDONE 0x0800
-#define MIIM_RTL8211B_PHYSTAT_LINK 0x0400
-
-
-/* RealTek RTL8211B */
-static int rtl8211b_config(struct phy_device *phydev)
+/* RTL8211x PHY Status Register */
+#define MIIM_RTL8211x_PHY_STATUS 0x11
+#define MIIM_RTL8211x_PHYSTAT_SPEED0xc000
+#define MIIM_RTL8211x_PHYSTAT_GBIT 0x8000
+#define MIIM_RTL8211x_PHYSTAT_100 0x4000
+#define MIIM_RTL8211x_PHYSTAT_DUPLEX 0x2000
+#define MIIM_RTL8211x_PHYSTAT_SPDDONE 0x0800
+#define MIIM_RTL8211x_PHYSTAT_LINK 0x0400
+
+
+/* RealTek RTL8211x */
+static int rtl8211x_config(struct phy_device *phydev)
{
phy_write(phydev, MDIO_DEVAD_NONE, MII_BMCR, BMCR_RESET);
@@ -46,20 +46,20 @@ static int rtl8211b_config(struct phy_device *phydev)
return 0;
}
-static int rtl8211b_parse_status(struct phy_device *phydev)
+static int rtl8211x_parse_status(struct phy_device *phydev)
{
unsigned int speed;
unsigned int mii_reg;
- mii_reg = phy_read(phydev, MDIO_DEVAD_NONE,
MIIM_RTL8211B_PHY_STATUS);
+ mii_reg = phy_read(phydev, MDIO_DEVAD_NONE,
MIIM_RTL8211x_PHY_STATUS);
- if (!(mii_reg MIIM_RTL8211B_PHYSTAT_SPDDONE)) {
+ if (!(mii_reg MIIM_RTL8211x_PHYSTAT_SPDDONE)) {
int i = 0;
/* in case of timeout -link is cleared */
phydev-link = 1;
puts(Waiting for PHY realtime link);
- while (!(mii_reg MIIM_RTL8211B_PHYSTAT_SPDDONE)) {
+ while (!(mii_reg MIIM_RTL8211x_PHYSTAT_SPDDONE)) {
/* Timeout reached ? */
if (i PHY_AUTONEGOTIATE_TIMEOUT) {
puts( TIMEOUT !\n);
@@ -71,29 +71,29 @@ static int rtl8211b_parse_status(struct phy_device
*phydev)
putc('.');
udelay(1000); /* 1 ms */
mii_reg = phy_read(phydev, MDIO_DEVAD_NONE,
- MIIM_RTL8211B_PHY_STATUS);
+ MIIM_RTL8211x_PHY_STATUS);
}
puts( done\n);
udelay(50); /* another 500 ms (results in faster
booting) */
} else {
- if (mii_reg MIIM_RTL8211B_PHYSTAT_LINK)
+ if (mii_reg MIIM_RTL8211x_PHYSTAT_LINK)
phydev-link = 1;
else
phydev-link = 0;
}
- if (mii_reg MIIM_RTL8211B_PHYSTAT_DUPLEX)
+ if (mii_reg MIIM_RTL8211x_PHYSTAT_DUPLEX)
phydev-duplex = DUPLEX_FULL;
else
phydev-duplex = DUPLEX_HALF;
- speed = (mii_reg MIIM_RTL8211B_PHYSTAT_SPEED);
+ speed = (mii_reg MIIM_RTL8211x_PHYSTAT_SPEED);
switch (speed) {
- case MIIM_RTL8211B_PHYSTAT_GBIT:
+ case MIIM_RTL8211x_PHYSTAT_GBIT:
phydev-speed = SPEED_1000;
break;
- case MIIM_RTL8211B_PHYSTAT_100:
+ case MIIM_RTL8211x_PHYSTAT_100:
phydev-speed = SPEED_100;
break;
default:
@@ -103,28 +103,53 @@ static int rtl8211b_parse_status(struct phy_device
*phydev)
return 0;
}
-static int rtl8211b_startup(struct phy_device *phydev)
+static int rtl8211x_startup(struct phy_device *phydev)
{
/* Read the Status (2x to make sure link is right) */
genphy_update_link(phydev);
- rtl8211b_parse_status(phydev);
+ rtl8211x_parse_status(phydev);
return 0;
}
+/* Support for RTL8211B PHY */
static struct phy_driver RTL8211B_driver = {
.name = RealTek RTL8211B,
.uid = 0x1cc910,
.mask = 0xf0,
.features = PHY_GBIT_FEATURES,
- .config = rtl8211b_config,
- .startup = rtl8211b_startup,
+ .config = rtl8211x_config,
+
