Hi all,
Pls find a patch attached to fix the issue of nand hw mode. This will enable the upload of x-loader from u-boot.
I have also upgraded the prompt for onenand since they were given as start and end address and not as offsets.
Pls let me know if you have any comments.
Regards
u-boot-nand-hw-p1.txt (9.13 KB)
Thanks for your patch submission!
A few comments:
1. It would be better if you didn't bundle your patches into one
email/file. I have to separate them by hand before I can apply them
and this increases the chance of something getting screwed up. In
this case a nand patch and a onenand patch would have been
appropriate.
2. Keep each patch/email to a separate chunk of functionality. That
way people can comment on each individually.
3. Patches that aren't omap specific (like the onenand patch) should
go directly to the u-boot mailing list for consideration.
4. It makes sense to include the nand ecc changes in this u-boot git
repo because they are omap specific and can't really be pushed
upstream until we push the board files. I will attempt to separate
those out by hand and apply them. I'll let you know if I run into any
difficulties.
Best regards,
Steve
Pillai, Manikandan wrote:
Hi all,
Pls find a patch attached to fix the issue of nand hw mode. This will enable the upload of x-loader from u-boot.
I have also upgraded the prompt for onenand since they were given as start and end address and not as offsets.
Pls let me know if you have any comments.
Many thanks for the patch!
Besides Steve's comments, some additional remarks:
- Do you like to have a look to
http://wiki.davincidsp.com/index.php?title=Patch_upstream_sending#Patch_rules
?
With increasing traffic at this list, it would be really helpful if you like to improve your subjects to add something like [PATCH] at subject beginning. It would help to recognize patches at list.
- It would be nice if you could add patch description to patch (attachment), too. Not only to mail text. And, additionally, being a little more specific in patch description would help, too. "to fix the issue" isn't really specific. I had to look into patch changes to get an idea what this patch is about.
- Do you have a Beagle (NAND) board, now? If not, maybe Khasim can help? Would be helpful if your patches are not only for one board but for all OMAP3 boards we currently support. Ok, nobody except Steve has overo, yet 
Many thanks for your help
Dirk
Hi all,
Pls find a patch which provides a changes for a single binary image for OMAP3
for NAND/Onenand based boards. I have added a description of the patch at the start of the file.
I was not sure whether to send this patch to this list or the u-boot list but
Since the single image is currently there for OMAP3 I am sending it to this list.
Note: While applying this patch, depending on whether the previous patch is applied, you might have warning for nand_base.c which you can ignore.
Pls let me know your comments.
Regards
Mani
u-boot-single-bin-p1.txt (18.2 KB)
Hi all,
Pls ignore the patches which have been sent for single binary image for NAND and OneNAND flashes. I will generate them again against the common branch and resend them.
In this patch, I am fixing some compilation bugs for jffs2 arising out of the upstream changes in nand header files and adding a default mux configuration for
EVM that support some display configuration.
Pls send in your comments for the same. I am in the process of generating the
Single binary image patch )based on a similar approach for the patch I sent a few days back).
Regards
Mani
u-boot-mux-p1.txt (43.9 KB)
Hi all,
Pls ignore the patches which have been sent for single binary image for NAND and OneNAND flashes. I will generate them again against the common branch and resend them.
In this patch, I am fixing some compilation bugs for jffs2 arising out of the upstream changes in nand header files and adding a default mux configuration for
EVM that support some display configuration.
Could that fix the "no picture on LCD" problem I'm having on the EVM?
regards,
Koen
Hi all,
Pls find attached a patch for generating a single binary image for
EVM. This detects on the fly whether the flash on the board is NAND
or ONENAND and does the proper initialization.
Pls send in your comments.
Regards
Manikandan
u-boot-single-bin-p1.txt (20.3 KB)
Mani,
Pillai, Manikandan wrote:
Hi all,
Pls ignore the patches which have been sent for single binary image for NAND and OneNAND flashes. I will generate them again against the common branch and resend them.
In this patch, I am fixing some compilation bugs for jffs2 arising out of the upstream changes in nand header files and adding a default mux configuration for
EVM that support some display configuration.Pls send in your comments for the same.
Thanks for your patches, they are not forgotten
Some remarks, though:
* In general, Steve and I like to wait with applying (new) patches to
Steve's git until basic OMAP3 support is accepted in upstream U-Boot.
Everything else would result in a lot merge work and confusion. The
next U-Boot merge window is supposed to open at mid of october, so
hopefully OMAP3 support is merged then. Hope it is ok for you to wait
some additional days. Maybe we can work on the topics below until then
* It would be easier to review and understand your patches if you could
a) split the patches in small logical parts with one functionality
change/bugfix in one patch. Having a quick look at changes below this
patch contains at least 3 logical independent parts (mux changes,
minor fixes/clean up, nand & jffs changes)
b) don't mix mails, subjects and patches. In this mail I count 4 (!)
different subjects:
[PATCH] - Fixing some MUX and compilation issues on the OMAP3 EVM
board(Patch1/1)
[PATCH] - Single binary image for NAND/OneNAND based OMAP3 board(Patch1/1)
Patch for fixing the nand hw mode write - Patch(1/1)
[PATCH] Changes for NAND compilation and EVM pin mux.
Quite confusing 
c) send OMAP3 independent patches directly to U-Boot list for inclusion.
* Regarding mux.h I'd like to discuss how we can do this more generic
with less code.
Yes, having a #define MUX_DEFAULT_xxx() for each board in mux.h is the
easiest way. But adding additional mux settings for additional boards
will result in a quite large mux.h, soon. So we should discuss how we
can replace the existing #define MUX_DEFAULT_xxx() with a more generic
and scalable solution.
I think we should have something like one global default mux setting
for all boards and then overwrite the (hopefully small) *different*
board specific parts with something in the board files. E.g. something
like we already do with the "const omap3_sysinfo sysinfo" logic we
introduced recently.
Unfortunately, I don't have an idea how this could look in real code,
yet Any proposals?
Thanks
Dirk