Patch series to add OMAP3 EVM support to Sakoman's u-boot Tree

GoogleGroups
1

Hi all,

I started working on getting OMAP3 EVM support on u-boot GIT, but later realized that similar development was on going for Beagle. I thought of working with you guys for getting EVM support on Sakoman's u-boot GIT branch and then do the additional cleanup and help in getting EVM and Beagle support on u-boot V1 GIT tree.

As part of my work, I am here by presenting a set of three patches that add EVM support to Sakoman's u-boot, kindly review the same and if no issues found I would request Sakoman to merge this onto his branch. Will continue my development on this branch further

Regards,
Mani

2

Pillai, Manikandan wrote:

I started working on getting OMAP3 EVM support on u-boot GIT, but later realized that similar development was on going for Beagle. I thought of working with you guys for getting EVM support on Sakoman's u-boot GIT branch and then do the additional cleanup and help in getting EVM and Beagle support on u-boot V1 GIT tree.

This sounds really great! Yes, we really need some additional help for cleanup. Maybe you already know the short status I wrote some days ago about Sakoman's u-boot GIT branch:

http://groups.google.com/group/beagleboard/browse_thread/thread/0f1991bbc9318fe0#

For the archives: Sakoman's u-boot GIT we talk about here can be found at

http://www.sakoman.net/cgi-bin/gitweb.cgi?p=u-boot-omap3.git;a=summary

As part of my work, I am here by presenting a set of three patches that add EVM support to Sakoman's u-boot, kindly review

I will do so, give me some days :wink:

To answer some more points from today's IRC:

- Additional board support, e.g. Pandora: Yes, this is welcome. While starting it will be some more work, but having e.g. three boards (e.g. Beagle, EVM and Pandora) will really help us to identify common code and let us optimize for future boards.

- Compiler: Yes, CSL 2008Q1 results in uboot I2C timeouts. So use 007Q3/Q1 for uboot. I observed this, too.

Mani and Khasim: At IRC it sounds like you are looking into this. If you have an idea, please let us know.

the same and if no issues found I would request Sakoman to merge this onto his branch. Will continue my development on this branch further

Many thanks for your patches

Dirk

3

Mani,

Thanks for the patches! Unfortunately I ran into a lot of the same
issues that Dirk did.

Could you run your patches through the kernel checkpatch script and
fix the things it complains about?

Passing checkpatch makes it much easier to ensure a clean merge on my
end. Otherwise I have to start doing hand edits and the odds of
messing something up increase :wink:

Thanks again!

Steve

4

Hi all,

I am re-sending the patch (1/3) for support of EVM boards. Since I had issues with earlier mail on the format, I am

sending this one as as attachments. I have run the checkpatch scripts and fixed the relevant warnings.

Pls let me know your comments. I will be sending the remaining two patches by today evening.

Regards

Mani

u-boot-omap3-p1.txt (84.8 KB)

5

Hi Mani,

Pillai, Manikandan wrote:

Hi all,

I am re-sending the patch (1/3) for support of EVM boards. Since I had
issues with earlier mail on the format, I am

sending this one as as attachments.

Attachments are fine on this list, better than having reformats by
some mail tools. We are not uboot here :wink:

I have run the checkpatch scripts
and fixed the relevant warnings.

Pls let me know your comments. I will be sending the remaining two
patches by today evening.

Many thanks!

As usual, give us some days to have a look.

Dirk

6

Hi all,

Pls find the Patch 2/3 for support of Ethernet on OMAP3EVM.
I have reused the existing 911x source code for supporting the Ethernet rather than adding a new file.

The tftp size has been changed back to 512 - After a tftp is done for the kernel
And/or filesystem the downloaded image does not work. (On diving more, I found that there are some memory corruptions at offsets of 0x4F8.)

Pls send me your comments.

Thanks and Regards
Mani

u-boot-omap3-p2.txt (16.2 KB)

7

Hi Mani,

Pillai, Manikandan wrote:

I am re-sending the patch (1/3) for support of EVM boards. Since I had issues with earlier mail on the format, I am

sending this one as as attachments. I have run the checkpatch scripts and fixed the relevant warnings.

Thanks! There is a small pitfall, though. Kernel's checkpatch script is a moving target. It may change from kernel version to kernel version. Most probably this is the reason why I still get some warnings with the checkpatch script from my 2.6.26-omap1 kernel. For reference, I attach the result.

Pls let me know your comments. I will be sending the remaining two patches by today evening.

diff --git a/Makefile b/Makefile
index e9bf61a..bc6da92 100644
--- a/Makefile
+++ b/Makefile
@@ -2570,6 +2570,9 @@ SMN42_config : unconfig
omap3530beagle_config : unconfig
   @./mkconfig $(@:_config=) arm omap3 omap3530beagle
+omap3evm_config : unconfig
+ @./mkconfig $(@:_config=) arm omap3 omap3evm
+

Can you please use @$(MKCONFIG) here. Yes, we did it wrong for Beagle, too.

diff --git a/board/omap3evm/sys_info.c b/board/omap3evm/sys_info.c
new file mode 100644
index 0000000..a07e94b
--- /dev/null
+++ b/board/omap3evm/sys_info.c

+/**************************************************************************
+ * get_gpmc0_type()
+ ***************************************************************************/
+u32 get_gpmc0_type(void)
+{
+ /* Default NAND */
+ return (2);
+}

Here you should return 1 for OneNand. Thanks to Steve for this hint.

Regarding NAND driver there seems to be an issue with it. Steve reports:

"onenand doesn't work. detects the hw just fine, but erase read and write silently fail unless you turn on mtd debugging. then there is just enough delay that it starts to work."

Dirk

checkpatch_p1.txt (9.77 KB)

8

Dirk Behme wrote:

+u32 get_gpmc0_type(void)
+{
+ /* Default NAND */
+ return (2);
+}

Here you should return 1 for OneNand. Thanks to Steve for this hint.

Regarding NAND driver there seems to be an issue with it. Steve reports:

"onenand doesn't work. detects the hw just fine, but erase read and write silently fail unless you turn on mtd debugging. then there is just enough delay that it starts to work."

fyi, see IRC log

http://www.beagleboard.org/irclogs/index.php?date=2008-07-25#T15:32:50

for more details regarding this.

Dirk

9

Hi all,

Hope to get it right this time. I am attaching patch (1/2) for OMAP3EVM support I have tried to fix the relevant comments.

This patch provides OMAP3EVM support on UBoot.

Regards
Mani

omap3evm_patch1.txt (84.6 KB)

10

Mani,

Pillai, Manikandan wrote:

Hope to get it right this time.

Yes.

http://www.sakoman.net/cgi-bin/gitweb.cgi?p=u-boot-omap3.git;a=commit;h=9867aa192ea0ed0c797ea2a2b8c48ab919b80e4c

http://www.sakoman.net/cgi-bin/gitweb.cgi?p=u-boot-omap3.git;a=commit;h=b2980a3b0e5bcd6b3696e579e76eeb06276df79b

:slight_smile:

Thanks for your help!

Hopfully you like to help with further uboot v1 clean up now to get it upstream ready. If interested, maybe you like to have a look to (a) - (h) at

http://groups.google.com/group/beagleboard/browse_thread/thread/0f1991bbc9318fe0#

Thanks

Dirk

11

Hi all,

Pls find attached the patch for I2C timeout errors.

I had initially thought the problem to be related to the compiler. Diving deep found that for some reason due to divide by 0, the compiler generates wrong values for writing to a register. This was happening because of I2C_SPEED being
passed as 100 rather than 100000 (for 100KB).

Pls review the patch and send me your comments. Meanwhile, I will get to some
of the cleanup activities.

Regards
Mani

u-boot-i2c-p1.txt (733 Bytes)

12

Pillai, Manikandan wrote:

Hi all,

Pls find attached the patch for I2C timeout errors.

Many thanks! Will try it.

Dirk

13

Hi all,

Pls find attached the patch(1/1) to fix issues regarding offset values to be given while using onenand command for read/write/erase ... operations.

Pls let me know your comments.

Regards
Mani

u-boot-onnd-p1.txt (5.57 KB)

14

Mani,

Thanks!

Pushed this evening -- also for overo and beagle

Steve

PS: x-load also had this issue, fixed there too

15

Mani,

The patch, as written, will break overo! I want to be carefull to
keep evm, beagle, and overo working.

We should also probably separate this into two patches: one to fix the
offset bug for evm, beagle, and overo; and a second to add the
'onenand erase block' command.

Regards,

Steve

16

Oops! My mistake, it won't break overo. I should get some sleep :slight_smile:

It *might* break other machines that currently expect the offset to be
subtracted, so it could be an issue getting this patch accepted
upstream. That was the reason I originally structured the overo fix
the way that I did - the behaviour did not change for non-overo
machines.

That said, I suspect that users of other machines that include onenand
are also annoyed by this bizzare behavior. So we might get a welcome
reception if we propose a patch that fixes it for all machines that
use onenand.

Steve

17

Steve, Mani,

Steve Sakoman wrote:

Oops! My mistake, it won't break overo. I should get some sleep :slight_smile:

It *might* break other machines that currently expect the offset to be
subtracted, so it could be an issue getting this patch accepted
upstream. That was the reason I originally structured the overo fix
the way that I did - the behaviour did not change for non-overo
machines.

That said, I suspect that users of other machines that include onenand
are also annoyed by this bizzare behavior. So we might get a welcome
reception if we propose a patch that fixes it for all machines that
use onenand.

I like to send something like in attachment as RFC to U-Boot list.

Do you like to have a look to it if I got it right? Do you like this?

Many thanks

Dirk

remove_onenand_base_address_offset.txt (3.16 KB)

18

Dirk,

Looks good to me.

Steve

19

Dirk,

I see the patch has already be accepted upstream. Good work!

You might also want to consider submitting this one:

http://www.sakoman.net/cgi-bin/gitweb.cgi?p=u-boot-omap3.git;a=commit;h=8406a19891788a3d86f6d20d6c3fa64e6db71616

I merged with upstream -- sadly one of the upstream commits (actually
a revert) broke the build. It introduces an extra #endif.

I'm testing a patch to fix this.

Thanks!

Steve

20

Steve,

Steve Sakoman wrote:

Dirk,

I see the patch has already be accepted upstream. Good work!

You might also want to consider submitting this one:

http://www.sakoman.net/cgi-bin/gitweb.cgi?p=u-boot-omap3.git;a=commit;h=8406a19891788a3d86f6d20d6c3fa64e6db71616

Done.

I merged with upstream -- sadly one of the upstream commits (actually
a revert) broke the build. It introduces an extra #endif.

I'm testing a patch to fix this.

Sent this fix, too. And got immediately a response pointing to a larger patch for this. I didn't follow this autostart discussion, but seems that there is something additional broken. E.g. apollon build stops with

bootm.c: In function 'do_bootm_linux':
bootm.c:140: error: 'bootm_headers_t' has no member named 'autostart'
bootm.c:160: error: 'bootm_headers_t' has no member named 'autostart'

Let us see which solution Wolfgang will take.

Many thanks

Dirk