On 13/02/19 1:54 AM, Adam Ford wrote:
> On Tue, Feb 12, 2019 at 1:20 PM Adam Ford <aford...@gmail.com> wrote:
>>
>> On Sun, Feb 10, 2019 at 10:37 PM Vignesh R <vigne...@ti.com> wrote:
>>>
>>>
>>>
>>> On 11/02/19 9:01 AM, Adam Ford wrote:
>>>> On Tue, Feb 5, 2019 at 12:00 AM Vignesh R <vigne...@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 <vigne...@ti.com>
>>>>> Tested-by: Simon Goldschmidt <simon.k.r.goldschm...@gmail.com>
>>>>> Tested-by: Stefan Roese <s...@denx.de>
>>>>> Tested-by: Horatiu Vultur <horatiu.vul...@microchip.com>
>>>>> Reviewed-by: Jagan Teki <ja...@openedev.com>
>>>>> Tested-by: Jagan Teki <ja...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
