[U-Boot-Users] RTC for MPC5200
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
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
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
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
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.
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
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
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
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?
- 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.
- 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.
- 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
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@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
participants (3)
-
Reinhard Meyer -
Victor Wren -
Wolfgang Denk