* Re: MPC8641D PCI-Express error
From: Jon Loeliger @ 2008-02-21 15:58 UTC (permalink / raw)
To: Marco Stornelli; +Cc: Timur Tabi, LinuxPPC-Embedded
In-Reply-To: <47BD9ACE.1090003@coritel.it>
Marco Stornelli wrote:
>
> When I try to read some register from my FPGA (virtex5) I have this bus
> error:
Hmmm.... OK, so if we've eliminated PCI-E as a source
for this issue, it really must be in the Virtex support
somewhere then. Unfortunately, I know nothing about those,
and am not going to be much direct help there.
Sorry.
jdl
> Machine check in kernel mode.
> Caused by (from SRR1=149030): Transfer error ack signal
> Oops: Machine check, sig: 7 [#1]
> PREEMPT SMP NR_CPUS=2
> Modules linked in: virtex5
> LTT NESTING LEVEL : 0
> NIP: F108019C LR: F1080198 CTR: 00000001
> REGS: c044dd60 TRAP: 0200 Not tainted (2.6.18-mpc8641d_hpcn)
> MSR: 00149030 <EE,ME,IR,DR> CR: 22000222 XER: 00000000
> TASK = c20e9990[568] 'insmod' THREAD: c044c000 CPU: 0
> GPR00: F1080198 C044DE10 C20E9990 0000002E 80000000 FFFFFFFF 00008000
> 00002EA3
> GPR08: C20E9990 00000000 C04C0220 C044C000 22000222 1001956C 00000000
> 00000000
> GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 00000000
> GPR24: 3000EAA0 7FD6FDC0 00000000 C045FCC0 F107E594 F10A0000 00000000
> C2036000
> NIP [F108019C] virtex5_probe+0x130/0x1c4 [virtex5]
> LR [F1080198] virtex5_probe+0x12c/0x1c4 [virtex5]
> Call Trace:
> [C044DE10] [F1080198] virtex5_probe+0x12c/0x1c4 [virtex5] (unreliable)
> [C044DE30] [C01D2A58] pci_device_probe+0x84/0xbc
> [C044DE50] [C0213754] driver_probe_device+0x60/0x118
> [C044DE70] [C0213890] __driver_attach+0x84/0x88
> [C044DE90] [C02130F4] bus_for_each_dev+0x58/0x94
> [C044DEC0] [C02135D4] driver_attach+0x24/0x34
> [C044DED0] [C0212AC8] bus_add_driver+0x88/0x164
> [C044DEF0] [C021397C] driver_register+0x70/0xb8
> [C044DF00] [C01D284C] __pci_register_driver+0x64/0x98
> [C044DF10] [F1080030] init_module+0x30/0x6c [virtex5]
> [C044DF20] [C004CBFC] sys_init_module+0xc8/0x25c
> [C044DF40] [C0011358] ret_from_syscall+0x0/0x38
> --- Exception: c00 at 0xff6de0c
> LR = 0x10000de4
> Instruction dump:
> 40820060 3c60f108 3863cea0 48000311 807f0238 3c800001 48000395 7c7d1b78
> 3c60f108 3863ced4 480002f5 809d0000 <3c60f108> 3863cf04 480002e5 3c60f108
^ permalink raw reply
* Re: Block devices
From: Christoph Hellwig @ 2008-02-21 16:48 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: linux-fsdevel, linux-mtd, linuxppc-embedded
In-Reply-To: <47BD22D0.9060008@dlasys.net>
On Thu, Feb 21, 2008 at 02:05:52AM -0500, David H. Lynch Jr. wrote:
> Can I boot an initramfs kernel without a block device ?
Yes.
> Can I write a filesystem driver for a flash device that does not
> require a block device ?
Yes.
> Are their any examples of something even close ?
For that particular flash case there's just jffs2 in the kernel tree,
with some more flash filesystems under development. You can of
course have network and in-memory filesystems aswell.
^ permalink raw reply
* Re: Problems with plb_temac+hard_temac+2.6.24rc3
From: A. Nolson @ 2008-02-21 17:10 UTC (permalink / raw)
To: Rick Moleres; +Cc: linuxppc-embedded
In-Reply-To: <20080221022651.1383190008A@mail125-sin.bigfish.com>
That is correct. I changed to hard temac 3.00.a and everything seems to
work perfectly now.
Thank you very much for your help,
/A
Rick Moleres wrote:
> Try using hard_temac_v3_00_a with the ML403 board. There's an
> incompatibility (posted previously on this list) with PHY access. This
> could be causing the strange behavior you're seeing.
>
> -Rick
>
> -----Original Message-----
> From: linuxppc-embedded-bounces+moleres=xilinx.com@ozlabs.org
> [mailto:linuxppc-embedded-bounces+moleres=xilinx.com@ozlabs.org] On
> Behalf Of A. Nolson
> Sent: Wednesday, February 20, 2008 8:33 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: Problems with plb_temac+hard_temac+2.6.24rc3
>
> Hi,
>
> I am working with a ML403 platform and I have my kernel 2.6.24rc3
> perfectly running on it. Almost everything seems to work but the
> ethernet. I am using the IP cores that come with the EDK 9.1sp2 (
> plb_emac 3.00a + hard_temac 3.00b). The weird thing arises when I try to
>
> bring up the interface and use it. If I do "ifconfig eth0 up" the
> interface shows up but, strangely, it eithers not receives or send
> packets. I will explain myself, if I assing an IP manually and try to
> connect to another worksatation within the network ( by pinging from
> just one of the sides for example ) the interface seems only to send or
>
> receive packets , but generallty not both at the same time ( I can see
> this through the evolution of the Rx/Tx bytes in ifconfig). The only few
>
> times that both tx/rx work at the same time is when I do (ifconfig eth0
> down and ifconfig eth0 up), but this only works sporadically and only
> for around a second or less.
>
> This is what I get after the first "ifconfig eth0 up":
> [ 293.258765] eth0: XTemac: Options: 0xb8f2
>
> [ 295.253048] eth0: XTemac: speed set to 10Mb/s
>
> [ 295.256042] eth0: XTemac: Send Threshold = 16, Receive Threshold = 2
>
> [ 295.256095] eth0: XTemac: Send Wait bound = 1, Receive Wait bound = 1
>
> [ 297.252047] eth0: XTemac: PHY Link carrier lost.
>
> [ 299.251657] eth0: XTemac: PHY Link carrier restored.
>
>
> and this after some ifconfig up/down:
>
> [ 293.258765] eth0: XTemac: Options: 0xb8f2
>
> [ 295.253048] eth0: XTemac: speed set to 10Mb/s
>
> [ 295.256042] eth0: XTemac: Send Threshold = 16, Receive Threshold = 2
>
> [ 295.256095] eth0: XTemac: Send Wait bound = 1, Receive Wait bound = 1
>
> [ 297.252047] eth0: XTemac: PHY Link carrier lost.
>
> [ 299.251657] eth0: XTemac: PHY Link carrier restored.
>
> [ 438.159833] eth0: XTemac: Options: 0xb8f2
>
> [ 440.154122] eth0: XTemac: speed set to 1000Mb/s
>
> [ 440.157316] eth0: XTemac: Send Threshold = 16, Receive Threshold = 2
>
> [ 440.157369] eth0: XTemac: Send Wait bound = 1, Receive Wait bound = 1
>
> [ 442.153739] eth0: XTemac: PHY Link carrier lost.
>
> [ 511.255518] eth0: XTemac: Options: 0xb8f2
>
> [ 513.249808] eth0: XTemac: speed set to 10Mb/s
>
> [ 513.252729] eth0: XTemac: Send Threshold = 16, Receive Threshold = 2
>
> [ 513.252784] eth0: XTemac: Send Wait bound = 1, Receive Wait bound = 1
>
> [ 515.249462] eth0: XTemac: PHY Link carrier restored.
>
> [ 992.441619] eth0: XTemac: Options: 0xb8f2
>
> [ 994.435904] eth0: XTemac: speed set to 1000Mb/s
>
> [ 994.438786] eth0: XTemac: Send Threshold = 16, Receive Threshold = 2
>
> [ 994.438839] eth0: XTemac: Send Wait bound = 1, Receive Wait bound = 1
>
> [ 996.435460] eth0: XTemac: PHY Link carrier lost.
>
> [ 1099.850622] eth0: XTemac: Options: 0xb8f2
>
> [ 1101.844907] eth0: XTemac: speed set to 10Mb/s
>
> [ 1101.847816] eth0: XTemac: Send Threshold = 16, Receive Threshold = 2
>
> [ 1101.847868] eth0: XTemac: Send Wait bound = 1, Receive Wait bound = 1
>
> [ 1103.844479] eth0: XTemac: PHY Link carrier restored.
>
> [ 1180.024979] eth0: XTemac: Options: 0xb8f2
>
> [ 1182.019263] eth0: XTemac: speed set to 1000Mb/s
>
> [ 1182.022265] eth0: XTemac: Send Threshold = 16, Receive Threshold = 2
>
> [ 1182.022316] eth0: XTemac: Send Wait bound = 1, Receive Wait bound = 1
>
> [ 1184.018815] eth0: XTemac: PHY Link carrier lost.
>
>
> It also seems to negotiate wrongly the speed since my network is
> 100Mb/s.
>
> This is my dmesg before "ifconfig eth0 up":
>
> [ 0.000000] Linux version 2.6.24-rc3-gd7ed933b-dirty (ios@xxx) (gcc
> versio
> ion 4.0.0 (DENX ELDK 4.1 4.0.0)) #17 Mon Feb 18 11:52:47 CET
> 2008 [
> [ 0.000000] Xilinx ML403 Reference System (Virtex-4
> FX) [
> [ 0.000000] Entering add_active_range(0, 0, 16384) 0 entries of 256
> used [
> [ 0.000000] Zone PFN
> ranges: [
> [ 0.000000] DMA 0 ->
> 16384 [
> [ 0.000000] Normal 16384 ->
> 16384 [
> [ 0.000000] HighMem 16384 ->
> 16384 [
> [ 0.000000] Movable zone start PFN for each
> node [
> [ 0.000000] early_node_map[1] active PFN
> ranges [
> [ 0.000000] 0: 0 ->
> 16384 [
> [ 0.000000] On node 0 totalpages:
> 16384 [
> [ 0.000000] DMA zone: 128 pages used for
> memmap [
> [ 0.000000] DMA zone: 0 pages
> reserved [
> [ 0.000000] DMA zone: 16256 pages, LIFO
> batch:3 [
> [ 0.000000] Normal zone: 0 pages used for
> memmap [
> [ 0.000000] HighMem zone: 0 pages used for
> memmap [
> [ 0.000000] Movable zone: 0 pages used for
> memmap [
> [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on.
> Total pages
> es:
> 16256
>
> [
> [ 0.000000] Kernel command line: console=ttyS0,57600 root=/dev/xsa2
> rw init=/sb
> sbin/init
>
> [
> [ 0.000000] Xilinx INTC #0 at 0x41200000 mapped to
> 0xFDFFE000 [
> [ 0.000000] PID hash table entries: 256 (order: 8, 1024
> bytes) [
> [ 0.000189] Console: colour dummy device
> 80x25 [
> [ 0.000632] Dentry cache hash table entries: 8192 (order: 3, 32768
> bytes) [
> [ 0.001411] Inode-cache hash table entries: 4096 (order: 2, 16384
> bytes) [
> [ 0.015628] Memory: 61312k available (2744k kernel code, 780k data,
> 116k init,
> , 0k
> highmem)
>
> [
> [ 0.015942] SLUB: Genslabs=11, HWalign=32, Order=0-1, MinObjects=4,
> CPUs=1, Nod
> odes=1
>
> [
> [ 0.015988] Calibrating delay loop... 199.47 BogoMIPS
> (lpj=997376) [
> [ 0.210274] Mount-cache hash table entries:
> 512 [
> [ 0.214569] net_namespace: 64
> bytes [
> [ 0.220610] NET: Registered protocol family
> 16 [
> [ 0.268325] NET: Registered protocol family
> 2 [
> [ 0.350699] IP route cache hash table entries: 1024 (order: 0, 4096
> bytes) [
> [ 0.353529] TCP established hash table entries: 2048 (order: 2, 16384
>
> bytes) [
> [ 0.353862] TCP bind hash table entries: 2048 (order: 1, 8192
> bytes) [
> [ 0.354067] TCP: Hash tables configured (established 2048 bind
> 2048) [
> [ 0.354107] TCP reno
> registered [
> [ 0.381445] sysctl table check failed: /kernel/l2cr .1.31 Missing
> strategy [
> [ 0.381529] Call
> Trace: [
> [ 0.381556] [c3c11e80] [c0008380] show_stack+0x4c/0x174
> (unreliable) [
> [ 0.381653] [c3c11eb0] [c0037170]
> set_fail+0x50/0x68 [
> [ 0.381735] [c3c11ed0] [c00377f8]
> sysctl_check_table+0x670/0x6bc [
> [ 0.381804] [c3c11f10] [c003780c]
> sysctl_check_table+0x684/0x6bc [
> [ 0.381871] [c3c11f50] [c0024e7c]
> register_sysctl_table+0x5c/0xac [
> [ 0.381953] [c3c11f70] [c034ab68]
> register_ppc_htab_sysctl+0x18/0x2c [
> [ 0.382040] [c3c11f80] [c034484c]
> kernel_init+0xc8/0x284 [
> [ 0.382103] [c3c11ff0] [c0004b18]
> kernel_thread+0x44/0x60 [
> [ 0.442249] Installing knfsd (copyright (C) 1996
> okir@monad.swb.de). [
> [ 0.447391] JFS: nTxBlock = 479, nTxLock =
> 3832 [
> [ 0.450534] SGI XFS with ACLs, large block numbers, no debug
> enabled [
> [ 0.466636] io scheduler noop
> registered [
> [ 0.466687] io scheduler anticipatory
> registered [
> [ 0.466722] io scheduler deadline
> registered [
> [ 0.467224] io scheduler cfq registered
> (default) [
> [ 1.069672] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ
> sharing di
> disabled
>
> [
> [ 1.078357] serial8250.0: ttyS0 at MMIO 0x40401003 (irq = 3) is a
> 16550A [
> [ 1.078443] console [ttyS0]
> enabled [
> [ 1.621990] RAMDISK driver initialized: 16 RAM disks of 4096K size
> 1024 blocksi
> size
>
> [
> [ 1.644429] loop: module
> loaded [
> [ 1.651930] xsysace xsysace.0: Xilinx SystemACE revision
> 1.0.12 [
> [ 1.664582] xsysace xsysace.0: capacity: 1019088
> sectors [
> [ 1.675836] xsa: xsa1 xsa2
> xsa3 [
> [ 1.688906] Xilinx SystemACE device driver,
> major=254 [
> [ 1.700197] nbd: registered device at major
> 43 [
> [ 1.728380] XTemac: using sgDMA
> mode. [
> [ 1.735840] XTemac: using TxDRE
> mode [
> [ 1.743198] XTemac: using RxDRE
> mode [
> [ 1.750455] XTemac: buffer descriptor size: 32768
> (0x8000) [
> [ 1.762007] XTemac: (buffer_descriptor_init) phy: 0x3d98000, virt:
> 0xff100000,
> , size:
> 0x8000
> [
> [ 1.785641] eth%d: XTemac: No PHY detected. Assuming a PHY at
> address 0 [
> [ 1.799277] eth0: Dropping NETIF_F_SG since no checksum
> feature. [
> [ 1.814696] eth0: Xilinx TEMAC #0 at 0x81200000 mapped to 0xC5060000,
>
> irq=0 [
> [ 1.828792] eth0: XTemac id 1.0f, block id 5, type
> 8 [
> [ 1.840200] NFTL driver: nftlcore.c $Revision: 1.98 $, nftlmount.c
> $Revision: 1
> 1.41
> $
> [
> [ 1.856295] INFTL: inftlcore.c $Revision: 1.19 $, inftlmount.c
> $Revision: 1.18
> 8
> $
>
> [
> [ 1.872015] SSFDC read-only Flash Translation
> layer [
> [ 1.885404] i8042.c: No controller
> found. [
> [ 1.895700] mice: PS/2 mouse device common for all
> mice [
> [ 1.908819] i2c /dev entries
> driver [
> [ 1.917372] TCP cubic
> registered [
> [ 1.924238] NET: Registered protocol family
> 1 [
> [ 1.933271] NET: Registered protocol family
> 17 [
> [ 1.944649] RPC: Registered udp transport
> module. [
> [ 1.954206] RPC: Registered tcp transport
> module. [
> [ 4.575003] kjournald starting. Commit interval 5
> seconds [
> [ 4.586220] EXT3-fs warning: maximal mount count reached, running
> e2fsck is rec
> ecommended
>
> [
> [ 4.641727] EXT3 FS on xsa2, internal
> journal [
> [ 4.650587] EXT3-fs: recovery
> complete. [
> [ 4.697624] EXT3-fs: mounted filesystem with ordered data
> mode. [
> [ 4.709702] VFS: Mounted root (ext3
> filesystem). [
> [ 4.719390] Freeing unused kernel memory: 116k
> init
> ba
>
> Any idea of what it can be?
>
> Thanks in advance!
>
> /A
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
>
>
^ permalink raw reply
* make zImage.initrd failure (was: Re: [PATCH v4] [POWERPC] bootwrapper: build multiple cuImages)
From: Geert Uytterhoeven @ 2008-02-21 17:22 UTC (permalink / raw)
To: Grant Likely; +Cc: Linux/PPC Development, Hiroaki Fuse
In-Reply-To: <20080206181833.13239.70510.stgit@trillian.secretlab.ca>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 4818 bytes --]
Hi Grant,
On Wed, 6 Feb 2008, Grant Likely wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> Currently, the kernel uses CONFIG_DEVICE_TREE to wrap a kernel image
> with a fdt blob which means for any given configuration only one dts
> file can be selected and so support for only one board can be built
>
> This patch moves the selection of the default .dts file out of the kernel
> config and into the bootwrapper makefile. The makefile chooses which
> images to build based on the kernel config and the dts source file
> name is taken directly from the image name. For example "cuImage.ebony"
> will use "ebony.dts" as the device tree source file.
>
> In addition, this patch allows a specific image to be requested from the
> command line by adding "cuImage.%" and "treeImage.%" targets to the list
> of valid built targets in arch/powerpc/Makefile. This allows the default
> dts selection to be overridden.
>
> Another advantage to this change is it allows a single defconfig to be
> supplied for all boards using the same chip family and only differing in
> the device tree.
>
> Important note: This patch adds two new zImage targets; zImage.dtb.% and
> zImage.dtb.initrd.% for zImages with embedded dtb files. Currently
> there are 5 platforms which require this: ps3, ep405, mpc885ads, ep88xc,
> adder875-redboot and ep8248e. This patch *changes the zImage filenames*
> for those platforms. ie. 'zImage.ps3' is now 'zImage.dtb.ps3'.
>
> This new zImage.dtb targets were added so that the .dts file could be
> part of the dependancies list for building them.
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
>
> ---
> v4: removed mpc837x_mds and mpc8313erdb cuimages and changed mpc885ads to
> a cuImage
>
> v3: I think this patch is complete. Renamed zImage.dtb.% targets to
> zImage-dtb.% to avoid make choosing the wrong rule if the dts file is missing.
>
> v2: This version fixes some bugs and adds new zImage.dtb and
> zImage.initrd.dtb targets.
>
> v1: Please review and comment. I have not exhaustively tested this patch
> and I'm sure to have missed some boards. However, I think the concept
> is sound and will be a good change.
Fuse-san discovered we can no longer do `make zImage.initrd' when building for
PS3:
| WRAP arch/powerpc/boot/zImage.initrd-dtb.ps3
| ppu-ld: arch/powerpc/boot/initrd-dtb.ps3.o: No such file: No such file or directory
| make[3]: *** [arch/powerpc/boot/zImage.initrd-dtb.ps3] Error 1
| make[2]: *** [zImage.initrd] Error 2
| make[1]: *** [sub-make] Error 2
| make: *** [all] Error 2
It can easily be reproduced using `make ps3_defconfig; make zImage.initrd'.
There seem to be two problems:
1. Before this patch, the generated build target was `zImage.initrd.ps3'.
After this patch, the generated build target is `zImage.initrd-dtb.ps3'.
Now `initrd-dtb.ps3' is passed to the boot wrapper as the `platform'
parameter, which of course no longer matches the `ps3' test case in the
boot wrapper script.
The patch below works around this problem, but I don't think it's the
proper fix.
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index c317815..aec4414 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -182,7 +182,7 @@ cuboot*)
;;
esac
;;
-ps3)
+*ps3)
platformo="$object/ps3-head.o $object/ps3-hvcall.o $object/ps3.o"
lds=$object/zImage.ps3.lds
gzip=
> # Don't put the ramdisk on the pattern rule; when its missing make will try
> # the pattern rule with less dependencies that also matches (even with the
> # hard dependency listed).
> -$(obj)/zImage.initrd.%: vmlinux $(wrapperbits) $(dts)
> - $(call if_changed,wrap,$*,$(dts),,$(obj)/ramdisk.image.gz)
> +$(obj)/zImage.initrd.%: vmlinux $(wrapperbits)
> + $(call if_changed,wrap,$*,,,$(obj)/ramdisk.image.gz)
>
> -$(obj)/zImage.%: vmlinux $(wrapperbits) $(dts)
> - $(call if_changed,wrap,$*,$(dts))
> +$(obj)/zImage.%: vmlinux $(wrapperbits)
> + $(call if_changed,wrap,$*)
2. The generated build target `zImage.initrd-dtb.ps3' matches both rules,
and of course the wrong one (the second one) is chosen by make, causing
the ramdisk image not to be included.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply related
* Xilinx Temac link detect
From: khollan @ 2008-02-21 17:36 UTC (permalink / raw)
To: linuxppc-embedded
Hi
Is there a good way to detect if the ethernet link is active at boot time,
so I can decided to setup the dchp and other network required stuff in an
init script. When I try to setup this stuff and the cable is disconnected
it hangs.
Thanks
Kevin
--
View this message in context: http://www.nabble.com/Xilinx-Temac-link-detect-tp15616042p15616042.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: TLB Miss booting linux kernel on ppc 405
From: Ricardo Ayres Severo @ 2008-02-21 17:50 UTC (permalink / raw)
To: David Baird; +Cc: linuxppc-embedded
In-Reply-To: <440abda90802201347w3945c53dhf47ffd0380aa01aa@mail.gmail.com>
Hi David,
I rebuilt the design in EDK 9.2i and problem persisted. The only
difference is the registers are not zeroing anymore. No exception is
thrown, and the system still hangs at memset_io. I'm running out of
options.
It is possible to boot Linux on Virtex-II, isn't?
Thanks,
On Wed, Feb 20, 2008 at 7:47 PM, David Baird <dhbaird@gmail.com> wrote:
> Hi Ricardo,
>
>
> On Feb 20, 2008 2:29 PM, Ricardo Ayres Severo <severo.ricardo@gmail.com> wrote:
> > I didn't solve the problem yet. I'm having problems with the memset_io
> > in early_init and am studying if the SDRAM is initializing right.
> > Any progress I'll send to the list.
>
> It sounds suspiciously like you might be having this problem:
>
> http://www.nabble.com/Problem-booting-Linux-2.6-on-Virtex-4-td14795525.html
> "Things start to go obviously wrong after early_init calls memset to
> clear the .bss section."
>
> I don't know what the cause of the problem was, but the symptom is
> that different memory regions were aliased onto each other (it was
> like an address bit wasn't working or something funny was happening
> with the cache ... but only in virtual mode). The problem was fixed
> after rebuilding the design in EDK 9.2i. I don't know what caused the
> problem originally though.
>
> Let us know if you get this resolved or have more questions... I
> might not be able answer, but hopefully someone can help.
>
> -David
>
--
Ricardo Ayres Severo <severo.ricardo@gmail.com>
^ permalink raw reply
* RE: Xilinx PowerPC
From: Stephen Neuendorffer @ 2008-02-21 17:50 UTC (permalink / raw)
To: David H. Lynch Jr., Grant Likely, linuxppc-embedded
In-Reply-To: <47BD212B.6090809@dlasys.net>
> -----Original Message-----
> From: linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org
[mailto:linuxppc-embedded-
> bounces+stephen=3Dneuendorffer.name@ozlabs.org] On Behalf Of David H.
Lynch Jr.
> Sent: Wednesday, February 20, 2008 10:59 PM
> To: Grant Likely; linuxppc-embedded
> Subject: Xilinx PowerPC
>=20
>=20
> So when you have Xilinx under powerpc working, do we pull it from
your
> git tree or the xilinx one ?
>=20
> Will there be an announcement ?
>=20
> How about a one paragraph getting started guide to moving a xilinx
> ppc bsp to
> xilinx powerpc.
>=20
> Like ?
>=20
> step 1).
> Generate a dts - gen-mhs-devicetree ?
> And pass it to through your boot loader to Linux ?
http://git.xilinx.com/gen-mhs-devtree.git contains two utilities for
generating device trees from EDK projects. The older option is a python
script, originally written by Grant. The newer (and probably more
mature at this point) option is an EDK BSP generator for u-boot,
originally written by Michal Simek. Preferably this gets passed from a
uboot, although it's also possible to compile it into the kernel.
Currently, the uboot option is somewhat annoying because there's not a
good surefire way for getting uboot up and running on an EDK design.
(Unfortunately, the EDK BSP generator is incomplete, and the uboot
support for virtex needs some work to get it integrated as well).
> Step 2).
> the code in arch/powerpc/???? is the devicetree equvalent
to
> arch/ppc/platforms/4xx/xilinx_ml410.c
http://git.xilinx.com/linux-2.6-xlnx.git contains a preliminary stab at
the bootcode for Virtex. I've been using this for a while with
ARCH=3Dpowerpc. There isn't really much need for board specific =
platform
code: This should (I think) be handled by the device tree. All of this
is still pretty preliminary at the moment however. The big problem with
the boot code in the Xilinx tree is that you need to be able to allocate
memory in order to parse the device tree in order to figure out how much
memory you have. I just haven't rewritten the code to use libfdt, which
can query the device tree without memory allocation yet. Grant has a
slightly different scheme in his tree, but it works as well. Generally
I've been more focused on avoiding u-boot, whereas Grant has been using
u-boot exclusively, I think.
> Step 3).
> device drivers need to change initialization/setup from
> ???? to ???
All the xilinx drivers in mainline and most of the ones in the
git.xilinx.com tree export both platform device and of_device
interfaces. You should be able to look at any of them to figure out a
good way of adding of_device support to a driver. the ll_temac is by
far the most complex instance of this, which has to do some non-trivial
traversal of the device tree to discover the information it needs about
it's interface to memory.
So, the short answer is, you might be able to get it to work today, but
the code isn't in shape for mainline yet.
Steve
^ permalink raw reply
* Re: initramfs problem - /init file
From: raul.moreno @ 2008-02-21 16:05 UTC (permalink / raw)
To: dhlii; +Cc: linuxppc-embedded
In-Reply-To: <47BD9936.2000400@dlasys.lcl>
Hi Dave,
I have just figured out the problem... an stupid error... By mistake I =
took
the filesystem compiled to intel instead to ppc. I guess I forgot to as=
sign
the right cross-compile toolchain. So the microprocessor can't execute =
the
init file.
Now it works.
Anyway thank you for your time.
Ra=FAl Moreno
"David H. Lynch Jr." <dhlii@dlasys.lcl>
"David H. Lynch Jr."
21/02/2008 16:31
Por favor, responda a dhlii
=
Para: raul.moreno@telvent.abengoa.com =
=
cc: linuxppc-embedded <linuxppc-embedded@ozlabs.org> =
=
Asunto: Re: initramfs problem - /init file =
=
raul.moreno@telvent.abengoa.com wrote:
> Hello Dave,
>
> thanks for your answer. I agree with you, the easy way is to assign t=
he
> rootfs directory. I gave the filesystem as a cpio file because it is =
the
> same (the kernel takes the rootfs and converts it to a cpio format), =
but
> the compilation is faster. Anyway, although now I do as you said, I s=
till
> get the error:
> "Failed to execute /init
> Kernel panic - not syncing: No init found. Try passing init=3D optio=
n to
> kernel."
> I can't understand why it happens. I check the permission of /init an=
d
> /sbin/init and everything seems to me OK.
>
> Any idea?
>
I have had the same problem.
Things I can remember:
Permissions,
console setup,
watch out for symbolic links to init.
Also is your init and executable or script ?
I think you get this failure if ANYTHING goes wrong exec'ing
init.
Like - it found init but could not execute a shell.
or the shell required a library it could not find.
Or something is not quite right with your Virtual memory -
Linux exec's by forcing chained page faults.
One thing I tried was a simple "hello world" in ppc assembler -
no libraries,
and named it /init. When it succeeded I was able to narrow my
problem down..
Then tried a "hello world" in C with a static library, then
dynamic, then ...
Basically building more and more complex /init's until I isolate=
d
what was failing.
> Ra=FAl Moreno
>
>
>
>
--
Dave Lynch
DLA Systems
Software Development:
Embedded Linux
717.627.3770 dhlii@dlasys.net
http://www.dlasys.net
fax: 1.253.369.9244 Cell:=
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 tak=
es a
touch of genius - and a lot of courage to move in the opposite directio=
n."
Albert Einstein
=
^ permalink raw reply
* Re: TLB Miss booting linux kernel on ppc 405
From: David Baird @ 2008-02-21 18:00 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <5ee408090802210950t498b9752meab2b91d2a13191c@mail.gmail.com>
On Thu, Feb 21, 2008 at 10:50 AM, Ricardo Ayres Severo
<severo.ricardo@gmail.com> wrote:
> I rebuilt the design in EDK 9.2i and problem persisted. The only
> difference is the registers are not zeroing anymore. No exception is
> thrown, and the system still hangs at memset_io. I'm running out of
> options.
> It is possible to boot Linux on Virtex-II, isn't?
Yes, it is possible. I have a Virtex-II Pro with Linux running on it
although I didn't configure it myself (it is one of those Black Dog
computers). I work with Virtex-4s right now.
Can you try a reference design for the Virtex-II perhaps?
Can you comment out memset_io and write your own version of it (which
you can insert debug statements into)?
When/where in memset are things breaking? What is the nature of the
breaking? Can you get your serial terminal to print out hex values
(for memory locations, memory values, etc.)?
^ permalink raw reply
* Re: TLB Miss booting linux kernel on ppc 405
From: David Baird @ 2008-02-21 18:04 UTC (permalink / raw)
To: linuxppc-embedded, Robert Woodworth
In-Reply-To: <1203542646.4812.38.camel@PisteOff>
Hi Robert,
On Wed, Feb 20, 2008 at 2:24 PM, Robert Woodworth
<rwoodworth@securics.com> wrote:
> I'm under the suspicion that the PLB is issuing an error when switching
> to virtual mode and that there is either a timing/synthesis error or a
> fundamental error with the way the FPGA is getting synthesized with the
> PLB.
Can you offer a suggestion how I can check to see if the PLB is
issuing an error (a good application note for me to read or anything)?
I was having a similar problem in virtual mode on one of my systems,
and I might be able to see also if I am having a problem with the PLB
bus.
-David
^ permalink raw reply
* [PATCH] [POWERPC] Fix zImage-dtb.initrd build error
From: Grant Likely @ 2008-02-21 18:57 UTC (permalink / raw)
To: Geert.Uytterhoeven, linuxppc-dev; +Cc: miltonm, paulus, Hiroaki_Fuse
From: Grant Likely <grant.likely@secretlab.ca>
The pattern substitution rules were failing when used with zImage-dtb
targets. if zImage-dtb.initrd was selected, the pattern substitution
would generate "zImage.initrd-dtb" instead of "zImage-dtb.initrd" which
caused the build to fail.
This patch renames zImage-dtb to dtbImage to avoid the problem entirely.
By not using the zImage prefix then is no potential for namespace
collisions.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
Note to reviewers. Please consider this change carefully. I saw two
options for fixing this bug;
1) rework the pattern substitution to handle zImage-dtb correctly
2) avoid using the zImage prefix
I chose option 2 because it avoids increasing the complexity of the
pattern substitution code for generating initrd names. However, doing
so will have an impact on distributors because it changes the name of
the generated image. If this is a problem for anyone, or if you have
a better name suggestion than "dtbImage", then please speak up.
Cheers,
g.
---
arch/powerpc/Makefile | 2 +-
arch/powerpc/boot/Makefile | 18 ++++++++++--------
2 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 1c6ce35..ab5cfe8 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -155,7 +155,7 @@ all: zImage
CPPFLAGS_vmlinux.lds := -Upowerpc
-BOOT_TARGETS = zImage zImage.initrd uImage treeImage.% cuImage.%
+BOOT_TARGETS = zImage zImage.initrd uImage zImage% dtbImage% treeImage.% cuImage.%
PHONY += $(BOOT_TARGETS)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 63d07cc..d57a67d 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -186,7 +186,7 @@ quiet_cmd_wrap = WRAP $@
image-$(CONFIG_PPC_PSERIES) += zImage.pseries
image-$(CONFIG_PPC_MAPLE) += zImage.pseries
image-$(CONFIG_PPC_IBM_CELL_BLADE) += zImage.pseries
-image-$(CONFIG_PPC_PS3) += zImage-dtb.ps3
+image-$(CONFIG_PPC_PS3) += dtbImage.ps3
image-$(CONFIG_PPC_CELLEB) += zImage.pseries
image-$(CONFIG_PPC_CHRP) += zImage.chrp
image-$(CONFIG_PPC_EFIKA) += zImage.chrp
@@ -205,7 +205,7 @@ image-$(CONFIG_DEFAULT_UIMAGE) += uImage
#
# Board ports in arch/powerpc/platform/40x/Kconfig
-image-$(CONFIG_EP405) += zImage-dtb.ep405
+image-$(CONFIG_EP405) += dtbImage.ep405
image-$(CONFIG_WALNUT) += treeImage.walnut
# Board ports in arch/powerpc/platform/44x/Kconfig
@@ -220,9 +220,9 @@ image-$(CONFIG_WARP) += cuImage.warp
# Board ports in arch/powerpc/platform/8xx/Kconfig
image-$(CONFIG_PPC_MPC86XADS) += cuImage.mpc866ads
image-$(CONFIG_PPC_MPC885ADS) += cuImage.mpc885ads
-image-$(CONFIG_PPC_EP88XC) += zImage-dtb.ep88xc
+image-$(CONFIG_PPC_EP88XC) += dtbImage.ep88xc
image-$(CONFIG_PPC_ADDER875) += cuImage.adder875-uboot \
- zImage-dtb.adder875-redboot
+ dtbImage.adder875-redboot
# Board ports in arch/powerpc/platform/52xx/Kconfig
image-$(CONFIG_PPC_LITE5200) += cuImage.lite5200 cuImage.lite5200b
@@ -230,7 +230,7 @@ image-$(CONFIG_PPC_LITE5200) += cuImage.lite5200 cuImage.lite5200b
# Board ports in arch/powerpc/platform/82xx/Kconfig
image-$(CONFIG_MPC8272_ADS) += cuImage.mpc8272ads
image-$(CONFIG_PQ2FADS) += cuImage.pq2fads
-image-$(CONFIG_EP8248E) += zImage-dtb.ep8248e
+image-$(CONFIG_EP8248E) += dtbImage.ep8248e
# Board ports in arch/powerpc/platform/83xx/Kconfig
image-$(CONFIG_MPC832x_MDS) += cuImage.mpc832x_mds
@@ -268,7 +268,8 @@ endif
initrd- := $(patsubst zImage%, zImage.initrd%, $(image-n) $(image-))
initrd-y := $(patsubst zImage%, zImage.initrd%, \
- $(patsubst treeImage%, treeImage.initrd%, $(image-y)))
+ $(patsubst dtbImage%, dtbImage.initrd%, \
+ $(patsubst treeImage%, treeImage.initrd%, $(image-y))))
initrd-y := $(filter-out $(image-y), $(initrd-y))
targets += $(image-y) $(initrd-y)
@@ -283,10 +284,11 @@ $(obj)/zImage.initrd.%: vmlinux $(wrapperbits)
$(obj)/zImage.%: vmlinux $(wrapperbits)
$(call if_changed,wrap,$*)
-$(obj)/zImage-dtb.initrd.%: vmlinux $(wrapperbits) $(dtstree)/%.dts
+# dtbImage% - a dtbImage is a zImage with an embedded device tree blob
+$(obj)/dtbImage.initrd.%: vmlinux $(wrapperbits) $(dtstree)/%.dts
$(call if_changed,wrap,$*,$(dtstree)/$*.dts,,$(obj)/ramdisk.image.gz)
-$(obj)/zImage-dtb.%: vmlinux $(wrapperbits) $(dtstree)/%.dts
+$(obj)/dtbImage.%: vmlinux $(wrapperbits) $(dtstree)/%.dts
$(call if_changed,wrap,$*,$(dtstree)/$*.dts)
# This cannot be in the root of $(src) as the zImage rule always adds a $(obj)
^ permalink raw reply related
* Re: Xilinx PowerPC
From: Grant Likely @ 2008-02-21 19:02 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-embedded
In-Reply-To: <20080221175025.7817BBD8057@mail91-sin.bigfish.com>
On Thu, Feb 21, 2008 at 10:50 AM, Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com> wrote:
> > Step 2).
> > the code in arch/powerpc/???? is the devicetree equvalent
> to
> > arch/ppc/platforms/4xx/xilinx_ml410.c
> http://git.xilinx.com/linux-2.6-xlnx.git contains a preliminary stab at
> the bootcode for Virtex. I've been using this for a while with
> ARCH=powerpc. There isn't really much need for board specific platform
> code: This should (I think) be handled by the device tree. All of this
> is still pretty preliminary at the moment however. The big problem with
> the boot code in the Xilinx tree is that you need to be able to allocate
> memory in order to parse the device tree in order to figure out how much
> memory you have. I just haven't rewritten the code to use libfdt, which
> can query the device tree without memory allocation yet. Grant has a
> slightly different scheme in his tree, but it works as well. Generally
> I've been more focused on avoiding u-boot, whereas Grant has been using
> u-boot exclusively, I think.
Actually, I'm not using u-boot at all. I've reworked the 'raw' image
target to use libfdt and properly initialize the cache and stuff.
I'll be merging it in the .26 merge window.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: TLB Miss booting linux kernel on ppc 405
From: Robert Woodworth @ 2008-02-21 19:12 UTC (permalink / raw)
To: David Baird; +Cc: linuxppc-embedded
In-Reply-To: <440abda90802211004h3833ed00ke1cdc1257e2b0379@mail.gmail.com>
I'm no expert but....
I did configure my device with the DCR enabled and connected the PLBv46
DCR to the PPC. In the TLB miss ISR I read the PLB registers and the
MCSR I *DID* notice that the PLB error registers were set.
I added some asm code to read MCSR (see Xilinx UG011.pdf, page 213) and
I also added the asm code to read the DCR of the PLB. Sure enough, the
MCSR and PLB-DCR registers showed a DPLBError.
It's only a couple of asm statements:
mfspr r30, 0x23c
Question to Xilinx experts:
What would cause the PLB to issue the DPLBError?????
<note to Xilinx>
Hey Xilinx guys!
Can you hack the gdb included with EDK such that it will recognize the
MCSR when gdb reads registers!
</note to Xilinx>
On Thu, 2008-02-21 at 11:04 -0700, David Baird wrote:
> Hi Robert,
>
> On Wed, Feb 20, 2008 at 2:24 PM, Robert Woodworth
> <rwoodworth@securics.com> wrote:
> > I'm under the suspicion that the PLB is issuing an error when switching
> > to virtual mode and that there is either a timing/synthesis error or a
> > fundamental error with the way the FPGA is getting synthesized with the
> > PLB.
>
> Can you offer a suggestion how I can check to see if the PLB is
> issuing an error (a good application note for me to read or anything)?
> I was having a similar problem in virtual mode on one of my systems,
> and I might be able to see also if I am having a problem with the PLB
> bus.
>
> -David
^ permalink raw reply
* [PATCH] [POWERPC] add target for building .dtb files
From: Grant Likely @ 2008-02-21 19:19 UTC (permalink / raw)
To: linuxppc-dev, jwboyer
From: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
Josh, is this what your were looking for?
Cheers,
g.
---
arch/powerpc/Makefile | 2 +-
arch/powerpc/boot/Makefile | 4 ++++
2 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index ab5cfe8..dd80825 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -164,7 +164,7 @@ boot := arch/$(ARCH)/boot
$(BOOT_TARGETS): vmlinux
$(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
-bootwrapper_install:
+bootwrapper_install %.dtb:
$(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
define archhelp
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index d57a67d..fb29f10 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -311,6 +311,10 @@ $(obj)/treeImage.initrd.%: vmlinux $(dtstree)/%.dts $(wrapperbits)
$(obj)/treeImage.%: vmlinux $(dtstree)/%.dts $(wrapperbits)
$(call if_changed,wrap,treeboot-$*,$(dtstree)/$*.dts)
+# Rule to build device tree blobs
+$(obj)/%.dtb: $(dtstree)/%.dts $(obj)/dtc
+ $(obj)/dtc -O dtb -o $(obj)/$*.dtb -b 0 $(dtstree)/$*.dts
+
# If there isn't a platform selected then just strip the vmlinux.
ifeq (,$(image-y))
image-y := vmlinux.strip
^ permalink raw reply related
* [PATCH] [POWERPC] 8xx: timebase frequency should not depend on bus-frequency
From: Anton Vorontsov @ 2008-02-21 19:45 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Scott Wood
m8xx_setup.c says:
/* Force all 8xx processors to use divide by 16 processor clock. */
And at the same time it is using bus-frequency for calculating
timebase. It is okay for most setups because bus-frequency is
equal to clock-frequency.
The problem emerges when cpu frequency is > 66MHz, quoting
u-boot/cpu/mpc8xx/speed.c:
if (gd->cpu_clk <= 66000000) {
sccr_reg |= SCCR_EBDF00; /* bus division factor = 1 */
gd->bus_clk = gd->cpu_clk;
} else {
sccr_reg |= SCCR_EBDF01; /* bus division factor = 2 */
gd->bus_clk = gd->cpu_clk / 2;
}
So in case of cpu clock > 66MHz, bus_clk = cpu_clk / 2. An then, from
Linux, we calculate timebase frequency as tb_freq = bus_clk / 16,
that is cpu_clk / 2 / 16, which is wrong.
This patch fixes system time drifting problem on the EP885C board
running at 133MHz.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/platforms/8xx/m8xx_setup.c | 7 +------
1 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/platforms/8xx/m8xx_setup.c b/arch/powerpc/platforms/8xx/m8xx_setup.c
index 184f998..0d9f75c 100644
--- a/arch/powerpc/platforms/8xx/m8xx_setup.c
+++ b/arch/powerpc/platforms/8xx/m8xx_setup.c
@@ -111,17 +111,12 @@ void __init mpc8xx_calibrate_decr(void)
/* Processor frequency is MHz.
*/
- ppc_tb_freq = 50000000;
- if (!get_freq("bus-frequency", &ppc_tb_freq)) {
- printk(KERN_ERR "WARNING: Estimating decrementer frequency "
- "(not found)\n");
- }
- ppc_tb_freq /= 16;
ppc_proc_freq = 50000000;
if (!get_freq("clock-frequency", &ppc_proc_freq))
printk(KERN_ERR "WARNING: Estimating processor frequency "
"(not found)\n");
+ ppc_tb_freq = ppc_proc_freq / 16;
printk("Decrementer Frequency = 0x%lx\n", ppc_tb_freq);
/* Perform some more timer/timebase initialization. This used
--
1.5.2.2
^ permalink raw reply related
* Re: [PATCH] [POWERPC] 8xx: timebase frequency should not depend on bus-frequency
From: Scott Wood @ 2008-02-21 19:48 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20080221194508.GA12896@localhost.localdomain>
Anton Vorontsov wrote:
> diff --git a/arch/powerpc/platforms/8xx/m8xx_setup.c b/arch/powerpc/platforms/8xx/m8xx_setup.c
> index 184f998..0d9f75c 100644
> --- a/arch/powerpc/platforms/8xx/m8xx_setup.c
> +++ b/arch/powerpc/platforms/8xx/m8xx_setup.c
> @@ -111,17 +111,12 @@ void __init mpc8xx_calibrate_decr(void)
>
> /* Processor frequency is MHz.
> */
> - ppc_tb_freq = 50000000;
> - if (!get_freq("bus-frequency", &ppc_tb_freq)) {
> - printk(KERN_ERR "WARNING: Estimating decrementer frequency "
> - "(not found)\n");
> - }
> - ppc_tb_freq /= 16;
> ppc_proc_freq = 50000000;
> if (!get_freq("clock-frequency", &ppc_proc_freq))
> printk(KERN_ERR "WARNING: Estimating processor frequency "
> "(not found)\n");
>
> + ppc_tb_freq = ppc_proc_freq / 16;
Shouldn't we just use the timebase-frequency property?
-Scott
^ permalink raw reply
* [PATCH] [USB POWERPC] ehci: fix ppc build
From: Anton Vorontsov @ 2008-02-21 19:49 UTC (permalink / raw)
To: linuxppc-dev; +Cc: dbrownell, linux-usb
Currently, this setup:
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_HCD_PPC_OF=y
Will fail to build:
CC drivers/usb/host/ehci-hcd.o
drivers/usb/host/ehci-hcd.c:1018:2: error: #error "missing bus glue for ehci-hcd"
make[3]: *** [drivers/usb/host/ehci-hcd.o] Error 1
ehci-hcd.c actually contains OF_PLATFORM_DRIVER glue, so error is bogus.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/usb/host/ehci-hcd.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 4caa6a8..3a19b1a 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1014,7 +1014,7 @@ MODULE_LICENSE ("GPL");
#endif
#if !defined(PCI_DRIVER) && !defined(PLATFORM_DRIVER) && \
- !defined(PS3_SYSTEM_BUS_DRIVER)
+ !defined(PS3_SYSTEM_BUS_DRIVER) && !defined(OF_PLATFORM_DRIVER)
#error "missing bus glue for ehci-hcd"
#endif
--
1.5.2.2
^ permalink raw reply related
* [PATCH] [USB POWERPC] ehci-fsl: add PPC_MPC837x to default y
From: Anton Vorontsov @ 2008-02-21 19:50 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-usb
Without this patch it's impossible to select ehci-fsl on PPC_MPC837x.
Another option would be to convert USB_EHCI_FSL to verbose bool,
but I presume EHCI_FSL is purposely made silent.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/usb/host/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index d97b16b..33da056 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -72,7 +72,7 @@ config USB_EHCI_FSL
bool
depends on USB_EHCI_HCD
select USB_EHCI_ROOT_HUB_TT
- default y if MPC834x || PPC_MPC831x
+ default y if MPC834x || PPC_MPC831x || PPC_MPC837x
---help---
Variation of ARC USB block used in some Freescale chips.
--
1.5.2.2
^ permalink raw reply related
* Re: [PATCH] [USB POWERPC] ehci-fsl: add PPC_MPC837x to default y
From: Scott Wood @ 2008-02-21 19:55 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, linux-usb
In-Reply-To: <20080221195021.GC12896@localhost.localdomain>
Anton Vorontsov wrote:
> Without this patch it's impossible to select ehci-fsl on PPC_MPC837x.
> Another option would be to convert USB_EHCI_FSL to verbose bool,
> but I presume EHCI_FSL is purposely made silent.
I think making it verbose bool would be better.
-Scott
^ permalink raw reply
* Re: [PATCH] [USB POWERPC] ehci-fsl: add PPC_MPC837x to default y
From: Kumar Gala @ 2008-02-21 19:58 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, linux-usb
In-Reply-To: <20080221195021.GC12896@localhost.localdomain>
On Feb 21, 2008, at 1:50 PM, Anton Vorontsov wrote:
> Without this patch it's impossible to select ehci-fsl on PPC_MPC837x.
> Another option would be to convert USB_EHCI_FSL to verbose bool,
> but I presume EHCI_FSL is purposely made silent.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> drivers/usb/host/Kconfig | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> index d97b16b..33da056 100644
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -72,7 +72,7 @@ config USB_EHCI_FSL
> bool
> depends on USB_EHCI_HCD
> select USB_EHCI_ROOT_HUB_TT
> - default y if MPC834x || PPC_MPC831x
> + default y if MPC834x || PPC_MPC831x || PPC_MPC837x
Can we just change this to FSL_SOC
- k
^ permalink raw reply
* Re: [PATCH] [POWERPC] 8xx: timebase frequency should not depend on bus-frequency
From: Anton Vorontsov @ 2008-02-21 19:59 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <47BDD587.9060206@freescale.com>
On Thu, Feb 21, 2008 at 01:48:23PM -0600, Scott Wood wrote:
> Anton Vorontsov wrote:
> >diff --git a/arch/powerpc/platforms/8xx/m8xx_setup.c
> >b/arch/powerpc/platforms/8xx/m8xx_setup.c
> >index 184f998..0d9f75c 100644
> >--- a/arch/powerpc/platforms/8xx/m8xx_setup.c
> >+++ b/arch/powerpc/platforms/8xx/m8xx_setup.c
> >@@ -111,17 +111,12 @@ void __init mpc8xx_calibrate_decr(void)
> >
> > /* Processor frequency is MHz.
> > */
> >- ppc_tb_freq = 50000000;
> >- if (!get_freq("bus-frequency", &ppc_tb_freq)) {
> >- printk(KERN_ERR "WARNING: Estimating decrementer frequency "
> >- "(not found)\n");
> >- }
> >- ppc_tb_freq /= 16;
> > ppc_proc_freq = 50000000;
> > if (!get_freq("clock-frequency", &ppc_proc_freq))
> > printk(KERN_ERR "WARNING: Estimating processor frequency "
> > "(not found)\n");
> >
> >+ ppc_tb_freq = ppc_proc_freq / 16;
>
> Shouldn't we just use the timebase-frequency property?
Nope. Most u-boots currently do not setup timebase-frequency, and if
they are setting it up, they're doing it wrong, in sense that Linux
overwrites timebase setup (yeah, in this regard MPC8xx is special).
So, for MPC8xx, Linux doesn't care what timebase setup was used in
the firmware.
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] [USB POWERPC] ehci: fix ppc build
From: David Brownell @ 2008-02-21 19:59 UTC (permalink / raw)
To: linuxppc-dev, avorontsov; +Cc: linux-usb
In-Reply-To: <20080221194913.GB12896@localhost.localdomain>
> From avorontsov@ru.mvista.com Thu Feb 21 11:49:48 2008
> Date: Thu, 21 Feb 2008 22:49:13 +0300
> From: Anton Vorontsov <avorontsov@ru.mvista.com>
> To: linuxppc-dev@ozlabs.org
> Cc: linux-usb@vger.kernel.org, dbrownell@users.sourceforge.net
> Subject: [PATCH] [USB POWERPC] ehci: fix ppc build
>
> Currently, this setup:
> CONFIG_USB_ARCH_HAS_EHCI=y
> CONFIG_USB_EHCI_HCD=y
> CONFIG_USB_EHCI_HCD_PPC_OF=y
>
> Will fail to build:
> CC drivers/usb/host/ehci-hcd.o
> drivers/usb/host/ehci-hcd.c:1018:2: error: #error "missing bus glue for ehci-hcd"
> make[3]: *** [drivers/usb/host/ehci-hcd.o] Error 1
>
> ehci-hcd.c actually contains OF_PLATFORM_DRIVER glue, so error is bogus.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: David Brownell <dbrownell@users.sourceforge.net>
... for 2.6.25 ...
> ---
> drivers/usb/host/ehci-hcd.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
> index 4caa6a8..3a19b1a 100644
> --- a/drivers/usb/host/ehci-hcd.c
> +++ b/drivers/usb/host/ehci-hcd.c
> @@ -1014,7 +1014,7 @@ MODULE_LICENSE ("GPL");
> #endif
>
> #if !defined(PCI_DRIVER) && !defined(PLATFORM_DRIVER) && \
> - !defined(PS3_SYSTEM_BUS_DRIVER)
> + !defined(PS3_SYSTEM_BUS_DRIVER) && !defined(OF_PLATFORM_DRIVER)
> #error "missing bus glue for ehci-hcd"
> #endif
>
> --
> 1.5.2.2
>
^ permalink raw reply
* Re: [PATCH] [POWERPC] 8xx: timebase frequency should not depend on bus-frequency
From: Scott Wood @ 2008-02-21 20:06 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev
In-Reply-To: <20080221195918.GA14636@localhost.localdomain>
Anton Vorontsov wrote:
> On Thu, Feb 21, 2008 at 01:48:23PM -0600, Scott Wood wrote:
>> Anton Vorontsov wrote:
>>> diff --git a/arch/powerpc/platforms/8xx/m8xx_setup.c
>>> b/arch/powerpc/platforms/8xx/m8xx_setup.c
>>> index 184f998..0d9f75c 100644
>>> --- a/arch/powerpc/platforms/8xx/m8xx_setup.c
>>> +++ b/arch/powerpc/platforms/8xx/m8xx_setup.c
>>> @@ -111,17 +111,12 @@ void __init mpc8xx_calibrate_decr(void)
>>>
>>> /* Processor frequency is MHz.
>>> */
>>> - ppc_tb_freq = 50000000;
>>> - if (!get_freq("bus-frequency", &ppc_tb_freq)) {
>>> - printk(KERN_ERR "WARNING: Estimating decrementer frequency "
>>> - "(not found)\n");
>>> - }
>>> - ppc_tb_freq /= 16;
>>> ppc_proc_freq = 50000000;
>>> if (!get_freq("clock-frequency", &ppc_proc_freq))
>>> printk(KERN_ERR "WARNING: Estimating processor frequency "
>>> "(not found)\n");
>>>
>>> + ppc_tb_freq = ppc_proc_freq / 16;
>> Shouldn't we just use the timebase-frequency property?
>
> Nope. Most u-boots currently do not setup timebase-frequency, and if
> they are setting it up, they're doing it wrong, in sense that Linux
> overwrites timebase setup (yeah, in this regard MPC8xx is special).
Current u-boots don't support device trees at all on 8xx. The most
recent 8xx FDT patch I saw called get_tbclk() to fill in
timebase-frequency; does get_tbclk() not work?
Obviously, when booting with a cuImage we can't use u-boot's value,
since it's not in the bd_t. In that case, we should fix the wrapper's
calculation of the timebase frequency.
-Scott
^ permalink raw reply
* How to dynamically disable/enable CPU features?
From: Gerhard Pircher @ 2008-02-21 20:07 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I'm wondering how to disable or enable CPU features based on the board the
kernel is running on. In my case I want to disable the
CPU_FTR_NEED_COHERENT flag for 74xx CPUs, because it locks up the machine.
I tried to clear the flag in the platform's *_probe() function with the
following code:
cur_cpu_spec->cpu_features &= ~CPU_FTR_NEED_COHERENT;
First I thought that this works fine, because the kernel booted once till
the console login prompt (and died afterwards). Therefore I suspected that
another change or bug in the kernel conflicts with my hardware (usually
the machine died much earlier on older kernels, if the flag wasn't
cleared).
Now I removed all CPU_FTR_NEED_COHERENT entries from the cputable.h file
and the kernel boots just fine without any lockups (reproducable).
I don't quite understand the difference between dynamically clearing the
flag in the platform setup code and removing the flag for all CPU
defines in cputable.h. I can only suspect that clearing the flag in the
platform probe function is too late, as the MMU and BATs may already be
set up.
Can anybody confirm my suspicion or give me a hint how to implement it
correctly? (I don't want to tinker with cputable.h)
Thanks!
regards,
Gerhard
--
Psst! Geheimtipp: Online Games kostenlos spielen bei den GMX Free Games!
http://games.entertainment.web.de/de/entertainment/games/free
^ permalink raw reply
* Re: [PATCH] [USB POWERPC] ehci-fsl: add PPC_MPC837x to default y
From: Scott Wood @ 2008-02-21 20:09 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, linux-usb
In-Reply-To: <9AD13D2E-B57F-4F19-B89C-C8A83157E0F2@kernel.crashing.org>
Kumar Gala wrote:
> On Feb 21, 2008, at 1:50 PM, Anton Vorontsov wrote:
>
>> Without this patch it's impossible to select ehci-fsl on PPC_MPC837x.
>> Another option would be to convert USB_EHCI_FSL to verbose bool,
>> but I presume EHCI_FSL is purposely made silent.
>>
>> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>> ---
>> drivers/usb/host/Kconfig | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
>> index d97b16b..33da056 100644
>> --- a/drivers/usb/host/Kconfig
>> +++ b/drivers/usb/host/Kconfig
>> @@ -72,7 +72,7 @@ config USB_EHCI_FSL
>> bool
>> depends on USB_EHCI_HCD
>> select USB_EHCI_ROOT_HUB_TT
>> - default y if MPC834x || PPC_MPC831x
>> + default y if MPC834x || PPC_MPC831x || PPC_MPC837x
>
> Can we just change this to FSL_SOC
Why do you want to bloat all freescale kernels, even on chips that don't
have this hardware?
There are very few cases where default y is justified. This isn't one
of them.
-Scott
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox