From: Stefano Babic <sbabic@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] ventana: Add Gateworks Ventana family support
Date: Wed, 29 Jan 2014 09:19:44 +0100 [thread overview]
Message-ID: <52E8B9A0.8090206@denx.de> (raw)
In-Reply-To: <CAJ+vNU07VZWmvJ0wyOTdachKXR-xTp+VreYSKJ+4BcHkHFcc+A@mail.gmail.com>
Hi Tim,
On 29/01/2014 02:26, Tim Harvey wrote:
>
> I should not have used the word 'header'.
>
> I _am_ talking about the Image Vector Table (IVT) and Device
> Configuration Data (DCD) data structures that the IMX6 BOOT ROM needs
> to boot and which are present in u-boot.imx.
Right.
> The kobs-ng (at least
> for IMX6) needs u-boot.imx because it contains these structures built
> from imximage and it must flash them onto the boot media.
ok, got it. My suggestion is then only to headline that kons-ng uses a
imximage, that contains IVT and DCD.
>
>>
>> As far as I know, kobs-ng is a flasher - a utility to install u-boot on
>> the target. It is not the only method to install the binary. I think you
>> should rework the text making the statements more clearer.
>
> Can you re-read the README instructions? Other than the bad link I
> feel they are very clear. I think perhaps your thinking that I was in
> error specifying that kobs-ng needing u-boot.imx added to some
> confusion?
Yes, it had confused me. IMHO you could add that kobs-ng adds the FCB
structure that it is not (yet) provided by imximage.
>>
>> If as I think kobs-ng is only a flasher, it does not take part to the
>> build of U-Boot binaries. IMHO it should be not part of U-Boot sources,
>> but maybe there are some features that can be interesting.
>>
>
> I was not referring to making the code a part of uboot sources but
> adding the functionality that it provides such that one could use
> uboot to update itself on an IMX NAND device. I'm actually surprised
> nobody has done this before for IMX in general as its a bit
> inconvenient to boot to a linux based OS in order to run kobs-ng to
> flash the bootloader.
> Regardless, this would be functionality added
> later.
It would be great. Of course, it will be great if we can flash NAND
exactly as we do for other SOCs. We will need to improve imximage to add
the FCB at the beginning of the image.
>
> It appears the only other mainlined IMX6 bootloader to support NAND is
> the Titanium and there is no README for it at all. If there were, I
> would expect it to say pretty much the same thing that my proposed
> Ventana README states. There was a comment by Fabio on original
> titanium patch to include a README explaining how to flash and boot
> from NAND but it apparently didn't make it in:
> http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/158436/focus=158441
Good point. Stefan, how do you flash the titanium ? At the moment I do
not see any other way as using the kobs-ng. Or do you have some early
improvement for mkimage adding the FCB/DBBT data ?
>
> No - the only communication channel to the GSC is the i2c bus. The
> only way it has to respond is to ACK or fail to ACK (aka NAK) within
> the i2c bit time (aka NAK). The device does not and can not support
> i2c clock stretching. The nature of GSC is such that the worst case
> failure when talking at 100kbps will be at most 2 times in a row (due
> to the latency of the timer tick) which is why I have a retry of 3.
ok - I think it will be cleaner if you split your patch and move gsc
code in a separate file, still in your board directory. I understand the
point - if the hardware does not provide any way to check if it is busy,
it is ok to retry when first access fails.
>> If it is at the moment dead code, please remove. Dead code that passes a
>> review will only confuse people.
>
> once I realized I could #define CONFIG_DISPLAY_BOARDINFO_LATE to make
> checkconfig() run after relocation I no longer needed to have EEPROM
> read prior to relocation and that removed the need for this structure
> to be in the data segement. I still have the structure so that eeprom
> can be read just once (as its used in several places) but it no longer
> needs to be in the data segment so the attribute will be removed in
> the next patch version.
Fine.
Best regards,
Stefano Babic
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================
next prev parent reply other threads:[~2014-01-29 8:19 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-21 18:41 [U-Boot] [PATCH] ventana: Add Gateworks Ventana family support Tim Harvey
2014-01-27 11:57 ` Fabio Estevam
2014-01-27 17:53 ` Tim Harvey
2014-01-27 14:39 ` Stefano Babic
2014-01-27 23:36 ` Tim Harvey
2014-01-28 10:20 ` Stefano Babic
2014-01-29 1:26 ` Tim Harvey
2014-01-29 7:07 ` Stefan Roese
2014-01-29 8:19 ` Stefano Babic [this message]
2014-01-29 8:36 ` Stefan Roese
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=52E8B9A0.8090206@denx.de \
--to=sbabic@denx.de \
--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;
as well as URLs for NNTP newsgroup(s).