Message ID | eeb5c500573a8584bfbfe6d33bf160c725683a18.1461688139.git.jpinto@synopsys.com |
---|---|
State | Changes Requested |
Headers | show |
Hello, This patch should be the second patch in the series, since it relies on the atfirmware package being added. The title of the patch should be something like: configs: use atfirmware package in arm_juno_defconfig On Tue, 26 Apr 2016 17:35:55 +0100, Joao Pinto wrote: > +Other ARM Trusted Firmware options > +================================== One empty new line here. > +If you need to include the bootlader into the fip package, please bootlader -> bootloader can you say "into the ARM Trusted Firmware fip image" instead of "into the fip package". In the context of Buildroot, "package" has a specific meaning, and there is nothing like a "fip package" in Buildroot. > +configure BR2_TARGET_ATFIRMWARE_PAYLOAD_PATH to specify the path to the > +binary. Why don't you automatically put the bootloader as the payload of the ATF firmware? How can the ATF firmware be useful without the bootloader as the payload? This is a real question, maybe there's a real use for it. > +If you need to include the SCP Firmware into the fip package please Same comment about "into the fip package". > +specify SCP_BL2=<binary_path> in BR2_TARGET_ATFIRMWARE_ADDITIONAL_VARIABLES. Just for info, what is this SCP Firmware ? > > Preparing your rootfs > ====================== > @@ -89,8 +104,8 @@ NOR3LOAD: 00000000 ;Image Load Address > NOR3ENTRY: 00000000 ;Image Entry Point > ...... > > -Installing kernel image and DTB > -=============================== > +Installing kernel image, DTB and bootloader > +=========================================== > > 1. Connect to the ARM Juno UART0 and execute USB_ON in the terminal > 2. Connect a USB cable between your PC and ARM Juno USB type B connector > @@ -98,7 +113,8 @@ Installing kernel image and DTB > 3. Open the software/ folder > 4. Copy the 'Image' file to software/ > 5. Copy the 'juno-r1.dtb' (r1) or the 'juno.dtb' (r0) file to software/ > -6. Press the red button in the front pannel of ARM Juno > +6. Copy the 'bl1.bin' and 'fip.bin' files to software/ > +7. Press the red button in the front pannel of ARM Juno > > At this time, the board will erase the Flash entry for each new item and > replace it with the lastest ones. > diff --git a/configs/arm_juno_defconfig b/configs/arm_juno_defconfig > index 87b6374..b94d04c 100644 > --- a/configs/arm_juno_defconfig > +++ b/configs/arm_juno_defconfig > @@ -12,3 +12,15 @@ BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y > BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/arm/juno/linux-juno-defconfig" > BR2_LINUX_KERNEL_DTS_SUPPORT=y > BR2_LINUX_KERNEL_INTREE_DTS_NAME="arm/juno arm/juno-r1" > +BR2_TARGET_UBOOT=y > +BR2_TARGET_UBOOT_BUILD_SYSTEM_KCONFIG=y > +BR2_TARGET_UBOOT_BOARDNAME="vexpress_aemv8a_juno" > +BR2_TARGET_UBOOT_CUSTOM_VERSION=y > +BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE="2016.03" > +BR2_TARGET_ATFIRMWARE=y > +BR2_TARGET_ATFIRMWARE_CUSTOM_GIT=y > +BR2_TARGET_ATFIRMWARE_VERSION="v1.2" > +BR2_TARGET_ATFIRMWARE_CUSTOM_GIT_REPO_URL="https://github.com/ARM-software/arm-trusted-firmware.git" > +BR2_TARGET_ATFIRMWARE_CUSTOM_GIT_VERSION="v1.2" > +BR2_TARGET_ATFIRMWARE_PLATFORM="juno" > + The last empty new line is useless. Could you fix those issues and send an updated version? Thanks! Thomas
Hello, On Tue, 26 Apr 2016 17:35:55 +0100, Joao Pinto wrote: > + +-- u-boot.bin > + +-- bl1.bin > + +-- bl2.bin > + +-- bl2u.bin > + +-- bl31.bin > + +-- fip.bin Looking at your atfirmware package, I see bl1.bin and fip.bin being copied to output/images, but not bl2.bin, bl2u.bin and bl31.bin. Why are you mentioning them here? Thanks! Thomas
Hello, On Wed, 27 Apr 2016 11:21:52 +0100, Liviu.Dudau@arm.com wrote: > > Same comment about "into the fip package". > > > > > +specify SCP_BL2=<binary_path> in BR2_TARGET_ATFIRMWARE_ADDITIONAL_VARIABLES. > > > > Just for info, what is this SCP Firmware ? > > Juno has a System Control Processor that does SoC clock and power management. OK, thanks for the explanation! So perhaps just for the sake of clarity, use "System Control Processor" in the readme.txt instead of just SCP. Thanks! Thomas
Hello, On Wed, 27 Apr 2016 11:23:02 +0100, Liviu.Dudau@arm.com wrote: > > On Tue, 26 Apr 2016 17:35:55 +0100, Joao Pinto wrote: > > > > > + +-- u-boot.bin > > > + +-- bl1.bin > > > + +-- bl2.bin > > > + +-- bl2u.bin > > > + +-- bl31.bin > > > + +-- fip.bin > > > > Looking at your atfirmware package, I see bl1.bin and fip.bin being > > copied to output/images, but not bl2.bin, bl2u.bin and bl31.bin. Why > > are you mentioning them here? > > Those get embedded into the fip.bin. For Juno you need only bl1.bin and > fip.bin to be transfered to the board. Right, and they are indeed not copied to $(BINARIES_DIR) by the atfirmware package. So they shouldn't be mentioned in the readme.txt. Thomas
Hello! On 4/27/2016 12:31 PM, Thomas Petazzoni wrote: > Hello, > > On Wed, 27 Apr 2016 11:23:02 +0100, Liviu.Dudau@arm.com wrote: > >>> On Tue, 26 Apr 2016 17:35:55 +0100, Joao Pinto wrote: >>> >>>> + +-- u-boot.bin >>>> + +-- bl1.bin >>>> + +-- bl2.bin >>>> + +-- bl2u.bin >>>> + +-- bl31.bin >>>> + +-- fip.bin >>> >>> Looking at your atfirmware package, I see bl1.bin and fip.bin being >>> copied to output/images, but not bl2.bin, bl2u.bin and bl31.bin. Why >>> are you mentioning them here? >> >> Those get embedded into the fip.bin. For Juno you need only bl1.bin and >> fip.bin to be transfered to the board. > > Right, and they are indeed not copied to $(BINARIES_DIR) by the > atfirmware package. So they shouldn't be mentioned in the readme.txt. Yes, no problem I will give a check to all your comments. > > Thomas > The SCP firmware is a critical piece for the Juno, but the problem is that it can't be built from any repository I think. @Liviu: Could you please confirm this info? If the SCP firmware exists as a binary only, then we have to include it in /board/arm/juno folder for building the ATF out-of-the-box. Opinions? Thanks, Joao
Hello, On Wed, 27 Apr 2016 12:44:39 +0100, Joao Pinto wrote: > The SCP firmware is a critical piece for the Juno, but the problem is that it > can't be built from any repository I think. > @Liviu: Could you please confirm this info? > > If the SCP firmware exists as a binary only, then we have to include it in > /board/arm/juno folder for building the ATF out-of-the-box. It's really super annoying to include binary blob in the Buildroot repository. If it really needs to be a binary blob, then I'd prefer to have it available somewhere (ARM website, Github, etc.) and a Buildroot package that downloads it. Best regards, Thoms
Hello, On Wed, 27 Apr 2016 13:04:54 +0100, Liviu.Dudau@arm.com wrote: > > The SCP firmware is a critical piece for the Juno, but the problem is that it > > can't be built from any repository I think. > > @Liviu: Could you please confirm this info? > > That's right, SCP firmware is not available in source form to 3rd parties for now. Even though that's unfortunate, that's completely OK from a Buildroot point of view: we already have lots of packages for closed-source binary blobs (OpenGL implementations, firmwares, etc.). > > If the SCP firmware exists as a binary only, then we have to include it in > > /board/arm/juno folder for building the ATF out-of-the-box. > > Thomas, the way ARM Trusted Firmware works (documented in docs/firmware-design.md in > the ATF repo) requires that a runtime firmware binary for SCP (embedded within fip.bin) > is loaded at boot time. OK. > One option is to copy the original fip.bin from the board, extract > the bl2.bin from it using fip_create tool (bad name, sorry) and then > embed it back in the newly created fip.bin. Mind you, fip_create > actually supports updating an existing fip.bin, it doesn't have to > create the file from scratch. That's an option, but it doesn't give a Buildroot output that works "out of the box" on the target, which is not unacceptable (it can be explained in the readme.txt that comes with Buildroot for this board) but a bit sad. So when you're saying this, are you saying that the binary blob is not even available publicly for download? Best regards, Thomas
Hello, On Wed, 27 Apr 2016 13:46:33 +0100, Liviu.Dudau@arm.com wrote: > > So when you're saying this, are you saying that the binary blob is not > > even available publicly for download? > > It is available for download from Linaro downloads page, look for Juno firmware. > However it is bundled inside a fip.bin and that is wrapped in a tarball. That is still OK, we can always have a Buildroot package that downloads that tarball, extracts it, takes the fip.bin, uses the fip_create tool to extract the SCP firmware, install it somewhere, and then have the atfirmware package pick it up to create the final fip.bin. Thomas
On 4/27/2016 1:53 PM, Thomas Petazzoni wrote: > Hello, > > On Wed, 27 Apr 2016 13:46:33 +0100, Liviu.Dudau@arm.com wrote: > >>> So when you're saying this, are you saying that the binary blob is not >>> even available publicly for download? >> >> It is available for download from Linaro downloads page, look for Juno firmware. >> However it is bundled inside a fip.bin and that is wrapped in a tarball. > > That is still OK, we can always have a Buildroot package that > downloads that tarball, extracts it, takes the fip.bin, uses the > fip_create tool to extract the SCP firmware, install it somewhere, and > then have the atfirmware package pick it up to create the final fip.bin. There's a detail. fip_create is built by the atfirmware package. So the package must be built once, extract the scp, copy somewhere, built it again now with the SCP_BL2. It is doable, but double build is needed and I don't know how buildroot deals with this 2xbuild operation. > > Thomas > Joao
Hello, On Wed, 27 Apr 2016 15:17:34 +0100, Joao Pinto wrote: > > That is still OK, we can always have a Buildroot package that > > downloads that tarball, extracts it, takes the fip.bin, uses the > > fip_create tool to extract the SCP firmware, install it somewhere, and > > then have the atfirmware package pick it up to create the final fip.bin. > > There's a detail. fip_create is built by the atfirmware package. So the package > must be built once, extract the scp, copy somewhere, built it again now with the > SCP_BL2. It is doable, but double build is needed and I don't know how buildroot > deals with this 2xbuild operation. Gaah. This is indeed going to be insane. Another option is to have: 1/ Your atfirmware package as-is. 2/ A package that just downloads/extracts the SCP firmware. 3/ A post-image script that generates the final fip.bin. That's probably the easiest solution for now. We can see at making that better when/if we have more platforms that require a similar firmware. My ARM64 platform does not: I simply need to build U-Boot and ATF, and the image produced by ATF is directly usable. Thomas
Hi! I am planning to put the atfirmware package u-boot dependent, in order to get the u-boot binary automatically without being needed to specify the location of the binary. For this: # Automatically find the U-Boot binary ifeq ($(BR2_TARGET_UBOOT_FORMAT_CUSTOM_NAME), ) ATFIRMWARE_PAYLOAD_PATH = $(BINARIES_DIR)/"u-boot.bin" else ATFIRMWARE_PAYLOAD_PATH = $(BINARIES_DIR)/$(BR2_TARGET_UBOOT_FORMAT_CUSTOM_NAME) endif ATFIRMWARE_MAKE_OPTS += \ CROSS_COMPILE="$(TARGET_CROSS)" \ BL33=$(call qstrip,$(ATFIRMWARE_PAYLOAD_PATH)) \ $(call qstrip,$(BR2_TARGET_ATFIRMWARE_ADDITIONAL_VARIABLES)) \ PLAT=$(ATFIRMWARE_PLATFORM) \ all fip In terms of the SCP_FW, I think for now is more reliable to make the final stage manually if using a Juno board. From my experience stuff in Linaro repositories change frequently and so we have a good probability of breaking the binary download. I suggest to put a note in the readme.txt saying what should be done, since everyone using a Juno will have access to the SCP FW in the board. What do you think? On 4/27/2016 3:41 PM, Liviu.Dudau@arm.com wrote: > On Wed, Apr 27, 2016 at 04:31:22PM +0200, Thomas Petazzoni wrote: >> Hello, >> >> On Wed, 27 Apr 2016 15:17:34 +0100, Joao Pinto wrote: >> >>>> That is still OK, we can always have a Buildroot package that >>>> downloads that tarball, extracts it, takes the fip.bin, uses the >>>> fip_create tool to extract the SCP firmware, install it somewhere, and >>>> then have the atfirmware package pick it up to create the final fip.bin. >>> >>> There's a detail. fip_create is built by the atfirmware package. So the package >>> must be built once, extract the scp, copy somewhere, built it again now with the >>> SCP_BL2. It is doable, but double build is needed and I don't know how buildroot >>> deals with this 2xbuild operation. > > It looks like the binary *is* available from a Linaro git tree, but it has the old > name before ATF has renamed it SCP_BL2: > > https://git.linaro.org/arm/vexpress-firmware.git/blob/refs/heads/juno:/SOFTWARE/bl30.bin > > Best regards, > Liviu > >> >> Gaah. This is indeed going to be insane. Another option is to have: >> >> 1/ Your atfirmware package as-is. >> 2/ A package that just downloads/extracts the SCP firmware. >> 3/ A post-image script that generates the final fip.bin. >> >> That's probably the easiest solution for now. We can see at making that >> better when/if we have more platforms that require a similar firmware. >> My ARM64 platform does not: I simply need to build U-Boot and ATF, and >> the image produced by ATF is directly usable. >> >> Thomas >> -- >> Thomas Petazzoni, CTO, Free Electrons >> Embedded Linux, Kernel and Android engineering >> http://free-electrons.com >> > Thanks. Joao
Hello, On Thu, 28 Apr 2016 18:21:50 +0100, Joao Pinto wrote: > # Automatically find the U-Boot binary > ifeq ($(BR2_TARGET_UBOOT_FORMAT_CUSTOM_NAME), ) use qstrip, otherwise this will never be true. Also, remove the space after the comma. > ATFIRMWARE_PAYLOAD_PATH = $(BINARIES_DIR)/"u-boot.bin" Remove the quotes. > else > ATFIRMWARE_PAYLOAD_PATH = $(BINARIES_DIR)/$(BR2_TARGET_UBOOT_FORMAT_CUSTOM_NAME) Use qstrip here as well. Are you sure it's either u-boot.bin or a custom name? There are plenty of other possible image names in uboot.mk (but quite certainly not all of them apply to ARM64). > In terms of the SCP_FW, I think for now is more reliable to make the final stage > manually if using a Juno board. From my experience stuff in Linaro repositories > change frequently and so we have a good probability of breaking the binary download. > I suggest to put a note in the readme.txt saying what should be done, since > everyone using a Juno will have access to the SCP FW in the board. > > What do you think? Sounds OK. Having everything built automatically is better, but as a first step, it's definitely OK as long as there are explanations in readme.txt. Thanks! Thomas
diff --git a/board/arm/juno/readme.txt b/board/arm/juno/readme.txt index 52fabf9..507ed6d 100644 --- a/board/arm/juno/readme.txt +++ b/board/arm/juno/readme.txt @@ -7,8 +7,8 @@ These instructions apply to all models of the ARM Juno: - Juno r0 (does not support PCIe) - Juno r1 (supports PCIe) -Buildroot will generate the kernel image, device tree blob and a -minimal root filesystem. +Buildroot will generate the kernel image, device tree blob, a minimal +root filesystem, a u-boot binary and ARM Trusted Firmware binaries. How to build it =============== @@ -42,6 +42,21 @@ After building, you should obtain this tree: +-- juno.dtb (if Juno r0 is used) +-- juno-r1.dtb (if Juno r1 is used) +-- Image + +-- u-boot.bin + +-- bl1.bin + +-- bl2.bin + +-- bl2u.bin + +-- bl31.bin + +-- fip.bin + +Other ARM Trusted Firmware options +================================== +If you need to include the bootlader into the fip package, please +configure BR2_TARGET_ATFIRMWARE_PAYLOAD_PATH to specify the path to the +binary. + +If you need to include the SCP Firmware into the fip package please +specify SCP_BL2=<binary_path> in BR2_TARGET_ATFIRMWARE_ADDITIONAL_VARIABLES. Preparing your rootfs ====================== @@ -89,8 +104,8 @@ NOR3LOAD: 00000000 ;Image Load Address NOR3ENTRY: 00000000 ;Image Entry Point ...... -Installing kernel image and DTB -=============================== +Installing kernel image, DTB and bootloader +=========================================== 1. Connect to the ARM Juno UART0 and execute USB_ON in the terminal 2. Connect a USB cable between your PC and ARM Juno USB type B connector @@ -98,7 +113,8 @@ Installing kernel image and DTB 3. Open the software/ folder 4. Copy the 'Image' file to software/ 5. Copy the 'juno-r1.dtb' (r1) or the 'juno.dtb' (r0) file to software/ -6. Press the red button in the front pannel of ARM Juno +6. Copy the 'bl1.bin' and 'fip.bin' files to software/ +7. Press the red button in the front pannel of ARM Juno At this time, the board will erase the Flash entry for each new item and replace it with the lastest ones. diff --git a/configs/arm_juno_defconfig b/configs/arm_juno_defconfig index 87b6374..b94d04c 100644 --- a/configs/arm_juno_defconfig +++ b/configs/arm_juno_defconfig @@ -12,3 +12,15 @@ BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/arm/juno/linux-juno-defconfig" BR2_LINUX_KERNEL_DTS_SUPPORT=y BR2_LINUX_KERNEL_INTREE_DTS_NAME="arm/juno arm/juno-r1" +BR2_TARGET_UBOOT=y +BR2_TARGET_UBOOT_BUILD_SYSTEM_KCONFIG=y +BR2_TARGET_UBOOT_BOARDNAME="vexpress_aemv8a_juno" +BR2_TARGET_UBOOT_CUSTOM_VERSION=y +BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE="2016.03" +BR2_TARGET_ATFIRMWARE=y +BR2_TARGET_ATFIRMWARE_CUSTOM_GIT=y +BR2_TARGET_ATFIRMWARE_VERSION="v1.2" +BR2_TARGET_ATFIRMWARE_CUSTOM_GIT_REPO_URL="https://github.com/ARM-software/arm-trusted-firmware.git" +BR2_TARGET_ATFIRMWARE_CUSTOM_GIT_VERSION="v1.2" +BR2_TARGET_ATFIRMWARE_PLATFORM="juno" +
This patch adds more options to the juno's default configuration file and more content to the readme.txt, regarding the introduction of u-boot and arm trusted firmware build. Signed-off-by: Joao Pinto <jpinto@synopsys.com> --- board/arm/juno/readme.txt | 26 +++++++++++++++++++++----- configs/arm_juno_defconfig | 12 ++++++++++++ 2 files changed, 33 insertions(+), 5 deletions(-)