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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
