initramfs and busybox kernel oops
hi all, I'm trying to get busybox working on my custom board mpc855t and linux kernel 2.6.19 (from eldk 4.1 uclibc). I've built an initramfs that i link directly in kernel. To verify whether the kernel is able to lauch the init process i've compiled a small hello world program. But no when i try with busybox 1.8.1 staticaly linked i got an Oops error kernel access to bad area. I don't know why the former work fine but no the latter. If someone have some ideas for where to look for ? In my initramfs there is : in /dev : crw-r--r-- 1 root root 5, 1 nov 22 13:32 console crw-rw-rw- 1 root root 1, 3 nov 26 10:10 null crw--- 1 root root 4, 1 nov 26 10:11 tty1 in /bin : lrwxrwxrwx 1 root root7 nov 26 10:17 ash - busybox* -rwxr-xr-x 1 root root 793804 nov 26 13:57 busybox* lrwxrwxrwx 1 root root7 nov 26 10:17 cat - busybox* (and others links) My init script file (/init) : #!/bin/sh /bin/ash ... Serial: CPM driver $Revision: 0.02 $ cpm_uart: WARNING: no UART devices found on platform bus! cpm_uart: the driver will guess configuration, but this mode is no longer supported. ttyCPM0 at MMIO 0xff000a80 (irq = 20) is a CPM UART RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize loop: loaded (max 8 devices) TCP cubic registered Freeing unused kernel memory: 512k init execute init process Hello world test bonjour salut ... ... ttyCPM0 at MMIO 0xff000a80 (irq = 20) is a CPM UART RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize loop: loaded (max 8 devices) TCP cubic registered Freeing unused kernel memory: 504k init execute init process Oops ... (log_buf) when i try with busybox. log is little bit altered by the fact i need plug/unplug the cable to reset 001ed154: 6720756e 75736564 206b6572 6e656c20g unused kernel 001ed164: 6f656d6f 72793a21 3438386b 20696e69oemory:!488k ini 001ed174: 740a3d37 3e43506f 20756172 745b305dt.=7CPo uart[0] 001ed184: 3a737461 72747570 0a3c373e 4358cd20:startup.7CX. 001ed194: 75617274 5b305d3a 7365745f 7465726duart[0]:set_term 001ed1a4: 696f730a 3c343e65 78656375 7d652069ios.4execu}e i 001ed1b4: 6e697420 70f26f63 6573730a 3c343e4fnit p.ocess.4O 001ed1c4: 7f70733a 206f6572 6e656c20 61636365.ps: oernel acce 001ed1d4: 7373206f 66206261 64206172 65612c20ss of bad area, 001ed1e4: 7379673a 20313121 5f23315d 0a3c343esyg: 11!_#1].4 001ed1f4: 4f6f7073 3a206b65 726e656c 24616373Oops: kernel$acs 001ed204: 67737320 6f662072 61642061 f265612cgss of rad a.ea, 001ed214: 20736967 3a203131 205b2332 5d0a3c34 sig: 11 [#2].4 001ed224: 3e4e4950 3a204330 30433035 4643204cNIP: C00C05FC L 001ed234: 523a2043 30303132 33303820 4354523aR: C0012308 CTR: 001ed244: 20303030 30383030 300a3c34 3e524547 8000.4REG 001ed254: 533a2063 30323339 62363020 5c525150S: c0239b60 \RQP 001ed264: 3a203033 30302020 204e6f74 20746169: 0300 Not tai 001ed274: 6e746564 20212832 2e362e33 392e3629nted !(2.6.19.6) 001ed284: 0b3c343e 4d53523a 20f13030 303130b3.4MSR: .00010. 001ed294: 32203c4d 452e4952 2c44523e 602043522 ME.IR,DR` CR 001ed2a4: 3a203535 30303030 39352020 58455a3a: 5595 XEZ: 001ed2b4: 20413030 30464637 4e0a3c34 3e444152 A000FF7N.4DAR 001ed2c4: 3a213346 30303030 30302c22 44534953:!3F00,DSIS 001ed2d4: 523a2043 30303032 3030300a 3c34be54R: C0002000.4.T 001ed2e4: 4153cb20 3d206330 32333762 37305b31AS. = c0237b70[1 001ed2f4: 5d202769 6e697427 205448d2 4549443a] 'init' TH.EID: 001ed304: a063b032 33383830 b00a3c36 3e475052.c.23880..6GPR 001ed314: b0303a20 30303030 30343733 20433032.0: 0473 C02 001ed324: 33394331 30204330 32333743 b730203339C10 C0237C.0 3 001ed334: 66303030 30303020 4330314d 44714333f00 C01MDqC3 001ed344: 20303030 32313032 45203030 30303430 0002102E 40 001ed354: 30342146 46303032 39333020 0a3c363e04!FF002930 .6 001ed364: 47505230 383a2047 30314544 31433620GPR08: G01ED1C6 001ed374: 32303030 42303032 20334630 303030302000B002 3F0 001ed384: 70204330 31363237 30342030 30307030p C0162704 000p0 001ed394: 30303120 30303030 30303034 20303046001 0004 00F 001ed3a4: 46453830 30223030 3746464e 3134240aFE87FFN14$. 001ed3b4: 3c363e47 50d231b6 3a203030 303030306GP.1.: 00 001ed3c4: 30302030 30b13030 30303120 30303f4600 00.1 00?F 001ed3d4: 46463030 204b3031 36303030 30205330FF00 K016 S0 ... thank a lot for help fab ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Debugging with gdbserver slow
khollan wrote: Hi everyone, Im using gdbserver to debug Linux apps on my embedded board, but it takes like 3-6 sec to step one line of code. Its about the same to go from breakpoint to breakpont. Im using TCP to connect the host to the target. Is this typical or is there some setting wrong or was it built wrong. Its a PPC405 in a Xilinx FPGA. Thanks khollan How long does it take everyone else to step through code serial or TCP? -- View this message in context: http://www.nabble.com/Debugging-with-gdbserver-slow-tf4846374.html#a13951808 Sent from the linuxppc-embedded mailing list archive at Nabble.com. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: The question about the UART on UCC5,UCC6,UCC7,UCC8 for MPC8360?
?? wrote: after compiled, I download the linux to MPC8360 board, but I cannot find the serial device for UCC5,UCC6,UCC7,UCC8. I just find the ttyS0,ttyS1 is OK. Could you tell me that what's the name for the serial device of UCC5,6,7,8? Whether or not I can use those UART just like the ttyS0,ttyS1? I don't know why the BSP offers a UART driver for the 8360, because the driver isn't available yet. I'm working on that, though. I'll post the driver in a week or so, and it will be included in 2.6.25. You'll have to ask the BSP support line if they plan on updating the BSP to include the new driver. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Xilinx devicetrees
On 11/26/07, Koss, Mike (Mission Systems) [EMAIL PROTECTED] wrote: DLAnd once again a plea to ALWAYS make version/capabilities registers DL atleast an optional part of every design. DLEmbeddeding a device tree into a design might be fairly expensive. a DL pair of read only 32 bit registers is damn near free - basically the DL FPGA equivalent of atmost 64 diodes or resistors. SN Actually, device trees actually seem to be cheaper (in the whole system sense) than such registers. Unless there is something I don't understand? The issue here is that the hardware changed and the driver doesn't support it. I think this would be fixed by having information passed to the driver in the platform_device struct to specify information, since its not able to be discerned by the physical hardware information: version registers, etc. This is exactly the information that should be encoded in the 'compatible' property of the device tree. (instead of platform_data; platform_data is no longer required with the of_platform bus binding) *If* edk is generating our device tree(s) for us, *then* version registers are not needed by Linux. 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
Re: initramfs and busybox kernel oops
2007/11/26, fabien [EMAIL PROTECTED]: hi all, I'm trying to get busybox working on my custom board mpc855t and linux kernel 2.6.19 (from eldk 4.1 uclibc). I've built an initramfs that i link directly in kernel. To verify whether the kernel is able to lauch the init process i've compiled a small hello world program. But no when i try with busybox 1.8.1 staticaly linked i got an Oops error kernel access to bad area. I don't know why the former work fine but no the latter. If someone have some ideas for where to look for ? In my initramfs there is : in /dev : crw-r--r-- 1 root root 5, 1 nov 22 13:32 console crw-rw-rw- 1 root root 1, 3 nov 26 10:10 null crw--- 1 root root 4, 1 nov 26 10:11 tty1 in /bin : lrwxrwxrwx 1 root root7 nov 26 10:17 ash - busybox* -rwxr-xr-x 1 root root 793804 nov 26 13:57 busybox* lrwxrwxrwx 1 root root7 nov 26 10:17 cat - busybox* (and others links) My init script file (/init) : #!/bin/sh /bin/ash ... Serial: CPM driver $Revision: 0.02 $ cpm_uart: WARNING: no UART devices found on platform bus! cpm_uart: the driver will guess configuration, but this mode is no longer supported. ttyCPM0 at MMIO 0xff000a80 (irq = 20) is a CPM UART RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize loop: loaded (max 8 devices) TCP cubic registered Freeing unused kernel memory: 512k init execute init process Hello world test bonjour salut ... ... ttyCPM0 at MMIO 0xff000a80 (irq = 20) is a CPM UART RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize loop: loaded (max 8 devices) TCP cubic registered Freeing unused kernel memory: 504k init execute init process Oops ... (log_buf) when i try with busybox. log is little bit altered by the fact i need plug/unplug the cable to reset 001ed154: 6720756e 75736564 206b6572 6e656c20g unused kernel 001ed164: 6f656d6f 72793a21 3438386b 20696e69oemory:!488k ini 001ed174: 740a3d37 3e43506f 20756172 745b305dt.=7CPo uart[0] 001ed184: 3a737461 72747570 0a3c373e 4358cd20:startup.7CX. 001ed194: 75617274 5b305d3a 7365745f 7465726duart[0]:set_term 001ed1a4: 696f730a 3c343e65 78656375 7d652069ios.4execu}e i 001ed1b4: 6e697420 70f26f63 6573730a 3c343e4fnit p.ocess.4O 001ed1c4: 7f70733a 206f6572 6e656c20 61636365.ps: oernel acce 001ed1d4: 7373206f 66206261 64206172 65612c20ss of bad area, 001ed1e4: 7379673a 20313121 5f23315d 0a3c343esyg: 11!_#1].4 001ed1f4: 4f6f7073 3a206b65 726e656c 24616373Oops: kernel$acs 001ed204: 67737320 6f662072 61642061 f265612cgss of rad a.ea, 001ed214: 20736967 3a203131 205b2332 5d0a3c34 sig: 11 [#2].4 001ed224: 3e4e4950 3a204330 30433035 4643204cNIP: C00C05FC L 001ed234: 523a2043 30303132 33303820 4354523aR: C0012308 CTR: 001ed244: 20303030 30383030 300a3c34 3e524547 8000.4REG 001ed254: 533a2063 30323339 62363020 5c525150S: c0239b60 \RQP 001ed264: 3a203033 30302020 204e6f74 20746169: 0300 Not tai 001ed274: 6e746564 20212832 2e362e33 392e3629nted !(2.6.19.6) 001ed284: 0b3c343e 4d53523a 20f13030 303130b3.4MSR: .00010. 001ed294: 32203c4d 452e4952 2c44523e 602043522 ME.IR,DR` CR 001ed2a4: 3a203535 30303030 39352020 58455a3a: 5595 XEZ: 001ed2b4: 20413030 30464637 4e0a3c34 3e444152 A000FF7N.4DAR 001ed2c4: 3a213346 30303030 30302c22 44534953:!3F00,DSIS 001ed2d4: 523a2043 30303032 3030300a 3c34be54R: C0002000.4.T 001ed2e4: 4153cb20 3d206330 32333762 37305b31AS. = c0237b70[1 001ed2f4: 5d202769 6e697427 205448d2 4549443a] 'init' TH.EID: 001ed304: a063b032 33383830 b00a3c36 3e475052.c.23880..6GPR 001ed314: b0303a20 30303030 30343733 20433032.0: 0473 C02 001ed324: 33394331 30204330 32333743 b730203339C10 C0237C.0 3 001ed334: 66303030 30303020 4330314d 44714333f00 C01MDqC3 001ed344: 20303030 32313032 45203030 30303430 0002102E 40 001ed354: 30342146 46303032 39333020 0a3c363e04!FF002930 .6 001ed364: 47505230 383a2047 30314544 31433620GPR08: G01ED1C6 001ed374: 32303030 42303032 20334630 303030302000B002 3F0 001ed384: 70204330 31363237 30342030 30307030p C0162704 000p0 001ed394: 30303120 30303030 30303034 20303046001 0004 00F 001ed3a4: 46453830 30223030 3746464e 3134240aFE87FFN14$. 001ed3b4: 3c363e47 50d231b6 3a203030 303030306GP.1.: 00 001ed3c4: 30302030 30b13030 30303120 30303f4600 00.1 00?F 001ed3d4: 46463030 204b3031 36303030 30205330FF00 K016 S0 ... thank a lot for help fab With symbols it's better : 4exe#uve init pr/cess 4Oops: kernel agcesS of bad aòea, sig: 11 [#1] 4Oopó; kernel access of bad area, sig: 11 [#2] 4NIP:`C00C19A4ÌR: C001239C CTR: JŽREGS: c024db60 TRAP:`0300 Not tainted `(2*6.9.2) 4MWR:!1032 ÍE¬IR,DR CR: 55100095 XER: A000FF7F 4DAR: 3F00, DSISR: C0°2 4TASK = c024bb70[1] 'init' THREAD: c024c000 6EPZ00:2073 C024Dc10 C024BB70
Re: The question about the high memory support on MPC8360?
On Mon, Nov 26, 2007 at 11:41:38AM +0530, vijay baskar wrote: Hi friends, Kernel virtual space is divided into 3 different zones namely ZONE_DMA, ZONE_NORMAL, ZONE_HIGHMEM.Remember that the kernel follows the 3GB/1GB split ie 3 GB for user space and 1 GB for kernel space. Since your ram is 1 GB, 896 MB will be mapped one to one with the kernel virtual space. This one to one mapping will be done in the ZONE_NORMAL and ZONE_DMA of kernel virtual space.Remaining 128 MB of kernel virtual address space will be used for setting up kernel data structures and for ioremaps and vmallocs that the kernel will need to perform during boot up. If u configure high memory this 128 MB will be used for accessing unmapped memory regions in the ram and there wont be sufficient virtual addresses for ioremaps and vmallocs. Thats why your kernel did not boot when high mem is configured. 1. The split is 768/256 on powerpc, not 896/128. 2. Why do you think this is insufficient? Since u want to have 1 GB of ram an alternative to this is that u can try 2 GB/ 2 GB split which is configurable ie 2 GB for user space and 2 GB for kernel space in your kernel. 1. He said he wanted 2GB of RAM, not 1. 2. I don't think this mode of operation has been tested very well on powerpc. = bootm fed0 fe90 ## Booting image at fed0 ... Image Name: Linux-2.6.11 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1054435 Bytes = 1 MB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... OK ## Loading RAMDisk Image at fe90 ... Image Name: uboot ext2 ramdisk rootfs Image Type: PowerPC Linux RAMDisk Image (gzip compressed) Data Size:3195657 Bytes = 3 MB Load Address: Entry Point: Verifying Checksum ... OK Loading Ramdisk to 0fc9a000, end 0ffa6309 ... OK Could you try with a more recent, arch/powerpc kernel? -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 85xx software reset problems from paulus.git
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.
Robert
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Device tree and /proc/iomem question
Hi all, I'm using a recent pull of the paulus tree 2.6.24RC2 on my
custom 85xx board. I'm trying to test my PCI1, PCI2 and PCIe . My
device tree for PCI is:
[EMAIL PROTECTED] {
compatible = fsl,mpc8540-pci;
device_type = pci;
interrupt-map-mask = f800 0 0 7;
interrupt-map =
/* IDSEL 0x11 J17 Slot 1 */
8800 0 0 1 mpic 2 1
8800 0 0 2 mpic 3 1
8800 0 0 3 mpic 4 1
8800 0 0 4 mpic 1 1
/* IDSEL 0x12 J16 Slot 2 */
9000 0 0 1 mpic 3 1
9000 0 0 2 mpic 4 1
9000 0 0 3 mpic 2 1
9000 0 0 4 mpic 1 1;
interrupt-parent = mpic;
interrupts = 18 2;
bus-range = 0 ff;
ranges = 0200 0 8000 8000 0 2000
0100 0 e200 0 0010;
clock-frequency = 3f940aa;
#interrupt-cells = 1;
#size-cells = 2;
#address-cells = 3;
reg = 8000 1000;
};
[EMAIL PROTECTED] {
compatible = fsl,mpc8540-pci;
device_type = pci;
interrupt-map-mask = f800 0 0 7;
interrupt-map =
/* IDSEL 0x11 J17 Slot 1 */
8800 0 0 1 mpic 2 1
8800 0 0 2 mpic 3 1
8800 0 0 3 mpic 4 1
8800 0 0 4 mpic 1 1
/* IDSEL 0x12 J16 Slot 2 */
9000 0 0 1 mpic 3 1
9000 0 0 2 mpic 4 1
9000 0 0 3 mpic 2 1
9000 0 0 4 mpic 1 1;
interrupt-parent = mpic;
interrupts = 18 2;
bus-range = 0 ff;
ranges = 0200 0 c000 c000 0 2000
0100 0 e280 0 0010;
clock-frequency = 3f940aa;
#interrupt-cells = 1;
#size-cells = 2;
#address-cells = 3;
reg = c000 1000;
};
[EMAIL PROTECTED] {
compatible = fsl,mpc8548-pcie;
device_type = pci;
#interrupt-cells = 1;
#size-cells = 2;
#address-cells = 3;
reg = a000 1000;
bus-range = 0 ff;
ranges = 0200 0 a000 a000 0 2000
0100 0 e300 0 0010;
clock-frequency = 1fca055;
interrupt-parent = mpic;
interrupts = 19 2;
interrupt-map-mask = f800 0 0 7;
interrupt-map =
/* IDSEL 0x0 */
0 0 1 mpic 0 1
0 0 2 mpic 1 1
0 0 3 mpic 2 1
0 0 4 mpic 3 1
;
};
I see all the above in /proc/device-tree/[EMAIL PROTECTED] when booting
the kernel. I double checked my memory mapping in u-boot and it
appears to match my device tree. Yet I don't see any pci here:
root:~ cat /proc/iomem
e0004500-e0004507 : serial
e0004600-e0004607 : serial
e0024000-e0024fff : ethernet
e0024520-e002453f : mdio
e0025000-e0025fff : ethernet
e0026000-e0026fff : ethernet
e0027000-e0027fff : ethernet
cat /proc/bus/pci/devices shows nothing though I have a card in PCI1,
and all I see from dmesg is PCI: Probing PCI hardware . Any ideas?
Robert
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: SPI driver for spi_mpc83xx
fabio777 wrote: Has anyone been using this driver ? I use it, on ARCH=powerpc, though. For legacy reasons I need to keep the ppc=arch however I haven't found out how to get this driver probed at start-up even basing my init on Lublock. The driver's expecting a platform device with name mpc83xx_spi to be registered in board init code. If you post your init code I may be able to help. regards, Ben ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: initramfs and busybox kernel oops
fabien wrote: hi all, I'm trying to get busybox working on my custom board mpc855t and linux kernel 2.6.19 (from eldk 4.1 uclibc). I've built an initramfs that i link directly in kernel. To verify whether the kernel is able to lauch the init process i've compiled a small hello world program. But no when i try with busybox 1.8.1 staticaly linked i got an Oops error kernel access to bad area. I don't know why the former work fine but no the latter. If someone have some ideas for where to look for ? In my initramfs there is : in /dev : crw-r--r-- 1 root root 5, 1 nov 22 13:32 console crw-rw-rw- 1 root root 1, 3 nov 26 10:10 null crw--- 1 root root 4, 1 nov 26 10:11 tty1 in /bin : lrwxrwxrwx 1 root root7 nov 26 10:17 ash - busybox* -rwxr-xr-x 1 root root 793804 nov 26 13:57 busybox* lrwxrwxrwx 1 root root7 nov 26 10:17 cat - busybox* (and others links) My init script file (/init) : #!/bin/sh /bin/ash It took me a while to get initramfs running. But after I did I have been very happy with it. It is possible you need more in /dev. My initramfs has much more than yours - though it is still quite small. I sort of stole it from somewhere. I think I took an initrd from somewhere expanded it an culled out what iI did not want. Busybox is still the bulk by volume, but that got me all the /dev /etc/ ... stuff I needed You can pull mine from http://www.picocomputing.net/files/initramfs/ ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
LED heartbeat trigger - in_atomic() while allocs
I was playing around with the LED heartbeat trigger and it caught the BUG() code when trying to activate. Does anyone know why this call stack would be in_atomic()? Or any ideas for a patch that would allow the heartbeat trigger to allocate when it is not in atomic context? BUG: sleeping function called from invalid context at mm/slab.c:3024 in_atomic():1, irqs_disabled():0 Call Trace: [def3dd90] [c0008e60] show_stack+0x48/0x194 (unreliable) [def3ddc0] [c0014160] __might_sleep+0xd0/0xdc [def3dde0] [c0063e60] kmem_cache_zalloc+0xdc/0x12c [def3de00] [c01975c0] heartbeat_trig_activate+0x24/0x80 [def3de20] [c0196844] led_trigger_set+0x128/0x160 [def3de40] [c0196988] led_trigger_store+0x10c/0x1a8 [def3deb0] [c0162f40] class_device_attr_store+0x44/0x5c [def3dec0] [c00ae614] sysfs_write_file+0x114/0x1dc [def3def0] [c0068ea4] vfs_write+0x9c/0x110 [def3df10] [c0068ff4] sys_write+0x4c/0x90 [def3df40] [c000fc00] ret_from_syscall+0x0/0x38 --- Exception: c01 at 0xfe83818 LR = 0xfe35448 Kernel 2.6.22-4, powerpc, targeting an MPC 8347. I don't think this issue is PowerPC specific but I was hoping other embedded people might have experience with the LED class driver. Thank you, Michael ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
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: Xilinx devicetrees
-Original Message- From: David H. Lynch Jr. [mailto:[EMAIL PROTECTED] Sent: Monday, November 26, 2007 1:17 PM To: Koss, Mike (Mission Systems) Cc: Stephen Neuendorffer; Grant Likely; linuxppc-embedded Subject: Re: Xilinx devicetrees Koss, Mike (Mission Systems) wrote: Time for my $.02, since I am heavily weighting my future designs on the use of the device trees. :) (and b/c I don't check my work e-mail from home ;P) From: Stephen Neuendorffer [mailto:[EMAIL PROTECTED] Sent: Sunday, November 25, 2007 6:59 PM To: David H. Lynch Jr.; Grant Likely; linuxppc-embedded Subject: RE: Xilinx devicetrees SN I don't understand the 'burden on software developers'. The code to do this will just be standard code. I got 16K of RAM for my boot loader and that 16K has to do alot more than just manage device trees. I think we have 2K left. In that I have to fit scripting, and ethernet, so where am I supposed to fit the standard code ? If the devicetree is say at the end of the bit file I can probably copy it to ram and pass a pointer to linux in maybe a couple of hundred bytes. If I have to do much more it ain't happening. Personally, It sounds like you're trying to do to much... The only thing that that code really needs to do is to find the 'real' boot code: Maybe Uboot stored in flash? :) I'm not naive enough to suggest that I understand all the constraints of your system, but it is another solution. The worst that one can say is: SN 1) I need several KB additional non volatile storage. Given the size of the FPGA bitstream, this can't be a huge constraint. Several KB is NOT happening. The bitstream is in flash. Flash is not a limited reasorce for us. FPGA cells, and BRAM are precious as gold. The more we use the less our clients have. Device tree should probably be stored in flash, in your case SN Certainly.. But in a sense, these are all intermediate files on the path to the image on the board. Unless we are going to teach linux to read and interpret .bit files while loading, then devicetrees are intermediate in an entirely different sense. The hardware works fine regardless of whether their is a devicetree. But Linux may not boot. I think this philosphy really minimized the value of software... The hardware doesn't work unless the software that comes with it *also* works. :) My objective is to get alot of software - linux, GHS, and standalone apps, to all load - from a single executables, accross multiple different bit images on several different (though deliberately similar) products. My Linux kernel needs to work regardless of the Pico card and regardless of the bit image, as done my GHS kernel, and And I need to do that in a severly resource constrained environment. I would hope that should make sense of my harping about version/capabilities registers. If I have maybe 10 possible peices of IP that may/maynot be present in a given FPGA and I am trying to dynamically configure - Linux/GHS/... to adapt to whatever it encounters and work as long as it is a viable combination. At best devicetrees are an extremly complex way of solving that - while version registers are a trivial way. It sounds like the real problem that you have is that even if you get device trees working for Linux, you still have the same problem for GHS, so from your perspective device trees don't help Steve ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Xilinx devicetrees
Grant Likely wrote: On 11/26/07, Koss, Mike (Mission Systems) [EMAIL PROTECTED] wrote: DLAnd once again a plea to ALWAYS make version/capabilities registers DL atleast an optional part of every design. DLEmbeddeding a device tree into a design might be fairly expensive. a DL pair of read only 32 bit registers is damn near free - basically the DL FPGA equivalent of atmost 64 diodes or resistors. SN Actually, device trees actually seem to be cheaper (in the whole system sense) than such registers. Unless there is something I don't understand? First the decoding for the register is almost certainly already present for the other registers for the device. After that - assuming that an FPGA can impliment a read only register as easily as discrete logic - it should be damn near the most trivial peice of hardware imaginable. It is simpler than 64 bits of RAM. It can be simpler than 64bits of ROM. I do not think there is a way in the world that devicetrees can more cheaply provide the same information. They might me more flexible, or powerful, but 2 64bit read only registers. Anyway I am not arguing that you should not do devicetrees. Just that you should do version/capabilities registers - atleast as a IP option always. Every OS does nto support devicetree's. Every application of an FPGA not going to have that as an option. But every peice of software that can access and I/O device can access its version and capabilities registers. *If* edk is generating our device tree(s) for us, *then* version registers are not needed by Linux. I want both. I want version registers - because they are ALWAYS available. They are available to software running on the FPGA that has no clue what bit file it is running on,how it got to be running. Devicetrees may provide a great deal more information bit it is not hard to come up with scenarios where that information might not be present. It is like the security arguments about biometric identification. I can forget my key card, my password, ... But I am unlikely to forget my thumbprint or retina. -- 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
Re: Xilinx devicetrees
Koss, Mike (Mission Systems) wrote: Time for my $.02, since I am heavily weighting my future designs on the use of the device trees. :) (and b/c I don't check my work e-mail from home ;P) From: Stephen Neuendorffer [mailto:[EMAIL PROTECTED] Sent: Sunday, November 25, 2007 6:59 PM To: David H. Lynch Jr.; Grant Likely; linuxppc-embedded Subject: RE: Xilinx devicetrees SN the device tree is packaged (somehow, TBD) along with the bitstream. If xilinx wants to optionally incorporate the device tree into the bitstream in a fashion that can easily be worked out by software - that would be excellent. I don't know if packaging the device tree with the bitstream is the best way to go. It's possible that it could lead to headaches for certain systems that have security restrictions. Make it an option. Where are the systems with security restrictions going to get their hardware information ? Besides - though I am not aware off the top of my head of a bitstream decompliler, still if you have access to the bitstream you have access to the information about the device. We deal with alot of high security applications. Security restrictions have to make sense. blocking devicetrees for security reasons is like telling somebody they can have the manual in computer readable form, but not on paper. Further if you are going to boot an OS that requires devicetrees then the devicetree must be somewhere - whether it is appended to the bitstream, appended to the kernel, compiled into the kernel, in a separate file, it still has to be present. The same could be said for using it w/ the SystemACE to load it into RAM after the image. (which is what I'm currently doing for my 2 linux images in lieu of a true on-chip bootloader). I am already taking the security concerns into account for future revisions of the hardware wrt to using a SystemACE, and am planning on moving the device trees into NV storage like FLASH. I am not working with MLXXX boards. Pico has no System ACE. The card has an FPGA, flash, ram and a few other things all in a CF/Cardbus/expressbus formfactor. You program it in a host with our tools. You run it either in the host or standalone. SN I don't understand the 'burden on software developers'. The code to do this will just be standard code. I got 16K of RAM for my boot loader and that 16K has to do alot more than just manage device trees. I think we have 2K left. In that I have to fit scripting, and ethernet, so where am I supposed to fit the standard code ? If the devicetree is say at the end of the bit file I can probably copy it to ram and pass a pointer to linux in maybe a couple of hundred bytes. If I have to do much more it ain't happening. The worst that one can say is: SN 1) I need several KB additional non volatile storage. Given the size of the FPGA bitstream, this can't be a huge constraint. Several KB is NOT happening. The bitstream is in flash. Flash is not a limited reasorce for us. FPGA cells, and BRAM are precious as gold. The more we use the less our clients have. Different systems are going to have different resource constraints. What is unlimited for me may be severely limited for someone else. What is unlimted for you may be seriously limited for me. I do agree that using more FPGA resources is not a solution to the problem. I'm already hitting 80% usage on a FX60 and trying to squeeze more real estate for storage of the device tree seems silly. Especially since that would require that every image have this extra hardware built into it just to support booting a Linux kernel. Why should I have to have different hardware to boot linux, versus non-kernel, xilkernel, or other (GHS, LynxOS, etc..)? One of the problems is that neither devicetrees, nor any of the ways of tracking them are one size fits all solutions. I do GHS work, it would be nice if GHS supported devicetrees and maybe it will. bound to the kernel, in a separate file, appended to the bitstream and in the FPGA fabric all have pluses and minuses. One reason I am harping on version registers is they are extremely cost cheap, can easily be made optional, and can be fairly easily incorporated into any OS (or no OS - we do that too). They are not a replacement for devicetrees. But they still have very important uses in many environments. SN Certainly.. But in a sense, these are all intermediate files on the path to the image on the board. Unless we are going to teach linux to read and interpret .bit files while loading, then devicetrees are intermediate in an entirely different sense. The hardware works fine regardless of whether their is a devicetree. But Linux may not boot. My objective is to get alot of software - linux, GHS, and standalone apps, to all load - from a single executables, accross multiple different bit
Re: Xilinx devicetrees
Stephen Neuendorffer wrote: In any event, why do you do this rather than just run out of the flash (or a ram copy of the flash?) This is not literally true, but the parameters are nearly the same - pretend we are using NAND flash and storing executables as elf files. We can not run from flash because: The code has not been relocated the flash is not persistent We do load the flash/elf file into DRAM dealing with elf issues along the way and then execute it. We can do something similar for devicetrees, actually just passing Linux the offset from the begining of flash to the devicetree would be sufficient. Or if finding the devicetree inside the bitsstream can be accomplished fairly simply, just passing the offset of the bit file. -- 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
Re: Xilinx devicetrees
On 11/26/07, Stephen Neuendorffer [EMAIL PROTECTED] wrote: -Original Message- From: David H. Lynch Jr. [mailto:[EMAIL PROTECTED] Sent: Monday, November 26, 2007 1:17 PM To: Koss, Mike (Mission Systems) Cc: Stephen Neuendorffer; Grant Likely; linuxppc-embedded Subject: Re: Xilinx devicetrees My objective is to get alot of software - linux, GHS, and standalone apps, to all load - from a single executables, accross multiple different bit images on several different (though deliberately similar) products. My Linux kernel needs to work regardless of the Pico card and regardless of the bit image, as done my GHS kernel, and And I need to do that in a severly resource constrained environment. I would hope that should make sense of my harping about version/capabilities registers. If I have maybe 10 possible peices of IP that may/maynot be present in a given FPGA and I am trying to dynamically configure - Linux/GHS/... to adapt to whatever it encounters and work as long as it is a viable combination. At best devicetrees are an extremly complex way of solving that - while version registers are a trivial way. I disagree. I'm not disputing that version registers are valuable. But I *am* disputing their value for device detection. It may work in your specific case of devices always in certain locations, but it does not help the general case where devices can be instantiated anywhere in the 4GB address space. It sounds like the real problem that you have is that even if you get device trees working for Linux, you still have the same problem for GHS, so from your perspective device trees don't help In embedded power.org land, device trees are becoming the recommended method for describing platform configuration for all embedded powerpc software. Not just Linux. So from that perspective device trees might help. 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
RE: Xilinx devicetrees
I don't know if packaging the device tree with the bitstream is the best way to go. It's possible that it could lead to headaches for certain systems that have security restrictions. Make it an option. Where are the systems with security restrictions going to get their hardware information ? Besides - though I am not aware off the top of my head of a bitstream decompliler, still if you have access to the bitstream you have access to the information about the device. We deal with alot of high security applications. Security restrictions have to make sense. blocking devicetrees for security reasons is like telling somebody they can have the manual in computer readable form, but not on paper. Further if you are going to boot an OS that requires devicetrees then the devicetree must be somewhere - whether it is appended to the bitstream, appended to the kernel, compiled into the kernel, in a separate file, it still has to be present. The devicetree itself is not the security concern, but the retrieval of it from the bitstream. If it is stored in the FPGA, it may be that accessing that stored information may not be probable at run-time. The worst that one can say is: SN 1) I need several KB additional non volatile storage. Given the size of the FPGA bitstream, this can't be a huge constraint. Several KB is NOT happening. The bitstream is in flash. Flash is not a limited reasorce for us. FPGA cells, and BRAM are precious as gold. The more we use the less our clients have. Which is why I'm proposing that it be an extra file that can be stored however. For one system, it could be stored in the FPGA using BRAM and it could be automatically available to kernel. For another system, it could be stored in FLASH and the bootloader may have to copy the data from FLASH to RAM. I do agree that using more FPGA resources is not a solution to the problem. I'm already hitting 80% usage on a FX60 and trying to squeeze more real estate for storage of the device tree seems silly. Especially since that would require that every image have this extra hardware built into it just to support booting a Linux kernel. Why should I have to have different hardware to boot linux, versus non-kernel, xilkernel, or other (GHS, LynxOS, etc..)? One of the problems is that neither devicetrees, nor any of the ways of tracking them are one size fits all solutions. I do GHS work, it would be nice if GHS supported devicetrees and maybe it will. bound to the kernel, in a separate file, appended to the bitstream and in the FPGA fabric all have pluses and minuses. One reason I am harping on version registers is they are extremely cost cheap, can easily be made optional, and can be fairly easily incorporated into any OS (or no OS - we do that too). They are not a replacement for devicetrees. But they still have very important uses in many environments. SN Certainly.. But in a sense, these are all intermediate files on SN the path to the image on the board. Unless we are going to teach linux to read and interpret .bit files while loading, then devicetrees are intermediate in an entirely different sense. The hardware works fine regardless of whether their is a devicetree. But Linux may not boot. You are correct, but I think a single self-contained file that has all of the hardware descriptions is much preferred to many header files, and #ifdef macro's to make sense of what is actually available at run-time. My objective is to get alot of software - linux, GHS, and standalone apps, to all load - from a single executables, accross multiple different bit images on several different (though deliberately similar) products. My Linux kernel needs to work regardless of the Pico card and regardless of the bit image, as done my GHS kernel, and And I need to do that in a severly resource constrained environment. I would hope that should make sense of my harping about version/capabilities registers. If I have maybe 10 possible peices of IP that may/maynot be present in a given FPGA and I am trying to dynamically configure - Linux/GHS/... to adapt to whatever it encounters and work as long as it is a viable combination. At best devicetrees are an extremly complex way of solving that - while version registers are a trivial way. As an example I know that if I have a UartLite, Keyhole, TEMAC, PIC, ... they will always be at specific addresses. We never move them. But I do not know for sure it they are present. A version register provides a fairly safe very efficient means of checking that a device is present (and establishing its version and maybe capabilites) - device trees might do the same thing but have alot higher overhead to do so. For your system, yes, you never move the location of the devices. But for others, we may add other pieces or multiple pieces and require them in multiple/different places. That's the beauty of the device
Re: LED heartbeat trigger - in_atomic() while allocs
Benedict, Michael wrote: I was playing around with the LED heartbeat trigger and it caught the BUG() code when trying to activate. Does anyone know why this call stack would be in_atomic()? Or any ideas for a patch that would allow the heartbeat trigger to allocate when it is not in atomic context? BUG: sleeping function called from invalid context at mm/slab.c:3024 in_atomic():1, irqs_disabled():0 Call Trace: [def3dd90] [c0008e60] show_stack+0x48/0x194 (unreliable) [def3ddc0] [c0014160] __might_sleep+0xd0/0xdc [def3dde0] [c0063e60] kmem_cache_zalloc+0xdc/0x12c [def3de00] [c01975c0] heartbeat_trig_activate+0x24/0x80 [def3de20] [c0196844] led_trigger_set+0x128/0x160 [def3de40] [c0196988] led_trigger_store+0x10c/0x1a8 [def3deb0] [c0162f40] class_device_attr_store+0x44/0x5c [def3dec0] [c00ae614] sysfs_write_file+0x114/0x1dc [def3def0] [c0068ea4] vfs_write+0x9c/0x110 [def3df10] [c0068ff4] sys_write+0x4c/0x90 [def3df40] [c000fc00] ret_from_syscall+0x0/0x38 --- Exception: c01 at 0xfe83818 LR = 0xfe35448 Kernel 2.6.22-4, powerpc, targeting an MPC 8347. From a brief glance at the code, looks like led_trigger_store is holding a rwlock while calling led_trigger_set. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: LED heartbeat trigger - in_atomic() while allocs
Thanks, yeah I see that now. I just changed the alloc to be GPF_ATOMIC for now, but I don't really know how this was intended to work. -Michael -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] rg] On Behalf Of Nathan Lynch Sent: Monday, November 26, 2007 2:37 PM To: Benedict, Michael Cc: linuxppc-embedded@ozlabs.org Subject: Re: LED heartbeat trigger - in_atomic() while allocs Benedict, Michael wrote: I was playing around with the LED heartbeat trigger and it caught the BUG() code when trying to activate. Does anyone know why this call stack would be in_atomic()? Or any ideas for a patch that would allow the heartbeat trigger to allocate when it is not in atomic context? BUG: sleeping function called from invalid context at mm/slab.c:3024 in_atomic():1, irqs_disabled():0 Call Trace: [def3dd90] [c0008e60] show_stack+0x48/0x194 (unreliable) [def3ddc0] [c0014160] __might_sleep+0xd0/0xdc [def3dde0] [c0063e60] kmem_cache_zalloc+0xdc/0x12c [def3de00] [c01975c0] heartbeat_trig_activate+0x24/0x80 [def3de20] [c0196844] led_trigger_set+0x128/0x160 [def3de40] [c0196988] led_trigger_store+0x10c/0x1a8 [def3deb0] [c0162f40] class_device_attr_store+0x44/0x5c [def3dec0] [c00ae614] sysfs_write_file+0x114/0x1dc [def3def0] [c0068ea4] vfs_write+0x9c/0x110 [def3df10] [c0068ff4] sys_write+0x4c/0x90 [def3df40] [c000fc00] ret_from_syscall+0x0/0x38 --- Exception: c01 at 0xfe83818 LR = 0xfe35448 Kernel 2.6.22-4, powerpc, targeting an MPC 8347. From a brief glance at the code, looks like led_trigger_store is holding a rwlock while calling led_trigger_set. ___ 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
Re: 85xx software reset problems from paulus.git
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. Can someone do a git-bisect and find the patch that breaks things? ACK. Exactly the same over here (mpc8540ads compatible). I added the global-utilities today as well, but reboot fails. if you are on a 8540 GUTS doesn't support hreset_req (8548 or newer). 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? Only the 8548 or newer CPUs have the GUTS HRESET_REQ ability that we use to reset. (8540, 8560, 8541, 8555 do not). - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
