[U-Boot] [PATCH 2/9] sunxi: Move SPL s_init() code to board_init_f()

Simon Glass sjg at chromium.org
Wed Feb 4 04:23:07 CET 2015


Hi Siarhei,

On 3 February 2015 at 18:58, Siarhei Siamashka
<siarhei.siamashka at gmail.com> wrote:
> On Tue, 3 Feb 2015 17:55:52 -0700
> Simon Glass <sjg at chromium.org> wrote:
>
>> Hi,
>>
>> On 2 February 2015 at 22:29, Simon Glass <sjg at chromium.org> wrote:
>> > Hi,
>> >
>> > On 2 February 2015 at 01:07, Hans de Goede <hdegoede at redhat.com> wrote:
>> >> Hi Simon, Siarhei,
>> >>
>> >> On 01-02-15 21:59, Simon Glass wrote:
>> >>>
>> >>> Hi Siarhei,
>> >>>
>> >>> On 1 February 2015 at 11:37, Siarhei Siamashka
>> >>> <siarhei.siamashka at gmail.com>
>> >>
>> >>
>> >> <snip>
>> >>
>> >>>> A comprehensive FEL usage guide is supposed to be in the linux-sunxi
>> >>>> wiki. But it might be not very up to date with the mainline u-boot
>> >>>> usage.
>> >>>>
>> >>>> Anyway, first just clone the https://github.com/linux-sunxi/sunxi-tools
>> >>>> repository and build it. This will provide you with the x86 binary of
>> >>>> the 'fel' tool, which is used on your desktop PC to talk with the
>> >>>> device.
>> >>>>
>> >>>> Then connect the device to your PC using a "USB A to USB mini/micro B"
>> >>>> cable. And reset the board while keeping the "FEL" button pressed. The
>> >>>> button might be labelled as "UPGRADE" on your pcduino3 board:
>> >>>> http://linux-sunxi.org/LinkSprite_pcDuino_V3#FEL_mode
>> >>>>
>> >>>> Then just run "fel ver" command:
>> >>>> http://linux-sunxi.org/FEL#Running_the_fel_tool
>> >>>>
>> >>>> If everything is fine, it should respond with something like this:
>> >>>> AWUSBFEX soc=00162500(A13) 00000001 ver=0001 44 08 scratchpad=00007e00
>> >>>> 00000000 00000000
>> >>>>
>> >>>> Now you can use "write" commands to upload data to SRAM. And "exe"
>> >>>> command to execute functions on the device (works as some kind of RPC):
>> >>>> http://linux-sunxi.org/FEL/USBBoot#Manual_loading
>> >>>>
>> >>>> As a simple test, you can upload just a single "bx lr" instruction
>> >>>> (compiled in ARM mode) to the address 0x2000 and try to execute it.
>> >>>> In the case if your code screws up something and does not return
>> >>>> control to the BROM correctly, then the "fel" tool can't communicate
>> >>>> over USB anymore and just timeouts. Regarding the address space, you
>> >>>> can use SRAM addresses starting from 0x2000 up to something like 0x5E00
>> >>>> (that's where the stack pointer is set). This was a description of a
>> >>>> "bare metal" FEL usage.
>> >>>>
>> >>>> Now as for the u-boot support. You can compile and run u-boot in the FEL
>> >>>> mode configuration on pcduino3 in the following way:
>> >>>>
>> >>>> make CROSS_COMPILE=arm-none-gnueabi- Linksprite_pcDuino3_felconfig
>> >>>> make CROSS_COMPILE=arm-none-gnueabi- -j2
>> >>>>
>> >>>> fel write 0x2000 spl/u-boot-spl.bin
>> >>>> fel exe 0x2000
>> >>>>
>> >>>> sleep 1 # Wait for DRAM initialization to complete
>> >>>
>> >>>
>> >>> i.e. wait for U-Boot SPL to return to the BROM?
>> >>>
>> >>>>
>> >>>> fel write 0x4a000000 u-boot.bin
>> >>>> fel exe 0x4a000000
>> >>>>
>> >>>> Please note the use of '*_felconfig' instead of '*_defconfig'.
>> >>>> And also right now the FEL mode support is broken. That's why the
>> >>>> http://lists.denx.de/pipermail/u-boot/2015-January/203282.html
>> >>>> patchset tried to address this problem.
>> >>>>
>> >>>
>> >>> OK that looks like an excellent guide, thank you. I will make some time to
>> >>> take a more detailed look at this as soon as I can, but definitely in the
>> >>> next few days.
>> >>
>> >>
>> >> I've been reading all threads on this, thank you both for looking into this,
>> >> since you're on it I'm going to leave this be (and not review / apply
>> >> Siarhei's patches for this), and we can revisit this later, with hopefully a
>> >> better fix.
>> >
>> > Thanks to Siarhei's instructions I have a working setup with pcduino3.
>> > One less board where I have to swap SD cards. Can I suggest that it
>> > would be really nice to have a README.sunxi that covers all of this?
>> >
>> > Anyway I will fiddle around and see what I can come up with.
>>
>> The problem seems to be the start.S code 'Setup vector' and
>> cpu_init_cp15. If I remove these then FEL boots OK without all the
>> gdata/r9 stuff and with the rest of the boot flow normal.
>
> I don't quite follow this brief explanation. Could you perhaps
> attach/paste a patch or provide a link to some test branch with
> the code?

If you look at code in start.S it fiddles with cp15 and this seems to
stuff up FEL. I'm not exactly sure what is breaking it, but we seem to
need to skip that code.

I will push what I have to a branch - I am just trying to tidy it up a bit.

>
>> I would quite like FEL to be an option you enable, but we can detect
>> whether it is actually being used (as with Tegra and Exynos).
>
> FEL is already a Kconfig option, which can be enabled/disabled
> in menuconfig. Currently it also disables certain parts of code
> (MMC support) in order to reduce the SPL size. If these parts are
> all included (but deactivated via a runtime check), then the SPL
> binary becomes too large.

OK. My point is that FEL support should not be such a pervasive
option, changing everything about how it boots. We should just change
the minimum to make FEL work. The only thing that really is a problem
is the size, so with FEL we must disable MMC. That is fine.

>
>> Perhaps checking the value of lr will allow this to work.
>
> Or by peeking into some of the MUSB hardware registers after the
> start of SPL. MUSB must be already initialized for FEL to work.

That sounds good, we should use whatever is a cast-iron way of knowing
the boot mode. On Exynos there is a register.

>
> However I'm still curious about how the SPL size problem is going
> to be addressed.

Well it probably cannot be addressed. Does the boot ROM have an MMC
stack? Surely it must if it supports booting from MMC?

>
>> I'm not sure of the best way to skip the vector/cp15 setup. For now I
>> can do an #ifdef but I'm wondering if we should allow
>> save_boot_params() to return some flags indicating what should be
>> skipped?

Regards,
Simon


More information about the U-Boot mailing list