JTAG debugger for MPC82xx/MPC83xx
Hi, My group is starting a new project includes a custom board with an MPC8258E processor on it. I'm in the process of evaluating the state of the Linux kernel, toolchains, etc. for the MPC8258E/MPC8360E, as well as selecting a JTAG debugger for our project. I've been researching the available JTAG debuggers that support the MPC82xx/MPC83xx family, and I've found these choices so far: * Abatron BDI-2000 * Green Hills Probe * Freescale's PowerTAP PRO for PowerPC * Lauterbach TRACE32-ICD * WindRiver ICE * Embedded Toolsmiths Guardian-SE (BUT...this is no longer being sold, according to an email response I received from Embedded Toolsmiths) We will definitely want one with a network connection, and will will run the debugger software from a Linux host. Ideally, we would also like one that provides a library to allow us to write apps to function the debugger. Can anyone comment on what JTAG debugger they are using, and how have your experiences been? Are there any other good options besides the ones mentioned above. I'd appreciate any input. Thanks! Steve -- Steve Hein ([EMAIL PROTECTED]) Engineering Diagnostics/Software Silicon Graphics, Inc. 1168 Industrial Blvd. Phone: (715) 726-8410 Chippewa Falls, WI 54729 Fax: (715) 726-6715 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Using WindRiver Probe JTAG
Hi Michael, We just went through this same selection process for a new project (MPC83xx based), and we ended up choosing the BDI2000. I asked WindRiver folks the same question, regarding the WR ICE interaction with GDB. They told me that they do not play together, WR ICE uses WR proprietary communication to the debugger SW. If you're already using WR workbench, I think your only option is to use the WR ice. (When we evaluated WR tools for our project, it seemed like going with WR is an all-or-nothing deal--and we already had experience with the GCC toolchains, GDB debugger, etc. So, we chose the GCC/GDB/BDI2000 approach). Hope this helps. Steve Michael Zagalsky wrote: Hi guys. I'd like to know if anybody had an experience using Wind River Probe JTAG with PowerPC architecture in general, and with PowerQuicc iii family in particular. We're using WR workbench, but I am not sure whether to use their JTAG or the popular BDI2000. Does anybody know if WR Probe uses GDB, or something proprietary to WR? Can it be attached to gdb/ddd/eclipse, or only to WR workbench IDE? For kernel debugging with symbolic information - can it use any binary compiled with -g, or it has to be compiled under WR workbench environment that has some add-ons (I know, it sounds strange - but I actually heard some vague saying of this kind from WR representative). I know those are questions that should be addressed to Wind River , which I did, but I didn't get clear enough answers - so your (good/bad) field experience could be very helpful. Thanks a lot, Michael ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded -- Steve Hein ([EMAIL PROTECTED]) Engineering Diagnostics/Software Silicon Graphics, Inc. 1168 Industrial Blvd. Phone: (715) 726-8410 Chippewa Falls, WI 54729 Fax: (715) 726-6715 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[Fwd: Re: kernel command line for CRAMFS root filesystem]
Hi Julien,
Attached is a patch to mkcramfs that adds a "-r" option. This
reverses the endianness of the CRAMFS filesystem when creating it.
I use this patched mkcramfs to do exactly what you are doing.
It should apply to all kernels up to and including 2.4.18.
Steve
Julien Eyries wrote:
>
> > we use cramfs here and it works without additional parameter. How do you
> > generate the cramfs and on which kind of system are you using it? The
> > mkcramfs tool has an endianess problem so if you do mkcramfs on 86x platform
> > to use it on ppc it wont work. (maybe there is some newer version i am not
> > aware of where that is fixed)
>
> Well it seems it is the problem ... i have generated cramfs on my x86
> and my target is ppc .
> is there a simple trick to make my cramfs image correct for ppc ?
> should i build my cramfs image on the target ?
>
> thanks,
>
> Julien.
>
--
Steve Hein (ssh at sgi.com) Engineering Diagnostics/Software
Silicon Graphics, Inc.
1168 Industrial Blvd. Phone: (715) 726-8410
Chippewa Falls, WI 54729 Fax: (715) 726-6715
-- next part --
--- linux-2.4.4/scripts/cramfs/mkcramfs.c.orig Fri May 4 12:36:58 2001
+++ linux-2.4.4/scripts/cramfs/mkcramfs.c Fri May 4 12:50:33 2001
@@ -52,6 +52,7 @@
" -p pad by %d bytes for boot code\n"
" -s sort directory entries (old option, ignored)\n"
" -z make explicit holes (requires >= 2.3.39)\n"
+ " -r reverse endian-ness of filesystem\n"
" dirnameroot of the filesystem to be compressed\n"
" outfileoutput file\n", progname, PAD_SIZE);
@@ -78,6 +79,7 @@
static char *opt_image = NULL;
static int warn_dev, warn_gid, warn_namelen, warn_skip, warn_size, warn_uid;
+static int swap_endian = 0;
#ifndef MIN
# define MIN(_a,_b) ((_a) < (_b) ? (_a) : (_b))
@@ -298,6 +300,50 @@
return totalsize;
}
+/* routines to swap endianness/bitfields in inode/superblock block data */
+static void fix_inode(struct cramfs_inode *inode)
+{
+#define wswap(x)(((x)>>24) | (((x)>>8)&0xff00) | (((x)&0xff00)<<8) |
(((x)&0xff)<<24))
+ /* attempt #2 */
+ inode->mode = (inode->mode >> 8) | ((inode->mode&0xff)<<8);
+ inode->uid = (inode->uid >> 8) | ((inode->uid&0xff)<<8);
+ inode->size = (inode->size >> 16) | (inode->size&0xff00) |
+ ((inode->size&0xff)<<16);
+ ((u32*)inode)[2] = wswap(inode->offset | (inode->namelen<<26));
+}
+
+static void fix_offset(struct cramfs_inode *inode, u32 offset)
+{
+ u32 tmp = wswap(((u32*)inode)[2]);
+ ((u32*)inode)[2] = wswap((offset >> 2) | (tmp&0xfc00));
+}
+
+static void fix_block_pointer(u32 *p)
+{
+ *p = wswap(*p);
+}
+
+static void fix_super(struct cramfs_super *super)
+{
+ u32 *p = (u32*)super;
+
+ /* fix superblock fields */
+ p[0] = wswap(p[0]); /* magic */
+ p[1] = wswap(p[1]); /* size */
+ p[2] = wswap(p[2]); /* flags */
+ p[3] = wswap(p[3]); /* future */
+
+ /* fix filesystem info fields */
+ p = (u32*)&super->fsid;
+ p[0] = wswap(p[0]); /* crc */
+ p[1] = wswap(p[1]); /* edition */
+ p[2] = wswap(p[2]); /* blocks */
+ p[3] = wswap(p[3]); /* files */
+
+ fix_inode(&super->root);
+#undef wswap
+}
+
/* Returns sizeof(struct cramfs_super), which includes the root inode. */
static unsigned int write_superblock(struct entry *root, char *base, int size)
{
@@ -333,6 +379,7 @@
super->root.gid = root->gid;
super->root.size = root->size;
super->root.offset = offset >> 2;
+ if (swap_endian) fix_super(super);
return offset;
}
@@ -347,7 +394,10 @@
fprintf(stderr, "filesystem too big. Exiting.\n");
exit(1);
}
- inode->offset = (offset >> 2);
+ if (swap_endian)
+ fix_offset(inode, offset);
+ else
+ inode->offset = (offset >> 2);
}
@@ -403,6 +453,7 @@
stack_entries++;
}
entry = entry->next;
+ if (swap_endian) fix_inode(inode);
}
/*
@@ -495,6 +546,7 @@
}
*(u32 *) (base + offset) = curr;
+ if (swap_endian) fix_block_pointer((u32*)(base + offset));
offset += 4;
} while (size);
@@ -595,7 +646,7 @@
progname = argv[0];
/* command line options */
- while ((c = getopt(argc, argv, "hEe:i:n:psz")) != EOF) {
+ while ((c = getopt(argc, argv, "hEe:i:n:psrz")) != EOF) {
switch (c) {
case 'h':
usage(0);
@@ -
cramfs for root filesystem?
Hi Stephen,
I have actually been using a cramfs initrd reliably for about 2
years. You do need a kernel patch to add cramfs to the list of
filesystems to check for in the initrd, also my patch forces the
blocksize of the initrd to 4K if it finds that it contains cramfs.
(I unfortunately don't have a publicly accessible web page to
stick this patch, so I'll attach it at the end of this email).
I have also previously posted a patch to mkcramfs to swap
endianness on a cramfs filesystem (this is also what I do,
create a PPC big endian cramfs using a little endian Intel PC).
I have posted this a couple of times, here's a link to the
most recent:
http://lists.linuxppc.org/linuxppc-embedded/200206/msg00128.html
These two patches should get you going with a cramfs initrd.
Good luck!
Steve
David Blythe wrote:
>
> It looks like you still have an initrd. Don't try running cramfs as an
> initrd. I don't know if anything has changed in later versions of 2.4
> but earlier ones used a 1k blocks size for the ramdisk and even if you
> tried changing the rd blocksize to 4k to match cramfs it still didn't
> work properly ...
>
> There were patches floating around for building a big-endian cramfs,
> rather than fixing the cramfs implemention to convert to little endian.
> I don't know if newer versions of cramfs support explicit little
> endian rather than native endian. I can send you a version of mkcramfs
> with the swap endian flag if you want.
>
> I'm in the process of getting ramfs to work with cramfs on my system as
> we speak.
> david
>
--
Steve Hein (ssh at sgi.com) Engineering Diagnostics/Software
Silicon Graphics, Inc.
1168 Industrial Blvd. Phone: (715) 726-8410
Chippewa Falls, WI 54729 Fax: (715) 726-6715
-- next part --
diff -uNr linux/drivers/block/rd.c linux-2.4.4/drivers/block/rd.c
--- linux/drivers/block/rd.cFri Feb 9 13:30:22 2001
+++ linux-2.4.4/drivers/block/rd.c Mon May 7 14:04:15 2001
@@ -47,6 +47,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -469,10 +470,11 @@
int __init
identify_ramdisk_image(kdev_t device, struct file *fp, int start_block)
{
- const int size = 512;
+ const int size = 1024;
struct minix_super_block *minixsb;
struct ext2_super_block *ext2sb;
struct romfs_super_block *romfsb;
+ struct cramfs_super *cramfsb, *cramfsb2;
int nblocks = -1;
unsigned char *buf;
@@ -483,6 +485,8 @@
minixsb = (struct minix_super_block *) buf;
ext2sb = (struct ext2_super_block *) buf;
romfsb = (struct romfs_super_block *) buf;
+ cramfsb = (struct cramfs_super *) buf;
+ cramfsb2 = (struct cramfs_super *) (&buf[512]);
memset(buf, 0xe5, size);
/*
@@ -515,6 +519,41 @@
goto done;
}
+ /* cramfs also at block zero */
+ /* (superblock can also live at 512-byte offset in block zero) */
+ if ((cramfsb->magic == CRAMFS_MAGIC &&
+ memcmp(cramfsb->signature, CRAMFS_SIGNATURE,
+ sizeof(cramfsb->signature)) == 0) ||
+ ((cramfsb = cramfsb2) && cramfsb2->magic == CRAMFS_MAGIC &&
+ memcmp(cramfsb2->signature, CRAMFS_SIGNATURE,
+ sizeof(cramfsb2->signature)) == 0)) {
+
+ printk(KERN_NOTICE
+ "RAMDISK: cramfs filesystem found at block %d\n",
+ start_block);
+
+ /* cramfs probably has a different blocksize--adjust the
+ ramdisk's block size to accomodate */
+ /* FIXME: should have a way to determine the cramfs
+ blocksize (if it's going to be variable.) */
+ if (rd_blocksize != PAGE_CACHE_SIZE) {
+ int i;
+
+ rd_blocksize = PAGE_CACHE_SIZE;
+ for (i = 0; i < NUM_RAMDISKS; i++) {
+ rd_hardsec[i] = rd_blocksize;
+ rd_blocksizes[i] = rd_blocksize;
+ }
+ printk(KERN_NOTICE
+ "RAMDISK: overriding ramdisk block size to %d
for cramfs filesystem\n",
+ rd_blocksize);
+ }
+ /* Note: even if ramdisk blocksize is changed, nblocks is still
+ calculated using 1k blocksize for the INITRD device */
+ nblocks = (cramfsb->size+BLOCK_SIZE-1)>>BLOCK_SIZE_BITS;
+ goto done;
+ }
+
/*
* Read block 1 to test for minix and ext2 superblock
*/
cramfs for root filesystem?
Sorry... I haven't been living in the development PPC world lately. These patches should apply against the stock 2.4.18 kernel. Anyone is welcome to adapt them to the PPC development stuff and the sourceforge version of mkcramfs :) (I'm on a new project involving an ARM processor now, so I'm not particularly current with the PPC stuff!) Steve "Cameron, Steve" wrote: > > Steven Hein [mailto:ssh at sgi.com] wrote: > > > [...] You do need a kernel patch to add cramfs to the list of > > filesystems to check for in the initrd, also my patch forces the > > blocksize of the initrd to 4K if it finds that it contains cramfs. [...] > > Hmm, this patch doesn't seem to apply to my fairly recent > linuxppc_2_4_devel tree. identify_ramdisk_image() for instance > is in init/do_mounts.c, not drivers/block/rd.c, and there is a > #define BUILD_CRAMDISK in there I guess relating to cramfs, though > I'm not sure what it's doing. > > > I have also previously posted a patch to mkcramfs to swap > > endianness on a cramfs filesystem [...] > > http://lists.linuxppc.org/linuxppc-embedded/200206/msg00128.html > > Hmm, this patch doesn't seem to apply to the mkcramfs I got from > sourceforge yesterday. > > Thanks, just the same. > > -- steve > -- Steve Hein (ssh at sgi.com) Engineering Diagnostics/Software Silicon Graphics, Inc. 1168 Industrial Blvd. Phone: (715) 726-8410 Chippewa Falls, WI 54729 Fax: (715) 726-6715 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
ppc.kernel.org problems
Dan, (My apologies if I'm not reading this right..) I just updated from BitKeeper this morning, and I'm still seeing problems. - in arch/ppc/8xx_io/uart.c the version says 0.02, where the version in the HardHat tree is 0.03 - the arch/ppc/8xx_io/fec.c still won't compile for me; it is trying to reference the field 'tbusy' in struct net_device, and there is no 'tbusy' field in net_device (looks like this still coresponds to the older 'struct device', which did have a 'tbusy' field.) Thanks, Steve Dan Malek wrote: > > I am working on the 2.3.xx kernel right now. There have been lots of > generic changes that need integration for 8xx. Keep looking at the > tree over the next few days, it should come together. > > > I have BitKeeper access and I grabbed the latest Linux/PPC kernel tree, > > but it doesn't have updated FEC or UART drivers in arch/ppc/8xx_io, > > That should have all been there last week.. > > > -- Dan -- Steve Hein (ssh at sgi.com) Engineering Diagnostics/Software Silicon Graphics, Inc. 1050 Lowater Road Phone: (715) 726-8410 Chippewa Falls, WI 54729 Fax: (715) 726-6715 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
mkcramfs changes to switch endianness
I'm getting ready to try using cramfs in the 2.4.4 kernel. Anybody done the work to make 'mkcramfs' create a big-endian image on a little-endian PC? Before I reinvent the wheel, I'd like to find out if anybody as done it (and would like to share :) Steve ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
booting from cramfs in flash
My cramfs adventure continues. Okay, so I have a cramfs filesystem image creaed created. Now, how do I tell the kernel to boot using that filesystem when the filesystem is an image in flash? Maybe I'm on the wrong path, but my previous setup used a compressed kernel and gzip'ed ext2 filesystem as an initial ramdisk, which also served as my permanent filesystem. So I thought I should be able to just replace my old initrd with my new cramfs image, tell the kernel where it is (in flash), and it would go. But, that's not the case for me so far. If I pass the address in flash of my cramfs image as the initrd_start and initrd_end (in R3/R4, the kernel craps out because it can't reuse the pages where I told it that the initrd lives). So,how do I make this connection? Or, do I still need an ext2 initrd like I used before? If so, then how do I mount the CRAMFS filesystem that is an image sitting flash? Any help is greatly appreciated! Steve -- Steve Hein (ssh at sgi.com) Engineering Diagnostics/Software Silicon Graphics, Inc. 1168 Industrial Blvd. Phone: (715) 726-8410 Chippewa Falls, WI 54729 Fax: (715) 726-6715 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
SUCCESS booting off cramfs initrd
Last week I asked for help in my cramfs adventure, so now that I've had some success, I thought I'd share how I got it done. My original goal was to boot from a cramfs filesystem residing in flash. As people explained to me, that would have required me to have a small ext2 initrd filesystem to boot from and them mount my cramfs filesystem as the root filesystem (through the /dev/mtd device, accessed through the MTD drivers). I went down this road, but found that the current MTD CFI flash drivers didn't support big-endian configurations at all. (Actually, I created a MTD map driver for my board that treated the flash space as ROM and I was able to access it). But, I didn;t really want to created two separate filesystems (the ext2 initrd, and the cramfs root filesystem), so I didn't continue this approach. It later occurred to me that, due to the way I update my image in flash, the filesystem needed to live in RAM. I still wanted to use cramfs to save RAM (my ext2 filesystem was 4.5MB, too expensive for a 16MB board). But, this brought me back to trying to use a cramfs initrd as my root filesystem. So, here's what I did to accomplish this: - started with linux-2.4.4 kernel plus linuxppc_2_4 diffs patch - incorporated the cramfs patch from Transmeta's Midori Linux 1.0.0-beta1 release (they use a different packaging mechanism, so you'll need to get the whole Midori release and unpack/build it to get access to the patch). I'm not sure if this step was necessary or not..but the patch makes significant improvements to the cramfs filesystem, so I wanted it (someone else may be able to answer this better). - modified drivers/block/rd.c to make several changes: 1) detect the cramfs superblock (at offset 0 or offset 512 in the first block of the filesystem) 2) when a cramfs filesystem is detected, force the block size of the ramdisks to 4KB, which is cramfs's block size. (this step tripped me up for several days, as I didn't and still don't know much about block devicesbut I did learn that the ramdisk that cramfs is on must use 4KB blocks!) - modified David Blythe's originalendian-swap patch to mkcramfs to work over the top of Midori's cramfs patch. Basically, this provided a "-r" option to mkcramfs to reverse the endian-ness of the filesystem (my host is an i686 box and my target is a custom MPC860T board). Basically, when i did all of the above, I was able to boot off of a cramfs initrd, and continue to use it as my root filesystem. I put all of the patches that I used to accomplish this out at: (listed in the order in which they should be applied) http://www.geocities.com/heinss1/cramfs_midori.patch.txt http://www.geocities.com/heinss1/mkcramfs_endian.patch.txt http://www.geocities.com/heinss1/cramfs_initrd.patch.txt for whoever may be interested. Hope it helps someone else get off the ground faster! Steve -- Steve Hein (ssh at sgi.com) Engineering Diagnostics/Software Silicon Graphics, Inc. 1168 Industrial Blvd. Phone: (715) 726-8410 Chippewa Falls, WI 54729 Fax: (715) 726-6715 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
860 RTC support
I've seen some discussions about real-time clocks lately, but (I think) I scoured the list and can't find any basic information about how to function the 860's real-time clock. I'm using the real 2.4.3 kernel right now and I don't see that /dev/rtc would work. Is there a working method (to read the RTC value at boot-time)? I see references to 'hwclock', but from what I can tell that won't work unless there's a /dev/rtc available (since 860 PPC isn't supported natively by hwclock). I apologize if I missed this info in the archives. Any help would be appreciated! Thanks, Steve ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
860 RTC support
Dan Malek wrote: > > > Is there a working method (to read the RTC value at boot-time)? > > The MPC8xx real-time clock is implicitly managed in the kernel. > At boot time, the register is read and stored in the kernel > time. Whenever the kernel time is updated, the hardware register > is also updated. Since the 8xx is simply a 32-bit register > access with an update rate that matches the kernel time, I > chose to do it this way. > Dan, My question was poorly worded (because at that point I didn't understand the whole picture.). I know that the 860's RTC on my board is working properly, that's not the issue. My problem is this: when I set the date via the "date --set" command (which calls stime()) or by calling settimeofday() directly, it doesn't result in the 860's RTC being updated. Yes, do_settimeofday() gets called properly, but it never results in ppc_md.set_rtc_time ==> m8xx_set_rtc_time getting called! (The only place I see that called is in timer_interrupt in arch/ppc/kernel/time.c, and it's only called if the STA_UNSYNC bit is not set in timer_status. do_settimeofday() results in the STA_UNSYNC bit being set and I don't see how it gets cleared.). I also looked at the other approach of configuring in /dev/rtc and using hwclock, but the kernel won't boot with this drivers/char/rtc.c built in, and that doesn't look like it has 8xx support anyway. In your response, you said "Whenever the kernel time is updated, the hardware register is also updated.". Is settimeofday()/stime() the methods of updating the kernel time that you were talking about? I know I'm missing something, as it sounds like this works for others, but I'd greatly appreciate it if someone would clue me in! (Again, I'm using the 2.4.3 kernel, if that's relevant). Thanks, Steve ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
860 RTC support
Dan Malek wrote: > > > Ahh, OK. I'll take a look at this. I thought it used to work in > older kernels. It's on my list (or if someone else wants to take > a look and send a patch .. :-). > I looked through the source, and the difference between the 2.2.x (2.2.13 and 2.2.14 mvista kernels) and the 2.4.3 kernel is that, in the 2.2.x kernel, the set_rtc_time function in timer_interrupt() can only be called if (time_status & STA_UNSYNC) != 0, where in the 2.4.x kernel set_rtc_time can only be called if the (time_status & STA_UNSYNC) == 0. As I see it, the STA_UNSYNC bit is always set, so the RTC will never be updated! At first I suspected just a bug in the PPC code regarding this bit, but I glanced through the time code in some of the other arch's (sh, sparc, arm, etc.) and saw the identical logic: - a call to do_settimeofday() *always* sets the STA_UNSYNC bit in time_status - the RTC is only updated when STA_UNSYNC is *not* set And I don't see any way that STA_UNSYNC gets cleared (unless it's cleared by adjtimex() or something like that.. > > As I recall, there are events that occur to update the RTC from > the kernel's notion of time, and one used to be some timeout. Perhaps > after you set the time, if you wait for a while it may update the RTC. > I had printk's in m8xx_set_rtc, and they never printed. (even after an hour or more). Again, it looks like it all boils down to the value of the STA_UNSYNC bit in 'time_status' and how that gets manipulated. -- Steve Hein (ssh at sgi.com) Engineering Diagnostics/Software Silicon Graphics, Inc. 1168 Industrial Blvd. Phone: (715) 726-8410 Chippewa Falls, WI 54729 Fax: (715) 726-6715 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
860 RTC support
Tom Rini wrote: > > I think I understand the question/problem too. We'll see what else I've > got to work on as well. :) Just checking, Steven have you tried to > enable the "PPC_RTC" driver and gotten this same incorrect behavior? > Tom, The only place I see references to PPC_RTC is in some of the PPC "defconfig" files. I don't see any other places where that is references in the 2.4.3 kernel. Steve ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
860 RTC support
Dan Malek wrote: > > Well, hell.what I used to do is now considered "userland > business." I guess the right thing to do is create a /dev/rtc > that will manage the MPC8xx RTC. Sorry I missed this as the > kernel evolved. > I know this isn't under your control, but.. If this is the case (that setting the RTC is properly done through /dev/rtc using hwclock, etc.), then doing a "date --set" no longer sets the RTC, correct? And it will never cause the RTC to be set? .Seems to me that separating the setting of the RTC from setting the kernel/system time is a Bad Idea.There's probably more to it than that, or maybe "date --set" isn't considered a proper way to manipulate the system clock anymore (maybe it never was :). -- Steve Hein (ssh at sgi.com) Engineering Diagnostics/Software Silicon Graphics, Inc. 1168 Industrial Blvd. Phone: (715) 726-8410 Chippewa Falls, WI 54729 Fax: (715) 726-6715 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
860 RTC support
I'd love to help here, but I can't find the source you're talking about!! I've looked in the mvista's 2.2.14 kernel, and in the LSP's for rpxlite and mbx860, plus the real 2.4.3 kernel, and I see no reference to PPC_RTC in drivers/macintosh or arch/ppc/config.in! Where should I be looking? Tom Rini wrote: > > > Yes, I just noticed this myself when I went to try it on my rpx. > What you'll need to do is: > edit ./Makefile, and compile in drivers/macintosh/macintosh.o on > CONFIG_PPC, not CONFIG_ALL_PPC. > edit drivers/Makefile, and go into drivers/macintosh on CONFIG_PPC, not > CONFIG_ALL_PPC. > Finally, edit arch/ppc/config.in, and remove the test for !8xx around the > PPC_RTC question. Then it'll either work or die at boot. I'm not sure > yet :) I should be able to test shortly tho. > > -- > Tom Rini (TR1265) > http://gate.crashing.org/~trini/ -- Steve Hein (ssh at sgi.com) Engineering Diagnostics/Software Silicon Graphics, Inc. 1168 Industrial Blvd. Phone: (715) 726-8410 Chippewa Falls, WI 54729 Fax: (715) 726-6715 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
860 RTC support
Tom Rini wrote: > > > Okay, it doesn't _quite_ work (hwclock will oops) but hopefully it > won't be too hard to track down. I'll try and get to it this afternoon > or tomorrow, or when time permits ([EMAIL PROTECTED] classes). Patches > greatly > appreciated. :) > I don't have a patch put together yet, but I found the problem: m8xx_get_rtc_time is an __init function in the 2.4.x tree. Remove the __init and it works great! -- Steve Hein (ssh at sgi.com) Engineering Diagnostics/Software Silicon Graphics, Inc. 1168 Industrial Blvd. Phone: (715) 726-8410 Chippewa Falls, WI 54729 Fax: (715) 726-6715 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
ppc.kernel.org problems
Dan, Sorry to bother you. I've scoured the linuxppc-emnbedded mailing list, and I've tried (unsuccessfully) to access ftp://ftp.ppc.kernel.org/pub/linuxppc/embedded/ I'm working on a MBX-based 860T board, and I'd like to move from the 2.2.13 kernel in the HardHat package to the latest 2.3.x kernel. (We need it for the USB drivers). I have BitKeeper access and I grabbed the latest Linux/PPC kernel tree, but it doesn't have updated FEC or UART drivers in arch/ppc/8xx_io, and I'd imagine there are other pieces missing. Are those pieces available to merge w/the Linux PPC (2.3.99-pre3) kernel? If so, where can I go besides www.ppc.kernel.org/embedded, which appears to be down. Any help would be appreciated Thanks, Steve -- Steve Hein (ssh at sgi.com) Engineering Diagnostics/Software Silicon Graphics, Inc. 1050 Lowater Road Phone: (715) 726-8410 Chippewa Falls, WI 54729 Fax: (715) 726-6715 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Configuring Freecale ucc_geth without a PHY
Hi all, I have a custom board with an MPC8358 (our board is based off of the MPC8360E-MDS development board) that has its eth's directly connected (GMII) to a Broadcom network switch part on the same board, with no PHYs between them. We've have been using a 2.6.16.18 kernel (from TimeSys) up until now, and I hacked in some crude support for no-phy configs forced to 100Mbit and 1Gbit speeds. Now I'm moving to 2.6.22 (with 8360 the patches from bitshrine.org), and I'm trying to understand how I should do this with device trees, the new PHY infrastructure, etc. Has anyone else needed this support? Does anyone have any suggestions as to how to tackle it? Thanks, Steve -- Steve Hein ([EMAIL PROTECTED]) Engineering Diagnostics/Software Silicon Graphics, Inc. 1168 Industrial Blvd. Phone: (715) 726-8410 Chippewa Falls, WI 54729 Fax: (715) 726-6715 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Configuring Freecale ucc_geth without a PHY
Kim Phillips wrote: > On Tue, 29 Jan 2008 11:08:43 -0600 > Steven Hein <[EMAIL PROTECTED]> wrote: > > >> Hi all, >> >> I have a custom board with an MPC8358 (our board is based >> off of the MPC8360E-MDS development board) that has its eth's >> directly connected (GMII) to a Broadcom network switch >> part on the same board, with no PHYs between them. >> We've have been using a 2.6.16.18 kernel (from TimeSys) up >> until now, and I hacked in some crude support for no-phy >> configs forced to 100Mbit and 1Gbit speeds. Now I'm >> moving to 2.6.22 (with 8360 the patches from bitshrine.org), >> and I'm trying to understand how I should do this with >> device trees, the new PHY infrastructure, etc. Has anyone >> else needed this support? Does anyone have any suggestions >> as to how to tackle it? >> > > check out the "fixed-link" property and associated code. This > implementation came about after 2.6.22 though (it's commit-ish > v2.6.23-10096-ga21e282). > > Kim > Thanks for the pointer Kim! Using the "fixed-link" property code already in the tree, and adding the glue in ucc_geth.c to use it (modeled after the code in gianfar fix-link support in fsl_soc.c), I was able to get this working with me 8360 board. Is there a document anywhere that describes how to submit patches for the powerpc kernel?Or do I just create the patch (I'm learning about git right now...) again the paulus/powerpc.git tree, and send it to this list? Thanks, Steve -- Steve Hein ([EMAIL PROTECTED]) Engineering Diagnostics/Software Silicon Graphics, Inc. 1168 Industrial Blvd. Phone: (715) 726-8410 Chippewa Falls, WI 54729 Fax: (715) 726-6715 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
8360 custom board, ucc_geth TX errors on longer(?) packets
Hi All: For our custom 8360-based board that is based fairly closely on the MPC8360-MDS board, I'm working on moving from a 2.6.16 kernel (Timesys distro) to 2.6.24. I didn't use the device tree in my old kernel, so I've had the learning experience of tweaking the dts file for my custom board. I've got it 99% working (I think!). But I'm running into a really odd ethernet problem that I don't understand. I have two boards: our custom 8360 board, and a MPC8360E-MDS dev board.I can build a kernel for the MDS board and ethernet works perfectly.When I build that kernel using the same config, but changing the platform to my custom board (and not changing any other options), everything works right except for ethernet:it won't get an IP address using DHCP (udhcpc)...I check the ifconfig output, and I see that the TX error count is increasing, and there are very few TX packets being sent. I verified that this isn't a timeout-- it's being caused by the UCCE[TXE] bit being set (I don't see any other error indications in dmesg). As another test, I configured the address manually. When I do that, I can ping the board with a normal ping; but if I use the -s option to increase the packet size, then the pings will fail when I use a size of about 250 or greater, and with a size of about 300 or greater I get no successful ping packets. The one main difference in this board is how eth0 is wired. We have a Broadcom GbE switch part, and UCC1 eth is wired directly to that switch (no PHY). (This where I needed to use the fixed-link option that I had asked about a couple of days ago!). In my 2.6.16-based kernel, I had created a dummy "null" PHY to force the link speed to 1000, and that worked well.I am using the same Broadcom network switch software with both kernels, so the switch side of the config should be the same. I created my custom board config from the MPC8360E-MDS board configs (starting with that defconfig, dts, and platform .c file), and matched my GPIO pin configs in the dtb file to what I had used in the 2.6.16 kernel.. I'm not sure where to look for this problem, as I've never seen UCCE[TXE] set before.Based on my experience in this move so far, I'd guess that I've got something configured wrong somewhere, but I just don't know where to look. Does anyone have any ideas/suggestions? Any help would be MUCH appreciated!! Thanks, Steve -- Steve Hein ([EMAIL PROTECTED]) Engineering Diagnostics/Software Silicon Graphics, Inc. 1168 Industrial Blvd. Phone: (715) 726-8410 Chippewa Falls, WI 54729 Fax: (715) 726-6715 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 8360 custom board, ucc_geth TX errors on longer(?) packets
Kim Phillips wrote: > On Fri, 01 Feb 2008 12:52:25 -0600 > Steven Hein <[EMAIL PROTECTED]> wrote: > > >> The one main difference in this board is how eth0 is wired. >> We have a Broadcom GbE switch part, and UCC1 eth is wired >> directly to that switch (no PHY). (This where I needed to >> > > sounds like you ran into some h/w errata. if on rgmii, you might > want to find a way to program the switch for rgmii with internal delay > (8360 rev.2 rgmii-id rx & tx; 8360rev2.1 rgmii-rxid (i.e. for rx > only)). If not, I'd contact fsl tech support directly. > > Kim > I would suspect HW.but this WORKS with the 2.6.16 kernel I was using!That's why I suspect that I still don't have something configured right in my device tree, or something else I missed in the new kernel.But I can't figure out what it is :-(I've poured over the code in the old versus new (both the ucc_geth driver and the platform initialization in the old, and the device tree in the new) and can't figure out what I missed! And like I said, a kernel with the same config (other than changing the platform) works on my MPC8360E-MDS board. Granted, that doesn't have this direct switch connection.. I did look at the code related to the HW errata (QE_ENET18). But we're using GMII to the switchand that workaround code wasn't in active in my old kernel (it was there, but commented out). Any other thoughts?Has anyone seen this symptom before? Steve -- Steve Hein ([EMAIL PROTECTED]) Engineering Diagnostics/Software Silicon Graphics, Inc. 1168 Industrial Blvd. Phone: (715) 726-8410 Chippewa Falls, WI 54729 Fax: (715) 726-6715 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 8360 custom board, ucc_geth TX errors on longer(?) packets
Steven Hein wrote: > Kim Phillips wrote: >> On Fri, 01 Feb 2008 12:52:25 -0600 >> Steven Hein <[EMAIL PROTECTED]> wrote: >> >> >>> The one main difference in this board is how eth0 is wired. >>> We have a Broadcom GbE switch part, and UCC1 eth is wired >>> directly to that switch (no PHY). (This where I needed to >>> >> >> sounds like you ran into some h/w errata. if on rgmii, you might >> want to find a way to program the switch for rgmii with internal delay >> (8360 rev.2 rgmii-id rx & tx; 8360rev2.1 rgmii-rxid (i.e. for rx >> only)). If not, I'd contact fsl tech support directly. >> >> Kim >> > > I would suspect HW.but this WORKS with the 2.6.16 kernel > I was using!That's why I suspect that I still don't have > something configured right in my device tree, or something > else I missed in the new kernel.But I can't > figure out what it is :-(I've poured over the code in > the old versus new (both the ucc_geth driver and the platform > initialization in the old, and the device tree in the new) > and can't figure out what I missed! And like I said, a > kernel with the same config (other than changing the platform) > works on my MPC8360E-MDS board. Granted, that doesn't have > this direct switch connection.. > > I did look at the code related to the HW errata (QE_ENET18). > But we're using GMII to the switchand that workaround > code wasn't in active in my old kernel (it was there, but > commented out). > > Any other thoughts?Has anyone seen this symptom before? > > Steve > OkayI found it!Started poking at the UCCE registers and found that the FIFO sizes weren't right. This led me to find a bug in my ucc_geth interface to the fixed-link PHY driver: the code to reconfigure the MURAM FIFO's for Gigabit operation wasn't being executed for no-phy configs! All is well once I changed this. Sorry for the noise. (glad I found this before submitting my patch! ;-) Steve -- Steve Hein ([EMAIL PROTECTED]) Engineering Diagnostics/Software Silicon Graphics, Inc. 1168 Industrial Blvd. Phone: (715) 726-8410 Chippewa Falls, WI 54729 Fax: (715) 726-6715 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
