Howto Cross Compile GCC to run on PPC Platform
On Fri, 28 Oct 2005, Peter Hanson wrote: On 10/28/05, Steven Blakeslee BlakesleeS at embeddedplanet.com wrote: get it to cross compile gcc (to run on ppc). Does anyone know of a good HowTo to do this? Karim Yaghmour's Building Embedded Linux Systems I'm currently downloading the source distro of ELDK, so if it's already in there I'll find it, but if there is one elsewhere online please let me know. Very good, full of features. My favorite cross tool chain site: Building and Testing gcc/glibc cross toolchains http://kegel.com/crosstool/ the Linux From Scratch site also has some useful discussion on building toolchains: http://www.linuxfromscratch.org/ rday
Regarding the PPC board bringup with Linux 2.6 kernel
On Tue, 6 Sep 2005, Clemens Koller wrote: Hi, Vinay Please reply to the list also! I can guess your problem, but you should give more information about your system i.e. Processor / Board / Kernel version, ... i missed the first part of this. i've booted a 2.6 kernel on an 8xx board and got to the command prompt. is that of any use here? rday p.s. i'm not using u-boot as the bootloader but that shouldn't be an unmanageable difference.
Linux Kernel MTD question
On Sat, 23 Jul 2005, JohnsonCheng wrote: Yes. You are right. It's design by myself. But I meet a problem. If I have three configuration files, A.conf, B.conf and C.conf, then I hope save them in one of partitions of MTD, 0x005C-0x1000. Two questions: 1. How to build these configuration files into an image for U-boot with mkimage? 2. In kernel, how to get these data? I use mount /dev/mtd4 /mnt, but it failed by block device required. for this second issue, you might try mounting the block device, which is probably called /dev/mtdblock4 or something similar. rday
[OT?] recommendations for a small footprint DB for PPC system?
any recommendations for a small, relational database that can be cross-compiled with ELDK 3.1.1 for a PPC system? it's not going to be holding a lot of records (about 1000, more or less), and will be initialized and loaded at system boot time, at which point the majority of operations will be read, with only occasional writes. thoughts? rday
Can you suggest a small FTP utility for Linux suitable for embedded systems?
On Wed, 13 Apr 2005, Vijay Padiyar wrote: Hi there I am running BusyBox 1.0 on the Linux 2.6.10 kernel on an MPC8260 target. Since BusyBox currently doesn't appear to provide an FTP server utility, I wanted to know where I can get a small FTP utility for Linux that doesn't take up much space and is suitable for embedded applications. we're using ftplib, which comes with both the library and the qftp client. seems to run well on our 8xx board alongside busybox-1.00. rday
Can you suggest a small FTP utility for Linux suitable for embedded systems?
On Wed, 13 Apr 2005, Vijay Padiyar wrote: Hi there I am running BusyBox 1.0 on the Linux 2.6.10 kernel on an MPC8260 target. Since BusyBox currently doesn't appear to provide an FTP server utility, I wanted to know where I can get a small FTP utility for Linux that doesn't take up much space and is suitable for embedded applications. whoops, sorry, i just noticed the word server in there. my previous post referred just to a client. sorry. rday
how to get busybox shell prompt on console port?
i'm still wrestling with how to get my 8xx-based board's shell prompt to show up on the console port. i've built a simple 2.6.11.7-based kernel and (busybox-based) root filesystem and, fairly quickly, i realized i needed to use the following kernel boot line: Linux/PPC load: rw root=/dev/ram0 console=ttyCPM0,9600 as the boot proceeds, i eventually see: Serial: CPM driver $Revision: 0.01 $ ttyCPM0 at MMIO 0xfa200a80 (irq = 20) is a CPM UART ttyCPM1 at MMIO 0xfa200a00 (irq = 46) is a CPM UART which seems to be a good sign. however, after all the standard boot output, i'm left with no shell prompt, and i'm assuming it's just because i haven't correctly started the shell thru /etc/inittab with the correct parameters to have it talk to that console port. what would be the correct invocation of /bin/sh in /etc/inittab to reflect my serial/console port setup above? thanks. rday
how to get busybox shell prompt on console port?
On Sun, 10 Apr 2005, Kylo Ginsberg wrote: I use this line in /etc/inittab (assuming you've built busybox to include sh): ttyCPM0::respawn:-/bin/sh (first, a caveat: even though this is the 2.6 kernel, i'm still using devfs for historical reasons. that will change shortly but may be part of my problems.) i'm pretty sure i tried that combo, and several others like it, and i finally had success with the following entry in /etc/inittab: ::respawn:/bin/sh /dev/console /dev/console 2 /dev/console yes, it's disgusting but it works. once i got a prompt, i noticed that these are the contents of /dev: crw---1 root root 204, 46 Dec 31 1969 NULL0 crw---1 root root 204, 47 Dec 31 1969 NULL1 crw---1 root root 5, 1 Oct 2 08:56 console crw-rw-rw-1 root root 1, 7 Dec 31 1969 full drwxr-xr-x1 root root0 Dec 31 1969 input crw-r-1 root root 1, 2 Dec 31 1969 kmem crw-r--r--1 root root 1, 11 Dec 31 1969 kmsg drwxr-xr-x1 root root0 Dec 31 1969 loop crw-r-1 root root 1, 1 Dec 31 1969 mem drwxr-xr-x1 root root0 Dec 31 1969 misc crw-rw-rw-1 root root 1, 3 Dec 31 1969 null crw-r-1 root root 1, 4 Dec 31 1969 port crw-rw-rw-1 root root 5, 2 Dec 31 1969 ptmx drwxr-xr-x1 root root0 Dec 31 1969 pts drwxr-xr-x1 root root0 Dec 31 1969 pty crw-r--r--1 root root 1, 8 Dec 31 1969 random drwxr-xr-x1 root root0 Dec 31 1969 rd lr-xr-xr-x1 root root4 Sep 25 1969 root - rd/0 drwxr-xr-x1 root root0 Dec 31 1969 shm crw-rw-rw-1 root root 5, 0 Dec 31 1969 tty crw-r--r--1 root root 1, 9 Dec 31 1969 urandom crw-rw-rw-1 root root 1, 5 Dec 31 1969 zero in other words, no /dev/ttyCPM0 which may be why that first solution never worked (i'm still fuzzy on support for the serial/console ports so i'm reading up on that now.) but given that i have a /dev/console, i'll stick with that for now until i have a better fix. and what's the two NULL entries up there? those are new to me. rday
how to get busybox shell prompt on console port?
On Sun, 10 Apr 2005, Kylo Ginsberg wrote: Fwiw, I explicitly created the CPM devices; note that the major/minor match those of your NULL nodes.? I'm running 2.6.11.? I'm fuzzy re if/how these devices should be automagically created by the kernel. mknod ttyCPM0 c 204 46 mknod ttyCPM1 c 204 47 chmod 660 ttyCPM* ... crw---1 root root 204, 46 Dec 31 1969 NULL0 crw---1 root root 204, 47 Dec 31 1969 NULL1 well, since i'm using devfs, i'm assuming that's what i get by default. ok, that clears up some of the confusion. thanks. rday
cross-compiling under cygwin?
i've just had a request from a colleague who wants to do all the cross-compilation for our 8xx board on a windows box, rather than linux. there was talk of cygwin, and kdevelop as well. i'm still parsing the rest of the email but is there a canonical URL that discusses working in the windows environment? i'm just about to head over to denx.de to see what i can find. thanks for any pointers. rday
cross-compiling under cygwin?
On Fri, 8 Apr 2005, Wolfgang Denk wrote: In message Pine.LNX.4.61.0504081010330.14089 at localhost.localdomain you wrote: i'm just about to head over to denx.de to see what i can find. You won't find any Cygwin stuff. We're a 100% Micro$oft-free company :-) We don't use any windoze. Instead, we show our customers how to integrate a Linux server into their existing network environment. This is MUCH more efficient. trust me, i'm working hard to talk them out of this approach. on a related issue, though, are there any IDEs that stand out for embedded system development? more than one person has recommended i look at eclipse, so it's downloading as we speak. and, related to the original issue, during a conference call this morn, when the client's tech folks asked me what development environment i use, i said, ELDK 3.1.1 and 'vi'. there was a noticeable silence ... :-) rday
cross-compiling under cygwin?
On Fri, 8 Apr 2005, Dan Malek wrote: On Apr 8, 2005, at 10:13 AM, Robert P. J. Day wrote: i've just had a request from a colleague who wants to do all the cross-compilation for our 8xx board on a windows box, rather than linux. Just remember there is lots more to building and developing than compiling a kernel. In addition to the compiler, you need lots of support tools. Once you get a kernel, you have to create some kind of file system, of course NFS won't work on Windows, creating a ramdisk without a loopback device and file system support is quite a challenge, too. a lot of that was part of the conversation. i suspect i may have to be more persuasive. something involving a blunt instrument, perhaps. I don't understand why you wouldn't want to develop on a Linux (or at least Unix) host, since you need those skills and environment for the target. Do they just like impossible challenges in their way to getting real work done? :-) i'm going to assume that was rhetorical. :-) rday
2.6.11-5 kernel on 8xx -- perhaps i messed up the console port?
to make a long story a little shorter, once upon a time, i had a 2.5.xx kernel running on my 8xx-based board. i used the latest bk checkout from bkbits.net and had at least a minimal operational kernel that would boot, mount its root filesystem, mount JFFS2 and a bit more. finally getting back to that, i grabbed the latest stock (2.6.11-5) kernel and tried to reproduce that. by hand, i perused my old config file, duplicated what i could, made (relatively?) intelligent decisions about new options and tried again. to keep things simple, i left out absolutely *everything* that wasn't essential for just an initial boot -- no networking, no MTD, not even an initrd -- i just wanted to see the kernel boot and would be quite happy for it to get to trying to mount the root filesystem, only to choke and fall over. no problem. however, after (all based on ELDK 3.1 cross-compilation): $ make ARCH=ppc menuconfig $ make ARCH=ppc $ ppc_8xx-objcopy -O binary zImage.elf zImage.bin download (via planet core boot loader) to 40 in RAM, and g 40, i get: loaded at: 0040 00485160 board data at: 00483124 00483140 relocated to: 00405090 004050AC zimage at: 004058C8 0048275F avail ram: 00486000 0200 Linux/PPC load: rw root=/dev/ram0 Uncompressing Linux...done. Now booting the kernel ... hangs ... of course, there are an infinite number of ways i could have screwed up, but one possibility is that i just messed up configuring the console port. the kernel could very well be loading but, as this is a bare board with no blinkenlights or anything, there's no way to tell. has anything changed in the last little while in terms of the console port? i tried to reproduce faithfully my earlier config options for console port support, but no luck. thoughts? the problem could, of course, be elsewhere but i'd like to check this out first. rday
2.6.11-5 kernel on 8xx -- perhaps i messed up the console port?
Solved. On Sat, 26 Mar 2005, Robert P. J. Day wrote: ... snip ... has anything changed in the last little while in terms of the console port? i tried to reproduce faithfully my earlier config options for console port support, but no luck. rather than console=ttyS0 as i used to use, it's now console=ttyCPM0. and we're off ... rday
still not clear on which tree to be using these days
what is the proper tree to be using these days for a 2.6 kernel on 8xx? for the longest time, i've used the bk checkout from bkbits.net, but i see others now working with what looks like the latest stock 2.6.x release. what's the status on patches that were submitted against the bk tree? have they been pushed upstream? etc, etc. rday
still not clear on which tree to be using these days
On Fri, 25 Mar 2005, Dan Malek wrote: On Mar 25, 2005, at 4:19 PM, Robert P. J. Day wrote: what is the proper tree to be using these days for a 2.6 kernel on 8xx? for the longest time, i've used the bk checkout from bkbits.net, but i see others now working with what looks like the latest stock 2.6.x release. I just use the latest kernel.org tree for everything. If I'm submitting a patch, or working with someone else, I use the bk tree just to be that little more up to date. i just downloaded the 2.6.11-5 kernel source and was a bit nonplussed to discover that 8xx wasn't in the list of choices for processor, until i noticed in the Kconfig file that 8xx depends on BROKEN. oh, my. :-) live and learn. rday
why is entire 8xx architecture defined as broken?
after i looked at the Kconfig setup for 2.6.11-5, i'm a bit puzzled -- why is the entire 8xx architecture defined as BROKEN? follow the logic along: arch/ppc/Kconfig: config 8xx depends on BROKEN bool 8xx and what means BROKEN? init/Kconfig: config BROKEN bool depends on !CLEAN_COMPILE default y ok, and CLEAN_COMPILE? defined just above that: config CLEAN_COMPILE bool Select only drivers expected to compile cleanly if EXPERIMENTAL default y ok, and EXPERIMENTAL? config EXPERIMENTAL bool Prompt for development and/or incomplete code/drivers and *that* refers to the top-level menu entry regarding whether you want to take a chance on development and/or incomplete code/drivers, not entire architectures. the above seems just a tad misleading, no? rday
Viosoft adds adds Abatron JTAG debug probe, PowerPC to toolsuite
disclaimer: i have no connection with the company above, i just thought some folks might want to know about this. http://linuxdevices.com/news/NS3861500285.html rday
looking for a model for building CRAMFS(?)-based system
On Thu, 17 Mar 2005, Patrick Huesmann wrote: I'm using separate MTD partitions for bootloader, device parameters, zImage, initrd and persistent storage. When updating the initrd, the only thing necessary is a eraseall /dev/mtdX cat initrd.gz /dev/mtdX now this is the sticky part. imagine this system out in the field, where you need to make an update to something in the initrd in the root filesystem. one technique would be to, of couse, download an entirely new initrd.gz and reflash (hoping no one pulls the plug as you're doing it), as you describe above. what about sacrificing space and having an uncompressed root filesystem in flash? and, if that's possible, would one mount it read-only from flash (speed?), or just copy it into RAM and mount that every time? if all this is covered somewhere, a URL would be fine, thanks. rday
looking for a model for building CRAMFS(?)-based system
On Thu, 17 Mar 2005, Wolfgang Denk wrote: Dear Robert, in message Pine.LNX.4.61.0503171011220.20335 at localhost.localdomain you wrote: now this is the sticky part. imagine this system out in the field, where you need to make an update to something in the initrd in the root filesystem. This is the szenario where an overly filesystem enters the stage. See http://www.denx.de/e/news.php#MINI_FO i'd already read that paper a few months back, but wasn't sure if this was actually being used, or was just a concept idea. if it's actually in practise, i'll take another look at it. rday
looking for a model for building CRAMFS(?)-based system
i'm hoping someone has an example of the following that they're willing to share. currently, the system i've built for our 850 board incorporates - boot loader (sadly, not u-boot, but i'm working on it) - standard zImage.initrd.bin kernel+initrd image ... mountable JFFS2 filesystem with persistent stuff ... obviously, with this layout, it's kind of a nuisance to update anything individually in the initrd portion of the system, so i'd like to at least experiment with a layout that has separate - boot loader (ideally, u-boot) - kernel image - updateable (normally mounted read-only?) root filesystem ... rest of stuff the same ... i'm going to start over at DENX with their docs since that seems to be the canonical place to get the scoop on this but, in the meantime, if anyone has built something like this and is willing to share, say, their makefile so i can see how it goes together, i'd be thrilled. if your example happens to *require* u-boot, well, perhaps so much the better since that will give me the incentive to switch. :-) thanks. rday
canonical source for latest 2.6 kernels for 8xx?
where is the primary site these days for up-to-date kernel source trees for the 2.6 kernel for PPC? thanks. rday
ELDK 3.1?
On Wed, 17 Nov 2004, Wolfgang Denk wrote: In message Pine.LNX.4.60.0411170914230.18374 at localhost.localdomain you wrote: any ETA for the upcoming enhanced ELDK 3.1? It's actually out. I just wait with the announcement until all mirrors picked it up. I have little influence on when they run rsync, though. cool. i normally check ftp.leo.org/pub/eldk, and i didn't see anything there this morning yet. rday
m8xx_pcmcia.c for v2.6 kernels
On Mon, 25 Oct 2004, Pantelis Antoniou wrote: Marcelo Tosatti wrote: Hi fellows, I'm attaching a port of our internal m8xx_pcmcia.c (based on MontaVista 2.1's 2.4.17 kernel with many fixes) to v2.6. ... huge SNIP here ... Marcelo Hi I'm gonna definately try this and get back to you. Thanks Regards Pantelis was it absolutely necessary to include 46K worth of patch in your reply, only to add what you did at the bottom? rday
Merge 8xx to Linus tree?
On Thu, 14 Oct 2004, Tom Rini wrote: On Thu, Oct 14, 2004 at 06:25:54PM -0400, Robert P. J. Day wrote: what does this mean in terms of urgency in getting changes into the 8xx stuff, then? does this imply a fixed window of opportunity in the near future, or does it mean that once stuff starts to get moved upstream, it will get moved on a regular basis? just curious. Once upstream, new changes won't (unless not-fully-baked) go into linuxppc-2.5. um ... sorry, i'm still not sure what this means. does it mean that, at some point (to be determined/announced?), the linuxppc-2.5 tree will be put to the side, and all further mods should be done directly against the 2.5 tree? rday
one more push to clean up microcode patches
(if you're intensely bored with this whole thread on ucode patches, just hit 'delete'. i won't take it personally. :-) i'd like to submit one more (probably sizable) patch to clean up the logistics for ucode patches. as it stands, the current micropatch.c file is just plain hideously ugly, being filled with not just the code for applying every conceivable patch, but the patch arrays themselves. i'd really like to move the actual array contents out of that file into separate includable files (a la DENX 2.4 kernel tree, which is aesthetically far nicer). so, to that end, some questions and looking for feedback on how to do this the cleanest way. first, a summary of what seems to be the logic for applying a ucode patch -- please correct me if i'm wrong: 1) commproc-cp_rccr = 0 ; 2) copy patch array(s) to some combination of offsets 0x0, 0x0e00 or 0x0f00 in DPMEM 3) possibly some extra work to set relocation pointers, whatever 4) possibly set some combination of trap values, cp_cpmcr[1234] 5) reset commproc-cp_rccr to appropriate value is that about right? it might be slightly simplified but are the critical steps there, and are they in the right order? from the sample patches i've seen, the above looks about right, at least for the 8xx (i shudder to think about extending this to other processors, let's not go there just yet, shall we?) now, the current infrastructure. if you take a look at the Kconfig file, the config variables that represent ucode patching are: UCODE_PATCH # *some* patch was selected NO_UCODE_PATCH# *no* patch was selected I2C_SPI_UCODE_PATCH, etc., etc. # one config variable per possible patch that first config variable, CONFIG_UCODE_PATCH, is used in a couple of places. first, in commproc.c: #ifdef CONFIG_UCODE_PATCH /* Perform a reset. */ commproc-cp_cpcr = (CPM_CR_RST | CPM_CR_FLG); /* Wait for it. */ while (commproc-cp_cpcr CPM_CR_FLG); cpm_load_patch(imp); #endif and in Makefile: ... obj-$(CONFIG_SCC_ENET) += enet.o obj-$(CONFIG_UCODE_PATCH) += micropatch.o -- obj-$(CONFIG_HTDMSOUND) += cs4218_tdm.o note that this means that, currently, neither of those files cares about *which* patch was selected, only that *some* patch was selected, and that it's micropatch.c that has to do all the work of checking the config variable, applying the appropriate patch array, etc. (but this could change.) first, i'd like to clean up micropatch.c by moving the actual arrays out of there into separate files, and there's a couple choices for this. i could break them off as per-patch .h include files, and just conditionally include them into micropatch.c depending on the config variable that's set: #ifdef CONFIG_I2C_SPI_UCODE_PATCH # include i2c_spi_patch.h #elif ... and so on. but i know some folks freak at the thought of a .h file containing actual compilable code. i *could* name them as .c files, of course, but then the same folks might freak at #include'ing .c source files. (personally, i'm not that much of a purist here -- i'd be quite happy with either of these.) another option is to simplify the logic in micropatch.c and move the tests into Makefile itself: obj-$(CONFIG_UCODE_PATCH) += micropatch.o obj-$(CONFIG_I2C_SPI_PATCH) += i2c_spi_patch.o obj-$(CONFIG_USB_SOF_PATCH) += usb_sof_patch.o ... etc etc ... and i have no problem with that either. (personally, i'd like to keep the arch/ppc/8xx_io directory relatively clean, and keep all the patch files in a subdirectory, say ucode_patches/ or something like that.) once all the actual arrays are moved out of micropatch.c (however that's done), i'd like to take the patching code that's left and make it *completely* modular, separate for each patch. currently, the cpm_load_patch() routine is being clever and shares common code between some of the patches. i'd prefer having each patch have its own function, even if it means a small amount of code duplication. trying to get clever and share common code is just begging for trouble, in my opinion, so i could see a separate function for each config variable that does all the work. note that that would mean that micropatch.c would still have to process the selected patch config variable, so if it already has to do that, it might be worth having it include the appropriate patch array at the same time and leave Makefile alone. thoughts? the whole idea is to not just make the code clearer, but to make it trivial to add and remove patches as time goes by. i'm willing to create the source code patch, i'm just interested in opinions on which of several ways to do it. rday
Merge 8xx to Linus tree?
On Thu, 14 Oct 2004, Tom Rini wrote: On Thu, Oct 14, 2004 at 04:53:49PM +0200, Joakim Tjernlund wrote: Is it not time to merge 8xx from linuxppc-2.5 into Linus tree? I know the 8xx is not fully functional yet but this isn't done soon I think it won't happen at all. The 8xx arch can be made to depend on BROKEN in Linus tree to make it clear that it isn't working properly yet. I've been the hard-ass about holding back on moving 8xx forward. Once 2.6.9 finally comes out (assuming and hoping that Linus really intends to do a release and not -rc5), I'll start moving stuff over and make it depend on BROKEN hopefully in time for 2.6.10-rc1. not like anyone here would care, but i'm pretty sure that it was my carping and whining some time back on LKML that inspired someone to add the extra options to the kernel config process regarding the selections to pick only drivers expected to compile cleanly, etc. this was based on my having, once too often, done a kernel compile and having the compile fail because a selected driver was just plain broken (from memory, it was a riscom driver that no one cared about anymore). see? sometimes the squeaky wheel really does get the grease. (or maybe they did it just to shut me up. hard to believe ...) rday
Merge 8xx to Linus tree?
On Fri, 15 Oct 2004, Joakim Tjernlund wrote: On Thu, Oct 14, 2004 at 04:53:49PM +0200, Joakim Tjernlund wrote: Is it not time to merge 8xx from linuxppc-2.5 into Linus tree? I know the 8xx is not fully functional yet but this isn't done soon I think it won't happen at all. The 8xx arch can be made to depend on BROKEN in Linus tree to make it clear that it isn't working properly yet. I've been the hard-ass about holding back on moving 8xx forward. Once 2.6.9 finally comes out (assuming and hoping that Linus really intends to do a release and not -rc5), I'll start moving stuff over and make it depend on BROKEN hopefully in time for 2.6.10-rc1. This is great news, thanks. what does this mean in terms of urgency in getting changes into the 8xx stuff, then? does this imply a fixed window of opportunity in the near future, or does it mean that once stuff starts to get moved upstream, it will get moved on a regular basis? just curious. rday
I2C versus IIC
i was just about to rename some of my variables and macros to be consistent with what i *thought* was the standard nomenclature of IIC as opposed to I2C. just checked include/asm-ppc, and grepped for case-insensitive instances of both strings ... oh, god. there's really no preferred usage, is there? rday
I2C versus IIC
On Wed, 13 Oct 2004, Eugene Surovegin wrote: Yeah, the most extreme variant being two-wire serial interface, without even mentioning I2C or IIC. You need some familiarity with bus protocol to figure out that this is really I2C :). oh, gawd, i'm sorry i started this. :-P rday
cleaning up the Kconfig menu structure -- the bigger picture
On Fri, 8 Oct 2004, Dan Malek wrote: Once again I'll add the observation that people using these processors have to know how the boards are configured and to select the proper options. There is lots of variation among the configurations and I'd rather not build complex configuration menus that try to keep users from hurting themselves. The default configuration files are there for a reason, let's use them to assist people (and keep them up to date). i have no problem with that. my point was that what are currently potentially confusing config menus should be made *simpler*. i wasn't even talking about putting smarts into the config menus to keep people from hurting themselves. i was only talking about putting what appeared to be tightly-related config options closer to one another so one did not have to bounce from one place to another in the config menus to select or deselect related features, that's all. not a big deal for me, it was just an observation. If you are making changes to configuration options, it would be nice if you would also at least regenerate all default configuration files affected by this (as I do). At least make an honest attempt at getting it correct. been there, done that, thanks. all of the microcode patch code that i've submitted is based on a user selecting that they want *some* patch, which is reflected by the config variable CONFIG_UCODE_PATCH. for all default config files that refer to this variable, they *all* contain the line: # CONFIG_UCODE_PATCH is not set in short, none of the default config files need to be changed -- they will all initially show a config menu with no selected patch. (what *won't*, of course, be in these default config files is the set of option lines for each possible patch, like: # CONFIG_I2C_SPI_UCODE_PATCH is not set ... and so on. but that doesn't matter, since the first time you configure and save, they'll be generated. in short, the default config files appear to be just fine.) rday p.s. ironically, i recall just yesterday suggesting that soon-to-be-deleted config variables should be removed from those very config files, and i was told to just leave them alone. one does get mixed messages on this list sometimes, don't one? :-)
next pass of cleaning up micropatch.c
On Fri, 8 Oct 2004, Tom Rini wrote: On Fri, Oct 08, 2004 at 11:34:06AM -0400, Dan Malek wrote: On Oct 8, 2004, at 8:44 AM, Robert P. J. Day wrote: + * Shortcut macros for patching code. */ + +#define PATCH2000 \ + dp = (uint *)(commproc-cp_dpmem); \ + for (i=0; i(sizeof(patch_2000)/4); i++) \ + *dp++ = patch_2000[i]; + +#define PATCH2E00 \ + dp = (uint *)(commproc-cp_dpmem[0x0e00]); \ + for (i=0; i(sizeof(patch_2e00)/4); i++) \ + *dp++ = patch_2e00[i]; + +#define PATCH2F00 \ + dp = (uint *)(commproc-cp_dpmem[0x0f00]); \ + for (i=0; i(sizeof(patch_2f00)/4); i++) \ + *dp++ = patch_2f00[i]; Please get rid of these macros and place the code where it belongs. They add no value and just make it harder to read the code and understand what it does. I agree. If there were more patches it might make sense to write a do_microcode_patch2(N) macro, but PATCH2NNN isn't readable and it's only 3 patches. fair enough, but keep in mind, the whole point was that what you're looking at is the minimal *infrastructure* for possibly adding more patches down the road. right *now*, there's only three because those are the only ones that were in micropatch.c at the moment. there's certainly a lot more available at freescale that can be added as time goes by. i'll put the actual code back in, but you might have second thoughts when we're up to 8 or 10 patches some day. :-) rday
[PATCH] further enhancements to micropatch.c
- make distinct patches more modular
- remove apparently redundant IIC/SPI relocation at bottom
- comment out questionable verify_patch() function for now
Signed-off-by: Robert P. J. Day rpjday at mindspring.com
= arch/ppc/8xx_io/micropatch.c 1.3 vs edited =
--- 1.3/arch/ppc/8xx_io/micropatch.c2004-10-07 18:28:32 -04:00
+++ edited/arch/ppc/8xx_io/micropatch.c 2004-10-08 12:13:54 -04:00
@@ -621,15 +621,9 @@
};
#endif
-/* Load the microcode patch. This is called early in the CPM initialization
- * with the controller in the reset state. We enable the processor after
- * we load the patch.
- */
void
-cpm_load_patch(volatile immap_t *immr)
-{
-#ifdef CONFIG_UCODE_PATCH
- volatile uint *dp;
+cpm_load_patch(volatile immap_t *immr) {
+ volatile uint *dp;/* Dual-ported RAM. */
volatile cpm8xx_t *commproc;
volatile iic_t *iip;
volatile spi_t *spp;
@@ -638,23 +632,9 @@
commproc = (cpm8xx_t *)immr-im_cpm;
- /* We work closely with commproc.c. We know it only allocates
-* from data only space.
-* For this particular patch, we only use the bottom 512 bytes
-* and the upper 256 byte extension. We will use the space
-* starting at 1K for the relocated parameters, as the general
-* CPM allocation won't come from that area.
-*/
+#ifdef CONFIG_USB_SOF_UCODE_PATCH
commproc-cp_rccr = 0;
- /* Copy the patch into DPRAM.
-*
-* ADDENDUM: I am somewhat nervous about the next few lines,
-* as they imply that *any* patch will *always* consist of at
-* least the patch_2000[] and patch_2f00[] arrays, and it's
-* not clear to me that that's true. More to come here as I
-* figure this out.
- */
dp = (uint *)(commproc-cp_dpmem);
for (i=0; i(sizeof(patch_2000)/4); i++)
*dp++ = patch_2000[i];
@@ -663,17 +643,24 @@
for (i=0; i(sizeof(patch_2f00)/4); i++)
*dp++ = patch_2f00[i];
-#ifdef CONFIG_USB_SOF_UCODE_PATCH
-
- /* Enable uCode fetches from DPRAM. */
commproc-cp_rccr = 0x0009;
- printk(USB uCode patch installed\n);
-#endif /* CONFIG_USB_SOF_PATCH */
+ printk(USB SOF microcode patch installed\n);
+#endif /* CONFIG_USB_SOF_UCODE_PATCH */
#if defined(CONFIG_I2C_SPI_UCODE_PATCH) || \
defined(CONFIG_I2C_SPI_SMC1_UCODE_PATCH)
+ commproc-cp_rccr = 0;
+
+ dp = (uint *)(commproc-cp_dpmem);
+ for (i=0; i(sizeof(patch_2000)/4); i++)
+ *dp++ = patch_2000[i];
+
+ dp = (uint *)(commproc-cp_dpmem[0x0f00]);
+ for (i=0; i(sizeof(patch_2f00)/4); i++)
+ *dp++ = patch_2f00[i];
+
iip = (iic_t *)commproc-cp_dparam[PROFF_IIC];
# define RPBASE 0x0500
iip-iic_rpbase = RPBASE;
@@ -684,63 +671,46 @@
spp = (spi_t *)commproc-cp_dparam[PROFF_SPI];
spp-spi_rpbase = i;
+# if defined(CONFIG_I2C_SPI_UCODE_PATCH)
+ commproc-cp_cpmcr1 = 0x802a;
+ commproc-cp_cpmcr2 = 0x8028;
+ commproc-cp_cpmcr3 = 0x802e;
+ commproc-cp_cpmcr4 = 0x802c;
+ commproc-cp_rccr = 1;
+
+ printk(I2C/SPI microcode patch installed.\n);
+# endif /* CONFIG_I2C_SPI_UCODE_PATCH */
+
# if defined(CONFIG_I2C_SPI_SMC1_UCODE_PATCH)
+
dp = (uint *)(commproc-cp_dpmem[0x0e00]);
for (i=0; i(sizeof(patch_2e00)/4); i++)
*dp++ = patch_2e00[i];
- /* Enable the traps to get to it.
- */
commproc-cp_cpmcr1 = 0x8080;
commproc-cp_cpmcr2 = 0x808a;
commproc-cp_cpmcr3 = 0x8028;
commproc-cp_cpmcr4 = 0x802a;
-
- /* Enable uCode fetches from DPRAM.
- */
commproc-cp_rccr = 3;
smp = (smc_uart_t *)commproc-cp_dparam[PROFF_SMC1];
smp-smc_rpbase = 0x1FC0;
- printk(I2C/SPI/SMC1 ucode patch installed.\n);
+ printk(I2C/SPI/SMC1 microcode patch installed.\n);
# endif /* CONFIG_I2C_SPI_SMC1_UCODE_PATCH) */
-# if defined(CONFIG_I2C_SPI_UCODE_PATCH)
- /* Enable the traps to get to it.
- */
- commproc-cp_cpmcr1 = 0x802a;
- commproc-cp_cpmcr2 = 0x8028;
- commproc-cp_cpmcr3 = 0x802e;
- commproc-cp_cpmcr4 = 0x802c;
-
- /* Enable uCode fetches from DPRAM.
- */
- commproc-cp_rccr = 1;
-
- printk(I2C/SPI ucode patch installed.\n);
-# endif /* CONFIG_I2C_SPI_UCODE_PATCH */
-
- /* Relocate the IIC and SPI parameter areas. These have to
-* aligned on 32-byte boundaries.
-*/
- iip = (iic_t *)commproc-cp_dparam[PROFF_IIC];
- iip-iic_rpbase = RPBASE;
-
- /* Put SPI above the IIC, also 32-byte aligned.
- */
- i = (RPBASE + sizeof(iic_t) + 31) ~31;
- spp = (spi_t *)commproc-cp_dparam[PROFF_SPI];
- spp-spi_rpbase = i;
-
-#endif
-#endif /* CONFIG_UCODE_PATCH */
+#endif /* some variation of the I2C/SPI patch
cleaning up the Kconfig menu structure -- the bigger picture
On Fri, 8 Oct 2004, Tom Rini wrote: On Fri, Oct 08, 2004 at 07:16:18AM -0400, Robert P. J. Day wrote: ... in that case, if you wanted to configure CPM SCC Ethernet, why would you go under MPC8xx CPM Options rather than the general networking menu? this is clearly inconsistent. Because the CPM1/CPM2 enet drivers are still waiting to be cleaned up a bit more, and moved there. The FEC enet driver that Pantelis wrote lives in drivers/net/ for example. ok, that's cool. more to the point, i've always found it a bit strange that selecting 8xx as a processor would suddenly cause the top-level MPC8xx CPM Options menu to appear, when other 8xx-related stuff was still scattered elswewhere throughout the kernel source tree. That's kinda the opposite direction of where I want things to move. ... i wasn't really arguing for any *particular* rearrangement, just arguing for *some* rearrangement that would be more consistent in terms of layout, that's all. and it sounds like it's already underway, so i'll shut up about it now. rday
next set of proposed microcode patch changes
slowly, but surely. so, assuming that that last submitted patch gets applied, here's the next set of changes i'm thinking about. weigh in one way or the other. some are aesthetic, some are more significant. (if you have objections to that last patch, just make the suggestion here and i can take care of it in the next round.) 1) change all variable references containing I2C to IIC since the latter appears to have historical precedent 2) break out individual patches from within cpm_load_patch() into separate functions in micropatch.c. that function is just getting too darned long and it's only going to get longer 3) remove all of the arrays from micropatch.c and, following the model in wolfgang's 2.4 kernel tree, put them in separate .h files that are simply included based on the config variable. more ambitiously, put all these individual patch files in a patches directory in arch/ppc/8xx_io/ to avoid cluttering this directory 4) at least *start* adding some help content to the Kconfig file thoughts? and now, off to lunch. rday
next pass of cleaning up micropatch.c
On Fri, 8 Oct 2004, Dan Malek wrote: On Oct 8, 2004, at 11:45 AM, Robert P. J. Day wrote: i'll put the actual code back in, but you might have second thoughts when we're up to 8 or 10 patches some day. :-) ... Instead of those macros, I would have written a simple function that takes a microcode patch array, #define'd those hard coded addresses with logical names and passed it into that function. nice idea, but sadly, doomed to failure. note that the code to copy the patch arrays *requires* you to be able to take the sizeof() those arrays to know *exactly* how much to copy. if you pass the array to a function by its address, i'm pretty sure you lose the ability to take its sizeof() anymore, isn't that right? in short, you either need the code or a macro representing the code. a function won't help you here. rday
next pass of cleaning up micropatch.c
On Sat, 9 Oct 2004, Wolfgang Denk wrote: I'm surprised that you didn't think about the possibility to pass the patch length as an argument to the function, that's all. This seems all too obvious to me. oh, sure, if you know the length, it's easy. and who wants to count those bytes? not me. that's why i long ago dropped the idea of writing a function. personally, i still like the macro solution. it seems to be appropriate for a 2-line loop, but i'm not going to start that discussion again. time to move on. rday
[PATCH] 2.6.9(?) kernel, replacing ucode patch infrastructure
On Thu, 7 Oct 2004, Tom Rini wrote: On Wed, Oct 06, 2004 at 09:15:56AM -0400, Robert P. J. Day wrote: ok, one more time, here's a patch that should apply cleanly to the latest bk repo for linuxppc-2.5. the purpose is to create a cleaner and more extensible microcode patch infrastructure, so that all you need to do is *select* the 8xx-relevant patch you want from the config menu under MPC8xx options. This doesn't apply cleanly, even if I tell patch to ignore whitespace changes. Please re-generate, thanks. sorry, i sent the last reply just to tom. the much larger patch referred to here should be applied *instead* of the earlier tinier patch, since i thought we had established that i should send larger, self-contained patches, and that we'd ignore all of my earlier submissions. the obvious solution is to unapply that earlier, tiny patch -- then this one should go in smoothly. rday
[PATCH] remove obsolete arch/ppc/8xx_io/uart.c
On Thu, 7 Oct 2004, Tom Rini wrote: Since these changes can go right into a linux-2.6 tree and out to Linus, I should be able to get BitKeeper to happily merge these changes and your changes. since i already went to the trouble to figure out what it would take to do this, i'll just post it in case any of it is helpful. first, i assume that anything related to UARTs in arch/ppc/8xx_io/ can be deleted (the newer stuff being in drivers/serial/cpm_uart/). this would include uart.c, and any references to UARTs in both Kconfig and Makefile. so that stuff is pretty easily deletable. regarding Kconfig, that currently defines the following config variables related to UARTs (all of the latter ones dependent on the first, so if you delete the first, all the rest pretty well have to vanish as well): CONFIG_8xx_UART CONFIG_SMC2_UART CONFIG_ALTSMC2 CONFIG_CONS_SMC2 CONFIG_USE_SCC_IO if you get rid of that chunk of Kconfig, then you better make sure there's nothing in the rest of the kernel source that refers to any of those config variables in any meaningful way. other than uart.c, some of these variables are listed in arch/ppc/configs/*, so you'd probably want to clean up any of those defconfig files while you're at it. (as an example, the file SM850_defconfig contains the line CONFIG_CONS_SMC2=y not good. :-) now, once all that stuff is taken care of, i'm assuming all UART-related stuff and its configuration is found under drivers/serial/cpm_uart/, and the kernel config menu for that stuff under Device drivers - Character devices - Serial drivers apparently, according to this menu, i can walk through and select every single serial port possibility: SMC[12] and SCC[1234]. but even after you do that, you can apparently still go to the MPC8xx menu and select to put ethernet on, say, SCC1. i'm pretty sure you shouldn't be able to select that SCC1 is for both UART and ethernet simultaneously. just need to add more dependencies to some Kconfig files, i suspect. thoughts? rday
[PATCH] remove obsolete arch/ppc/8xx_io/uart.c
On Thu, 7 Oct 2004, Dan Malek wrote: On Oct 7, 2004, at 2:48 PM, Tom Rini wrote: CONFIG_8xx_UART CONFIG_SMC2_UART CONFIG_ALTSMC2 CONFIG_CONS_SMC2 CONFIG_USE_SCC_IO Not all of these options exist in linux-2.6. Why not? They must or some equivalent to get these features. I dislike this 2.6 forward progress that continually removes features we have deemed necessary in previous kernel versions. actually, i was going to mention this very point earlier, but i got the impression that others were already all over this issue so i left it alone. in the current Kconfig file, you have the option of selecting which of SMC1 or SMC2 you want to be the console. fair enough, and a useful feature to be sure. but if the UART-related stuff is removed from arch/ppc/8xx_io, then i'm assuming you'll do that configuration under the menu Device Drivers -- Character devices -- Serial drivers CPM SCC/SMC serial port support at least, that's what it looks like. but there's no equivalent selection to pick *exactly* where you want your console in that submenu. i wasn't suggesting that all the above *features* had to be expunged -- just that those specific variables were related to the old UART way of doing things and had to be dealt with, one way or the other. obviously, new variables should be added to the new config part of the menu to add that functionality back in (the same names could, of course, be re-used). as it stands, from what i can see by looking through the directory drivers/serial/cpm_uart, there is currently no way to select your console (among other things). before messing with any more code, i think someone has to sit down and just design the Kconfig menus that will represent all the features you want, with menus, submenus, variables, dependencies and so on. thoughts? rday I think this had been discussed before, but perhaps not. What should happen at some point is something more like Do you hae SMC1 ? What is it? Do you have SMC2 ? What is it? Do youhave SCC1? What is it? and so on. For now, I wouldn't worry about it. I don't understand the what is it? part of these questions. As I have continually pointed out over the years, we don't have SMC or SCC drivers. We have UART drivers that use SMCs or SCC, Ethernet drivers that use SCCs or FECs, audio drivers that use SMCs or SCCs, and so on. It's a subtle but important configuration selection. You select the feature you want (uart, Ethernet, audio, ATM, etc.), then you can be further prompted for peripheral routing information if necessary. We have discussed this at length in the past. Thanks. -- Dan
[PATCH] first in a series to enhance microcode patches
On Tue, 5 Oct 2004, Wolfgang Denk wrote: In message Pine.LNX.4.60.0410051543230.3549 at localhost.localdomain you wrote: that's definitely understandable. it's just potentially confusing to have a structure's reserved chunks declared as some combination of uchar, ushort, uint and/or ulong, when it's obviously more comprehensible to make each reserved chunk a standard array of char whose size is obvious at a glance. Actually this might not be confusing, but making the code easier to read, to understand, and maybe one day to extend - remember that these struct definitions are direct translations of Motorola provided documentation - and I tend to believe that the chip manufacturer knows more about the internals of his chips than you or me. One day, a uint reserved_xxx; may turn into a new, shiny 32 bit register. from Documentation/SubmittingPatches, at the very end: 4) Don't over-design. Don't try to anticipate nebulous future cases which may or may not be useful: Make it as simple as you can, and no simpler it seems that, if that's good advice for patches, it should be good advice for the code proper. i do appreciate your point, but if at some point, a shiny new register suddenly appears, that strikes me as a significant enough change that mods to the header file shouldn't be considered a big deal. anyway, just my $0.02. rday
[PATCH] first in a series to enhance microcode patches
On Wed, 6 Oct 2004, Mark Chambers wrote: Rob, What about, if it ain't broke, don't fix it. If it were my code I wouldn't touch that stuff - at best you get pretty code, at worst you break something. oh, i wasn't suggesting going through removing the volatile qualifier from reserved spaces or anything insane like that. i was just making an observation, that's all. i have no intention of touching that stuff. really. i promise. :-) rday
more (unanswered) questions on microcode patches
and since i'm pretty sure i haven't beaten this subject bloody yet, and while i wait -- patiently -- for my patch to be applied, some questions to clarify still-mysterious issues related to ucode patches so i can make further enhancements. i've asked some of these before and i still haven't got an unambiguous answer. 1) is there any value to the source file arch/ppc/8xx_io/uart.c anymore? i was under the impression that the code to implement UARTs now lives in drivers/serial/cpm_uart/. if that's the case, that file, and all references to it in other files (Makefile, Kconfig) should be deleted. (i can add those deletions to a subsequent patch if it's appropriate.) (as it is, i'm not selecting Use UART from the MPC8xx CPM Options menu, but i still have my console on SMC1 working just fine.) 2) as it stands now, the file for applying ucode patches (micropatch.c) just flat out assumes that *all* conceivable patches will be represented at least by arrays to be copied to offsets at 0x2000 and 0x2f00. this strikes me as dangerous since you can set the RCCR register to specify that the patch locations in DPMEM can be 0x2000 and 0x2e00 instead. if there's ever a patch that involves loading patch code at those addresses instead, micropatch.c will blow up, looking for an array named patch_2f00 that doesn't exist. any thoughts on this? (the function verify_patch() has the same potential problem -- it flat out assumes that there will always exist arrays named patch_2000 and patch_2f00, and will not bother to verify any other patch array, like patch_2e00. since no one even calls this function, it's not like it's a problem. but, if no one calls it, what's it doing there? in any case, it's pretty clearly wrong. 3) and, still on the topic of verify_patch() in micropatch.c, i'm still bothered that, at the top, rccr - 0 (good), and is then explicitly set back to 0x0009 at the bottom, which just *can't* be right. it would seem that what you want is to save rccr at the top, and *restore* it at the bottom. again, since no one calls this function, it's not like this is going to hurt, but that code has just *got* to be wrong. basically, that verify_patch() function is pretty much junk. there's more, but i'd settle for clarification of the above for now. rday
[PATCH] first in a series to enhance microcode patches
(after a short discussion with tom rini, we're going to ignore any
previous patch submissions of mine WRT microcode patches and start
fresh. first trivial patch, just to start things off.)
purpose of patch:
1) adds a relocation pointer to smc_uart_t
2) redeclares reserved chunks in structures to be in terms of a
standard char array, rather than the hideous combination of uint,
ushort, and so on. (a purely aesthetic fix, admittedly.)
more patches to follow shortly.
--- linuxppc-2.5/include/asm-ppc/commproc.h 2004-09-16 13:08:12.0
-0400
+++ linuxppc-2.5-new/include/asm-ppc/commproc.h 2004-09-16 13:40:52.0
-0400
@@ -145,6 +145,8 @@
ushort smc_brkec; /* rcv'd break condition counter */
ushort smc_brkcr; /* xmt break count register */
ushort smc_rmask; /* Temporary bit mask */
+ charres1[8];/* Reserved */
+ ushort smc_rpbase; /* Relocation pointer */
} smc_uart_t;
/* Function code bits.
@@ -475,8 +477,7 @@
*/
typedef struct scc_uart {
sccp_t scc_genscc;
- uintscc_res1; /* Reserved */
- uintscc_res2; /* Reserved */
+ charres1[8];/* Reserved */
ushort scc_maxidl; /* Maximum idle chars */
ushort scc_idlc; /* temp idle counter */
ushort scc_brkcr; /* Break count register */
@@ -560,9 +561,9 @@
ushort iic_tbptr; /* Internal */
ushort iic_tbc;/* Internal */
uintiic_txtmp; /* Internal */
- uintiic_res;/* reserved */
+ charres1[4];/* Reserved */
ushort iic_rpbase; /* Relocation pointer */
- ushort iic_res2; /* reserved */
+ charres2[2];/* Reserved */
} iic_t;
#define BD_IIC_START ((ushort)0x0400)
[PATCH] first in a series to enhance microcode patches
resend of previous patch -- sorry, forgot the developer's cert of
origin. please be patient, i'm slowly getting the hang of this.
purpose of patch:
1) adds a relocation pointer to smc_uart_t
2) redeclares reserved chunks in structures to be in terms of a
standard char array, rather than the hideous combination of uint,
ushort, and so on.
Signed-off-by: Robert P. J. Day rpjday at mindspring.com
--- linuxppc-2.5/include/asm-ppc/commproc.h 2004-09-16 13:08:12.0
-0400
+++ linuxppc-2.5-new/include/asm-ppc/commproc.h 2004-09-16 13:40:52.0
-0400
@@ -145,6 +145,8 @@
ushort smc_brkec; /* rcv'd break condition counter */
ushort smc_brkcr; /* xmt break count register */
ushort smc_rmask; /* Temporary bit mask */
+ charres1[8];/* Reserved */
+ ushort smc_rpbase; /* Relocation pointer */
} smc_uart_t;
/* Function code bits.
@@ -475,8 +477,7 @@
*/
typedef struct scc_uart {
sccp_t scc_genscc;
- uintscc_res1; /* Reserved */
- uintscc_res2; /* Reserved */
+ charres1[8];/* Reserved */
ushort scc_maxidl; /* Maximum idle chars */
ushort scc_idlc; /* temp idle counter */
ushort scc_brkcr; /* Break count register */
@@ -560,9 +561,9 @@
ushort iic_tbptr; /* Internal */
ushort iic_tbc;/* Internal */
uintiic_txtmp; /* Internal */
- uintiic_res;/* reserved */
+ charres1[4];/* Reserved */
ushort iic_rpbase; /* Relocation pointer */
- ushort iic_res2; /* reserved */
+ charres2[2];/* Reserved */
} iic_t;
#define BD_IIC_START ((ushort)0x0400)
[PATCH] first in a series to enhance microcode patches
On Tue, 5 Oct 2004, Tom Rini wrote: On Tue, Oct 05, 2004 at 03:20:37PM -0400, Dan Malek wrote: No, send a whole patch that _does_ something. Let's see all of these changes at once. By itself, this patch is useless and doesn't add any features, it just wastes our time discussing it. A series of inter-dependant patches might be better, but I like small, easy to understand patches. you know, it's a good thing i'm severely bipolar. :-) somebody needs to make a decision -- i'll go with whatever it is. rday
[PATCH] first in a series to enhance microcode patches
On Tue, 5 Oct 2004, Dan Malek wrote: No, send a whole patch that _does_ something. Let's see all of these changes at once. By itself, this patch is useless and doesn't add any features, it just wastes our time discussing it. ok, not a problem. i'll submit it any way the powers that be prefer, i just wanted explicit instructions on how. give me a day and i'll have a full, working patch. that does something. 2) redeclares reserved chunks in structures to be in terms of a standard char array, rather than the hideous combination of uint, ushort, and so on. (a purely aesthetic fix, admittedly.) Just for information, most of the original data structures were all machine generated with some minor manual touch ups. I certainly wasn't going to type in all of that stuff and risk mistakes with offsets and sizes. that's definitely understandable. it's just potentially confusing to have a structure's reserved chunks declared as some combination of uchar, ushort, uint and/or ulong, when it's obviously more comprehensible to make each reserved chunk a standard array of char whose size is obvious at a glance. just for fun, $ cd include/asm-ppc $ grep -i reserved *.h man. the standards for declaring reserved space are all over the map, including this one: mpc52xx.h: volatile u32reserved[4];/* MMAP_CTRL + 0x3c .. 0x48 */ mpc52xx.h: volatile u32reserved1; /* INTR + 0x20 */ mpc52xx.h: volatile u32reserved2; /* INTR + 0x34 */ ... now *that* kind of creeps me out. why is reserved space being declared as volatile? yeesh. i may not understand what's happening here but, IMHO, if something is declared as reserved, that should be an indication that *nobody* is using it. if it's being used for anything, then it shouldn't be labelled as reserved; it should have a name. to be both volatile and reserved just makes me queasy. but that's just me. rday
what is the protocol for getting patches into the tree?
(i emailed dan m. offline about this earlier, but i have no way of
knowing if he's the right person to ask, so i'll post here and try to
settle this once and for all.)
*what* does it take to get a patch into the bk-managed kernel source
tree at http://ppc.bkbits.net:8080/linuxppc-2.5. originally, as i was
learning the ropes here and started to make suggestions, i was told,
in no uncertain terms, to submit a patch.
once i figured out what i wanted, i did indeed start submitting
patches. and, without exception (as far as i can tell), every one of
them was discarded without acknowledgement or any reason for
rejection. at this point, i'm sure you can appreciate that the
frustration level is starting to build. it's not terribly productive
to be told to submit patches, when whatever time i put into doing so
turns out to be a complete waste of time.
is this even the right place for such patches? or should i be
submitting to the LKML list proper? or what? i'm more than willing
to follow the instructions for doing this the right way, i just need
to know what the right way is.
what follows is (for ... what ... the third time?), an attempt to
just extend the smc_uart struct in commproc.h to add a relocation
pointer. there's no reason i can think of why this shouldn't be
applied. it can't possible break anything, it adds functionality, and
it makes that struct consistent with the I2C and SPI structs that have
analogous relocation pointers. what's not to accept? (it also makes
an aesthetic change to that file to define reserved chunks of structs
with a standard char, rather than with the really hideous practice
of using int, short or whatever size the reserved space happens to
represent. but if people are offended by that *change*, i'll be happy
to take it out. i just want the gosh-darned relocation pointer.)
i can submit sizable patches that try to do several related things
at once, or i can do it two lines at a time. given the standard
protocol over at LKML, am i expected to just keep submitting the same
patch over and over, again and again, repeatedly, until it gets in?
some guidance here would be appreciated. is there a code word? a
secret handshake? what?
and now, the patch. if there's a problem with this (format,
functionality, whatever), can someone explain it so i can fix it and
try again? that's all i'm asking. (this patch was generated by
running bk -r diffs -u. if it should be done another way, i'd be
happy to learn about that, too.)
--- linuxppc-2.5/include/asm-ppc/commproc.h 2004-09-16 13:08:12.0
-0400
+++ linuxppc-2.5-new/include/asm-ppc/commproc.h 2004-09-16 13:40:52.0
-0400
@@ -145,6 +145,8 @@
ushort smc_brkec; /* rcv'd break condition counter */
ushort smc_brkcr; /* xmt break count register */
ushort smc_rmask; /* Temporary bit mask */
+ charres1[8];/* Reserved */
+ ushort smc_rpbase; /* Relocation pointer */
} smc_uart_t;
/* Function code bits.
@@ -475,8 +477,7 @@
*/
typedef struct scc_uart {
sccp_t scc_genscc;
- uintscc_res1; /* Reserved */
- uintscc_res2; /* Reserved */
+ charres1[8];/* Reserved */
ushort scc_maxidl; /* Maximum idle chars */
ushort scc_idlc; /* temp idle counter */
ushort scc_brkcr; /* Break count register */
@@ -560,9 +561,9 @@
ushort iic_tbptr; /* Internal */
ushort iic_tbc;/* Internal */
uintiic_txtmp; /* Internal */
- uintiic_res;/* reserved */
+ charres1[4];/* Reserved */
ushort iic_rpbase; /* Relocation pointer */
- ushort iic_res2; /* reserved */
+ charres2[2];/* Reserved */
} iic_t;
#define BD_IIC_START ((ushort)0x0400)
Status of uart driver on mpc8xx in 2.6
On Thu, 30 Sep 2004, Robin Gilks wrote: Greetings Could anyone point me to a uart driver for mpc8xx as the one in 2.6.8.1 obviously has not been hacked from the 2.4 variant since it still contains references to DECLARE_TASK_QUEUE and other things that have changed. I'm sure there is a ppc 'special' tree that has all the necessary fixes but with this list disappearing for a while I've rather lost track of what is where!! as i understand it, the source file arch/ppc/8xx_io/uart.c is no longer used. you'll find the uart stuff in drivers/serial/cpm_uart, i think. at least, that's where i'm messing with the code. rday
value of XIP? and whether it works with 2.6 kernel?
working with a recent post to the MTD mailing list, and reading the wiki part on XIP over at www.denx.de, i'm curious about who's using XIP with the 2.6 kernel, specifically with the 8xx boards. as i read it from david w's post on the MTD list, XIP has limited value since flash is noticeably more expensive than RAM anyway. so, thoughts? who's actually using this? and it's not clear from the DENX page that there's a patch for the 2.6 kernel -- that page refers specifically to 2.4. anyway, i'm just curious, wondering whether it would be worth giving it a try, just for the entertainment value. rday ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Init hangs
On Fri, 6 Aug 2004, Dan Malek wrote: On the MPC8xx, which does not have a floating point unit, there is still sufficient support in the kernel to trap and emulate FPU reset and context save/restore for this purpose. You only need the CONFIG_MATH_EMULATION is you intend to really do floating point arithmetic. thanks for that tidbit. i've always wondered, for our 850DE, hmmm ... math emulation or no math emulation? i guess i can just make sure it's turned off, and see if it ever causes a problem. rday ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
yee ha. SMC1 relocation working under 2.6.
based on a patch set that i got from torsten demke (thank you, mr. demke), and incorporated into my patch set, i verified that i now have SMC1 relocation. hot diggety. about to go for ethernet on SCC3. rday p.s. previous patch i posted here had a stupid omission, forgot to add a few critical lines to micropatch.c from torsten's patch, but once that went in, the boot confirmed that SMC1 was now at 0x1FC0. slowly, but surely ... ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] add reserved and smc_rpbase field to smc_uart
first patch to add the required reloc field for SMC1 relocation -- is this the appropriate format? --- linuxppc-2.5/include/asm-ppc/commproc.h 2004-07-27 12:23:32.723864264 -0400 +++ linuxppc-2.5.new/include/asm-ppc/commproc.h 2004-07-27 12:29:27.609913384 -0400 @@ -145,6 +145,8 @@ ushort smc_brkec; /* rcv'd break condition counter */ ushort smc_brkcr; /* xmt break count register */ ushort smc_rmask; /* Temporary bit mask */ + uchar smc_res[8]; /* Reserved to push next field to 0x3C */ + ushort smc_rpbase; /* Relocation pointer */ } smc_uart_t; /* Function code bits. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] move 8xx microcode patches into Kconfig submenu
create a submenu for 8xx microcode patches to keep them organized in one place, under the assumption that there will be more to come. --- linuxppc-2.5/arch/ppc/8xx_io/Kconfig 2004-07-27 12:36:24.050604776 -0400 +++ linuxppc-2.5.new/arch/ppc/8xx_io/Kconfig 2004-07-27 12:36:56.869615528 -0400 @@ -140,6 +140,8 @@ If in doubt, say N here. +menu Microcode patches + config UCODE_PATCH bool I2C/SPI Microcode Patch help @@ -150,3 +152,5 @@ endmenu +endmenu + ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
more questions about 8xx microcode patches
after poring over the header and source files, and the MOT docs, a few questions about possible microcode patches, based on the following layout of the parameter RAM memory map of the MCP850 family, reproduced from the user's manual (and, just remember, i'm not *trying* to be pedantic or annoying, i am merely succeeding :-): the DPRAM memory map: Offset from DPRAM base Controller 0x1C00-0x1C7F USB 0x1C80-0x1CAF I2C 0x1CB0-0x1CBF Misc. 0x1CC0-0x1CCF IDMA1 (whatever that is) 0x1D00-0x1D7F SCC2 0x1D80-0x1DAF SPI 0x1DB0-0x1DBF RISC timer table 0x1DC0-0x1DFF IDMA2 0x1E00-0x1E7F SCC3 0x1E80-0x1EBF SMC1 0x1EC0-0x1EFF (Reserved) 0x1F00-0x1F7F (Reserved) 0x1F80-0x1FBF SMC2 0x1FC0-0x1FFF (Reserved) so, barring any typoes in the above ... 1) i recall that, while the manual lists the first controller above as USB, SCC1 is also a possibility for other 8xx processors, yes? (i'm sure i saw this somewhere; it's not an issue for us, i just wanted to be complete.) 2) given the size of the scc_enet structure in commproc.h, the whole reason to relocate SMC1 is to let ethernet on SCC3 spill over into the normally-reserved SMC1 memory. i would assume the same situation would hold if you were trying to use SCC2 for ethernet -- you'd need to relocate SPI, right? 3) speaking of I2C and SPI, what's the rationale for pretty much every single piece of information insisting that these two controllers are relocated as a pair? micropatch.c provides a patch which relocates them both, a motorola doc i have has a table entitled I2C/SPI Parameter RAM as if these things are absolutely inseparable. but they clearly initially live in different locations, and commproc.h has two distinct structs -- iic and spi. so why historically are these two so inextricably linked, especially in terms of a relocation patch? can't you relocate one and leave the other where it is? certainly, if i wanted to put ethernet on SCC2, SPI would have to move but not I2C. rationale? (if address 0x1C00 was in fact being used for SCC1, then ethernet on SCC1 would require I2C to move. you get the idea.) 4) the current micropatch.c file appears to limit one to applying a single patch. the first patch (written to DPRAM address 0) appears to relocate both I2C/SPI (there's that linkage again). further down, there's a test for USE_SMC_PATCH (*clearly* not compatible with the first patch since they both write to DPRAM address 0) which represents the SMC/I2C/SPI patch. (actually, it reads SMC2, which i assume is a typo.) i'm assuming that this patch relocates *all* of SMC1, I2C and SPI. this suggests that there's currently no patch for just relocating SMC1, which seems somewhat restrictive. is there no reason why someone might want to relocate just SMC1? or does that patch just not exist? 5) in general, what patches should exist? taking into account that applying some patches may make others impossible to use, what should be in the list of possible microcode patches in the MPC8xx CPM submenu? right now, it seems that that list could contain two entries: I2C/SPI SMC1/I2C/SPI which would be mutually exclusive. should there be others? SMC1 by itself? SMC2? 6) should the USB SOF patch listed in micropatch.c be an option? despite the fact that, as some have pointed out, USB is kind of borked in the 850 Rev B board? it seems that creating a menu of 8xx microcode patches would be fairly easy: 1) collect the current patches, assign them symbolic names [*] 2) decide which are mutually exclusive and code that into Kconfig 3) using the denx 2.4.25 tree as a model, put each patch into a separate source file and just include the appropriate file, making the appropriate changes to source files like cpm_uart_cpm1.c where necessary thoughts? rday [*] definitely need some decent Kconfig names for possible ucode patches if there's going to be a list. the current UCODE_PATCH would clearly have to go. :-) ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
more questions about 8xx microcode patches
On Tue, 27 Jul 2004, Dan Malek wrote: On Jul 27, 2004, at 4:23 PM, Robert P. J. Day wrote: it seems that creating a menu of 8xx microcode patches would be fairly easy: Hahahahaha You don't know how big of a hole you are digging :-) oh, fer shure. :-) but given that there are three clear and identifiable patches that exist at the moment, i'll put together a patch that turns them into a submenu and submit it, and you can decide what to do with it. i'll make sure that the submission doesn't change any of the current functionality, just makes it easier to pick what you want. (specifically, it's inconvenient to be able to select one patch via Kconfig, and the other only by editing micropatch.c. but give me a bit, and i'll post something based on those other two small patches i submitted.) rday p.s. should patches be submitted as main body in postings, or as attachments? or do you care? ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
more questions about 8xx microcode patches
On Tue, 27 Jul 2004, Mark Chambers wrote: Robert, I know I've never had a need to use a microcode patch. Maybe a quick survey - has anybody ever had a need to use two patches at once? I'm suspecting you may be putting a lot of effort into something that's rarely needed. Also, as Motorola updates their silicon the patches will likely become less relevant (less likely that new users will need the patches). on my project alone, we've needed two different selections of those patches. so while it's not an earth-shattering modification, it doesn't hurt and it sometimes helps. and it makes the addition of any future patches really trivial, if that ever happens. rday ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
question about specific patch to cpm_uart_core.c for SMC reloc
torsten demke sent me a set of patches for SMC1 relocation and they included the following addition to cpm_uart_core.c: diff -purN linuxppc-2.6.7-bk1.1248-org/drivers/serial/cpm_uart/cpm_uart_core.c linuxppc-2.6.7-bk1.1248/drivers/serial/cpm_uart/cpm_uart_core.c --- linuxppc-2.6.7-bk1.1248-org/drivers/serial/cpm_uart/cpm_uart_core.c 2004-07-20 10:57:37.0 +0200 +++ linuxppc-2.6.7-bk1.1248/drivers/serial/cpm_uart/cpm_uart_core.c 2004-07-20 11:02:21.0 +0200 @@ -743,6 +743,15 @@ static void cpm_uart_init_smc(struct uar pinfo-smcup-smc_rbase = (u_char *)pinfo-rx_bd_base - DPRAM_BASE; pinfo-smcup-smc_tbase = (u_char *)pinfo-tx_bd_base - DPRAM_BASE; +#if defined (CONFIG_SHMC) defined (CONFIG_UCODE_PATCH) + up-smc_rbptr = pinfo-smcup-smc_rbase; + up-smc_tbptr = pinfo-smcup-smc_tbase; + up-smc_rstate = 0; + up-smc_tstate = 0; + up-smc_brkcr = 1; /* number of break chars */ + up-smc_brkec = 0; +#endif + AFAICT, the added code at the bottom is because, when you relocate SMC1, you lose some functionality. is there, somewhere, i can read up on what the above is fixing? thanks. i think that's the last piece of the puzzle -- all the rest of the changes make sense. rday ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
more questions about 8xx microcode patches
On Tue, 27 Jul 2004, Dan Malek wrote: On Jul 27, 2004, at 4:23 PM, Robert P. J. Day wrote: it seems that creating a menu of 8xx microcode patches would be fairly easy: Hahahahaha You don't know how big of a hole you are digging :-) Now, Ward, don't just tell the Beav he shouldn't do it. It's always better when they learn these things on their own. rday ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
2.4 versus 2.6 patches
On Mon, 26 Jul 2004, Mark Chambers wrote: If 2.4 works already for you, by all means use it -- but if you're doing any new development, or you _really_ want people to care when you find bugs, it really ought to be 2.6. Well, this is a surprise to me. Does the stock 2.6 even compile on 8xx yet, or are you talking about 8xxx and/or IBM? well, the linuxppc-2.5 bk pull from bkbits.net compiles and boots on our 8xx board. although i'm still working on relocating SMC1 to allow ethernet on SCC3. but other than that, sure, it builds and boots. rday ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
couple questions about MPC8xx CPM Options menu
On Sat, 24 Jul 2004, Dan Malek wrote: If you want something different, submit a patch for consideration that changes the behavior. Thanks. ok, fair enough. thanks. rday ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Could 2_4_devel support RPXlite DW LCD panel?
From: Song Sam [EMAIL PROTECTED] I want to port 2_4_devel on RPXlite DW with framebuffer support and tried linuxppc_2_4_devel in linuxppc official BK tree and DENX tree repectively but failed.Could anyone try it before?Worked? is it just the FB selection that's causing problems? and what do you mean by failed? you'll have to be more specific. does the system fail to boot? does it boot but the FB doesn't work? etc, etc. rday ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
different device file name when relocating SMC1?
working with the latest 2.4.25 kernel tree from denx (sorry, i know everyone else is keen on 2.6, but we do have a project to maintain), i have a baseline kernel config for our 850DE board with SMC1 UART, and no networking configured in yet. i just wanted to test the simple relocation of SMC1 *in* *preparation* for adding ethernet on SCC3, so i added the ucode patches to shift SMC1 (that was the only change in the kernel config), and a couple of us moved over the patches from the old uart.c file as best we could. with just this change, all we now get at boot time is: Linux/PPC load: console=ttyS0,9600 rw root=/dev/ram0 Uncompressing Linux...done. Now booting the kernel ... and hang ... so, simple question -- until now, we've identified the console as ttyS0, and it's worked fine. does relocation require referring to the console with a different device file name? i (vaguely) recall /dev entries with names like cpmuart0 or something like that. given relocation, should i be using something other than ttyS0? (chances are, of course, we have to mess with uart.c a bit longer to see what's different between the two 2.4 kernel trees, but i thought i'd ask if it could be something this simple.) rday ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
couple questions about MPC8xx CPM Options menu
is there some rationale for the 8xx CPM options menu to contain entries for either of: 860T FEC Ethernet CPU6 Silicon Errata (860 Pre Rev. c) the first has a help entry that refers, not to the 860, but to the 8260 (making it out of place here). and the second, while being in the 8xx family, is still displayed even after choosing a platform that's not an 860. (the same can be said for the first option as well -- why is it still available if one selects, say, the 850-based rpxlite?) this is the sort of confusion i was talking about in my earlier emails. rday ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
random ramblings on 8xx patches (long and tedious :-)
On Thu, 22 Jul 2004, Matt Porter wrote: On Thu, Jul 22, 2004 at 08:00:01AM -0400, Robert P. J. Day wrote: [Remove long explanation] thoughts? i'm willing to help with menu reorg -- my only contribution to the 2.6 kernel was to thoroughly restructure the Filesystems menu. which means i like it, and i don't care what *you* think. ;-) You raise a lot of interesting concerns on usability for a newbie. Descriptive menu options with useful help info are a good thing. Please send a patch with your proposed changes so it can be reviewed. the first addition i'd like to see is a set of extra conditionals added to arch/ppc/config.in, to refine the type of processor. in some cases, it's not enough to know that you have an 8xx, and it's *too* refined to know that you have, say, a TDM850M. sometimes, you need to know only that you have an 823, or 850, or whatever. perhaps variables: CONFIG_8xx_823 CONFIG_8xx_850 CONFIG_8xx_860 or alternatively named CONFIG_PPC_823 CONFIG_PPC_850 and so on. i've already seen code in the kernel tree (can't remember where, sadly) that goes through a tedious preprocessor check when all it wanted to know was the actual processor. and all of this extra checking and setting could be done entirely within the arch/ppc/config.in file, with no harm to other files or small animals. (i suspect the same might hold true for 4xx, 6xx and others, but i haven't looked at those yet.) i can't design this patch just yet, as i'm not sure how many different variants are worth keeping track of. if there's a list someone could point me at, that would be just ducky. rday p.s. sadly, there's some inconsistency in the way the current variable names were chosen. in that same file, we have both of CONFIG_8xx and CONFIG_PPC_5xxx. even thought it's more verbose, it might have been safer to keep that PPC internal string to avoid potential conflicts. so it's a tossup as to what variable name would be the best choice to identify an 850: CONFIG_850 CONFIG_PPC_850 CONFIG_8xx_850 thoughts? yes, this is just me being pedantic. it gets worse. :-) ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
random ramblings on 8xx patches (long and tedious :-)
On Fri, 23 Jul 2004, Wolfgang Denk wrote: In message Pine.LNX.4.60.0407230821050.4487 at localhost.localdomain you wrote: CONFIG_850 CONFIG_PPC_850 CONFIG_8xx_850 thoughts? yes, this is just me being pedantic. it gets worse. :-) How far do you want to take this? 850 may not be detailed enough - is it a MPC850, MPC850DE, MPC850DSL, or a MPC850SR ? There is at least 40 differnt models of 8xx processors. Go and add 82xx and 85xx and 52xx and than start working down the 4xx, 7xx, 74xx, ... lines? I think this gives a LONG list... possibly, but there's no need for it to be infinitely detailed. if you look at arch/ppc/config.in, there's obviously a coarse categorization with things like CONFIG_6xx, CONFIG_8xx and so on. at the other extreme, there's specific models like CONFIG_ARCTIC2, etc. there's also *some* current refinement somewhere in the middle with conditionals like: if [ $CONFIG_TQM823M = y -o \ $CONFIG_TQM850M = y -o \ $CONFIG_TQM855M = y -o \ $CONFIG_TQM860M = y -o \ $CONFIG_TQM862M = y -o \ $CONFIG_NSCU= y ]; then define_bool CONFIG_TQM8xxM y so *someone* must have thought this approach was a good idea at some point. :-) so the obvious question is, is there any value for more of this mid-level categorization? if not, then we can just forget the idea and move on. but if there is, no one says it has to be patched in all at once. different people who work with different processors can submit patches relative to their area to make future work easier. if someone works primarily with, say, 4xx processors, they can submit a patch to add to the config.in file for that family refining the 4xx family. whatever makes their life easier. if no one cares about a particular family, no big deal. as a thought, what about additional variables of the form CONFIG_850, CONFIG_7xx, CONFIG_74xx, etc. (sadly, as i mentioned earlier, there's already some inconsistency between names like CONFIG_8xx and CONFIG_PPC_5xxx with that internal PPC_. technically, i would have preferred variables of the form CONFIG_PPC_, but i think the trend has already been established.) so, to start things off, here's a proposal. if this kind of refinement would have made/will make your life easier, email me directly with the patch you'd like to see added. i'll collect them all, paste them together, make sure they're aesthetically consistent, examine the final result as if i know what i'm doing, and submit the whole thing as one big patch. you don't need to be perfect with the first attempt, you can always save further, more detailed refinement for a later patch. thoughts? rday ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
850 Rev C (the USB fix)
850 Errata http://www.freescale.com/files/32bit/doc/errata/MPC850CE.pdf 850 Errata Summary http://www.freescale.com/files/netcomm/doc/errata/MPC850CESUMM.pdf rday ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
2.4 versus 2.6 patches
i just realized that the sample excerpts i was posting from the ppc config files were from the 2.4 source tree, not 2.6, so for most of the folks on this list, i suspect they'd be more interested in patches to a 2.6-style Kconfig file, not a 2.4-style config.in file, correct? rday ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
random ramblings on 8xx patches (long and tedious :-)
i'd like to clarify a number of things regarding potential 8xx patches, ask some questions, make some observations, etc. (poor wolfgang has already seen much of this via private e-mail so i expect he'll skim it, if that. i'm still working thru his replies so i'll be repeating some of the stuff i already sent him.) What's a patch? - from the mpc850 family user's manual, i have the parameter RAM memory map table (USB, I2C, SCC2, SPI, and so on), and it's clear that a major purpose of patching is to relocate some of these areas elsewhere in DPRAM by patching the microcode (did i phrase that correctly?) in our case, we need to relocate SMC1 so we can use SCC3 for ethernet, and we already have that working under an ancient 2.4.22 kernel so, yes, we've succesfully applied a patch. does that completely cover the definition of a patch? an array of hex values to be written to, say, 2000, or 2f00 (or elsewhere)? and strictly for the purposes of parameter relocation? if not, what else would fall under the definition of patch that should be available to the developer? How many potential patches are there? - currently, in the latest bk pull, there is only one patch selection option: I2C/SPI Microcode Patch. but clearly there are other choices. even though that's the only selection listed in the config menu, if you look at micropatch.c, there's mention of an SMC patch (which you can apparently get only by editing the file, not by just selecting an option). there's also reference to a USB SOF patch. why wouldn't these also be listed in the kernel config menu? it seems misleading to display a choice for only a single patch when, in fact, there are *clearly* others (specifically, SMC1 relocation to use SCC3 for ethernet which is the one we need although, admittedly, that's kind of specialized). rather than that single selection in the MPC8xx CPM Options, it would make far more sense to have *all* patches listed as subentries under a patch menu, like: MPC8xx CPM Patches -- akin to top-level config menu entries like: Device drivers -- File systems -- and so on, with mutually-exclusive patches deactivating one another as they're selected. to present the user with a single I2C/SPI patch option is just silly. What's the limit on patches? again, based on my reading, it seems clear that you can apply only a limited number of patches, as each patch appears to require a certain number of traps in micropatch.c for example, if you want to apply the SMC patch, there's this excerpt in micropatch.c: /* Enable the traps to get to it. */ commproc-cp_cpmcr1 = 0x8080; commproc-cp_cpmcr2 = 0x808a; commproc-cp_cpmcr3 = 0x8028; commproc-cp_cpmcr4 = 0x802a; similarly, if you want the IIC patch: /* Enable the traps to get to it. */ commproc-cp_cpmcr1 = 0x802a; commproc-cp_cpmcr2 = 0x8028; commproc-cp_cpmcr3 = 0x802e; commproc-cp_cpmcr4 = 0x802c; which suggests that not only are the SMC and IIC patches mutually exclusive, once you pick either one, you're finished in terms of applying other patches. is that accurate? (interestingly, there's nothing in micropatch.c that forces those two patches to be mutually exclusive. since IIC occurs further down in the file, it would apparently override the earlier SMC patch. not good.) and what about the USB patch? at first glance, it doesn't appear to require any traps, but it does set commproc-cp_rccr, so does that make it mutually exclusive with IIC and SMC patches? in short, it would be useful to know: * what's the definition of a patch? * what are the list of possible patches? * what are the resources required for a patch to be applied, and what are the consequences for patch co-existence? The I2C/SPI patch - perhaps showing my unbounded ignorance but, given that the parameter RAM memory map table shows different addresses for I2C and SPI, respectively, is it feasible to relocate one and not the other? why does all the literature i read insist on referring to the *combined* I2C/SPI patch? just curious. would there be any value in relocating just one and, if you could, would that cost only two traps, leaving open the possibility of another patch? The USB SOF patch - apparently, the onboard USB on the 850 is somewhat flaky, which is why the USB SOF patch isn't even selectable in micropatch.c, is that it? note the excerpt from micropatch.c #ifdef CONFIG_USB_MPC8xx #define USE_USB_SOF_PATCH #endif a recursive grep shows that there's nothing in the entire kernel source tree that even defines CONFIG_USB_MPC8xx, so that patch is pretty well a non-issue. (side note: apparently, up to rev. b of the processor had this problem. we are using rev. c which allegedly has fixed the problem, but rev. c is not
can the 8xx patch configuration be made more comprehensible?
i imagine it's just me, but i find the configuration process of
selecting possible patches for 8xx a bit confusing under the 2.6
kernel.
under MPC8xx CPM Options, there's a single option for patches:
[ ] I2C/SPI Microcode Patch
seems simple enough, although the help screen muddies the waters
somewhat:
CONFIG_UCODE_PATCH:
Motorola releases microcode updates for their 8xx CPM modules. The
microcode update file has updates for IIC, SMC and USB. Currently
only the USB update is available by default, if the MPC8xx USB option
is enabled. If in doubt, say 'N' here.
so, suddenly, a patch labelled as for I2C and SPI is described as
also affecting SMC and USB (but only if you selected USB in the first
place. and where went SPI?)
and if you look inside micropatch.c, you notice that the only way to
get the SMC patch (whatever that does) is not to have selected it at
config time, but to manually edit this file and define USE_SMC_PATCH
(which requires you to apparently edit the uart driver as well).
does it really have to be this painful? a number of simple
questions:
* how many patches are there?
* which ones can be selected independently from the others? and can
they be made separate selections in the config menu? (does it even
make sense to select only some of the possible patches?)
* and can they be documented so the builder knows what the purpose of
the patch is?
* and can the SMC patch be moved out of the source file and made a
config-time selection along with the others (might be difficult
given the necessity of editing the uart driver file).
anyway, you get the idea.
rday
p.s. i notice in micropatch.c the preprocessor test:
#ifdef USE_IIC_PATCH
#define PATCH_DEFINED
/* IIC/SPI */
uint patch_2000[] = {
0x7FFFEFD9,
...
i have no idea where the macro USE_IIC_PATCH is defined, if anywhere.
and, trust me, i've looked. is this dead code?
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
can the 8xx patch configuration be made more comprehensible?
On Wed, 21 Jul 2004, Wolfgang Denk wrote: There are least 3 that are relevant here: - MPC850 microcode patch for relocating I2C/SPI parameters. - MPC860 microcode patch for relocating I2C/SPI parameters i can see that, in the 2.6 arch/ppc/8xx_io/micropatch.c file, there is a test for the macro USE_IIC_PATCH. now, back in wolfgang's 2.4.25 source tree, that macro is defined in include/asm-ppc/commproc.h thusly: #ifdef CONFIG_UCODE_PATCH # define USE_IIC_PATCH #else # undef USE_IIC_PATCH #endif however, in the 2.6 tree, i see nowhere that that macro could possibly be set, so it seems that any tests for USE_IIC_PATCH in the 2.6 tree are irrelevant, no? rday ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
list of 2.6-related migration issues for embedded programmers?
On Tue, 20 Jul 2004, Linh Dang wrote: On 20 Jul 2004, wd at denx.de wrote: In message wn5zn5v8nl8.fsf at linhd-2.ca.nortel.com you wrote: - I failed to see what in initramfs mechanism would prevent one from having separated images which can be updated independently of each other. initramfs gets linked with the kernel into one image, similar to But you don't have to. What ever you can do with the good-old initrd image you can do with the new initramfs (really cpio archive) image. The main difference is the creation: genext2fs vs cpio. I just happen to use zImage.initrd (where ramdisk.image.gz is a cpio archive) in our project because it's the most appropriate for our situation. i have to agree with wolfgang here -- how would you create and use an initramfs image separately from the kernel image? the only possibility i can see based on my perusal is to incorporate the initramfs into the zImage.initrd. rday ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
list of outstanding issues somewhere?
is there, somewhere, a list of known issues/bugs/upcoming fixes for the PPC-oriented kernel source? on a number of occasions, i've had the bad timing to ask about something that was, in fact, in the process of being patched or that someone was just about to start working on, or that at least someone already knew about. it would be great if there was a list of outstanding issues one could check to see that a problem they're having is already on someone's radar screen -- not necessarily even being actively worked on, just acknowledged that that issue exists. a TO DO list? just curious. rday ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
list of 2.6-related migration issues for embedded programmers?
on the topic of lists of things, is there a list somewhere of the potentially important 2.6-related issues someone should at least understand before migrating from 2.4 to 2.6? i don't mean just improvements in the kernel from 2.4 to 2.6; i mean significantly new features that would require a rethinking and possible redesign of the build process. as examples off the top of my head: - replace devfs with udev: currently, even with my current 8xx 2.6 build, i'm sticking with devfs until i'm confident i understand enough to move up. - initramfs: currently, i'm still using a zImage.initrd-based image, and all i know about initramfs is that it's checked for at boot time. should i care about it? at some point, probably, i'm sure. - redesign of modules and device drivers to be 2.6-compatible, that's a biggie. and the fact that the CVS busybox tree just recently had 2.6 support added to its modules-related commands. - totally redesigned kernel config menus at the moment, i'm going through the 5-part series on migrating to 2.6 starting at http://linuxdevices.com/articles/AT3855888078.html. some of it's useful, some of it's kind of fluffy. but it would be nice to have a list of that type aimed primarily at embedded developers. rday ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
list of outstanding issues somewhere?
On Mon, 19 Jul 2004, Gary Thomas wrote: On Mon, 2004-07-19 at 05:44, Wolfgang Denk wrote: Maybe we could even have a (searchable) patch database so that submissions, even if rejected, don't get lost completely. BugZilla works great for this. i'm not sure it needs to be that detailed or precise; i was just thinking of a more general summary of things we're working on or that have to be dealt with at some point. whatever works. rday ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
list of 2.6-related migration issues for embedded programmers?
On Mon, 19 Jul 2004, Linh Dang wrote: On 19 Jul 2004, rpjday at mindspring.com wrote: - initramfs: currently, i'm still using a zImage.initrd-based image, and all i know about initramfs is that it's checked for at boot time. should i care about it? at some point, probably, i'm sure. initramfs is convenient. you don't need root access nor special tools to create the root-fs. it very easy when you want to version-controlled you root-fs. ah, that would be convenient since, as it is, i'm using a hacked version of genext2fs that allows me to create the initial root fs as a regular user. i *definitely* have to look into initramfs, then. rday ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
list of 2.6-related migration issues for embedded programmers?
On Mon, 19 Jul 2004, Linh Dang wrote: Don't use the .initramfs section option (the one that's linked with with vmlinux.) Build your ramdisk.image.gz as a compressed cpio archive. I.e. zvmlinux.initrd's .ramdisk section contains a compressed cpio archive instead of an compressed ext2 image. that's all it takes? that sounds just too easy. rday ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
list of 2.6-related migration issues for embedded programmers?
On Mon, 19 Jul 2004, Linh Dang wrote: Don't use the .initramfs section option (the one that's linked with with vmlinux.) Build your ramdisk.image.gz as a compressed cpio archive. I.e. zvmlinux.initrd's .ramdisk section contains a compressed cpio archive instead of an compressed ext2 image. so, just to clarify, i'm looking at arch/ppc/boot/simple/Makefile, the excerpt: $(obj)/zvmlinux.initrd: $(OBJS) $(LIBS) $(srctree)/$(boot)/ld.script \ $(images)/vmlinux.gz $(obj)/dummy.o $(OBJCOPY) $(OBJCOPY_ARGS) \ -- --add-section=.ramdisk=$(images)/ramdisk.image.gz \ --set-section-flags=.ramdisk=contents,alloc,load,readonly,data \ and all i need to change is ramdisk.image.gz to, say, my newc format gzipped cpio archive, initramfs.cpio.gz, and the early kernel code should recognize it as such automatically? i'll give that a shot later. rday ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
list of 2.6-related migration issues for embedded programmers?
On Mon, 19 Jul 2004, Wolfgang Denk wrote: In message Pine.LNX.4.60.0407191350320.23725 at dell.enoriver.com you wrote: initramfs is convenient. you don't need root access nor special tools to create the root-fs. it very easy when you want to version-controlled you root-fs. ah, that would be convenient since, as it is, i'm using a hacked version of genext2fs that allows me to create the initial root fs as a regular user. i *definitely* have to look into initramfs, then. What do you mean with hacked? Standard genext2fs will do this just fine. sadly for me, the version floating around doesn't build FIFOs (even though the command-line options suggest it does). and i need FIFOs to support minit. so i merged a couple different versions to get one that handles the extended device file format (erik andersen's??), and a small patch to handle FIFOs. And as usual, there is two sides to initramfs. It may be convenient for some cases, where you can use the very same root filesystem image bundled with the kernel image, but exactly thsi convenience may hurt you in other cases where it's much better when you have separated images which can be updated independently of each other. Speaking for myself: I don't see advantages in it. None. i most likely wouldn't use it for the final build, but it would still be more efficient for testing, rather than reflashing the root filesystem on the unit every time. once the image is finalized, then i can flash the kernel and rootFS separately. rday p.s. of course, this assumes GNU cpio can handle FIFOs. oops, better check that. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
list of 2.6-related migration issues for embedded programmers?
On Tue, 20 Jul 2004, Wolfgang Denk wrote: In message Pine.LNX.4.60.0407191731390.24783 at dell.enoriver.com you wrote: sadly for me, the version floating around doesn't build FIFOs (even though the command-line options suggest it does). and i need FIFOs to support minit. so i merged a couple different versions to get one that handles the extended device file format (erik andersen's??), and a small patch to handle FIFOs. I thought Erik Anderse's version _is_ the standard version these days ;-) it is, except as i mentioned, it doesn't support FIFOs, although it does handle the extended device file format that i needed. i got another version that didn't support the extended file format, but handled FIFOs. quick merge, and i had what i wanted. And I thought you were using the ELDK? i am. not sure what that has to do with genext2fs. what's a big deal for me is to make sure the entire build and test process can be done without any access to the root account on the development system. i most likely wouldn't use it for the final build, but it would still be more efficient for testing, rather than reflashing the root filesystem on the unit every time. once the image is finalized, then i can flash the kernel and rootFS separately. I can't follow. Why would you flash the root filesystem if you're still testing it? Just TFTP the test image and use it from RAM (the kernel may be stored in flash if you like). but the whole idea is that using genext2fs required me to make a couple small changes to allow non-root users to do the entire process. IIRC, the ability to mount and umount. initramfs looks like an easier way to just let regular users do all this. and when we have the final image, then burn *that* to flash. sorry, i didn't mean to drag this out so much. i just see initramfs as a cheap and easy way to let non-root users build and test. and if i can reduce my dependency on tools additional (i.e., genext2fs), so much the better. rday ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
fix to enet.c to enable networking when booting from flash
with our current 2.4.22-pre8 kernel, we found that, on our 850DE board (ethernet on SCC3), ethernet would work fine when we downloaded the bootable image, but not if we booted from the image that was burned into flash. eventually, one of the guys here tracked the problem to arch/ppc/8xx_io/enet.c, and made the following change (around line 915 in enet.c in both this version of the kernel and in the latest bk pull of linuxppc-2.5): #if defined(CONFIG_RPXLITE) || defined(CONFIG_RPXCLASSIC) || defined(CONFIG_EP8xx) || defined(CONFIG_EP852) /* And while we are here, set the configuration to enable ethernet. */ *((volatile uint *)RPX_CSR_ADDR) = ~BCSR0_ETHLPBK; *((volatile uint *)RPX_CSR_ADDR) |= (BCSR0_ETHEN | BCSR0_COLTESTDIS | BCSR0_FULLDPLXDIS); *((volatile uint *)RPX_CSR_ADDR) |=0x0010; -- add this //1:ethernet,0:SPI #endif i don't know enough about the hardware to know what this is for. if anyone does, is it still an issue? is there a better way to handle this? as much as possible, i'm trying to get everything running on this board without messing with the kernel source. thanks. given that the author of that line is not around at the moment, i'm just going to poke around the source and see if i can deduce what it's for. rday ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/ ** This list is shutting down 7/24/2004.
apparent config error, SMC1/SCC3 conflict in uart.c
following up on my earlier posts regarding trying to simultaneously use SMC1 as console and SCC3 as ethernet, it appears that the source file arch/ppc/8xx_io/uart.c has a condition error. similar to a check that was used in the 2.4 kernel, we have: = ... # ifndef CONFIG_SERIAL_CONSOLE_PORT # ifdef CONFIG_SCC3_ENET # ifdef CONFIG_CONS_SMC2 #define CONFIG_SERIAL_CONSOLE_PORT 0 /* Console on SMC2 is 1st port */ # else #error Can't use SMC1 for console with Ethernet on SCC3 # endif # else /* ! CONFIG_SCC3_ENET */ # ifdef CONFIG_CONS_SMC2 /* Console on SMC2 */ #define CONFIG_SERIAL_CONSOLE_PORT 1 # else/* Console on SMC1 */ #define CONFIG_SERIAL_CONSOLE_PORT 0 # endif /* CONFIG_CONS_SMC2 */ # endif /* CONFIG_SCC3_ENET */ # endif /* CONFIG_SERIAL_CONSOLE_PORT */ #endif/* CONFIG_SERIAL_CONSOLE */ ... = which would normally prevent both SMC1 and SCC3 being selected simultaneously (without the necessary patch, that is). but based on changes in Kconfig options, it appears that i can select both of those and not be notified of an error (my system will just hang at boot time). some of my config options: CONFIG_SERIAL_CONSOLE=y ... CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y CONFIG_SERIAL_CPM=y CONFIG_SERIAL_CPM_CONSOLE=y # CONFIG_SERIAL_CPM_SCC1 is not set # CONFIG_SERIAL_CPM_SCC2 is not set # CONFIG_SERIAL_CPM_SCC3 is not set # CONFIG_SERIAL_CPM_SCC4 is not set CONFIG_SERIAL_CPM_SMC1=y -- pick SMC1 # CONFIG_SERIAL_CPM_SMC2 is not set ... CONFIG_SCC_ENET=y # CONFIG_SCC1_ENET is not set # CONFIG_SCC2_ENET is not set CONFIG_SCC3_ENET=y -- pick SCC3 # CONFIG_FEC_ENET is not set # CONFIG_ENET_BIG_BUFFERS is not set # CONFIG_8xx_UART is not set based on the above, it sure *looks* like i'm selecting SMC1 and SCC3 at the same time, and i recall a previous poster suggesting that CONFIG_8xx_UART is a holdover from 2.4 that will disappear so i left it unselected. with this set of options, the build succeeds, but the system hangs at boot time. however, if i select ethernet on SCC2 (it will obviously not work, then), at least the system boots and i have a system console. thoughts? i suspect that set of ifdefs needs to be updated -- there isn't even a CONFIG_SERIAL_CONSOLE_PORT option anymore, among other things. or CONFIG_CONS_SMC2. and probably others. rday ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/ ** This list is shutting down 7/24/2004.
fix to enet.c to enable networking when booting from flash
On Tue, 13 Jul 2004, Dan Malek wrote: On Jul 13, 2004, at 1:34 PM, Robert P. J. Day wrote: #if defined(CONFIG_RPXLITE) || defined(CONFIG_RPXCLASSIC) || defined(CONFIG_EP8xx) || defined(CONFIG_EP852) /* And while we are here, set the configuration to enable ethernet. */ *((volatile uint *)RPX_CSR_ADDR) = ~BCSR0_ETHLPBK; *((volatile uint *)RPX_CSR_ADDR) |= (BCSR0_ETHEN | BCSR0_COLTESTDIS | BCSR0_FULLDPLXDIS); *((volatile uint *)RPX_CSR_ADDR) |=0x0010; -- add this //1:ethernet,0:SPI #endif In newer drivers, this would be done in a board specific file. As you can tell, this code enables the Ethernet PHY. I don't understand why that extra 'add this' is necessary. That does some PCMCIA signal routing to IP_B5, which should not have any effect on the Ethernet. What revision of board is this? I have RPXLite's that I boot from flash all of the time without trouble. i *just* *now* talked to the author. it's board-specific, has to do with a register in the CPLD on our board, that's the reader's digest condensed version. this is a custom board, so i definitely don't expect it to behave like a regular rpxlite. so ignore all this, unless this explanation makes no sense at all. :-) rday ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/ ** This list is shutting down 7/24/2004.
short followup on apparently obsolete config variables
from what i can tell, the config process under 2.6 doesn't recognize the option variables (among others): CONFIG_SERIAL_CONSOLE_PORT CONFIG_CONS_SMC2 yet those variables are explicitly mentioned in kernel source files as follows: CONFIG_SERIAL_CONSOLE_PORT: arch/ppc/8xx_io/uart.c drivers/serial/68360serial.c CONFIG_CONS_SMC2: arch/ppc/8xx_io/uart.c arch/ppc/configs/TQM823L_defconfig arch/ppc/configs/TQM860L_defconfig arch/ppc/configs/mbx_defconfig arch/ppc/configs/SM850_defconfig arch/ppc/configs/SPD823TS_defconfig arch/ppc/configs/SCCS/s.FADS_defconfig arch/ppc/configs/rpxcllf_defconfig arch/ppc/configs/bseip_defconfig arch/ppc/configs/TQM850L_defconfig arch/ppc/configs/FADS_defconfig i'd try to submit some patches but, trust me, you probably don't want me messing with the code. rday ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/ ** This list is shutting down 7/24/2004.
what is the status of devfs?
On Fri, 9 Jul 2004, Mark Chambers wrote: probably should send this to the main kernel list, but in playing around, i noticed that DEVFS_FS is labelled as both OBSOLETE and NEW, but in the Kconfig file, it depends on EXPERIMENTAL. it seems a bit inconsistent for anything to be simultaneously EXPERIMENTAL, NEW and OBSOLETE, no? I found the following in udev-FAQ: Q: Why was devfs marked OBSOLETE if udev is not finished yet? A: To quote Al Viro (Linux VFS kernel maintainer): - it was determined that the same thing could be done in userspace - devfs had been shoved into the tree in hope that its quality will catch up - devfs was found to have fixable and unfixable bugs - the former had stayed around for many months with maintainer claiming that everything works fine - the latter had stayed, period. - the devfs maintainer/author disappeared and stoped maintaining the code. oh, i knew devfs was on its way out, i was just curious about it being labelled as EXPERIMENTAL, NEW and OBSOLETE all at the same time. what's the story on proposed udev support some day? rday ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
error: lsmod: QM_MODULES: Function not implemented
(i've asked about this on the busybox list as well, so profuse apologies to those who see it twice.) Scenario: 850DE-based board ELDK 3.0 latest bk pull of linuxppc-2.5 today's snapshot of BB (20040709) # lsmod lsmod: QM_MODULES: Function not implemented i've configured BB explicitly to support 2.6 modules, and the kernel also has module support. historically, when one got this error, the response was, hey, you have to upgrade to rusty's latest 'module-init-tools' package, that'll fix it. but that's clearly not an option when using BB. someone on the BB list posted a reference to a patch that seemed to only fix modprobe, which doesn't help here. note that i'm not trying to actually load a module (i don't even *have* any 2.6-compatible modules to play with yet), but it would be nice to just get lsmod to work and tell me i have no modules loaded yet. thoughts? i'm currently following the logic flow through BB's libbb/module_syscalls.c code. rday ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
what's the value of CONFIG_8xx_UART?
On Fri, 9 Jul 2004, Tom Rini wrote: On Thu, Jul 08, 2004 at 06:04:31PM -0400, Robert P. J. Day wrote: under MPC8xx CPM Options, what's the purpose of selecting [ ] Use UART (representing option CONFIG_8xx_UART) This is the older serial driver. This can probably go away soon (Kumar and Panto have fixed the issues wrt needing SMC1 and SCC1, should be in kernel.org soon). cool. so now i can go find something else to complain about. :-) rday p.s. when you say should be in kernel.org soon, what's the flow of fixes between that and the linuxppc-2.5 tree at bkbits? ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
should 860T FEC Ethernet be an option for 8xx?
under MPC8xx CPM Options, we have: [ ] 860T FEC Ethernet whose help reads: Enable Ethernet support via the Fast Ethernet Controller (FCC) on the Motorola MPC8260. but if it's specific to the 8260, it shouldn't even be available in the menu for 8xx, no? either that, or the help is wrong. rday ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
what is the status of devfs?
probably should send this to the main kernel list, but in playing around, i noticed that DEVFS_FS is labelled as both OBSOLETE and NEW, but in the Kconfig file, it depends on EXPERIMENTAL. it seems a bit inconsistent for anything to be simultaneously EXPERIMENTAL, NEW and OBSOLETE, no? rday ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
confusion re: CPM2 and 8xxx
there's some confusion (well, ok, just me) regarding kernel config settings in the linuxppc-2.5 tree. when i select a processor type, i see that i have a number of choices, including ... 8xx ... 6xx/7xx/74xx/8260 ... so far, so good. so i select 8xx and, later, under Device drivers Character devices Serial drivers ... * CPM2 SCC/SMC serial port support [*] Support for console on CPM2 SCC/SMC serial port according to the help on that first option: This driver supports the SCC and SMC serial ports on Motorola embedded PowerPC that contain a CPM2 (8xxx) or a CPM1 (8xx) given that i explicitly selected 8xx, i don't think i should be presented with any options related to an 8xxx platform (that is, anything saying CPM2). yes, it's picky, but the first time i did this, i sat there thinking, i know CPM, but what the heck is this CPM2 thing, and what does it have to do with an 8xx platform? thoughts? rday p.s. it's also a bit misleading since there are no options whatever in .config that contain the string CPM2, in case you go grepping for them. p.p.s. more pedantry to follow. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
having to configure SCC1 for serial port just to boot??
on to the next issue. 850DE-based board with SMC1:console SCC2: DSP SCC3: ethernet (yes, we're going to have to install a patch to have SMC1 and SCC3 simultaneously, but that's the subject for a later post.) for now, just to get the system to boot to the command line, i set the following: Device drivers Character devices Serial drivers * CPM2 SCC/SMC serial port support [*] Support for console on CPM2 SCC/SMC serial port [ ] Support for SCC1 serial port [ ] Support for SCC2 serial port [ ] Support for SCC3 serial port [ ] Support for SCC4 serial port [*] Support for SMC1 serial port -- my console ? [ ] Support for SMC2 serial port and MPC8xx CPM Options [*] CPM SCC Ethernet SCC used for Ethernet (SCC2) --- [ ] 860T FEC Ethernet [ ] Use Big CPM Ethernet Buffers [ ] Use UART -- not sure about this ... ... note the deliberately erroneous choice of SCC2 for ethernet, just to avoid the conflict between SMC1 and SCC3 for now. just means i won't really have networking. compile, load, boot: === Linux/PPC load: rw root=/dev/ram0 (do i need console= ??) Uncompressing Linux...done. Now booting the kernel Linux version 2.6.7 (rpjday at localhost.localdomain) (gcc version 3.2.2 20030217 4On node 0 totalpages: 8192 DMA zone: 8192 pages, LIFO batch:2 Normal zone: 0 pages, LIFO batch:1 HighMem zone: 0 pages, LIFO batch:1 Built 1 zonelists Kernel command line: rw root=/dev/ram0 PID hash table entries: 256 (order 8: 2048 bytes) Decrementer Frequency = 18750/60 Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 28592k available (1416k kernel code, 364k data, 72k init, 0k highmem) Calibrating delay loop... 47.23 BogoMIPS Mount-cache hash table entries: 512 (order: 0, 4096 bytes) checking if image is initramfs...it isn't (no cpio magic); looks like an initrd Freeing initrd memory: 1913k freed NET: Registered protocol family 16 devfs: 2004-01-31 Richard Gooch (rgooch at atnf.csiro.au) devfs: boot_options: 0x1 Initializing Cryptographic API Generic RTC Driver v1.07 Serial: CPM driver $Revision: 0.01 $ ttyCPM0 at MMIO 0xfa200a80 (irq = 20) is a CPM UART RAMDISK driver initialized: 16 RAM disks of 6144K size 1024 blocksize loop: loaded (max 8 devices) eth0: CPM ENET Version 0.2 on SCC2, 00:10:ec:00:00:00 NET: Registered protocol family 2 IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 2048 bind 4096) NET: Registered protocol family 1 NET: Registered protocol family 17 RAMDISK: Compressed image found at block 0 VFS: Mounted root (ext2 filesystem). Mounted devfs on /dev Freeing unused kernel memory: 72k init ... and hang ... = now, just for fun and no reason whatever, add support for an SCC1 serial port: * CPM2 SCC/SMC serial port support [*] Support for console on CPM2 SCC/SMC serial port [*] Support for SCC1 serial port--- add this option NOTE: AFAIK, this board doesn't even *have* SCC1, so this is apparently a meaningless change. and yet, the result: === Linux/PPC load: rw root=/dev/ram0 Uncompressing Linux...done. Now booting the kernel Linux version 2.6.7 (rpjday at localhost.localdomain) (gcc version 3.2.2 20030217 4On node 0 totalpages: 8192 DMA zone: 8192 pages, LIFO batch:2 Normal zone: 0 pages, LIFO batch:1 HighMem zone: 0 pages, LIFO batch:1 Built 1 zonelists Kernel command line: rw root=/dev/ram0 PID hash table entries: 256 (order 8: 2048 bytes) Decrementer Frequency = 18750/60 Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 28592k available (1416k kernel code, 364k data, 72k init, 0k highmem) Calibrating delay loop... 47.23 BogoMIPS Mount-cache hash table entries: 512 (order: 0, 4096 bytes) checking if image is initramfs...it isn't (no cpio magic); looks like an initrd Freeing initrd memory: 1913k freed NET: Registered protocol family 16 devfs: 2004-01-31 Richard Gooch (rgooch at atnf.csiro.au) devfs: boot_options: 0x1 Initializing Cryptographic API Generic RTC Driver v1.07 Serial: CPM driver $Revision: 0.01 $ ttyCPM0 at MMIO 0xfa200a80 (irq = 20) is a CPM UART ttyCPM1 at MMIO 0xfa200a00 (irq = 46) is a CPM UART RAMDISK driver initialized: 16 RAM disks of 6144K size 1024 blocksize loop: loaded (max 8 devices) eth0: CPM ENET Version 0.2 on SCC2, 00:10:ec:00:00:00 NET: Registered protocol family 2 IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 2048 bind 4096) NET: Registered protocol family 1 NET: Registered protocol family 17 RAMDISK: Compressed image found at block 0 VFS: Mounted root (ext2 filesystem).
what's the value of CONFIG_8xx_UART?
under MPC8xx CPM Options, what's the purpose of selecting [ ] Use UART (representing option CONFIG_8xx_UART) i mean, i already have SMC1 serial port support, and a working console, and SMC1 is on a UART. so what else would this give me? there is no help for this option. if i select it, i get the chance of now selecting SMC2 for UART, which kind of implies that SMC1 is the default anyway, which is already working, etc, etc. thoughts? this is going to lead in to yet another question regarding SMC1/SCC3 co-existence. but now, time for supper. rday ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
SMC1, ethernet on SCC3 and patches to allow this
final issue i have here involving our 850DE board, related to console on SMC1 co-existing with ethernet on SCC3. the default parameter RAM layout for this processor is, according to the user's manual: ... 0x1e00-0x1e7f SCC3 0x1e80-0x1ebf SMC1 no problem, unless you want ethernet on SCC3, which won't fit in that window and runs over into the space for SMC1, clobbering it. in the 2.4 kernel we have, this is solved by (apparently) relocating SMC1 by adding a micropatch.c file to the kernel in the directory arch/ppc/8xx_io/. the relevant part of the Config.in file in that 2.4 source tree: if [ $CONFIG_SCC3_ENET != y -o $CONFIG_SMCUCODE_PATCH = y ]; then bool 'Use SMC1 for UART' CONFIG_8xx_SMC1 fi in short, you can't use SMC1 for UART unless you *don't* put ethernet on SCC3, or you've installed the patch to relocate SMC1. easy enough. so how is this handled in the 2.6 kernel, which should have the same problem? first, arch/ppc/8xx_io/uart.c clearly recognizes the conflict with the code: # ifndef CONFIG_SERIAL_CONSOLE_PORT # ifdef CONFIG_SCC3_ENET # ifdef CONFIG_CONS_SMC2 #define CONFIG_SERIAL_CONSOLE_PORT 0 /* Console on SMC2 is 1st port */ # else #error Can't use SMC1 for console with Ethernet on SCC3 -- aha! # endif # else /* ! CONFIG_SCC3_ENET */ # ifdef CONFIG_CONS_SMC2 /* Console on SMC2 */ #define CONFIG_SERIAL_CONSOLE_PORT 1 # else/* Console on SMC1 */ #define CONFIG_SERIAL_CONSOLE_PORT 0 # endif /* CONFIG_CONS_SMC2 */ # endif /* CONFIG_SCC3_ENET */ # endif /* CONFIG_SERIAL_CONSOLE_PORT */ #endif/* CONFIG_SERIAL_CONSOLE */ but there's no reference to a patch that lets me get away with this. surely others might want to have console SMC1 and ethernet SCC3. how is it done? (i mean, short of configuring the console on SMC2, which is not an option here.) rday ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
make menuconfig error in latest bk pull
i'm probably way behind the curve here, but: $ make ARCH=ppc menuconfig scripts/kconfig/mconf arch/ppc/Kconfig drivers/net/Kconfig:201: can't open file drivers/net/ibm_ocp/Kconfig make[1]: *** [menuconfig] Error 1 make: *** [menuconfig] Error 2 $ rday ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
compile error, USB gadgets
not sure if i should report this here or to the kernel list proper, but after selecting support for USB gadgets, ethernet (RPXlite configuration, just goofing around): CC drivers/usb/gadget/ether.o drivers/usb/gadget/ether.c: In function `eth_bind': drivers/usb/gadget/ether.c:2380: `fs_status_desc' undeclared (first use in this function) drivers/usb/gadget/ether.c:2380: (Each undeclared identifier is reported only once drivers/usb/gadget/ether.c:2380: for each function it appears in.) make[3]: *** [drivers/usb/gadget/ether.o] Error 1 make[2]: *** [drivers/usb/gadget] Error 2 make[1]: *** [drivers] Error 2 where *is* the right place to note this stuff? rday ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
getting support for command-line flash partitioning
looking a bit more into command-line flash partitioning, i noticed the following, and i just want to make sure i understand the current state of this feature. first, there's a fair amount of support for CONFIG_MTD_CMDLINE_PARTS in the current denx (2.4.25) ppc kernel; that is, in the source files under drivers/mtd/maps. (not yet in rpxlite.c, where i want it, but it certainly seems straightforward to add it, i'll try that shortly.) however, in the current 2.6 kernel bk pull from ppc.bkbits.net, none of those maps files support that feature yet. the kernel itself clearly lets you select that feature, but none of the drivers yet take advantage of it, if i read it correctly. so how is this being added to the files? as in, who will add this feature to the individual files, and get it pushed upstream, if that's what's going to happen? just curious as to how this feature will eventually end up in the mainstream. rday ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
getting support for command-line flash partitioning
On Thu, 1 Jul 2004, David Woodhouse wrote:
On Thu, 2004-07-01 at 10:45 -0400, Robert P. J. Day wrote:
so how is this being added to the files? as in, who will add this
feature to the individual files, and get it pushed upstream, if that's
what's going to happen? just curious as to how this feature will
eventually end up in the mainstream.
The owner of each board support ('map') file is expected to make sure
that it's kept up to date in my CVS tree. Periodically I push updates to
Linus, although individuals are welcome to send their own changes to
Linus as soon as they're committed to CVS too.
ok, i was just trying to figure out how the different versions of the
kernel i have have such differing levels of that CMDLINE support.
the original kernel tree i have from embedded planet (approx. 2.4.22)
has a small number of map files that make any reference to that
feature. the CVS tree from denx (2.4.25) has considerably more. and
neither the latest bk pull of the 2.5/2.6 kernel from bkbits.net, or
the standard 2.6 kernel on my fedora core system has *any* support for
that feature in the map files (even though the kernel has the internal
support).
i was just trying to figure out the logical flow of how that feature
worked its way in. thanks.
rday
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
getting support for command-line flash partitioning
On Thu, 1 Jul 2004, Sylvain Munaut wrote:
Robert P. J. Day wrote:
| and neither the latest bk pull of the 2.5/2.6 kernel from
| bkbits.net, or the standard 2.6 kernel on my fedora core system has
| *any* support for that feature in the map files (even though the
| kernel has the internal support).
|
Are you sure about that ?
tnt at 246tNt-laptop maps $ grep cmdline *
ceiva.c:static const char *probes[] = { cmdlinepart, RedBoot, NULL };
dc21285.c:static const char *probes[] = { RedBoot, cmdlinepart,NULL };
edb7312.c:static const char *probes[] = { RedBoot, cmdlinepart,NULL };
h720x-flash.c:static const char *probes[] = { cmdlinepart, NULL };
impa7.c:static const char *probes[] = { cmdlinepart, NULL };
integrator-flash.c:static const char *probes[] = { cmdlinepart,RedBoot,
afs, NULL };
iq80310.c:static const char *probes[] = { RedBoot, cmdlinepart,NULL };
ixp4xx.c:static const char *probes[] = { RedBoot, cmdlinepart, NULL };
lubbock-flash.c:static const char *probes[] = { RedBoot,cmdlinepart, NULL
};
physmap.c:const char *part_probes[] = {cmdlinepart, RedBoot, NULL};
sa1100-flash.c:const char *part_probes[] = { cmdlinepart, RedBoot,NULL };
solutionengine.c:static const char *probes[] = { RedBoot,cmdlinepart,
NULL };
wr_sbc82xx_flash.c:static const char *part_probes[] __initdata
={cmdlinepart, RedBoot, NULL};
oops, i was working off the structure of the older kernel version
where the individual files explicitly checked the value of the config
variable CONFIG_MTD_CMDLINE_PARTS to decide what to do, and that's the
string i was grep'ing for. this clearly changed in the newer files.
mea culpa.
rday
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
duplicate menu entry in 2.5 source tree?
does anyone else see a duplicate menu entry in the current 2.5 bk pull, under Serial drivers (selecting RPXLite for me): 8250/16550 and compatible serial support --- Non-8250 serial port support CPM2 SCC/SMC serial port support CPM2 SCC/SMC serial port support if you select either one, then both submenus pop up. the Kconfig file (drivers/serial/Kconfig) has the menu definition: config SERIAL_CPM tristate CPM2 SCC/SMC serial port support depends on CPM2 || 8xx select SERIAL_CORE help This driver supports the SCC and SMC serial ports on Motorola embedded PowerPC that contain a CPM2 (8xxx) or a CPM1 (8xx) i haven't looked more closely than that, just thought i'd mention it. rday ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
looking for .config file for RPXlite board for 2.6 kernel
On Wed, 30 Jun 2004, Tom Rini wrote: On Wed, Jun 30, 2004 at 11:12:18AM -0400, Robert P. J. Day wrote: ok, in the interests of my mental health, i've grabbed an rpxlite board off the shelf, and am going to see how far i can boot it with the current 2.6 kernel. 'make rpxlite_defconfig' and then enable SERIAL_CPM and select SMC1 and SCC1 (you are correct, AFAIK, about the right console being SMC1, but this is the board I've been using and mentioning that it doesn't quite get right). WRT having to pass in console=, etc, iff you have CONFIG_VT=n, which I believe is in the defconfig, you don't need to pass anything. i did eventually find the defconfig files for PPC, and grabbed the rpxlite one and have been playing with it for a while. every combination i've tried so far has given me only: = Linux/PPC load: ... various load lines, trying console mostly ... Uncompressing Linux...done. Now booting the kernel = and that's it. i assumed that my fundamental problem was just not getting the system console configured properly. i've confirmed through the bootloader that, yes, SMC1 is my monitor serial port. so, based on what you've suggested, i've gone into (somewhere i've already been many times :-): Device Drivers Character devices Serial drivers and i've selected: [*] CPM2 SCC/SMC serial port support [ ] Support for console on CPM2 SCC/SMC serial port (NEW) [*] Support for SCC1 serial port [ ] Support for SCC2 serial port (NEW) [ ] Support for SCC3 serial port (NEW) [ ] Support for SCC4 serial port (NEW) [*] Support for SMC1 serial port [ ] Support for SMC2 serial port (NEW) and left everything else alone, and it's building now. if this still hangs after Now booting the kernel, maybe you can just send me a copy of your .config file to diff. i can't believe this isn't something really trivial i'm screwing up. rday ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
