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, Stefan