All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joao Pinto <Joao.Pinto@synopsys.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] uboot build and deploy added to juno board
Date: Thu, 21 Apr 2016 17:35:54 +0100	[thread overview]
Message-ID: <5719016A.1020303@synopsys.com> (raw)
In-Reply-To: <20160421132639.16cd8714@free-electrons.com>

Hi Thomas,

I developed the atfirmware config and I am having problems in the Makefile.
How does the buildroot structure git clones / untar / etc.? I suppose there is a
common spot to do these stuff right?

Send in attchment tarball of the new package. I am thinking of adding it to
Bootloaders. What do you think?

Thanks.
Joao


On 4/21/2016 12:26 PM, Thomas Petazzoni wrote:
> Hello,
> 
> On Thu, 21 Apr 2016 11:34:02 +0100, Joao Pinto wrote:
> 
>>> The whole point of Buildroot is to automate the build process, so this
>>> should be done by a Buildroot package, rather than manually by the
>>> user. So a package for ATF should probably be created.
>>>
>>> I also work on an ARM64 platform that uses ATF+U-Boot, so I'll be able
>>> to compare and tell you whether what you're proposing is only
>>> applicable to Juno, or can be used for other platforms as well.
>>
>> It would great to do it 100% automatic. I'll be waiting for your feedback
>> regarding your ARM64 platform. If it is the same we could do it together.
> 
> Well, the build process is quite similar. I build ATF with:
> 
>   make CROSS_COMPILE=aarch64-linux-gnu- BL33=/path/to/uboot USE_COHERENT_MEM=0 PLAT=<platform> DEBUG=1 LOG_LEVEL=20 all fip
> 
> I think DEBUG=1 and LOG_LEVEL=20 are not important, but I think the
> PLAT= and USE_COHERENT_MEM= variables are important in my case.
> 
> So I guess you do do something like:
> 
>   make CROSS_COMPILE=$(TARGET_CROSS) \
> 	BL33=$(call qstrip,$(BR2_BOOT_ATF_PAYLOAD_PATH) \
> 	$(BR2_BOOT_ATF_ADDITIONAL_VARIABLES) \
> 	all fip
> 
> and that's it. Of course, the location from where you download ATF
> should be configurable, because I'm not using the ATF from ARM
> directly, but a vendor-specific fork.
> 
> Thanks!
> 
> Thomas
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: atfirmware.tar
Type: application/octet-stream
Size: 10240 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20160421/805748f2/attachment.obj>

  reply	other threads:[~2016-04-21 16:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-20 17:47 [Buildroot] [PATCH] uboot build and deploy added to juno board Joao Pinto
2016-04-20 20:02 ` Thomas Petazzoni
2016-04-21 10:34   ` Joao Pinto
2016-04-21 11:26     ` Thomas Petazzoni
2016-04-21 16:35       ` Joao Pinto [this message]
2016-04-21 19:28         ` Thomas Petazzoni
2016-04-21 20:55 ` Arnout Vandecappelle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5719016A.1020303@synopsys.com \
    --to=joao.pinto@synopsys.com \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.