[U-Boot] [PATCH v4 14/20] mtd: spi: Switch to new SPI NOR framework

[Vignesh R]

On 13/02/19 1:54 AM, Adam Ford wrote:
> On Tue, Feb 12, 2019 at 1:20 PM Adam Ford <aford173 at gmail.com> wrote:
>>
>> On Sun, Feb 10, 2019 at 10:37 PM Vignesh R <vigneshr at ti.com> wrote:
>>>
>>>
>>>
>>> On 11/02/19 9:01 AM, Adam Ford wrote:
>>>> On Tue, Feb 5, 2019 at 12:00 AM Vignesh R <vigneshr at ti.com> wrote:
>>>>>
>>>>> Switch spi_flash_* interfaces to call into new SPI NOR framework via MTD
>>>>> layer. Fix up sf_dataflash to work in legacy way. And update sandbox to
>>>>> use new interfaces/definitions
>>>>>
>>>>> Signed-off-by: Vignesh R <vigneshr at ti.com>
>>>>> Tested-by: Simon Goldschmidt <simon.k.r.goldschmidt at gmail.com>
>>>>> Tested-by: Stefan Roese <sr at denx.de>
>>>>> Tested-by: Horatiu Vultur <horatiu.vultur at microchip.com>
>>>>> Reviewed-by: Jagan Teki <jagan at openedev.com>
>>>>> Tested-by: Jagan Teki <jagan at amarulasolutions.com> #zynq-microzed
>>>>
>>>> This patch appears to break the da850_evm board which boots from SPI
>>>> Flash and initializes the davinci driver with platdata since the
>>>> device tree stuff does not quite work right in SPL.
>>>
>>> Oops, I did test on K2G EVM that has davinci SPI controller with micron
>>> n25q flash but that was with DT. Not sure whats missing with platdata.
>>>
>>>>
>>>> U-Boot SPL 2019.01-02923-gc4e8862308-dirty (Feb 10 2019 - 21:24:38 -0600)
>>>> Trying to boot from SPI
>>>> SPI probe failed.
>>>> SPL: failed to boot from all boot devices
>>>> ### ERROR ### Please RESET the board ###
>>>
>>> Could you enable debug prints at spi-mem level in drivers/spi/spi-mem.c
>>> (especially debug prints at the end of spi_mem_exec_op()) and post the
>>> logs here?
>>>
>>>>
>>>> Any suggestions on how to fix the SPI initialization without needing
>>>> the device tree?  I have tried to port the device tree stuff to SPL,
>>>> but I haven't yet been successful so I have had to leave the platdata
>>>> initialization in place.
>>>>
>>>
>>> I haven't changed any driver names so, platdata to driver bindings
>>> should still be the same. Could you verify if spi_nor_scan() is being
>>> called in drivers/mtd/spi/spi-nor-tiny.c for SPL?
>>
>> I globally turned on DEBUG and I have two logs for you:
>>
>> Not working:
>>
>> U-Boot SPL 2019.01-02923-gc4e8862308-dirty (Feb 12 2019 - 13:04:19 -0600)
>> Trying to boot from SPI
>> uclass_find_device_by_seq: 0 -1
>> uclass_find_device_by_seq: 0 0
>>    - -1 -1 'davinci_spi'
>>    - not found
>> spi_get_bus_and_cs: Binding new device 'spi_flash', busnum=0, cs=0,
>> driver=spi_flash_std
>> spi_get_bus_and_cs: Error path, created=1, device 'spi_flash'
>> SPI probe failed.
>> SPL: failed to boot from all boot devices
>> ### ERROR ### Please RESET the board ###
>>
>> As a point of reference , I thought I'd show
>> WORKING version (before this patch):
>>
>> U-Boot SPL 2019.01-02922-g2ee6705be0-dirty (Feb 12 2019 - 12:59:49 -0600)
>> Trying to boot from SPI
>> uclass_find_device_by_seq: 0 -1
>> uclass_find_device_by_seq: 0 0
>>    - -1 -1 'davinci_spi'
>>    - not found
>> spi_get_bus_and_cs: Binding new device 'spi_flash', busnum=0, cs=0,
>> driver=spi_flash_std
>> uclass_find_device_by_seq: 0 -1
>> uclass_find_device_by_seq: 0 0
>>    - -1 -1 'spi_flash'
>>    - not found
>> spi_flash_std_probe: slave=8001fd60, cs=0
>> davinci_spi_set_speed speed 30000000
>> davinci_spi_set_mode mode 3
>> davinci_spi_set_speed speed 30000000
>> davinci_spi_set_mode mode 3
>> spi_get_bus_and_cs: bus=8001fbf4, slave=8001fd60
>> SPL: payload image: U-Boot 2019.01-02922-g2ee6705be0   load addr:
>> 0xc107ffc0 size: 405306
>> Jumping to U-Boot
>> loaded - jumping to U-Boot...
>> image entry point: 0xc1080000
>> ...
>>
>> During this process, I learned a few things.
>> 1.  I am not really using the device tree during SPL like i originally
>> thought and the OF_PLATDATA
>> 2.  Getting SPL to support device tree with or without PLATDATA isn't
>> as straightforward as I hoped
>> 3.  With the knowledge I learned from item 1, I tried to disabled
>> OF_CONTROL during SPL, but this patch also fails to build since it
>> assumes OF_CONTROL is always enabled.
>>
>> If there are any suggestions you might have, I am willing to try them.
>>
> 
> I beleive I have narrowed it down a bit to a chunk of code (int
> device_probe(struct udevice *dev)) located in device.c:
> 
> /* Allocate private data if requested and not reentered */
> if (drv->priv_auto_alloc_size && !dev->priv) {
> dev->priv = alloc_priv(drv->priv_auto_alloc_size, drv->flags);
> if (!dev->priv) {
> printf("Allocate private data if requested and not reentered\n");
> ret = -ENOMEM;
> goto fail;
> }
> }
> 
> I am not sure how the sizes are defined and/or allocated

priv_auto_alloc_size is determined by:
drivers/mtd/spi/sf_probe.c:180: .priv_auto_alloc_size = sizeof(struct spi_flash),

Allocation is done at:
./drivers/core/device.c::alloc_priv()
If you are seeing -ENOMEM, it looks calloc() maybe failing in above function.

Could you increase available size of malloc in SPL to a higher value.
I believe you are using da850evm_defconfig. If so, could you change

CONFIG_SPL_SYS_MALLOC_F_LEN=0x800 or higher and see if that helps?


Regards
Vignesh


-- 
Regards
Vignesh