linuxppc-embedded help needed:kernel access of bad area
thanks very much.but i'm not going to write a user space program.
this is the detail:
//led-module.c
#ifndef __KERNEL__
#define __KERNEL__
#endif
#ifndef MODULE
#define MODULE
#endif
#include linux/config.h
#include linux/module.h
MODULE_LICENSE(GPL);
#ifdef CONFIG_SMP
#define __SMP__
#endif
#define CONFIG_TASK_SIZE 0x8000
#include asm/processor.h
#include linux/init.h
#include asm/uaccess.h /* copy_to_user(), copy_from_user() */
#include linux/fs.h /* struct file_operations, register_chrdev(), ... */
#include linux/kernel.h /* printk()*/
#include linux/sched.h
#include led-module.h
#define BCSRADDR 0x0450
static int PQ2FADS_GPL_open (struct inode *inode, struct file *filp);
static ssize_t PQ2FADS_GPL_read (struct file *filp, char *buf, size_t
count,loff_t *f_pos);
static ssize_t PQ2FADS_GPL_write (struct file *filp, const char *buf, size_t
count,loff_t *f_pos);
static int PQ2FADS_GPL_ioctl (struct inode *inode,struct file *filp,unsigned
int cmd,unsigned long scmd);
static int PQ2FADS_GPL_release (struct inode *inode, struct file *filp);
struct file_operations PQ2FADS_GPL_fops = {
open: PQ2FADS_GPL_open,
release: PQ2FADS_GPL_release,
ioctl: PQ2FADS_GPL_ioctl,
read: PQ2FADS_GPL_read,
write: PQ2FADS_GPL_write,
};
static int PQ2FADS_GPL_major;
static int PQ2FADS_GPL_state;
static volatile PQ2FADS_BCSR *PQ2FADS_GPL_CSR=0;
static int init_module(void)
{
printk (This' a PQ2FADS_ZU board GPL LED Device File!\n);
PQ2FADS_GPL_major = register_chrdev (0, GPL LED Device,
PQ2FADS_GPL_fops);
if (PQ2FADS_GPL_major 0)
{
printk(error1);
return PQ2FADS_GPL_major;
}
printk (The major is:%d\n, PQ2FADS_GPL_major);
return 0;
}
static void cleanup_module(void)
{
unregister_chrdev(PQ2FADS_GPL_major, GPL LED Device);
printk(PQ2FADS_ZU board GPL LED Device has been removed! bye!\n);
}
static int PQ2FADS_GPL_open(struct inode *inode,struct file *filp)
{
PQ2FADS_GPL_CSR=(PQ2FADS_BCSR*)BCSRADDR;
printk(open %s...OK!\n , current-comm);
return 0;
}
static int PQ2FADS_GPL_release(struct inode *inode,struct file *filp)
{
printk(closeOK!\n );
return 0;
}
static ssize_t PQ2FADS_GPL_read(struct file *filp,char *buf,size_t count,loff_t
*f_pos)
{
// char ledopen[20]=led is open.;
// char ledclose[20]=led is close.;
// count=20;
if(((PQ2FADS_GPL_CSR-bcsr0) 0x0200) == 0x0) printk(led is
open);
// else copy_to_user(buf,ledclose,20);
return count;
}
static ssize_t PQ2FADS_GPL_write(struct file *filp,const char *buf,size_t
count,loff_t *f_pos)
{
PQ2FADS_GPL_CSR-bcsr0 |=0x0200;
return 0;
}
static int PQ2FADS_GPL_ioctl(struct inode *inode,struct file *filp,unsigned int
cmd,unsigned long scmd)
{
return 0;
}
//led-app.c
#include stdio.h
int main(void)
{
int mydev,err;
char resultchar[20]=begin...;
mydev=open(/dev/PQ2FADS_GPL,rb+);
if(mydev0)
{
printf(open error.\n);
return 1;
}
err=read(mydev,resultchar,20);
if(err !=20) printf(read1 error!\n);
printf(read1=%s,resultchar);
err=write(mydev,resultchar,20);
if(err !=0) printf(write error!\n);
err=read(mydev,resultchar,20);
if(err !=20) printf(read2 error!\n);
printf(read2=%s,resultchar);
return 0;
}
i got led-module.o and led-app.exe
i insmod led-module.o
mknod /dev/PQ2FADS_GPL
and when i run led-app.exe
show:
# ./led-app.exe
open led-app.exe...OK!
Oops: kernel access of bad area, sig: 11
NIP: C30B11B4 XER: LR: C003A310 SP: C06B1F00 REGS: c06b1e50 TRAP: 0300
Not tainted
MSR: 9032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 0450, DSISR: 2000
TASK = c06b[201] 'led-app.exe' Last syscall: 3
last math c06b last altivec
GPR00: C003A310 C06B1F00 C06B C01A5AA0 7DE0 0014 C01A5AC0
GPR08: 0450 000C C01A 30025CE8 10018B5C
GPR16: 9032 006B1F40 C0003E88
GPR24: C0003BE0 0001 1500 7EA4 7DE0 FFEA C01A5AA0 0014
Call backtrace:
1A1C C003A310 C0003C3C 14AC 0FEC6D74
Segmentation fault
#
as you know,i am really a new gay.help me please.
- Original Message -
From: Fillod Stephane
To: zengshuai at sogou.com ;ppc
Subject: RE: linuxppc-embedded help needed:kernel access of bad area
Sent: Wed Nov 30 17:33:25 CST 2005
Dear zengshuai,
zengshuai at sogou.com wrote:
i writed a led driver for PQ2FADS(a ppc board).
but i can't read/write 0x0450 where led register addr locate in.
i tested two ways to do that.
first,
p=0x0450;
*p=0x12;
second,
outb(0x12,0x0450);
...
two ways both didn't work.they had a some wrong:kernel access of bad
area.
how can i know which area is bad
Xilinx_uartlite
Hi Tom, Thanks for your reply, but then I only get: Now booting the kernel Beste regards, Jaap -Oorspronkelijk bericht- Van: T Ziomek [mailto:ctz001 at email.mot.com] Verzonden: donderdag 1 december 2005 02:06 Aan: Jaap de Jong; linuxppc-embedded Onderwerp: Re: Xilinx_uartlite I'm trying to get my avnet virtex4fx12 running with linux. It boots, but ends with: Warning: unable to open an initial console. This means /dev/console was not opened; init is running. Since my board has no 16550 uart I must use xilinx_uartlite Part of my configuration: +--Character devices +--Xilinx UART Lite ON +--Console on UART Lite portON Any ideas? /dev/console may not be tied to your UARTLite. If you don't specify the console on your kernel command line, try adding something along the lines of console=ttyS0,19200 to it (with the appropriate device and baud rate of course). Tom -- /\ ASCII Ribbon Campaign | \ / | Email to user 'CTZ001' XAgainst HTML | at 'email.mot.com' / \ in e-mail news |
[PATCH] ibm_emac: fix graceful stop timeout handling
applied
AW: RE: linuxppc-embedded help needed:kernel access of bad area
Hello,
#define BCSRADDR 0x0450
...
static int PQ2FADS_GPL_open(struct inode *inode,struct file *filp)
{
PQ2FADS_GPL_CSR=(PQ2FADS_BCSR*)BCSRADDR;
possible you have to change physical address to logical see ioremap.
achim
bus error
//test.c
#include stdio.h
#include stdlib.h
#include sys/types.h
#include sys/stat.h
#include fcntl.h
#include unistd.h
#include sys/mman.h
int main(void)
{
static volatile char *reg_mem;
static int axs_mem_fd = -1;
axs_mem_fd = open(/dev/mem, O_RDWR|O_SYNC);
if (axs_mem_fd 0) {
perror(AXS: can't open /dev/mem);
return NULL;
}
/* memory map */
reg_mem =(volatile char*)mmap(
(caddr_t)reg_mem,
0x4,
PROT_READ|PROT_WRITE,
MAP_SHARED,
axs_mem_fd,
0x0460
);
if(reg_mem[0]==0x10) printf(OK);
else printf(sorry);
}
host:
ppc_6xx-gcc -o test test.c
target:
./test
Bus error
need help,thanks
--
?Sogou.com?2G??!
http://mail.sogou.com/recommend/sogoumail_invite_reg1.jsp?from=sogouinvitations_EMAIL=zengshuai%40sogou.comusername=linuxppc-embeddedFullName=linuxppc-embeddedEmail=linuxppc-embedded%40ozlabs.orgverify=755eff4e640bdcfc57d93cbd8b0a9cb7
porting linux to new board type
Hi! I stepped over your message without noticing, do you still need help? I do not have much experience yet, as I've been graduated only two month ago, but my job actualy is porting linux to custom boards, and I achieved my first one two weeks ago. So maybe I can hand out some usefull clues. Have fun :) +++
Linux hangs while Uncompressing
Hi All, I have RAM version of U-Boot which is running on a board similar to MPC8260. My memory map isas follows: Staring address Device Size Memory controller and CS 0800 FFF0 0F00 3000 3800 4200 5000 FLASH (Boot) FLASH (Code) SSRAM CPU internal registers SDRAM SDRAM Framer DSP 8102 1MB (512Kx16) 4 MB (1Mx16) 2 MB (512Kx36) 128 KB 128 MB (16Mx72) 128 MB (16Mx72) 1 MB 2 MB BR0/OR0: CS0 BR1/OR1: CS1 BR2/OR2: CS2 BR3/OR3: CS3 BR4/OR4: CS4 BR5/OR5: CS5 BR6/OR6: CS6 I have downloaded Linux 2.4.25 kernel image through kermit. after downloading the image in SDRAM location 0x3000 and giving the command bootm 0x3000 the prompt shows a message: TCS-PIC-UBOOT= loadb 0x3000## Ready for binary (kermit) download to 0x3000 at 57600 bps... ## Total Size = 0x000936f6 = 603894 Bytes ## Start Addr = 0x3000 TCS-PIC-UBOOT= bootm 0x3000## Booting image at 3000 ... Image Name: Linux-2.4.25 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:603830 Bytes = 589.7 kB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... The system hangs here and is not able to uncompress the kernel any further. I have checked in the FAQs provided in the denx's site, but could not find anything similar to my case. I would appreciate any help. Thanks Regards, Pritha Bhattacharya Tata Consultancy Services Limited Mailto: pritha.bhattacharya at tcs.com Website: http://www.tcs.com Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20051201/f2efec47/attachment.htm
8560 SCC uart driver
Hi all, It is required to configure one of the SCC of MPC8560 as complete UART and analog modem to be interfaced. Is driver already available in this regard or let me know how to proceed further. Thanks in advance. Regards, Kiran - Yahoo! Music Unlimited - Access over 1 million songs. Try it free. -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20051201/cf7257dd/attachment.htm
Linux hangs while Uncompressing
) SSRAM CPU internal registers SDRAM SDRAM Framer DSP 8102 1MB (512Kx16) 4 MB (1Mx16) 2 MB (512Kx36) 128 KB 128 MB (16Mx72) 128 MB (16Mx72) 1 MB 2 MB BR0/OR0: CS0 BR1/OR1: CS1 BR2/OR2: CS2 BR3/OR3: CS3 BR4/OR4: CS4 BR5/OR5: CS5 BR6/OR6: CS6 I have downloaded Linux 2.4.25 kernel image through kermit. after downloading the image in SDRAM location 0x3000 and giving the command bootm 0x3000 the prompt shows a message: TCS-PIC-UBOOT= loadb 0x3000## Ready for binary (kermit) download to 0x3000 at 57600 bps... ## Total Size = 0x000936f6 = 603894 Bytes ## Start Addr = 0x3000 TCS-PIC-UBOOT= bootm 0x3000## Booting image at 3000 ... Image Name: Linux-2.4.25 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:603830 Bytes = 589.7 kB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... The system hangs here and is not able to uncompress the kernel any further. I have checked in the FAQs provided in the denx's site, but could not find anything similar to my case. I would appreciate any help. Thanks Regards, Pritha Bhattacharya Tata Consultancy Services Limited Mailto: pritha.bhattacharya at tcs.com Website: http://www.tcs.com Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20051201/f2efec47/attachment.htm -- ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded End of Linuxppc-embedded Digest, Vol 16, Issue 3
Linux hangs while Uncompressing
Hi All,
I have RAM version of U-Boot which is running on a board similar to MPC8260. My
memory map isas follows:
Staring addressDeviceSize
Memory controller and CS
0800
FFF0
0F00
3000
3800
4200
5000 FLASH (Boot)
FLASH (Code)
SSRAM
CPU internal registers
SDRAM
SDRAM
Framer
DSP 8102 1MB (512Kx16)
4 MB (1Mx16)
2 MB (512Kx36)
128 KB
128 MB (16Mx72)
128 MB (16Mx72)
1 MB
2 MB BR0/OR0: CS0
BR1/OR1: CS1
BR2/OR2: CS2
BR3/OR3: CS3
BR4/OR4: CS4
BR5/OR5: CS5
BR6/OR6: CS6
This configuration will not work for linux. Linux needs to run in SDRAM
starting at zero (notice
'Load Address' and 'Entry Point' just before 'uncompressing image'.)
Mark Chambers
-- next part --
An HTML attachment was scrubbed...
URL:
http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20051201/dcd53f69/attachment.htm
[PATCH] ppc32: 8xx board-specific platform stuff for fs_enet
On Wed, Nov 30, 2005 at 01:08:31AM -0600, Kumar Gala wrote: Hi Kumar, I dont really know the policy for driver placement, but it seems that it works on a case by case basis. The files in arch/ppc/8xx_io/ (which is what I think you refer to as candidates for drivers/), are: We have been slowly working on moving drivers out of arch/ppc and into drivers/ so that subsystem maintainers could get proper review of them. 1) commproc.c Basic API for dpram access. Core code. 2) micropatch.c microcode update code/data. Core code. Well #1 #2 aren't what I would call drivers at all. I would consider them syslib/ candidates. Hopefully, someone will Move them there? Yeah... We can add that to the 8xx TODO list if its interesting. 3) cs4218.h 4) cs4218_tdm.c cs4218 does not compile at the moment due to syntatical problems, I've fixed them up and the driver compiles, but I don't know if it works (patch attached). I would not be surprised if the driver has been broken since long time ago. Does anyone have hardware to test it? Dan? Otherwise we should remove it from the tree, since its unmaintained and unused. If its still good, I would guessing /drivers/audio or snd, but neither seem to exist. I wondering where sound card drivers live these days. snd/ I think... Someone needs to test the driver. I think we should just fixup the syntactical problems and mark it as BROKEN until someone (Dan?) confirms it works. 5) enet.c 6) fec.c The ENET/FEC network drivers are obseleted by fs_enet. However there are some PHY descriptions in fec.c which are missing from fs_enet - we'd better make sure to have them all in the new driver before removing the old one. Agreed. Aris, would you mind looking into this? Once we have that we can set a deadline at Documentation/feature- removal.txt if desired. Other than those there are no 8xx drivers in arch/ppc/ AFAIK. cs42.patch Good deal. Are we really removing anything (except maybe cs4218)? FEC certainly and cs4218 seems like a candidate. Thanks for your comments!
MPC8555 8280/8270 USB host support
Hi Mike I've made some modifications due to the difference between mpc8272 and mpc8270. MPC8272 use SCC3 and MPC8270 use SCC4. Added some more clock configuration options ... I think the changes are quite generic. The driver seems to work with a 2.6.13 kernel. Only some basic tests is performed with - serial ftdi_sio to ports ttyUSB0 ttyUSB1 - storage i.e. some kind of no name usb-memory - 3 1/4 floppy drive - Nokia hub. Don't you think u-boot should take care of clock setup i.e. as much as possible of all board dependent stuff ? Regards Hans Schillstrom On Tue, 2005-11-15 at 07:59, Mike Rapoport wrote: Hans Schillstrom wrote: Hi Mike I'm working with a 8270 board and 2.6.12 kernel and searching for USB drivers. Could you help me finding the files ? I've opened a project on the SourceForge, http://cpm2usb.sourceforge.net. The file containing patch against 2.6.12.3 can be downloaded at http://sourceforge.net/projects/cpm2usb. I can help you with the testing. What status do they have right now ? The driver was developed on MPC8272ADS, but should go as well on 8270 since they have the same USB host controller AFAIK. Currently, as far as I tested it works fine with full-speed single device attached through hub, but fails is there are transfers from/to several devices simultaneously. As for the code itself, it's far from being perfect. Regards Hans -- next part -- A non-text attachment was scrubbed... Name: m8270usb.patch Type: text/x-patch Size: 6861 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20051201/b9ac91c3/attachment.bin
[PATCH] ppc32: Add TQM85xx (8540/8541/8555/8560) board support
This patch adds support for the TQ Components TQM85xx modules. Currently the modules TQM8540/8541/8555/8560 are supported. Signed-off-by: Stefan Roese sr at denx.de Best regards, Stefan -- next part -- A non-text attachment was scrubbed... Name: add-tqm85xx-board-support-2.patch Type: text/x-diff Size: 100665 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20051201/46a9119b/attachment.patch
MPC8555 8280/8270 USB host support
Hans Schillstrom wrote: Hi Mike I've made some modifications due to the difference between mpc8272 and mpc8270. MPC8272 use SCC3 and MPC8270 use SCC4. Added some more clock configuration options ... Thanks a lot. I've added your patch as is to the SF page. Don't you think u-boot should take care of clock setup i.e. as much as possible of all board dependent stuff ? I think you're right, but then it was easier to make all these setups in the driver itself. Regards Hans Schillstrom -- Sincerely yours, Mike Rapoport
[PATCH] ppc32: 8xx board-specific platform stuff for fs_enet
On Dec 1, 2005, at 7:17 AM, Marcelo Tosatti wrote: snd/ I think... Someone needs to test the driver. I think we should just fixup the syntactical problems and mark it as BROKEN until someone (Dan?) confirms it works. Since I'm probably the only one left in the world with this hardware, it probably doesn't make sense to keep it around. I know people have used it in the past as an example of how to program the TDM on the 8xx, but it's not necessary to keep it around for that reason. Thanks. -- Dan
Linux hangs while Uncompressing
Try to change your 'load address' and 'entry address' to a more sensible value, maybe 0x3008 or so. This is done when you create the PPCBOOT image with mkimage, by passing parameters -a and -e respectively. Right now, U-boot tries to uncompress the kernel into your boot flash, which hopefully is hw-protected.. good luck /Carl On Thu, 01 Dec 2005 10:59:10 +0100, pritha.bhattacharya at tcs.com wrote: Hi All, I have RAM version of U-Boot which is running on a board similar to MPC8260. My memory map isas follows: Staring address Device Size Memory controller and CS 0800 FFF0 0F00 3000 3800 4200 5000 FLASH (Boot) FLASH (Code) SSRAM CPU internal registers SDRAM SDRAM Framer DSP 8102 1MB (512Kx16) 4 MB (1Mx16) 2 MB (512Kx36) 128 KB 128 MB (16Mx72) 128 MB (16Mx72) 1 MB 2 MB BR0/OR0: CS0 BR1/OR1: CS1 BR2/OR2: CS2 BR3/OR3: CS3 BR4/OR4: CS4 BR5/OR5: CS5 BR6/OR6: CS6 I have downloaded Linux 2.4.25 kernel image through kermit. after downloading the image in SDRAM location 0x3000 and giving the command bootm 0x3000 the prompt shows a message: TCS-PIC-UBOOT= loadb 0x3000## Ready for binary (kermit) download to 0x3000 at 57600 bps... ## Total Size = 0x000936f6 = 603894 Bytes ## Start Addr = 0x3000 TCS-PIC-UBOOT= bootm 0x3000## Booting image at 3000 ... Image Name: Linux-2.4.25 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:603830 Bytes = 589.7 kB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... The system hangs here and is not able to uncompress the kernel any further. I have checked in the FAQs provided in the denx's site, but could not find anything similar to my case. I would appreciate any help. Thanks Regards, Pritha Bhattacharya Tata Consultancy Services Limited Mailto: pritha.bhattacharya at tcs.com Website: http://www.tcs.com Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you
[PATCH] ppc32: 8xx board-specific platform stuff for fs_enet
On Dec 1, 2005, at 6:17 AM, Marcelo Tosatti wrote: On Wed, Nov 30, 2005 at 01:08:31AM -0600, Kumar Gala wrote: Hi Kumar, I dont really know the policy for driver placement, but it seems that it works on a case by case basis. The files in arch/ppc/8xx_io/ (which is what I think you refer to as candidates for drivers/), are: We have been slowly working on moving drivers out of arch/ppc and into drivers/ so that subsystem maintainers could get proper review of them. 1) commproc.c Basic API for dpram access. Core code. 2) micropatch.c microcode update code/data. Core code. Well #1 #2 aren't what I would call drivers at all. I would consider them syslib/ candidates. Hopefully, someone will Move them there? Yeah... We can add that to the 8xx TODO list if its interesting. I would just wait and move them to arch/powerpc/sysdev whenever 8xx moves over to arch/powerpc. No reason to move the files twice. 3) cs4218.h 4) cs4218_tdm.c cs4218 does not compile at the moment due to syntatical problems, I've fixed them up and the driver compiles, but I don't know if it works (patch attached). I would not be surprised if the driver has been broken since long time ago. Does anyone have hardware to test it? Dan? Otherwise we should remove it from the tree, since its unmaintained and unused. If its still good, I would guessing /drivers/audio or snd, but neither seem to exist. I wondering where sound card drivers live these days. snd/ I think... Someone needs to test the driver. I think we should just fixup the syntactical problems and mark it as BROKEN until someone (Dan?) confirms it works. Agreed. 5) enet.c 6) fec.c The ENET/FEC network drivers are obseleted by fs_enet. However there are some PHY descriptions in fec.c which are missing from fs_enet - we'd better make sure to have them all in the new driver before removing the old one. Agreed. Aris, would you mind looking into this? Once we have that we can set a deadline at Documentation/feature- removal.txt if desired. Other than those there are no 8xx drivers in arch/ppc/ AFAIK. cs42.patch Good deal. Are we really removing anything (except maybe cs4218)? FEC certainly and cs4218 seems like a candidate. Well cs4218 depends on Dan's feedback. As far as FEC, I see that we replaced it with something else. So we should feel free to remove it from 8xx_io as long as we feel that the new driver will work for people and update the in kernel platforms for it. - kumar
Mailing list
Hi all For the sake of the mailing list (and my own sake) do you know of a mailer tool which handles the in-reply-to field ? And of course, how should the field be set with this particular tool. Thanks a lot.
Linux hangs while Uncompressing
In message OF0098DF7F.857DE409-ON652570CA.001AA3F7-652570CA.0036DB32 at tcs.com you wrote: I have RAM version of U-Boot which is running on a board similar to MPC8260. My memory map isas follows: Your mode of operation is unsupported. You either ignored to read the FAQ, or it's content: http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStartedInRAM Staring address Device Size Memory controller and CS ... 0F00 CPU internal registers 3000 SDRAM ... Your memory map is bogus. You either ignored to read the FAQ, or it's content: http://www.denx.de/wiki/view/PPCEmbedded/Kernel#Section_10.2. ... Verifying Checksum ... OK Uncompressing Kernel Image ... The system hangs here and is not able to uncompress the kernel any further. I have checked in the FAQs provided in the denx's site, but could not find anything similar to my case. You either ignored to read the FAQ, or it's content: http://www.denx.de/wiki/view/DULG/LinuxUncompressingError I think you should go back and read the existing documentation, and follow the advice it contains. If you continue to ignore what's written in the FAQ's you would probably also ignore any answeres to your postings here. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de This is an unauthorized cybernetic announcement.
MPC8555 8280/8270 USB host support
In message 1133439981.8518.237.camel at hawk.pwav.net you wrote: Don't you think u-boot should take care of clock setup i.e. as much as possible of all board dependent stuff ? No, it should not. A river should not make any assumptions about the state of the hardware, but initialize everything it needs for correct operation itself. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Save yourself! Reboot in 5 seconds!
MPC8555 8280/8270 USB host support
Hi Don't you think u-boot should take care of clock setup i.e. as much as possible of all board dependent stuff ? I think you're right, but then it was easier to make all these setups in the driver itself. If u-boot is the boot loader of your board (the stuff running on it --before-- we see this: loaded at: 0040 005153B4 board data at: 00513130 00513334 relocated to: 00405090 00405294 zimage at: 00405A85 00512099 avail ram: 00516000 0800 Linux/PPC load: rw console=ttyS0 root=/dev/nfs ip=on Uncompressing Linux...done) Then I would say NO If u-boot is this exact stuff (the files in arch/ppc/boot/simple/... misc-embedded.c for example) then, yes, this is somehow better. But (tell me if I'm wrong) this is not really Linux code, and this should be done by Linux. What I think should be good also is the platform files (arch/ppc/platforms/) for this is the place where all the board dependant stuff stays. Maybe I'm completely mistaken. Feel free to tell me (and explain please !) Have fun.
linuxppc-embedded help needed:kernel access of bad area
-Original Message- From: zengshuai at sogou.com Sent: Thursday, December 01, 2005 00:52 #define BCSRADDR 0x0450 This address is wrong. It's the address the manual gives, but the bootloadre usually moves it because it interferes with the SDRAM when running Linux. Check the bootloader, or even better, if you know which ChipSelect the BCSR is on, read the BRn register and use that address. sort of like: bcsr_addr = cpm2_immr-im_memctl.memc_br1 0x8000; // BCSR is on CS1 on MPC8266ADS board
MPC8555 8280/8270 USB host support
In message 438F198F.9020606 at cpe.fr you wrote: If u-boot is the boot loader of your board (the stuff running on it --before-- we see this: loaded at: 0040 005153B4 board data at: 00513130 00513334 relocated to: 00405090 00405294 zimage at: 00405A85 00512099 avail ram: 00516000 0800 If U-Boot is your boot load, *and* you see this, than you made some serious mistake. U-Boot is supposed to boot the uImage images, which do not issue such messages. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de The shortest unit of time in the multiverse is the News York Second, defined as the period of time between the traffic lights turning green and the cab behind you honking. - Terry Pratchett, _Lords and Ladies_
PPC 32bits and big RAM mapping problem
Hello, I have a PPC board with an address width fixed to 32bits, so I can address 4GB. M MM M M M M 0 00 0 0 1 e 0 28 c e e f --- --- | Physical || PCI | Kernel | Kernel | User | Peripheral | | RAM | unused | memory | memory | reserved | memory| mapping | | || | kmalloc | | vmalloc | | | ex 512MB || ex 1GB | ex 512MB | 16MB | | ex 32MB | | 2GB max | 1GB max | max ?| | 464MB max | | --- --- (0) (1) (2) 00M stand for 0x (0) kernel_base (1) vmalloc_start (2) vmalloc_end The exemple above shows a classical(?) mapping with a physical RAM of 512MB. The physical RAM can growth up to 2GB, but if the kernel maps a Kernel memory of 2GB, there is no more place for the other items. The 4GB are eated. Even with only 512MB of RAM, the kernel can't fully vmalloc it for user. I know that the kernel and drivers kmalloc in Kernel memory which has the full space but when the users wants more RAM, it is for vmallocations. Now when the physical RAM increases, the User memory is reduced for vmalloc. And I don't talk about Peripheral mappings which also reduce the User memory. So I'm under the impression to be cornered in my shoes. Any idea, book, article, prediction would be welcome. Thanks Laurent
PPC 32bits and big RAM mapping problem
-Original Message- From: Laurent Lagrange Sent: Thursday, December 01, 2005 11:48 To: linuxppc-embedded at ozlabs.org Subject: PPC 32bits and big RAM mapping problem So I'm under the impression to be cornered in my shoes. Any idea, book, article, prediction would be welcome. I have 2GB of ram working on my PPC32 board. You have to change the following in the kernel config: Under Advanced Setup: Set Maximum Low memory (Set to 0x4000) Set Custom Kernel config address (Set to 0xA000) I do not remember if I had to change anything else.
PPC 32bits and big RAM mapping problem
On Thu, Dec 01, 2005 at 12:43:02PM -0600, Rune Torgersen wrote: -Original Message- From: Laurent Lagrange Sent: Thursday, December 01, 2005 11:48 To: linuxppc-embedded at ozlabs.org Subject: PPC 32bits and big RAM mapping problem So I'm under the impression to be cornered in my shoes. Any idea, book, article, prediction would be welcome. I have 2GB of ram working on my PPC32 board. You have to change the following in the kernel config: Under Advanced Setup: Set Maximum Low memory (Set to 0x4000) Set Custom Kernel config address (Set to 0xA000) I do not remember if I had to change anything else. If you have 2GB you had to have something else. Right now you have it set to constrict the max lowmem to 1GB. So, you must have CONFIG_HIGHMEM on as well to utilize the other 1GB. To answer the original poster's question: simply enable CONFIG_HIGHMEM and UP system will have 768MB in lowmem and the rest in highmem. If there's some constraint on your application (like many embedded apps) that requires all 2GB in lowmem then configure: Set Maximum low memory (Set to 0x8000) Set custom kernel base address (Set to 0x4000) Set custom user task size (Set to 0x4000) Don't do this unless highmem won't work for your app. If you use this approach each process will be limited to 1GB of virtual memory which may or may not be an OK tradeoff for your app. -Matt
PPC 32bits and big RAM mapping problem
-Original Message- From: Matt Porter [mailto:mporter at kernel.crashing.org] Sent: Thursday, December 01, 2005 12:56 If you have 2GB you had to have something else. Right now you have it set to constrict the max lowmem to 1GB. So, you must have CONFIG_HIGHMEM on as well to utilize the other 1GB. Ahh.. Yep, have CONFIG_HIGHMEM set. I only did 1G of kernel low mem, so that there still would be space left for vmalloc mappings. I have a 8265 witch uses 0xf000 and up for internal stuff and flash, so with 1G lowmem and kernel baseadr set to 0xa I have 0xe000 to 0xe for virtual address space. I do not remember if I had to patch some other parts of the kernel also. I do not think I did. Can't chech right now either, because we used bitkeeper and I cannot even check the commit logs anymore.
