Hi Phillip,

W dniu 09.08.2017 o 22:01, Dr. Philipp Tomsich pisze:
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.

I will implement this as 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.

Cheers,
Philipp.

So i'll go option two.

Cheers,
Paweł
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Reply via email to