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