Re: RTC woes
Marc LeFevre schrieb: I’m new to the list. Welcome! :-) I have an e500-based embedded Linux system running a 2.6.22 kernel. I have a PCF8563T i2c based RTC chip attached to the PPC i2c bus. In my kernel config file I have selected CONFIG_RTC_INTF_DEV=y and CONFIG_RTC_DRV_PCF8563=y. I do a mknod for /dev/rtc as c 10 135 (standard Linux) and link /dev/rtc0 to it. When I boot, get the following message: drivers/rtc/hctosys.c: unable to open rtc device (rtc0) 2.6.22.x and 2.6.23.x i2c rtc code was quite messy around PCF8563. 3) Does the PPC have some quirks regarding i2c operation that are at the root of this problem? The RTC subsystem was improved quite a bit lately. Try 2.6.24' powerpc architecture with a proper device tree instead. It works over here on mpc8540 / mpc8548 whereas the older ones were just a waste of time. Regards, Clemens ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: reg Philips ISP 1562 usb controller support in linux2.6.23.11
Hi, Magendra! - please don't top-post! - and please keep the list on CC: mahendra varman schrieb: Sir, I have enabled the necessary configs for ISP1562 The IRQ number is 39 and while probing the driver correctly assigns the IRQ number but if i insert a device in usb port iam getting error as Unlink after no-IRQ? Controller is probably using the wrong IRQ Although the interrupt number assignment is correct why it gives the above message ? Well, that seems odd. What kind of cpu / platform / hardware are you using? Please send the output of `lspci -vv` and `cat /proc/cpuinfo` If you have the ISP1562 attached to PCI, I guess the interrupt assignments are wrong or the IRQ line is broken. Regards, Clemens ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: reg Philips ISP 1562 usb controller support in linux2.6.23.11
mahendra varman schrieb: Hello all If iam not using the open firmware architecture Then can u please help me what i need to enable in menuconfig for ISP 1562 pci based usb controller ... According to it's datasheet, The ISP1562 integrates normal OHCI / EHCI compliant USB cores. My ISP1563 works fine with these CONFIGs enabled. Please do reply Please don't push anybody. Regards, Clemens Koller ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: framebuffer swap endianess
Roman Fietze schrieb: Hello Angelo, Question to the mailing list readers: is it ok to post an xfree86 or xorg patch in this mailing list (about 9KiB), or would it be better to mail that patch to Angelo directly? Thanks. I'm interested in it. Please, at least, CC me. :-) I was having similar issues with my SM501/SM502 on MPC8540/MPC8548. But due to other projects I had to slow down a bit that area. Thank you, Clemens ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: tiny login
pjmaiya schrieb: hi, - don't cross-post - don't post HTML to the lists I am using tiny login provided by montavista. Binaries already obtained from tool provided from montavista. We are able to add only 10 users. But I need to add more than 10 users. Tried to contact montavista for support? ;-) I have already downloaded free open source for tinylogin (tinylogin-1.4). Can we modifiy this source code of this version and support users more than 10?? If yes, can somebody inform step to build tiny login and installation method. Well, you propably want to understand the advantage of open source software first. You can (depending on the license) change the code according to your needs... Read: http://tldp.org/HOWTO/Software-Building-HOWTO.html If you have questions, please tell exactly, where you have a problem. $ wget http://tinylogin.busybox.net/downloads/tinylogin-1.4.tar.bz2 $ tar xvf tinylogin-1.4.tar.bz2 $ cd tinylogin-1.4 $ make works like a charm. A quick look into login.c says: // login defines #define TIMEOUT 60 #define FAIL_DELAY3 #define EMPTY_USERNAME_COUNT10 ... which looks quite promising! Ask the busybox guys for details since this is off-topic here. Regards, Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: OT: Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
Hi, Scott! Well, the subject is about RTCs. Not really, it's about a change in the i2c subsystem (I noticed you didn't include the i2c list or linuxppc-dev... you'd get a larger audience of the people that actually made the change that way). That it happens to be an RTC chip you're using on the i2c bus is an inconsequential detail. Looks like I wasn't subscribed to the list anymore, so I missed lots of DT related discussions - my bad. :-( Well... let's take it easy. I'll dig into the pcf8563 code now. BTW, there were patches posted recently by Jon Smirl to convert that driver to new-style, and to change the i2c subsystem to have the OF matches in the driver itself. That looks promising. I really didn't expect to find rtc driver names in fsl_soc.c... Regards, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: OT: Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
Jon Smirl schrieb: On 12/4/07, Clemens Koller [EMAIL PROTECTED] wrote: That was discussed already in detail in several threads and there were already decisions made that the DT went into the kernel - no problem with that. I just don't see that it 'really does help' in it's current state if things are broken in a way they are hard to fix for non DT-familiar developers, almost impossible to fix for users which just need to compile their own kernel to achieve their project goal. Well... let's take it easy. I'll dig into the pcf8563 code now. Most of this is addressed in the patch series starting with this message: http://ozlabs.org/pipermail/linuxppc-dev/2007-December/047382.html The pcf8563 driver is converted to the new format and is modified to pick up it's address from the device tree. This patch series is being held waiting for an ok on the low level changes to the i2c subsystem. Hopefully it will go into 2.6.25 Thanks Jon, thanks Scott for the pointers, this works for me. (Patches have some whitespace damage, you propably want to run it thru checkpatch.pl before pushing upstream.) Regards, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: OT: Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
Hi, Scott! Scott Wood schrieb: On Mon, Dec 03, 2007 at 08:35:29PM +0100, Clemens Koller wrote: Even if I have an eeprom which can have varying addresses, I can simply tell the driver/the kernel .config what address it should use... That's precisely what we do, via the device tree. It is not practical to do it with kconfig. It's propably not practical to do it with kconfig right now, but creating a separate configuration repository with strong relation to the kernel config is IMO the wrong way to do it. Again putting aside multiplatform kernels for the moment, what would you do in kconfig to describe the addresses of multiple chips without having a fixed-size list of possibilities? I don't see How would you tell the kernel, using kconfig, that there's a foo chip at address 0x68 on i2c bus 0, and a bar chip at address 0x68 on i2c bus 1? I would prefer to not tell the driver for 'foo' that it should attach to 0-0068 because it should attach to the first i2c bus (0) it finds per default. Then I would need to tell 'bar' to attach to 1-0068. Where is the problem? The 0068 is already redundant in the case of these RTCs because they are fixed. There is already an example in the kernel for a very similar configuration issue: see CONFIG_RTC_HCTOSYS_DEVICE. The structure for this already present in kconfig, and I don't see any road block not to be able to use it. If later on, we want to have OF to be able to reconfigure it in the form of a DT structure, we could still feed a tool like the dtc with the .config and generate one. Just let me make the point clear, why I got so upset here: Having two different non-independent repositories make the configuration much more error-prone, especially if the second one (the DT) is partially redundant and not sufficiently documented. Example: I need to use the PCF8563 on the MPC8540' I2C as well (*) - it was just working in 2.6.22. Now, somebody a) has to enable it in the kernel config b) then add it to the i2c_driver_device struct in fsl_soc.c c) then add it to the DTS. Step b and c are not difficult at all, but completely non-obvious and undocumented for non-developers. You actually have to dig in the code to find out that you need it and this s. linux-2.6/Documentation/powerpc$ grep rtc * only gives on hit in the mpc52xx-device-tree-bindings.txt (from Grant, btw.). which could give a clue what's going on here. linux-2.6/Documentation/powerpc$ grep fsl_soc * - nothing - The configuration process is away from KISS - I would simply state: it's broken - or - it's a regression from 2.6.22. (*) Patch will follow, let me see if I guess it right. :-) Regards, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: OT: Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
Hi, Scott! Scott Wood schrieb: How would you tell the kernel, using kconfig, that there's a foo chip at address 0x68 on i2c bus 0, and a bar chip at address 0x68 on i2c bus 1? I would prefer to not tell the driver for 'foo' that it should attach to 0-0068 because it should attach to the first i2c bus (0) it finds per default. Absolutely wrong. Hmm... Why? What if foo is on bus 1? Then I would need to tell the driver 'foo' that it should attach to 1-0068. Sorry, I really don't understand your problem here. If we have 'foo' on both busses, I need of course tell it to attach to 0-0068 as well as 1-0068. Propably you should see the bigger picture here: We just need to tell what we have, if it's not some default... statically (kconfig) or dynamically (of/dt) to get it right because we cannot probe for sure what we have (in contrast to PCI). I just don't want to be pushed into configuring things twice or on two different places because that's error prone. Then I would need to tell 'bar' to attach to 1-0068. Where is the problem? OK, now say there's another foo on bus 2, and a pair of bars on buses 3 and 4? Okay, let's play that game: foo - connect an instance to 0-0068 and 2-0068 bar - connect an instance to 1-0068 and and 3-0068 and 4-0068 If i.e. bar is a 8-page eeprom which hw-configurable addresses nailed down to 0x50 and 0x58 to have a contigous eeprom area from 0x50 to 0x5f it can also look like: bar - connect an instance to 1-0050 and 1-0058 I still don't see a conflict here. You cannot connect more than one device to an address, that would violate the I2C Spec. If you have different devices with the same address, you have to nail down which ones belong together. The 0068 is already redundant in the case of these RTCs because they are fixed. How do you know I'm even talking about RTCs? Well, the subject is about RTCs. But still the same applys for other i2c devices. Those chips at 0x68 could be anything. There are many chips that don't have a single fixed address. Sure. Just to make sure There is already an example in the kernel for a very similar configuration issue: see CONFIG_RTC_HCTOSYS_DEVICE. That's not remotely the same. That's telling a kernel init procedure what kernel device to use, not describing the layout of hardware. I was trying to tell you that the structure to embed above information is already there. The structure for this already present in kconfig, It is not. Okay, our point of view is different here. We really should try to get the table populated with names for all of the new-style drivers in the kernel, though. Yes. That's what's really necessary to put usability back in. linux-2.6/Documentation/powerpc$ grep rtc * only gives on hit in the mpc52xx-device-tree-bindings.txt (from Grant, btw.). which could give a clue what's going on here. linux-2.6/Documentation/powerpc$ grep fsl_soc * - nothing - Uh, did you try grepping for i2c? No, I've just read the whole file from time to time. The configuration process is away from KISS - I would simply state: it's broken - or - it's a regression from 2.6.22. The transition could have been done more smoothly if the i2c driver model allowed a driver to be both new-style and old-style at the same time (subject to a config option to shut off old-style if it's screwing things up), I'll agree with that much. But please, try to understand that the device tree really does help. That was discussed already in detail in several threads and there were already decisions made that the DT went into the kernel - no problem with that. I just don't see that it 'really does help' in it's current state if things are broken in a way they are hard to fix for non DT-familiar developers, almost impossible to fix for users which just need to compile their own kernel to achieve their project goal. Well... let's take it easy. I'll dig into the pcf8563 code now. Regards, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
Hi, Alessandro, Hi, Olof! Olof Johansson wrote: ds1307 requires you to register i2c_board_info for it to probe properly. Does your platform do so? I started to add some pr_debug()s. It seems that rtc-ds1307's ds1307_init() is just never called despite the module gets loaded. Regards, Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
Hi, Bartlomiej! Bartlomiej Sieka schrieb: Do you have rtc node in your dts file (I'm assuming arch/powerpc situation)? If not, you'll have to add it - for example similarly to what's being done in the attached patch (68 is the I2C address of the RTC chip - a DS1339 in my case). Thank you also for your hint... that was indeed the problem here. Simple but not really obvious. Is it possible to have a maximum generic .dts configuration where the kernel is told to include any device it propably finds? I guess the failing reset since 2.6.22 is also just an entry in my .dts... ? Regards, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
OT: Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
Hello, Scott! Scott Wood schrieb: Clemens Koller wrote: [OT+sarcasm on] So, the time is over, where you just enable a driver in the kernel config and the device gets probed and - if it's probed successfully - it usually works. The problem is the probed successfully bit -- i2c can't be automatically detected like PCI can, and the probing that was being done before was very error-prone. I think I understood the original purpose of device trees, or it's intended advantage but don't see much of this yet. Before (2.6.22) everything was working fine just by enabling the proper kernel config. But in it's current implementation I primarily see the an additional, duplicate, badly documented configuration step for these - in my case - stupid, usually trivial to handle RTC chips. That's the simplest way, but not the only way. You could also have a wrapper platform that chooses the proper device tree based on something you detect. Here is the problem: something it detects = probing (what we planned to avoid) something I detect = configurating (currently duplicated work). This wrapper platform doesn't really exist yet in practice. Hmmm... this just s! There are some growing pains, but the old method of blindly poking at i2c addresses and hoping that the first driver to ask for a port that something responds to is actually the right driver for that port is just shit. That's not a good example: Of course, blindly poking is bad... therefore there is the (kernel.)configuration step to have only the relevant drivers enabled: The Philips PCF8563 is on address 0x51 and the DS13x7 on 0x68. The drivers don't touch foreign addresses at all and they are fixed. No issues there... proved by 2.6.22. Well, I don't want to start a flamewar on this since we have had already enough pro contra Device Tree discussions. I just want to point out that the current situation doesn't really follow the KISS principle at all in my eyes. Here, the next idea which comes to my mind: Maybe we should think about a kernel-config - dts compiler for the future where the enabled drivers generate their default dts entries automagically? Regards, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: OT: Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
Hello, Scott! Scott Wood schrieb: Here, the next idea which comes to my mind: Maybe we should think about a kernel-config - dts compiler for the future where the enabled drivers generate their default dts entries automagically? Sorry, there's just not enough information in .config for that. If there is really the need to put more information (which I don't see in the case of the RTCs) to .config, it might be an idea to extend the current structure for this use instead of duplicating and maintaining a second repository. And regarding the DS1337 (or the PCF8563 and similar RTCs): It's address (0x68) is immutable fixed by the manufacturer of that device. So, why do we include it in the DT, when we already told the kernel what driver we want to use? Even if I have an eeprom which can have varying addresses, I can simply tell the driver/the kernel .config what address it should use... If I want to be able to alter that address for whatever reason by OF, I still don't want to touch a separate file in the kernel tree. Regards, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH] Add abort for fsl-devices which lack an RSTCR register.
This adds a fallback and calls abort() (in head_fsl_booke.S) to be able to successfully reset some older freescale devices (i.e. mpc8540) which don't have a RSTCR register. Robert, this should also fix your issues. Please test. Kumar, please ACK/NACK the patch since you touched fsl_rstcr_restart() last time (2007-10-04). Maybe the call to abort (which resets the processor via the Debug Control Register 0) could be put somewhere else or we create another entry for the device tree. Otherwise, I would prefer to check the PVR/SVR registers and use a suitable cpu_reset() call which fits to the current cpu. Regards, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com Add a fallback to abort() call (in head_fsl_booke.S) to be able to successfully reset some older freescale power devices (i.e. mpc8540) which don't have a rstcr register. Signed-off-by: Clemens Koller [EMAIL PROTECTED] diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c index 3ace747..6fe674a 100644 --- a/arch/powerpc/sysdev/fsl_soc.c +++ b/arch/powerpc/sysdev/fsl_soc.c @@ -42,6 +42,7 @@ extern void init_fcc_ioports(struct fs_platform_info*); extern void init_fec_ioports(struct fs_platform_info*); extern void init_smc_ioports(struct fs_uart_platform_info*); +extern void abort(void); static phys_addr_t immrbase = -1; phys_addr_t get_immrbase(void) @@ -1336,6 +1337,8 @@ void fsl_rstcr_restart(char *cmd) if (rstcr) /* set reset control register */ out_be32(rstcr, 0x2); /* HRESET_REQ */ + else + abort(); while (1) ; } ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
Hi, Alessandro! Alessandro Zummo schrieb: On Fri, 30 Nov 2007 12:04:00 +0100 Clemens Koller [EMAIL PROTECTED] wrote: Modular doesn't make sense to me, because the filesystem check starts to complain when last mount time was way to far in the past or in the future. But I will try... It's just to see if there's any timing issue like module-coming-up-before-bus-and/or-rtc. it should work anyway, but who knows... [EMAIL PROTECTED]:/lib/modules/2.6.24-rc3-ge1cca7e8/kernel/drivers/rtc$ lsmod Module Size Used by [EMAIL PROTECTED]:/lib/modules/2.6.24-rc3-ge1cca7e8/kernel/drivers/rtc$ modprobe rtc-ds1307 [EMAIL PROTECTED]:/lib/modules/2.6.24-rc3-ge1cca7e8/kernel/drivers/rtc$ lsmod Module Size Used by rtc_ds1307 6944 0 i2c_core 29936 1 rtc_ds1307 rtc_core 24248 1 rtc_ds1307 rtc_lib 3456 2 rtc_ds1307,rtc_core i2c_core doesn't pull in i2c_mpc (the MPC107/85xx i2c driver)! [EMAIL PROTECTED]:/lib/modules/2.6.24-rc3-ge1cca7e8/kernel/drivers/rtc$ modprobe i2c-mpc [EMAIL PROTECTED]:/lib/modules/2.6.24-rc3-ge1cca7e8/kernel/drivers/rtc$ lsmod Module Size Used by i2c_mpc 8128 0 rtc_ds1307 6944 0 i2c_core 29936 2 i2c_mpc,rtc_ds1307 rtc_core 24248 1 rtc_ds1307 rtc_lib 3456 2 rtc_ds1307,rtc_core it's still unused. Doing it the other way around: [EMAIL PROTECTED]:/lib/modules/2.6.24-rc3-ge1cca7e8/kernel/drivers/rtc$ lsmod Module Size Used by [EMAIL PROTECTED]:/lib/modules/2.6.24-rc3-ge1cca7e8/kernel/drivers/rtc$ modprobe i2c-mpc [EMAIL PROTECTED]:/lib/modules/2.6.24-rc3-ge1cca7e8/kernel/drivers/rtc$ lsmod Module Size Used by i2c_mpc 8128 0 i2c_core 29936 1 i2c_mpc [EMAIL PROTECTED]:/lib/modules/2.6.24-rc3-ge1cca7e8/kernel/drivers/rtc$ modprobe rtc-ds1307 [EMAIL PROTECTED]:/lib/modules/2.6.24-rc3-ge1cca7e8/kernel/drivers/rtc$ lsmod Module Size Used by rtc_ds1307 6944 0 rtc_core 24248 1 rtc_ds1307 rtc_lib 3456 2 rtc_ds1307,rtc_core i2c_mpc 8128 0 i2c_core 29936 2 rtc_ds1307,i2c_mpc [EMAIL PROTECTED]:/lib/modules/2.6.24-rc3-ge1cca7e8/kernel/drivers/i2c/busses$ cd /dev [EMAIL PROTECTED]:/dev$ ls -la r* crw-rw-rw- 1 root root 1, 8 Jan 1 1970 random I guess I'll have to dig in the code now since this is a 100% road block for my project. :-( Does it make sense to pickup some I2C people here? Same story, next week... Have a nice weekend. If you come up with some idea / patches, still let me know, I'll be able to login remotely. Thank you, Regards, Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: ppcboot and powerpc branch question
fabien schrieb: hi all, After some problem with my custom board and kernel 2.6.19 about the init process, i've moved on 2.6.23 and that had fixed my problems. (related to this post : http://marc.info/?l=linuxppc-embeddedm=11960901017w=2) Apparently it was a problem with cpm_uart on SMC1. (http://lkml.org/lkml/2007/9/23/99) the patch have been integrated in 2.6.23. Now i use this kernel and busybox works. I want to migrated my board in powerpc branch instead of ppc (i plan to use xenomai but in 2.6.23 there is only an adeos patch for piowerpc branch), but i see the use of a device tree instead of bd_t struct. I'm a bit disappointed because i also see that older u-boot (in my case ppcboot 1.1.5) aren't capable to pass dts to kernel. Is there a way to keep my old bootloader to boot a powerpc branch kernel ? please read linux/Documentation/powerpc/booting-without-of.txt To get a cuImage, you - need to adjust your platform.dts and configure your kernel to use it. - need the latest dtc (device tree compiler), - need the latest mkimage (from the latest u-boot tree) - and build your cuImage by building the target zImage (make zImage) - your cuImage then rests in i.e. arch/powerpc/boot/cuImage.platform Aside of no good documentation, I ran into the problem that the embedded device tree doesn't get updated by the bd_t struct properly (the mac addresses) in the latest versions of the kernel. This might be a bug or a configuration error on my side. I didn't check yet. U-Boot with full device tree support will hopfully fix that, when it's out. Regards, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
that won't be a solution for me. (I don't wan't modules at all.) Thank you a lot, best regards, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com config.gz Description: application/gzip ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: DS1337 RTC on I2C broken.
Hi, Alessandro! Alessandro Zummo schrieb: On Thu, 29 Nov 2007 21:03:49 +0100 Clemens Koller [EMAIL PROTECTED] wrote: My guess is that the new rtc-lib's RTC_DRV_DS1307 support is still broken and it also breaks the deprecated SENSORS_DS1337. :-( One more update: I am back to mainline (linus' .git) on 2.6.24-rc3-g09f345da to verify that the problem with the RTC still persists. I startet to bisect, but ran quickly into other crashes. (no console on 2.6.23-rc2 and 2.6.23) So, I just can tell that it broke in between 2.6.22-rc6-gb75ae860 and and 2.6.24-rc2-ge6a5c27f. did you tried compiling it modular? you might even check with i2cdetect if the chip is there A kernel upgrade doesn't make the chip to disappear ;-) The I2C bus is/was basically working fine all the time... see below. Modular doesn't make sense to me, because the filesystem check starts to complain when last mount time was way to far in the past or in the future. But I will try... I can: $ uname -a Linux fox_1 2.6.24-rc3-g09f345da #1 Thu Nov 29 21:21:39 CET 2007 ppc e500 GNU/Linux $ i2cdetect 0 WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-0. I will probe address range 0x03-0x77. Continue? [Y/n] Y 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- 48 -- -- -- -- -- -- -- 50: UU -- -- -- -- -- -- UU -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- At 0x68 is the DS1337, at 0x48 I have an LM75 at 0x50 and 0x57 there is some EEPROM attached $ i2cdump 0 0x68 b Error: Could not set address to 0x68: Device or resource busy That would tell me AFAICT that the ds1307 driver claimed that address already... But... Well, I've attached the config again. (Note, I enabled the SENSORS_x during my manual bisecting again to find where it doesn't work anymore. Disabling them didn't work for sure, but will retry now...) Regards, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com config.gz Description: application/gzip ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: DS1337 RTC on I2C broken.
Hello, Allessandro! Alessandro Zummo schrieb: On Wed, 28 Nov 2007 19:25:00 +0100 Clemens Koller [EMAIL PROTECTED] wrote: Well, as already mentioned, I have problems to get my DS1337 RTC on I2C on my MPC8540(ads like) PowerPC working properly on latest 2.6.24-rc2-ge6a5c27f kernels. A paulus.git 2.6.21-rc5-g9a5ee4cc as well as a 2.6.22-rc6-gb75ae860 is working fine. (mainstream's console is broken, so cannot test these, yet.) Just to give you an update: The latest paulus.git as of today (Linux-2.6.24-rc3-g0b47759d) is still broken. Same story as yesterday. Regards, Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: DS1337 RTC on I2C broken.
Hello, Raul! [EMAIL PROTECTED] schrieb: I am trying to use some devices on i2c protocol, one of them is the DS1337 RTC, but I don't know too much about how. I am using the Linux kernel 2.6.15 and a mpc866 processor. I don't remember too much about these old kernels. And, please notice, that - I am on an mpc8540 which is quite different from your mpc866 processor. - I am on the latest kernels which are also very different from the old ones regarding the RTC subsystem. Usually you have to configure the kernel using the right i2c interface for your processor (if supported). I am using the 'fsl-i2c' driver enabled by: I2C-support - I2C Hardware Bus support - MPC107/824x/85xx/52xx/86xx which will be: CONFIG_I2C_MPC=y Then, you might have to enable the (now deprecated) Misc I2C Chip Support - Dallas DS1337 and ... Real Time Clock support which gives you: CONFIG_SENSORS_DS1337=y I've seen there is a cpm i2c interface for these processors (for a rpx board). the fsl-i2c might be the right place However the corresponding code (i2c-algo8xx) doesn't appear in the sources. The i2c-rpx.c just initializes the ioports, the adapter struct and the isr. Maybe I am not understanding the i2c driver right. I am a bit confused about it. Could you give me some help about how it works or what should I have to do? I would suggest - despite the current problems - to use a current kernel and check your mileage there. I don't want to ride dead horses anymore. Regards, Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: DS1337 RTC on I2C broken.
Hi There! Clemens Koller [EMAIL PROTECTED] wrote: Well, as already mentioned, I have problems to get my DS1337 RTC on I2C on my MPC8540(ads like) PowerPC working properly on latest 2.6.24-rc2-ge6a5c27f kernels. A paulus.git 2.6.21-rc5-g9a5ee4cc as well as a 2.6.22-rc6-gb75ae860 is working fine. (mainstream's console is broken, so cannot test these, yet.) My guess is that the new rtc-lib's RTC_DRV_DS1307 support is still broken and it also breaks the deprecated SENSORS_DS1337. :-( One more update: I am back to mainline (linus' .git) on 2.6.24-rc3-g09f345da to verify that the problem with the RTC still persists. I startet to bisect, but ran quickly into other crashes. (no console on 2.6.23-rc2 and 2.6.23) So, I just can tell that it broke in between 2.6.22-rc6-gb75ae860 and and 2.6.24-rc2-ge6a5c27f. Regards, Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: DS1337 RTC on I2C broken.
Hi, Alessandro! Thank you for your quick response... I'll just follow your ideas and provide you with the dmesg output ASAP. If you are online for some more time, I will accelerate this debugging session... Just let me know. Alessandro Zummo schrieb: On Wed, 28 Nov 2007 19:25:00 +0100 Clemens Koller [EMAIL PROTECTED] wrote: Well, as already mentioned, I have problems to get my DS1337 RTC on I2C on my MPC8540(ads like) PowerPC working properly on latest 2.6.24-rc2-ge6a5c27f kernels. A paulus.git 2.6.21-rc5-g9a5ee4cc as well as a 2.6.22-rc6-gb75ae860 is working fine. (mainstream's console is broken, so cannot test these, yet.) My guess is that the new rtc-lib's RTC_DRV_DS1307 support is still broken and it also breaks the deprecated SENSORS_DS1337. :-( mmm. I've been told it should work ;) Here is a snippet from my .config which is similar among my kernels. CONFIG_GEN_RTC=y this one must be deselected. CONFIG_SENSORS_DS1337=y CONFIG_SENSORS_DS1374=y ditto. Will do. DEV: registering device: ID = '0-0068' bus i2c: add device 0-0068 bound device '0-0068' to driver 'ds1337' maybe the wrong driver is kicking in here. the fact that there is no rtc class related output in dmesg should and that there is no /dev/rtc0 could be a sign that the whole class is not going in. do you have full dmesg? Not a full one from the 2.6.24 right now... But I'll disable above stuff and get you a full one. (in 5..10 minutes). Regards, Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: DS1337 RTC on I2C broken.
Alessandro Zummo schrieb: On Wed, 28 Nov 2007 19:25:00 +0100 Clemens Koller [EMAIL PROTECTED] wrote: Well, as already mentioned, I have problems to get my DS1337 RTC on I2C on my MPC8540(ads like) PowerPC working properly on latest 2.6.24-rc2-ge6a5c27f kernels. A paulus.git 2.6.21-rc5-g9a5ee4cc as well as a 2.6.22-rc6-gb75ae860 is working fine. (mainstream's console is broken, so cannot test these, yet.) My guess is that the new rtc-lib's RTC_DRV_DS1307 support is still broken and it also breaks the deprecated SENSORS_DS1337. :-( mmm. I've been told it should work ;) Here is a snippet from my .config which is similar among my kernels. CONFIG_GEN_RTC=y this one must be deselected. CONFIG_SENSORS_DS1337=y CONFIG_SENSORS_DS1374=y ditto. DEV: registering device: ID = '0-0068' bus i2c: add device 0-0068 bound device '0-0068' to driver 'ds1337' maybe the wrong driver is kicking in here. the fact that there is no rtc class related output in dmesg should and that there is no /dev/rtc0 could be a sign that the whole class is not going in. do you have full dmesg? My current .config as well as the dmesg is attached with your suggested changes. Regards, Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com DEV: registering device: ID = 'tty47' DEV: registering device: ID = 'tty48' DEV: registering device: ID = 'tty49' DEV: registering device: ID = 'tty50' DEV: registering device: ID = 'tty51' DEV: registering device: ID = 'tty52' DEV: registering device: ID = 'tty53' DEV: registering device: ID = 'tty54' DEV: registering device: ID = 'tty55' DEV: registering device: ID = 'tty56' DEV: registering device: ID = 'tty57' DEV: registering device: ID = 'tty58' DEV: registering device: ID = 'tty59' DEV: registering device: ID = 'tty60' DEV: registering device: ID = 'tty61' DEV: registering device: ID = 'tty62' DEV: registering device: ID = 'tty63' Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled Registering platform device 'serial8250'. Parent at platform DEV: registering device: ID = 'serial8250' bus platform: add device serial8250 DEV: registering device: ID = 'ttyS0' DEV: registering device: ID = 'ttyS1' DEV: registering device: ID = 'ttyS2' DEV: registering device: ID = 'ttyS3' bus platform: add driver serial8250 platform: Matched Device serial8250.0 with Driver serial8250 platform: Probing driver serial8250 with device serial8250.0 DEV: Unregistering device. ID = 'ttyS0' device_create_release called for ttyS0 serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 42) is a 16550A console [ttyS0] enabled DEV: registering device: ID = 'ttyS0' DEV: Unregistering device. ID = 'ttyS1' device_create_release called for ttyS1 serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 42) is a 16550A DEV: registering device: ID = 'ttyS1' bound device 'serial8250.0' to driver 'serial8250' platform: Bound Device serial8250.0 to Driver serial8250 platform: Matched Device serial8250 with Driver serial8250 platform: Probing driver serial8250 with device serial8250 bound device 'serial8250' to driver 'serial8250' platform: Bound Device serial8250 to Driver serial8250 bus pci: add driver serial loop: module loaded bus platform: add driver fsl-gianfar_mdio platform: Matched Device fsl-gianfar_mdio.-5 with Driver fsl-gianfar_mdio platform: Probing driver fsl-gianfar_mdio with device fsl-gianfar_mdio.-5 DEV: registering device: ID = 'e0024520:00' bus mdio_bus: add device e0024520:00 DEV: registering device: ID = 'e0024520:1f' bus mdio_bus: add device e0024520:1f Gianfar MII Bus: probed bound device 'fsl-gianfar_mdio.-5' to driver 'fsl-gianfar_mdio' platform: Bound Device fsl-gianfar_mdio.-5 to Driver fsl-gianfar_mdio bus platform: add driver fsl-gianfar platform: Matched Device fsl-gianfar.0 with Driver fsl-gianfar platform: Probing driver fsl-gianfar with device fsl-gianfar.0 DEV: registering device: ID = 'eth0' eth0: Gianfar Ethernet Controller Version 1.2, 00:d0:93:0e:4e:c4 eth0: Running with NAPI enabled eth0: 256/256 RX/TX BD ring size bound device 'fsl-gianfar.0' to driver 'fsl-gianfar' platform: Bound Device fsl-gianfar.0 to Driver fsl-gianfar platform: Matched Device fsl-gianfar.1 with Driver fsl-gianfar platform: Probing driver fsl-gianfar with device fsl-gianfar.1 DEV: registering device: ID = 'eth1' eth1: Gianfar Ethernet Controller Version 1.2, 00:d0:93:0e:4e:c5 eth1: Running with NAPI enabled eth1: 256/256 RX/TX BD ring size bound device 'fsl-gianfar.1' to driver 'fsl-gianfar' platform: Bound Device fsl-gianfar.1 to Driver fsl-gianfar platform: Matched Device fsl-gianfar.2 with Driver fsl-gianfar platform: Probing driver fsl-gianfar with device fsl-gianfar.2 DEV: registering device: ID = 'eth2' eth2: Gianfar Ethernet Controller Version 1.2, 00:d0:93:0e:4e:c6 eth2: Running with NAPI enabled eth2: 256/256 RX/TX BD ring size bound
Re: 85xx software reset problems from paulus.git
Hi, Robert, Hi, Kumar!
robert lazarski schrieb:
Hi Kumar, I finally got time to get back to this:
On Nov 17, 2007 2:52 PM, Kumar Gala [EMAIL PROTECTED] wrote:
On Nov 16, 2007, at 4:01 PM, robert lazarski wrote:
Sorry for replying to myself, but thought I'd mention SRESET works
fine on 85xx 2.6.23 , ie, the board resets after kernel panic. It
doesn't work for me on 2.6.24rc2 .
What actual 85xx are you using?
- k
Custom 8548 board. I'm using the cds 85xx code for a reference and I
calling the same reset functions.
1. do you have the following in your dts:
[EMAIL PROTECTED] {//global utilities reg
compatible = fsl,mpc8548-guts;
reg = e 1000;
fsl,has-rstcr;
};
Yes.
2. in your platform code are you using fsl_rstcr_restart in
define_machine()
- k
Yes. The symptoms in 2.6.24RC2 are that during a kernel panic or when
calling 'reboot' in the shell, it just hangs. Using the same dts and
resets in 2.6.23.1 reboots fine. I don't have a cds reference, but
someone who does should be able to confirm whether the issue exists or
not by just attempting to reboot via bash.
ACK. Exactly the same over here (mpc8540ads compatible).
I added the global-utilities today as well, but reboot fails.
Why is the guts stuff missing i.e. in most of the shipped
mpc85xx*.dts? Does it depend on some hardware connections
external to the CPU?
Regards,
--
Clemens Koller
___
RD Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm-technology.com
Phone: +49-89-741518-50
Fax: +49-89-741518-19
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: PCI to Parallel for PowerPC
Bai Shuwei schrieb: Please don't cross-post. hi, all I bought a SMC1500 stepper motor card. And it can connect with host through parallel port. My target board is PowerPC 440, which hasn't parrallel port. So I bought a PCI to Parallel line for SMC1500. But when I run the stepper motor, I find it's not stable. I doubt there are somthing wrong with my PCI to Parallel line. So I beg somebody can tell me where I can bought the appropriate conversion line from PCI to parallel, and does somebody give me some idea about how to control my stepper motor through PowerPC 440? thx all Put that PCI Card to your host where your stepper was working properly to see if it's a hardware issue with that card. Then it depends on how you control your stepper motor. If you use some bit-banging (which I wouldn't recommend) to drive each winding and want to have smooth movement, you need a very precise timing when it comes to some more than low-speed stepper motors, otherwise your motors will start to coggle. To be precise: you will first have to figure out what leads to the effect of it's not stable. Do you have an Oscilloscope? Regards, -- Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm-technology.com Phone: +49-89-741518-50 Fax: +49-89-741518-19 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: cant' compile busybox-1.8.1 with eldk 4.1
fabien schrieb: I try to compile busybox for my ppc custom board. What ARCH/cpu? I successfuly compile kernel 2.6.19 with eldk and boot it. Now i try to get busybox working but i get some errors at compile time. It's look strange if someone can spend one minute to look at the compile log What step could i miss ? [...] /opt/eldk/usr/../ppc_8xx/usr/include/linux/param.h:4:23: error: asm/param.h: No such file or directory make[1]: *** [applets/applets.o] Erreur 1 make: *** [applets] Erreur 2 It looks like your kernel headers (ARCH-specific or generic) are broken or missing. See i.e. Linux From Scratch to get an idea about the dependencies. Or, see latest kernel's 'make headers_install' target and how it is used. Google is your friend, here... The busybox mailing list would be more suited for this question. Regards, Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Firmware Support for USB Hub
Misbah khan schrieb: Laurent Pinchart-4 wrote: On Wednesday 21 November 2007 18:20, Scott Wood wrote: If I remember correctly, CPM2 USB host support requires the host to create SOF packets in software. High system loads will probably mess the bus up. A colleague of mines was told by Freescale to use an external USB controller instead of the MPC8248 bundled one. I have posted this quarry to freescale. Anyway if you get more information could you please share with me ?? Well... can you post the source of this information. I would expect having effects like this documented in the user manual or if it's really erratic behaviour (and not a mess in an unmaintained piece of software) in an errata sheet. Please update. Regards, Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Oops: of_platform_serial_probe
Hi, Arnd!
Arnd Bergmann schrieb:
On Monday 19 November 2007, Clemens Koller wrote:
Unable to handle kernel paging request for data at address 0x
Faulting instruction address: 0xc018f03c
Oops: Kernel access of bad area, sig: 11 [#1]
MPC85xx ADS
Modules linked in:
NIP: c018f03c LR: c018f00c CTR: c00127b4
REGS: c0821cf0 TRAP: 0300 Not tainted (2.6.24-rc2-ge6a5c27f)
MSR: 00029000 EE,ME CR: 42022088 XER: 2000
DEAR: , ESR:
TASK = c081e000[1] 'swapper' THREAD: c082
GPR00: b100 c0821da0 c081e000 c0833e10 0004 c0821d80 c03d3064
c05eea80
GPR08: 0200 0002 002a 13ab6680 82022042 c03318a4
c033188c
GPR16: c0331908 c03318f0 c03a0e30 c0331930 c033191c 007fff00 0ffeccbc
c03a
GPR24: c0821dc4 0003 c0934cf8 cba8 c0833e00
c07fdc6c
NIP [c018f03c] of_platform_serial_probe+0x118/0x1e4
LR [c018f00c] of_platform_serial_probe+0xe8/0x1e4
Call Trace:
Ok, that is a NULL pointer access, probably somewhere in the
of_platform_serial_setup that can be inlined. Please post the
device tree entries for your serial ports so we can see what
goes wrong there.
The device tree is the default one which comes with the kernel:
paulus.git/arch/powerpc/boot/dts/mpc8540ads.dts
which contains:
[EMAIL PROTECTED] {
device_type = serial;
compatible = ns16550;
reg = 4500 100; // reg base, size
clock-frequency = 0; // should we fill in in uboot?
interrupts = 2a 2;
interrupt-parent = mpic;
};
[EMAIL PROTECTED] {
device_type = serial;
compatible = ns16550;
reg = 4600 100; // reg base, size
clock-frequency = 0; // should we fill in in uboot?
interrupts = 2a 2;
interrupt-parent = mpic;
};
One potential problem that I can see is a missing 'current-speed'
property in your tree, which would cause this behavior.
That's correct. Should be fixed in all .dts' ?
It looks
like many device trees set this, but it is not required by all
bindings.
How should someone know, when it's really needed and when not?
If that's the case, the patch below should fix your
problem, but you probably want to set the current-speed anyway,
according to your boot loader settings.
I think there was no need to set it again, because of: console=ttyS0,115200
But I'll verify...
--- a/drivers/serial/of_serial.c
+++ b/drivers/serial/of_serial.c
@@ -56,7 +56,8 @@ static int __devinit of_platform_serial_setup(struct
of_device *ofdev,
port-flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_IOREMAP
| UPF_FIXED_PORT;
port-dev = ofdev-dev;
- port-custom_divisor = *clk / (16 * (*spd));
+ if (spd)
+ port-custom_divisor = *clk / (16 * (*spd));
return 0;
}
Ack! However, I changed it similar to the available code.
No idea what's better here. At least it should tell the user:
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 42) is a 16550A
console [ttyS0] enabled
serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 42) is a 16550A
of_serial e0004500.serial: no current-speed property set
of_serial e0004600.serial: no current-speed property set
Patch attached.
Regards,
--
Clemens Koller
__
RD Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
Warn user when current-speed property isn't set and exit.
Signed-off-by: Clemens Koller [EMAIL PROTECTED]
CC: Arnd Bergmann [EMAIL PROTECTED]
diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
index a64d858..e035cb2 100644
--- a/drivers/serial/of_serial.c
+++ b/drivers/serial/of_serial.c
@@ -36,6 +36,10 @@ static int __devinit of_platform_serial_setup(struct
of_device *ofdev,
memset(port, 0, sizeof *port);
spd = of_get_property(np, current-speed, NULL);
clk = of_get_property(np, clock-frequency, NULL);
+ if (!spd) {
+ dev_warn(ofdev-dev, no current-speed property set\n);
+ return -ENODEV;
+ }
if (!clk) {
dev_warn(ofdev-dev, no clock-frequency property set\n);
return -ENODEV;
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 2.6 kernel hangs after loading device tree
charanya venkatraman wrote: Hi all Sorry about the previous mail.Got sent by mistake. Iam using the 2.6.22.5 kernel on MPC 8560 and MPC8540 on my custom board.Mykernel hangs after loading the device tree in both the processors. There is no output on the serial port after loading the device tree. I have tried the following console arguments: MPC8540: bootargs root=/dev/ram rw console=ttyS0,115200 MPC8560:bootargs root=/dev/ram rw console=ttyCPM0,115200 Any help on this issue?? Maybe your problem is related to... See the thread at: http://ozlabs.org/pipermail/linuxppc-embedded/2007-November/028968.html (I use Paulus' git tree.) Regards, Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Problem with uboot on lite5200
Hello, Wolfgang! Wolfgang Denk schrieb: In message [EMAIL PROTECTED] you wrote: How should people get a glue what's current, when in the section Latest News at http://sourceforge.net/projects/u-boot/ the people still find a more or less official looking u-boot-1.1.5 release. Maybe by reading the very first two lines on the SF page: ... NOTE: current source code is available from DENX git repository and FTP server; see http://www.denx.de/en/Software/GIT I tried to convince you to point them to the releases... and _not_ to any repository. The problem is that you cannot really shut down a SourceForge project (please correct me if I'm wrong). I don't like SourceForge for some reasons... now, if that's true, I got one more. But anyway, there should be a way to update the Latest News... in a way it points to current stuff. Current U-Boot is 1.3.0-rc4. Please wake up. Well... maybe it's better to remove all references to the old releases at sourceforge and point them to ftp://ftp.denx.de/pub/u-boot/ Can you please teach me how to do that? I would expect that one of the project admins (i.e. you) is able to update the site information. You could update the SF project as you did since u-boot-0.2.0. If you don't want to continue with SF, propably an update to a last SF version with nothing more than an README should suffice. Well, I know you expect people to read... I'm just wondering why so many people use ancient versions. (-: And 1.3.0 will be out in less than 2 hours from now :-) Well... that's great... thank you all! Regards, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Oops: of_platform_serial_probe
@@ -36,6 +36,10 @@ static int __devinit of_platform_serial_setup(struct
of_device *ofdev,
memset(port, 0, sizeof *port);
spd = of_get_property(np, current-speed, NULL);
clk = of_get_property(np, clock-frequency, NULL);
+ if (!spd) {
+ dev_warn(ofdev-dev, no current-speed property set\n);
+ return -ENODEV;
+ }
if (!clk) {
dev_warn(ofdev-dev, no clock-frequency property set\n);
return -ENODEV;
This looks wrong. Since the current-speed property is not mandated by open
firmware,
we should not error out here, but simply use the setting from the command
line
or whatever other defaults can be used. Not setting port-custom_divisor at
all
should do the job.
Understood... but then, my console just stops / gets reinitialized to some
unknown
baudrate when I get to of_serial.c. :-(
Regards,
Clemens Koller
__
RD Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Oops: of_platform_serial_probe
Hi, I just ran into this in paulus.git: = bootm fe50 ## Booting image at fe50 ... Image Name: Linux-2.6.24-rc2-ge6a5c27f Created: 2007-11-19 13:06:38 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1951325 Bytes = 1.9 MB Load Address: 0040 Entry Point: 004005b0 Verifying Checksum ... OK Uncompressing Kernel Image ... OK x3' Generic RTC Driver v1.07 Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 42) is a 16550A console [ttyS0] enabled serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 42) is a 16550A Unable to handle kernel paging request for data at address 0x Faulting instruction address: 0xc018f03c Oops: Kernel access of bad area, sig: 11 [#1] MPC85xx ADS Modules linked in: NIP: c018f03c LR: c018f00c CTR: c00127b4 REGS: c0821cf0 TRAP: 0300 Not tainted (2.6.24-rc2-ge6a5c27f) MSR: 00029000 EE,ME CR: 42022088 XER: 2000 DEAR: , ESR: TASK = c081e000[1] 'swapper' THREAD: c082 GPR00: b100 c0821da0 c081e000 c0833e10 0004 c0821d80 c03d3064 c05eea80 GPR08: 0200 0002 002a 13ab6680 82022042 c03318a4 c033188c GPR16: c0331908 c03318f0 c03a0e30 c0331930 c033191c 007fff00 0ffeccbc c03a GPR24: c0821dc4 0003 c0934cf8 cba8 c0833e00 c07fdc6c NIP [c018f03c] of_platform_serial_probe+0x118/0x1e4 LR [c018f00c] of_platform_serial_probe+0xe8/0x1e4 Call Trace: [c0821da0] [c018f00c] of_platform_serial_probe+0xe8/0x1e4 (unreliable) [c0821e70] [c0210c1c] of_platform_device_probe+0x5c/0x84 [c0821e90] [c0192f30] driver_probe_device+0xf4/0x238 [c0821eb0] [c01932a4] __driver_attach+0xcc/0xf8 [c0821ed0] [c019254c] bus_for_each_dev+0x58/0x94 [c0821f00] [c0192cec] driver_attach+0x24/0x34 [c0821f10] [c0191e18] bus_add_driver+0xac/0x21c [c0821f30] [c0193524] driver_register+0x58/0xa0 [c0821f40] [c0008178] of_register_platform_driver+0x64/0x80 [c0821f50] [c03953d4] of_platform_serial_init+0x18/0x28 [c0821f60] [c03831f4] kernel_init+0xd0/0x2b0 [c0821ff0] [c000d980] kernel_thread+0x44/0x60 Instruction dump: 3802 9061002c 9801003a 387e0010 93410088 3c00b100 393a 2b89000f 817f 9001007c 9061009c 91610030 8019 813f 54002036 7d290396 Kernel panic - not syncing: Attempted to kill init! Please note the x3' trash characters right in the beginning. I guess I didn't configure the OF serial right in the .dts but it still shouldn't crash. My .config is attached. Regards, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com # # Automatically generated make config: don't edit # Linux kernel version: 2.6.24-rc2 # Mon Nov 19 13:33:54 2007 # # CONFIG_PPC64 is not set # # Processor support # # CONFIG_6xx is not set CONFIG_PPC_85xx=y # CONFIG_PPC_8xx is not set # CONFIG_40x is not set # CONFIG_44x is not set # CONFIG_E200 is not set CONFIG_85xx=y CONFIG_E500=y CONFIG_BOOKE=y CONFIG_FSL_BOOKE=y # CONFIG_PHYS_64BIT is not set CONFIG_SPE=y # CONFIG_PPC_MM_SLICES is not set CONFIG_PPC32=y CONFIG_WORD_SIZE=32 CONFIG_PPC_MERGE=y CONFIG_MMU=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_HARDIRQS=y CONFIG_IRQ_PER_CPU=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_FIND_NEXT_BIT=y # CONFIG_ARCH_NO_VIRT_TO_BUS is not set CONFIG_PPC=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_NVRAM=y CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y CONFIG_OF=y CONFIG_PPC_UDBG_16550=y # CONFIG_GENERIC_TBSYNC is not set CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y CONFIG_DEFAULT_UIMAGE=y # CONFIG_PPC_DCR_NATIVE is not set # CONFIG_PPC_DCR_MMIO is not set CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=14 # CONFIG_CGROUPS is not set CONFIG_FAIR_GROUP_SCHED=y CONFIG_FAIR_USER_SCHED=y # CONFIG_FAIR_CGROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_RELAY=y # CONFIG_BLK_DEV_INITRD is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y
Re: Oops: of_platform_serial_probe
Timur Tabi schrieb: Clemens Koller wrote: I guess I didn't configure the OF serial right in the .dts but it still shouldn't crash. My .config is attached. Try disabling CONFIG_SERIAL_OF_PLATFORM. I don't think it means what you think it means. Thanks, disabling CONFIG_SERIAL_OF_PLATFORM helps. but it still shouldn't crash... Regards, Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Problem with uboot on lite5200
Hello, Wolfgang! Wolfgang Denk schrieb: In message [EMAIL PROTECTED] you wrote: how can i re-flash the uboot inside the MPC5200? i use bdi2000, compiled the You are off topic here. Please post U-Boto related questions on the U-Boot maioling list. new uboot version 1.1.6 but didnt find out anyway to flash it inside the New? 1.1.6? That's stone-age. How should people get a glue what's current, when in the section Latest News at http://sourceforge.net/projects/u-boot/ the people still find a more or less official looking u-boot-1.1.5 release. (And they don't want to use scm repositories because they are afraid of using anything unstable.) Current U-Boot is 1.3.0-rc4. Please wake up. Well... maybe it's better to remove all references to the old releases at sourceforge and point them to ftp://ftp.denx.de/pub/u-boot/ instead. Btw. 1.3.0-rc4 isn't there as well. :-P Regards, -- Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm-technology.com Phone: +49-89-741518-50 Fax: +49-89-741518-19 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 85xx software reset problems from paulus.git
Hello, Robert! robert lazarski schrieb: Hi all, on my custom 85xx board I can't do a soft reset. I'm using u-boot 1.3rc3 that has the latest cpu/mpc85xx/cpu.c patch to fix some type of reset problem. When I press the software reset button on my board after my nfs kernel panic, I get this: Please define software reset button in your case. :-) I consider a button clearly as hardware. In my case (my button) asserts the HRESET# CPU pin low. As far as I understood the details (not verified again): To trigger a hard reset via software, the CPU (8540 at least) should assert the HRESET_REQ# (Pin AG20) low (which needs to be triggered in software, somehow). Some external glue logic should then issue the HRESET# (pin AH16) low to reset the CPU (hard, Power On Reset). The SRESET# (pin AF20) is the soft reset input, causes an mcp assertion to the core (RTFM) So, the detailed explanation seems to be implementation specific (if HRESET_REQ# can get triggered and if HRESET_REQ# assertion is glued to assert HRESET# from the HW guys). Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0) Rebooting in 10 seconds..Machine check in kernel mode. Caused by (from MCSR=8000): Machine Check Signal Oops: Machine check, sig: 7 [#1] MPC85xx CDS NIP: c00131f8 LR: c0014060 CTR: c00230dc REGS: c0289f50 TRAP: 0202 Not tainted (2.6.24-rc2-ge6a5c27f-dirty) MSR: 00021000 ME CR: 2428 XER: 2000 TASK = c102[1] 'swapper' THREAD: c1022000 GPR00: 0002 c1023e30 c102 0686 0047 c1023e38 GPR08: 7e58da6f f1b0 003d0900 c0281ec8 4488 7fffa7e3 3ffefb00 0080 GPR16: 007fff00 c022 c026 c026 3ffeb254 GPR24: c026 c028 c0219f84 c029 2710 c026 NIP [c00131f8] fsl_rstcr_restart+0x20/0x24 LR [c0014060] mpc85xx_cds_restart+0x78/0x8c Call Trace: [c1023e30] [c0014008] mpc85xx_cds_restart+0x20/0x8c (unreliable) [c1023e50] [c000c894] machine_restart+0x34/0x48 [c1023e60] [c0031f9c] emergency_restart+0x14/0x24 [c1023e70] [c00234e8] panic+0x134/0x174 [c1023f00] [c0242d5c] mount_block_root+0x108/0x24c [c1023f50] [c02431c0] prepare_namespace+0xd0/0x210 [c1023f70] [c0242938] kernel_init+0x170/0x290 [c1023ff0] [c000d2dc] kernel_thread+0x44/0x60 Instruction dump: 80010014 38210010 7c0803a6 4e800020 7c000146 3d20c029 8129821c 2f89 419e0010 3802 7c0004ac 9009 4800 81230044 8009003c 70090008 Kernel panic - not syncing: Attempted to kill init! Rebooting in 10 seconds.. I believe Clemens recently confirmed the same issue. Any ideas? Robert Not really. I just can confirm that the a $shutdown -r now doesn't reboot my board anymore whereas 2.6.21-rc4 did. IIRC, I've seen a patch which changed some instructions in some reboot() function some time ago. (Please note, I'm using the mpc8540_ads which might be slightly different from the *_cds.) Regards, Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Latest paulus.git PCI broken on mpc8540?
Hi, Ben! Benjamin Herrenschmidt schrieb: On Fri, 2007-11-16 at 13:18 -0600, Kumar Gala wrote: Well, for one the generic pci code will complain if its not able to allocate the resource which is the true failure. I'm thinking maybe we just make these pr_debug() instead of standard printk? I was thinking about changing the message to cannot allocate initial resource, will reallocate or something like that. That is, make it clear it's non fatal. I don't know much of the code, so, propably a stupid question: Can we avoid to do the initial resource allocation, when it's known to fail? It seems to me like things are done twice here: 1. try 2. reallocate 3. retry Regards, -- Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm-technology.com Phone: +49-89-741518-50 Fax: +49-89-741518-19 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Latest paulus.git PCI broken on mpc8540?
Hi there! I try to use the latest Linux-2.6.24-rc2-ge6a5c27f from paulus.git for my mpc8540ads compatible board. $ dmesg contains some nasty messages, which look like something is wrong. PCI: Probing PCI hardware PCI: Cannot allocate resource region 0 of device :00:12.0 PCI: Cannot allocate resource region 1 of device :00:12.0 PCI: Cannot allocate resource region 2 of device :00:12.0 PCI: Cannot allocate resource region 3 of device :00:12.0 PCI: Cannot allocate resource region 4 of device :00:12.0 PCI: Cannot allocate resource region 0 of device :00:14.0 PCI: Cannot allocate resource region 2 of device :00:14.0 However, the PCI devices just work fine - machine boots and: $ lspci -vv 00:12.0 Mass storage controller: Promise Technology, Inc. 20269 (rev 02) (prog-if 85) Subsystem: Promise Technology, Inc. Ultra133TX2 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=slow TAbort- TAbort- MAbort- SERR- - Latency: 128 (1000ns min, 4500ns max), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 18 Region 0: I/O ports at 1000 [size=8] Region 1: I/O ports at 1008 [size=4] Region 2: I/O ports at 1010 [size=8] Region 3: I/O ports at 100c [size=4] Region 4: I/O ports at 1020 [size=16] Region 5: Memory at 8000 (32-bit, non-prefetchable) [size=16K] Expansion ROM at 000dc000 [disabled] [size=16K] Capabilities: [60] Power Management version 1 Flags: PMEClk- DSI+ D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: pata_pdc2027x 00:14.0 Mass storage controller: Promise Technology, Inc. PDC40775 (SATA 300 TX2plus) (rev 02) Subsystem: Promise Technology, Inc. PDC40775 (SATA 300 TX2plus) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR-- Latency: 128 (1000ns min, 4500ns max), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 19 Region 0: I/O ports at 1080 [size=128] Region 2: I/O ports at 1400 [size=256] Region 3: Memory at 80004000 (32-bit, non-prefetchable) [size=4K] Region 4: Memory at 8002 (32-bit, non-prefetchable) [size=128K] Expansion ROM at 0008 [disabled] [size=32K] Capabilities: [60] Power Management version 2 Flags: PMEClk- DSI+ D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: sata_promise Hmm... I suspect a wrong kernel config or problems with the device tree (I'm using an unchanged arch/powerpc/boot/dts/mpc8540ads.dts). My .config is based on the mpc8540_ads_defconfig was attached: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20071114/2567627a/attachment-0001.txt Any ideas? Thank you, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 85xx Device tree problems: e0024520:02 not found
Hello, Robert!
robert lazarski schrieb:
On Nov 13, 2007 3:33 PM, Clemens Koller [EMAIL PROTECTED] wrote:
robert lazarski schrieb:
Hi all,
I'm trying to bring up a new 8548 board on 2.6.23.1 . When booting,
Some times I can get as far mounting over nfs. However, it gets stuck
here:
NET: Registered protocol family 1
NET: Registered protocol family 17
e0024520:02 not found
eth2: Could not attach to PHY
IP-Config: Failed to open eth2
IP-Config: Device `eth2' not found.
As already written in the u-boot-users list,
you could give the pauilis.git tree a try.
There have been recently (last month) several
PHY related changes. 2.6.23.1 seems to be too
old.
I'm now running pauilis.git and 2.6.24rc2, along with a new custom
board. I still can't attach to the phy though. I know the phy works
because it works fine in u-boot. Clemens, IIRC you are using the
88e - is that with the gianfar driver? I'm having problems getting
soft reboot to work with pauilis.git from some reason so debugging is
slow going - might someone have some hints?
I was busy all day long with some other broken hardware stuff.
As I told you yesterday, I was able to boot the mpc8540ads_defconfig
paulus.git tree. I was just able to boot it to see boot messages, where
I stopped yesterday ('cause time squeezes all men under it's foot like a bug).
Today I finished my kernel config and booted up my distro but...
klump... network doesn't work either. Maybe I only got some PHY
addresses wrong (I don't remember).
The 88e works fine, in u-boot, too.
So, we might sit in the same boat again...
I am about to start more debugging...
My current Kernel config is attached.
Any hints are welcome - of course.
Regards,
Clemens Koller
__
RD Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.24-rc2
# Wed Nov 14 18:27:25 2007
#
# CONFIG_PPC64 is not set
#
# Processor support
#
# CONFIG_6xx is not set
CONFIG_PPC_85xx=y
# CONFIG_PPC_8xx is not set
# CONFIG_40x is not set
# CONFIG_44x is not set
# CONFIG_E200 is not set
CONFIG_85xx=y
CONFIG_E500=y
CONFIG_BOOKE=y
CONFIG_FSL_BOOKE=y
# CONFIG_PHYS_64BIT is not set
CONFIG_SPE=y
# CONFIG_PPC_MM_SLICES is not set
CONFIG_PPC32=y
CONFIG_WORD_SIZE=32
CONFIG_PPC_MERGE=y
CONFIG_MMU=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_IRQ_PER_CPU=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_ILOG2_U32=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
# CONFIG_ARCH_NO_VIRT_TO_BUS is not set
CONFIG_PPC=y
CONFIG_EARLY_PRINTK=y
CONFIG_GENERIC_NVRAM=y
CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_PPC_OF=y
CONFIG_OF=y
CONFIG_PPC_UDBG_16550=y
# CONFIG_GENERIC_TBSYNC is not set
CONFIG_AUDIT_ARCH=y
CONFIG_GENERIC_BUG=y
CONFIG_DEFAULT_UIMAGE=y
# CONFIG_PPC_DCR_NATIVE is not set
# CONFIG_PPC_DCR_MMIO is not set
CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config
#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
# CONFIG_USER_NS is not set
# CONFIG_AUDIT is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_CGROUPS is not set
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_FAIR_USER_SCHED=y
# CONFIG_FAIR_CGROUP_SCHED is not set
CONFIG_SYSFS_DEPRECATED=y
CONFIG_RELAY=y
# CONFIG_BLK_DEV_INITRD is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_EMBEDDED=y
CONFIG_SYSCTL_SYSCALL=y
# CONFIG_KALLSYMS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLUB_DEBUG=y
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
# CONFIG_KMOD is not set
CONFIG_BLOCK=y
# CONFIG_LBD is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set
# CONFIG_BLK_DEV_BSG is not set
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_DEFAULT_AS=y
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED=anticipatory
#
# Platform support
#
# CONFIG_PPC_MPC52xx is not set
# CONFIG_PPC_MPC5200 is not set
Re: 85xx Device tree problems: e0024520:02 not found
robert lazarski schrieb: I'm now running pauilis.git and 2.6.24rc2, along with a new custom board. I still can't attach to the phy though. I know the phy works because it works fine in u-boot. Clemens, IIRC you are using the 88e - is that with the gianfar driver? Yes, yes. (I still have to check my PHY addresses.) I'm having problems getting soft reboot to work with paulus.git from some reason so debugging is slow going - might someone have some hints? I can also ACK your reboot-problem. $ shutdown -r now stops here at: Restarting system. IIRC, there were some patches some time ago changing some powerpc reboot stuff... Propably, git-bisect will be our friend. The latest working kernel over here was: Linux-2.6.21-rc5-g9a5ee4cc with ARCH=ppc I think it was also from paulus. Now I am at ARCH=powerpc. Regards, Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 85xx Device tree problems: e0024520:02 not found
Hi, Robert! Just one more short note... My good - vs. - bad dmesg output: good 2.6.21-rc5-git: Gianfar MII Bus: probed eth0: Gianfar Ethernet Controller Version 1.2, 00:ww:xx:yy:zz:dd eth0: Running with NAPI enabled eth0: 256/256 RX/TX BD ring size eth1: Gianfar Ethernet Controller Version 1.2, 00:ww:xx:yy:zz:dd eth1: Running with NAPI enabled eth1: 256/256 RX/TX BD ring size eth2: Gianfar Ethernet Controller Version 1.2, 00:ww:xx:yy:zz:dd eth2: Running with NAPI enabled eth2: 256/256 RX/TX BD ring size Marvell 88E1101: Registered new driver Marvell 88E: Registered new driver Marvell 88E1145: Registered new driver (I've wiped out my MAC) bad 2.6.24-rc2-git: Gianfar MII Bus: probed eth0: Gianfar Ethernet Controller Version 1.2, 00:00:00:00:00:00 eth0: Running with NAPI enabled eth0: 256/256 RX/TX BD ring size eth1: Gianfar Ethernet Controller Version 1.2, 00:00:00:00:00:00 eth1: Running with NAPI enabled eth1: 256/256 RX/TX BD ring size eth2: Gianfar Ethernet Controller Version 1.2, 00:00:00:00:00:00 eth2: Running with NAPI enabled eth2: 256/256 RX/TX BD ring size The MACs are all 00 here. The PHY drivers don't get registered. (What happened to CONFIG_NETDEV_1000 in the newer kernels?) How is your mileage? Next round... tomorrow, regards, Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: how to improve linux tcp/ip(UDP) efficiency on mpc8541 833Mhz.
[EMAIL PROTECTED] schrieb: hi,everbody: I have run linux-2.6.15 on my mpc8541 custom board. but when i test TSEC use UDP, i found it's efficinecy is lower. my test enviroment: i only run a UDP recieve program and not to handle data recieved. when i recevie 400Mbps data, 79% of MPC8541 have be consumed. so i think tcp/ip protocal have consume my mpc8541 resource. i dont know how to improve tcp/ip code or TSEC driver(gianfar.c). can somebody help me ? Hmm... you should first try one of the current kernels and check the performance there. For further details about linux networking, I recommend you to contact the guys at the netdev list, giving lots of details how you do your benchmarking and how your workload looks like. Regards, Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 85xx Device tree problems: e0024520:02 not found
robert lazarski schrieb: Hi all, I'm trying to bring up a new 8548 board on 2.6.23.1 . When booting, Some times I can get as far mounting over nfs. However, it gets stuck here: NET: Registered protocol family 1 NET: Registered protocol family 17 e0024520:02 not found eth2: Could not attach to PHY IP-Config: Failed to open eth2 IP-Config: Device `eth2' not found. As already written in the u-boot-users list, you could give the pauilis.git tree a try. There have been recently (last month) several PHY related changes. 2.6.23.1 seems to be too old. Regards, Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: While booting montavista kernel for PPC sometimes Kernel Panic occurs
Misbah khan schrieb: Hi all... Please find the print message when kernel panic occured while booting the Montavista kernel for PPC. This happens rarely and i am not able to find the real cause of it Please do suggest me how to debug it and the cause of it . I suggest you to ask Montavista support about their kernels or use a standard vanilla kernel. Regards, Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH] add cuImage comment for 'make help'
It just take some time to figure out that there is no make cuImage for the embedded powerpc stuff when you want to embed the OF device tree into the target. You have to use 'make zImage' instead. The following patch adds a comment to the platform specific 'make help' section. Signed-off-by: Clemens Koller [EMAIL PROTECTED] --- arch/powerpc/Makefile~ 2007-10-12 18:43:44.0 +0200 +++ arch/powerpc/Makefile 2007-11-06 21:27:59.0 +0100 @@ -159,6 +159,8 @@ $(BOOT_TARGETS): vmlinux define archhelp @echo '* zImage - Compressed kernel image (arch/$(ARCH)/boot/zImage.*)' + @echo 'Use this target also when you want to build a cuImage' + @echo 'with an embedded OF device tree.' @echo ' install - Install kernel using' @echo '(your) ~/bin/installkernel or' @echo '(distribution) /sbin/installkernel or' ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: tiny login: useradd command
pjmaiya schrieb: Hi, I am using montavista linux. Then, please ask their support, when they charge a 5 number USD amount as part of their license/support model. (That's what I've been told this week.) Using TCT tool i have added package for user creation. I am having following problem * If I use tiny login package, I will be getting useradd binary but number of parameter are few like Usage: adduser [OPTIONS]... USER Options: -h directoryspecify home directory -s shellspecify shell -g gecosspecify GECOS string * If I don't use tiny login package, I will be selecting useradd package from admin menu. But I am unable to execute this command since it gives follwing error /usr/sbin/groupadd missing.. * Actually I want useradd command similar to linux where more argument are taken, especially I wanted 'user' to be part of more than one group. can anyone help me out.. I would just take useradd/groupadd from the Shadow password file utilities. Regards, Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: random panic and freezes on mpc8349 itx
Hi, Nicolas! Nicolas Schichan schrieb: Hi, I am currently working with an MPC8349ITX board and I have some trouble with the kernel as soon as it reaches userland. If I boot the kernel with all the memory (256MB) available (no mem=... on the command line), I get random freezes or random kernel panics. Some times it won't even run init. Some times it will panic badly if I try to put some pressure to the system (stress --cpu 256). Some times it will hang immediately after logging in, ... Just some ideas how I prefer to roughly track down random crashes: Check if the problems dependend of supply voltages, grounding or temperature. Mounting a prototype to an aluminum board improved uptime a lot in one case. If you don't see any variations at all, I would guess it's a problem caused by software. If I boot the kernel with mem=64M, these freeze and random panic disapear and I am able to run the stress program without any problems. I have had this strange behaviour on both kernel 2.6.20 and 2.6.22 with mpc834x_itx_defconfig (both from kernel.org) (ARCH=powerpc). I am inclined to say that it is not a broken RAM chip problem because if I use a 2.6.17 from kernel.org with all the RAM available (ARCH=ppc) configured with mpc834x_sys_defconfig (there was no defconfig for the itx board on this version) everything runs fine and I am able to run the stress program without any problems. Hmm... check the cpu/memory timing manually (by dumping some registers) and compare. The two ARCHitectures might do things quite different in the meanwhile. Otherwise, if you can stay within one ARCH, git bisect might be your friend here. Regards, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Thanks and new problems
schardt schrieb: First, many many thanks to Grant. My VirtexII Demo Board ist running a 2.6. Linux :)) But now, i switched to a Virtex4-Board with Ethernet (Mini Module from Avnet) This will i used in my application, if i can handle it. :) Linux is up and running, the ethernet is detected as eth0, link led is on but, and thats the problem, speed negotiating das not work. Check the PHY configuration (i.e. the bootstrap pins on the PHY). And - if appropriate - read out the PHY configuration (MDIO) and see if it's correct. Regards, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: little endian page mapping on PQ3
Hi, Jose! Jose Almeida schrieb: Hi all, Looking at PQ3 documentation, it looks like there is a way to select on a page basis if we would like to map one particular page in BIG or LITTLE endian. This is a very nice feature when you need to exchange some data between a PC and a PQ3 target. I would be interested, however cannot spend time right now to work on that subject. I am wondering if someone have already tryed this PQ3 feature ? I guess this would require some kind of hook in the kernel ... Just some random bits I found in the web: http://developer.apple.com/documentation/Hardware/DeviceManagers/pci_srvcs/pci_cards_drivers/PCI_BOOK.250.html The Interesting part is: Thus, the address swizzle is completely transparent to software. So, I would just try to setup some memory mapping and turn on little endian mode to access that area... MMMV. Just a guess. Regards, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Xilinx Virtex4 FX PPC
Hi, Robert, Josh Question 1: Do I need a special glibc for the Xilinx PPC 405 Does a normal PPC glibc have more advanced instructions compiled in that will not work on a Xilinx PPC 405?? Have a look at the eglibc project (embedded glibc) at http://www.eglibc.org I think they support all kind of soft-fp configurations. (i.e. The stuff seems to work fine on my MPC8540 e500 core with soft-fp) Make sure you're building glibc with soft-fp, or make sure you have CONFIG_MATH_EMULATION enabled in your kernel. The PPC 405 doesn't have an FPU. josh CONFIG_MATH_EMULATION fixed it!! What are the opinions out there? Kernel fp or glibc soft-fp?? AFAICT: soft-fp in (e)glibc. They should be faster / hopefully more optimized to your specific cpu. Regards, -- Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm-technology.com Phone: +49-89-741518-50 Fax: +49-89-741518-19 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Fedora 7 on a non FPU system
Hi, Michael! Michael Brian Willis schrieb: I'm trying to install a Fedora 7 Root File System on an MPC8540 based embedded system with a Denx 2.6.21 kernel. I have read the Denx Application note located at: http://www.denx.de/wiki/DULG/AN2007_03_InstallFC7OnSequoia. However this App. Note says that the instructions apply only to processors that have a full Floating Point Unit (FPU). My processor does not have an FPU and I believe that this is causing some system hangs. Yes, that won't work. You can either use FPU emulation or do the floating point stuff on the e500 core's SPE (Signal Processing Engine) which is AFAIK not supported by any major distribution. Has anybody every successfully installed Fedora(or another major distro) on a non-FPU system? CRUX - not a major distro, because it's targeted at experienced Linux users. I am running my selfmade version of embedded CRUX on my MPC8540 Boards based on http://cruxppc.sunsite.dk/wp/index.php which now fully supports the e500 core features. Or, does anybody know what is needed to get it working properly on a non FPU system? ... mentioned above. I bootstrapped the toolchain (binutils, (e)glibc, gcc and friends) from scratch. See: http://www.anagramm-technology.com/05_Services/FoxFactSheet.pdf Current versions: kernel 2.6.23-rc2, gcc-4.2.1, (e)glibc 2.5.1/2.6.1. Regards, -- Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm-technology.com Phone: +49-89-741518-50 Fax: +49-89-741518-19 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: reg : SM722 Linux driver
mahendra varman schrieb: Hi Members Iam in need of SM722 Linux driver source code for Linux 2.6 or for Linux 2.4 Help me to find the source code You will find Xfree86 drivers from Siliconmotion here: http://www.siliconmotion.com.tw/en/en2/download2c.htm And the siliconmotion driver of Xorg in it's git repository: http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-siliconmotion.git;a=summary I don't think there are in-kernel framebuffer drivers (tried the vesa ones?) for the SM722 (==Lynx3DM+), read the code. ;-) Regards, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Reboot Command Makes kernel to hang (MPC8560)
Hi, Ansari! Ansari schrieb: Hi Koller Kumar Thanks for ur reply. Is there a way to reset the full chip (MPC8560) whenever core reset occurs (using hardware or software) ?? I recommend you to have a look at i.e. the MPC8540ADS reference design (as an example, the 8560 should be similar) to see how the reset signals are realized. I didn't run into problems with the reset circuitry. u-boot resets my thing by issung a reset and linux does the same when I do a shutdown -r now or similar thing. Read the code at these places what's happening there. AFAICT this is not done by enabling the Watchdog and wait until it triggers. (Hence, that would be interesting to try...) In your case I would have a look at the ramdisk code to see where it/what fails in the first place. Regards, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Embedded linux FTP Server
khollan schrieb: Hey Im looking for a basic ftp server to run on my ML410 Xilinx board, I was looking on the net and couldn't find anything that stands out. Does anyone have suggestions, or know of something that works well. Thanks kholland netkit-ftp seems to be standard. I am using vsftp because it seems to be good for production. The http://vsftpd.beasts.org http://www.proftpd.org http://www.wu-ftpd.org are propably the well known/often used ones. And there are also tftp servers (trivial ftp)... if that's what you mean with basic. Just choose one from: http://crux.nu/portdb/?q=ftpa=search Regards, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Reboot Command Makes kernel to hang (MPC8560)
Hi, Ansari! Ansari schrieb: Hi Kumar, First of all thanks for ur reply . Even i went through the linux source . And i have observe that the reboot command used to hard reset the core . I have few doubts can u please clarify me. 1. Is there any way to reset the full chip with out using any external signal (MPC8560) ? (like any register that can be used for reseting the processor) I RTFM: It should be the bits RST[1:0] in the Debug Control Register 0 (DBCR0). I didn't find details how the external signals are affected: HRESET_REQ# and friends. The HRESET_REQ# is usually fed back to the CPU's HRESET#. So if the HRESET_REQ# gets asserted by writing to above registers it should really bring down the CPU, it's internal as well as it's external components, which are usually connected to a replication of that signal. However the existence of cpm2_reset() and a qe_reset() (QuiccEngine?) in the code tells me that the above expectations could be wrong. Would be nice to have that verified by some hardware guys from freescale... 2. Even same reboot command works fine for MPC8540 Processor ?. ...because it doesn't have a cpm ? 3. what are the factors that makes ramdisk hangs . When its uncompressing ? Well, side effects ? Regards, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Help required for porting ISP1362 usb device driver
Hello, Vikram! Vikram Kone schrieb: Hi.. I'm a linux newbie and im working on porting the USB driver ISP1362 by Philips on to my Freescale ppc board. Please don't crosspost. Please don't write HTML. I dont know how to do this... so if any of you can tell me how to do this step by step, i would be very grateful to you Few details.. I'm running RHEL with kernel 2.4.21 on a PC (i386 machine) Target Machine is MPC8548 CDS by Free scale (ppc architecture) running kernel version 2.6.11 Did you try something like: http://www.freescale.com/files/32bit/doc/app_note/AN3094.pdf?fsrch=1 I think it's one of these step by step things. (You should consider moving up to the latest Kernel which is 2.6.22.1 as of today. Nobody fixes bugs on that old kernel.) I do have a ppc tool chain, if that helps. What tool chain? but i dont know how to use it Did you read the documentation? What problem do you have? P.S. I downloaded the deive driver and host controller drivers from sourceforge.net and both of them seem to work for 2.6.6 kernel for i386 arch .. Fine! P.P.S : Wolfgang ??!1 Can you help me out... I went through the archives on the list and seems thatu answered many Qs on this driver. But i didnt find any post specifcally for my problem..so Sorry, my crystal ball is broken. You didn't tell us any details about your problem. This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message. Oops... If I am not the intended recipient, please: /dev/null my mail. Regards, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Help required for porting ISP1362 usb device driver
Hello, Vikram! Vikram Kone schrieb: Hi.. I'm a linux newbie and im working on porting the USB driver ISP1362 by Philips on to my Freescale ppc board. Please don't crosspost. Please don't write HTML. I dont know how to do this... so if any of you can tell me how to do this step by step, i would be very grateful to you Few details.. I'm running RHEL with kernel 2.4.21 on a PC (i386 machine) Target Machine is MPC8548 CDS by Free scale (ppc architecture) running kernel version 2.6.11 Did you try something like: http://www.freescale.com/files/32bit/doc/app_note/AN3094.pdf?fsrch=1 I think it's one of these step by step things. (You should consider moving up to the latest Kernel which is 2.6.22.1 as of today. Nobody fixes bugs on that old kernel.) I do have a ppc tool chain, if that helps. What tool chain? but i dont know how to use it Did you read the documentation? What problem do you have? P.S. I downloaded the deive driver and host controller drivers from sourceforge.net and both of them seem to work for 2.6.6 kernel for i386 arch .. Fine! P.P.S : Wolfgang ??!1 Can you help me out... I went through the archives on the list and seems thatu answered many Qs on this driver. But i didnt find any post specifcally for my problem..so Sorry, my crystal ball is broken. You didn't tell us any details about your problem. This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message. Oops... If I am not the intended recipient, please: /dev/null my mail. Regards, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Help required for porting ISP1362 usb device driver
/hal_pci.c: In function 'isp1362_request_irq': /usr/src/linux-2.6.21.5/drivers/ISP1362_Device/x86pci/hal_pci.c:724: warning: passing argument 2 of 'request_irq' from incompatible pointer type Building modules, stage 2. MODPOST 3 modules CC /usr/src/linux-2.6.21.5/drivers/ISP1362_Device/device/devmscd/mscd.mod.o LD [M] /usr/src/linux-2.6.21.5/drivers/ISP1362_Device/device/devmscd/mscd.ko CC /usr/src/linux-2.6.21.5/drivers/ISP1362_Device/device/pdc/pdc.mod.o LD [M] /usr/src/linux-2.6.21.5/drivers/ISP1362_Device/device/pdc/pdc.ko CC /usr/src/linux-2.6.21.5/drivers/ISP1362_Device/x86pci/hal_pci.mod.o LD [M] /usr/src/linux-2.6.21.5/drivers/ISP1362_Device/x86pci/hal_pci.ko make[1]: Leaving directory `/usr/src/linux-2.6.21.5' [EMAIL PROTECTED]:/usr/src/linux-2.6.21.5/drivers/ISP1362_Device$ make make -C /usr/src/linux-2.6.21.5/drivers/ISP1362_Device/device/diskemu make[1]: Entering directory `/usr/src/linux-2.6.21.5/drivers/ISP1362_Device/device/diskemu' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/usr/src/linux-2.6.21.5/drivers/ISP1362_Device/device/diskemu' make -C /usr/src/linux-2.6.21.5 M=/usr/src/linux-2.6.21.5/drivers/ISP1362_Device make[1]: Entering directory `/usr/src/linux-2.6.21.5' CC [M] /usr/src/linux-2.6.21.5/drivers/ISP1362_Device/x86pci/hal_pci.o /usr/src/linux-2.6.21.5/drivers/ISP1362_Device/x86pci/hal_pci.c: In function 'isp1362_request_irq': /usr/src/linux-2.6.21.5/drivers/ISP1362_Device/x86pci/hal_pci.c:724: warning: passing argument 2 of 'request_irq' from incompatible pointer type Building modules, stage 2. MODPOST 3 modules CC /usr/src/linux-2.6.21.5/drivers/ISP1362_Device/device/devmscd/mscd.mod.o LD [M] /usr/src/linux-2.6.21.5/drivers/ISP1362_Device/device/devmscd/mscd.ko CC /usr/src/linux-2.6.21.5/drivers/ISP1362_Device/device/pdc/pdc.mod.o LD [M] /usr/src/linux-2.6.21.5/drivers/ISP1362_Device/device/pdc/pdc.ko CC /usr/src/linux-2.6.21.5/drivers/ISP1362_Device/x86pci/hal_pci.mod.o LD [M] /usr/src/linux-2.6.21.5/drivers/ISP1362_Device/x86pci/hal_pci.ko make[1]: Leaving directory `/usr/src/linux-2.6.21.5' Quick and dirty patch attached below... Give it a try and publish your results (also to the list!) Anybody who wants to see this in mainline? It would be good to pick up *now*! For sure it needs more clean up... Regards, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com diff -Nurp ISP1362_Device/Makefile ISP1362_Device.fixed/Makefile --- ISP1362_Device/Makefile 2006-09-25 11:37:29.0 +0200 +++ ISP1362_Device.fixed/Makefile 2007-07-13 22:04:53.0 +0200 @@ -1,5 +1,5 @@ TOPDIR=$(shell pwd) -KERNEL_DIR=/usr/src/linux-2.6.6 +KERNEL_DIR=/usr/src/linux-2.6.21.5 export $(KERNEL_DIR) obj-m += x86pci/ diff -Nurp ISP1362_Device/device/devmscd/devmscd.c ISP1362_Device.fixed/device/devmscd/devmscd.c --- ISP1362_Device/device/devmscd/devmscd.c 2006-09-25 11:32:21.0 +0200 +++ ISP1362_Device.fixed/device/devmscd/devmscd.c 2007-07-13 22:08:48.0 +0200 @@ -32,10 +32,6 @@ * ***/ -#include linux/config.h -#ifdef LINUX_24 -#defineMODULE -#endif #include linux/types.h #include linux/string.h #include linux/kernel.h @@ -50,20 +46,14 @@ #include linux/module.h #include linux/vmalloc.h #include linux/init.h -#ifdef LINUX_24 -#include linux/tqueue.h -#else #include linux/workqueue.h -#endif #include asm/byteorder.h #include asm/irq.h -#include asm/segment.h #include asm/io.h #include linux/proc_fs.h #include linux/poll.h - #include pdc_intf.h #include devmscd.h #include mscdbridge.h diff -Nurp ISP1362_Device/device/devmscd/msbridge.c ISP1362_Device.fixed/device/devmscd/msbridge.c --- ISP1362_Device/device/devmscd/msbridge.c2006-09-25 11:32:21.0 +0200 +++ ISP1362_Device.fixed/device/devmscd/msbridge.c 2007-07-13 22:09:46.0 +0200 @@ -30,17 +30,12 @@ * 09/25/06MMASBAD Released with GPL * ***/ -#include linux/config.h -#ifdef LINUX_24 -#defineMODULE -#endif #include linux/module.h #include linux/pci.h #include linux/kernel.h #include linux/delay.h #include linux/ioport.h #include linux/sched.h -#include linux/devfs_fs_kernel.h #include linux/slab.h #include linux/smp_lock.h #include linux/errno.h Binary files ISP1362_Device/device/diskemu/msdisk and ISP1362_Device.fixed/device/diskemu/msdisk differ diff -Nurp ISP1362_Device/device/pdc/pdc_bus.c ISP1362_Device.fixed/device/pdc/pdc_bus.c --- ISP1362_Device/device/pdc/pdc_bus.c 2006-09-25 11:32:22.0 +0200 +++ ISP1362_Device.fixed/device/pdc/pdc_bus.c 2007-07-13 22:11:04.0
Re: Porting kernel 2.6.11 to WindRiver board.
linuxdev schrieb: I have to port a linux kernel to Motorola MPC 7447 based WindRiver SBC 7447 board. The MPC7447 is one of the G4+ PowerPC processor series. You shouldn't run into much issues to get Linux running on it. A good start can be to use the latest ELDK from http://www.denx.de. I created a native PowerPC environment for embedded use based on the latest CRUX linux distribution (http://cruxppc.sunsite.dk). CRUX is also available for x86 (http://crux.nu) which is nice to work completely platform independent. I plan to use Kernel 2.6.11 and Uboot for the same. It doesn't make sense to use an older than the latest Kernel because nobody wants to help you in case you run into problems. Use the latest linux git tree. (or at least some 2.6.22) And use the latest U-Boot git tree. (also from denx) I wanted to know whether these two can be used for the board. Also how do I get hold of a BSP for this board and kernel? Are there any information resources for the same? It's all available in the web. It depends on your hardware setup how complicated your porting might be. I hope you good good documentation for it. If you have a Harddisk to boot from or some network interface, porting it might be as simple as installing some x86 platform. Thanks in advance... LinuxDev. Please use your real name. Regards, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MPC8540 DMA transfer
Hello, Ansari! Ansari schrieb: Hello Koller, Is there any support for dma transter in linux 2.4.x kernel . Whether u have any source code for tht ?. I think u have attached a dma driver code for 2.6.x kernel . But i need it for 2.4 kernel. ( Processor : MPC8540 / MPC8560 ) There are no new features going into kernel 2.4.x. Development has stopped long time ago. Have a look at the available code and backport it to 2.4 (YMMV). But you propably want to move to the latest 2.6. The MPC8540 is supported very well. If you want to have new features implemented, use the latest 2.6.x tree from Linus. Don't ride dead horses! Regards, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Mem-2-Mem DMA - Generalized API
Clifford Wolf schrieb: On Mon, Jun 25, 2007 at 08:01:10PM +0200, Clifford Wolf wrote: I've put a 'draft header file' of an api as I would have expected it online: [...] Ok, so here comes the first implementation: (I also have other projects, so it took a while.. ;-) http://www.clifford.at/priv/dmatransfer-20070704.diff This is just for the MPC8349 DMA now, registers are still hardcoded in the driver instead of beeing taken from the platform files and support for scatter-gather is still missing and the Kconfig integration isn't checking if we are building for the mpc8349 (or even ppc) yet. But I think the direction of the API is pretty clear. That looks good. It should be useful on other PowerQUICC's DMA engines and maybe even for the MPC5200 BestComm, too, with some changes. The patch also contains a hackish demo client (dma_demo_client.ko) which is performing some dma transfers in the 256th MB of physical memory. So it should only be used on a machine with 256MB of memory bootet with mem=255M (but changing that should be trivial). The demo client shows well how the API works and how much overhead the API adds. Any feedback this time? Sorry, I'm currently busy with some hardware design work. But if you want to test some code, I can get you an SSH account on my MPC8540 platform. Best regards, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Mem-2-Mem DMA - Generalized API
Hello, Matt! Matt Sealey schrieb: IOAT and Intel's DMA engine driver is very IOAT specific in places.. I had a peek at it as I have a little interest in the concept; at least the two platforms Genesi has been supporting (Pegasos and Efika) have quite competant DMA engines which are woefully underused (i.e. not at all). True. There exists a Marvell DMA driver somewhere (I have a copy, someone on this list posted it about a year ago) and while the MPC5200B doesn't have explicit support for DMA from memory to memory (although memory to SRAM might work in chunks, or memory to a FIFO wired as a loopback like in the docs..??) There is so much you can do with most SoC DMA controllers, and it's not even limited to PowerPC (most ARM/XScale SoCs have very capable devices inside too). I can only imagine that nobody got excited over IOAT because the entire programming interface stinks of offloading gigabit ethernet and not much else. The main question remains: Is it possible to have a flexible cross platform DMA API which handles even complex requests and does scheduling, prioritizing, queuing, locking, (re-)building/caching of SG lists... automagically. It could fall back to CPU's memcpy if the hardware doesn't have the ability to use the DMA machine because all channels are already busy, or the requested memory isn't DMAable or the request is just too small that it doesn't make sense to setup a DMA channel. Filling memory with zero is also a simple task for a DMA engine. (Thinking about malloc() and memset()) The problem is IMHO similar to video acceleration. Within the Xorg's XAA/EXA/whatever framework, the drivers accelerate certain calls if the hardware has the capability to do so. Other calls fall back to some default non accelerated memcpy() friends. Sounds like a lot of fun... replacing kernel's and libc's memcpy() with memcpy_with_dma_if_possible(). :-) Best regards, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: General question on upgrading Linux version
Hello, Bizhan! Bizhan Gholikhamseh (bgholikh) schrieb: Hi All, We are using MPC8541 processor from freescale. Our current kernel version is based on 2.6.11 plus some patches provided by Freescale. I would like to update our Kernel version to a more recent version. I am not sure about the exact versions but you propably need to switch over from devfs to udev. (usually no big deal) I would greatly appreciate if you could provide me with some general guideline on how to proceed . I follow the latest stable and latest-git from kernel.org. I didn't run into major problems over here for MPC8540, however I am still on the old ARCH=ppc. ARCH=powerpc compiles fine as well. I just had no time to have a closer look at the DeviceTree/OpenFirmware/U-Boot stuff. Is there any brief HowTo migrate from ppc to powerpc including u-boot? Best greets, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: silicon motion sm502 or sm501
Hello, Pete! pete c schrieb: Hi , im looing for a silicon motion sm501 or sm502 pci voyager gx demo board. Try to get the newer SM502 one. Avoid the older SM501-AA revision. I saw a message of yours on a news group, do you know where i can get one of these, or do you have one i can buy from you? I have a board here. It's still in use, so we don't sell it (yet). We have a few SM501GX08LF00-AB (8MB Mem on Chip, Lead Free, Rev. AB) in stock. If you need some samples, feel free to contact me off list. Otherwise, ask Silicon Motion for your local Silicon Motion Distributor. Then ask the Distributor... In Germany, a SMI Distributor is HY-LINE: http://www.hy-line.de/ Regards, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MPC8560 Gianfar driver hangs after soft reboot
Hello, Bill! Bill Farrow schrieb: On 25 May 2007 Clemens Koller wrote: Bill Farrow schrieb: The Gianfar driver is hanging during boot-up after a soft reboot. It works fine when the board is power cycled. Any hints on where to look further on this issue? I have had some rare issues with PHY initialization on the PM854 with the u-boot-1.2.0 not being able to download something via TFTP. There is an entry somewhere in the U-Boot wiki (I think) that the TQM8540 board can have some issues... well the boards are quite similar. Pushing the reset button (Never needed to power that off) solves the issue. We have found a work around for this problem: If the network interfaces are disabled before doing a soft reboot then everything works properly. We are using the ramdisk from the ELDK 4.1 and are no rc scripts for busybox to call to shutdown the network interfaces before rebooting. We will just add our own script to do this when rebooting. Something like: /sbin/ip route del default /sbin/ip link set eth0 down /sbin/ip addr del 192.168.1.200/24 dev eth0 (or something similar using the ifconfig foo) Or how do you define to shutdown the network interfaces? I guess I am lucky that I always had rc scripts running on my system. (native distribution on harddisk, based on http://crux.nu ) Agreed. I did look at some future kernel versions to see what changes had been made to the gianfar source code, but your right, we should try some out on the actual hardware. Yup, there were lots of changes, also in the PHY/MII interface. We are using the Microsys carrier board with the PM856 module and has been quite stable. Same over here. It's good stuff! Best greets, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: ML403 2.6 kernel, root file system on NFS, stops after freeing unused kernel memory
Hi, Mohammed! Mohammad Sadegh Sadri schrieb: ok! problem solved problem was kernel command line mine was: CONFIG_CMDLINE=console=ttyS0,9600 console=tty0 root=/dev/nfs rw nfsroot=10.10.10.10:/home/sadri/hdl/eldk_rootfs/ppc_4xx ip=dhcp by default 2.6.21 CMDLINE contains two console parameters, the correct one should be CONFIG_CMDLINE=console=ttyS0,9600 root=/dev/nfs rw nfsroot=10.10.10.10:/home/sadri/hdl/eldk_rootfs/ppc_4xx ip=dhcp well , rootfs comes up until login prompt, I enter root as the password but it gives incorrect login message/ I have had the same symptoms. Some device node was missing. I guess it was something like: crw--w--w- 1 root tty 5, 1 May 1 09:30 console crw-rw-rw- 1 root tty 5, 0 May 27 10:14 tty Also check -8- # # /etc/securetty: defines which devices root can log in on # console ttyS0 tty1 tty2 tty3 tty4 tty5 tty6 # End of file -8- Greets, Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm-technology.com Phone: +49-89-741518-50 Fax: +49-89-741518-19 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MPC8560 Gianfar driver hangs after soft reboot
Hi, Bill! Bill Farrow schrieb: The Gianfar driver is hanging during boot-up after a soft reboot. It works fine when the board is power cycled. Any hints on where to look further on this issue? I have had some rare issues with PHY initialization on the PM854 with the u-boot-1.2.0 not being able to download something via TFTP. There is an entry somewhere in the U-Boot wiki (I think) that the TQM8540 board can have some issues... well the boards are quite similar. Pushing the reset button (Never needed to power that off) solves the issue. 3. After rebooting, the system starts up Linux and it hangs after: eth0: Gianfar Ethernet Controller Version 1.2, 00:40:42:01:00:00 eth0: Running with NAPI enabled eth0: 256/256 RX/TX BD ring size The Kernels I 've tried (2.6.13 up to 2.6.21-rc5 and some latest gits) never stopped there... I would just try another kernel. Checkout the code in the latest git. Also tried soft rebooting without the network cable and the kernel boots without hanging, but the network does not work when the re-connected. The PHY seems to be working because when we plug the cable back in it detects the link and writes this console message: [ 1557.465085] PHY: 0:01 - Link is Up - 100/Full Note that there are two Ethernet controllers on the board (eth0 and eth1). Only eth1 is connected to the network. What PHY's do you have on these ports? (MV88E over here) Background info: Kernel version 2.6.20.4 PPC Uboot version 1.2.0 Busybox version 1.5.0 ELDK: 4.1 JTAG: BDI-2000 Board : Microsys PM856 - with MPC8560 processor. Looks good. I am using the PM854. Well, some other thing: I had some instabilities on my prototyping hardware in the beginnging, but I guess due to EMI and the sloppy setup. After I got all the stuff nailed down onto some aluminum-plate, the boards is working _very_ stable (24/7). Greets, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Latest GCC/GLIBC working combo for a Linux 2.4.x kernel?
Hi, Sasvata! We are using a RHEL/386 machine to cross-compile for Debian/PowerPC (8260) target, a few year old embedded system that we inherited. The kernel is 2.4.9. Using crosstools, and following Dan Kegel's notes, the combo we have is gcc-2.95-3/glibc-2.2.5. Does anybody have any working version using newer versions of the 2.4 kernel and newer GCC versions for a powerpc-603e target? One motivation is to use BusyBox-1.5.1, but I am told on that list that GCC 2/x is too old (I tried before I asked, it doesn't compile). It's propably painful to work your way through crosstools with such an old toolchain. I would have a look if one of the ELDK's from http://www.denx.de can be used for your board - at least for a good start. If you run into problems with older linux-2.4 kernel version with the newer ELDK's, you can also go back to some older version? Any help, pointers, example config files for crosstools, etc. would be really appreciated! You are always welcome at their mailing list. See: http://kegel.com/crosstool Best greets, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: I2C support for 8541
Hi, Charles! Charles Krinke schrieb: Assuming I have the external IRQ's understood, the next issue is the hardware clock on our board with the linux-2.6.17.11 kernel. We are using a DS1338U, which is an I2C RTC. The I2C RTC drivers have changed in the latest kernels. You might consider to update to some current 2.6.20+ kernel. On one of my mpc8540's I get my RTC working right out of the box with an unpatched vanilla kernel! :-) Greets, -- Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Power management for ppc 85xx
Hello, Kumar, Hi, Marta! Glad I managed to make sense. I checked the hardware spec on the board and it looks like we're using everything, apart from the SEC and maybe the stand-alone I2C (I think we're just using the one within the CMP). By the way, I made a mistake and the actual processor on the board is the cut-down 8541, not the 8555. My apologies for that. This morning I added some printks and confirmed that there is no code behind pm_ops, so my question remains: is there some code out there that I can use? (hope so, otherwise I'm doomed...) I'm sorry to say you're doomed. I don't believe anyone's spent any time trying to do pwr mgmt on 85xx. I am working with the MPC8540 in a mobile product and some power saving would be fine to use. But I haven't seen any power management code for that thingy in the kernels at all. So, there is some work left there. Maybe I will have a closer look in the future. According to some tests of a board manufacturer, the cpu doesn't power down very much, when you stop some peripherals or send the core to nap. But I wasn't able to confirm that yet. Best greets, Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm-technology.com Phone: +49-89-741518-50 Fax: +49-89-741518-19 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Perl
Hello, Lee! Lee Revell schrieb: I've been trying to cross compile Perl for a PPC440 board and it just isn't happening. Perl is probably the least amenable application to cross compiling I've found. I tried the instructions in the Cross/ directory of the Perl distro but they don't work - sh Configure fails on my target because it expects a full C development environment, which won't fit. Is there any easy solution? Can someone send me a binary? I don't know much about the ppc440 and it's core. But maybe you can use mine?! I am using perl successfully on a MPC8540 CPU which has an e500 core w/o an FPU. I don't need to cross compile and it comes with only the necessary dependencies: $ prt-get deptree perl -- dependencies ([i] = installed, '--' = seen before) [i] perl [i] db [i] gdbm all that on top of glibc-2.3.4 If you want to try those three tar.gz's please contact me off list and I can send it to you. It's also possible to recompile that stuff to a different ppc target... Greets, Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm.de Phone: +49-89-741518-50 Fax: +49-89-741518-19 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Toolchain to 'use' u-boot (was: Re: Please give your feedback)
Hi, Manjunath! Please add a proper subject to your postings next time. 1. I am using toolchain which support u-boot 1.1.1 and i could not get toolchain that support u-boot 1.1.3 and above in the net as well as in Freescale site, Please suggest me where i can download the toolchain to use u-boot1.1.3 http://www.denx.de - ELDK but any other properly configured current toolchain should be able to compile u-boot. For questions regarding u-boot, please see the dedicated mailing list. Google should be able tell you all that, too. Greets, Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm.de Phone: +49-89-741518-50 Fax: +49-89-741518-19 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
OT: Re: [U-Boot-Users] Status of OF in TQM8540 and linux-2.6.17.11
Hello, Wolfgang! - moving from u-boot-users to linuxppc-embedded Wolfgang Denk wrote: In message [EMAIL PROTECTED] you wrote: Now I try to boot a current linux kernel - the vanilla 2.6.17.11 with the default tqm8540 config but it doesn't show any sign of life Please use the kernel from our repo instead; see http://www.denx.de/cgi-bin/gitweb.cgi?p=linux-2.6-denx.git Okay, the compilation after a make TQM8540_defconfig fails: [EMAIL PROTECTED]:~/git/linux-2.6-denx$ make uImage CHK include/linux/version.h CHK include/linux/utsrelease.h SYMLINK include/asm - include/asm-ppc CHK include/linux/compile.h CC arch/ppc/syslib/mpc85xx_devices.o In file included from arch/ppc/syslib/mpc85xx_devices.c:23: include/asm/cpm2.h:1193:1: warning: FCC2_MEM_OFFSET redefined include/asm/cpm2.h:1192:1: warning: this is the location of the previous definition arch/ppc/syslib/mpc85xx_devices.c:99: error: `F1_RXCLK' undeclared here (not in a function) arch/ppc/syslib/mpc85xx_devices.c:99: error: `F1_TXCLK' undeclared here (not in a function) arch/ppc/syslib/mpc85xx_devices.c:99: error: initializer element is not constant arch/ppc/syslib/mpc85xx_devices.c:99: error: (near initialization for `mpc85xx_fcc1_pdata.clk_route') arch/ppc/syslib/mpc85xx_devices.c:100: error: initializer element is not constant arch/ppc/syslib/mpc85xx_devices.c:100: error: (near initialization for `mpc85xx_fcc1_pdata.clk_trx') arch/ppc/syslib/mpc85xx_devices.c:117: error: `F2_RXCLK' undeclared here (not in a function) arch/ppc/syslib/mpc85xx_devices.c:117: error: `F2_TXCLK' undeclared here (not in a function) arch/ppc/syslib/mpc85xx_devices.c:117: error: initializer element is not constant arch/ppc/syslib/mpc85xx_devices.c:117: error: (near initialization for `mpc85xx_fcc2_pdata.clk_route') arch/ppc/syslib/mpc85xx_devices.c:118: error: initializer element is not constant arch/ppc/syslib/mpc85xx_devices.c:118: error: (near initialization for `mpc85xx_fcc2_pdata.clk_trx') arch/ppc/syslib/mpc85xx_devices.c:135: error: `F3_RXCLK' undeclared here (not in a function) arch/ppc/syslib/mpc85xx_devices.c:135: error: `F3_TXCLK' undeclared here (not in a function) arch/ppc/syslib/mpc85xx_devices.c:135: error: initializer element is not constant arch/ppc/syslib/mpc85xx_devices.c:135: error: (near initialization for `mpc85xx_fcc3_pdata.clk_route') arch/ppc/syslib/mpc85xx_devices.c:136: error: initializer element is not constant arch/ppc/syslib/mpc85xx_devices.c:136: error: (near initialization for `mpc85xx_fcc3_pdata.clk_trx') arch/ppc/syslib/mpc85xx_devices.c:138: error: `FCC3_MEM_OFFSET' undeclared here (not in a function) arch/ppc/syslib/mpc85xx_devices.c:138: error: initializer element is not constant arch/ppc/syslib/mpc85xx_devices.c:138: error: (near initialization for `mpc85xx_fcc3_pdata.mem_offset') make[1]: *** [arch/ppc/syslib/mpc85xx_devices.o] Error 1 make: *** [arch/ppc/syslib] Error 2 Are there any tipstricks to consider regarding that point? Yes, use a working kernel. Not all our patches have been accepted upstream, and we have some lag with re-submissions. According to TQC, the latest working kernel was a 2.6.15-git from your (denx) tree. I get the details from Mr. [EMAIL PROTECTED] and see how far I can get. Okay, let's move over to linux-ppc-embedded. (xposting) Best greets, Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm.de Phone: +49-89-741518-50 Fax: +49-89-741518-19 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [U-Boot-Users] OT: Re: Status of OF in TQM8540 and linux-2.6.17.11
Hi, Wolfgang! Success! The upper defines need to reside in the board-specific code for tqm as well as for other boards utilizing such scheme (see platforms/85xx/mpc85xx_ads_common.h for instance). Thanks for pointing out. Clemens, plese try again (commit id cd4ebbc9b95434977e5f182b9a22d7d1de0748ce) Jup, that works! Just for the records: As of Sept 05 2006, U-Boot 1.1.4-gf60ba0d3 and linux-2.6-denx-cd4ebbc9b (aka: 2.6.18-rc5-git) is known to boot on the TQM8540 + STK85XX in the default configurations. Thank you! Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm.de Phone: +49-89-741518-50 Fax: +49-89-741518-19 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
OT: Re: [U-Boot-Users] Status of OF in TQM8540 and linux-2.6.17.11
Hello, Wolfgang! - moving from u-boot-users to linuxppc-embedded Wolfgang Denk wrote: In message 44FD5BD4.9090406 at anagramm.de you wrote: Now I try to boot a current linux kernel - the vanilla 2.6.17.11 with the default tqm8540 config but it doesn't show any sign of life Please use the kernel from our repo instead; see http://www.denx.de/cgi-bin/gitweb.cgi?p=linux-2.6-denx.git Okay, the compilation after a make TQM8540_defconfig fails: clemens at ecam:~/git/linux-2.6-denx$ make uImage CHK include/linux/version.h CHK include/linux/utsrelease.h SYMLINK include/asm - include/asm-ppc CHK include/linux/compile.h CC arch/ppc/syslib/mpc85xx_devices.o In file included from arch/ppc/syslib/mpc85xx_devices.c:23: include/asm/cpm2.h:1193:1: warning: FCC2_MEM_OFFSET redefined include/asm/cpm2.h:1192:1: warning: this is the location of the previous definition arch/ppc/syslib/mpc85xx_devices.c:99: error: `F1_RXCLK' undeclared here (not in a function) arch/ppc/syslib/mpc85xx_devices.c:99: error: `F1_TXCLK' undeclared here (not in a function) arch/ppc/syslib/mpc85xx_devices.c:99: error: initializer element is not constant arch/ppc/syslib/mpc85xx_devices.c:99: error: (near initialization for `mpc85xx_fcc1_pdata.clk_route') arch/ppc/syslib/mpc85xx_devices.c:100: error: initializer element is not constant arch/ppc/syslib/mpc85xx_devices.c:100: error: (near initialization for `mpc85xx_fcc1_pdata.clk_trx') arch/ppc/syslib/mpc85xx_devices.c:117: error: `F2_RXCLK' undeclared here (not in a function) arch/ppc/syslib/mpc85xx_devices.c:117: error: `F2_TXCLK' undeclared here (not in a function) arch/ppc/syslib/mpc85xx_devices.c:117: error: initializer element is not constant arch/ppc/syslib/mpc85xx_devices.c:117: error: (near initialization for `mpc85xx_fcc2_pdata.clk_route') arch/ppc/syslib/mpc85xx_devices.c:118: error: initializer element is not constant arch/ppc/syslib/mpc85xx_devices.c:118: error: (near initialization for `mpc85xx_fcc2_pdata.clk_trx') arch/ppc/syslib/mpc85xx_devices.c:135: error: `F3_RXCLK' undeclared here (not in a function) arch/ppc/syslib/mpc85xx_devices.c:135: error: `F3_TXCLK' undeclared here (not in a function) arch/ppc/syslib/mpc85xx_devices.c:135: error: initializer element is not constant arch/ppc/syslib/mpc85xx_devices.c:135: error: (near initialization for `mpc85xx_fcc3_pdata.clk_route') arch/ppc/syslib/mpc85xx_devices.c:136: error: initializer element is not constant arch/ppc/syslib/mpc85xx_devices.c:136: error: (near initialization for `mpc85xx_fcc3_pdata.clk_trx') arch/ppc/syslib/mpc85xx_devices.c:138: error: `FCC3_MEM_OFFSET' undeclared here (not in a function) arch/ppc/syslib/mpc85xx_devices.c:138: error: initializer element is not constant arch/ppc/syslib/mpc85xx_devices.c:138: error: (near initialization for `mpc85xx_fcc3_pdata.mem_offset') make[1]: *** [arch/ppc/syslib/mpc85xx_devices.o] Error 1 make: *** [arch/ppc/syslib] Error 2 Are there any tipstricks to consider regarding that point? Yes, use a working kernel. Not all our patches have been accepted upstream, and we have some lag with re-submissions. According to TQC, the latest working kernel was a 2.6.15-git from your (denx) tree. I get the details from Mr. Becher at TQC and see how far I can get. Okay, let's move over to linux-ppc-embedded. (xposting) Best greets, Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm.de Phone: +49-89-741518-50 Fax: +49-89-741518-19
MPC8540 experience
Hello, Mark! Sorry, for my late reply, I wasn't reading the mailing lists for a while because I am pretty busy with hardware development. Hallo Herr Koller, ich habe heute ihre EMail (http://ozlabs.org/pipermail/linuxppc-embedded/2004-October/015851.html) gelesen. Hatten sie bereits Erfolg? Ich habe ein ?hnliches Problem. Wir beutzen bei uns ebenfalls einen PPC und haben das Problem mit Big und Littel-Endian im XServer. English, please. You are looking for the SM501 graphics controller working on the PCI Bus on the MPC8540 as far as I got your mail. Yes, the last status I got is that the endianess is an issue for the X-server if the SM501 is on PCI. However there are patches for the framebuffer/X driver environment which takes care about the RGBA's somewhere out there. There are also accelerated native X drivers available but I haven't used those. Additionally, we have the option to swap the colors in hardware, just in case anything goes wrong. :-) Have you seen the work done at Denx (www.denx.de) with the MPC5200 and SM501? Yes. But AFAIK they have the SM501 on the Local Bus of the MPC5200 which is a different thing. Check their hardware documentation, if available. Maybe there are more updates in the meanwhile... Updates are very welcome. I will have to investigate that further if I come back to the software layer of my project. Best greets, Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm.de Phone: +49-89-741518-50 Fax: +49-89-741518-19
kernel 2.6.15-rc5-latest doesn't work anymore on mpc8540ads
Hello, I am just about to update my kernel from 2.6.13-rc7 which is working fine to linus' 2.6.15-rc5-latest git on my mpc8540ads flavored board. However, the kernel hangs pretty early after openpic: exit any ideas or a hint what's wrong there... before I start to debug deeper into the code? Thanks, Clemens -8- U-Boot 1.1.3 (Jun 23 2005 - 10:40:01) CPU: 8540, Version: 2.0, (0x80300020) Core: E500, Version: 2.0, (0x80200020) Clocks Configuration: CPU: 825 MHz, CCB: 330 MHz, DDR: 165 MHz, LBC: 82 MHz L1:D-cache 32 kB enabled I-cache 32 kB enabled Board: MicroSys PM854 PCI1: 32 bit, 66 MHz (compiled) I2C: ready DRAM: Initializing DDR: 256 MB FLASH: 32 MB L2:256 kB enabled In:serial Out: serial Err: serial Net: ENET0: PHY is Marvell 88ES (1410cc2) ENET1: PHY is Marvell 88ES (1410cc2) ENET2: PHY is LXT971 (1378e2) ENET0, ENET1, ENET2 Hit any key to stop autoboot: 0 ## Booting image at fe30 ... Image Name: Linux-2.6.15-rc5-g7116317d Created: 2005-12-16 15:30:40 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1394968 Bytes = 1.3 MB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... OK mpc8540ads_init(): exit id mach(): done MMU:enter MMU:hw init MMU:mapin MMU:setio MMU:exit setup_arch: enter setup_arch: bootmem mpc8540ads_setup_arch() arch: exit openpic: enter openpic: timer openpic: external openpic: spurious openpic: exit -8 -- Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm.de Phone: +49-89-741518-50 Fax: +49-89-741518-19
Help ! 2.6.14 kernel can't bring up
Hello, zjznliang! zjznliang wrote: Hi linuxppc-embedded? Hi , How to config the early printk in 2.6.14 linux configration??? Well... check the .config or the kernel sources for CONFIG_EARLY_PRINTK or CONFIG_WANT_EARLY_SERIAL Have a look at the bootup code of your board, where it's used. I would call the printk as soon as the serial ports are initialized. If that's too late, try to toggle some pin as early as possible. If that doesn't work, and if you have no more ideas of what to do, you might think about getting some hardware debugging tools. Best greets, -- Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm.de Phone: +49-89-741518-50 Fax: +49-89-741518-19
Help ! 2.6.14 kernel can't bring up
Hello, zjznliang! zjznliang wrote: And there is nothing output ,I thought that it was serial port fault. I checked my Linux configuration ,but found nothing . Check your kernel configuration. Have you tried to turn on early printk support in your kernel config? Linux might be booting already, but you just don't see it on your console. Good luck, -- Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm.de Phone: +49-89-741518-50 Fax: +49-89-741518-19
Getting Perl on Embedded Linux PowerPC
Hello, Russell! Russell McGuire wrote: I was attempting to get some ATM Tools compiled into the embedded PowerPC, and found I needed Perl installed on the target before I continue. So my question... Has anyone had any luck getting any version of Perl 5 or higher installed onto the file system. I am still running this over the NFS dev environment, and plan to remove it before final production, so space is of no concern at the moment. I was compiling and running Perl on my mpc8540 system (natively)... I haven't had any problems with that. $ perl --version This is perl, v5.8.6 built for ppc-linux - my (old) install log says: perl: wget ftp://.../perl-5.8.6.tar.gz tar ... less INSTALL rm -f config.sh Policy.sh sh Configure or sh Configure -de(for default installation) make make test and it should end up with something like: All tests successful. u=6.52 s=0.89 cu=415.95 cs=22.58 scripts=845 tests=87560 make[2]: Leaving directory `/home/clemens/build/perl-5.8.6' make[1]: Leaving directory `/home/clemens/build/perl-5.8.6' and finally: su - make install - Or perhaps a pre-compiled RPM that installs, that is built for PowerPC. Sorry, no rpm's over here. Which PowerPC? I am using DENX Linux 2.4.25 at the moment, with pretty much the default root file system that is provided. Should be no problem, I think. I started with that too, a long time ago. Give it a try. You just need make sure that you don't run out of coffee! ;-) Greets, -- Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm.de Phone: +49-89-741518-50 Fax: +49-89-741518-19
A question about the /dev/ide
Hello, Wang Baohua! FCG WANG Baohua wrote: Dear all: I had use the UPM of MPC8270 to create the device driver of my pcmcia CF card. Just an idea: There are IDE-to-CF adapters and PCI-IDE adapters with working drivers. (for evaluation) How to create the /dev/hda device nodes? I had only /dev/ide device nodes, I want to use command like mkswap /dev/hda4. When I use mkswap /dev/ide/host0/bus0/target0/lun0/part1p4, it shows the No such file or directory message. How can I create the right device nodes? thanks! man mknod? But maybe you want to read some more things about devfs, udev, ... /etc/devfsd.conf before you know what you are doing there? Well... all that depends on your kernel/system config a bit... Best greets, -- Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm.de Phone: +49-89-741518-50 Fax: +49-89-741518-19
New message about: Lost interrupt with promise20268 PCI-IDE chard onmpc8540_ads
Hello, KylongMu, Rune! (Please reply to the thread.) First I according Clemens Koller' suggestion : remove DMA part , but the result is no change. Okay, sorry if my 'workaround' (let's call it 'cheat') didn't do it for you... According Clemens Koller's message , I guess mabe the problem is on the hardware configuration. So I checked my schematics and arch/ppc/platforms/85xx/mpc85xx_ads_common.c at line 170 . The attached file is changed . After these , Lost interrupt appears on PCI1-Slot1 , but my PCI1-Slot2 shows no Lost interrupt the .config file is still without change . Another new problem is I can't mount it on , I attached the steps message of new operation. Please help me check it . To be honest, I didn't tell you that there are still issues with my mpc85xx_map_irq() and friends(). I didn't fix the table for my board yet as the official CR854 demo board has only on PCI slot and I just didn't care about proper IDSEL-IRQ mapping. The hardware add-on we design should be compatible to the ADS board (or to be precise to the default mpc8540_ads behaviour in the kernel) as much as possible, so there should be no need for a separate platform port. Rune Torgersen wrote : I have run a Silicon Image SiI0680 based card on a MPC8560ADS board without problems Yes, but AFAIK it's only 32bit/33MHz PCI and therefore not speedy enough for the things we want to achieve (100..200Mbyte+/sec). So, this problem with the PDC has to be fixed... but it will take some time. Best greets, Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm.de Phone: +49-89-741518-50 Fax: +49-89-741518-19
Lost interrupt with promise20268 PCI-IDE chard on mpc8540_ads platform!
Hi KylongMu! KylongMu wrote: Hi, all Please help solve this problem , or give me some advise . Thanks a lot ! Try to turn off DMA. It doesn't work yet AFAIK. I am using a PDC20269 on PCI on a MPC8540, too. See my .config file... I didn't focus on this problem yet. Let me know if you get it going. My board PM854 is similar to the MPC8540_ADS Best greets, Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm.de Phone: +49-89-741518-50 Fax: +49-89-741518-19 -- next part -- A non-text attachment was scrubbed... Name: .config.gz Type: application/octet-stream Size: 5090 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050912/2304b5cd/attachment.obj
Regarding the PPC board bringup with Linux 2.6 kernel
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, ... vinay hegde wrote: I do not have the board in my possesion. Actually, I am using the board through virtual network. Hence, I am unable to use any of the debugging techniques (JTAG, logic analyzer etc) except going through the source code and printing some messages. Then you depend on the console output at least. - early printk. Also, how do I enable early printk option? I did not find any such option under kernel configuration. i.e. if you use one of the latest 2.6 kernels, turn on Support for early boot texts over serial port (That's in in Kernel hacking) Verify your console settings twice. You can even start to poke out some characters manually to the serial port to see if (where) it really hangs if you cannot use or don't want to spend lots of money to get a hw debugger just for this. And, thanks for referring me to the mailing addresses. I will immediately subscribe to Ozlabs! Read the list archives and the FAQ's mentioned in here and ask google. You will get good answers there, too! Best greets, Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm.de Phone: +49-89-741518-50 Fax: +49-89-741518-19
Did anybody use netatalk on ppc??
Hello, Johnson! Advice? This is the wrong list for questions like this, I guess. However we run netatalk also on our systems (mostly ix86) on an utf-8 reiserfs filesystem and we used convmv to solve some character translation issues to/from non-utf-8 filesystems. You might want to check with google and the netatalk lists. Greets, Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm.de Phone: +49-89-741518-50 Fax: +49-89-741518-19 JohnsonCheng wrote: Dear All, I have used netatalk2.0.3 with Unicode on x86, it's no problem. Then I port it to ppc board, compiler is OK and also can running. Unfortunately, I have trouble on Unicode issue, I found it doesn't work. Does someone give me some advice?? Thanks, Johnson Cheng ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Mapping huge user buffers for DMA
Hello, Stephen! Please have a look at the whole thread around my posts at: http://lkml.org/lkml/2005/8/4/201 I am working on an mpc8540 (e500) ppc and we are pushing data from the local bus directly to the userspace mlock()ed memory with the dma engine, using scatter/gather (chaining and page/chunk-defragmentation/compression) transfers. Currently, I send the application's user virtual and mlock()ed address to the kernel driver through an ioctl and do an iopa() at the user virtual addresses (pages) to get to the physical addresses (pages). The system works stable and we can fill up the whole memory (192MByte) with currently 144MByte/s (still improvements possible). If you are interested in our design, feel free to contact me directly. Greets, Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm.de Phone: +49-89-741518-50 Fax: +49-89-741518-19 Stephen Williams wrote: I have a PPC405GPr system with an image processing device, that is creating potentially huge amounts of data. In one setup I have a 256Meg system, and I'm trying to map a 192Meg destination buffer using map_user_kiovec and an array of kiobufs. I'm finding, however, that I'm getting an Oops in map_user_kiovec when it tries this, and I'm wondering where I need to look for any limits I might be overrunning. Also, I've been considering skipping kiobufs all together and instead using code like this (lifted from map_user_kiobuf) /* Try to fault in all of the necessary pages */ down_read(mm-mmap_sem); /* rw==READ means read from disk, write into memory area */ err = get_user_pages(current, mm, va, pgcount, (rw==READ), 0, iobuf-maplist, NULL); up_read(mm-mmap_sem); to get the user pages directly. This is really what I want, and I do not need the other functionality of kiobufs. Is the get_user_pages function kosher for use by drivers? Is there a limit to what get_user_pages may map?
A configure error for samba3 on ppc
Hi, JohnsonCheng! you wrote: When I configure samba3.0.10 on ppc as following command: CC=powerpc-linux-gcc AR=powerpc-linux-ar RANLIB=powerpc-linux-ranlib ./configure -host=powerpc-linux I got a configure error message as following: Configure: error: cannot run test program while cross compiling See 'config.log' for more details I think this is a samba configure bug, do anybody know how to pass it? No, it's not a bug. It's exactly what the message trys to tell you. Samba wants to do some tests. But as it's not a native build, it doesn't want to execute itself for the tests. Because samba might not run on a different platform as it was built for. If you want to do the tests, you need to let to do it on the target where it was built for and not where it was built on. Samba works fine over here on ppc embedded systems. Greets, Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm.de Phone: +49-89-741518-50 Fax: +49-89-741518-19
A configure error for samba3 on ppc
Hi, JohnsonCheng! you wrote: Yes. But how can I pass the testing? Running it on the target - where it is actually supposed to work. For cross-compile environment, the HOST and the TARGET are almost not the same, so many utility can configure for cross-compile with host setting except samba. Well, you can tell configure to skip the tests silently if HOST!=TARGET or give the message you got. But I wouldn't expect configure to guess how it can get the code from the host to the target. Yes, it's indeed a bad virus ;-) It seems not sense. I'd like to see the message. For me I prefer to compile things native - if somehow possible. Greets, Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm.de Phone: +49-89-741518-50 Fax: +49-89-741518-19 -Original Message- From: Clemens Koller [mailto:clemens.koller at anagramm.de] Sent: Tuesday, August 09, 2005 6:24 PM To: JohnsonCheng Cc: linuxppc-embedded at ozlabs.org Subject: Re: A configure error for samba3 on ppc Hi, JohnsonCheng! you wrote: When I configure samba3.0.10 on ppc as following command: CC=powerpc-linux-gcc AR=powerpc-linux-ar RANLIB=powerpc-linux-ranlib ./configure -host=powerpc-linux I got a configure error message as following: Configure: error: cannot run test program while cross compiling See 'config.log' for more details I think this is a samba configure bug, do anybody know how to pass it? No, it's not a bug. It's exactly what the message trys to tell you. Samba wants to do some tests. But as it's not a native build, it doesn't want to execute itself for the tests. Because samba might not run on a different platform as it was built for. If you want to do the tests, you need to let to do it on the target where it was built for and not where it was built on. Samba works fine over here on ppc embedded systems. Greets, Clemens Koller
MPC8555CDS CCSRBAR
Hi!
You might want to try that:
#include asm/mpc85xx.h
#include immap_85xx.h /* see mail archives for complete mpc8540
version */
...
void foo(void)
{
volatile ccsr_t *immap;
phys_addr_t ccsrbar;
ccsrbar=get_ccsrbar();
immap=ioremap(ccsrbar,sizeof(ccsr_t)); /* is ioremap_nochache() the
same on mpc85xx? */
if (!immap) {
printk(KERN_ALERT Failed to ioremap CCSRBAR!\n);
err = -EIO;
goto out;
}
/* examples */
printk(KERN_INFO CCSRBAR addr%.8lx\n,ccsrbar);
printk(KERN_INFO IMMAP addr %p\n,immap);
printk(KERN_INFO BR0%.8x\n,immap-im_lbc.br0);
printk(KERN_INFO OR0%.8x\n,immap-im_lbc.or0);
/* unmap the ccsr*/
iounmap(immap);
out:
}
I hope that's all current code.
Comments are welcome.
Greets,
Clemens Koller
___
RD Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19
Gerhard Jaeger wrote:
On Tuesday 09 August 2005 16:04, Eric Kampman wrote:
Trying to port an SEC driver to Linux/PPC8555. Reading
the default CCSRBAR @ 0xFF70 I read 0x
which is wrong. Looking at Metrowerks init files and
uboot code (1.1.2) I see it's likely been moved to
0xE000, but I get a seg fault when I try to read
there.
So, what am I doing wrong, and even better, how do I
at runtime find out where CCSRBAR is? Thanks in
advance, and please forgive the likely ignorance,
Eric
use the get_ccsrbar() function to get the address, then ioremap()
will be your friend ;)
HTH
Gerhard
MPC8541E DMA transfer
Hello, Bizhan! and all the other mpc85xx DMA fans. I am working on the mpc85xx dma stuff (based on Jason's work) on the lastest 2.6.x kernels. My cpu is a mpc8540. That's all work in progress, so have a look at the code. Attached you will find some of my test code (a separate kernal module) which should compile fine for 2.6 now. Make a symlink ~/linux to the latest 2.6 kernel or change the makefile. There is also the latest immap_85xx.h (almost complete) included. Some old code is commented out... Not all code is enabled in the module yet, and the dma_test routine copys data from physical memory you might not have in your hardware. Please change that according to your setup. Feedback is welcome! Enjoy! Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm.de Phone: +49-89-741518-50 Fax: +49-89-741518-19 Bizhan Gholikhamseh (bgholikh) wrote: Is there any support in Linux 2.6.X for using this controller, if so, are you aware of any test driver I can take a look at? Thanks, Bizhan Many thanks in -Original Message- From: Kumar Gala [mailto:kumar.gala at freescale.com] Sent: Wednesday, August 03, 2005 11:24 AM To: Bizhan Gholikhamseh (bgholikh) Cc: linuxppc-embedded at ozlabs.org Subject: Re: MPC8541E DMA transfer I dont see any reason you couldn't use the internal DMA engine on the MPC8541E to do what you need. You will just need to schedule the work every 10ms. - kumar On Aug 3, 2005, at 10:04 AM, Bizhan Gholikhamseh \(((bgholikh\))) wrote: Hi all, I am developing a linux driver (2.6.10) for Freescale MPC8541E (customized board) to read and write 8 buffers (each buffer is 960 bytes long) every 10 ms to/from a custom made PCI card with on board DSP Chip. The chip's internal and external memories are memory mapped to the CPU address space. For reason that is beyond the discussion here, the DMA request line on the PCI card is not connected although the PCI card has DMA capabilities. So what are my options? Could I still do DMA transfer from the Host to the device? Many thanks in advance, Bizhan ATT293768.txt ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded -- next part -- A non-text attachment was scrubbed... Name: mpc85xx_dma.tar.gz Type: application/octet-stream Size: 20570 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050804/53ce8323/attachment.obj
[PATCH] ppc32: Register definition for MPC85xx
Hello! I suggest to put the register definitions into the Kernel _before_ more driver writers start using their own / different maps. Greets, Clemens Koller --- Almost complete and verified register map for the MPC85xx. Based on sources from Jason McMullan and the MPC8540 Reference Manual. Signed-off-by: Clemens Koller clemens.koller at anagramm.de -- next part -- An embedded and charset-unspecified text was scrubbed... Name: immap_85xx-register-update.patch Url: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050719/dbe8eec9/attachment.txt
[PATCH] ppc32: Register definition for MPC85xx
Hello, Kumar, This isn't going to get into the kernel tree. I'm against putting full register definitions in like this because they are too difficult to maintain properly. We currently have some 14 different 85xx devices today and the number is only going to grow larger. Okay, no problem. I experienced that it is definitely difficult to maintain if there are lot of changes/patches which can corrupt the whole set if only one register is misaligned. Once a set it's completed for a device, it could be nailed down to a specific device by specifying a filename like immap_mpc8540.h And... it doesn't necessarily stay within the kernel tree... maybe Freescale can put out those files on their website for reference? Best greets, Clemens Koller Kumar Gala wrote: Clemens, This isn't going to get into the kernel tree. I'm against putting full register definitions in like this because they are too difficult to maintain properly. We currently have some 14 different 85xx devices today and the number is only going to grow larger. If and when you need something specific in the immap_85xx please provide it as a patch along with the driver that you want in. For certain devices like PCI, LBC, etc I've got no issue adding info into immap_85xx. However, for devices like DUART, I2C, TSEC, etc I'm completely against the idea of having their register definitions in immap_85xx. - kumar On Jul 19, 2005, at 5:01 AM, Clemens Koller wrote: Hello! I suggest to put the register definitions into the Kernel _before_ more driver writers start using their own / different maps. Greets, Clemens Koller --- Almost complete and verified register map for the MPC85xx. Based on sources from Jason McMullan and the MPC8540 Reference Manual. Signed-off-by: Clemens Koller clemens.koller at anagramm.de immap_85xx-register-update.patch ATT1082226.txt
MPC8540 DMA routines (channel 0 broken?)
Hello again... In the meanwhile, I got channel 0 working. It seems that the DMA#0 machine got stuck in some configuration from any previous (u-boot?) operation which didn't clean up things properly. I had to explicitly abort a (continously running?) transfer to be able to re-program it in the way I need. Best greets, Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm.de Phone: +49-89-741518-50 Fax: +49-89-741518-19 Clemens Koller wrote: Hello, I am about to bring Jason McMullan's DMA routines up to linux-2.6 Currently I am in the process of getting the things started step by step. Until today I had a pretty hard time for some basic direct dma transfers because it seems that dma channel 0 doesn't work at all on my hardware (PPC8540PX833LB 2L71V MSIA QEAD0412). The status register always stays 0x0 (means everything is happy and okay) but it doesn't copy any data. I cannot even trigger a programming error by a wrong configuration! But when I let ch 1,2,3 do the work, everything seems to work fine! I havent found anything in the errata sheets or in the web. Can a DMA machine crash that it stays completely unusable? Have anybody seen similar things like that? Some other questions: I would also suggest to put my revised and almost complete immap_85xx.h and the mpc85xx_dma module into the current linux tree (Kumar?) to get things like that started more easily. Why is Jason's work not in the Kernel? If you are fine with that, I can offer some patches. But I first need to strip tons of the debug stuff from the last two weeks. :-/ Best greets, Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm.de Phone: +49-89-741518-50 Fax: +49-89-741518-19 ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
MPC8540 DMA routines (channel 0 broken?)
Hello, Stephane! In the meanwhile, I got channel 0 working. It seems that the DMA#0 machine got stuck in some configuration from any previous (u-boot?) operation which didn't clean up things properly. I had to explicitly abort a (continously running?) transfer to be able to re-program it in the way I need. Are you using a BDI2000? Nope. Some init mode uses the DMA#0 for memory zeroing (see your .cfg file). Also the DDR ECC U-boot code may use the DMA#0. Isn't it possible to reset the DMA#0 from Linux? Thank you! Yes, that's true! ACK I've checked the U-Boot code, today. The problem comes up when U-Boot is built with CONFIG_DDR_ECC. The DMA #0 is used to initialize the DDR prior enabling ECC. Maybe the DMA doesn't get cleaned up properly. (I'll have to re-check the registers). But I can get my mpc85xx_dma driver working now. However I cannot disable ECC when I am in Linux for testing yet. :-] I'll need to customize U-Boot without ECC because I don't want to use it due to performance issues anyway. But that's getting OT here. Greets, Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm.de Phone: +49-89-741518-50 Fax: +49-89-741518-19
MPC8540 DMA routines (channel 0 broken?)
Hello, I am about to bring Jason McMullan's DMA routines up to linux-2.6 Currently I am in the process of getting the things started step by step. Until today I had a pretty hard time for some basic direct dma transfers because it seems that dma channel 0 doesn't work at all on my hardware (PPC8540PX833LB 2L71V MSIA QEAD0412). The status register always stays 0x0 (means everything is happy and okay) but it doesn't copy any data. I cannot even trigger a programming error by a wrong configuration! But when I let ch 1,2,3 do the work, everything seems to work fine! I havent found anything in the errata sheets or in the web. Can a DMA machine crash that it stays completely unusable? Have anybody seen similar things like that? Some other questions: I would also suggest to put my revised and almost complete immap_85xx.h and the mpc85xx_dma module into the current linux tree (Kumar?) to get things like that started more easily. Why is Jason's work not in the Kernel? If you are fine with that, I can offer some patches. But I first need to strip tons of the debug stuff from the last two weeks. :-/ Best greets, Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm.de Phone: +49-89-741518-50 Fax: +49-89-741518-19
MPC85xx DMA support for Kernel 2.6?
Hi, Dan and Mark! Dan Malek wrote: On Jul 1, 2005, at 10:15 AM, Mark Chambers wrote: Is the SRAM being cached? I don't think the CPU will generate bursts unless it's cached, right? I don't really remember :-) I know the 8xx will not burst if the line isn't cached, and I know the 7xxx will. I thought the 82xx and 85xx would also burst if you had sufficient sequential operations queued. On 83/85xx you have to further qualify the discussion based upon the DDR2 or the local bus interface :-) The CPM and DMA will burst on all buses for 8xx/82xx/83xx/85xx if the memory controller is configured to do so. Thanks, for your comments! I'll have a look at it during the next days and let you know about my mileage :-) Greets, Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm.de Phone: +49-89-741518-50 Fax: +49-89-741518-19
MPC85xx DMA support for Kernel 2.6?
Hi, Dan! Dan Malek wrote: Before you start, just make sure such a thing is really a performance enhancement. Yes, the DMA does run in parallel with the core, but often the overhead of the set up and clean up interrupt is more code and time that if you just copied the data in a loop. If possible, integrate the DMA processing into other driver work, clean up a previous DMA the next time the driver needs to use it, not with a separate completion handler. Well... thanks. But the CPU is intended to do image processing while data comes in. And currently, when I access (memcopy) the SRAM on my Local Bus via UPM I cannot get it to generate bursts yet, so I hope the DMA will speed up those things, too. Greets, Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm.de Phone: +49-89-741518-50 Fax: +49-89-741518-19
MPC85xx DMA support for Kernel 2.6?
Hi, Murray! Hello, Jason! Thank you very much! It seems like you saved my holiday! :-))) I will have a look and see what I can find there. Is there any interest to publish this and the other patches and get it into 2.6 if not already planned? Best regards, Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm.de Phone: +49-89-741518-50 Fax: +49-89-741518-19 Murray.Jensen at csiro.au wrote: On Thu, 30 Jun 2005 17:56:30 +0200, Clemens Koller writes: But is there any code available for recycling? Jason McMullan has some code for mpc85xx dma here: http://www.evillabs.net/~gus/patches/mpc85xx_dma.patch Looks like it wouldn't take much to get it working. Cheers! Murray... -- Murray Jensen, CSIRO Manufacturing Infra. Tech. Phone: +61 3 9662 7763 Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 9662 7853 Internet: Murray.Jensen at csiro.au To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference. The information contained in this e-mail may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this e-mail in error, please delete it immediately and notify Murray Jensen on +61 3 9662 7763. Thank you.
MPC85xx DMA support for Kernel 2.6?
Hello! I am planning to use DMA/burst access for copying large chunks of data (100MBytes) from the Local Bus (UPM accessed SRAM) to System Memory (DDR) as fast as possible (200MBytes/s). (As you can guess, that's a framegrabber). As far as I have seen, the DMA engines of the MPC85xx (fsl-dma) are not supported in the classical way (dma_request(), free_dma()) in the kernel 2.6.x. The memory allocators in arch/ppc/dma-mapping.c seem to be usable, but there is no valuable dma support yet (true?). I can program the DMA Controllers in my MPC8540 on my own to achieve what I want but it would be great to get/produce/stick with as much cross-platform reusable code as possible. Is there any ongoing work to put DMA support for the mpc85xx and similar devices into the kernel? Is there any ongoing work in this area or is somebody working with the fsl-dma and can publish some code and share some ideas? Best greets, Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm.de Phone: +49-89-741518-50 Fax: +49-89-741518-19
MPC85xx DMA support for Kernel 2.6?
Hi, Kumar... I'm not aware of anyone work on such a thing. *Sigh*... no holiday for me this summer .-( I'd be more than happy to accept patches for it. I know several of us have written some APIs on top of the DMA for 85xx. Those however are non-standard APIs. But is there any code available for recycling? Are there any Freescale-FAE's with some snippets? (Hello, world!) I am about to start more or less from scratch and re-invent the wheel. What APIs exist for general purpose DMA engines? Last time I looked at this problem nothing really existed. :-) I was wondering about that, too... Maybe we can get some basics from this one: Linux/Documentation/DMA-API.txt And, well, code from: asm-ppc/ppc4xx_dma.h arch/ppc/syslib/ppc4xx_sgdma.c and from the pci.h subsystem. Hmm... and there is the factor that it's difficult to get resources in my project for all that. :-((( Best greets, Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm.de Phone: +49-89-741518-50 Fax: +49-89-741518-19
2.6 support for MPC8541(e)
Hi! I had to do the same for my MPC8540 board (Microsys PM854). It's based on the MPC8540_ADS platform, too with changes in PCI subsystem and Gigabit Ethernet (gianfar_phy). Enable early serial and enjoy printk. Try to find out, where it hangs. Greets, Clemens Koller ___ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm.de Phone: +49-89-741518-50 Fax: +49-89-741518-19 Kumar Gala wrote: You probably need to port the platform code from 2.4 to 2.6 for this board. I'm guessing you are running into some PCI config issue with interrupts and the such. Take a look at arch/ppc/platforms/85xx/* for examples of boards that support 85xx processors. - kumar On Jun 28, 2005, at 9:03 AM, jbi130 at yahoo.com jbi130 at yahoo.com wrote: I've recently received a GDA PCI-G8400 evaluation board with an MPC8541E. It came with u-boot 1.1.2 and a 2.4.27 kernel. Our hopes are to get a 2.6 kernel running on this device so it is in sync with out MPC8248 based boards. What is the status of the support for these chips? When I enable CONFIG_SERIAL_TEXT_DEBUG I'm able to get some output, it seems to die when initializing openpic. There also appears to be issues with the serial console as I'm not getting printk output at all, and I think I should be by the time start_kernel is entered. My current 2.6.12 builds use the MPC8540_ADS configs as a base. The 2.4 that was received with the board does as well. For now I'm not concerned with the 'E' part. My main job is to actually add support for the security engine, but I'd like to get 2.6 up and running first. Yes, this is my first jump into machine specific code.. Thanks. ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
