drivers/rtc: add Marvell Integrated RTC.

From: Jason Cooper <[email protected]>

rewrite of the not-merged code from Globalscale Technologies. This RTC is known to exist in the DreamPlug platform and is accessed via two registers.

---
Questions:
- I completely rewrote this, should I add mention of Commercial/GPL2+/BSD (pick your license) source files I based it on?
http://people.debian.org/~clint/dreamplug/dreamplug-uboot-gti.tar.gz
- The link is a dirty git tree. The uncommitted stuff is how they modified Guruplug u-boot to work on the Dreamplug.
- chmod -x the changed files to undo the windows fs stuff.
- the usb storage changes are already in.
- I'm close on the SPI flash stuff.
- This patch is the RTC driver.
- Their MPP cfg is cleaner than mine, I'll use theirs.
- I'll add the clock stuff in a future patch.
- I feel that register definitions should be somewhere else, like SoC code. But I don't know if this is Dreamplug-specific, kirkwood-specific, or other?
- common/cmd_date.c assumes I2C interface, is that harmless?
- common/cmd_date.c checks return value. The register ops have no return value. I assume it's safe to always return zero?
- Is there an easy way to calc the day of the year based on the info in the date register? I don't like leaving that set ot zero.
- This is compile-tested. Once I get back to my Dreamplug, I will test.
- checkpatch has 2 warnings about volatile. My understanding is that it is needed when reading/writing registers.

 drivers/rtc/Makefile        |    1 +
 drivers/rtc/mvinteg_rtc.c   |  151 +++++++++++++++++++++++++++++++++++++++++++
 drivers/rtc/mvinteg_rtc.h   |   89 +++++++++++++++++++++++++
 include/configs/dreamplug.h |    8 ++
 4 files changed, 249 insertions(+), 0 deletions(-)
 create mode 100644 drivers/rtc/mvinteg_rtc.c
 create mode 100644 drivers/rtc/mvinteg_rtc.h

index e4be4a4..ed63e9c 100644
@@ -55,6 +55,7 @@ COBJS-$(CONFIG_MCFRTC) += mcfrtc.o
 COBJS-$(CONFIG_RTC_MK48T59) += mk48t59.o
 COBJS-$(CONFIG_RTC_MPC5200) += mpc5xxx.o
 COBJS-$(CONFIG_RTC_MPC8xx) += mpc8xx.o
+COBJS-$(CONFIG_RTC_MVINTEG) += mvinteg_rtc.o
 COBJS-$(CONFIG_RTC_PCF8563) += pcf8563.o
 COBJS-$(CONFIG_RTC_PL031) += pl031.o
 COBJS-$(CONFIG_RTC_PT7C4338) += pt7c4338.o

index 6aceed9..ed153fe 100644
@@ -109,6 +109,14 @@
 #define CONFIG_SYS_ATA_IDE0_OFFSET	MV_SATA_PORT0_OFFSET
 #endif /*CONFIG_MVSATA_IDE*/
 
+/*
+ * RTC driver configuration
+ */
+#ifdef CONFIG_CMD_DATE
+#define CONFIG_RTC_MVINTEG
+#endif /* CONFIG_CMD_DATE */
+
+
 #define CONFIG_SYS_ALT_MEMTEST
 
 #endif /* _CONFIG_DREAMPLUG_H */

1.7.0.4

Sorry, this is RFC. In the midst of rebase, commit, checkpatch, repeat I forgot to edit the subject line. My apologies.

thx,

Jason.

If I apply this on top of your v4 patch on top of 2011.06, I only need two tweaks to build: MACH_TYPE_DREAMPLUG which will obviously sort itself out, and s/MPP7_GP0/MPP7_GPO/ in board/Marvell/dreamplug/dreamplug.c .

It has not yet been tested on a plug. Do you have a working OpenOCD config for flash/ram?

Yes, what an embarrassing typo, that shouldn't even build. :-( Well, it was RFC...

Sort of. The openocd config for the sheevaplug/guruplug is what I use, and is distributed on the dreamplug download page [1]. It does _not_ have support for the SPI flash. You can also use the sheevaplug.cfg shipped with openocd. So, I use openocd or tftp to transfer to RAM, then use u-boot to write to flash.

To test images, or to reflash, I load the known-good u-boot into RAM via openocd, then I'll either reflash it or load a new testing one from there.

To write a u-boot.kwb test image to flash, here is what I do:

openocd$ sheevaplug_init

openocd$ load_image u-boot                 # known good from Marvell
openocd$ load_image u-boot.kwb 0x00800000  # monster I created
openocd$ resume 0x00600000                 # run the known good

then, in u-boot

u-boot$ sf probe 0
u-boot$ sf erase 0x0 0x100000
u-boot$ sf write 0x00800000 0x0 0x100000

If time allows, I'd like to add SPI flash support to OpenOCD. Unfortunately, time is short and the above process works.

hth,

Jason.

[1]
http://code.google.com/p/dreamplug/downloads/detail?name=dream_burn_spi.tar.bz2&can=2&q=

Okay, here's neat problem. In the globalscale u-boot code, they set the environment address to 0x30000 in the 2MB spi nor flash. So, they have:

#ifdef CONFIG_SPI_FLASH
#define CONFIG_ENV_IS_IN_SPI_FLASH 1
#define CONFIG_ENV_SECT_SIZE 0x10000 /* 64K */
#else
#define CONFIG_ENV_IS_NOWHERE 1 /* if env in SDRAM */
#endif

and...

#define CONFIG_ENV_SIZE 0x1000 /* 4k */
#define CONFIG_ENV_ADDR 0x30000
#define CONFIG_ENV_OFFSET 0x30000 /* env starts here */

If that's an absolute address, and I wrote my u-boot to 0x0 in the flash, did 'saveenv' to remove the CRC message, then that's why it died after reset, right? I must have overwrote part of u-boot with the env.

In my meager understanding, I thought maybe u-boot structured itself so the env was physically stored 0x30000 into the code and it would magically work. Guess not. :-P

So, what is a standard flash layout? Do I put u-boot at 0x0 and just throw the env out at 0x100000 (1MB), or, put the env at 0x0 and u-boot in the second erase block (0x10000)? Doesn't u-boot have to be at 0x0 so the cpu can find it?

Thanks for any advice.

btw - I have everything else tested and working. RTC, spi flash, cpu speed, etc. This issue is the last holdout before I resubmit v5.

thx,

Jason.

Hi Jason,

We same to be having some issues with USB support with your v4 set, particularly that it's unhappy with the internal microsd card. Any ideas?

try v5. patch #3 increases the timeout waiting for slow usb chipsets, which works for me.

In the meantime, I'm going to take a more careful look at the usb changes in the tarball you sent me. I checked a few lines of it and it looked like a backported patch that was already in mainline, but I didn't check the whole thing. I'll do so when I address all of Prafulla's comments.

hth,

Jason.