Hi, Andre, Looks like I had enough time for trying the entire process today. Please see my steps below. The UART download tool seems to be missed in the "tools" folder. I will ask if it possible to put the binary version somewhere until we got the new release with sources. I probably have to build and try the SATA image as the next step.
BTW It was more complicated than I expected, probably since I usually only run the step 4. Enjoy! Regards Kosta ############################# # 1. Get sources from the GIT ############################# mkdir /work/community && cd /work/community git clone [email protected]:MarvellEmbeddedProcessors/atf-marvell.git -b atf-v1.3-armada-17.06 git clone https://github.com/MarvellEmbeddedProcessors/A3700-utils-marvell.git - b A3700_utils-armada-17.06 git clone [email protected]:MarvellEmbeddedProcessors/u-boot-marvell.git -b u-boot-2017.03-armada-17.06 ########################################################## # 2. TBB tool build - not sure if this step is needed # or the build will be triggered by ATF build # However I preferred to build it separately - this should # be done only once anyway. ########################################################## wget https://www.cryptopp.com/cryptopp565.zip cd /work/community/A3700-utils-marvell/wtptp_tool/src/TBB_Linux && makedir -p lib/cryptpp565 cd lib/cryptpp565 && unzip /work/community/cryptopp565.zip make -f GNUmakefile && cd ../../ make -f TBB_linux.mak LIBDIR=`pwd`/lib/cryptpp565 ###################### # 3. WTMI binary build ###################### cd /work/community/A3700-utils-marvell/wtmi make ############################################### # 4. Build the u-boot, ATF and the flash image ############################################### cd /work/community/u-boot-marvell export CROSS_COMPILE=/opt/gcc-linaro-5.3.1-2016.05-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu- export BL33=`pwd`/u-boot.bin export ATF_DIR=/work/community/atf-marvell export WTP=/work/community/A3700-utils-marvell export WTMI_IMG=/work/community/A3700-utils-marvell/wtmi/build/wtmi.bin make mrproper && make mvebu_espressobin-88f3720_defconfig && make make -C ${ATF_DIR} distclean && make -C ${ATF_DIR} DDR_TOPOLOGY=0 BOOTDEV=SPINOR USE_COHERENT_MEM=0 LOG_LEVEL=20 PLAT=a3700 all fip ########################################################## # The resulting images are in ${ATF_DIR}/build/a3700/release # The "flash-image.bin" is the image for the boot source device # (SPI NOR flash for the above example) # The "uart-images.tgz" archive contains separate image # components for UART download. ########################################################## Regards Kosta > -----Original Message----- > From: U-Boot [mailto:[email protected]] On Behalf Of Kostya > Porotchkin > Sent: Wednesday, July 19, 2017 18:48 > To: Andre Przywara > Cc: Thomas Petazzoni; Benjamin (Guodan) Huang; Marc Zyngier; U-Boot; > Stefan Roese; Andreas Färber > Subject: [EXT] Re: [U-Boot] How to update Espressobin (U-Boot) firmware? > > External Email > > ---------------------------------------------------------------------- > Hi, Andre, > > > -----Original Message----- > > From: Andre Przywara [mailto:[email protected]] > > Sent: Wednesday, July 19, 2017 18:19 > > To: Kostya Porotchkin > > Cc: Stefan Roese; Marc Zyngier; Thomas Petazzoni; Gregory CLEMENT; > > Antoine Tenart; Andreas Färber; U-Boot; Benjamin (Guodan) Huang > > Subject: Re: How to update Espressobin (U-Boot) firmware? > > > > Hi Kosta, > > > > thanks again for the instructions, though I feel the road there is > > still a bit bumpy and has some potholes ;-) > > > [Konstantin Porotchkin] Until the WIKI instructions are ready, I will > try to follow the entire build process out of Github sources and post > you my results here. > > Here is what I did: > > 1) build u-boot.bin > > 2) build wtmi.bin (from the utils repo) > > 3) build ATF > > $ make USE_COHERENT_MEM=0 DEBUG=1 LOG_LEVEL=20 DDR_TOPOLOGY=2 > > BOOTDEV=SPINOR WTMI_IMG=/path/to/wtmi.bin PLAT=a3700 all fip This > > breaks after having created fip.bin. I concatenated bl1.bin (padded to > > 128K) and fip.bin to atf.bin manually. > > 4) create the image description file (in the utils repo): > > ./buildtim.sh 0 SPINOR ./untrusted ./ CPU_800_DDR_800 2 0 1 ntim.txt > > 5) fixup the filenames in the generated text file (wtmi.bin and > > atf.bin) > > 6) create the image (utils repo): > > ./wtptp_tool/linux/TBB_linux -m 1 -r ntim.txt -V > > > > From staring at the SPI dump in a hexeditor, I take it that: > > a) TIM_ATF.bin goes to 0 > > b) wtmi.bin goes to 0x4000 > > c) atf.bin goes to 0x15000 > > > > Is that about right? Is it that doimage from the ATF repo is supposed > > to glue this together (step 4-6), which for some reason doesn't work > > for me? > [Konstantin Porotchkin] It should not be THAT complex. You suppose to > run few build commands and get the flash image ready with almost no > effort. I am mostly working with another SoC family (A8K) and need to > try this build by my own for refreshing the entire process in my memory. > If Benjamin (included in this thread) does not have the build recipe > already, I will give you my compilation steps tomorrow. > > > > Another issue seems to be that the UART download tool seems to be > > closed source only and only available from the Marvell "Extranet" > under NDA? > [Konstantin Porotchkin] I think it's not an NDA issue. If the UART > download tool currently not available in a source form, it probably will > be supplied in August SW release (17.08). Anyway, I believe if this tool > is missing, we can share it in the binary form as a temporary solution. > I will update you about it after my build test. > > > > From looking at the output of the "h" command in UART mode I guess > > this tools is just a glorious wrapper around spoon-feeding the > > generated binaries in 32-bit chunks into the respective SRAM regions, > > then execute them? Possibly also doing all those register setups (via > > MMIO) described in the ntim.txt/TIM_ATF.bin file? > > Which doesn't look too complicated to hack an Open Source tool for. > > Or is this tool actually available somewhere (either as source or as a > > binary)? > [Konstantin Porotchkin] The UART download tool is working with the SoC > service CPU (Cortex-M3), which runs the BootROM. So the BootROM verifies > the information received over the serial line and executes all required > initializations. Some memory regions and registers are not accessible or > cannot be modified by the application CPU, so only the service CPU can > do the job. > > Regards > Kosta > > > > Cheers, > > Andre. > > > > > > On 18/07/17 16:32, Kostya Porotchkin wrote: > > > Hi, Andre, > > > > > >> -----Original Message----- > > >> From: Andre Przywara [mailto:[email protected]] > > >> Sent: Tuesday, July 18, 2017 18:24 > > >> To: Kostya Porotchkin > > >> Cc: Stefan Roese; Marc Zyngier; Thomas Petazzoni; Gregory CLEMENT; > > >> Antoine Tenart; Andreas Färber; U-Boot; Benjamin (Guodan) Huang > > >> Subject: Re: [EXT] How to update Espressobin (U-Boot) firmware? > > >> > > >> Hi Kosta, > > >> > > >> On 18/07/17 16:13, Kostya Porotchkin wrote: > > >>> The A37xx SoC does not support boot from SD. > > >> > > >> Ah! > > >> > > >>> Only boot from eMMC is supported, however your board probably only > > >>> has > > >> soldering pads for the eMMC and not eMMC chip installed. > > >>> If you want to play with the bootloader without jeopardizing your > > >>> SPI > > >> image, you have to use either UART or SATA boot mode. > > >> > > >> Does SATA boot work like SD boot, where the boot image starts at > > >> sector 1? And it needs to be flagged as a SATA boot image, right? > > > [Konstantin Porotchkin] Correct. You can put it on LBA-1 or LBA-34 > > > if > > you use GPT. > > > Just remember, this image is very special. It's actually a multipart > > > image that we merge into a single blob for easier usage with the u- > > boot "bubt" command. > > > > > >> > > >>> For the boot image build you will need to obtain the u-boot, ATF > > >>> and > > >> the image building tools sources. > > >>> https://github.com/MarvellEmbeddedProcessors/atf-marvell/tree/atf- > > >>> v1 > > >>> .3 > > >>> -armada-17.06 > > >>> https://github.com/MarvellEmbeddedProcessors/A3700-utils-marvell/t > > >>> re > > >>> e/ > > >>> A3700_utils-armada-17.06 > > >>> https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/tree/u > > >>> -b > > >>> oo > > >>> t-2017.03-armada-17.06 > > >>> > > >>> The "utils" git contains also the UART download tool. > > >>> It uses a proprietary download protocol and not xmodem one as in > > >>> KW > > >> case. > > >>> The flash image structure on this platform also differs from KW, > > >>> so > > >> please do not try to directly burn a "bin" or "kw" file created by > > >> the u-boot build system. > > >>> The ATF git from above already contains the required changes in > > >>> the > > >> Makefile for running the additional steps of the final flash image > > >> formatting. > > >>> Additionally, the boot image contains a boot device information in > > >>> its > > >> header, so you cannot move SPI flash image to another boot device. > > >>> > > >>> For the boot loader build instructions please check the following > > >> documents: > > >>> https://github.com/MarvellEmbeddedProcessors/atf-marvell/blob/atf- > > >>> v1 > > >>> .3 > > >>> -17.04/docs/marvell/build.txt > > >>> https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/blob/u > > >>> -b oo t-2017.03-armada-17.06/doc/mvebu/build.txt > > >>> > > >>> UART boot details: > > >>> https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/blob/u > > >>> -b oo t-2017.03-armada-17.06/doc/mvebu/uart_boot.txt > > >> > > >> Thanks a ton for those links and information, that was exactly what > > >> I was looking for! > > >> Do you mind if I (later ;-) write up those steps in a document > > >> which we merge into the repo? > > >> Something like [1], which proved useful in the past just to point > > >> people to - that would save you some typing as well ;-) > > > [Konstantin Porotchkin] Sure, any additional source of information > > would be great. > > > I just notified the Espressobin WIKI team about urgent need for this > > type of document and for an alternative boot source usage example. > > > Hope the new WIKI entry will be ready shortly. > > > > > > Regards > > > Kosta > > >> > > >> Cheers, > > >> Andre. > > >> > > >> [1] > > >> http://git.denx.de/?p=u- > > >> boot.git;a=blob;f=board/sunxi/README.sunxi64;hb=HEAD > > >> > > >>> > > >>> > > >>> Regards > > >>> Kosta > > >>> > > >>>> -----Original Message----- > > >>>> From: Andre Przywara [mailto:[email protected]] > > >>>> Sent: Tuesday, July 18, 2017 17:45 > > >>>> To: Kostya Porotchkin > > >>>> Cc: Stefan Roese; Marc Zyngier; Thomas Petazzoni; Gregory > > >>>> CLEMENT; Antoine Tenart; Andreas Färber; U-Boot > > >>>> Subject: [EXT] How to update Espressobin (U-Boot) firmware? > > >>>> > > >>>> External Email > > >>>> > > >>>> ----------------------------------------------------------------- > > >>>> -- > > >>>> -- > > >>>> - > > >>>> Hi, > > >>>> > > >>>> I wanted to exploit U-Boot's EFI support on the Espressobin > > >>>> board, to use off-the-shelf arm64 distribution installer images. > > >>>> This should work with current U-Boot, which has support for the > > >>>> Espressobin board (and for UEFI). > > >>>> > > >>>> The firmware my board ships with seems to be built from older and > > >>>> non- upstream sources - and, in contrast to the Macchiatobin > > >>>> board > > >>>> - I cannot find either proper sources for all components (mv-ddr, > > >>>> ATF) nor > > >>>> *any* kind of instructions how to (re-)build and update the > > firmware. > > >>>> > > >>>> So I was wondering if there are any instructions or documentation > > >>>> I missed on how to update at least U-Boot? > > >>>> > > >>>> I see some hints that people are apparently chain-loading > > >>>> mainline > > >>>> U- Boot, is this the only way? > > >>>> I dumped the SPI flash and could identify the ATF FIP image on > > >>>> it, but I am a bit wary of bricking the board by just squashing a > > >>>> freshly built u- boot.bin into that - which I guess wouldn't work > > >>>> that easily > > >> anyway. > > >>>> > > >>>> And to allow experimentation: Are the boot selection jumpers > > >>>> actually working? Setting them to SD card (111) doesn't seem to > > >>>> make a difference (it still booted off the SPI flash, > apparently). > > >>>> Or does it fall back to SPI flash in case the SD image is not > > >>>> valid (I put the dumped image at sector 1)? > > >>>> I see that selecting "UART" (110) gives me that "E" prompt, > > >>>> apparently waiting for some data to be fed, but again can't tell > > >>>> what to do from here? I take it that mkimage/kwboot won't work as > > >>>> is, as it needs ATF? I found some mentioning of a Windows binary, > > >>>> but hope that's not the only way to use this mode? > > >>>> > > >>>> I'd be very grateful for any insight into this! > > >>>> > > >>>> Cheers, > > >>>> Andre. > _______________________________________________ > U-Boot mailing list > [email protected] > https://lists.denx.de/listinfo/u-boot _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
