[U-Boot] [PATCH 12/13] armv7: support rk3066 early back to bootrom in start.S

[Paweł Jarosz]

W dniu 15.06.2017 o 18:00, Simon Glass pisze:
> (just repeating other thread for completeness)
>
> On 15 June 2017 at 09:42, Paweł Jarosz <paweljarosz3691 at gmail.com> wrote:
>>
>> W dniu 15.06.2017 o 16:50, Simon Glass pisze:
>>
>>> + Some other rockchip people
>>>
>>> Hi Pawel,
>>>
>>> On 15 June 2017 at 01:15, Paweł Jarosz <paweljarosz3691 at gmail.com> wrote:
>>>> Hi Simon
>>>>
>>>>
>>>> W dniu 14.06.2017 o 13:06, Simon Glass pisze:
>>>>
>>>> +Philippe
>>>>
>>>> Hi Pawel,
>>>>
>>>> On 12 June 2017 at 17:50, Simon Glass <sjg at chromium.org> wrote:
>>>>
>>>> Hi Pawel,
>>>>
>>>> On 9 June 2017 at 06:31, Paweł Jarosz <paweljarosz3691 at gmail.com> wrote:
>>>>
>>>> W dniu 09.06.2017 o 13:46, Heiko Stuebner pisze:
>>>>
>>>> Am Mittwoch, 7. Juni 2017, 17:37:13 CEST schrieb Paweł Jarosz:
>>>>
>>>> Hi Simon,
>>>>
>>>>
>>>> W dniu 06.06.2017 o 23:10, Simon Glass pisze:
>>>>
>>>> Hi Pawel,
>>>>
>>>> On 6 June 2017 at 12:53, Paweł Jarosz <paweljarosz3691 at gmail.com> wrote:
>>>>
>>>> Rockchip bootrom first reads 1KB data from nand at offset 0x10080C00
>>>> and
>>>> executes it. Then waits for back to bootrom and loads another 32KB to
>>>> sram
>>>> which also executes. Sdram initialisation code needs to be in one of
>>>> these two
>>>> steps. Then bootloader loads another ~200KB of data at offset
>>>> 0x60000000
>>>> and jumps to it.
>>>>
>>>> 32KB of data is a little low for tpl + spl part and ~200KB data is to
>>>> low for
>>>> u-boot part(for example to boot from mmc you need to disable usb
>>>> support.
>>>>
>>>> My solution to size problem is to move sdram initialisation code to tpl
>>>> stage,
>>>> move spl part to third stage(reading 200KB data) and add support for
>>>> loading
>>>> u-boot by spl from ext2/4, fat partitions.
>>>>
>>>> But moving sdram initialisation code to tpl increases size of tpl above
>>>> 1KB
>>>> (first boot stage). Solution to this is to add code which will be below
>>>> 1KB
>>>> offset in tpl binary and do back to bootrom at very beginning of the
>>>> tpl
>>>> execution.
>>>>
>>>> So do you mean that TPL starts and then loads more of itself? Why not
>>>> put SDRAM init in SPL? You say above that 32KB is 'too low', but It's
>>>> not clear why.
>>>>
>>>> Ad.1 No. Tpl starts and at the first execution returns to bootrom.
>>>> Bootrom then loads
>>>> rest of the tpl (31KB) and executes it for a second time.
>>>>
>>>> Ad.2,3 Due to size issues (200KB limit) i needed to move main u-boot to
>>>> mmc. To load u-boot from
>>>> mmc by SPL (there is 32KB bootrom limit, not enough space for mmc
>>>> support) i moved SPL to sdram.
>>>> Code executed in sdram can't mess with sdram settings because it will
>>>> hang the board. Sdram setup
>>>> needs to be done by code in SRAM (tpl).
>>>>
>>>> At least the rk3288-Firefly was able to also have mmc stack in the SPL in
>>>> the past, without requiring the back_to_bootrom at all. So question would
>>>> be why this doesn't fit anymore, or on the rk3066 specifically.
>>>>
>>>> Also, it seems like I got my hands on a preliminary (linux/mtd) nand
>>>> driver
>>>> (rk3228 but cursory glance at the registers suggests that it may actually
>>>> work on previous socs down to the rk3066 as well) and it may be possible
>>>> to adapt that for uboot, therefore making the spl able to also load the
>>>> full u-boot from without needing back_to_bootrom.
>>>>
>>>>
>>>> Heiko
>>>>
>>>> I was not able to get mmc support on rk3066 in spl in ~31kb (32kb - 1kb
>>>> for
>>>> tpl)size limit.
>>>> One (or two i didn't check how much) back to bootrom is required on
>>>> rk3066.
>>>> If not done bootrom stays in weird state and halts on bringup secondary
>>>> cpu
>>>> in kernel. So it's rk3066 specific.
>>>>
>>>> What size do you get? With firefly-rk3288 I get about 25KB with SDRAM
>>>> init and MMC stack. Are you building with Thumb 2?
>>>>
>>>> If you are on irc we could try to clear this up more quicky (I am sjg1)
>>>>
>>>> To summarise where I think we got to:
>>>>
>>>> - move DRAM init into SPL
>>>> - either have a very small TPL which just returns to boot ROM, or
>>>> adjust start.S to return to the boot room early in SPL to load the
>>>> other 31KB
>>>>
>>>> Can you please post to the mailing list with your thoughts on this so
>>>> that others (including rockchip) can chime in? I think either will
>>>> work but I think others will have an opinion.
>>>>
>>>> Regards,
>>>> Simon
>>>>
>>>>
>>>> About moving dram init to spl i agree.
>>>>
>>>> I think early back to bootrom in start.S is a good solution as it would
>>>> give
>>>> me 1KB more space for spl and i could drop hacks like jumping to spl in
>>>> tpl
>>>> board file. But I would like to hear the opinion of other people on this.
>>> So with this solution there would be no TPL needed? It sounds
>>> reasonable to me. I'd like to hear other opinions also.
>>
>> We don't need tpl if i use early back to bootrom in start.S patch with
>> spl... but i didn't test it yet. If it will work i will drop the tpl. Is
>> that ok?
>
> It's OK with me. I don't know how the BROM re-enters SPL after the
> first call into the 1KB region. Depending on how that works, it might
> be too painful to use SPL only (e.g. if it jumps to a place in the
> middle of SPL).

BROM re-enters same address 0x10080C04 two times. First when it boots, 
second after first back to brom. That is why i used counter at address 
0x10080900 to count boot entries.
So it's not painful at all.

>>
>>>> Also i got a nandc driver from Heiko and i would like to adopt it for
>>>> u-boot
>>>> in the next version. Is it ok?
>>> Sounds good.
>>>
>>> Regards,
>>> Simon
>>
> Regards,
> Simon
Cheers
Paweł