Re: [U-Boot] [PATCH] Use common function to set GPIOs for MX3 and MX5
Hi Mike, On Monday, August 23, 2010 17:03:24 Detlev Zundel wrote: Hi Stefan, On Monday 23 August 2010 17:55:44 Stefano Babic wrote: I am also adding support for S25FL032P chips to the spansion driver. Will post a patch later. I have seen. However, it should be better if you send the patch also to the maintainer for the MTD subsystem (Stefan Roese, I set his address in CC). Small correction: I'm not the custodian of the MTD subsystem, but of the CFI flash driver (amongst others). And I have never really taken care of the SPI flash patches before (and never used one of those drivers before). IIRC, then Mike (added to Cc) has the most insight here. In fact I cannot see that you extended the CC list. Wanna have another go? ;) i did since he added me to the cc ... Hm, hm, hm. That strange invisible CC phaenomenon again. I just checked again and on the mail that I received you are definitely not on the CC list Anyway, sorry for the noise Detlev -- To you I'm an atheist; to God, I'm the Loyal Opposition. -- Woody Allen -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Use common function to set GPIOs for MX3 and MX5
Hi again, On Friday 20 August 2010 03:35:57 pm Stefano Babic wrote: Just figured out one big mistake. I was debugging spi_flash.c, and had CONFIG_ENV_IS_IN_SPI_FLASH set. That means, first SPI access is done before malloc is available, and guess what? spi_setup_slave() uses malloc ;-) I have CONFIG_ENV_IS_IN_SPI_FLASH set, too. I try to figure out how the functions are called, but I do not get the same issue. I set with the debugger two breakpoints, one in mem_malloc_init and the second one in spi_setup_slave. I see that mem_alloc_init is hit first, and when spi_setup_slave is called, malloc is available. I get a valid pointer for the private structure. It seems there something in our config files that makes the things different. I do not yet know why. Are you sure? In arch/arm/lib/board.c function start_armboot(), init_sequence is processed first, which contains env_init() before dram_init() and just after completing init_sequence, mem_malloc_init() is called. How can you have working malloc then? The C++ comments show original code, the line below is new. Understood, if malloc is not called, we have to use static or (better) try to call mem_malloc_init() first I don't know if that is possible. I know that physically RAM is initialized before u-boot even starts (it runs from RAM), but logically, dram_init() is called _after_ env_init(), so I'm not sure if you are supposed to call mem_malloc_init() in env_init()... I see a one byte access followed by a 5 byte access, That is correct, you see the code in spi_flash.c. First the ID command is sent (0x97), without reading nothing (that is, din is NULL). Then the answer is read (dout is NULL), and the id buffer is 5 bytes long. I am slowly progressing... now the transfer succeeds, but I only read FF ;-) [...] I am trying another approach. As the MX51 has 32 bytes FIFO, it makes sense to use it and not send a single word, if we can. This must not change the behavior for the MX31, because this processor has no FIFO and a single word can be sent. So I replaced completely spi_xfer, and the logic you put in spi_xfer I have (more or less, I have not checked in details) moved inside the spi_xcgh:single, that now has the meaning for me as single transation: up to 1 word for i.MX31, up to 32 words (128 bytes) for i.MX51. Take into account that loading the kernel using a single word takes a lot of time.. A good point. I was following the premise that u-boot drivers should be simple, but a little bit of speed for booting is surely not a bad idea ;-) However, I am currently working on several issues for MX51. It should be nice to know which are your plans to save both some time ;-) Well, I am in a bit of a hurry, and essentially what I need is to be able to access SPI-nor flash (spansion type) for environment and booting linux. MMC/SD access would be nice, but is not yet necessary. Ok, quite the same. I have a ST flash, but we get the same problems, I see. I am just now picking up where I left last week, so give me a few hours and I should have something working, I guess. I know. I thought to do it in two steps: Fix mxc_spi.c with a workaround for the pmic driver (which amounts to '#define spi_xfer spi_xfer_fsl' at the beginning of this driver basically) and fix the pmic driver later, since it is probably not trivial, and needs to be done carefully (you know, one can smoke a board by mistake :-) I know, this makes funny setting voltages via software I always say: Electronics work on smoke. If the smoke escapes, it stops working :-) Best regards, -- David Jander Protonic Holland. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Use common function to set GPIOs for MX3 and MX5
On Monday 23 August 2010 10:50:53 am David Jander wrote: I am just now picking up where I left last week, so give me a few hours and I should have something working, I guess. Ok, I guess I was pessimistic. There is a weird bug in mxc_spi.c: CPOL is negated! I just saw that in the mx51evk.h header file CONFIG_FSL_PMIC_MODE was set to low-active clock (CPOL=1), which is not supposed to work. But it did work, and on the scope clock-polarity was active-high. In spi_cfg(), I saw this line: if (!(mode SPI_CPOL)) sclkpol = 1; AFAIK, this should be: if (mode SPI_CPOL) sclkpol = 1; At least for the MX51. Can you confirm that this is different on the MX31? Now I get a correct flash id. Best regards, -- David Jander Protonic Holland. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Use common function to set GPIOs for MX3 and MX5
David Jander wrote:
Hi again,
Hi David,
Are you sure? In arch/arm/lib/board.c function start_armboot(), init_sequence
is processed first, which contains env_init() before dram_init() and just
after completing init_sequence, mem_malloc_init() is called. How can you have
working malloc then?
Well, I tried to investigate to see if I get the same issue, env_init is
called before mem_malloc_init, but it does nothing (in env_sf.c):
int env_init(void)
{
/* SPI flash isn't usable before relocation */
gd-env_addr = (ulong)default_environment[0];
gd-env_valid = 1;
return 0;
}
And really I can see that mem_malloc_init() is called before
spi_setup_slave(). I guess there is a different configuration on our
targets, that makes the difference, but I do not know which one.
I don't know if that is possible. I know that physically RAM is initialized
before u-boot even starts (it runs from RAM), but logically, dram_init() is
called _after_ env_init(), so I'm not sure if you are supposed to call
mem_malloc_init() in env_init()...
Yes, but as I see env_init does not read from flash and does not call
spi_setup_flash(). This is done by env_relocate_spec(), but this
function is called later.
I am slowly progressing... now the transfer succeeds, but I only read FF ;-)
I think I have a good status now. I can correctly read/write the whole
flash. I have still an issue with saveenv (the first time does not work,
and it works after I called sf probe...crazy, but probably depends on
my target, I am investigating), but I should find a fix for that too.
A good point. I was following the premise that u-boot drivers should be
simple, but a little bit of speed for booting is surely not a bad idea ;-)
Even using the whole FIFO I need about 8 Seconds to read the whole Flash
(4 MB). In normal case, this means I need 3 Seconds for a kernel.
I am just now picking up where I left last week, so give me a few hours and I
should have something working, I guess.
Ok. We can make a point later. As I said, things are not so bad on my
target.
I always say: Electronics work on smoke. If the smoke escapes, it stops
working :-)
;-)))
Best regards,
Stefano
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Use common function to set GPIOs for MX3 and MX5
David Jander wrote: Ok, I guess I was pessimistic. There is a weird bug in mxc_spi.c: CPOL is negated! I just saw that in the mx51evk.h header file CONFIG_FSL_PMIC_MODE was set to low-active clock (CPOL=1), which is not supposed to work. But it did work, and on the scope clock-polarity was active-high. Ok In spi_cfg(), I saw this line: if (!(mode SPI_CPOL)) sclkpol = 1; AFAIK, this should be: if (mode SPI_CPOL) sclkpol = 1; At least for the MX51. Can you confirm that this is different on the MX31? Agree. According to the MX51 Manual, the register must be set with: 0 Active high polarity (0 = Idle). 1 Active low polarity (1 = Idle). So we need to change both CONFIG_FSL_PMIC_MODE in config and in mxc_spi.c. Do you send a patch or do you prefer I will do this job ? I will add your signed-off-by if you agree. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Use common function to set GPIOs for MX3 and MX5
Hi Stefano, On Monday 23 August 2010 12:37:16 pm Stefano Babic wrote: [...] In spi_cfg(), I saw this line: if (!(mode SPI_CPOL)) sclkpol = 1; AFAIK, this should be: if (mode SPI_CPOL) sclkpol = 1; At least for the MX51. Can you confirm that this is different on the MX31? Agree. According to the MX51 Manual, the register must be set with: 0 Active high polarity (0 = Idle). 1 Active low polarity (1 = Idle). I just checked in the reference manual of the i.MX31, and there the meaning of this bit has the same polarity as on the i.MX51, so you'll need to fix this also at the end of the spi_setup_slave() function, in the #else path of the #ifdef CONFIG_MX51 directive. if (!(mode SPI_CPOL)) ctrl_reg |= MXC_CSPICTRL_POL; should be: if (mode SPI_CPOL) ctrl_reg |= MXC_CSPICTRL_POL; Would be nice if someone with a MX31 board could verify this. So we need to change both CONFIG_FSL_PMIC_MODE in config and in mxc_spi.c. Do you send a patch or do you prefer I will do this job ? I will add your signed-off-by if you agree. I agree, and I guess you can better include it in your patch-set, otherwise I'd have to wait for your patches and then provide my own patch on top of that too complicated :-) I am also adding support for S25FL032P chips to the spansion driver. Will post a patch later. Right now I have correct detection of the chip, but the environment is not saved and read back correctly. Still investigating... maybe some chip configuration prolem in the spansion driver? Best regards, -- David Jander Protonic Holland. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Use common function to set GPIOs for MX3 and MX5
David Jander wrote: Hi Stefano, Hi David, I just checked in the reference manual of the i.MX31, and there the meaning of this bit has the same polarity as on the i.MX51, so you'll need to fix this also at the end of the spi_setup_slave() function, in the #else path of the #ifdef CONFIG_MX51 directive. if (!(mode SPI_CPOL)) ctrl_reg |= MXC_CSPICTRL_POL; should be: if (mode SPI_CPOL) ctrl_reg |= MXC_CSPICTRL_POL; Would be nice if someone with a MX31 board could verify this. I can test myself on a qong board - I hope someone else can test on other MX.31 boards. I agree, and I guess you can better include it in your patch-set, otherwise I'd have to wait for your patches and then provide my own patch on top of that too complicated :-) I will do it - I think I could send in a short time the whole patchset for review :-). I am also adding support for S25FL032P chips to the spansion driver. Will post a patch later. I have seen. However, it should be better if you send the patch also to the maintainer for the MTD subsystem (Stefan Roese, I set his address in CC). Right now I have correct detection of the chip, but the environment is not saved and read back correctly. Still investigating... maybe some chip configuration prolem in the spansion driver? Probably. I have got some issues with the ST that do not depend from the modifications in SPI driver. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Use common function to set GPIOs for MX3 and MX5
On Monday 23 August 2010 17:55:44 Stefano Babic wrote: I am also adding support for S25FL032P chips to the spansion driver. Will post a patch later. I have seen. However, it should be better if you send the patch also to the maintainer for the MTD subsystem (Stefan Roese, I set his address in CC). Small correction: I'm not the custodian of the MTD subsystem, but of the CFI flash driver (amongst others). And I have never really taken care of the SPI flash patches before (and never used one of those drivers before). IIRC, then Mike (added to Cc) has the most insight here. Cheers, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Use common function to set GPIOs for MX3 and MX5
Hi Stefan, On Monday 23 August 2010 17:55:44 Stefano Babic wrote: I am also adding support for S25FL032P chips to the spansion driver. Will post a patch later. I have seen. However, it should be better if you send the patch also to the maintainer for the MTD subsystem (Stefan Roese, I set his address in CC). Small correction: I'm not the custodian of the MTD subsystem, but of the CFI flash driver (amongst others). And I have never really taken care of the SPI flash patches before (and never used one of those drivers before). IIRC, then Mike (added to Cc) has the most insight here. In fact I cannot see that you extended the CC list. Wanna have another go? ;) Cheers Detlev -- Paul Simon sang Fifty Ways to Lose Your Lover, because quite frankly, A Million Ways to Tell a Developer He Is a D*ckhead doesn't scan nearly as well. But I'm sure he thought about it. -- linux/Documentation/ManagementStyle -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Use common function to set GPIOs for MX3 and MX5
On Monday, August 23, 2010 17:03:24 Detlev Zundel wrote: Hi Stefan, On Monday 23 August 2010 17:55:44 Stefano Babic wrote: I am also adding support for S25FL032P chips to the spansion driver. Will post a patch later. I have seen. However, it should be better if you send the patch also to the maintainer for the MTD subsystem (Stefan Roese, I set his address in CC). Small correction: I'm not the custodian of the MTD subsystem, but of the CFI flash driver (amongst others). And I have never really taken care of the SPI flash patches before (and never used one of those drivers before). IIRC, then Mike (added to Cc) has the most insight here. In fact I cannot see that you extended the CC list. Wanna have another go? ;) i did since he added me to the cc ... but as David said, he posted a sep patch, so i'll stick to that thread. i generally delete threads about parts i dont care about (like whatever a MX3 and MX5 are). -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Use common function to set GPIOs for MX3 and MX5
On Friday 20 August 2010 10:20:11 am Stefano Babic wrote: The patch adds support for setting gpios to the MX51 processor and change name to the corresponding functions for MX31. In this way, it is possible to get rid of nasty #ifdef switches related to the processor type. Argh! I was just writing the exact same code as in this patch :-( Thanks a lot anyway. Best regards, -- David Jander Protonic Holland. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Use common function to set GPIOs for MX3 and MX5
Hi Stefano,
On Friday 20 August 2010 10:20:11 am Stefano Babic wrote:
diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c
index e15a63c..54af2e3 100644
--- a/drivers/spi/mxc_spi.c
+++ b/drivers/spi/mxc_spi.c
@@ -23,6 +23,7 @@
#include spi.h
#include asm/errno.h
#include asm/io.h
+#include mxc_gpio.h
#ifdef CONFIG_MX27
/* i.MX27 has a completely wrong register layout and register definitions
in the @@ -68,9 +69,6 @@ static unsigned long spi_bases[] = {
0x53f84000,
};
-#define OUT MX31_GPIO_DIRECTION_OUT
-#define mxc_gpio_direction mx31_gpio_direction
-#define mxc_gpio_set mx31_gpio_set
#elif defined(CONFIG_MX51)
#include asm/arch/imx-regs.h
#include asm/arch/clock.h
@@ -111,13 +109,12 @@ static unsigned long spi_bases[] = {
CSPI2_BASE_ADDR,
CSPI3_BASE_ADDR,
};
-#define mxc_gpio_direction(gpio, dir)(0)
-#define mxc_gpio_set(gpio, value){}
-#define OUT 1
After this change, it seems something else is missing:
GCC somehow removed the following code for i.MX51 without actually compiling
the arguments to the functions (???), but now it becomes evident this only
compiles for i.MX31:
void spi_cs_activate(struct spi_slave *slave)
{
struct mxc_spi_slave *mxcs = to_mxc_spi_slave(slave);
if (mxcs-gpio 0)
mxc_gpio_set(mxcs-gpio, mxcs-ctrl_reg MXC_CSPICTRL_SSPOL);
}
void spi_cs_deactivate(struct spi_slave *slave)
{
struct mxc_spi_slave *mxcs = to_mxc_spi_slave(slave);
if (mxcs-gpio 0)
mxc_gpio_set(mxcs-gpio,
!(mxcs-ctrl_reg MXC_CSPICTRL_SSPOL));
}
On i.MX51 SSPOL is set in the config register, and per SS individually.
Therefore, MXC_CSPICTRL_SSPOL isn't defined for i.MX51.
Best regards,
--
David Jander
Protonic Holland.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Use common function to set GPIOs for MX3 and MX5
David Jander wrote:
Hi Stefano,
Hi David,
After this change, it seems something else is missing:
GCC somehow removed the following code for i.MX51 without actually compiling
the arguments to the functions (???), but now it becomes evident this only
compiles for i.MX31:
Understood, in SPI driver. Really I had another patch in my private
tree, but I have not yet sent. However, as you note, it makes no sense
to split changes in two patches.
I will rebase my tree and send V2 version of the pacth, inclusive the
changes for mxc_spi.c
void spi_cs_activate(struct spi_slave *slave)
{
struct mxc_spi_slave *mxcs = to_mxc_spi_slave(slave);
if (mxcs-gpio 0)
mxc_gpio_set(mxcs-gpio, mxcs-ctrl_reg MXC_CSPICTRL_SSPOL);
I know, I had already change this code...I store ss_pol in the priivate
structure to be independent from the processor register.
I will send the compound patch soon.
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Use common function to set GPIOs for MX3 and MX5
Stefano,
On Friday 20 August 2010 12:01:00 pm Stefano Babic wrote:
After this change, it seems something else is missing:
GCC somehow removed the following code for i.MX51 without actually
compiling the arguments to the functions (???), but now it becomes
evident this only compiles for i.MX31:
Understood, in SPI driver. Really I had another patch in my private
tree, but I have not yet sent. However, as you note, it makes no sense
to split changes in two patches.
I will rebase my tree and send V2 version of the pacth, inclusive the
changes for mxc_spi.c
Ok, thanks!
void spi_cs_activate(struct spi_slave *slave)
{
struct mxc_spi_slave *mxcs = to_mxc_spi_slave(slave);
if (mxcs-gpio 0)
mxc_gpio_set(mxcs-gpio, mxcs-ctrl_reg MXC_CSPICTRL_SSPOL);
I know, I had already change this code...I store ss_pol in the priivate
structure to be independent from the processor register.
I will send the compound patch soon.
Great. I'll wait.
In the meantime I have just done this to get it working:
#ifdef CONFIG_MX31
void spi_cs_activate(struct spi_slave *slave)
{
struct mxc_spi_slave *mxcs = to_mxc_spi_slave(slave);
if (mxcs-gpio 0)
mxc_gpio_set(mxcs-gpio, mxcs-ctrl_reg MXC_CSPICTRL_SSPOL);
}
void spi_cs_deactivate(struct spi_slave *slave)
{
struct mxc_spi_slave *mxcs = to_mxc_spi_slave(slave);
if (mxcs-gpio 0)
mxc_gpio_set(mxcs-gpio,
!(mxcs-ctrl_reg MXC_CSPICTRL_SSPOL));
}
#elif defined (CONFIG_MX51)
void spi_cs_activate(struct spi_slave *slave)
{
struct mxc_spi_slave *mxcs = to_mxc_spi_slave(slave);
unsigned int val = mxcs-cfg_reg
(1 (slave-cs + MXC_CSPICON_SSPOL));
if (mxcs-gpio 0)
mxc_gpio_set(mxcs-gpio, val);
}
void spi_cs_deactivate(struct spi_slave *slave)
{
struct mxc_spi_slave *mxcs = to_mxc_spi_slave(slave);
unsigned int val = !(mxcs-cfg_reg
(1 (slave-cs + MXC_CSPICON_SSPOL)));
if (mxcs-gpio 0)
mxc_gpio_set(mxcs-gpio, val);
}
#endif
Seems to work, but never mind...
Best regards,
--
David Jander
Protonic Holland.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Use common function to set GPIOs for MX3 and MX5
David Jander wrote:
Great. I'll wait.
In the meantime I have just done this to get it working:
#ifdef CONFIG_MX31
void spi_cs_activate(struct spi_slave *slave)
{
struct mxc_spi_slave *mxcs = to_mxc_spi_slave(slave);
if (mxcs-gpio 0)
mxc_gpio_set(mxcs-gpio, mxcs-ctrl_reg MXC_CSPICTRL_SSPOL);
}
Ok, but one goal I have is to get rid of nasty #ifdef CONFIG_MX*. I
introduce general gpio functions to make code more common, and I do not
want to fall back adding processor switches.
Seems to work, but never mind...
Ok, I will resend my patch, I hope you can give a chance a test it on
your target.
Best regards,
Stefano
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Use common function to set GPIOs for MX3 and MX5
David Jander wrote: Absolutely right. I just posted it as reference for your patch eventually, not because I thought it was good that way. Yes, I know. I want only to point out what we have to reach ;-) Seems to work, but never mind... Ok, I will resend my patch, I hope you can give a chance a test it on your target. Will do. Btw, do you have any idea why spi_xchg_single() hangs while transmitting the second word without claiming the bus again? Can you see where does it hang ? Which device is connected to your SPI bus ? Does it work with the pmic (I think so, see later...). Also, I don't know if you already fixed mxc_spi.c, to use the correct byte- ordering when sending u8 buffers. Well, it seems we are working at the same issues, and probably it is better if we try some coordination ;-) I have already fix the byte ordering, but I am fixing now the misaligned access (this is the reason I have not sent the changes for gpios in the mxc_spi.c: I am reworking this driver...). In the mainline driver, only 32-bit aligned buffers are allowed, and this is a strong limitation. I cannot use some other components in u-boot, such as SPI flash, because the code allocates u8 buffers that can be disaligned. And with other devices (sensors, eeprom, ...) does not work, because most of them require to transfer only one or two bytes as command. Now that I think...is it maybe your case now ? The FIFO can be accessed only as word, other accesses are not allowed according to the manual. However, I am currently working on several issues for MX51. It should be nice to know which are your plans to save both some time ;-) I have a fix, but it is not yet ready. I essentially renamed spi_xfer() to spi_xfer_fsl(), to be used in the (broken) pmic driver, As I said, I changed the pmic driver, too. I do not agree we must have special functions, only because something is broken. The pmic works because it is connected to the FSL SPI controller, and the endianess is consistent. However, it is common for a SPI driver to allocate a char buffer, and the first byte in the buffer is the first byte sent to the SPI bus. This is not the case with mxc_spi.c Regards, Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Use common function to set GPIOs for MX3 and MX5
Hi Stefano,
On Friday 20 August 2010 01:19:28 pm Stefano Babic wrote:
Will do.
Btw, do you have any idea why spi_xchg_single() hangs while transmitting
the second word without claiming the bus again?
Can you see where does it hang ? Which device is connected to your SPI
bus ? Does it work with the pmic (I think so, see later...).
Just figured out one big mistake. I was debugging spi_flash.c, and had
CONFIG_ENV_IS_IN_SPI_FLASH set. That means, first SPI access is done before
malloc is available, and guess what? spi_setup_slave() uses malloc ;-)
So I did something in the way of this:
static struct mxc_spi_slave mxc_spi_slave_pool[4];
struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs,
unsigned int max_hz, unsigned int mode)
{
unsigned int ctrl_reg;
struct mxc_spi_slave *mxcs;
int ret;
if (bus = ARRAY_SIZE(spi_bases))
return NULL;
//mxcs = malloc(sizeof(struct mxc_spi_slave));
//if (!mxcs)
// return NULL;
mxcs = mxc_spi_slave_pool[cs];
The C++ comments show original code, the line below is new.
It still hangs though, waiting for MXC_CSPICTRL_TC to become active. Busy
finding out why...
I see a one byte access followed by a 5 byte access, of which only 8.5 clock
pulses come out of SCLK, and then nothing more. MXC_CSPICTRL_TC stays low.
Also, I don't know if you already fixed mxc_spi.c, to use the correct
byte- ordering when sending u8 buffers.
Well, it seems we are working at the same issues, and probably it is
better if we try some coordination ;-)
Good idea.
I have already fix the byte ordering, but I am fixing now the misaligned
access (this is the reason I have not sent the changes for gpios in the
mxc_spi.c: I am reworking this driver...). In the mainline driver, only
32-bit aligned buffers are allowed, and this is a strong limitation. I
cannot use some other components in u-boot, such as SPI flash, because
the code allocates u8 buffers that can be disaligned. And with other
devices (sensors, eeprom, ...) does not work, because most of them
require to transfer only one or two bytes as command.
I assumed that u-boot spi drivers use only u8 buffers for simplicity.
So my fix looks as this:
int spi_xfer(struct spi_slave *slave, unsigned int bitlen, const void *dout,
void *din, unsigned long flags)
{
int n_blks = (bitlen + 31) / 32;
u32 out, in;
u8 *in_b, *out_b;
int i;
out_b = (u8 *)dout;
in_b = (u8 *)din;
for(i = 0; i n_blks; i++, bitlen -= 32) {
if(dout) {
out = out_b[0];
if(bitlen 8)
out = (out8) | out_b[1];
if(bitlen 16)
out = (out8) | out_b[2];
if(bitlen 24)
out = (out8) | out_b[3];
out_b += 4;
} else {
out=0;
}
in = spi_xchg_single(slave, out, bitlen, flags);
if(din) {
if(bitlen 24) {
in_b[3] = in 0xff;
in = 8;
}
if(bitlen 16) {
in_b[2] = in 0xff;
in = 8;
}
if(bitlen 8) {
in_b[1] = in 0xff;
in = 8;
}
in_b[0] = in 0xff;
in_b += 4;
}
}
return 0;
}
Does this sound like it could work?
Now that I think...is it maybe your case now ? The FIFO can be accessed
only as word, other accesses are not allowed according to the manual.
I am aware of that. That's why I used spi_xchg_single() as is.
However, I am currently working on several issues for MX51. It should be
nice to know which are your plans to save both some time ;-)
Well, I am in a bit of a hurry, and essentially what I need is to be able to
access SPI-nor flash (spansion type) for environment and booting linux.
MMC/SD access would be nice, but is not yet necessary.
I have a fix, but it is not yet ready.
I essentially renamed spi_xfer() to spi_xfer_fsl(), to be used in the
(broken) pmic driver,
As I said, I changed the pmic driver, too. I do not agree we must have
special functions, only because something is broken. The pmic works
because it is connected to the FSL SPI controller, and the endianess is
consistent. However, it is common for a SPI driver to allocate a char
buffer, and the first byte in the buffer is the first byte sent to the
SPI bus. This is not the case with mxc_spi.c
I know. I thought to do it in two steps: Fix mxc_spi.c with
Re: [U-Boot] [PATCH] Use common function to set GPIOs for MX3 and MX5
David Jander wrote:
Hi Stefano,
Hi David,
On Friday 20 August 2010 01:19:28 pm Stefano Babic wrote:
Will do.
Btw, do you have any idea why spi_xchg_single() hangs while transmitting
the second word without claiming the bus again?
Can you see where does it hang ? Which device is connected to your SPI
bus ? Does it work with the pmic (I think so, see later...).
Just figured out one big mistake. I was debugging spi_flash.c, and had
CONFIG_ENV_IS_IN_SPI_FLASH set. That means, first SPI access is done before
malloc is available, and guess what? spi_setup_slave() uses malloc ;-)
I have CONFIG_ENV_IS_IN_SPI_FLASH set, too.
I try to figure out how the functions are called, but I do not get the
same issue. I set with the debugger two breakpoints, one in
mem_malloc_init and the second one in spi_setup_slave. I see that
mem_alloc_init is hit first, and when spi_setup_slave is called, malloc
is available. I get a valid pointer for the private structure. It seems
there something in our config files that makes the things different. I
do not yet know why.
The C++ comments show original code, the line below is new.
Understood, if malloc is not called, we have to use static or (better)
try to call mem_malloc_init() first
I see a one byte access followed by a 5 byte access,
That is correct, you see the code in spi_flash.c. First the ID command
is sent (0x97), without reading nothing (that is, din is NULL). Then the
answer is read (dout is NULL), and the id buffer is 5 bytes long.
I assumed that u-boot spi drivers use only u8 buffers for simplicity.
So my fix looks as this:
int spi_xfer(struct spi_slave *slave, unsigned int bitlen, const void *dout,
void *din, unsigned long flags)
{
int n_blks = (bitlen + 31) / 32;
u32 out, in;
u8 *in_b, *out_b;
int i;
out_b = (u8 *)dout;
in_b = (u8 *)din;
for(i = 0; i n_blks; i++, bitlen -= 32) {
if(dout) {
out = out_b[0];
if(bitlen 8)
out = (out8) | out_b[1];
if(bitlen 16)
out = (out8) | out_b[2];
if(bitlen 24)
out = (out8) | out_b[3];
out_b += 4;
} else {
out=0;
}
in = spi_xchg_single(slave, out, bitlen, flags);
if(din) {
if(bitlen 24) {
in_b[3] = in 0xff;
in = 8;
}
if(bitlen 16) {
in_b[2] = in 0xff;
in = 8;
}
if(bitlen 8) {
in_b[1] = in 0xff;
in = 8;
}
in_b[0] = in 0xff;
in_b += 4;
}
}
return 0;
}
Does this sound like it could work?
I am trying another approach. As the MX51 has 32 bytes FIFO, it makes
sense to use it and not send a single word, if we can. This must not
change the behavior for the MX31, because this processor has no FIFO and
a single word can be sent.
So I replaced completely spi_xfer, and the logic you put in spi_xfer I
have (more or less, I have not checked in details) moved inside the
spi_xcgh:single, that now has the meaning for me as single transation:
up to 1 word for i.MX31, up to 32 words (128 bytes) for i.MX51.
Take into account that loading the kernel using a single word takes a
lot of time..
However, I am currently working on several issues for MX51. It should be
nice to know which are your plans to save both some time ;-)
Well, I am in a bit of a hurry, and essentially what I need is to be able to
access SPI-nor flash (spansion type) for environment and booting linux.
MMC/SD access would be nice, but is not yet necessary.
Ok, quite the same. I have a ST flash, but we get the same problems, I see.
I know. I thought to do it in two steps: Fix mxc_spi.c with a workaround for
the pmic driver (which amounts to '#define spi_xfer spi_xfer_fsl' at the
beginning of this driver basically) and fix the pmic driver later, since it
is
probably not trivial, and needs to be done carefully (you know, one can smoke
a board by mistake :-)
I know, this makes funny setting voltages via software
Best regards,
Stefano
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de
=
___
U-Boot mailing list
