From: Tom Rini <trini@konsulko.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] Booting Wandboard through USB
Date: Tue, 2 Jun 2015 10:25:22 -0400 [thread overview]
Message-ID: <20150602142522.GP1728@bill-the-cat> (raw)
In-Reply-To: <CAJ+vNU0cVMCk++vtW3j1G4MhXH8nxvZjUw4-H9TO_CcDPp7W0w@mail.gmail.com>
On Mon, Jun 01, 2015 at 09:38:18AM -0700, Tim Harvey wrote:
[snip]
> Honestly I've never used fsl's mfgtool and never want to. I think its
> way more complicated than a scrip-table linux solution with very few
> dependencies (imx_usb_loader) and IMHO I think we should not be
> encumbered with fitting that complicated mould but instead work on
> breaking it by providing better options.
The counter-point that we can't just dismiss is that we want companies
on mainline. Today many use the Freescale mfgtool (which is a big
wrapper around shoving u-boot.imx over and booting a kernel + ramdisk
into Linux and then flashing the board. A solution that continues to
work within this framework removes a barrier from getting them on
mainline (and from Freescale shipping a more recent version of U-Boot
with their refernce SW).
Thinking about this a bit, as near as I can tell the way the mfgtool
(and for that matter, imx_usb_loader when passing in multiple files)
works is to use the header of u-boot.imx (or whatever...) to initialize
DDR, then start taking files and putting them in. Could we not add some
debug (or opt-in CONFIG statement) that would cause SPL to spit out in
essence the values to plug into a template for header-based DDR init?
That way the mfgtool itself will continue working and instead of being
told to use u-boot.imx it's given a script (which iirc it supports) and
u-boot.img to run and it's normal loads of everything to flash. Roughly
speaking :)
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150602/efbc01d4/attachment.sig>
next prev parent reply other threads:[~2015-06-02 14:25 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-29 9:46 [U-Boot] Booting Wandboard through USB Vincent Stehlé
2015-05-30 16:49 ` Tom Rini
2015-05-30 17:24 ` Vincent Stehlé
2015-05-30 20:09 ` Eric Nelson
2015-05-30 20:38 ` Tom Rini
2015-05-31 22:54 ` Nikolay Dimitrov
2015-05-31 23:15 ` Nikolay Dimitrov
2015-06-01 8:10 ` Stefano Babic
2015-06-01 16:03 ` Tim Harvey
2015-06-01 16:28 ` Nikolay Dimitrov
2015-06-01 16:38 ` Tim Harvey
2015-06-02 14:25 ` Tom Rini [this message]
2015-06-02 15:00 ` Tim Harvey
2015-06-01 16:08 ` Nikolay Dimitrov
2015-05-30 17:41 ` Eric Nelson
2015-05-30 19:25 ` Tom Rini
2015-05-30 19:53 ` Eric Nelson
2015-07-24 0:59 ` Fabio Estevam
2015-05-30 16:49 ` Fabio Estevam
-- strict thread matches above, loose matches on Subject: below --
2017-07-27 9:05 Vincent Prince
2017-07-27 20:54 ` Wolfgang Denk
2017-08-05 12:22 ` Fabio Estevam
2017-08-05 13:44 ` Vincent Prince
2017-08-05 15:46 ` Tom Rini
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=20150602142522.GP1728@bill-the-cat \
--to=trini@konsulko.com \
--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