Hi Siarhei, On 3 February 2015 at 20:23, Simon Glass <s...@chromium.org> wrote: > Hi Siarhei, > > On 3 February 2015 at 18:58, Siarhei Siamashka > <siarhei.siamas...@gmail.com> wrote: >> On Tue, 3 Feb 2015 17:55:52 -0700 >> Simon Glass <s...@chromium.org> wrote: >> >>> Hi, >>> >>> On 2 February 2015 at 22:29, Simon Glass <s...@chromium.org> wrote: >>> > Hi, >>> > >>> > On 2 February 2015 at 01:07, Hans de Goede <hdego...@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.siamas...@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?
I will send a series separately for you to try. It needs work but I hope it illustrates the idea. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
