Re: [U-Boot] [PATCH] net: fec_mxc: fix mii_speed configuration for MX6's
Hi Markus,
On Thu, Feb 20, 2014 at 08:40:03AM +0100, Markus Niebel wrote:
Hello Phillip,
Am 19.02.2014 15:27, wrote Philippe De Muyter:
On MX6DL at least, measured mdc speed was wrong (3.3 Mhz instead of 2.5
Mhz), because of wrong assumptions about the reference clock and the
way the divider is used.
I have fixed that for all MX6's by using the IPG clock as the reference
clock, and applying the - 1 correction when we have a ENET MAC instead
of a FEC MAC, just like what is done in the fec linux driver.
this should be fixed with
ARM: imx6: fix wrong fec clk
NET: fec_mxc: fix MDIO clock prescaler calculation
and was pulled yesterday to
u-boot-arm/master
I am working with plain u-boot (git://git.denx.de/u-boot.git), and of course
those patches were not yet there yesterday :)
Thanks
Philippe
Signed-off-by: Philippe De Muyter p...@macqel.be
---
drivers/net/fec_mxc.c | 20 +---
1 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index 3b2b995..3ab0ecd 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -124,13 +124,27 @@ static int fec_mdio_read(struct ethernet_regs *eth,
uint8_t phyAddr,
static void fec_mii_setspeed(struct ethernet_regs *eth)
{
+ u32 sysclock;
+ u32 mii_speed;
+
/*
* Set MII_SPEED = (1/(mii_speed * 2)) * System Clock
* and do not drop the Preamble.
+* shift the result by 1, because MII_SPEED field is at bits 6..1.
*/
- writelimx_get_fecclk() / 100) + 2) / 5) 1,
- eth-mii_speed);
- debug(%s: mii_speed %08x\n, __func__, readl(eth-mii_speed));
+#if defined(CONFIG_MX6)
+ sysclock = mxc_get_clock(MXC_IPG_CLK);
+#else
+ sysclock = imx_get_fecclk();
+#endif
+#define MIIM_SPEED 250
+ mii_speed = DIV_ROUND_UP(sysclock, (MIIM_SPEED * 2));
+#ifdef FEC_QUIRK_ENET_MAC
+ mii_speed -= 1;
+#endif
+ writel(mii_speed 1, eth-mii_speed);
+ debug(%s: sysclock %u, mii_speed %08x\n, __func__, sysclock,
+ readl(eth-mii_speed));
}
static int fec_mdio_write(struct ethernet_regs *eth, uint8_t phyAddr,
--
Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] net: phy: micrel: add support for KSZ8895 switch in SMI mode
This patch adds a phy driver for the Micrel KSZ8895 switch. As the SoC MAC
is directly connected to the switch MAC the link to the switch is always up.
But the KSZ8895 switch can be hardwired in three configuration modes :
- not configurable with eventually an eeprom-stored configuration
- configurable by the mdio/mdc connection (SMI protocol)
- configurable by a SPI connection.
In not configurable mode, the switch starts automatically, but in the
other modes, it must be started programmatically, by writing 1 in
configuration register 1.
We only support the not configurable and mdio/mdc (aka SMI) modes here.
Signed-off-by: Philippe De Muyter p...@macqel.be
Cc: Christian Gmeiner christian.gmei...@gmail.com
---
drivers/net/phy/micrel.c | 58 ++
1 files changed, 58 insertions(+), 0 deletions(-)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index 5d7e3be..8fbd7d5 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -22,6 +22,63 @@ static struct phy_driver KSZ804_driver = {
.shutdown = genphy_shutdown,
};
+/**
+ * KSZ8895
+ */
+
+static unsigned short smireg_to_phy(unsigned short reg)
+{
+ return ((reg 0xc0) 3) + 0x06 + ((reg 0x20) 5);
+}
+
+static unsigned short smireg_to_reg(unsigned short reg)
+{
+ return reg 0x1F;
+}
+
+static void ksz8895_write_smireg(struct phy_device *phydev, int smireg, int
val)
+{
+ phydev-bus-write(phydev-bus, smireg_to_phy(smireg), MDIO_DEVAD_NONE,
+ smireg_to_reg(smireg), val);
+}
+
+#if 0
+static int ksz8895_read_smireg(struct phy_device *phydev, int smireg)
+{
+ return phydev-bus-read(phydev-bus, smireg_to_phy(smireg),
+ MDIO_DEVAD_NONE, smireg_to_reg(smireg));
+}
+#endif
+
+int ksz8895_config(struct phy_device *phydev)
+{
+ /* we are connected directly to the switch without
+* dedicated PHY. SCONF1 == 001 */
+ phydev-link = 1;
+ phydev-duplex = DUPLEX_FULL;
+ phydev-speed = SPEED_100;
+
+ /* Force the switch to start */
+ ksz8895_write_smireg(phydev, 1, 1);
+
+ return 0;
+}
+
+static int ksz8895_startup(struct phy_device *phydev)
+{
+ return 0;
+}
+
+static struct phy_driver ksz8895_driver = {
+ .name = Micrel KSZ8895/KSZ8864,
+ .uid = 0x221450,
+ .mask = 0xe1,
+ .features = PHY_BASIC_FEATURES,
+ .config = ksz8895_config,
+ .startup = ksz8895_startup,
+ .shutdown = genphy_shutdown,
+};
+
#ifndef CONFIG_PHY_MICREL_KSZ9021
/*
* I can't believe Micrel used the exact same part number
@@ -222,5 +279,6 @@ int phy_micrel_init(void)
phy_register(KS8721_driver);
#endif
phy_register(ksz9031_driver);
+ phy_register(ksz8895_driver);
return 0;
}
--
1.7.5.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: fec_mxc: fix mii_speed configuration for MX6's
On Wed, Feb 19, 2014 at 12:19:04PM -0700, Troy Kisky wrote:
On 2/19/2014 7:27 AM, Philippe De Muyter wrote:
On MX6DL at least, measured mdc speed was wrong (3.3 Mhz instead of 2.5
Mhz), because of wrong assumptions about the reference clock and the
way the divider is used.
I have fixed that for all MX6's by using the IPG clock as the reference
clock, and applying the - 1 correction when we have a ENET MAC instead
of a FEC MAC, just like what is done in the fec linux driver.
Signed-off-by: Philippe De Muyter p...@macqel.be
---
drivers/net/fec_mxc.c | 20 +---
1 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index 3b2b995..3ab0ecd 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -124,13 +124,27 @@ static int fec_mdio_read(struct ethernet_regs *eth,
uint8_t phyAddr,
static void fec_mii_setspeed(struct ethernet_regs *eth)
{
+ u32 sysclock;
+ u32 mii_speed;
+
/*
* Set MII_SPEED = (1/(mii_speed * 2)) * System Clock
* and do not drop the Preamble.
+* shift the result by 1, because MII_SPEED field is at bits 6..1.
*/
- writelimx_get_fecclk() / 100) + 2) / 5) 1,
- eth-mii_speed);
- debug(%s: mii_speed %08x\n, __func__, readl(eth-mii_speed));
+#if defined(CONFIG_MX6)
+ sysclock = mxc_get_clock(MXC_IPG_CLK);
+#else
+ sysclock = imx_get_fecclk();
+#endif
Why not fix it in arch/arm/cpu/armv7/mx6/clock.c ?
u32 imx_get_fecclk(void)
{
- return decode_pll(PLL_ENET, MXC_HCLK);
+ mxc_get_clock(MXC_IPG_CLK);
}
Yeah. I had not thought about it. Thanks.
Actually, one could also call directly get_ipg_clk().
+#define MIIM_SPEED 250
+ mii_speed = DIV_ROUND_UP(sysclock, (MIIM_SPEED * 2));
+#ifdef FEC_QUIRK_ENET_MAC
+ mii_speed -= 1;
+#endif
+ writel(mii_speed 1, eth-mii_speed);
+ debug(%s: sysclock %u, mii_speed %08x\n, __func__, sysclock,
+ readl(eth-mii_speed));
}
static int fec_mdio_write(struct ethernet_regs *eth, uint8_t phyAddr,
--
Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] net: fec_mxc: fix mii_speed configuration for MX6's
On MX6DL at least, measured mdc speed was wrong (3.3 Mhz instead of 2.5
Mhz), because of wrong assumptions about the reference clock and the
way the divider is used.
I have fixed that for all MX6's by using the IPG clock as the reference
clock, and applying the - 1 correction when we have a ENET MAC instead
of a FEC MAC, just like what is done the fec linux driver.
Signed-off-by: Philippe De Muyter p...@macqel.be
---
Change since v1:
- call get_ipg_clk() directly in mx6's imx_get_fecclk()
arch/arm/cpu/armv7/mx6/clock.c |2 +-
drivers/net/fec_mxc.c | 16 +---
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c
index 5617a41..83bb3b7 100644
--- a/arch/arm/cpu/armv7/mx6/clock.c
+++ b/arch/arm/cpu/armv7/mx6/clock.c
@@ -409,7 +409,7 @@ u32 imx_get_uartclk(void)
u32 imx_get_fecclk(void)
{
- return decode_pll(PLL_ENET, MXC_HCLK);
+ return get_ipg_clk();
}
int enable_sata_clock(void)
diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index 3b2b995..02fd1a6 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -124,13 +124,23 @@ static int fec_mdio_read(struct ethernet_regs *eth,
uint8_t phyAddr,
static void fec_mii_setspeed(struct ethernet_regs *eth)
{
+ u32 sysclock;
+ u32 mii_speed;
+
/*
* Set MII_SPEED = (1/(mii_speed * 2)) * System Clock
* and do not drop the Preamble.
+* shift the result by 1, because MII_SPEED field is at bits 6..1.
*/
- writelimx_get_fecclk() / 100) + 2) / 5) 1,
- eth-mii_speed);
- debug(%s: mii_speed %08x\n, __func__, readl(eth-mii_speed));
+ sysclock = imx_get_fecclk();
+#define MIIM_SPEED 250
+ mii_speed = DIV_ROUND_UP(sysclock, (MIIM_SPEED * 2));
+#ifdef FEC_QUIRK_ENET_MAC
+ mii_speed -= 1;
+#endif
+ writel(mii_speed 1, eth-mii_speed);
+ debug(%s: sysclock %u, mii_speed %08x\n, __func__, sysclock,
+ readl(eth-mii_speed));
}
static int fec_mdio_write(struct ethernet_regs *eth, uint8_t phyAddr,
--
1.7.5.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] cfi: Problem with Intel Strata 28F320 flash
Hello Heiko, On Tue, Mar 08, 2011 at 02:08:26PM +0100, Heiko Schocher wrote: Hello, as I am actual trying to get the keymile boards in sync with actual mainline u-boot, I faced the following Problem with an Intel Strata Flash on the mgcoge (mpc8247 based board): I couldn;t unprotect/erase/write/protect some (not all!) Flash sectors. For Example, I could do this without errors on the sectors where u-boot sits (First three sectors), but not with the environment (next two sectors)! That's exactly the problem I had, but triggered by another valid command sequence. So it is also a flash bug. Have you searched with google for your chip plus errata or specification update as they call that ? After some debugging, I found out, that, if I revert commit commit 54652991caedc39b2ec2e5b49e750669bfcd1e2e Author: Philippe De Muyter p...@macqel.be Date: Tue Aug 17 18:40:25 2010 +0200 Work around bug in Numonyx P33/P30 256-Mbit 65nm flash chips. I have ported U-boot to a in house made board with Numonyx Axcell P33/P30 256-Mbit 65nm flash chips. After some time :( searching for bugs in our board or soft, we have discovered that those chips have a small but annoying bug, documented in Numonyx Axcell P33/P30 256-Mbit Specification Update [...] It works again fine, and without problems ... did somebody faced similiar issues with the cfi driver? Some Ideas? It seems like we'll need to check the flash chip type before issuing one command sequence or another. Philippe -- Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCHv4 CFI flash] Work around bug in Numonyx P33/P30 256-Mbit 65nm flash chips.
I have ported U-boot to a in house made board with Numonyx Axcell P33/P30
256-Mbit 65nm flash chips.
After some time :( searching for bugs in our board or soft, we have
discovered that those chips have a small but annoying bug, documented in
Numonyx Axcell P33/P30 256-Mbit Specification Update
It states :
When customer uses [...] block unlock, the block lock status might be
altered inadvertently. Lock status might be set to either 01h or 03h
unexpectedly (00h as expected data), which leads to program/erase failure
on certain blocks.
A working workaround is given, which I have applied and tested with success :
Workaround: If the interval between 60h and its subsequent command
can be guaranteed within 20μs, Option I is recommended,
otherwise Option II (involves hardware) should be selected.
Option I: The table below lists the detail command sequences:
Command
Data bus Address bus Remarks
Sequence
1 90hBlock Address
Read Lock Status
2 Read Block Address + 02h
(2)(3) (1)
360h Block Address
(2)(3) (1) Lock/Unlock/RCR Configuration
4 D0h/01h/03hBlock Address
Notes:
(1) Block Address refers to RCR configuration data only when the 60h
command sequence is used to set RCR register combined with 03h
subsequent command.
(2) For the third and fourth command sequences, the Block Address must
be the same.
(3) The interval between 60h command and its subsequent D0h/01h/2Fh/03h
commands should be less than 20μs.
And here is a log comparison of a simple (destructive) flash test without
and with the workaround.
diff -U 50 without-numonyx-workaround.log with-numonyx-workaround.log
-U-Boot 2010.06-00696-g22b002c-dirty (Aug 16 2010 - 15:07:47)
+U-Boot 2010.06-00696-g22b002c-dirty (Aug 16 2010 - 15:25:19)
CPU: Freescale MCF5484
CPU CLK 200 MHz BUS CLK 100 MHz
Board: Macq Electronique ME2060
I2C: ready
DRAM: 64 MiB
FLASH: 32 MiB
In:serial
Out: serial
Err: serial
Net: FEC0, FEC1
- flinfo
Bank # 1: CFI conformant FLASH (16 x 16) Size: 32 MB in 259 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x8922
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 5 ms, buffer size: 1024 bytes
Sector Start Addresses:
FE00 RO FE008000 RO FE01 RO FE018000 RO FE02 RO
FE04 RO FE06 RO FE08 RO FE0A RO FE0C RO
...
FFF8 RO FFFA RO FFFC RO FFFE RO
- protect off all
Un-Protect Flash Bank # 1
...
done
- erase all
Erase Flash Bank # 1
...
done
- cp.b 100 fe00 200
-Copy to Flash... Flash not Erased
+Copy to Flash... done
-
Signed-off-by: Philippe De Muyter p...@macqel.be
---
diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index 2d09caf..809ff0e 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -1348,15 +1350,32 @@ int flash_real_protect (flash_info_t * info, long
sector, int prot)
case CFI_CMDSET_INTEL_PROG_REGIONS:
case CFI_CMDSET_INTEL_STANDARD:
case CFI_CMDSET_INTEL_EXTENDED:
- flash_write_cmd (info, sector, 0,
-FLASH_CMD_CLEAR_STATUS);
- flash_write_cmd (info, sector, 0, FLASH_CMD_PROTECT);
- if (prot)
- flash_write_cmd (info, sector, 0,
- FLASH_CMD_PROTECT_SET);
- else
+ /*
+* see errata called
+* Numonyx Axcell P33/P30 Specification Update :)
+*/
+ flash_write_cmd (info, sector, 0, FLASH_CMD_READ_ID);
+ if (!flash_isequal (info, sector, FLASH_OFFSET_PROTECT,
+ prot)) {
+ /*
+* cmd must come before FLASH_CMD_PROTECT + 20us
+* Disable interrupts which might cause a
timeout here.
+*/
+ int flag = disable_interrupts
Re: [U-Boot] [PATCHv4 CFI flash] Work around bug in Numonyx P33/P30 256-Mbit?65nm flash chips.
On Tue, Aug 17, 2010 at 05:57:00PM +0200, Stefan Roese wrote: Hi Philippe, unfortunately your patch base64 encoded. :-( Are you sure ? It isn't so in my `sent' folder. Even though git seems to be able to handle this, your commit text still has some problems. Please see below: On Tuesday 17 August 2010 11:49:24 Philippe De Muyter wrote: I have ported U-boot to a in house made board with Numonyx Axcell P33/P30 256-Mbit 65nm flash chips. After some time :( searching for bugs in our board or soft, we have discovered that those chips have a small but annoying bug, documented in Numonyx Axcell P33/P30 256-Mbit Specification Update It states : When customer uses [...] block unlock, the block lock status might be altered inadvertently. Lock status might be set to either 01h or 03h unexpectedly (00h as expected data), which leads to program/erase failure on certain blocks. A working workaround is given, which I have applied and tested with success : Workaround: If the interval between 60h and its subsequent command can be guaranteed within 20μs, Option I is recommended, otherwise Option II (involves hardware) should be selected. Option I: The table below lists the detail command sequences: Command Data bus Address bus Remarks Sequence 1 90hBlock Address Read Lock Status 2 Read Block Address + 02h (2)(3) (1) 360h Block Address (2)(3) (1) Lock/Unlock/RCR Configuration 4 D0h/01h/03hBlock Address Notes: (1) Block Address refers to RCR configuration data only when the 60h command sequence is used to set RCR register combined with 03h subsequent command. (2) For the third and fourth command sequences, the Block Address must be the same. (3) The interval between 60h command and its subsequent D0h/01h/2Fh/03h commands should be less than 20μs. And here is a log comparison of a simple (destructive) flash test without and with the workaround. diff -U 50 without-numonyx-workaround.log with-numonyx-workaround.log -U-Boot 2010.06-00696-g22b002c-dirty (Aug 16 2010 - 15:07:47) +U-Boot 2010.06-00696-g22b002c-dirty (Aug 16 2010 - 15:25:19) You still have this diff stuff in the commit text. This results in the remaining stuff being dropped by git after applying. Please remove those diff lines. Sorry about that; I had tested with `patch', but of course it does not need the commit text part :( And please don't send base64 encoded mails. I strongly suggest using git send-email. My experience with `git send-email' is not that good (none of the mails I sent this way were answered), but I'll try again. Thanks Philippe -- Philippe De Muyter phdm at macqel dot be Tel +32 27029044 Macq Electronique SA rue de l'Aeronef 2 B-1140 Bruxelles Fax +32 27029077 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCHv5 CFI flash] Work around bug in Numonyx P33/P30 256-Mbit 65nm flash chips.
I have ported U-boot to a in house made board with Numonyx Axcell P33/P30
256-Mbit 65nm flash chips.
After some time :( searching for bugs in our board or soft, we have
discovered that those chips have a small but annoying bug, documented in
Numonyx Axcell P33/P30 256-Mbit Specification Update
It states :
When customer uses [...] block unlock, the block lock status might be
altered inadvertently. Lock status might be set to either 01h or 03h
unexpectedly (00h as expected data), which leads to program/erase failure
on certain blocks.
A working workaround is given, which I have applied and tested with success :
Workaround: If the interval between 60h and its subsequent command
can be guaranteed within 20us, Option I is recommended,
otherwise Option II (involves hardware) should be selected.
Option I: The table below lists the detail command sequences:
Command
Data bus Address bus Remarks
Sequence
1 90hBlock Address
Read Lock Status
2 Read Block Address + 02h
(2)(3) (1)
360h Block Address
(2)(3) (1) Lock/Unlock/RCR Configuration
4 D0h/01h/03hBlock Address
Notes:
(1) Block Address refers to RCR configuration data only when the 60h
command sequence is used to set RCR register combined with 03h
subsequent command.
(2) For the third and fourth command sequences, the Block Address must
be the same.
(3) The interval between 60h command and its subsequent D0h/01h/2Fh/03h
commands should be less than 20us.
And here is a log comparison of a simple (destructive) flash test without
and with the workaround.
diff without-numonyx-workaround.log with-numonyx-workaround.log
-U-Boot 2010.06-00696-g22b002c-dirty (Aug 16 2010 - 15:07:47)
+U-Boot 2010.06-00696-g22b002c-dirty (Aug 16 2010 - 15:25:19)
CPU: Freescale MCF5484
CPU CLK 200 MHz BUS CLK 100 MHz
Board: Macq Electronique ME2060
I2C: ready
DRAM: 64 MiB
FLASH: 32 MiB
In:serial
Out: serial
Err: serial
Net: FEC0, FEC1
- flinfo
Bank # 1: CFI conformant FLASH (16 x 16) Size: 32 MB in 259 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x8922
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 5 ms, buffer size: 1024 bytes
Sector Start Addresses:
FE00 RO FE008000 RO FE01 RO FE018000 RO FE02 RO
FE04 RO FE06 RO FE08 RO FE0A RO FE0C RO
...
FFF8 RO FFFA RO FFFC RO FFFE RO
- protect off all
Un-Protect Flash Bank # 1
... done
- erase all
Erase Flash Bank # 1
... done
- cp.b 100 fe00 200
-Copy to Flash... Flash not Erased
+Copy to Flash... done
-
Signed-off-by: Philippe De Muyter p...@macqel.be
---
diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index 2d09caf..809ff0e 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -1348,15 +1350,32 @@ int flash_real_protect (flash_info_t * info, long
sector, int prot)
case CFI_CMDSET_INTEL_PROG_REGIONS:
case CFI_CMDSET_INTEL_STANDARD:
case CFI_CMDSET_INTEL_EXTENDED:
- flash_write_cmd (info, sector, 0,
-FLASH_CMD_CLEAR_STATUS);
- flash_write_cmd (info, sector, 0, FLASH_CMD_PROTECT);
- if (prot)
- flash_write_cmd (info, sector, 0,
- FLASH_CMD_PROTECT_SET);
- else
+ /*
+* see errata called
+* Numonyx Axcell P33/P30 Specification Update :)
+*/
+ flash_write_cmd (info, sector, 0, FLASH_CMD_READ_ID);
+ if (!flash_isequal (info, sector, FLASH_OFFSET_PROTECT,
+ prot)) {
+ /*
+* cmd must come before FLASH_CMD_PROTECT + 20us
+* Disable interrupts which might cause a
timeout here.
+*/
+ int flag = disable_interrupts ();
+ unsigned short cmd;
+
+ if (prot)
+ cmd = FLASH_CMD_PROTECT_SET;
+ else
+ cmd = FLASH_CMD_PROTECT_CLEAR;
+
flash_write_cmd (info, sector, 0,
- FLASH_CMD_PROTECT_CLEAR);
+ FLASH_CMD_PROTECT
Re: [U-Boot] [PATCHv4 CFI flash] Work around bug in Numonyx P33/P30 256-Mbit?65nm flash chips.
On Tue, Aug 17, 2010 at 06:18:07PM +0200, Philippe De Muyter wrote: On Tue, Aug 17, 2010 at 05:57:00PM +0200, Stefan Roese wrote: Hi Philippe, unfortunately your patch base64 encoded. :-( Are you sure ? It isn't so in my `sent' folder. Thinking again about it, it must happen somewhere between my computer and yours, because of the `micro' character (here replaced by 'u') in the `20us' clause in the commit text. Philippe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCHv3 CFI flash] Work around bug in Numonyx P33/P30 256-Mbit 65nm flash chips.
I have ported U-boot to a in house made board with Numonyx Axcell P33/P30
256-Mbit 65nm flash chips.
After some time :( searching for bugs in our board or soft, we have
discovered that those chips have a small but annoying bug, documented in
Numonyx Axcell P33/P30 256-Mbit Specification Update
It states :
When customer uses [...] block unlock, the block lock status might be
altered inadvertently. Lock status might be set to either 01h or 03h
unexpectedly (00h as expected data), which leads to program/erase failure
on certain blocks.
A working workaround is given, which I have applied and tested with success :
Workaround: If the interval between 60h and its subsequent command
can be guaranteed within 20μs, Option I is recommended,
otherwise Option II (involves hardware) should be selected.
Option I: The table below lists the detail command sequences:
Command
Data bus Address bus Remarks
Sequence
1 90hBlock Address
Read Lock Status
2 Read Block Address + 02h
(2)(3) (1)
360h Block Address
(2)(3) (1) Lock/Unlock/RCR Configuration
4 D0h/01h/03hBlock Address
Notes:
(1) Block Address refers to RCR configuration data only when the 60h
command sequence is used to set RCR register combined with 03h
subsequent command.
(2) For the third and fourth command sequences, the Block Address must
be the same.
(3) The interval between 60h command and its subsequent D0h/01h/2Fh/03h
commands should be less than 20μs.
And here is a log comparison of a simple (destructive) flash test without
and with the workaround.
diff -U 50 without-numonyx-workaround.log with-numonyx-workaround.log
--- without-numonyx-workaround.log 2010-08-16 15:32:34.0 +0200
+++ with-numonyx-workaround.log 2010-08-16 15:32:55.0 +0200
@@ -1,33 +1,33 @@
-U-Boot 2010.06-00696-g22b002c-dirty (Aug 16 2010 - 15:07:47)
+U-Boot 2010.06-00696-g22b002c-dirty (Aug 16 2010 - 15:25:19)
CPU: Freescale MCF5484
CPU CLK 200 MHz BUS CLK 100 MHz
Board: Macq Electronique ME2060
I2C: ready
DRAM: 64 MiB
FLASH: 32 MiB
In:serial
Out: serial
Err: serial
Net: FEC0, FEC1
- flinfo
Bank # 1: CFI conformant FLASH (16 x 16) Size: 32 MB in 259 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x8922
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 5 ms, buffer size: 1024 bytes
Sector Start Addresses:
FE00 RO FE008000 RO FE01 RO FE018000 RO FE02 RO
FE04 RO FE06 RO FE08 RO FE0A RO FE0C RO
...
FFF8 RO FFFA RO FFFC RO FFFE RO
- protect off all
Un-Protect Flash Bank # 1
...
done
- erase all
Erase Flash Bank # 1
...
done
- cp.b 100 fe00 200
-Copy to Flash... Flash not Erased
+Copy to Flash... done
-
Signed-off-by: Philippe De Muyter p...@macqel.be
---
diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index 2d09caf..809ff0e 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -1348,15 +1350,32 @@ int flash_real_protect (flash_info_t * info, long
sector, int prot)
case CFI_CMDSET_INTEL_PROG_REGIONS:
case CFI_CMDSET_INTEL_STANDARD:
case CFI_CMDSET_INTEL_EXTENDED:
- flash_write_cmd (info, sector, 0,
-FLASH_CMD_CLEAR_STATUS);
- flash_write_cmd (info, sector, 0, FLASH_CMD_PROTECT);
- if (prot)
- flash_write_cmd (info, sector, 0,
- FLASH_CMD_PROTECT_SET);
- else
+ /*
+* see errata called
+* Numonyx Axcell P33/P30 Specification Update :)
+*/
+ flash_write_cmd (info, sector, 0, FLASH_CMD_READ_ID);
+ if (!flash_isequal (info, sector, FLASH_OFFSET_PROTECT,
+ prot)) {
+ /*
+* cmd must come before FLASH_CMD_PROTECT + 20us
Re: [U-Boot] [PATCHv2 CFI flash]: Workaround for Numonyx Axcell P33/P30 256-Mbit 65nm bug
Hi Stefan,
On Tue, Aug 10, 2010 at 01:20:42PM +0200, Stefan Roese wrote:
Hi Philippe,
On Monday 09 August 2010 17:46:03 Philippe De Muyter wrote:
Please move this variable declaration of cmd and assignment further
down (see below). You can remove the { } of this block then.
Here is the excerpt from the errata :
Workaround: If the interval between 60h and its subsequent command
can be guaranteed within 20μs, Option I is recommended,
otherwise Option II (involves hardware) should be selected.
Option I: The table below lists the detail command sequences:
Command
Data bus Address bus Remarks
Sequence
1 90hBlock Address
Read Lock Status
2 Read Block Address + 02h
(2)(3) (1)
360h Block Address
(2)(3) (1) Lock/Unlock/RCR
Configuration 4 D0h/01h/03hBlock Address
Notes:
(1) Block Address refers to RCR configuration data only when the 60h
command sequence is used to set RCR register combined with 03h
subsequent command.
(2) For the third and fourth command sequences, the Block Address must
be the same.
(3) The interval between 60h command and its subsequent D0h/01h/2Fh/03h
commands should be less than 20μs.
Because of requirement (3), I choosed to minimize the number of
instructions between the `read lock status' and the `unlock' commands,
hence the initialisation of `cmd' moved before the `read lock status'
(hidden in `flash_isequal').
Yes, you're right. I had misread the doc :(
From my understanding, only the last 2 operations need to be in max.
20µs interval. If this is the case, then I would prefer this code
version:
I prefer it too.
case CFI_CMDSET_INTEL_EXTENDED:
/*
* see errata called
* Numonyx Axcell P33/P30 Specification Update :)
*/
flash_write_cmd (info, sector, 0, FLASH_CMD_READ_ID);
if (!flash_isequal (info, sector, FLASH_OFFSET_PROTECT,
prot)) {
int flag = disable_interrupts ();
unsigned short cmd;
if (prot)
cmd = FLASH_CMD_PROTECT_SET;
else
cmd = FLASH_CMD_PROTECT_CLEAR;
/*
* cmd must come before FLASH_CMD_PROTECT + 20us
* Disable interrupts which might cause a
timeout here.
*/
Should the above comment not stay closer to the disable_interrupts () call ?
flash_write_cmd (info, sector, 0,
FLASH_CMD_PROTECT);
flash_write_cmd (info, sector, 0, cmd);
/* re-enable interrupts if necessary */
if (flag)
enable_interrupts ();
}
+ /*
+* see errata called
+* Numonyx Axcell P33/P30 Specification
Update :) +*/
+ flash_write_cmd (info, sector, 0,
FLASH_CMD_READ_ID); + if (!flash_isequal (info,
sector, FLASH_OFFSET_PROTECT, +
prot)) {
+ int flag = disable_interrupts ();
Declare and assign cmd here please.
Please change and resubmit. Thanks.
If you still prefer it changed, speak :)
Yes, please let me know if this patch version also fixes the bug. If
this is the case, I would prefer that you change it accordingly.
I surmise it does, but I currently do not have a board to test. I'll
get new boards (with the same bug) soon, and I'll let you know then.
Best regards
Philippe
--
Philippe De Muyter phdm at macqel dot be Tel +32 27029044
Macq Electronique SA rue de l'Aeronef 2 B-1140 Bruxelles Fax +32 27029077
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH CFI]: Fix printing reading of 16-bit CFI device identifiers
Fix reading and printing of CFI flashes 16-bit devices identifiers
Nowadays CFI flashes have a 16-bit device identifier. U-boot still
print them and read them as if they were only 8-bit wide. Fix that.
Before:
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x1B
After:
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x881B
Signed-off-by: Philippe De Muyter p...@macqel.be
---
drivers/mtd/cfi_flash.c | 11 +++
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index 013d4ad..8fb6c2e 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -1142,8 +1142,10 @@ void flash_print_info (flash_info_t * info)
printf (Unknown (%d), info-vendor);
break;
}
- printf ( command set, Manufacturer ID: 0x%02X, Device ID: 0x%02X,
- info-manufacturer_id, info-device_id);
+ printf ( command set, Manufacturer ID: 0x%02X, Device ID: 0x,
+ info-manufacturer_id);
+ printf (info-chipwidth == FLASH_CFI_16BIT ? %04X : %02X,
+ info-device_id);
if (info-device_id == 0x7E) {
printf(%04X, info-device_id2);
}
@@ -1494,8 +1496,9 @@ static void cmdset_intel_read_jedec_ids(flash_info_t
*info)
udelay(1000); /* some flash are slow to respond */
info-manufacturer_id = flash_read_uchar (info,
FLASH_OFFSET_MANUFACTURER_ID);
- info-device_id = flash_read_uchar (info,
- FLASH_OFFSET_DEVICE_ID);
+ info-device_id = (info-chipwidth == FLASH_CFI_16BIT) ?
+ flash_read_word (info, FLASH_OFFSET_DEVICE_ID) :
+ flash_read_uchar (info, FLASH_OFFSET_DEVICE_ID);
flash_write_cmd(info, 0, 0, FLASH_CMD_RESET);
}
--
1.6.3.3
--
Philippe De Muyter phdm at macqel dot be Tel +32 27029044
Macq Electronique SA rue de l'Aeronef 2 B-1140 Bruxelles Fax +32 27029077
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv2 CFI flash]: Workaround for Numonyx Axcell?P33/P30 256-Mbit 65nm bug
On Tue, Aug 10, 2010 at 05:28:59PM +0200, Stefan Roese wrote: Hi Philippe, one more thing: On Monday 09 August 2010 17:46:03 Philippe De Muyter wrote: Here is the excerpt from the errata : Workaround: If the interval between 60h and its subsequent command can be guaranteed within 20μs, Option I is recommended, otherwise Option II (involves hardware) should be selected. Option I: The table below lists the detail command sequences: Command Data bus Address bus Remarks Sequence 1 90hBlock Address Read Lock Status 2 Read Block Address + 02h (2)(3) (1) 360h Block Address (2)(3) (1) Lock/Unlock/RCR Configuration 4 D0h/01h/03hBlock Address Notes: (1) Block Address refers to RCR configuration data only when the 60h command sequence is used to set RCR register combined with 03h subsequent command. (2) For the third and fourth command sequences, the Block Address must be the same. (3) The interval between 60h command and its subsequent D0h/01h/2Fh/03h commands should be less than 20μs. Please add this workaround text from the errata to the commit text in your next patch version. This makes things easier - no need to search for the errata. OK Philippe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv2 CFI flash]: Workaround for Numonyx Axcell P33/P30 256-Mbit 65nm bug
Hello Joakim, On Mon, Aug 09, 2010 at 10:32:25AM +0200, Joakim Tjernlund wrote: Dear Stefan, In message 20100623131040.ga23...@frolo.macqel Philippe De Muyter wrote: Hello Wolfgang list, This is a revised patch, with comments and indentation fixed, I hope. I have ported U-boot to a in house made board with Numonyx Axcell P33/P30 256-Mbit 65nm flash chips. After some time :( searching for bugs in our board or soft, we have discovered that those chips have a small but annoying bug, documented in Numonyx Axcell P33/P30 256-Mbit Specification Update It states : When customer uses [...] block unlock, the block lock status might be altered inadvertently. Lock status might be set to either 01h or 03h unexpectedly (00h as expected data), which leads to program/erase failure on certain blocks. A working workaround is given, which I have applied and tested with success. Signed-off-by: Philippe De Muyter p...@macqel.be --- drivers/mtd/cfi_flash.c | 27 --- 1 files changed, 20 insertions(+), 7 deletions(-) I didn't see comments from you? Best regards, Wolfgang Denk Doesn't the Linux kernel need the same fix? Would be great if you(Philippe) could provide one. I too have such chips but I have never seen this problem so I guess I have been lucky so far :) Jocke I use linux on those boards, of course, so I also thought that I'd need to fix linux, but I didn't have to. On the boards I had, the bug was easily repeatable with u-boot or the bdm-tools's bdm-based flash programmer I used. The same blocks always gave the same error, while other blocks always worked perfectly. From linux, I tested with eraseall from mtd-utils also on the bad blocks and I never had any problem, so linux probably already does the erase sequence the way numonyx testers do it. The key point is that the CFI unlock command sequence must come just before the CFI erase command sequence, not long before. Philippe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv2 CFI flash]: Workaround for Numonyx Axcell P33/P30 256-Mbit 65nm bug
Hi Stefan,
On Mon, Aug 09, 2010 at 03:52:03PM +0200, Stefan Roese wrote:
Hi Philippe,
first sorry for the late review (thanks Wolfgang for reminding).
On Saturday 07 August 2010 01:11:02 Wolfgang Denk wrote:
Dear Stefan,
In message 20100623131040.ga23...@frolo.macqel Philippe De Muyter wrote:
Hello Wolfgang list,
This is a revised patch, with comments and indentation fixed, I hope.
Minor note: Such commentary lines should be moved below the --- line
below. They shouldn't appear in the git history.
snip
diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index 3267c5d..4bf0807 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -1347,17 +1347,34 @@ int flash_real_protect (flash_info_t * info, long
sector, int prot)
switch (info-vendor) {
case CFI_CMDSET_INTEL_PROG_REGIONS:
case CFI_CMDSET_INTEL_STANDARD:
- case CFI_CMDSET_INTEL_EXTENDED:
- flash_write_cmd (info, sector, 0,
-FLASH_CMD_CLEAR_STATUS);
- flash_write_cmd (info, sector, 0,
FLASH_CMD_PROTECT);
+ case CFI_CMDSET_INTEL_EXTENDED: {
+ unsigned short cmd;
+
if (prot)
- flash_write_cmd (info, sector, 0,
- FLASH_CMD_PROTECT_SET);
+ cmd = FLASH_CMD_PROTECT_SET;
else
+ cmd = FLASH_CMD_PROTECT_CLEAR;
Please move this variable declaration of cmd and assignment further down
(see below). You can remove the { } of this block then.
Here is the excerpt from the errata :
Workaround: If the interval between 60h and its subsequent command
can be guaranteed within 20μs, Option I is recommended,
otherwise Option II (involves hardware) should be selected.
Option I: The table below lists the detail command sequences:
Command
Data bus Address bus Remarks
Sequence
1 90hBlock Address
Read Lock Status
2 Read Block Address + 02h
(2)(3) (1)
360h Block Address
(2)(3) (1) Lock/Unlock/RCR Configuration
4 D0h/01h/03hBlock Address
Notes:
(1) Block Address refers to RCR configuration data only when the 60h
command sequence is used to set RCR register combined with 03h
subsequent command.
(2) For the third and fourth command sequences, the Block Address must
be the same.
(3) The interval between 60h command and its subsequent D0h/01h/2Fh/03h
commands should be less than 20μs.
Because of requirement (3), I choosed to minimize the number of instructions
between the `read lock status' and the `unlock' commands, hence the
initialisation of `cmd' moved before the `read lock status' (hidden
in `flash_isequal').
+ /*
+* see errata called
+* Numonyx Axcell P33/P30 Specification Update :)
+*/
+ flash_write_cmd (info, sector, 0,
FLASH_CMD_READ_ID);
+ if (!flash_isequal (info, sector,
FLASH_OFFSET_PROTECT,
+ prot)) {
+ int flag = disable_interrupts ();
Declare and assign cmd here please.
Please change and resubmit. Thanks.
If you still prefer it changed, speak :)
Best regards
Philippe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv2 CFI flash]: Workaround for Numonyx Axcell P33/P30 256-Mbit 65nm bug
On Mon, Aug 09, 2010 at 02:57:27PM +0200, Philippe De Muyter wrote: Hello Joakim, On Mon, Aug 09, 2010 at 10:32:25AM +0200, Joakim Tjernlund wrote: Dear Stefan, In message 20100623131040.ga23...@frolo.macqel Philippe De Muyter wrote: Hello Wolfgang list, This is a revised patch, with comments and indentation fixed, I hope. I have ported U-boot to a in house made board with Numonyx Axcell P33/P30 256-Mbit 65nm flash chips. After some time :( searching for bugs in our board or soft, we have discovered that those chips have a small but annoying bug, documented in Numonyx Axcell P33/P30 256-Mbit Specification Update It states : When customer uses [...] block unlock, the block lock status might be altered inadvertently. Lock status might be set to either 01h or 03h unexpectedly (00h as expected data), which leads to program/erase failure on certain blocks. A working workaround is given, which I have applied and tested with success. Signed-off-by: Philippe De Muyter p...@macqel.be --- drivers/mtd/cfi_flash.c | 27 --- 1 files changed, 20 insertions(+), 7 deletions(-) I didn't see comments from you? Best regards, Wolfgang Denk Doesn't the Linux kernel need the same fix? Would be great if you(Philippe) could provide one. I too have such chips but I have never seen this problem so I guess I have been lucky so far :) Jocke I use linux on those boards, of course, so I also thought that I'd need to fix linux, but I didn't have to. On the boards I had, the bug was easily repeatable with u-boot or the bdm-tools's bdm-based flash programmer I used. The same blocks always gave the same error, while other blocks always worked perfectly. From linux, I tested with eraseall from mtd-utils also on the bad blocks and I never had any problem, so linux probably already does the erase sequence the way numonyx testers do it. The key point is that the CFI unlock command sequence must come just before the CFI erase command sequence, not long before. Sorry, bad memory :( The unlock command must be preceded by a read lock command, with no more than 20 us between. Philippe -- Philippe De Muyter phdm at macqel dot be Tel +32 27029044 Macq Electronique SA rue de l'Aeronef 2 B-1140 Bruxelles Fax +32 27029077 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH CFI flash]: Workaround for Numonyx Axcell P33/P30 256-Mbit 65nm bug
Hello Wolfgang list,
I have ported U-boot to a in house made board with Numonyx Axcell P33/P30
256-Mbit 65nm flash chips.
After some time :( searching for bugs in our board or soft, we have
discovered that those chips have a small but annoying bug, documented in
Numonyx Axcell P33/P30 256-Mbit Specification Update
It states :
When customer uses [...] block unlock, the block lock status might be
altered inadvertently. Lock status might be set to either 01h or 03h
unexpectedly (00h as expected data), which leads to program/erase failure
on certain blocks.
A working workaround is given, which I have applied and tested with success.
Signed-off-by: Philippe De Muyter p...@macqel.be
---
drivers/mtd/cfi_flash.c | 27 ---
1 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index 3267c5d..0931137 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -1347,16 +1347,29 @@ int flash_real_protect (flash_info_t * info, long
sector, int prot)
switch (info-vendor) {
case CFI_CMDSET_INTEL_PROG_REGIONS:
case CFI_CMDSET_INTEL_STANDARD:
- case CFI_CMDSET_INTEL_EXTENDED:
- flash_write_cmd (info, sector, 0,
-FLASH_CMD_CLEAR_STATUS);
- flash_write_cmd (info, sector, 0, FLASH_CMD_PROTECT);
+ case CFI_CMDSET_INTEL_EXTENDED: {
+ unsigned short cmd;
+
if (prot)
- flash_write_cmd (info, sector, 0,
- FLASH_CMD_PROTECT_SET);
+ cmd = FLASH_CMD_PROTECT_SET;
else
+ cmd = FLASH_CMD_PROTECT_CLEAR;
+ /* see errata
+ Numonyx Axcell P33/P30 Specification Update :) */
+ flash_write_cmd (info, sector, 0, FLASH_CMD_READ_ID);
+ if (!flash_isequal (info, sector, FLASH_OFFSET_PROTECT,
+ prot)) {
+ /* cmd must come before 20us after
FLASH_CMD_PROTECT */
+ /* Disable interrupts which might cause a
timeout here */
+ int flag = disable_interrupts ();
flash_write_cmd (info, sector, 0,
- FLASH_CMD_PROTECT_CLEAR);
+ FLASH_CMD_PROTECT);
+ flash_write_cmd (info, sector, 0, cmd);
+ /* re-enable interrupts if necessary */
+ if (flag)
+ enable_interrupts ();
+ }
+ }
break;
case CFI_CMDSET_AMD_EXTENDED:
case CFI_CMDSET_AMD_STANDARD:
--
1.6.3.3
--
Philippe De Muyter phdm at macqel dot be Tel +32 27029044
Macq Electronique SA rue de l'Aeronef 2 B-1140 Bruxelles Fax +32 27029077
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] m68k: Add ME2060_config (Macq Electronique MCF5484-based board)
---
Makefile | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 9a436fe..aa8738e 100644
--- a/Makefile
+++ b/Makefile
@@ -2188,6 +2188,7 @@ M5475GFE_config : unconfig
fi
@$(MKCONFIG) -a M5475EVB m68k mcf547x_8x m547xevb freescale
+ME2060_config \
M5485AFE_config \
M5485BFE_config \
M5485CFE_config \
@@ -2197,6 +2198,7 @@ M5485FFE_config \
M5485GFE_config \
M5485HFE_config : unconfig
@case $@ in \
+ ME2060_config) BOOT=32;CODE=0;VID=0;USB=0;RAM=64;RAM1=0;; \
M5485AFE_config)BOOT=2;CODE=0;VID=0;USB=0;RAM=64;RAM1=0;; \
M5485BFE_config)BOOT=2;CODE=16;VID=0;USB=0;RAM=64;RAM1=0;; \
M5485CFE_config)BOOT=2;CODE=16;VID=1;USB=1;RAM=64;RAM1=0;; \
@@ -2220,6 +,19 @@ M5485HFE_config :unconfig
fi; \
if [ $${USB} == 1 ] ; then \
echo #define CONFIG_SYS_USBCTRL $(obj)include/config.h ; \
+ fi; \
+ if [ $@ == ME2060_config ] ; then \
+ echo '#define CONFIG_HOSTNAME ME2060'
$(obj)include/config.h ; \
+ echo '#define CONFIG_BOARD_NAME_STRING Macq Electronique
ME2060\n' $(obj)include/config.h ; \
+ echo #define CONFIG_NO_CMD_PCI $(obj)include/config.h ; \
+ echo #define CONFIG_CMD_DHCP $(obj)include/config.h ; \
+ echo #define CONFIG_SYS_ALT_MEMTEST $(obj)include/config.h
; \
+ echo #define CONFIG_SYS_CS0_BASE 0xFE00
$(obj)include/config.h ; \
+ echo #define CONFIG_SYS_MAX_FLASH_SECT 259
$(obj)include/config.h ; \
+ echo #define CONFIG_ENV_OFFSET 0x8000
$(obj)include/config.h ; \
+ echo #define CONFIG_ENV_SECT_SIZE 0x8000
$(obj)include/config.h ; \
+ echo #define CONFIG_ENV_OFFSET_REDUND 0x1
$(obj)include/config.h ; \
+ echo TEXT_BASE = 0xFE00
$(obj)board/freescale/m548xevb/config.tmp ; \
fi
@$(MKCONFIG) -a M5485EVB m68k mcf547x_8x m548xevb freescale
--
1.6.3.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] m68k/mcf547x_8x : Fix relocation errors in start.S
If the environment sectors in the flash are big, one get those errors : mcf547x_8x/start.S:173: relocation truncated to fit: R_68K_PC16 against symbol `cpu_init_f' defined in .text section in libmcf547x_8x.a(cpu_init.o) mcf547x_8x/start.S:174: relocation truncated to fit: R_68K_PC16 against symbol `board_init_f' defined in .text section in libm68k.a(board.o) Fix that. --- arch/m68k/cpu/mcf547x_8x/start.S |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/m68k/cpu/mcf547x_8x/start.S b/arch/m68k/cpu/mcf547x_8x/start.S index 8411862..80905ed 100644 --- a/arch/m68k/cpu/mcf547x_8x/start.S +++ b/arch/m68k/cpu/mcf547x_8x/start.S @@ -164,8 +164,8 @@ _start: move.l #__got_start, %a5/* put relocation table address to a5 */ - bsr cpu_init_f /* run low-level CPU init code (from flash) */ - bsr board_init_f/* run low-level board init code (from flash) */ + jbsr cpu_init_f /* run low-level CPU init code (from flash) */ + jbsr board_init_f /* run low-level board init code (from flash) */ /* board_init_f() does not return */ -- 1.6.3.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] m68k: restore bi_enetaddr bi_enet1addr in bd_t for bootm compatibility.
---
arch/m68k/include/asm/u-boot.h |4
arch/m68k/lib/bootm.c |8
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/m68k/include/asm/u-boot.h b/arch/m68k/include/asm/u-boot.h
index a0f2983..91bb240 100644
--- a/arch/m68k/include/asm/u-boot.h
+++ b/arch/m68k/include/asm/u-boot.h
@@ -48,6 +48,7 @@ typedef struct bd_info {
unsigned long bi_bootflags; /* boot / reboot flag (for LynxOS) */
unsigned long bi_boot_params; /* where this board expects params */
unsigned long bi_ip_addr; /* IP Address */
+ unsigned char bi_enetaddr[6]; /* OLD: see README.enetaddr */
unsigned short bi_ethspeed; /* Ethernet speed in Mbps */
unsigned long bi_intfreq; /* Internal Freq, in MHz */
unsigned long bi_busfreq; /* Bus Freq, in MHz */
@@ -60,6 +61,9 @@ typedef struct bd_info {
unsigned long bi_flbfreq; /* Flexbus Freq in MHz */
#endif
unsigned long bi_baudrate; /* Console Baudrate */
+#ifdef CONFIG_HAS_ETH1
+ unsigned char bi_enet1addr[6]; /* OLD: see README.enetaddr */
+#endif
} bd_t;
#endif /* __ASSEMBLY__ */
diff --git a/arch/m68k/lib/bootm.c b/arch/m68k/lib/bootm.c
index e5ed6eb..255a490 100644
--- a/arch/m68k/lib/bootm.c
+++ b/arch/m68k/lib/bootm.c
@@ -32,6 +32,7 @@
#ifdef CONFIG_SHOW_BOOT_PROGRESS
# include status_led.h
#endif
+#include net.h
DECLARE_GLOBAL_DATA_PTR;
@@ -96,6 +97,13 @@ int do_bootm_linux(int flag, int argc, char *argv[],
bootm_headers_t *images)
}
set_clocks_in_mhz(kbd);
+#if defined(CONFIG_CMD_NET)
+ eth_getenv_enetaddr (ethaddr, kbd-bi_enetaddr);
+#if defined(CONFIG_HAS_ETH1)
+ eth_getenv_enetaddr (eth1addr, kbd-bi_enet1addr);
+#endif
+#endif
+
kernel = (void (*)(bd_t *, ulong, ulong, ulong, ulong))images-ep;
rd_len = images-rd_end - images-rd_start;
--
1.6.3.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] m68k: Make m548xevb config reusable for derived boards.
Allow to redefine :
- CONFIG_BOARD_NAME_STRING and CONFIG_HOSTNAME,
- flash-model related constants :
- TEXT_BASE (for loader) and CONFIG_SYS_CS0_BASE,
- CONFIG_SYS_MAX_FLASH_SECT, CONFIG_ENV_OFFSET and CONFIG_ENV_SECT_SIZE,
- and CONFIG_CMD_PCI.
---
board/freescale/m548xevb/config.mk |4
board/freescale/m548xevb/m548xevb.c |5 -
include/configs/M5485EVB.h | 16 +---
3 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/board/freescale/m548xevb/config.mk
b/board/freescale/m548xevb/config.mk
index fa66b75..10d9e3e 100644
--- a/board/freescale/m548xevb/config.mk
+++ b/board/freescale/m548xevb/config.mk
@@ -22,4 +22,8 @@
# MA 02111-1307 USA
#
+sinclude $(OBJTREE)/board/$(BOARDDIR)/config.tmp
+
+ifndef TEXT_BASE
TEXT_BASE = 0xFF80
+endif
diff --git a/board/freescale/m548xevb/m548xevb.c
b/board/freescale/m548xevb/m548xevb.c
index 4a2a5c7..771bb35 100644
--- a/board/freescale/m548xevb/m548xevb.c
+++ b/board/freescale/m548xevb/m548xevb.c
@@ -34,7 +34,10 @@ DECLARE_GLOBAL_DATA_PTR;
int checkboard(void)
{
puts(Board: );
- puts(Freescale FireEngine 5485 EVB\n);
+#ifndef CONFIG_BOARD_NAME_STRING
+#define CONFIG_BOARD_NAME_STRING Freescale FireEngine 5485 EVB\n
+#endif
+ puts(CONFIG_BOARD_NAME_STRING);
return 0;
};
diff --git a/include/configs/M5485EVB.h b/include/configs/M5485EVB.h
index f23b8b0..ceb3919 100644
--- a/include/configs/M5485EVB.h
+++ b/include/configs/M5485EVB.h
@@ -58,10 +58,12 @@
#define CONFIG_CMD_MISC
#define CONFIG_CMD_MII
#define CONFIG_CMD_NET
+#ifndef CONFIG_NO_CMD_PCI
#define CONFIG_CMD_PCI
+#define CONFIG_CMD_USB
+#endif
#define CONFIG_CMD_PING
#define CONFIG_CMD_REGINFO
-#define CONFIG_CMD_USB
#define CONFIG_SLTTMR
@@ -149,7 +151,9 @@
#define CONFIG_BOOTDELAY 1 /* autoboot after 5 seconds */
#define CONFIG_UDP_CHECKSUM
+#ifndef CONFIG_HOSTNAME
#define CONFIG_HOSTNAMEM548xEVB
+#endif
#define CONFIG_EXTRA_ENV_SETTINGS \
netdev=eth0\0 \
loadaddr=1\0 \
@@ -247,7 +251,9 @@
# define CONFIG_SYS_FLASH_BASE(CONFIG_SYS_CS0_BASE)
# define CONFIG_FLASH_CFI_DRIVER 1
# define CONFIG_SYS_FLASH_CFI_WIDTH FLASH_CFI_16BIT
-# define CONFIG_SYS_MAX_FLASH_SECT137 /* max number of
sectors on one chip */
+# ifndef CONFIG_SYS_MAX_FLASH_SECT
+# define CONFIG_SYS_MAX_FLASH_SECT137 /* max number
of sectors on one chip */
+# endif
# define CONFIG_SYS_FLASH_PROTECTION /* Real (hardware) sectors
protection */
# define CONFIG_SYS_FLASH_USE_BUFFER_WRITE
#ifdef CONFIG_SYS_NOR1SZ
@@ -263,8 +269,10 @@
/* Configuration for environment
* Environment is embedded in u-boot in the second sector of the flash
*/
-#define CONFIG_ENV_OFFSET 0x2000
+#ifndef CONFIG_ENV_OFFSET
+#define CONFIG_ENV_OFFSET 0x2000
#define CONFIG_ENV_SECT_SIZE 0x2000
+#endif
#define CONFIG_ENV_IS_IN_FLASH 1
/*---
@@ -299,7 +307,9 @@
* CS4 - Available
* CS5 - Available
*/
+#ifndef CONFIG_SYS_CS0_BASE
#define CONFIG_SYS_CS0_BASE0xFF80
+#endif
#define CONFIG_SYS_CS0_MASK(((CONFIG_SYS_BOOTSZ 20) - 1)
0x0001)
#define CONFIG_SYS_CS0_CTRL0x00101980
--
1.6.3.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] u-boot coldfire linux and fdt
Hello Tsi Chung Liew, I have installed u-boot and linux on a in-house-made coldfire mcf5484 based board. As u-boot currently supports mcf5484-based development boards, I used that as a starting point for the u-boot port for our in-house board. For linux unfortunately I needed to stick with the ltib-based version of linux-2.6.25 for mcf5484-based development boards distributed by freescale. I have discovered the hard way that that version of linux does not use the mac addresses for the ethernet ports as known by u-boot under the names ethaddr and eth1addr, but uses the same wrong mac-address for all the boards. Now it seems that the old way to communicate the mac addresses from u-boot to linux using the struct bd_info has been deprecated and removed from u-boot sources. I see some fdt-related functions in the u-boot sources, but I am not sure that the fdt blob is given to linux, or that linux for coldfire expects to get and use a fdt blob. Can you enlighten me regarding that point, especially for mcf5484 boards ? Thanks in advance Philippe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] what's the uboot way to pass eth*addr to linux ?
Hi Maxim, On Sat, Feb 20, 2010 at 10:30:32AM +0300, Maxim Podbereznyi wrote: Hi Philippe! May be it is a little bit tricky but you can just read the u-boot environment from you Linux driver and use the ethaddr variable. I did the same for osk5912 Thanks, but I need something more straightforward. The ethernet driver in linux must know the mac address at startup to be able to have root on nfs. Previously, the mac addresses were stored in the bd_info struct, but that has been removed, but alas not replaced by a common mechanism for all architectures. Philippe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] what's the uboot way to pass eth*addr to linux ?
Hi Maxim, On Sat, Feb 20, 2010 at 10:30:32AM +0300, Maxim Podbereznyi wrote: Hi Philippe! May be it is a little bit tricky but you can just read the u-boot environment from you Linux driver and use the ethaddr variable. I did the same for osk5912 Sorry, I replied too fast, It seems that I misunderstood your answer. How do you access the U-boot environment from the linux driver ? Is there a linux kernel library function to retrieve one element of a U-boot environment ? Does U-boot tell linux where the U-boot environment resides in memory ? Philippe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] what's the uboot way to pass eth*addr to linux ?
Hello Wolfgang, On Sat, Feb 20, 2010 at 04:08:45PM +0100, Wolfgang Denk wrote: Dear Philippe De Muyter, In message 20100220093717.ga9...@frolo.macqel you wrote: Previously, the mac addresses were stored in the bd_info struct, but that has been removed, but alas not replaced by a common mechanism for all architectures. Complain about this to the Linux architecture maintainers - there have been many and longf discussions about this before. Do you mean lkml or some other mailing list or individual ? Today we consider the device tree to be the Right Thing (TM) to pass such information to the kernel, and more and more architectures use this method. AFAIK, device trees are powerpc-specific and my board is coldfire based. As long as it's not available for your architecture, the most straightforward way is to pass an ethaddr=... argument on the kernel command line. Drivers can pick it up easily there. Just don't expect that such Linux driver code will be accepted for mainline. I don't like that method because it can easily be forgotten by someone changing bootargs for some other reason. IMO bootargs should only be used for configuration choices. I'd rather go for an additional parameter given by u-boot to linux with the address of the used u-boot environment, passed the same way that the address of bd_info is given to linux (for coldfire's, that's on the stack) Philippe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] what's the uboot way to pass eth*addr to linux ?
Hi Maxim,
On Sat, Feb 20, 2010 at 05:49:53PM +0300, Maxim Podbereznyi wrote:
The code for MontaVista with kernel 2.4:
static int nicGetMacAddress(u8* macaddr)
{
[...]
endptr = fw_getenv(sf, ethaddr);
[...]
}
Hope you can easily adapt it to your kernel!
So the library fucntion to retrieve the value of a u-boot environment
variable is 'fw_getenv'. I do not have that function in my linux sources.
Philippe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] what's the uboot way to pass eth*addr to linux ?
Hello I have a problem : my (coldfire) linux kernel does not reuse the mac addresses known by u-boot as ethaddr and eth1addr. I have read doc/README.enetaddr, that states : struct bd_info [...] are temporary copies of the MAC address only for the purpose of passing this information to an OS kernel we are about to boot. but I see no field in bd_info that could be set before booting linux. I thought that the address of the environment zone could be given to linux, but I do not see where either. So what's the recommended/supported way to inform the kernel of the mac addresses of all the ethernet interfaces ? Philippe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH MAKEALL coldfire] : Fix start.S:Error: Conversion of PC relative displacement to absolute
Hi all, This fixes the following errors when running MAKEALL for coldfire : start.S: Assembler messages: start.S:320: Error: Conversion of PC relative displacement to absolute Signed-off-by: Philippe De Muyter p...@macqel.be diff -ru a/cpu/mcf523x/start.S b/cpu/mcf523x/start.S --- a/cpu/mcf523x/start.S 2009-09-17 23:28:31.0 +0200 +++ b/cpu/mcf523x/start.S 2009-09-21 19:58:34.0 +0200 @@ -246,7 +246,7 @@ /* exception code */ .globl _fault _fault: - jmp _fault + bra _fault .globl _exc_handler _exc_handler: diff -ru a/cpu/mcf52x2/start.S b/cpu/mcf52x2/start.S --- a/cpu/mcf52x2/start.S 2009-09-17 23:28:31.0 +0200 +++ b/cpu/mcf52x2/start.S 2009-09-21 19:47:40.0 +0200 @@ -317,7 +317,7 @@ /* exception code */ .globl _fault _fault: - jmp _fault + bra _fault .globl _exc_handler _exc_handler: diff -ru a/cpu/mcf532x/start.S b/cpu/mcf532x/start.S --- a/cpu/mcf532x/start.S 2009-09-17 23:28:31.0 +0200 +++ b/cpu/mcf532x/start.S 2009-09-21 19:50:36.0 +0200 @@ -256,7 +256,7 @@ /* exception code */ .globl _fault _fault: - jmp _fault + bra _fault .globl _exc_handler _exc_handler: ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH MAKEALL coldfire] fix tools/kwbimage.c format warning
Hi all,
This fixes the following warnings when running MAKEALL for coldfire :
tools/kwbimage.c: In function #kwbimage_checksum32#:
tools/kwbimage.c:135: warning: format #%ld# expects type #long int#, but
argument 4 has type #unsigned int#
Signed-off-by: Philippe De Muyter p...@macqel.be
diff -ru a/tools/kwbimage.c b/tools/kwbimage.c
--- a/tools/kwbimage.c 2009-09-17 23:28:31.0 +0200
+++ b/tools/kwbimage.c 2009-09-21 19:40:19.0 +0200
@@ -131,7 +131,7 @@
return 0;
if (len % sizeof(uint32_t)) {
- printf (Error:%s[%d] - lenght is not in multiple of %ld\n,
+ printf (Error:%s[%d] - length is not in multiple of %u\n,
__FUNCTION__, len, sizeof(uint32_t));
return 0;
}
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH MAKEALL coldfire] fix cmd_bdinfo.c:354: warning: 'print_eth' defined but not used
Hi all,
This fixes the following warnings when running MAKEALL for coldfire :
cmd_bdinfo.c:354: warning: 'print_eth' defined but not used
Signed-off-by: Philippe De Muyter p...@macqel.be
diff -ru a/common/cmd_bdinfo.c b/common/cmd_bdinfo.c
--- a/common/cmd_bdinfo.c 2009-09-17 23:28:31.0 +0200
+++ b/common/cmd_bdinfo.c 2009-09-21 20:10:45.0 +0200
@@ -31,7 +31,7 @@
static void print_num(const char *, ulong);
-#if !defined(CONFIG_ARM) || defined(CONFIG_CMD_NET)
+#if !(defined(CONFIG_ARM) || defined(CONFIG_M68K)) || defined(CONFIG_CMD_NET)
static void print_eth(int idx);
#endif
@@ -349,7 +349,7 @@
printf (%-12s= 0x%08lX\n, name, value);
}
-#if !defined(CONFIG_ARM) || defined(CONFIG_CMD_NET)
+#if !(defined(CONFIG_ARM) || defined(CONFIG_M68K)) || defined(CONFIG_CMD_NET)
static void print_eth(int idx)
{
char name[10], *val;
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH MAKEALL coldfire] fix tools/kwbimage.c format warning
Dear Wolfgang, On Mon, Sep 21, 2009 at 10:53:13PM +0200, Wolfgang Denk wrote: Seems you are using old code. This has long been fixed (using a %zu format). That's surprising. I got a tarball last friday (3 days ago) using the snapshot button on the gitweb interface : u-boot-3dc5e00454a58499d4f4c790b38036b0e873747e.tar.gz You need this commit: ... Date: Tue Sep 15 21:13:27 2009 +0200 ... It was merged into the master branch on 2009-09-18 23:20:12. OK, that's the explanation : I downloaded the snapshot on 2009-09-18 18:59 thanks and good night Philippe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
