Hi Stefan,
On May 4, 2015 1:50 AM, "Stefan Roese" sr@denx.de wrote:
Hi Simon,
On 03.05.2015 19:20, Simon Glass wrote:
Hi Stefan,
On 3 May 2015 at 03:16, Stefan Roese sr@denx.de wrote:
Hi Simon,
On 02.05.2015 22:59, Simon Glass wrote:
On 24 April 2015 at 22:29, Stefan Roese sr@denx.de wrote:
This patch series adds support for the Marvell Armada A38x SoC's. Specifically the 88F6820 / 88F6828.
Basic support for the DB-88F6820-GP evaluation board is added.
Supporting
the following interfaces:
- UART
- SPI (including SPI NOR flash)
- I2C
- Ethernet (neta)
One big part of this new SoC support is the move of the already
exisiting
Armada XP support into the "mach-mvebu" directory. With this move its easier to re-use this code for the A38x, which is pretty similar to
the
AXP.
When I try to build this I get an error - its wants a 'binard.0' file. It talks about extracting this from an 'existing image'. Is it not available as source code? If not, is there a README explaining where to get it?
This error should not occur. Sorry I've missing this.
The patch "arm: mvebu: Add Armada A38x DB-88F6820-GP board support"
includes
this file:
--------------------- board/Marvell/db-88f6820-gp/binary.0
new file mode 100644 index 0000000..57a4cbf @@ -0,0 +1,16 @@ +-------- +WARNING: +-------- +This file should contain the bin_hdr generated by the original Marvell +U-Boot implementation. As this is currently not included in this +U-Boot version, we have added this placeholder, so that the U-Boot +image can be generated without errors.
+If you have a known to be working bin_hdr for your board, then you +just need to replace this text file here with the binary header +and recompile U-Boot.
+In a few weeks, mainline U-Boot will get support to generate the +bin_hdr with the DDR training code itself. By implementing this code +as SPL U-Boot. Then this file will not be needed any more and will +get removed.
Which should at least enable building this image for now. Until I've submitted the missing patches to integrate the SPL code including the
DDR
setup code. I'm currently busy with the cleanup of this code.
Hopefully this
will follow later this week. But I really would like to have this
basic A38x
support added now.
The build fails because of this. If this is the intended final state then I think you should define an environment variable to enable the binary build, so that we don't get buildman errors. For x86 (which has serious problems with binary blobs still) we use BUILD_ROM for this. It probably isn't a very good name for you, but you could create your own.
As explained above, the build should not fail. I'll take a look at it tomorrow and either send a follow up patch (when its already applied by then) or send v4 of this patchset.
Thanks for the explanation, sounds good.
I re-tested this patch series and found that it build (as I would have expected) without errors when using the "make" commands:
$ make mrproper $ make db-88f6820-gp_defconfig # # configuration written to .config # $ make -j10 -s $ ll u-boot.kwb -rw-rw-r-- 1 stefan stefan 175708 Mai 4 09:47 u-boot.kwb $ make
Only when run via buildman this error shows:
$ ./tools/buildman/buildman db-88f6820-gp boards.cfg is up to date. Nothing to do. Building current source for 1 boards (1 thread, 8 jobs per thread) arm: + db-88f6820-gp +Didn't find the file 'board/Marvell/db-88f6820-gp/binary.0' in
'/home/stefan/git/u-boot/.bm-work/00/build' which is mandatory to generate the image
+This file generally contains the DDR3 training code, and should be
extracted from an existing bootable
+image for your board. See 'kwbimage -x' to extract it from an existing
image.
+Could not create image +make[1]: *** [u-boot.kwb] Error 1 +make: *** [sub-make] Error 2 0 0 1 /1 db-88f6820-gp
Do you have an explanation why this is the case? The file board/Marvell/db-88f6820-gp/binary.0 is available and building via "make" does work. Where does this difference come from?
Could it be that out-of-tree building is broken?
You can try buildman -i to check.
Regards, Simon