[meta-xilinx] u-boot Commit 81ec69066b270c62a6468662314728cc8b7008f9 breaks SPL
Mike Looijmans
mike.looijmans at topic.nl
Tue Jan 19 04:08:19 PST 2016
On 19-01-16 10:30, Mike Looijmans wrote:
> 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.
>
This did deliver a "boot.bin" and "u-boot.img" (current master u-boot). Put
them on a card, and the SPL part seems to work (it got a LOT bigger though)
but the second part is a no-go, all I get is:
U-Boot SPL 2016.01 (Jan 19 2016 - 11:47:48)
mmc boot
Trying to boot from MMC
reading u-boot.img
reading u-boot.img
So it looks like I got all the SPL bits in place. Something is not quite right
for the second stage though...
The boot.bin is now >64k and because the previous versions were only 45k in
size, I only reserved 64k for it, so I can't test it on QSPI until I've
trimmed it down a bit.
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
More information about the meta-xilinx
mailing list