[U-Boot] [PATCH] ventana: Add Gateworks Ventana family support

Stefano Babic sbabic at denx.de
Wed Jan 29 09:19:44 CET 2014


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
=====================================================================


More information about the U-Boot mailing list