[U-Boot] [PATCH] Use common function to set GPIOs for MX3 and MX5

[David Jander]

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.