[meta-xilinx] u-boot Commit 81ec69066b270c62a6468662314728cc8b7008f9 breaks SPL

[Mike Looijmans]

On 19-01-16 10:16, Nathan Rossi wrote:
> On Tue, Jan 19, 2016 at 7:05 PM, Michal Simek <michal.simek at xilinx.com> wrote:
>> On 19.1.2016 09:07, Mike Looijmans wrote:
>>> On 19-01-16 08:46, Michal Simek wrote:
>>>> On 18.1.2016 13:59, Mike Looijmans wrote:
>>>>> On 18-01-16 13:51, Nathan Rossi wrote:
>>>>>> On Mon, Jan 18, 2016 at 9:45 PM, Mike Looijmans
>>>>>> <mike.looijmans at topic.nl> wrote:
>>>>>>> On 18-01-16 11:59, Nathan Rossi wrote:
>>>>>>>>
>>>>>>>> On Mon, Jan 18, 2016 at 8:43 PM, Mike Looijmans
>>>>>>>> <mike.looijmans at topic.nl>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> I just tried with current xilinx/master u-boot.
>>>>>>>>>
>>>>>>>>> QSPI support is still broken.
>>>>>>>>>
>>>>>>>>> This makes the current bootloader useless, we ALWAYS boot from QSPI.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Any news on this front? Anything we can do?
>>>>>>>>
>>>>>>>>
>>>>>>>> Try u-boot mainline master, it has fixes for QSPI booting. I have it
>>>>>>>> working well on the Zybo, but the fixes were not specific to that
>>>>>>>> board.
>>>>>>>
>>>>>>>
>>>>>>> That's what I did. QSPI works, but it's broken in SPL.
>>>>>>>
>>>>>>> So you can boot from SD and access the QSPI flash, but you cannot
>>>>>>> boot from
>>>>>>> QSPI flash.
>>>>>>
>>>>>> Ok, so I am a little confused, is it that SPL does not boot when using
>>>>>> QSPI (aka SPL never starts)? or is the issue that QSPI does not work
>>>>>> from within SPL aka it fails to load the image(s) from the flash?
>>>>>
>>>>> The latter. It loads the SPL code, and then bails out with "invalid boot
>>>>> mode" because it cannot read the QSPI from within the SPL.
>>>>>
>>>>>> Also which board are you using out of curiosity?
>>>>>
>>>>> topic-miami
>>>>>
>>>>> It's not in your list, but the QSPI is connected in the same way as the
>>>>> Zed.
>>>>>
>>>>>> you wouldn't happen
>>>>>> to be using the zedboard? I just noticed that it is missing the
>>>>>> u-boot,dm-pre-reloc for the qspi node in the device tree in u-boot,
>>>>>> which is needed (see
>>>>>> http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/dts/zynq-zybo.dts;h=fbbb8911910bcd1905f60811aa582966f16b3133;hb=HEAD
>>>>>>
>>>>>>
>>>>>> vs
>>>>>> http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/dts/zynq-zed.dts;h=5ec59e2b4c6fdcf5deec58bd4d04effa2c094704;hb=HEAD).
>>>>>>
>>>>>>
>>>>>
>>>>> Ah, wait... You're talking about u-boot from denx.de. I didn't know that
>>>>> the Xilinx code had already merged into that. I was looking at the
>>>>> u-boot-xlnx repository.
>>>>>
>>>>> In that case, no I haven't tried current master yet. Will do.
>>>>>
>>>>> I might want to put some effort into mainlining our u-boot code for the
>>>>> board then.
>>>>
>>>> Xilinx tree is not that far from mainline.
>>>>
>>>
>>> Okay, just to get things clear:
>>>
>>>
>>> SHOULD u-boot SPL be able to boot from QSPI with current master on the
>>> u-boot-xlnx repo? In other words, does it work with other boards?
>>>
>>>
>>> I mean, is there something that I missed in my code and should I fix it
>>> myself, of is the SPL support for QSPI still broken as it was after the
>>> aforementioned commit?
>>>
>>
>> I don't think it is working. But it should work when I push upgrade to
>> 2016.01
>
> Note though that 2016.01 does not include the SPL_DM_ALIAS patches
> which are needed for QSPI flash.
>
> http://git.denx.de/?p=u-boot.git;a=commit;h=4f627c5a59f4f69df156c199d6238849f26fe9af
> http://git.denx.de/?p=u-boot.git;a=commit;h=5c9b1d735ea782c2d0ad97496d74cb1fdd27c2d9
>

I'm currently attempting at using the "master" and these two are already in there.

However, I cannot get it to compile, I get this:

drivers/serial/serial-uclass.c:27:2: error: #error "Serial is required before 
relocation - define CONFIG_SYS_MALLOC_F_LEN to make this work"


Looking at what other boards do, adding "CONFIG_SYS_MALLOC_F_LEN=0x2000" to my 
defconfig might satisfy that, but apparently doesn't because that doesn't even 
make the error go away.

Strangely, defining it in the board's config.h does make the error go away. 
But no other board does it like that.



Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijmans at topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail