[U-Boot-Users] RTC for MPC5200

[U-Boot-Users] RTC for MPC5200

[Victor Wren]

Good morning.  I have a couple of questions.  After struggling with an initrd
boot for a few days, I said "heck with it" and just made /dev/hda2 my root
device.  Given that the kernel is in flash, and the devices I need are
compiled in (and I don't have module support), is there any reason to
mess around with an initrd-style boot, given that we absolutely know 
what the hardware config is going to be?  It works like a charm with the 
default DENX Sys-V init, from the ppc-82xx tree, by the way, though I will
have to prune some services.

The other question regards the real time clock on the MPC5200.  Unless I am
seriously overlooking something, this does not appear to be implemented, yet,
yes?  The register structure doesn't look too arcane.  Is anybody working on
this?  I am tempted, but nobody wants to roll in code from a rank novice.  The
project we're working on needs a self-contained clock.  I notice that u-boot
provides rtc services, but isn't that more properly a kernel function?  I'm
a little fuzzy on the dividing line.

Thanks!
Victor Wren

[U-Boot-Users] RTC for MPC5200

[Wolfgang Denk]

In message <20040108210501.GA4693@timension.com> you wrote:
> Good morning.  I have a couple of questions.  After struggling with an initrd

What exactly is the problem? The procedure is fairly well  documented
in the DULG, and a ready-to-run image is supplied with the ELDK. Just
boot it...

> boot for a few days, I said "heck with it" and just made /dev/hda2 my root
> device.  Given that the kernel is in flash, and the devices I need are
> compiled in (and I don't have module support), is there any reason to
> mess around with an initrd-style boot, given that we absolutely know 
> what the hardware config is going to be?  It works like a charm with the 

A ramdisk image (loaded from flash) is one way to provide an embedded
system  that  is  100%  bullet-proof  agains  unexpected  reboots  or
power-cycling.

> default DENX Sys-V init, from the ppc-82xx tree, by the way, though I will
> have to prune some services.

Also, a more leaner setup like the busybox-based SELF  used  for  our
defualt  ramdisk  images  boots much, much faster than the full-blown
SysV init stuff.

> The other question regards the real time clock on the MPC5200.  Unless I am
> seriously overlooking something, this does not appear to be implemented, yet,
> yes?  The register structure doesn't look too arcane.  Is anybody working on
> this?  I am tempted, but nobody wants to roll in code from a rank novice.  The

You  will  not  be  judged  by  years  of  experience,  or   by   any
certificates. It's just the quality of the code that matters :-)

Seriously: don't worry, just go on, do it, and submit a patch. If  it
needs improvements somebody else will help.

> project we're working on needs a self-contained clock.  I notice that u-boot
> provides rtc services, but isn't that more properly a kernel function?  I'm
> a little fuzzy on the dividing line.

Support for the RTC is not exactly needed in U-Boot. But it  is  very
convenient.  It  is  much easier to debug in U-Boot, and you can just
test in the firmware  if  the  RTC  is  really  running  iunstead  of
debugging  a  Linux device driver. Also, the clock on some RTCs needs
to get started before you can use them.  Not  all  Linux  drivers  do
that.

Best regards,

Wolfgang Denk

-- 
See us @ Embedded World, Nuremberg, Feb 17 - 19,  Hall 12.0 Booth 440
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
"How to make a million dollars:  First, get a million dollars."
- Steve Martin

[U-Boot-Users] RTC for MPC5200

[Victor Wren]

On Thu, Jan 08, 2004 at 11:56:52PM +0100, Wolfgang Denk wrote:
> 
> What exactly is the problem? The procedure is fairly well  documented
> in the DULG, and a ready-to-run image is supplied with the ELDK. Just
> boot it...

Oh, it boots, no problem.  What I'm having trouble with (inexperience) is
changing the root filesystem after and cutting all ties to busybox so that
I can unmount the ramdisk.  The closest I've gotten to booting is with

mount /dev/hda2 /mnt
cd /mnt
pivot_root . /mnt/initrd 
chroot . /etc/rc.sysinit <dev/console >dev/console 2>&1

But after that, I'm still running busybox, and when the "application" process
expires, it starts berating me.  Of course, I can't umount /initrd because
it's still occupied.   I've read up all I can find on the boot
process using initrd, and haven't found much specifics about handing over
control from one init process to another.

> A ramdisk image (loaded from flash) is one way to provide an embedded
> system  that  is  100%  bullet-proof  agains  unexpected  reboots  or
> power-cycling.

Well, this does have a hard drive attached, so there will still be some 
issues with filesystem recovery in case of accidents.  I'm using this 
more like a mini-server than an embedded system.

> Also, a more leaner setup like the busybox-based SELF  used  for  our
> defualt  ramdisk  images  boots much, much faster than the full-blown
> SysV init stuff.

It certainly does.  My cable box should start so fast.  

> You  will  not  be  judged  by  years  of  experience,  or   by   any
> certificates. It's just the quality of the code that matters :-)

That's what worries me. :-)  In my case, the years of experience were too
many years ago.  Last time I did much low-level code munching was on my Atari
ST.  MMUs were after my time.

Victor Wren

[U-Boot-Users] RTC for MPC5200

[Wolfgang Denk]

In message <20040109002314.GA5148@timension.com> you wrote:
> 
> Oh, it boots, no problem.  What I'm having trouble with (inexperience) is
> changing the root filesystem after and cutting all ties to busybox so that
> I can unmount the ramdisk.  The closest I've gotten to booting is with

Why do you want to  do  that?  If  you  want  a  ramdisk  based  root
filesystem  then use that. If you wand a root filesystem on harddisk,
that use that. I see no need  (and  no  sense)  in  booting  with  an
initial ramdisk and then switching to a harddisk.

> But after that, I'm still running busybox, and when the "application" process
> expires, it starts berating me.  Of course, I can't umount /initrd because

Well, remove the "application" process and the network  servers  from
/etc/inittab?

> it's still occupied.   I've read up all I can find on the boot
> process using initrd, and haven't found much specifics about handing over
> control from one init process to another.

You have to design your system. You must  understand  which  services
are needed where, and use those, but not anything else. It definitely
makes  no  sense  to start network servers and application stuff that
keeps running in the background if you later intend to pivot_root  to
a different filesystem.


Best regards,

Wolfgang Denk

-- 
See us @ Embedded World, Nuremberg, Feb 17 - 19,  Hall 12.0 Booth 440
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
HR Manager to job candidate "I see you've had no  computer  training.
Although  that  qualifies  you  for upper management, it means you're
under-qualified for our entry level positions."

[U-Boot-Users] RTC for MPC5200

[Reinhard Meyer]

What good is a RTC that has no separate backup power pin?

It will only keep running as long as main power is applied to the 5200. Of
course you can minimise power consumption by shutting down everything in the
5200, but still you will not have a real RTC with GoldCap or Lithium
Battery.

my 0.01 Euros ;)

Reinhard

----- Original Message -----

> The other question regards the real time clock on the MPC5200.  Unless I
am
> seriously overlooking something, this does not appear to be implemented,
yet,
> yes?  The register structure doesn't look too arcane.  Is anybody working
on
> this?  I am tempted, but nobody wants to roll in code from a rank novice.
The
> project we're working on needs a self-contained clock.  I notice that
u-boot
> provides rtc services, but isn't that more properly a kernel function?
I'm
> a little fuzzy on the dividing line.

[U-Boot-Users] RTC for MPC5200

[Reinhard Meyer]

Hello,

attached find mpc5200.c to support the MPC5200 RTC

Instructions to use:

put mpc5200.c into the u-boot/rtc folder:

add mpd5200.o to the Makefile in this folder:

OBJS = date.o   \
   ds12887.o ds1302.o ds1306.o ds1307.o ds1337.o \
   ds1556.o ds164x.o ds174x.o \
   m41t11.o m48t35ax.o mc146818.o mk48t59.o \
   mpc8xx.o pcf8563.o s3c24x0_rtc.o mpc5200.o

add
#define CONFIG_RTC_MPC5200 1 /* use 5200 RTC */
and add CFG_CMD_DATE to your CONFIG_COMMANDS

and it should work.

I only tested it on our own hardware (TOP5200), we do not own any IceCube
development boards.

for Wolfgang:
CHANGELOG:
* Patch by Reinhard Meyer, 09 Jan 2004:
  - added RTC support for MPC5200 based boards (requires RTC_XTAL)

Reinhard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mpc5200.zip
Type: application/x-zip-compressed
Size: 1681 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20040109/583948e6/attachment.bin 

[U-Boot-Users] RTC for MPC5200

[Wolfgang Denk]

In message <033d01c3d6ec$decf7670$6d4ba8c0@alb.sub.de> you wrote:
> 
> attached find mpc5200.c to support the MPC5200 RTC

Added (as rtc/5xxx.c).

> Instructions to use:
> 
> put mpc5200.c into the u-boot/rtc folder:
> 
> add mpd5200.o to the Makefile in this folder:
...

No. This is not acceptable. Will you please  submit  a  proper  patch
including all these modifications next time? Thanks.

Best regards,

Wolfgang Denk

-- 
See us @ Embedded World, Nuremberg, Feb 17 - 19,  Hall 12.0 Booth 440
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
There comes to all races an ultimate crisis which  you  have  yet  to
face  ....  One  day  our  minds became so powerful we dared think of
ourselves as gods.
	-- Sargon, "Return to Tomorrow", stardate 4768.3

[U-Boot-Users] RTC for MPC5200

[Reinhard Meyer]

Dear Wolfgang,

> In message <033d01c3d6ec$decf7670$6d4ba8c0@alb.sub.de> you wrote:
> >
> > attached find mpc5200.c to support the MPC5200 RTC
> Added (as rtc/5xxx.c).

I do not understand the logic behind this filename. Are all 5xxx having this
type of RTC?
MGT5100 ? MPC5200 ? MCF5xxx (Coldfire) ??? MPC5500-Series ?
I sincerely doubt that.
So at least a filename like mpc5xxx.c would be better... Currently it
supports only the MPC5200 and nothing else
The RTC support for mpc8xx, for example, is in a file named (correctly)
mpc8xx.c

> > add mpd5200.o to the Makefile in this folder:
> No. This is not acceptable. Will you please  submit  a  proper  patch
> including all these modifications next time? Thanks.

1. these instructions were meant for Victor Wren, who had asked for MPC5200
RTC support
2. the patch for Makefile would not have worked when you rename the file
3. can a patch produce a new file in CVS? If yes, how?

Best regards
Reinhard

[U-Boot-Users] RTC for MPC5200

[Wolfgang Denk]

In message <06cc01c3db51$e2f496e0$6d4ba8c0@alb.sub.de> you wrote:
>
> > Added (as rtc/5xxx.c).

Actually it's rtc/mpc5xxx

> I do not understand the logic behind this filename. Are all 5xxx having this
> type of RTC?
> MGT5100 ? MPC5200 ? MCF5xxx (Coldfire) ??? MPC5500-Series ?

At least MGT5100 and MPC5200.

I was mostly following the agreed-on naming conventions of the  Linux
kernel, where most files were named mpc5xxx...

> So at least a filename like mpc5xxx.c would be better... Currently it

Actually this is what I used.

OTOH in Linux there is arch/ppc/5xxx_io, too ;-)

> supports only the MPC5200 and nothing else

MGT5100?

> 1. these instructions were meant for Victor Wren, who had asked for MPC5200
> RTC support

You sent it to the public mailing list. It was  5  minutes  of  extra
work to prepare a proper patch.

I _had_ to complain because ther eis some tendency to  drop  arbitray
source  files  to the list with just laconic comments "this is what I
am using - feel free to try it - it's sink or swim."

There are documented rules, and they should be followed.

> 2. the patch for Makefile would not have worked when you rename the file

This is my internal problem, and I have tools to deal with that.

> 3. can a patch produce a new file in CVS? If yes, how?

Of course it can. See the documentation in the README (and/or read in
the diff man page about the "-N" option).

Best regards,

Wolfgang Denk

-- 
See us @ Embedded World, Nuremberg, Feb 17 - 19,  Hall 12.0 Booth 440
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Our way is peace.
	-- Septimus, the Son Worshiper, "Bread and Circuses",
	   stardate 4040.7.

[U-Boot-Users] RTC for MPC5200

[Reinhard Meyer]

Dear Wolfgang,

> In message <06cc01c3db51$e2f496e0$6d4ba8c0@alb.sub.de> you wrote:
> > supports only the MPC5200 and nothing else
> MGT5100?

I do not have the 5100 datasheet (and I cannot find any on the
www.mot-sps.com site), nor do I have 5100 hardware to verify.
If you can mail me a 5100 datasheet I am willing to have a look at its RTC
and if similiar enough I will modify the source to accomodate both.
But I cannot test it with a 5100, that would be up to someone else (you?)

> I _had_ to complain because ther eis some tendency to  drop  arbitray
> source  files  to the list with just laconic comments "this is what I
> am using - feel free to try it - it's sink or swim."

I was not trying to go in this tendency, though of course I can only test
new stuff on our own hardware.

> Of course it can. See the documentation in the README (and/or read in
> the diff man page about the "-N" option).

I _am_ using

cvs -z6 -d :pserver:anonymous at cvs.sourceforge.net:/cvsroot/u-boot diff -puRN
u-boot >u-boot.patch.txt

but files that are new in my tree do not show up in the patch. A hand made
diff like

diff -puN /dev/null u-boot/rtc/mpc5200.c

does the trick, however.

Reinhard