> On 04 Aug 2017, at 19:01, Paweł Jarosz <paweljarosz3...@gmail.com> wrote:
> Hi Philipp,
> W dniu 04.08.2017 o 18:51, Dr. Philipp Tomsich pisze:
>>> On 04 Aug 2017, at 18:33, Paweł Jarosz <paweljarosz3...@gmail.com> wrote:
>>> Hi,
>>> W dniu 15.06.2017 o 18:40, Simon Glass pisze:
>>>> Hi Pawel,
>>>> On 15 June 2017 at 10:32, Paweł Jarosz <paweljarosz3...@gmail.com> wrote:
>>>>> 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 <paweljarosz3...@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 <paweljarosz3...@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 <s...@chromium.org> wrote:
>>>>>>>>> Hi Pawel,
>>>>>>>>> On 9 June 2017 at 06:31, Paweł Jarosz <paweljarosz3...@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 <paweljarosz3...@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.
>>>> OK from my POV this seems good.
>>>> [..]
>>>> Regards,
>>>> Simon
>>> It turns out that i will be needing tpl, spl and main u-boot. Also sdram 
>>> initialization will be needed in tpl.
>>> Reason for that is how bootrom on rk3066 executes stuff:
>>> 1. At first stage it reads 2KB of data from nand to sram at address 
>>> 0x10080C00 and decodes 1KB, executes decoded data at 0x10080C04 and waits 
>>> for back to bootrom.
>>> 2. At second stage it reads 31KB, decodes it and executes again data at 
>>> 0x10080C04 and waits for second back to bootrom. Also SDRAM init MUST BE 
>>> HERE or board hangs at third stage.
>>> 3. At third stage bootrom reads ~200KB data to RAM at 0x60000000, decodes 
>>> it and do final execution.
>> Are both the first stage and the second stage loaded to SRAM + 0xc00?
>> I.e. does the second stage (31KB) overwrite the first stage?
> No. First stage is loaded to 0xC00 in sram(2KB but decoded from rc4 only 
> 1KB), second stage is then loaded to 0xC00 + 2KB(0x400)

If you have no logic (except for counting ‘reentries’) in the first stage, you 
might be able to implement this as a boot0 hook.

>>> All three stages are required or else later kernel will halt at bringup 
>>> secondary cpus using bootrom (there is another back to bootrom in kernel 
>>> code to bringup secondary cpus)
>>> So there are two ways to boot main u-boot:
>>> 1. TPL + SPL loaded to sram (stages one and two) and main u-boot loaded to 
>>> sdram(third stage). In this case main u-boot must fit in ~200KB which is 
>>> not much and ONLY ONE of the features nand, mmc, usb might be compiled in.
>>> 2. TPL with SDRAM INIT + early back to bootrom patch as stage one and two, 
>>> SPL as stage three, and main u-boot loaded from nand by SPL (stage four).
>>> I know all of this from bootrom disassembly and tests.
>>> So is it ok to go the second way?

I would view option two as just having the usual three stages, but the TPL 
stage being loaded in pieces and being entered twice.
So option 2 will then look a lot like other Rockchip boot sequences.


U-Boot mailing list

Reply via email to