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