Re: current ARCH=powerpc for v2pro.
On 11/30/07, Stephen Neuendorffer <[EMAIL PROTECTED]> wrote: > > Grant, > > I'm trying to bring up your arch/powerpc work, using a compiled in > device tree. I added this: > > > Which seems bizarre, because that code is very simple. I'm guessing > that something in the memory configuration is wierd (or maybe > zImage.virtex is not the right way to do this?) but I'm a little lost > where to look from here. I also tried it with both paulus_master and > your virtex-for-2.6.24 branch. I've got a patch that adds 'raw' image support (originally written by Scott Wood) which somewhat works for booting (but not entirely; I haven't had time to dig into it properly yet). It's not suitable to go into mainline yet. I'll try to get the patch out to my tree this evening... actually I've been trying to get my tree pushed out all today, but other things keep coming up. :-) Okay, I pushed my current patch set out to the master branch of my linux-2.6-virtex tree. Give it a whirl. It's not perfect, but it should be usable for booting. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Cannot login via tinylogin on sequoia
Hi: I have built u-boot, kernel and filesystem using ELDK 4.1 for AMCC PPC440EPx sequoia board. When I boot linux using NFS filesystem, supplied with ELDK itself, I can login (usrr root, no password). However I couldn't login while used ramdisk, built by myself or taken from AMCC resource CD. Combinations root/root or root/nothing don't work. Sequoia login: root Password: Login incorrect Please press Enter to activate this console. Dec 31 18:00:26 Sequoia auth.warn login[37]: invalid password for `UNKNOWN' on `ttyS0' Dec 31 18:00:26 Sequoia daemon.info init: Process '/bin/tinylogin login -f root' (pid 37) exited. Scheduling it for restart. How I can learn what user/password combination are configured and how do I change them? This is static/etc/passwd from my SIMPLE filesystem: root::0:0:root:/root:/bin/sh bin:*:1:1:bin:/bin: daemon:*:2:2:daemon:/sbin: halt:*:7:0:halt:/sbin:/sbin/halt ftp:*:14:50:FTP User:/ nobody:*:99:99:Nobody:/: target:$1$x4Rc1j78$n5FVlLwarSyMYoZaMlijU1:200:100:Test User:/home:/bin/sh Thanks, Leonid. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Semaphores in eldk4.1
In message <[EMAIL PROTECTED]> you wrote: > > I have been suing the eldk4.1 tool chain for a few months now and have Please post ELDK related questions on the ELDK mailing list instead, see http://lists.denx.de/mailman/listinfo/eldk > The problem I have come up against is related to some of the semaphore > functions in semaphore.h, namely sem_wait, sem_post. This was originally > noticed in a third party driver I am porting from one board to another -- > but a small test program has shown the same results. What exactly are you talking about? Device driver (i. e. kernel) code, or application (i. e. user space) code ? > Calls to these functions on the ppc_82xx platform return -1 with an > error code of 38, in this case meaning ENOSYS (not implemented). On the Did you enable the CONFIG_SYSVIPC option in your Linux kernel configuration? > ppc_85xx the same program executes fine, thus I conclude that it is > specific to the libc-2.3.5 for ppc_82xx. Has anyone else come across > this problem, I did find one thread but there was no conclusion listed. There is absolutley no difference between ppc_85xx and ppc_82xx as far as library sources or configuration are concerned. The problem is most probably in your Linux kernel, I guess. > I also can not find anything stating that these functions are not > implemented for the 82xx arch compared with others for the eldk4.1 Provide a test program that fails for yuou, and we can provide much better comments. But please post followups on the ELDK mailing list. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] Old programmers never die, they just become managers. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: ppcboot and powerpc branch question
Wolgang, This question does pertain to the thread in question, but.. I am currently using your ELDK 4.1 Uclibc and have written various scripts that allow it to be used with buildroot makefiles. Are you going to releasing a newer version anytime soon? Thanks, Chris P. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wolfgang Denk Sent: Friday, November 30, 2007 2:16 PM To: fabien Cc: linuxppc-embedded@ozlabs.org Subject: Re: ppcboot and powerpc branch question In message <[EMAIL PROTECTED]> you wrote: > > 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. PPCBoot was a in a distant past before U-Boot. Actually, PPCBoot 1.1.5 is more than 5 and a half years old. You cannot really expect a Neanderthal man to drive a space shuttle. > Is there a way to keep my old bootloader to boot a powerpc branch kernel ? No. Please use a current U-Boot (i. e. at least U-Boot 1.3.0). Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] As in certain cults it is possible to kill a process if you know its true name. -- Ken Thompson and Dennis M. Ritchie ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
current ARCH=powerpc for v2pro.
Grant,
I'm trying to bring up your arch/powerpc work, using a compiled in
device tree. I added this:
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 18e3271..48f745d 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -53,7 +53,7 @@ src-wlib := string.S crt0.S stdio.c main.c
flatdevtree.c flatd
cpm-serial.c stdlib.c mpc52xx-psc.c planetcore.c
uartlite.c \
fsl-soc.c mpc8xx.c pq2.c
src-plat := of.c cuboot-52xx.c cuboot-83xx.c cuboot-85xx.c holly.c \
- cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
+ virtex.c cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c
cuboot-8xx.c \
cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c
cuboot-bamboo.c
fixed-head.S ep88xc.c cuboot-hpc2.c
@@ -159,6 +159,7 @@ image-$(CONFIG_EBONY) +=
treeImage.ebo
image-$(CONFIG_BAMBOO) += treeImage.bamboo
cuImage.bamboo
image-$(CONFIG_SEQUOIA)+= cuImage.sequoia
image-$(CONFIG_WALNUT) += treeImage.walnut
+image-$(CONFIG_XILINX_VIRTEX_GENERIC_BOARD)+=
zImage.virtex
endif
# For 32-bit powermacs, build the COFF and miboot images
diff --git a/arch/powerpc/boot/virtex.c b/arch/powerpc/boot/virtex.c
new file mode 100644
index 000..32cebc1
--- /dev/null
+++ b/arch/powerpc/boot/virtex.c
@@ -0,0 +1,20 @@
+
+
+#include "ops.h"
+#include "stdio.h"
+#include "dcr.h"
+#include "4xx.h"
+#include "io.h"
+
+BSS_STACK(4096);
+
+void platform_init(void)
+{
+ unsigned long end_of_ram = 0xfff;
+ unsigned long avail_ram = end_of_ram - (unsigned long) _end;
+
+ simple_alloc_init(_end, avail_ram, 32, 32);
+ ft_init(_dtb_start, _dtb_end - _dtb_start, 32);
+ serial_console_init();
+printf("booting virtex\n");
+}
and got as far as:
---
booting virtex
zImage starting: loaded at 0x0040 (sp: 0x00551f14)
Allocating 0x2d7324 bytes for kernel ...
gunzipping (0x <- 0x0040b000:0x00550d74)...done 0x2b35ec bytes
Linux/PowerPC load: root=/dev/xsysace/disc0/part2
Finalizing device tree... flat tree at 0x409870
---
Tracing through the code, it appears that there is a machine check in
memset_io in early_init():
unsigned long __init early_init(unsigned long dt_ptr)
{
unsigned long offset = reloc_offset();
struct cpu_spec *spec;
/* First zero the BSS -- use memset_io, some platforms don't
have
* caches on yet */
memset_io((void __iomem *)PTRRELOC(&__bss_start), 0,
__bss_stop - __bss_start);
/*
* Identify the CPU type and fix up code sections
* that depend on which cpu we have.
*/
spec = identify_cpu(offset, mfspr(SPRN_PVR));
do_feature_fixups(spec->cpu_features,
PTRRELOC(&__start___ftr_fixup),
PTRRELOC(&__stop___ftr_fixup));
return KERNELBASE + offset;
}
Which seems bizarre, because that code is very simple. I'm guessing
that something in the memory configuration is wierd (or maybe
zImage.virtex is not the right way to do this?) but I'm a little lost
where to look from here. I also tried it with both paulus_master and
your virtex-for-2.6.24 branch.
Any ideas?
Steve
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: ppcboot and powerpc branch question
In message <[EMAIL PROTECTED]> you wrote: > > 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. PPCBoot was a in a distant past before U-Boot. Actually, PPCBoot 1.1.5 is more than 5 and a half years old. You cannot really expect a Neanderthal man to drive a space shuttle. > Is there a way to keep my old bootloader to boot a powerpc branch kernel ? No. Please use a current U-Boot (i. e. at least U-Boot 1.3.0). Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] As in certain cults it is possible to kill a process if you know its true name. -- Ken Thompson and Dennis M. Ritchie ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Semaphores in eldk4.1
HI Stuart, Stuart Hodgson wrote: > Hi, > > I have been suing the eldk4.1 tool chain for a few months now and have > not not encountered any problems with building until now. I build for > two slightly different archs, ppc_85xx and ppx_82xx. > > The problem I have come up against is related to some of the semaphore > functions in semaphore.h, namely sem_wait, sem_post. This was originally > noticed in a third party driver I am porting from one board to another > but a small test program has shown the same results. > > Calls to these functions on the ppc_82xx platform return -1 with an > error code of 38, in this case meaning ENOSYS (not implemented). On the > ppc_85xx the same program executes fine, thus I conclude that it is > specific to the libc-2.3.5 for ppc_82xx. Has anyone else come across > this problem, I did find one thread but there was no conclusion listed. > > These work fine for me with ppc_6xx architecture and ELDK 4.1, although they didn't with ELDK 4.0. In that case, I was getting ENOSYS on sem_open() and sem_init(). Do these functions return 0 for you? I assume you're using a kernel that supports POSIX semaphores (I think that started at 2.6.12) and that you're using the glibc version of ELDK and not ulibc. > I also can not find anything stating that these functions are not > implemented for the 82xx arch compared with others for the eldk4.1 > > Thanks > > Stuart > ___ > Linuxppc-embedded mailing list > Linuxppc-embedded@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded > > regards, Ben ___ 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 __ R&D 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
Semaphores in eldk4.1
Hi, I have been suing the eldk4.1 tool chain for a few months now and have not not encountered any problems with building until now. I build for two slightly different archs, ppc_85xx and ppx_82xx. The problem I have come up against is related to some of the semaphore functions in semaphore.h, namely sem_wait, sem_post. This was originally noticed in a third party driver I am porting from one board to another but a small test program has shown the same results. Calls to these functions on the ppc_82xx platform return -1 with an error code of 38, in this case meaning ENOSYS (not implemented). On the ppc_85xx the same program executes fine, thus I conclude that it is specific to the libc-2.3.5 for ppc_82xx. Has anyone else come across this problem, I did find one thread but there was no conclusion listed. I also can not find anything stating that these functions are not implemented for the 82xx arch compared with others for the eldk4.1 Thanks Stuart ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: ppcboot and powerpc branch question
Thanks for yours advices Scott and Clemens i'll read the docs given Best regards 2007/11/30, Clemens Koller <[EMAIL PROTECTED]>: > 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-embedded&m=11960901017&w=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 .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. > > 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 > __ > R&D 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-embedded&m=11960901017&w=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 .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. 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 __ R&D 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 wrote: > Ok, thanks > So do I need to define a dts file or the bd_t struct only will be > sufficient to boot with cuImage ? You need to define a dts file (see the existing ones in arch/powerpc/boot/dts for examples), and set CONFIG_DEVICE_TREE to tell the wrapper which one to include. Note that this dts must have linux,network-index properties in the network nodes for the MAC addresses to be filled in, and must have /chosen/linux,stdout-path if you want output from the wrapper (useful if something goes wrong (such as insufficient memory to relocate the kernel) or if you want to edit the command line). You also need to do make zImage rather than make uImage for cuImage to be built. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: ppcboot and powerpc branch question
2007/11/30, Grant Likely <[EMAIL PROTECTED]>: > On 11/30/07, fabien <[EMAIL PROTECTED]> wrote: > > 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-embedded&m=11960901017&w=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 ? > > Yes, you can build a 'cuImage' in arch/powerpc which wraps the kernel > image with a device tree and copies the bd_t data into the tree before > booting. > > Cheers, > g. > > > -- > Grant Likely, B.Sc., P.Eng. > Secret Lab Technologies Ltd. > [EMAIL PROTECTED] > (403) 399-0195 > Ok, thanks So do I need to define a dts file or the bd_t struct only will be sufficient to boot with cuImage ? Best regards Fab ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
Hello, Alessandro! Alessandro Zummo schrieb: > 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... Here comes more debugging output: Please note that I have now _two_ almost identical systems up and running with the latest kernel. One machine (ecam) with an pcf8563 RTC on I2C and another one (fox_1) with an DS1337. Both RTCs work, but the kernel doesn't get the time right. I have now the SENSORS_*=n as you said and the (new) RTC configured. The kernel configuration (attached) is identical for both machines. Can you please check that again?! Which CONFIG do I have to enable that I get /dev/rtc and/or /dev/rtc0 devices? Note that I don't get any /dev/rtc* entry right now despite RTC_INTF_DRV=Y Here are the outputs of the two hosts: HOST ECAM [EMAIL PROTECTED]:~$ dmesg Using MPC85xx ADS machine description Memory CAM mapping: CAM0=256Mb, CAM1=0Mb, CAM2=0Mb residual: 0Mb Linux version 2.6.24-rc3-g09f345da ([EMAIL PROTECTED]) (gcc version 4.2.2 (ckcore)) #2 Fri Nov 30 13:06:38 CET 2007 Found legacy serial port 0 for /[EMAIL PROTECTED]/[EMAIL PROTECTED] mem=e0004500, taddr=e0004500, irq=0, clk=33000, speed=0 Found legacy serial port 1 for /[EMAIL PROTECTED]/[EMAIL PROTECTED] mem=e0004600, taddr=e0004600, irq=0, clk=33000, speed=0 Entering add_active_range(0, 0, 65536) 0 entries of 256 used Found FSL PCI host bridge at 0xe0008000.Firmware bus number: 0->0 Top of RAM: 0x1000, Total RAM: 0x1000 Memory hole size: 0MB Zone PFN ranges: DMA 0 ->65536 Normal 65536 ->65536 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 ->65536 On node 0 totalpages: 65536 DMA zone: 512 pages used for memmap DMA zone: 0 pages reserved DMA zone: 65024 pages, LIFO batch:15 Normal zone: 0 pages used for memmap Movable zone: 0 pages used for memmap Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024 Kernel command line: root=/dev/sdb3 ro console=ttyS0,115200 mpic: Setting up MPIC " OpenPIC " version 1.2 at e004, max 1 CPUs mpic: ISU size: 56, shift: 6, mask: 3f mpic: Initializing for 56 sources PID hash table entries: 1024 (order: 10, 4096 bytes) time_init: decrementer frequency = 41.25 MHz time_init: processor frequency = 825.00 MHz clocksource: timebase mult[60f83e1] shift[22] registered clockevent: decrementer mult[a8f] shift[16] cpu[0] Console: colour dummy device 80x25 Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 256000k/262144k available (3296k kernel code, 5840k reserved, 144k data, 92k bss, 124k init) SLUB: Genslabs=11, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1 Calibrating delay loop... 82.43 BogoMIPS (lpj=164864) Mount-cache hash table entries: 512 net_namespace: 64 bytes NET: Registered protocol family 16 rstcr compatible register does not exist! 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 SCSI subsystem initialized libata version 3.00 loaded. usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb NET: Registered protocol family 2 Time: timebase clocksource has been installed. Switched to high resolution mode on CPU 0 IP route cache hash table entries: 2048 (order: 1, 8192 bytes) TCP established hash table entries: 8192 (order: 4, 65536 bytes) TCP bind hash table entries: 8192 (order: 3, 32768 bytes) TCP: Hash tables configured (established 8192 bind 8192) TCP reno registered io scheduler noop registered io scheduler anticipatory registered (default) io scheduler deadline registered io scheduler cfq registered 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 loop: module loaded Gianfar MII Bus: probed 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 eth1: Gianfar Ethernet Controller Version 1.2, 00:40:42:01:00:01 eth1: Running with NAPI enabled eth1: 256/256 RX/TX BD ring size eth2: Gianfar Ethernet Controller Version 1.2, 00:40:42:01:00:02 eth2: Running with NAPI enabled eth2: 256/256 RX/TX BD ring size sata_promise :00:14.0: version 2.11 scsi0 : sata_promise scsi1 : sata_promise scsi2 : sata_promise ata1
Re: ppcboot and powerpc branch question
On 11/30/07, fabien <[EMAIL PROTECTED]> wrote: > 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-embedded&m=11960901017&w=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 ? Yes, you can build a 'cuImage' in arch/powerpc which wraps the kernel image with a device tree and copies the bd_t data into the tree before booting. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
ppcboot and powerpc branch question
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-embedded&m=11960901017&w=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 ? Best regards Fab ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
On Fri, 30 Nov 2007 12:04:00 +0100 Clemens Koller <[EMAIL PROTECTED]> wrote: > A kernel upgrade doesn't make the chip to disappear ;-) > The I2C bus is/was basically working fine all the time... see below. you never know those pesky chips ;) > 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... -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it ___ 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 __ R&D 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: Init hangs on Xilinx4
schardt wrote: > Hi David, > > thanks for your help. > >>> >>> >>> >> I am presuming you are using PK's UartLite driver. >> >> > I use the Kernel from Grant's git server, and let me look... yes its > from Peter Korsgaard :) > > >> Try printing out membase some time possibly in ulite_console_setup. >> If the value of membase is 0x40600 that is your problem. >> It should be something like 0xfd I think. >> >> > Mmmh, my EDK Project maps the uartlite to 0x4060, so i think its > okay. but i can try it at a higher adress > > it is very strange. i use the same hardware setup and boot from > system-ace without any problems. Another posibility that I thought of since you are using Peter K's driver. If you have any interrupt problems I think you could get your current behavior. During boot console I/O is not interrupt driven. When the OS sends a string the whole string gets sent and then the console write exits, but very close to running init, the console switches to using the full driver. PK's driver is interrupt driven. If the UartLite TX FIFO empty interrupt is broke in anyway, it will send until the first time the FIFO fills and then stop. The interrupt could be broken in firmware - not properly connected to the PIC, or it could be broken in software - however your driver is receiving its interrupt configuration, the driver may be receiving the incorrect intterrupt #. At one point I tried to add timer driven polling to PK's driver similar to that in the 8250 and others - we have clients that run without any PIC, but trying to figure out what was going on proved sufficiently difficult I just went back to my own driver. > > > > Regards > Georg > > > --- > --- > Forschungszentrum Jülich GmbH > 52425 Jülich > > Sitz der Gesellschaft: Jülich > Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 > Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe > Geschäftsführung: Prof. Dr. Achim Bachem (Vorsitzender), > Dr. Ulrich Krafft (stellv. Vorsitzender), Dr. Sebastian M. Schmidt > --- > --- > -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. "Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction." Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
