mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
To: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Lior Amsalem <alior@marvell.com>,
	barebox@lists.infradead.org, Willy Tarreau <w@1wt.eu>,
	Ezequiel Garcia <ezequiel.garcia@free-electrons.com>,
	Jason Cooper <jason@lakedaemon.net>
Subject: Re: [PATCH 2/7] scripts: new kwbimage manipulation tool for Marvell SoC boot images
Date: Mon, 6 May 2013 22:35:40 +0200	[thread overview]
Message-ID: <20130506203540.GC30509@game.jcrosoft.org> (raw)
In-Reply-To: <20130506222104.7ea22be0@skate>

On 22:21 Mon 06 May     , Thomas Petazzoni wrote:
> Hello,
> 
> On Mon, 6 May 2013 21:53:59 +0200, Willy Tarreau wrote:
> 
> > > And it's does not require you to generate the image before flashing.
> > > And request the blob by XMODEM will NEVER work to update at runtime
> > > as can not discuss with the ROM code via XMODEM. So yes this will
> > > not work for self update
> > 
> > You seem to be assuming that the bootloader is already running fine
> > on the box, which is not the case that Thomas has addressed. In order
> > to *flash* the bootloader to the device, you need that DDR3 code to
> > be *executed*, and if you had read his cover mail carefully, you'd
> > have seen that this happens *during* the XMODEM upload sequence
> > (hence the changes to kwboot to protect the upload while this code
> > talks to the serial port). It's painful but that's how it works, and
> > once you get it after all it's rather flexible in the end.
> > 
> > So please don't use your update code as an argument as it's not the
> > interesting part here.
> 
> Just to expand on what Willy explains: the bootable image contains
> essentially 3 things:
> 
>  * A header describing the image
>  * A binary header that contains the binary blob responsible for
>    calculating the DDR3 timings
>  * The payload, which in our case is Barebox.
> 
> When the ROM code sees a bootable image on SPI/NAND, or receives it
> through Xmodem, it sets up the MMU, initializes the L2 cache as SRAM,
> and it copies the header of the image (including the binary header)
> into the SRAM. At this point, it *stops* getting data from Xmodem, and
> executes the binary blob to configure the DDR3. Then, it goes on to
> fetch the rest of the image (i.e the payload) and pushes that directly
> to the DRAM, at an address defined in the header of the image. So the
> DDR3 training code actually gets executed in the *middle* of the Xmodem
> transfer, and the Xmodem transfer cannot continue if the DDR3 timings
> have not been set up properly by the binary blob.
Same principle as on Atmel when you flash via XMODEM or USB Device

This does not means you need to generate any specific media file
> 
> So, when you have in front of your eyes a device with *nothing* on it,
> then you *must* have an image as prepared by kwbimage, that contains
> those three elements: the header, the binary blob, and the payload, and
> you must use the kwboot tool to push it through Xmodem to the SoC.
> 
> For self-update, there is no problem: the same kwbimage tool can
> generate either an image that boots from UART, SPI, NAND or SATA. So
> you can simply flash the generated image wherever you want on a SPI
> flash or NAND flash, reboot and that's it. The image needs to be
> slightly different depending on the boot media, but that's really
> because the Marvell ROM code insists in the image having a 'blockid',
> which identifies on which boot media the image is stored.

this is where it's wrong, you does not need such binary at all, barebox update
will handle this by himself and will never requiere one image per media

As barebox does not care wheren it boot from or where the dev is stored. we
choose is at runtime not at compile time

Barebox update will generate the correct image for the storagemedia at
runtime
> 
> Jean-Christophe, I think you should have a serious look at the boot
> process of Marvell SoC before aggressively telling everybody that they
> are wrong. It's not because you know how AT91 and i.MX are booting that
> you necessarily know the specificities of Marvell SoCs. Remember also
> that the Marvell Armada 370 and XP have a different booting process than
> Marvell Kirkwood (Marvell Kirkwood does not have this mechanism of
> binary blob).

I very well such mecanism ST and ST-Ericsson use similar way. But mandatory to
generate the barebox image for a storage media is a non sense. That's why we
work to have multi-arch. SO no this is in the oposite way of the whole work on
barebox done for months. It's regression
> 
> Best regards,
> 
> Thomas
> -- 
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

  reply	other threads:[~2013-05-06 20:40 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-03 16:51 [PATCH 0/7] Basic support for Marvell Armada 370/XP SoC Thomas Petazzoni
2013-05-03 16:51 ` [PATCH 1/7] scripts: allow lines longer than 80 cols with printf() in checkpatch Thomas Petazzoni
2013-05-06  7:23   ` Sascha Hauer
2013-05-06  7:27     ` Thomas Petazzoni
2013-05-03 16:51 ` [PATCH 2/7] scripts: new kwbimage manipulation tool for Marvell SoC boot images Thomas Petazzoni
2013-05-04 19:51   ` Jean-Christophe PLAGNIOL-VILLARD
2013-05-04 20:32     ` Jason Cooper
2013-05-05  6:40       ` Sascha Hauer
2013-05-05 11:19       ` Jean-Christophe PLAGNIOL-VILLARD
2013-05-05 11:40         ` Willy Tarreau
2013-05-06 13:53         ` Thomas Petazzoni
2013-05-06 13:54           ` Jean-Christophe PLAGNIOL-VILLARD
2013-05-06 14:06             ` Thomas Petazzoni
2013-05-06 14:04               ` Jean-Christophe PLAGNIOL-VILLARD
2013-05-06 14:13                 ` Thomas Petazzoni
2013-05-06 14:14                   ` Jean-Christophe PLAGNIOL-VILLARD
2013-05-06 14:31                     ` Willy Tarreau
2013-05-06 19:34                       ` Jean-Christophe PLAGNIOL-VILLARD
2013-05-06 19:53                         ` Willy Tarreau
2013-05-06 20:21                           ` Thomas Petazzoni
2013-05-06 20:35                             ` Jean-Christophe PLAGNIOL-VILLARD [this message]
2013-05-06 20:44                               ` Thomas Petazzoni
2013-05-06 20:56                                 ` Sascha Hauer
2013-05-06 21:03                                   ` Thomas Petazzoni
2013-05-07  6:31                                     ` Sascha Hauer
2013-05-07  9:33                                     ` Jean-Christophe PLAGNIOL-VILLARD
2013-05-07  9:46                                       ` Willy Tarreau
2013-05-07  9:47                                       ` Sascha Hauer
2013-05-07  9:57                                         ` Thomas Petazzoni
2013-05-06 20:48                               ` Sascha Hauer
2013-05-06 14:21                 ` Jason Cooper
2013-05-06 19:39                   ` Jean-Christophe PLAGNIOL-VILLARD
2013-05-07  6:44         ` Sascha Hauer
2013-05-06 19:41     ` Sascha Hauer
2013-05-06 19:16   ` Sascha Hauer
2013-05-06 20:22     ` Thomas Petazzoni
2013-05-07 23:30   ` Gregory CLEMENT
2013-05-03 16:51 ` [PATCH 3/7] scripts: add kwboot tool Thomas Petazzoni
2013-05-03 16:51 ` [PATCH 4/7] arm: initial support for Marvell Armada 370/XP SoCs Thomas Petazzoni
2013-05-06 14:09   ` Thomas Petazzoni
2013-05-06 14:07     ` Jean-Christophe PLAGNIOL-VILLARD
2013-05-06 14:30     ` Sascha Hauer
2013-05-06 14:34       ` Thomas Petazzoni
2013-05-06 14:46         ` Sascha Hauer
2013-05-06 14:48           ` Thomas Petazzoni
2013-05-03 16:51 ` [PATCH 5/7] arm: add basic support for Armada XP OpenBlocks AX3 platform Thomas Petazzoni
2013-05-05  6:59   ` Sascha Hauer
2013-05-03 16:51 ` [PATCH 6/7] arm: add basic support for the Armada 370 Mirabox platform Thomas Petazzoni
2013-05-03 16:51 ` [PATCH 7/7] arm: add basic support for the Armada XP GP platform Thomas Petazzoni
2013-05-04 17:15 ` [PATCH 0/7] Basic support for Marvell Armada 370/XP SoC Jason Cooper
2013-05-04 17:23   ` Re[2]: " Alexander Shiyan
2013-05-04 17:49     ` Thomas Petazzoni
2013-05-04 17:52       ` Re[2]: " Alexander Shiyan
2013-05-04 17:52   ` Thomas Petazzoni
2013-05-04 18:34     ` Jason Cooper
2013-05-05  6:33     ` Sascha Hauer
2013-05-06 13:54       ` Thomas Petazzoni
2013-05-06 19:28 ` Sascha Hauer
2013-05-06 20:32   ` Thomas Petazzoni
2013-05-07 23:28 ` Gregory CLEMENT
2013-05-07 23:46   ` Gregory CLEMENT
2013-05-08 10:46   ` Thomas Petazzoni
2013-05-08 21:02     ` Gregory CLEMENT

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=20130506203540.GC30509@game.jcrosoft.org \
    --to=plagnioj@jcrosoft.com \
    --cc=alior@marvell.com \
    --cc=barebox@lists.infradead.org \
    --cc=ezequiel.garcia@free-electrons.com \
    --cc=jason@lakedaemon.net \
    --cc=thomas.petazzoni@free-electrons.com \
    --cc=w@1wt.eu \
    /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