public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Paul Chavent <Paul.Chavent@onera.fr>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] arm/da850 : [RFC] add bootdsp to cmd_elf
Date: Thu, 30 Jan 2014 08:55:36 +0100	[thread overview]
Message-ID: <52EA0578.50106@onera.fr> (raw)
In-Reply-To: <20140129223733.GB3277@bill-the-cat>



On 01/29/2014 11:37 PM, Tom Rini wrote:
> On Mon, Jan 27, 2014 at 05:28:22PM +0100, Paul Chavent wrote:
>
>> On platform with a DSP co-processor, add a command to boot an elf on
>> it.
>>
>> * Test *
>>
>> This patch has been tested on an OMAP-L138 EVM with DSP code generated
>> with TI's code generation tools 7.4.6 with the --abi=eabi option.
>>
>> * Bugs *
>>
>> Some elf generated with older TI's cgt have mis-aligned header
>> sections that lead to u-boot freeze. This point can be checked with
>> readelf (see "Start of program headers" and/or "Start of section
>> headers") if you experience such problem.
>>
>> * Discussion *
>>
>> Our first question is about the interest of the u-boot community for
>> this feature ?
>>
>> For the implementation, we tried to separate platform specific code
>> (dsp's reset and entry point) from the elf generic code (check and
>> load elf in memory). We would like to have your opinion on this
>> design.
>>
>
> This seems like the right direction to take for things.  The question I
> have first is, are we talking about loading something into the DSP and
> then letting it go, or are we talking about getting a result back from
> the DSP in Linux?  I assume the first case.
>

Thank you for having considered the patch.

Indeed, this is about loading something into the DSP and then letting it 
go without worrying about the result.

In our use case however, later, the ARM run some programs (under Linux) 
that will use services provided by the DSP through its L2 cache used as 
shared memory. Ideally, we would like to be able to soft reset the ARM 
without killing the DSP that will run the critical code that should 
survive to hight level apps failures...

I wait for your advices to improve the patch integration (I'm not sure 
that the "extern" declarations on top of cmd_elf.c will be integrated 
like that).
Moreover, i wonder if we should begin to think about a more generic 
"boot_companion" function that would introduce a framework in order to 
boot companion cpu... but perhaps it's a bit premature.

Regards.

Paul Chavent.

      reply	other threads:[~2014-01-30  7:55 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-27 16:28 [U-Boot] [PATCH] arm/da850 : [RFC] add bootdsp to cmd_elf Paul Chavent
2014-01-29 22:37 ` Tom Rini
2014-01-30  7:55   ` Paul Chavent [this message]

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=52EA0578.50106@onera.fr \
    --to=paul.chavent@onera.fr \
    --cc=u-boot@lists.denx.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox