From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Roese Date: Thu, 11 Apr 2019 10:35:15 +0200 Subject: [U-Boot] [PATCH v2 5/5] arm: mvebu: Add DB-XC3-24G4XG board In-Reply-To: References: <20190215224902.28351-1-judge.packham@gmail.com> <20190215224902.28351-6-judge.packham@gmail.com> Message-ID: <72ffc7fa-9a33-3fd1-6207-843797457dd4@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 11.04.19 10:21, Chris Packham wrote: > On Thu, Apr 11, 2019 at 7:23 PM Chris Packham wrote: >> >> On Thu, Apr 11, 2019 at 6:46 PM Stefan Roese wrote: >>> >>> Hi Chris, >>> >>> On 15.02.19 23:49, Chris Packham wrote: >>>> From: Chris Packham >>>> >>>> The DB-XC3-24G4XG is a switch development board from Marvell. It can >>>> either use and external CPU card such as the db-88f6820-amc or the >>>> internal CPU that is integrated into the switch. >>>> >>>> Add support for running U-Boot on the internal CPU and enable the USB, >>>> SPI and NAND peripherals. For now this needs the bin_hdr from the >>>> Marvell U-Boot for this board. >>>> >>>> Signed-off-by: Chris Packham >>> >>> Compiling this with buildman (Travis) leads to this error: >>> >>> arm: + db-xc3-24g4xg >>> +Didn't find the file 'board/Marvell/db-xc3-24g4xg/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[1]: *** Deleting file 'u-boot.kwb' >>> >>> The external build output directory seems to be the problem here. >>> Could you please look into this? >> >> Yep I'll take a look. > > There are a two options > > 1. Add a rule to copy the binary blob to the output directory > $(obj)/binary.0: $(src}/binary.0 > cp $^ $@ This would be in the board directory, right? > 2. Set CONFIG_BUILD_TARGET to u-boot.bin > > Option 1 suits me because I have the required binary blob from > Marvell's tree. Option 2 would work for the compile tests and for > anyone chain loading the upstream u-boot. > > Any preferences? If 1 suits you better, then I don't object. Please continue this way. Thanks, Stefan