[U-Boot] imx27lite stability problems.
I have tried u-boot for the imx27lite board from LogicPD which is currently in u-boot-arm repository and I have experienced some stability problems: - Sometimes the system gets stuck in serial_getc() from serial_mxc.c driver when printing information (ex. mii read ). - Pings do not work properly, the system gets stuck in fec_send() function waiting always for a frame to be sent (which actually does not happen). - Sometimes the system gets stuck when saving the environment to flash 'saveenv', but other times it does it well. I would like to help to solve this problems, but I don't know exactly where to begin from. I have been reviewing clock settings. Could this be happening because this board is using 32KHz xtal as reference instead of 26MHz one? Have you experienced these problems also? Thank you. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] imx27lite stability problems.
2009/9/17 Wolfgang Denk : > Dear javier Martin, > > In message you > wrote: >> I have tried u-boot for the imx27lite board from LogicPD which is >> currently in u-boot-arm repository and I have experienced some >> stability problems: >> - Sometimes the system gets stuck in serial_getc() from serial_mxc.c >> driver when printing information (ex. mii read ). >> - Pings do not work properly, the system gets stuck in fec_send() >> function waiting always for a frame to be sent (which actually does >> not happen). >> - Sometimes the system gets stuck when saving the environment to flash >> 'saveenv', but other times it does it well. > > We don't see any such issues on the board we have here in the lab. > >> I would like to help to solve this problems, but I don't know exactly >> where to begin from. I have been reviewing clock settings. Could this >> be happening because this board is using 32KHz xtal as reference >> instead of 26MHz one? > > Yes, of course this could be a problem. Is this an original LogicPD > board? Did you adapt the code for the different clock speed? What > exactly did you change? Sorry, I am not trying it on an original LogicPD board. Our board is based in i.mx27 ipcam. We have a different phy which is in 0x0 address instead of 0x1F and we have also a different NOR flash model. We have also the external 32KHz xtal at 32.768 KHz. - The init code for our sdram is different as we have different model and memory configuration, however I made a memory test and all seems fine. - I adapted NOR flash configuration and PHY_ADDRESS only, and experienced the previous problems. I could expect issues with NOR flash but I don't know why I could have any issue with ethernet. > >> Have you experienced these problems also? > > No, we didn't. > > Best regards, > > Wolfgang Denk > > -- > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de > Monday is an awful way to spend one seventh of your life. > -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mx27ads: add support for iMX27ADS board from Freescale
Has anyone tested ethernet connection in this board? Thank you. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] imx27lite stability problems.
I've found some problems because the cache is enabled, I don't see any place where you disable it. Are you sure you have this controlled properly? -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] imx27lite stability problems.
2009/9/17 Fred Fan : > Dear Javier Martin: > > 2009/9/17, javier Martin : >> >> I've found some problems because the cache is enabled, I don't see any >> place where you disable it. >> [Fred] Do you means D-cache is enabled? There are no mmu enabled, D-cache >> should be disabled as default setting. This is what I also though but I found it making some debugging through JTAG + GDB. As I stated in my first mail, FEC driver was getting stuck after transmitting a frame in a while() loop. However, using wireshark the frame had actually been sent. And using GDB I found that in the SDRAM the while() condition was true, nevertheless the microprocessor was evaluating it as false. That seemed to cache issues to me, so I put a "dcache_disable()" just before that while() loop and saw that these problems were not happening anymore. What is your opinion? Thanks. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] u-boot memory map questions
I am trying to port u-boot to our custom board based on i.MX27 SoC. For that purpose I am taking the code for i.mx27 litekit as start point. Currently I am figuring out what the memory map of my system would be if I have the following parameters: In config.mk TEXT_BASE = 0xA3F0 In my board config file: /* * Memory Info */ /* malloc() len */ #define CONFIG_SYS_MALLOC_LEN(0x1 + 512 * 1024) /* reserved for initial data */ #define CONFIG_SYS_GBL_DATA_SIZE128 /* memtest start address */ #define CONFIG_SYS_MEMTEST_START0xA000 #define CONFIG_SYS_MEMTEST_END0xA100/* 16MB RAM test */ #define CONFIG_NR_DRAM_BANKS1/* we have 1 bank of DRAM */ #define CONFIG_STACKSIZE(256 * 1024)/* regular stack */ #define PHYS_SDRAM_10xA000/* DDR Start */ #define PHYS_SDRAM_1_SIZE0x0400/* DDR size 64MB */ According to the README file I think my memory map should be the following: 0xA000 Exception Vector code [Start of RAM] : 0xA000 1FFF -- 0xA000 2000 Free for Application Use : : 0xA3E2 FF7BEnd of application memory -- 0xA3E2 FF7C Stack End (TEXT_BASE - CONFIG_SYS_MALLOC_LEN - CONFIG_SYS_GBL_DATA_SIZE - 4 - CONFIG_STACKSIZE) : 0xA3E6 FF7CMonitor Stack (Growing downward) (TEXT_BASE - CONFIG_SYS_MALLOC_LEN - CONFIG_SYS_GBL_DATA_SIZE - 4) -- 0xA3E6 FF80 Board Info Data and permanent copy of global data (TEXT_BASE - CONFIG_SYS_MALLOC_LEN - CONFIG_SYS_GBL_DATA_SIZE) : 0xA3E6 -- 0xA3E7 Malloc Area (TEXT_BASE - CONFIG_SYS_MALLOC_LEN) : 0xA3EF -- 0xA3F0 RAM Copy of Monitor Code (TEXT_BASE) ... eventually: LCD or video framebuffer ... eventually: pRAM (Protected RAM - unchanged by reset) 0xA3FF [End of RAM] Do you see some wrong point here? Thanks. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] imx27lite stability problems.
2009/9/17 Wolfgang Denk : > Dear javier Martin > >> I would like to help to solve this problems, but I don't know exactly >> where to begin from. I have been reviewing clock settings. Could this >> be happening because this board is using 32KHz xtal as reference >> instead of 26MHz one? > > Yes, of course this could be a problem. Is this an original LogicPD > board? Did you adapt the code for the different clock speed? What > exactly did you change? Dear Wolfgang Denk, I could finally test this in an original LogicPD i.mx27 litekit board and found the same problems. System gets stuck when issuing a ping command. - I am using u-boot-arm repository "commit 617da90c1dcf65428ddfb63fef897439950bc915" without any modifications. - arm-linux-gcc toolchains from eldk-arm-4.1. - I configured u-boot for i.mx27 litekit, compiled and flashed it in the NOR with a JTAG. Please, do you have an idea of what could I be missing? -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] imx27lite stability problems.
2009/10/16 Wolfgang Denk : > Dear Javier Martin, > > In message you > wrote: >> >> I could finally test this in an original LogicPD i.mx27 litekit board >> and found the same problems. >> System gets stuck when issuing a ping command. >> >> - I am using u-boot-arm repository "commit >> 617da90c1dcf65428ddfb63fef897439950bc915" without any modifications. > > Can you please use mainline, i. e. the master branch at > git://git.denx.de/u-boot.git instead? > >> Please, do you have an idea of what could I be missing? > > Well, there is a "Possible iMX27 intermittent Ethernet connection > issue rework" issued by LPD on 7/8/2008; in essence the PHY's > internal 1.8V core regulator may shut off at power up. > > To work around this, try and implement the following two hardware > modifications: > > 1) Populate R841 with a 4.7K resistor. (This forces the internal core > regulator off for the LAN8700. R841 is located on top of the PCB > just "above" the LAN8700 IC. > > 2) Add a jumper wire from U125.5 to C561.1. This connects the on > board 1.8V rail to the core ensuring that it is always powered. Before trying hardware fixes you suggested I tried using another toolchain which comes with LTIB for i.mx27ads: * I used arm-linux-gnueabi- toolchain from LTIB with the command: USE_PRIVATE_LIBGCC=yes make CROSS_COMPILE=arm-none-linux-gnueabi- And found some improvements, ping doesn't hang the system, although it fails, but the second time it is executed I get an error: => ping 192.168.0.40 FEC_MXC: Autonegotiation timeout Using FEC_MXC device ping failed; host 192.168.0.40 is not alive => ping 192.168.0.40 Unhandled Exception: exception mode: abort fsr: 0x0008 far: 0x000c **UNRECOVERABLE ERROR** There was a memory access exception at 0x000c of type 'extern fetch1' this may be due to an access to an invalid memory region, unaligned access, or a problem with the current memory map. Please check the memory layout section of your processor manual. For information about the active memory map type 'info cpu'. r00: a7e9c000 r01: r02: r03: r04: a7e816f8 r05: a7e81700 r06: r07: a7f31600 r08: a7e6ffe0 r09: r10: r11: r12: a7f326f0 sp: a7e6f270 lr: 0001a908 pc: a7f1774c spsr:00d3 cpsr:00d7 bt: sp: a7e6f1a8 (stack: a00667e4 - a00697e4) (fp:->a7e6f1d0, sp:a7e6f1a8) What toolchain are you using for compiling this? It seems I got a different behavior changing it. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [u-boot] [PATCH] [1/2] mxc_fec: fix some erroneous PHY accesses.
This patch fixes erroneous access to the ethernet PHY which broke the driver. 1. Selector field in the auto-negotiation register must be 0x1 for using 802.3, not 0x0 which is reseved. 2. Access to the PHY address specified by CONFIG_FEC_MXC_PHYADDR, not 0x0 fixed address. This has been tested in i.MX27 Litekit board and eldk-2.0 toolchains. Signed-off-by: Javier Martin -- diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c index bd83a24..18f0bba 100644 --- a/drivers/net/fec_mxc.c +++ b/drivers/net/fec_mxc.c @@ -157,7 +157,7 @@ static int miiphy_restart_aneg(struct eth_device *dev) /* * Set the auto-negotiation advertisement register bits */ - miiphy_write(dev->name, CONFIG_FEC_MXC_PHYADDR, PHY_ANAR, 0x1e0); + miiphy_write(dev->name, CONFIG_FEC_MXC_PHYADDR, PHY_ANAR, 0x1e1); miiphy_write(dev->name, CONFIG_FEC_MXC_PHYADDR, PHY_BMCR, PHY_BMCR_AUTON | PHY_BMCR_RST_NEG); @@ -341,8 +341,8 @@ static int fec_open(struct eth_device *edev) writel(FEC_ECNTRL_ETHER_EN, &fec->eth->ecntrl); miiphy_wait_aneg(edev); - miiphy_speed(edev->name, 0); - miiphy_duplex(edev->name, 0); + miiphy_speed(edev->name, CONFIG_FEC_MXC_PHYADDR); + miiphy_duplex(edev->name, CONFIG_FEC_MXC_PHYADDR); /* * Enable SmartDMA receive task -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [u-boot] [PATCH] [2/2] mxc_fec: put freed pointers to NULL to avoid problems with further free() calls.
If a free() call is used on an already freed pointer we run into
stability problems.
Put all pointers to NULL after freeing to avoid this problem.
Tested on i.MX27 Litekit board with eldk-2.0 toolchain.
Signed-off-by: Javier Martin
--
diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index bd83a24..7e86bc6 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -444,6 +444,7 @@ static int fec_init(struct eth_device *dev, bd_t* bd)
*/
if (fec_rbd_init(fec, FEC_RBD_NUM, FEC_MAX_PKT_SIZE) < 0) {
free(fec->base_ptr);
+ fec->base_ptr = NULL;
return -ENOMEM;
}
fec_tbd_init(fec);
@@ -492,7 +493,9 @@ static void fec_halt(struct eth_device *dev)
fec->rbd_index = 0;
fec->tbd_index = 0;
free(fec->rdb_ptr);
+ fec->rdb_ptr = NULL;
free(fec->base_ptr);
+ fec->base_ptr = NULL;
debug("eth_halt: done\n");
}
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [u-boot] [PATCH] [2/2] mxc_fec: put freed pointers to NULL to avoid problems with further free() calls.
2009/10/19 Wolfgang Denk : > Dear javier Martin, > > In message you > wrote: >> If a free() call is used on an already freed pointer we run into >> stability problems. > > Is this actually the case anywhere in the code? If so, that code > should be fixed, as thisis obviously a bug then. > > I dislike workarounds like these as they just hush up design and/or > implementation issues int he code. lease rather fix the real problems > instead. > > Thanks. You are right. > >> Tested on i.MX27 Litekit board with eldk-2.0 toolchain. > > ELDK 2.0? Wow. I did not think this was still in use anywhere around. This is obviously a typo, I used eldk-4.2. > Best regards, > > Wolfgang Denk > > -- > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de > "Most people would like to be delivered from temptation but would > like it to keep in touch." - Robert Orben > Thank you for your comments, I will resent this patch fixing the real problem. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [u-boot] [PATCH] [2/2] [v1.2] mxc_fec: avoid free() calls to already freed pointers.
Sometimes, inside NetLoop, eth_halt() is called before eth_init() has
been called. This is harmless except for free() calls to pointers
which have not been allocated yet. This patch adds two states to
distinguish when it is necessary to call free() and when it is not.
This has been tested in i.MX27 Litekit board and eldk-4.2 toolchains.
Signed-off-by: Javier Martin
--
drivers/net/fec_mxc.c |9 +++--
drivers/net/fec_mxc.h | 10 ++
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index bd83a24..9e9ef99 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -55,6 +55,7 @@ struct fec_priv gfec = {
.tbd_base = NULL,
.tbd_index = 0,
.bd= NULL,
+ .status= FEC_HALT_STATUS,
};
/*
@@ -453,6 +454,7 @@ static int fec_init(struct eth_device *dev, bd_t* bd)
miiphy_restart_aneg(dev);
fec_open(dev);
+ fec->status = FEC_INIT_STATUS;
return 0;
}
@@ -491,8 +493,11 @@ static void fec_halt(struct eth_device *dev)
writel(0, &fec->eth->ecntrl);
fec->rbd_index = 0;
fec->tbd_index = 0;
- free(fec->rdb_ptr);
- free(fec->base_ptr);
+ if (fec->status == FEC_INIT_STATUS) {
+ free(fec->rdb_ptr);
+ free(fec->base_ptr);
+ }
+ fec->status = FEC_HALT_STATUS;
debug("eth_halt: done\n");
}
diff --git a/drivers/net/fec_mxc.h b/drivers/net/fec_mxc.h
index 6cb1bfc..266b5d3 100644
--- a/drivers/net/fec_mxc.h
+++ b/drivers/net/fec_mxc.h
@@ -245,9 +245,19 @@ struct fec_priv {
bd_t *bd;
void *rdb_ptr;
void *base_ptr;
+ int status; /* whether fec is halted or not* */
};
/**
+ * @brief Possible values for status
+ *
+ * fec_halt() changes the status to FEC_HALT_STATUS and fec_init()
+ * changes the status to FEC_INIT_STATUS
+ */
+#define FEC_HALT_STATUS 0
+#define FEC_INIT_STATUS 1
+
+/**
* @brief Numbers of buffer descriptors for receiving
*
* The number defines the stocked memory buffers for the receiving task.
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [u-boot] [PATCH] [2/2] [v1.2] mxc_fec: avoid free() calls to already freed pointers.
> >> /** >> + * @brief Possible values for status >> + * >> + * fec_halt() changes the status to FEC_HALT_STATUS and fec_init() >> + * changes the status to FEC_INIT_STATUS >> + */ >> +#define FEC_HALT_STATUS 0 >> +#define FEC_INIT_STATUS 1 > > It would seem more logical to me if you swapped names around, i. e. > please use FEC_STATUS_INIT and FEC_STATUS_HALT. > > Also, we might consider using an enum here? No problem, let me fix it and resend. Thank you for the comments. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [u-boot] Problem with exceptions in i.mx27.
In my custom i.mx27 based board am having data_abort exceptions. As I could find from arm library code, a simple dump showing last register values should happen to the console, since it is coded so in data_abort handler. So, why is not i.mx27 triggering the data_abort exception handler? I did some tests on i.mx27 litekit board, where I forced a data_abort exception trying to access to a NULL pointer. What I found is that dump wasn't shown on this board neither. Then, I disassembled code in the internal ROM of the i.MX27 where lowest level exception vectors should be placed and I found the following: 0x 0xe59ff00c LDR r15, [r15, #0xc] 0x0004 0xe51ff11c LDR r15, [r15, #-0x11c] 0x0008 0xe51ff11c LDR r15, [r15, #-0x11c] 0x000c 0xe51ff11c LDR r15, [r15, #-0x11c] 0x0010 0xe51ff11c LDR r15, [r15, #-0x11c] 0x0014 0xc000 ANDGT r0, r0, r0 0x0018 0xe51ff120 LDR r15, [r15, #-0x120] 0x001c 0xe51ff120 LDR r15, [r15, #-0x120] This means that u-boot exception vector address should be located in the internal vRAM (0x_4C00 - 0x_). I solved the problem adding an assembler macro in lowlevel_init.S for the imx27lite board: -- diff --git a/board/logicpd/imx27lite/lowlevel_init.S b/board/logicpd/imx27lite/lowlevel_init.S index e2cdecb..8419471 100644 --- a/board/logicpd/imx27lite/lowlevel_init.S +++ b/board/logicpd/imx27lite/lowlevel_init.S @@ -40,6 +40,19 @@ SDRAM_LOADMODE_CMD_W:.word (ESDCTL_SDE | ESDCTL_SMODE_LOAD_MODE | \ ESDCTL_ROW13 | ESDCTL_COL10) SDRAM_NORMAL_CMD_W:.word SDRAM_ESDCTL_REGISTER_VAL +.macro init_vram_vectors + /* TODO: +* - Find a proper place to do this for all i.mx27 chips. +* - Calculate Exception vector address in RAM using some parameter. +*/ + write32 0xfef0, 0xa7f4 /* Undefined interrupt handler */ + write32 0xfef4, 0xa7f8 /* Software interrupt handler */ + write32 0xfef8, 0xa7fc /* Prefetch abort handler */ + write32 0xfefc, 0xa7f00010 /* Data abort handler */ + write32 0xff00, 0xa7f00018 /* Default IRQ handler */ + write32 0xff04, 0xa7f0001c /* Default FIQ handler */ +.endm /* init vram vectors */ + .macro init_aipi /* * setup AIPI1 and AIPI2 @@ -167,4 +180,6 @@ lowlevel_init: sdram_init + init_vram_vectors + mov pc,r10 -- I am aware that this patch is not probably the proper way of doing this but I'd like to know: Has anyone got the same problem? Please, try to force and exception and see if a dump is generated, if not, apply this patch and confirm results. If this is a generalized problem, which would be a good place to do it? Comments are much appreciated. Thank you. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [u-boot] [PATCH] [2/2] [v1.3] mxc_fec: avoid free() calls to already freed pointers.
Sometimes, inside NetLoop, eth_halt() is called before eth_init() has
been called. This is harmless except for free() calls to pointers
which have not been allocated yet. This patch adds two states to
distinguish when it is necessary to call free() and when it is not.
This has been tested in i.MX27 Litekit board with eldk-4.2 toolchains.
Signed-off-by: Javier Martin
--
diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index bd83a24..351c75c 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -55,6 +55,7 @@ struct fec_priv gfec = {
.tbd_base = NULL,
.tbd_index = 0,
.bd= NULL,
+ .status= FEC_STATUS_HALT,
};
/*
@@ -453,6 +454,7 @@ static int fec_init(struct eth_device *dev, bd_t* bd)
miiphy_restart_aneg(dev);
fec_open(dev);
+ fec->status = FEC_STATUS_INIT;
return 0;
}
@@ -491,8 +493,11 @@ static void fec_halt(struct eth_device *dev)
writel(0, &fec->eth->ecntrl);
fec->rbd_index = 0;
fec->tbd_index = 0;
- free(fec->rdb_ptr);
- free(fec->base_ptr);
+ if (fec->status == FEC_STATUS_INIT) {
+ free(fec->rdb_ptr);
+ free(fec->base_ptr);
+ }
+ fec->status = FEC_STATUS_HALT;
debug("eth_halt: done\n");
}
diff --git a/drivers/net/fec_mxc.h b/drivers/net/fec_mxc.h
index 6cb1bfc..51c74ea 100644
--- a/drivers/net/fec_mxc.h
+++ b/drivers/net/fec_mxc.h
@@ -245,9 +245,19 @@ struct fec_priv {
bd_t *bd;
void *rdb_ptr;
void *base_ptr;
+ enum { FEC_STATUS_HALT, FEC_STATUS_INIT } status;
};
/**
+ * @brief Possible values for status
+ *
+ * fec_halt() changes the status to FEC_HALT_STATUS and fec_init()
+ * changes the status to FEC_INIT_STATUS
+ */
+#define FEC_STATUS_HALT 0
+#define FEC_STATUS_INIT 1
+
+/**
* @brief Numbers of buffer descriptors for receiving
*
* The number defines the stocked memory buffers for the receiving task.
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] imx27lite: add support for imx27lite board from LogicPD
Hi, What happened with this patch? Was it applied or did it have any problems? Is it tested? Thank you. -- Javier Martin Vista Silicon S.L. Universidad de Cantabria CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] imx27lite: add support for imx27lite board from LogicPD
2009/8/5 javier Martin : > Hi, > What happened with this patch? Was it applied or did it have any problems? > Is it tested? I have applied it but when compiling it gives the following errors: hdog/libwatchdog.a common/libcommon.a libfdt/libfdt.a api/libapi.a post/libpost.a board/freescale/mx31ads/libmx31ads.a --end-group -L /opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/lib/gcc/arm-none-linux-gnueabi/4.1.2 -lgcc -Map u-boot.map -o u-boot arm-none-linux-gnueabi-ld: ERROR: Source object /opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/lib/gcc/arm-none-linux-gnueabi/4.1.2/libgcc.a(_udivsi3.o) has EABI version 4, but target u-boot has EABI version 0 arm-none-linux-gnueabi-ld: failed to merge target specific data of file /opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/lib/gcc/arm-none-linux-gnueabi/4.1.2/libgcc.a(_udivsi3.o) arm-none-linux-gnueabi-ld: ERROR: Source object /opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/lib/gcc/arm-none-linux-gnueabi/4.1.2/libgcc.a(_divsi3.o) has EABI version 4, but target u-boot has EABI version 0 arm-none-linux-gnueabi-ld: failed to merge target specific data of file /opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/lib/gcc/arm-none-linux-gnueabi/4.1.2/libgcc.a(_divsi3.o) arm-none-linux-gnueabi-ld: ERROR: Source object /opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/lib/gcc/arm-none-linux-gnueabi/4.1.2/libgcc.a(_umodsi3.o) has EABI version 4, but target u-boot has EABI version 0 arm-none-linux-gnueabi-ld: failed to merge target specific data of file /opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/lib/gcc/arm-none-linux-gnueabi/4.1.2/libgcc.a(_umodsi3.o) arm-none-linux-gnueabi-ld: ERROR: Source object /opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/lib/gcc/arm-none-linux-gnueabi/4.1.2/libgcc.a(_modsi3.o) has EABI version 4, but target u-boot has EABI version 0 arm-none-linux-gnueabi-ld: failed to merge target specific data of file /opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/lib/gcc/arm-none-linux-gnueabi/4.1.2/libgcc.a(_modsi3.o) arm-none-linux-gnueabi-ld: ERROR: Source object /opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/lib/gcc/arm-none-linux-gnueabi/4.1.2/libgcc.a(_dvmd_lnx.o) has EABI version 4, but target u-boot has EABI version 0 arm-none-linux-gnueabi-ld: failed to merge target specific data of file /opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/lib/gcc/arm-none-linux-gnueabi/4.1.2/libgcc.a(_dvmd_lnx.o) /opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/lib/gcc/arm-none-linux-gnueabi/4.1.2/libgcc.a(_dvmd_lnx.o): In function `__div0': /usr/src/redhat/BUILD/cross-mlib/source/gcc-4.1.2/gcc/config/arm/lib1funcs.asm:1000: undefined reference to `raise' make: *** [u-boot] Error 1 Any ideas about this problem? Thank you. > > -- > Javier Martin > Vista Silicon S.L. > Universidad de Cantabria > CDTUC - FASE C - Oficina S-345 > Avda de los Castros s/n > 39005- Santander. Cantabria. Spain > +34 942 25 32 60 > www.vista-silicon.com > -- Javier Martin Vista Silicon S.L. Universidad de Cantabria CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] imx27lite: add support for imx27lite board from LogicPD
2009/8/5 Wolfgang Denk : > Dear javier Martin, > > In message you > wrote: >> >> I have applied it but when compiling it gives the following errors: > ... >> arm-none-linux-gnueabi-ld: ERROR: Source object >> /opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/lib/gcc/arm-none-linux-gnueabi/4.1.2/libgcc.a(_udivsi3.o) >> has EABI version 4, but target u-boot has EABI version 0 > ... >> Any ideas about this problem? > > You want to read the FAQ: > http://www.denx.de/wiki/view/DULG/SourceObjectHasEABIVersion4ButTargetHasEABIVersion0 What toolchains do you use then? I have tried with the toolchains provided with ELDK4 but no luck. They also seem to be EABI version 4. -- Javier Martin Vista Silicon S.L. Universidad de Cantabria CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] imx27lite: add support for imx27lite board from LogicPD
Now, I am using 4.1 version of eldk. With the previous patch applied I get this problem with "board_nand_init". I don't know if it's still a problem of my toolchain of this is a BUG: drivers/mtd/nand/libnand.a(nand.o): In function `nand_init': /home/javier/GIT/u-boot/drivers/mtd/nand/nand.c:53: undefined reference to `board_nand_init' Regards. -- Javier Martin Vista Silicon S.L. Universidad de Cantabria CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] imx27lite: add support for imx27lite board from LogicPD
2009/8/6 Wolfgang Denk : > I have just posted a patch: > > [PATCH] ARM EABI: add new helper functions resp. function names > > (see http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/65473 > > > Combined with commit 52b1bf2c: > > Make linking against libgcc configurable > > I can run a "USE_PRIVATE_LIBGCC=yes ./MAKEALL arm" with an EABI > conformant tool chain (ELDK 4.2) without any related issues. > > It would be great if you all could test this, so we can get this in as > quickly as possible. This also works for me using Freescale's toolchain included in LTIB for i.mx27 ads board. One thing that confuses me a little about this imx27litekit patch is that TEXT_ADDRESS is a RAM address but, according to the FAQ u-boot cannot be run from RAM by another bootloader. Why is TEXT_ADDRESS in RAM then? Thanks. -- Javier Martin Vista Silicon S.L. Universidad de Cantabria CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [u-boot] [PATCH] [1/2] mxc_fec: fix some erroneous PHY accesses.
Who can ack this patch? Is Fred Fan or Tom Rix? Thank you. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] macro substitution - can someone explain please
I have a similar problem. In my environment:
bootcmd=cp.b c004 ${loadaddr} 28;bootm ${loadaddr}
mtdparts=mtdparts=mxc_nor_flash.0:256k(U-Boot),2560k(kernel),29312k(rootfs),512k(config),128k(env1)
bootargs=noinitrd console=ttymxc0,115200 root=/dev/mtdblock2
init=linuxrc rw ${mtdparts}
But when I execute 'run bootm', kernel boots but "mtdparts" variable
is not substituted in kernel command line:
Uncompressing
Linux..
done, booting the kernel.
[0.00] Linux version 2.6.22.6-gb5e710ce-dirty (jav...@acuario)
(gcc version 4.1.2) #219 PREEMPT Fri Oct 23 18:12:58 CEST 2009
[0.00] CPU: ARM926EJ-S [41069264] revision 4 (ARMv5TEJ), cr=00053177
[0.00] Machine: Freescale i.MX27ADS
[0.00] Memory policy: ECC disabled, Data cache writeback
[0.00] CPU0: D VIVT write-back cache
[0.00] CPU0: I cache: 16384 bytes, associativity 4, 32 byte
lines, 128 sets
[0.00] CPU0: D cache: 16384 bytes, associativity 4, 32 byte
lines, 128 sets
[0.00] Built 1 zonelists. Total pages: 16256
[0.00] Kernel command line: noinitrd console=ttymxc0,115200
root=/dev/mtdblock2 init=linuxrc rw ${mtdparts}
As stated in README file, global variables should be able to be
accessed through ${ } symbols. Is this also valid inside "bootargs"
variable?
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [u-boot] [PATCH] [1/2] [v1.2] mxc_fec: fix some erroneous PHY accesses.
This patch fixes erroneous access to the ethernet PHY which broke the driver. 1. Selector field in the auto-negotiation register must be 0x1 for using 802.3, not 0x0 which is reseved. 2. Access to the PHY address specified by CONFIG_FEC_MXC_PHYADDR, not 0x0 fixed address. This has been tested in i.MX27 Litekit board and eldk-4.2 toolchains. Now using proper defines for auto-negotiation register. Signed-off-by: Javier Martin -- drivers/net/fec_mxc.c |8 +--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c index bd83a24..9764e12 100644 --- a/drivers/net/fec_mxc.c +++ b/drivers/net/fec_mxc.c @@ -157,7 +157,9 @@ static int miiphy_restart_aneg(struct eth_device *dev) /* * Set the auto-negotiation advertisement register bits */ - miiphy_write(dev->name, CONFIG_FEC_MXC_PHYADDR, PHY_ANAR, 0x1e0); + miiphy_write(dev->name, CONFIG_FEC_MXC_PHYADDR, PHY_ANAR, + PHY_ANLPAR_TXFD | PHY_ANLPAR_TX | PHY_ANLPAR_10FD | + PHY_ANLPAR_10 | PHY_ANLPAR_PSB_802_3); miiphy_write(dev->name, CONFIG_FEC_MXC_PHYADDR, PHY_BMCR, PHY_BMCR_AUTON | PHY_BMCR_RST_NEG); @@ -341,8 +343,8 @@ static int fec_open(struct eth_device *edev) writel(FEC_ECNTRL_ETHER_EN, &fec->eth->ecntrl); miiphy_wait_aneg(edev); - miiphy_speed(edev->name, 0); - miiphy_duplex(edev->name, 0); + miiphy_speed(edev->name, CONFIG_FEC_MXC_PHYADDR); + miiphy_duplex(edev->name, CONFIG_FEC_MXC_PHYADDR); /* * Enable SmartDMA receive task -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [u-boot] [PATCH] [2/2] [v1.4] mxc_fec: avoid free() calls to already freed pointers.
Sometimes, inside NetLoop, eth_halt() is called before eth_init() has
been called. This is harmless except for free() calls to pointers
which have not been allocated yet.
This patch initializes those pointers to NULL and allocates them only
the first time. This way we can get rid of free calls in halt callback.
This has been tested in i.MX27 Litekit board and eldk-4.2 toolchains.
Signed-off-by: Javier Martin
--
drivers/net/fec_mxc.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index bd83a24..08a4dd5 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -55,6 +55,8 @@ struct fec_priv gfec = {
.tbd_base = NULL,
.tbd_index = 0,
.bd= NULL,
+ .rdb_ptr = NULL,
+ .base_ptr = NULL,
};
/*
@@ -228,7 +230,8 @@ static int fec_rbd_init(struct fec_priv *fec, int
count, int size)
uint32_t p = 0;
/* reserve data memory and consider alignment */
- fec->rdb_ptr = malloc(size * count + DB_DATA_ALIGNMENT);
+ if (fec->rdb_ptr == NULL)
+ fec->rdb_ptr = malloc(size * count + DB_DATA_ALIGNMENT);
p = (uint32_t)fec->rdb_ptr;
if (!p) {
puts("fec_imx27: not enough malloc memory!\n");
@@ -363,8 +366,9 @@ static int fec_init(struct eth_device *dev, bd_t* bd)
* Datasheet forces the startaddress of each chain is 16 byte
* aligned
*/
- fec->base_ptr = malloc((2 + FEC_RBD_NUM) *
- sizeof(struct fec_bd) + DB_ALIGNMENT);
+ if (fec->base_ptr == NULL)
+ fec->base_ptr = malloc((2 + FEC_RBD_NUM) *
+ sizeof(struct fec_bd) + DB_ALIGNMENT);
base = (uint32_t)fec->base_ptr;
if (!base) {
puts("fec_imx27: not enough malloc memory!\n");
@@ -491,8 +495,6 @@ static void fec_halt(struct eth_device *dev)
writel(0, &fec->eth->ecntrl);
fec->rbd_index = 0;
fec->tbd_index = 0;
- free(fec->rdb_ptr);
- free(fec->base_ptr);
debug("eth_halt: done\n");
}
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [u-boot] [PATCH] imx27: make 26MHz clock input value selectable from config files.
Some boards like Freescale imx27-ipcam and Vista Silicon
imx27_visstrim_m10 have 25MHz clocks connected to 26MHz input.
This patch allows this value to be specified from the board
configuration file in the same way as it is done with 32KHz clock.
It does not break any existing board since its default value is 26MHz.
Tested in imx27lite and imx27_visstrim_m10 board.
Signed-off-by: Javier Martin
--
cpu/arm926ejs/mx27/generic.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/cpu/arm926ejs/mx27/generic.c b/cpu/arm926ejs/mx27/generic.c
index da05c55..c26fc56 100644
--- a/cpu/arm926ejs/mx27/generic.c
+++ b/cpu/arm926ejs/mx27/generic.c
@@ -26,7 +26,9 @@
#ifdef CONFIG_MXC_MMC
#include
#endif
-
+#ifndef CONFIG_MX27_CLK26M
+#define CONFIG_MX27_CLK26M 2600
+#endif
/*
* get the system pll clock in Hz
*
@@ -58,9 +60,9 @@ static ulong clk_in_26m(void)
if (readl(&pll->cscr) & CSCR_OSC26M_DIV1P5) {
/* divide by 1.5 */
- return 2600 * 2 / 3;
+ return CONFIG_MX27_CLK26M * 2 / 3;
} else {
- return 2600;
+ return CONFIG_MX27_CLK26M;
}
}
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Support for several I2C interfaces in the same board.
I read a discussion about this subject in the past but it didn't arrive to a conclusion. What would be necessary for supporting two I2C interfaces? Maybe an i2c command that supports changing active interface or something similar? -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Support for several I2C interfaces in the same board.
> If you need two different hardware interfaces, there > is an approach, see: > > http://git.denx.de/?p=u-boot/u-boot-i2c.git;a=shortlog;h=refs/heads/multibus_v2 > > I ported (hopefully all) hardware i2c drivers to this new approach, > but didn;t find the time to test this again from scratch, I just > hold it in sync with mainline, and if I find time for testing it > again and it works, I vote for including it in mainline ... Thank you this is what I meant. > But testers are welcome :-) Sure, count on me for that; as soon as I have finished i.mx27 i2c driver I will integrate it in your tree and test it. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Support for several I2C interfaces in the same board.
> Hmm.. there is a driver/i2c/mxc_i2c.c driver for i.mx31, maybe the > i.mx27 is similiar to this? Can you check this? Yes, I2C registers are the same in both chips. The only things that I must change are: - i2c clock management. - i2c base addresses. My current approach is trying to make this driver work for imx27/imx31 using CONFIG_MX27/CONFIG_MX31 defines. I don't know if you have a better suggestion for this. Thank you. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [u-boot] [PATCH][1/2] mx27: Add necessary defines and helper functions to support I2C in i.MX27.
Add proper register definitions, macros and clock functions required
for I2C driver to be developed.
Signed-off-by: Javier Martin
--
diff --git a/cpu/arm926ejs/mx27/generic.c b/cpu/arm926ejs/mx27/generic.c
index 808371f..540ef0c 100644
--- a/cpu/arm926ejs/mx27/generic.c
+++ b/cpu/arm926ejs/mx27/generic.c
@@ -22,11 +22,21 @@
#include
#include
#include
+#include
#include
#ifdef CONFIG_MXC_MMC
#include
#endif
+int imx_get_revision(void)
+{
+ ulong val;
+
+ val = readl(SYSCTRL_CID);
+
+ return (int)(val >> 28);
+}
+
/*
* get the system pll clock in Hz
*
@@ -152,6 +162,19 @@ ulong imx_get_perclk4(void)
return imx_decode_perclk(((readl(&pll->pcdr1) >> 24) & 0x3f) + 1);
}
+ulong imx_get_ipgclk(void)
+{
+ ulong rate, ipg_pdf;
+
+ if (imx_get_revision() >= CHIP_REV_2_0)
+ return imx_get_ahbclk();
+ else
+ ipg_pdf = (readl(CSCR) >> 8) & 1;
+
+ rate = imx_get_ahbclk();
+ return rate / (ipg_pdf + 1);
+}
+
#if defined(CONFIG_DISPLAY_CPUINFO)
int print_cpuinfo (void)
{
diff --git a/include/asm-arm/arch-mx27/asm-offsets.h
b/include/asm-arm/arch-mx27/asm-offsets.h
index 497afe5..cdecef6 100644
--- a/include/asm-arm/arch-mx27/asm-offsets.h
+++ b/include/asm-arm/arch-mx27/asm-offsets.h
@@ -14,3 +14,5 @@
#define ESDCTL1_ROF0x08
#define ESDCFG1_ROF0x0C
#define ESDMISC_ROF0x10
+#define SYSCTRL_CID0x10027800
+#define CHIP_REV_2_0 0x01
diff --git a/include/asm-arm/arch-mx27/imx-regs.h
b/include/asm-arm/arch-mx27/imx-regs.h
index d36a6da..2b89b4e 100644
--- a/include/asm-arm/arch-mx27/imx-regs.h
+++ b/include/asm-arm/arch-mx27/imx-regs.h
@@ -206,6 +206,10 @@ struct iim_regs {
};
#endif
+#define __REG(x) (*((volatile u32 *)(x)))
+#define __REG16(x) (*((volatile u16 *)(x)))
+#define __REG8(x)(*((volatile u8 *)(x)))
+
#define IMX_IO_BASE0x1000
#define IMX_AIPI1_BASE (0x0 + IMX_IO_BASE)
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [u-boot][PATCH][2/2] i2c_mxc: Add I2C support for i.MX27 chip processor.
Add support for I2C in i.MX27 chip.
Tested on imx27_visstrim_m10 board.
Signed-off-by: Javier Martin
--
diff --git a/drivers/i2c/mxc_i2c.c b/drivers/i2c/mxc_i2c.c
index 8e10fbb..63a8085 100644
--- a/drivers/i2c/mxc_i2c.c
+++ b/drivers/i2c/mxc_i2c.c
@@ -2,6 +2,8 @@
* i2c driver for Freescale mx31
*
* (c) 2007 Pengutronix, Sascha Hauer
+ * (c) 2009 Vista Silicon, Javier Martin
+ *
*
* See file CREDITS for list of people who contributed to this
* project.
@@ -21,13 +23,19 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston,
* MA 02111-1307 USA
*/
-
#include
#if defined(CONFIG_HARD_I2C)
+#ifdef CONFIG_MX31
#include
#include
+#elif defined (CONFIG_MX27)
+#include
+#include
+#else
+#error "architecture not supported by mxc_i2c driver"
+#endif
#define IADR 0x00
#define IFDR 0x04
@@ -47,6 +55,7 @@
#define I2SR_IIF (1 << 1)
#define I2SR_RX_NO_AK (1 << 0)
+#ifdef CONFIG_MX31
#ifdef CONFIG_SYS_I2C_MX31_PORT1
#define I2C_BASE 0x43f8
#define I2C_CLK_OFFSET 26
@@ -59,6 +68,18 @@
#else
#error "define CONFIG_SYS_I2C_MX31_PORTx to use the mx31 I2C driver"
#endif
+#endif /* CONFIG_MX31 */
+
+#ifdef CONFIG_MX27
+#ifdef CONFIG_SYS_I2C_MX27_PORT1
+#define I2C_BASE IMX_I2C1_BASE
+#elif defined (CONFIG_SYS_I2C_MX27_PORT2)
+#define I2C_BASE IMX_I2C2_BASE
+#else
+#error "define CONFIG_SYS_I2C_MX27_PORTx to use the mx27 I2C driver"
+#endif
+#endif /* CONFIG_MX27 */
+
#ifdef DEBUG
#define DPRINTF(args...) printf(args)
@@ -70,17 +91,37 @@ static u16 div[] = { 30, 32, 36, 42, 48, 52, 60, 72, 80,
88, 104, 128, 144,
160, 192, 240, 288, 320, 384, 480, 576, 640, 768, 960,
1152, 1280, 1536, 1920, 2304, 2560, 3072, 3840};
+static void i2c_clken(void)
+{
+#ifdef CONFIG_MX31
+ __REG(CCM_CGR0) = __REG(CCM_CGR0) | (3 << I2C_CLK_OFFSET);
+#elif defined(CONFIG_MX27)
+#ifdef CONFIG_SYS_I2C_MX27_PORT1
+ __REG(PCCR0) = __REG(PCCR0) | PCCR0_I2C1_EN;
+#else
+ __REG(PCCR0) = __REG(PCCR0) | PCCR0_I2C2_EN;
+#endif
+#endif /* CONFIG_MX31 */
+}
+
void i2c_init(int speed, int unused)
{
- int freq = mx31_get_ipg_clk();
+ int freq;
int i;
+#ifdef CONFIG_MX31
+ freq = mx31_get_ipg_clk();
+#elif defined(CONFIG_MX27)
+ freq = imx_get_ipgclk();
+#endif
/* start the required I2C clock */
- __REG(CCM_CGR0) = __REG(CCM_CGR0) | (3 << I2C_CLK_OFFSET);
+ i2c_clken();
+ DPRINTF("ipg_freq is %d\n", freq);
for (i = 0; i < 0x1f; i++)
if (freq / div[i] <= speed)
break;
+ DPRINTF("i2c_clk divisor is %d\n", div[i]);
DPRINTF("%s: speed: %d\n",__FUNCTION__, speed);
@@ -121,7 +162,6 @@ static int rx_byte(void)
int i2c_probe(uchar chip)
{
int ret;
-
__REG16(I2C_BASE + I2CR) = 0; /* Reset module */
__REG16(I2C_BASE + I2CR) = I2CR_IEN;
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [u-boot] [PATCH][1/2] mx27: Add necessary defines and helper functions to support I2C in i.MX27.
2009/11/2 Heiko Schocher :
> Hello Javier,
>
> Javier Martin wrote:
>> Add proper register definitions, macros and clock functions required
>> for I2C driver to be developed.
>>
>>
>>
>> Signed-off-by: Javier Martin
>> --
>> diff --git a/cpu/arm926ejs/mx27/generic.c b/cpu/arm926ejs/mx27/generic.c
>> index 808371f..540ef0c 100644
> [...]
>> diff --git a/include/asm-arm/arch-mx27/imx-regs.h
>> b/include/asm-arm/arch-mx27/imx-regs.h
>> index d36a6da..2b89b4e 100644
>> --- a/include/asm-arm/arch-mx27/imx-regs.h
>> +++ b/include/asm-arm/arch-mx27/imx-regs.h
>> @@ -206,6 +206,10 @@ struct iim_regs {
>> };
>> #endif
>>
>> +#define __REG(x) (*((volatile u32 *)(x)))
>> +#define __REG16(x) (*((volatile u16 *)(x)))
>> +#define __REG8(x) (*((volatile u8 *)(x)))
>> +
>
> Why you need this? Couldn;t you use io accessor from asm/io.h?
Hi Heiko,
thank you for the comments. I think that would make the driver dirty
since there would also be needed the use of an ifdef to separate
i.MX31 reg accesses, which are accessed through __REG() macros, from
i.MX27 ones which should be accessed by io accessors from io.h. If you
do not have any complaint about that I will use functions from
asm/io.h.
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [u-boot] [PATCH] imx27: make 26MHz clock input value selectable from config files.
I think Fred Fan is currently responsible of acking this patch if there are no objections, but he seems missing since some weeks. Couldn't the patch be reviewed by a higher level maintainer? Thanks. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Problem with SD card and ext2ls
I have an SD card with an ext2 partition and I am trying to access it through ext2ls command but this is what I get: # ext2ls mmc 0:1 / ** Bad partition - mmc 0:1 ** I have read some previous mails of some people complaining about a similar problem: http://www.mail-archive.com/u-boot@lists.denx.de/msg12776.html Here also Wolfgang Denk says that ext2 is currently broken in u-boot for newer ext2 images. Is this still true or has it been fixed since then? Thank you. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problem with SD card and ext2ls
Also if I issue a "mmc rescan 0" I get the following: # mmc rescan 0 # ext2ls mmc 0:1 / get partition info called raise: Signal # 8 caught raise: Signal # 8 caught raise: Signal # 8 caught What could be happening here? Thank you. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problem with SD card and ext2ls
Looking deeply in the list I found someone that had the same problem with an AT91: http://www.mail-archive.com/u-boot@lists.denx.de/msg23442.html I submit here all useful information about my case. Board: imx27lite Toolchains: eldk-4.2 GIT commit: f67066b6b0740b826ed862615c5ab022aaf4779a SD card formatted in ext2 with gparted. How to reproduce: => mmc rescan 0 => ext2ls mmc 0:1 / <2, 0, 204> ext2fs read inode 2 ext2fs read 0 group descriptor (blkno 2 blkoff 0) <4, 0, 32> raise: Signal # 8 caught ext2fs read inode blkno 0 blkoff 0 raise: Signal # 8 caught raise: Signal # 8 caught ext2fs read inode blkno 6 blkoff 0 <12, 0, 128> -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problem with SD card and ext2ls
> Sorry, the batteries of my crystal ball are running low... > > It _might_ help if you provided a _little_ information, at least the > most vital pieces like which architecture / board you are speaking of, > and which exact version (which git commit id) you are running. Please see my last mail. I sent three mails without reply and maybe this lead to some confusion, sorry. In that, my previous mail, you have all the information: Board, SD card, how to reproduce... Thank you. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [u-boot] [PATCH] imx27: make 26MHz clock input value selectable from config files.
I agree with the patch in general, but it seems very strange to me to > name the variable "CLK26M" when it could be, for example, 25M instead. > > Please chose a better name and resubmit. > Thank you for your comments I will pick up a better name and resubmit. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] USB tty corrupted stream on Beagleboard xM.
Hi, I am trying to get u-boot console out of USB OTG included in Beagleboard XM. For that purpose I'm using u-boot v2011.03 compiled for "omap3_beagle". I just boot my board and stop u-boot's booting process and enter the following: setenv stdout usbtty; setenv stdin usbtty; setenv stderr usbtty Then I connect my USB OTG cable and get a /dev/ttyACM0 device in my host PC. However, while I am able to send commands, it seems the stream gets corrupted. I've seen some people seeing the same issue before here without response: http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/99482 Has anyone found a solution for this? Thank you. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
