* Re: Marvell MV6436xx ethernet driver patch
From: Sven Luther @ 2005-08-31 16:33 UTC (permalink / raw)
To: Mark A. Greer; +Cc: Nicolas DET, linuxppc-dev
In-Reply-To: <20050831160417.GA3848@mag.az.mvista.com>
On Wed, Aug 31, 2005 at 09:04:17AM -0700, Mark A. Greer wrote:
> On Wed, Aug 31, 2005 at 07:55:49AM +0100, Nicolas DET wrote:
> > > This is a good idea. I suspect that most of the gain is from
> > > turning off snooping and flushing/invalidating the cache explicitly.
> > > Implementation-wise, I'd rather we not manipulate the MV643XX_ETH_BAR_?
> > > registers directly in the driver. Today that is done in platform
> > > setup code. This has promise but needs to be reworked.
> >
> > Yeah, the point was to have no snooping for this part of the chip.
> > The descriptors in SRAM, and the data in DDR. This give a serious boost.
> >
> > I noticed MV643xx memory performances are really higher when turning
> > off snoop (not only for ethernet).
> >
> > Well, I confess manipulating such thing here, is not totaly smart.
> > However I don't really know where to put them.
> > Maybe, somewhere in arch/ppc ?
> >
> > Because, at some pooint the driver will need to have this modified in order
> > to reall work correctly.
> >
> > For example, if you use a module with that option (it will disable
> > snooping) and then 'rmmod & modprobe' a new module without it will not work
> > (no snooping as the new module expect!).
> >
> > Conclusion: yes, touching ETH_BAR isn't really well here, but where could
> > we move it ?
>
> The enet->mem BARs are configured in
> arch/ppc/syslib/mv64xc60.c:mv64360_config_io2mem_windows().
Which is not used in the pegasos code path, as we are chrp though.
Friendly,
Sven Luther
^ permalink raw reply
* Re: Marvell MV6436xx ethernet driver patch
From: Mark A. Greer @ 2005-08-31 17:07 UTC (permalink / raw)
To: Sven Luther; +Cc: Nicolas DET, linuxppc-dev
In-Reply-To: <20050831163313.GA25391@localhost.localdomain>
On Wed, Aug 31, 2005 at 06:33:13PM +0200, Sven Luther wrote:
> Which is not used in the pegasos code path, as we are chrp though.
I wondered that after I sent the email. So, yep, chrp_pegasos_eth.c
seem reasonable to me.
Mark
^ permalink raw reply
* Re: ??: Question about SMC serial port on MPC8270 in u-boot
From: Wolfgang Denk @ 2005-08-31 20:36 UTC (permalink / raw)
To: FCG WANG Baohua; +Cc: linuxppc-embedded
In-Reply-To: <A9DE2BAF233E444FA9C5E77A5825A01E865068@ydmail.sbell.com.cn>
In message <A9DE2BAF233E444FA9C5E77A5825A01E865068@ydmail.sbell.com.cn> you wrote:
>
> Now the UART can work. But another question comes :
> The u-Boot reboot forever when enter
...
I already told you that such questions are off topic here. Please ask
on the U-Boot mailinglist instead. But read the FAQ before posting.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"Confound these ancestors.... They've stolen our best ideas!"
- Ben Jonson
^ permalink raw reply
* Re: [RFC] MPC5200 BestComm microcode [en]/[de]coding draft
From: Wolfgang Denk @ 2005-08-31 20:46 UTC (permalink / raw)
To: Andrey Volkov; +Cc: Sylvain Munaut, linuxppc-embedded
In-Reply-To: <4315D1DC.1000607@varma-el.com>
Dear Andrey,
in message <4315D1DC.1000607@varma-el.com> you wrote:
>
> Wolfgang, first question to you:
> May be you are know where I could find (if it exist)
> BestComm (SmartComm) API for mystic MGT5100?
We did not test the current code on the Icecube with the 5100, but
previous versions used to run fine (well, within the limitations of
the 5100, that is). So if the current code on our CVS server does not
run, just check out an oder version. You can search the history of
changes for example here:
http://source.denx.net/cgi-bin/gitweb.cgi?p=linuxppc_2_4_devel.git
like that:
http://source.denx.net/cgi-bin/gitweb.cgi?p=linuxppc_2_4_devel.git&a=search&s=bestcomm
> Agree, good think. Wolfgang, is it appropriately to use WIKI of denx.de?
Yes, of course. Just let me know what you want and we can create a
new web (I don't see any good existing place where this fits).
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"The number of Unix installations has grown to 10, with more
expected." - The Unix Programmer's Manual, 2nd Edition, June, 1972
^ permalink raw reply
* Re: linuxppc-2.4.30-pre1 crashes with root fs on Xilinx SystemACE
From: Tony Lee @ 2005-09-01 1:11 UTC (permalink / raw)
To: Peter Ryser; +Cc: linuxppc-embedded
In-Reply-To: <4313FA43.1040206@xilinx.com>
[-- Attachment #1: Type: text/plain, Size: 2857 bytes --]
Keith,
Some suggestions, before you verify your hw board/FPGA works fine with
SYSACE,
* don't use sysace as root fs.
* use a ram fs as root fs.
* Next, load sysace driver a loadable driver module. It works, I tried it.
* check mount read only and see if it works.
* Next, mount it writable.
We have some issues with sysace driver initially, everything works out fine
later.
There were small errors in our HW layout.
I had to hack the sysace driver left and right to id the problem. But at the
end, after I fixed the layout problem from the fpga's ucf file, the original
driver
run perfectly without any modification.
In my experiences, the ppc linux distribution and its linux sysace driver
are good
if everything is setup correctly.
One minor issues: The sysace driver's write performance sucks. I have to
explain
to others why the upgrade 10 MBytes files with usb flash writer takes tens
of
seconds. When we do it from linux (nfs or ftp), it tooks minutes to sync.
Peter, maybe you can push the xilinx a bit on sysace write performance? :-)
-Tony
On 8/29/05, Peter Ryser <peter.ryser@xilinx.com> wrote:
>
> Hi Keith,
>
> I sent you a private email but for other interested people:
> Downloading the latest linuxppc-2.4 kernel I could boot from and access
> System ACE CF without problems on a ML403 (Virtex-4, 4VFX12) and a ML310
> (Virtex-II Pro, 2VP30) using EDK 7.1.2. In both cases I started with
> config_xilinx_ml300.
>
> - Peter
>
>
>
> Keith J Outwater wrote:
>
> >Hello -
> >Per a previous suggestion from this list, I rsynced the linuxppc-2.4
> >kernel sources from MontaVista and modified the kernel to run on my
> custom
> >ppc405/VirtexII Pro based system with U-Boot as the bootloader.
> >When I try to use the SystemACE device as the root filesystem, the kernel
> >crashes with a sig 11. Looking at the 'oops' output it appears the
> >SystemACE driver may be to blame. The crash is random - sometimes I get
> >all the way to login as root and then things crash on a file copy or a
> >file read.
> >Before I start digging deeper, is anyone running a VirtexIIPro based
> >system with the root filesystem in the CF card attached to a SystemACE?
> >I'm wondering if I really have the best kernel and SystemACE driver.
> >BTW, I'm developing the hardware design using Xilinx EDK 7.02i.
> >Thanks,
> >Keith
> >_______________________________________________
> >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
>
--
-Tony
Having fun with FPGA HW + ppc + Linux
[-- Attachment #2: Type: text/html, Size: 3732 bytes --]
^ permalink raw reply
* Machine check - D-Cache search parity error occurs on a ppc440 core
From: Shawn Jin @ 2005-09-01 1:49 UTC (permalink / raw)
To: ppcembed
Hi,
When the kernel starts /sbin/init, a machine check occurs showing it's
a d-cache search parity error. The CPU is a ppc440 core.
What usually causes this kind of exception? The user's manual of 440
core lists three possible situation where such an exception will
occur.
1) Multi-hit parity error on any instr that does a CAM lookup
2) Tag or data parity errors on load instr
3) Tag parity erros on dcbf, dcbi, dcbst instr
Both 1) and 3) are excluded in this case because the internal cpu core
signals show dcrTagEvenSearchParityError is set. Why did this error
happen? It's a cpu bug?
Anyone has seen this error before? Please share your experience.
RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 72k init
Machine check in kernel mode.
D-Cache Search Parity Error
Oops: machine check, sig: 7 [#1]
NIP: C0000D20 LR: 30001BA8 SP: 7FFFFC80 REGS: c00e5f50 TRAP: 0202 Not ta=
inted
MSR: 00021000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
TASK =3D c016cab0[1] 'init' THREAD: c1fca000
Last syscall: 11=20
GPR00: 00000001 7FFFFC80 00000000 00000000 AAAA0000 30025160 30024B18 00000=
DF8=20
GPR08: 30024B80 0000012A 0000037E 30000AC8 00000254 00000000 02004D00 00000=
000=20
GPR16: 00000000 00000001 FFFFFFFF 01FFDF58 00000000 007FFF00 00000003 7FFFF=
F10=20
GPR24: 00000002 7FFFFC90 300002C4 7FFFFC88 3000195C 30000000 C00011C8 30001=
8C0=20
NIP [c0000d20] DataTLBError+0x0/0xa0
LR [30001ba8] 0x30001ba8
Kernel panic - not syncing: Attempted to kill init!
Best regards,
-Shawn.
^ permalink raw reply
* PayPal Account Security Measures
From: service @ 2005-09-01 1:32 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/html, Size: 1860 bytes --]
^ permalink raw reply
* PayPal Account Security Measures
From: service @ 2005-09-01 1:32 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/html, Size: 1860 bytes --]
^ permalink raw reply
* linux hangs after uncompress kernel image
From: lily @ 2005-09-01 3:55 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1197 bytes --]
i work on octobusHPPC405EP board . when I try to bring up the kernel i meet the problem that linux hangs after uncompressing image:
U-Boot 1.1.2 (Jun 3 2005 - 12:05:48)
CPU: IBM PowerPC 405EP Rev. B at 133.333 MHz (PLB=133, OPB=66, EBC=33 MHz)
IIC Boot EEPROM disabled
PCI async ext clock used, internal PCI arbiter enabled
16 kB I-Cache 16 kB D-Cache
OCTOBUS Board: ### No HW ID - assuming OCTOBUS HPPC405
I2C: ready
DRAM: 32 MB
FLASH: 4 MB
=>iminfo 1000000
## Checking Image at 01000000 ...
Image Name: Linux-2.4.21-pre5
Created: 2005-08-03 17:45:20 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 548345 Bytes = 535.5 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
=> bootm 1000000
## Booting image at 01000000 ...
Image Name: Linux-2.4.21-pre5
Created: 2005-08-03 17:45:20 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 548345 Bytes = 535.5 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
<hang>
what's the problem??
[-- Attachment #2: Type: text/html, Size: 2273 bytes --]
^ permalink raw reply
* A question regarding ramdisks
From: Adrian B. Weissman @ 2005-09-01 5:46 UTC (permalink / raw)
To: linuxppc-embedded
Hello:
I am having some configuration / problems with
using a ramdisk and the 2.6.12 Kernel for a ppc 7447A
processor, using u-boot version 0.3.0
Here is what I am doing, I make uImage, after
configuring ramdisk support
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=2
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RAMFS=y
I then set my bootargs in uboot to
root=/dev/ram rw
I then load my kernel and ramdisk image into
memory and specify to boot the kernel with the ramdisk
in uboot via
bootm 0x300000 0x10000000
The following is the output:
U-Boot 0.3.0 (Jun 29 2005 - 09:50:51)SKY Computers
1.1.3
CPU: MPC7447A v1.1 @ 1399.650 MHz
BOARD: HDPU_COMPUTE_BLADE SINGLE
BUS: 133300000
DRAM: 512 MB
******************************************************
Please Wait, Scrubbing SDRAM to initialize ECC bits...
******************************************************
FLASH: [65536kB@fc000000] 64 MB
In: serial
Out: serial
Err: serial
Net: ### Error: Phy is not active
mv_enet0
=> bootp
bootp
### Error: Phy is not active
BOOTP broadcast 1
DHCP client bound to address 10.0.0.5
ARP broadcast 1
TFTP from server 10.0.0.254; our IP address is
10.0.0.5
Filename 'adrian/uImage.adr'.
Load address: 0x300000
Loading:
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
done
Bytes transferred = 1661461 (195a15 hex)
=> tftpboot 0x10000000 adrian/ramdisk.img
tftpboot 0x10000000 adrian/ramdisk.img
### Error: Phy is not active
ARP broadcast 1
TFTP from server 10.0.0.254; our IP address is
10.0.0.5
Filename 'adrian/ramdisk.img'.
Load address: 0x10000000
Loading:
#################################################################
#################################################################
#################################################################
#################################################################
###############
done
Bytes transferred = 1403903 (156bff hex)
=> bootm 0x300000 0x10000000
bootm 0x300000 0x10000000
## Booting image at 00300000 ...
Image Name: Linux-2.6.12-2_0_2
Image Type: PowerPC Linux Kernel Image (gzip
compressed)
Data Size: 1661397 Bytes = 1.6 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at 10000000 ...
Image Name: Simple Embedded Linux Framework
Image Type: PowerPC Linux RAMDisk Image (gzip
compressed)
Data Size: 1403839 Bytes = 1.3 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Loading Ramdisk to 1fe47000, end 1ff9dbbf ... OK
Total memory = 512MB; using 1024kB for hash table (at
80400000)
Linux version 2.6.12-2_0_2 (root@1_4_0_0) (gcc version
3.3) #18 Wed Aug 31 16:49:39 EDT 2005
SKY HDPU Compute Blade
Built 1 zonelists
Kernel command line: root=/dev/ram rw
PID hash table entries: 4096 (order: 12, 65536 bytes)
time_init: decrementer frequency = 33.325000 MHz
Dentry cache hash table entries: 131072 (order: 7,
524288 bytes)
Inode-cache hash table entries: 65536 (order: 6,
262144 bytes)
Memory: 514304k available (2388k kernel code, 1264k
data, 132k init, 0k highmem)
Mount-cache hash table entries: 512
scheduling while atomic: swapper/0x00000002/0
Call trace:
[80007b1c] dump_stack+0x18/0x28
[80250614] schedule+0x764/0x768
[80004980] syscall_exit_work+0x108/0x10c
[8037d78c] proc_root_init+0x164/0x170
[80390000] __log_buf+0xb9c/0x8000
[8036a68c] start_kernel+0x18c/0x1c4
[00003a30] 0x3a30
NET: Registered protocol family 16
PCI: Probing PCI hardware
PCI: Cannot allocate resource region 2 of PCI bridge 2
SCSI subsystem initialized
Installing knfsd (copyright (C) 1996
okir@monad.swb.de).
JFFS2 version 2.2. (C) 2001-2003 Red Hat, Inc.
Initializing Cryptographic API
Generic RTC Driver v1.07
Serial: MPSC driver $Revision: 1.1.1.1 $
ttyMM0 at MMIO 0xf1008000 (irq = 36) is a MPSC
ttyMM1 at MMIO 0xf1009000 (irq = 38) is a MPSC
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 2 RAM disks of 4096K size
1024 blocksize
loop: loaded (max 8 devices)
Sky CPU State Driver v1.1
MV-643xx 10/100/1000 Ethernet Driver
eth0: port 0 with MAC address 00:50:c2:1f:10:cd
eth0: RX NAPI Enabled
st: Version 20050312, fixed bufsize 32768, s/g segs
256
physmap flash device: 4000000 at fc000000
phys_mapped_flash: Found 2 x16 devices at 0x0 in
32-bit bank
Intel/Sharp Extended Query Table at 0x0031
Using buffer write method
cfi_cmdset_0001: Erase suspend on write enabled
cmdlinepart partition parsing not available
RedBoot partition parsing not available
Using physmap partition definition
Creating 6 MTD partitions on "phys_mapped_flash":
0x00000000-0x04000000 : "No FS"
mtd: Giving out device 0 to No FS
0x00000000-0x03400000 : "Root FS"
mtd: Giving out device 1 to Root FS
0x03400000-0x03c00000 : "User FS"
mtd: Giving out device 2 to User FS
0x03c00000-0x03ec0000 : "Kernel Image"
mtd: Giving out device 3 to Kernel Image
0x03ec0000-0x03f00000 : "bootEnv"
mtd: Giving out device 4 to bootEnv
0x03f00000-0x04000000 : "bootROM"
mtd: Giving out device 5 to bootROM
mice: PS/2 mouse device common for all mice
NET: Registered protocol family 2
IP: routing cache hash table of 4096 buckets, 32Kbytes
TCP established hash table entries: 131072 (order: 8,
1048576 bytes)
TCP bind hash table entries: 65536 (order: 6, 262144
bytes)
TCP: Hash tables configured (established 131072 bind
65536)
NET: Registered protocol family 1
NET: Registered protocol family 17
Kernel panic - not syncing: VFS: Unable to mount root
fs on unknown-block(1,0)
<0>Rebooting in 180 seconds..
However, the kernel is unable to mount the block.
I have tried the following:
1. Setting root=/dev/ram0 rw
2. Setting root=/dev/ram ramdisk_start=0x1fe47000
Thus, spelling out where the ramdisk is unpacked by
uboot to the Kernel.
3. tftpboot 0x10000000 adrian/ramdisk.gz and
root=/dev/ram ramdisk_start=0x10000000, thus loading
the compressed ramdisk right into memory.
4. Combining the ramdisk and kernel image, with a
uboot header via Wolfgang's directions:
http://www.denx.de/twiki/bin/view/DULG/CombiningKernelAndRamdisk
After looking through uboot, there really is no
super custom cpu initialization. And the bootm
command works solid. So I don't think having a
somewhat old version of uboot is the reason. But I
am out of ideas.
1. My question is why don't I see
"RAMDISK: Compressed image found at block 0"
instead of the Kernel Panic? Am I missing some
arguments? noinitrd, ramdisk_start, ramdisk_size,
etc?
2. Does uboot have issues with this processor,
MPX bus, ramdisks? I don't think so, but has anyone
seen an issue with version 0.3.0 of uboot?
3. Also, I am using the SELF ramdisk provided on
Wolfgang Denk's U-boot and Linux guide. ( Thank you
Wolfgang!!!) and am able once booted via nfs to
mount the ramdisk without a problem. Thus, I believe
the ramdisk is ok.
Any pointers, comments, constructive critisism
would be greatly appreciated. And yes, I have read
through several archives quite abit before posting.
A close example of my problem is
http://ozlabs.org/pipermail/linuxppc-embedded/2005-July/019071.html
However, no solution was posted.
Regards and thanks in advance!
Adrian
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
^ permalink raw reply
* Re: linux hangs after uncompress kernel image
From: John F Davis @ 2005-09-01 6:58 UTC (permalink / raw)
To: lily; +Cc: linuxppc-embedded-bounces, linuxppc-embedded
In-Reply-To: <000801c5aea9$059f01e0$fa0cc9ca@lcj3bdfa4e34dd>
[-- Attachment #1: Type: text/plain, Size: 1642 bytes --]
Hello Lily,
Maybe you could try to put in some printk's and see which line of code
generates an exception.
JD
"lily" <lichanjuan04@st.lzu.edu.cn>
Sent by: linuxppc-embedded-bounces@ozlabs.org
09/01/2005 05:55 AM
To
<linuxppc-embedded@ozlabs.org>
cc
Subject
linux hangs after uncompress kernel image
i work on octobusHPPC405EP board . when I try to bring up the kernel i
meet the problem that linux hangs after uncompressing image:
U-Boot 1.1.2 (Jun 3 2005 - 12:05:48)
CPU: IBM PowerPC 405EP Rev. B at 133.333 MHz (PLB=133, OPB=66, EBC=33
MHz)
IIC Boot EEPROM disabled
PCI async ext clock used, internal PCI arbiter enabled
16 kB I-Cache 16 kB D-Cache
OCTOBUS Board: ### No HW ID - assuming OCTOBUS HPPC405
I2C: ready
DRAM: 32 MB
FLASH: 4 MB
=>iminfo 1000000
## Checking Image at 01000000 ...
Image Name: Linux-2.4.21-pre5
Created: 2005-08-03 17:45:20 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 548345 Bytes = 535.5 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
=> bootm 1000000
## Booting image at 01000000 ...
Image Name: Linux-2.4.21-pre5
Created: 2005-08-03 17:45:20 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 548345 Bytes = 535.5 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
<hang>
what's the problem?? _______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[-- Attachment #2: Type: text/html, Size: 3242 bytes --]
^ permalink raw reply
* Re: A question regarding ramdisks
From: Murray.Jensen @ 2005-09-01 7:16 UTC (permalink / raw)
To: Adrian B. Weissman; +Cc: linuxppc-embedded
In-Reply-To: <20050901054650.11322.qmail@web35208.mail.mud.yahoo.com>
On Wed, 31 Aug 2005 22:46:50 -0700 (PDT), "Adrian B. Weissman" writes:
> Here is what I am doing, I make uImage, after
>configuring ramdisk support
>
>CONFIG_BLK_DEV_RAM=y
>CONFIG_BLK_DEV_RAM_COUNT=2
>CONFIG_BLK_DEV_RAM_SIZE=4096
>CONFIG_INITRAMFS_SOURCE=""
>CONFIG_RAMFS=y
Do you have CONFIG_BLK_DEV_INITRD enabled? Cheers!
Murray...
--
Murray Jensen, CSIRO Manufacturing & Infra. Tech. Phone: +61 3 9662 7763
Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 9662 7853
Internet: Murray.Jensen@csiro.au
To the extent permitted by law, CSIRO does not represent, warrant and/or
guarantee that the integrity of this communication has been maintained or
that the communication is free of errors, virus, interception or interference.
The information contained in this e-mail may be confidential or privileged.
Any unauthorised use or disclosure is prohibited. If you have received this
e-mail in error, please delete it immediately and notify Murray Jensen on
+61 3 9662 7763. Thank you.
^ permalink raw reply
* Question about ELDK and i18n...
From: David Jander @ 2005-09-01 8:09 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I am using ELDK-3.1, and I am not getting i18n to work. I have looked at
recent changelog of ELDK and newer (CVS) versions don't seem to fix any bug
in that direction.
The installation seems ok, the locale-files are all there as it seems.
I have tried this as a test:
# LANG=es_ES strace tar
in the output, I can see these relevant lines:
open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No
such file or directory)
- This does not matter.
open("/usr/share/locale/locale.alias", O_RDONLY) = 3
- OK, good. locale.alias is read
open("/usr/lib/locale/es_ES/LC_IDENTIFICATION", O_RDONLY) = 3
- Also looks fine, read the locales identification.
open("/usr/lib/locale/es/LC_IDENTIFICATION", O_RDONLY) = -1 ENOENT (No such
file or directory)
- Here I am puzzled. Why? Maybe this is not important.
Then there are no more calls to open or stat with files in "/usr/lib/locale"
nor "/usr/share/locale" as argument, and I can't figure out why. What am I
doing wrong? Is this version of glibc in ELDK broken?
Best regards,
--
David Jander
^ permalink raw reply
* Re: [PATCH] MPC8xx PCMCIA driver
From: Dominik Brodowski @ 2005-09-01 8:53 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Russell King, linux-kernel, linux-ppc-embedded
In-Reply-To: <20050830024840.GA5381@dmt.cnet>
Hi,
On Mon, Aug 29, 2005 at 11:48:40PM -0300, Marcelo Tosatti wrote:
> Russell: The driver is using pccard_nonstatic_ops for card window
> management, even though the driver its marked SS_STATIC_MAP (using
> mem->static_map).
This is obviously broken. Where does it fail if pccard_static_ops is used?
> +typedef struct {
> + u_int regbit;
> + u_int eventbit;
> +} event_table_t;
No typedefs, please.
Dominik
^ permalink raw reply
* Re: Question about ELDK and i18n...
From: Wolfgang Denk @ 2005-09-01 9:18 UTC (permalink / raw)
To: David Jander; +Cc: linuxppc-embedded
In-Reply-To: <200509011009.24114.david.jander@protonic.nl>
Dear David,
in message <200509011009.24114.david.jander@protonic.nl> you wrote:
>
> I am using ELDK-3.1, and I am not getting i18n to work. I have looked at
> recent changelog of ELDK and newer (CVS) versions don't seem to fix any bug
> in that direction.
There is no fix yet, but the problem is known :-(
> The installation seems ok, the locale-files are all there as it seems.
No.
> I have tried this as a test:
>
> # LANG=es_ES strace tar
>
> in the output, I can see these relevant lines:
>
> open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No
> such file or directory)
>
> - This does not matter.
It does. For the setlocale() call to succeed, an additional file is
needed, apart from the locale files themselves. It is a
locale-archive file in the /usr/lib/locale directory on the target.
This file is still missing in the ELDK glibc RPM.
> open("/usr/share/locale/locale.alias", O_RDONLY) = 3
>
> - OK, good. locale.alias is read
>
> open("/usr/lib/locale/es_ES/LC_IDENTIFICATION", O_RDONLY) = 3
>
> - Also looks fine, read the locales identification.
>
> open("/usr/lib/locale/es/LC_IDENTIFICATION", O_RDONLY) = -1 ENOENT (No such
> file or directory)
>
> - Here I am puzzled. Why? Maybe this is not important.
>
> Then there are no more calls to open or stat with files in "/usr/lib/locale"
> nor "/usr/share/locale" as argument, and I can't figure out why. What am I
> doing wrong? Is this version of glibc in ELDK broken?
There is a problem with locale support. The contents of the
'locale-archive' file is endian-dependent. This means that we can't
use the existing tools on the x86 (= little endian) ELDK build host
to generate it for a big-endian target.
As a workaround, the locale files can be generated natively on the
target, using for example the following command:
# localedef -i de_DE -f ISO-8859-1 de_DE
Hope this helps.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
There is, however, a strange, musty smell in the air that reminds me
of something...hmm...yes...I've got it...there's a VMS nearby, or I'm
a Blit. - Larry Wall in Configure from the perl distribution
^ permalink raw reply
* Re: [PATCH] MPC8xx PCMCIA driver
From: Magnus Damm @ 2005-09-01 11:44 UTC (permalink / raw)
To: Dominik Brodowski, Marcelo Tosatti, linux-ppc-embedded,
linux-kernel, Russell King, Dan Malek, Pantelis Antoniou
In-Reply-To: <20050901085319.GB6285@isilmar.linta.de>
Hello all,
Nice to see that this driver gets forward ported to 2.6. I originally
wrote it for pcmcia-cs, but it made its way into 2.4 after a while.
Thanks to all the people who added code and fixes.
I'm not sure how the current Linux pcmcia layer works, and I am not
involved in powerpc land anymore so I have no comments on the porting
work or the driver itself.
On 9/1/05, Dominik Brodowski <linux@dominikbrodowski.net> wrote:
> On Mon, Aug 29, 2005 at 11:48:40PM -0300, Marcelo Tosatti wrote:
> > Russell: The driver is using pccard_nonstatic_ops for card window
> > management, even though the driver its marked SS_STATIC_MAP (using
> > mem->static_map).
>=20
> This is obviously broken. Where does it fail if pccard_static_ops is used=
?
I remember it was interesting to write the driver for pcmcia-cs. This
was because the mpc8xx socket hardware did not implement per-window
offsets, and pcmcia-cs required that. So a wild guess is that this
static/notstatic thing is related to that.
/ magnus
^ permalink raw reply
* Re: [RFC] MPC5200 BestComm microcode [en]/[de]coding draft
From: Andrey Volkov @ 2005-09-01 12:15 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Sylvain Munaut, linuxppc-embedded
In-Reply-To: <20050831204627.EAF8C35258E@atlas.denx.de>
Wolfgang Denk wrote:
> Dear Andrey,
>
> in message <4315D1DC.1000607@varma-el.com> you wrote:
>
>>Wolfgang, first question to you:
>>May be you are know where I could find (if it exist)
>>BestComm (SmartComm) API for mystic MGT5100?
>
>
> We did not test the current code on the Icecube with the 5100, but
> previous versions used to run fine (well, within the limitations of
> the 5100, that is). So if the current code on our CVS server does not
> run, just check out an oder version. You can search the history of
> changes for example here:
> http://source.denx.net/cgi-bin/gitweb.cgi?p=linuxppc_2_4_devel.git
> like that:
> http://source.denx.net/cgi-bin/gitweb.cgi?p=linuxppc_2_4_devel.git&a=search&s=bestcomm
No, Wolfgang, I'm sorry, but you are don't understand me.
I seek bestcomm u-code for MGT5100 (and only for 5100) exceptionally for
subj. Since in 5100 was implemented EU#1, hence bestcomm u-code
for it have a little differences (in DRD2xx, if be more precesily).
This u-code is partially presented in U-boot (eth RX/TX tasks),
but it is not enough for me.
--
Regards
Andrey Volkov
^ permalink raw reply
* Error while accessing physical address
From: Garcia Jérémie @ 2005-09-01 13:44 UTC (permalink / raw)
To: linuxppc-dev
Hi everybody.
As a kernel newbie, I still encounter basic problems. I read a lot of =
things on the memory management,
but obviously I didn't understand some things.
I have some kernel source code that only write data to our card =
registers:
>>>>>>>
void bhWriteCardRegister(unsigned short * address, unsigned short data)
{
unsigned short * regHdwAddress;
printk("Writing data: %x at address:%x\n",data,address);
/* Get the virtual address for the physical one */
regHdwAddress =3D (unsigned short *) ioremap((unsigned =
short)address,0x1);
printk("ioremap returned : %x\n",regHdwAddress);
=20
/* write hardware register data value */=20
*regHdwAddress =3D data;
=20
iounmap((void *)regHdwAddress);
}
<<<<<<<<
In a module init I call this function:
>>>>>>>>
#define CARD_PROCESSOR_CTRL_IN_SERVICE 0x8000
#define CARD_PROCESSOR_CTRL_REG_P 0x40000400
bhWriteCardRegister((unsigned short *)(CARD_PROCESSOR_CTRL_REG_P), =
(unsigned short)CARD_PROCESSOR_CTRL_IN_SERVICE);
<<<<<<<<
When I load this module on our powerPC 405EP based arch, the execution =
gives that:
>>>>>>>>
Writing data: 8000 at address:40000400
ioremap returned : c2090400
<<<<<<<<
The problem is that after this write operation, every shell cmd I try =
give a "segmentation fault".
What I did wrong ??
Please help me cause I have to go on fast... (tks boss...)
^ permalink raw reply
* RE : Error while accessing physical address
From: Garcia Jérémie @ 2005-09-01 14:20 UTC (permalink / raw)
To: Marcin Dawidowicz; +Cc: linuxppc-dev
Tks for your answer Marcin. This is a good idea but unfortunately,=20
the result remains the same...
When using "ioremap", do I need need to use inb/oub... family to=20
handle those remapped address??
-------- Message d'origine--------
De: Marcin Dawidowicz [mailto:marcin.dawidowicz@kontron.pl]
Date: jeu. 01/09/2005 16:11
=C0: Garcia J=E9r=E9mie
Objet : Re: Error while accessing physical address
=20
Maybe you could try to change this:
> regHdwAddress =3D (unsigned short *) ioremap((unsigned =
short)address,0x1);
into this:
regHdwAddress =3D (unsigned short *) ioremap((unsigned =
short)address,sizeof=20
(unsigned short));
Cause you are accessing unsigned short register later.... and "unsigned =
short"=20
I assume is 2 bytes long.
Marcin
On Thursday 01 of September 2005 15:44, you wrote:
> Hi everybody.
>
> As a kernel newbie, I still encounter basic problems. I read a lot of
> things on the memory management, but obviously I didn't understand =
some
> things.
>
> I have some kernel source code that only write data to our card =
registers:
>
> void bhWriteCardRegister(unsigned short * address, unsigned short =
data)
> {
> unsigned short * regHdwAddress;
>
> printk("Writing data: %x at address:%x\n",data,address);
>
> /* Get the virtual address for the physical one */
> regHdwAddress =3D (unsigned short *) ioremap((unsigned =
short)address,0x1);
>
> printk("ioremap returned : %x\n",regHdwAddress);
>
> /* write hardware register data value */
> *regHdwAddress =3D data;
>
> iounmap((void *)regHdwAddress);
> }
> <<<<<<<<
>
> In a module init I call this function:
>
> #define CARD_PROCESSOR_CTRL_IN_SERVICE 0x8000
> #define CARD_PROCESSOR_CTRL_REG_P 0x40000400
> bhWriteCardRegister((unsigned short *)(CARD_PROCESSOR_CTRL_REG_P),
> (unsigned short)CARD_PROCESSOR_CTRL_IN_SERVICE); <<<<<<<<
>
> When I load this module on our powerPC 405EP based arch, the execution
> gives that:
>
> Writing data: 8000 at address:40000400
> ioremap returned : c2090400
> <<<<<<<<
>
> The problem is that after this write operation, every shell cmd I try =
give
> a "segmentation fault". What I did wrong ??
>
> Please help me cause I have to go on fast... (tks boss...)
>
>
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [RFC] MPC5200 BestComm microcode [en]/[de]coding draft
From: Sylvain Munaut @ 2005-09-01 14:25 UTC (permalink / raw)
To: Andrey Volkov; +Cc: linuxppc-embedded
In-Reply-To: <4316F0EE.3020001@varma-el.com>
Andrey Volkov wrote:
>
> Wolfgang Denk wrote:
>
>>Dear Andrey,
>>
>>in message <4315D1DC.1000607@varma-el.com> you wrote:
>>
>>
>>>Wolfgang, first question to you:
>>>May be you are know where I could find (if it exist)
>>>BestComm (SmartComm) API for mystic MGT5100?
>>
>>
>>We did not test the current code on the Icecube with the 5100, but
>>previous versions used to run fine (well, within the limitations of
>>the 5100, that is). So if the current code on our CVS server does not
>>run, just check out an oder version. You can search the history of
>>changes for example here:
>>http://source.denx.net/cgi-bin/gitweb.cgi?p=linuxppc_2_4_devel.git
>>like that:
>>http://source.denx.net/cgi-bin/gitweb.cgi?p=linuxppc_2_4_devel.git&a=search&s=bestcomm
>
> No, Wolfgang, I'm sorry, but you are don't understand me.
> I seek bestcomm u-code for MGT5100 (and only for 5100) exceptionally for
> subj. Since in 5100 was implemented EU#1, hence bestcomm u-code
> for it have a little differences (in DRD2xx, if be more precesily).
> This u-code is partially presented in U-boot (eth RX/TX tasks),
> but it is not enough for me.
>
Do you have a MGT5100 ?
Frankly I'm not sure it's of much interest since even Freescale is
not seeking to have linux on 5100 and I'm not even sure you can buy some ...
Sylvain
^ permalink raw reply
* Re: linux hangs after uncompress kernel image
From: Sylvain Munaut @ 2005-09-01 14:30 UTC (permalink / raw)
To: John F Davis; +Cc: linuxppc-embedded
In-Reply-To: <OF4A6E57B7.047A8CB6-ON8725706F.00264CE2-C125706F.00264A01@us.ibm.com>
Or take the address of the __log_buf symbol then after the crash,
reboot and dump the buffer there, so you can see erly printk (before
console is up).
Sylvain
John F Davis wrote:
>
> Hello Lily,
>
> Maybe you could try to put in some printk's and see which line of code
> generates an exception.
>
> JD
>
>
> *"lily" <lichanjuan04@st.lzu.edu.cn>*
> Sent by: linuxppc-embedded-bounces@ozlabs.org
>
> 09/01/2005 05:55 AM
>
>
> To
> <linuxppc-embedded@ozlabs.org>
> cc
>
> Subject
> linux hangs after uncompress kernel image
>
>
>
>
>
>
>
>
> i work on octobusHPPC405EP board . when I try to bring up the kernel i
> meet the problem that linux hangs after uncompressing image:
>
> U-Boot 1.1.2 (Jun 3 2005 - 12:05:48)
>
> CPU: IBM PowerPC 405EP Rev. B at 133.333 MHz (PLB=133, OPB=66, EBC=33 MHz)
> IIC Boot EEPROM disabled
> PCI async ext clock used, internal PCI arbiter enabled
> 16 kB I-Cache 16 kB D-Cache
> OCTOBUS Board: ### No HW ID - assuming OCTOBUS HPPC405
> I2C: ready
> DRAM: 32 MB
> FLASH: 4 MB
> =>iminfo 1000000
> ## Checking Image at 01000000 ...
> Image Name: Linux-2.4.21-pre5
> Created: 2005-08-03 17:45:20 UTC
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 548345 Bytes = 535.5 kB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> => bootm 1000000
> ## Booting image at 01000000 ...
> Image Name: Linux-2.4.21-pre5
> Created: 2005-08-03 17:45:20 UTC
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 548345 Bytes = 535.5 kB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
>
> <hang>
> what's the problem?? _______________________________________________
> 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
^ permalink raw reply
* RE: RE : Error while accessing physical address
From: Nghiem, Tien @ 2005-09-01 14:40 UTC (permalink / raw)
To: Garcia Jérémie, Marcin Dawidowicz; +Cc: linuxppc-dev
Hi Garcia,
unsigned short is 2 bytes, so you should use:
regHdwAddress =3D (unsigned short *) ioremap((unsigned =
short)address,0x2);
Tien
-----Original Message-----
From: linuxppc-dev-bounces@ozlabs.org
[mailto:linuxppc-dev-bounces@ozlabs.org]On Behalf Of Garcia J=E9r=E9mie
Sent: Thursday, September 01, 2005 10:20 AM
To: Marcin Dawidowicz
Cc: linuxppc-dev@ozlabs.org
Subject: RE : Error while accessing physical address
Tks for your answer Marcin. This is a good idea but unfortunately,=20
the result remains the same...
When using "ioremap", do I need need to use inb/oub... family to=20
handle those remapped address??
-------- Message d'origine--------
De: Marcin Dawidowicz [mailto:marcin.dawidowicz@kontron.pl]
Date: jeu. 01/09/2005 16:11
=C0: Garcia J=E9r=E9mie
Objet : Re: Error while accessing physical address
=20
Maybe you could try to change this:
> regHdwAddress =3D (unsigned short *) ioremap((unsigned =
short)address,0x1);
into this:
regHdwAddress =3D (unsigned short *) ioremap((unsigned =
short)address,sizeof=20
(unsigned short));
Cause you are accessing unsigned short register later.... and "unsigned =
short"=20
I assume is 2 bytes long.
Marcin
On Thursday 01 of September 2005 15:44, you wrote:
> Hi everybody.
>
> As a kernel newbie, I still encounter basic problems. I read a lot of
> things on the memory management, but obviously I didn't understand =
some
> things.
>
> I have some kernel source code that only write data to our card =
registers:
>
> void bhWriteCardRegister(unsigned short * address, unsigned short =
data)
> {
> unsigned short * regHdwAddress;
>
> printk("Writing data: %x at address:%x\n",data,address);
>
> /* Get the virtual address for the physical one */
> regHdwAddress =3D (unsigned short *) ioremap((unsigned =
short)address,0x1);
>
> printk("ioremap returned : %x\n",regHdwAddress);
>
> /* write hardware register data value */
> *regHdwAddress =3D data;
>
> iounmap((void *)regHdwAddress);
> }
> <<<<<<<<
>
> In a module init I call this function:
>
> #define CARD_PROCESSOR_CTRL_IN_SERVICE 0x8000
> #define CARD_PROCESSOR_CTRL_REG_P 0x40000400
> bhWriteCardRegister((unsigned short *)(CARD_PROCESSOR_CTRL_REG_P),
> (unsigned short)CARD_PROCESSOR_CTRL_IN_SERVICE); <<<<<<<<
>
> When I load this module on our powerPC 405EP based arch, the execution
> gives that:
>
> Writing data: 8000 at address:40000400
> ioremap returned : c2090400
> <<<<<<<<
>
> The problem is that after this write operation, every shell cmd I try =
give
> a "segmentation fault". What I did wrong ??
>
> Please help me cause I have to go on fast... (tks boss...)
>
>
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] MPC8xx PCMCIA driver
From: Marcelo Tosatti @ 2005-09-01 14:51 UTC (permalink / raw)
To: Dominik Brodowski, linux-ppc-embedded, linux-kernel, Russell King,
Dan Malek, Pantelis Antoniou
In-Reply-To: <20050901085319.GB6285@isilmar.linta.de>
Thu, Sep 01, 2005 at 10:53:19AM +0200, Dominik Brodowski wrote:
> Hi,
>
> On Mon, Aug 29, 2005 at 11:48:40PM -0300, Marcelo Tosatti wrote:
> > Russell: The driver is using pccard_nonstatic_ops for card window
> > management, even though the driver its marked SS_STATIC_MAP (using
> > mem->static_map).
>
> This is obviously broken. Where does it fail if pccard_static_ops is used?
IIRC pcmcia_request_io() fails to dynamically allocate IO windows for PCMCIA
cards because find_io_region returns NULL.
OTOH, as Magnus noted, the memory windows are static:
* Because of the lacking offset register we must map the whole card.
* We assign each memory window PCMCIA_MEM_WIN_SIZE address space.
* Make sure there is (PCMCIA_MEM_WIN_SIZE * PCMCIA_MEM_WIN_NO
* * PCMCIA_SOCKETS_NO) bytes at PCMCIA_MEM_WIN_BASE.
* The i/o windows are dynamically allocated at PCMCIA_IO_WIN_BASE.
* They are maximum 64KByte each...
socket[i].socket.features = SS_CAP_PCCARD | SS_CAP_MEM_ALIGN | SS_CAP_STATIC_MAP;
socket[i].socket.io_offset = 0;
> > +typedef struct {
> > + u_int regbit;
> > + u_int eventbit;
> > +} event_table_t;
>
> No typedefs, please.
OK, will fix.
^ permalink raw reply
* Re: RE : Error while accessing physical address
From: Segher Boessenkool @ 2005-09-01 16:00 UTC (permalink / raw)
To: Nghiem, Tien; +Cc: linuxppc-dev, Marcin Dawidowicz, Garcia Jérémie
In-Reply-To: <A93DEE5BF142D6419D27C298B6F463D812CCF5@mail.oerlikon.ca>
> unsigned short is 2 bytes, so you should use:
>
> regHdwAddress = (unsigned short *) ioremap((unsigned
> short)address,0x2);
Nah. The size doesn't matter that much (it will be mapped
with a page granularity anyway). You just want to use
regHdwAddress = (unsigned short *)ioremap(address, 2);
Casting the address to unsigned short made the address 0x0400
instead of the address you wanted, so you destroy the ISI
vector when writing to it (and you might cause a cache paradox
as well, as the ioremap maps it uncacheable, and it might
already be in the cache at that time).
Segher
^ permalink raw reply
* Re: A question regarding ramdisks
From: Shawn Jin @ 2005-09-01 17:38 UTC (permalink / raw)
To: Adrian B. Weissman; +Cc: linuxppc-embedded
In-Reply-To: <20050901054650.11322.qmail@web35208.mail.mud.yahoo.com>
> Kernel panic - not syncing: VFS: Unable to mount root
> fs on unknown-block(1,0)
> <0>Rebooting in 180 seconds..
If you're sure that you enable INITRD and EXT2 support in the kernel
and the problem still exist, check if initrd_start and initrd_end are
set correctly in platform_init().
In 2.6.x, parse_bootinfo() doesn't recognize u-boot's bd_t. One quick
and dirty solution is to set initrd_start and initrd_end to r4 and r5
respectively in platform_init().
=09/* set initrd parameters */
#ifdef CONFIG_BLK_DEV_INITRD
=09if (r4) {
=09 =09initrd_start =3D r4 + KERNELBASE;
=09=09initrd_end =3D r5 + KERNELBASE;
=09}
#endif /* CONFIG_BLK_DEV_INITRD */
Regards,
-Shawn.
^ 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