From: Daniel Wu <hidden> Date: 2000-05-19 04:31:30
Hi,
I have a question about the embedded ppc port of Linux which I hope you can
help me with.
I compiled the mpc8xx-2.2.13 sources using the attached configuration for a
MPC860T based board with 32MB of RAM. The output vmlinux file was downloaded to
the target using a BDM debugger. I changed the KERNELLOAD and KERNELBASE to
1000000 instead of c0000000 so that the code is located at the start of the
16MB region.
When I step through the code (.../arch/ppc/kernel/head.S), I see that the code
is crashing after the rfi. The PC is 0x02000000 (32MB), which is greater than
the available RAM. But I checked the value of r0 and it looks reasonable, ie.
where the start_here is defined.
*** Line 1753 ***
lis r0,start_here@h
ori r0,r0,start_here@l
1010: mtspr SRR0,r0
SYNC
rfi /* enables MMU */
#ifdef CONFIG_SMP
.globl __secondary_start_psurge
__secondary_start_psurge:
li r24,1 /* cpu # */
b __secondary_start
etc.
Do you have any suggestions to how to track down this problem? Is this
introduced by the fact that I changed the address of the KERNELBASE?
I hope you can help me here or point me in the right direction for
documentation.
Thanks in advance for your comments.
Kind regards,
Daniel
PS. Please reply directly to me as I am not subscribed to the mailing list.
From: Graham Stoney <hidden> Date: 2000-05-19 05:10:50
Hi Daniel,
Daniel Wu writes:
I compiled the mpc8xx-2.2.13 sources using the attached configuration for a
MPC860T based board with 32MB of RAM. The output vmlinux file was downloaded
to the target using a BDM debugger. I changed the KERNELLOAD and KERNELBASE
to 1000000 instead of c0000000 so that the code is located at the start of
the 16MB region.
From: Daniel Wu <hidden> Date: 2000-05-19 08:09:22
Hi Graham,
Graham Stoney wrote:
To quote Grant Erickson in
http://lists.linuxppc.org/listarcs/linuxppc-embedded/200001/msg00123.html:
"You don't ever want to change KERNELLOAD or KERNELBASE, otherwise the
virtual memory and MMU code will all break."
This seems to be a common error, so I might add mention of it in the HOWTO.
Yes, I saw the article after sending the question. But this doesn't really help me
:-( I've put back the KERNELLOAD and KERNELBASE address back to their orginal
values and load the zImage (in the .../arch/ppc/mbxboot directory) rather than the
vmlinux file using the BDM debugger but it still crashes very early in the piece.
To be precise, while clearing the BSS.
/* Clear all of BSS */
lis r3,edata@h
ori r3,r3,edata@l
lis r4,end@h
ori r4,r4,end@l
subi r3,r3,4
subi r4,r4,4
li r0,0
50: stwu r0,4(r3) <---- crashes here
cmp 0,r3,r4
bne 50b
The strange thing is that it seems to work if I step through the loop. In any
case, it crashes soon after that in serial_init.
I think I'm missing something fundamental here ... any suggestions.
Regards,
Daniel
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Graham Stoney <hidden> Date: 2000-05-19 08:19:51
Daniel Wu writes:
I think I'm missing something fundamental here ... any suggestions.
Have you checked that your BDM configuration file is disabling the watchdog
when releasing the board from reset?
Regards,
Graham
--
Graham Stoney
Principal Hardware/Software Engineer
Canon Information Systems Research Australia
Ph: +61 2 9805 2909 Fax: +61 2 9805 2929
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Dan A. Dickey <hidden> Date: 2000-05-19 11:07:41
Graham Stoney wrote:
Daniel Wu writes:
quoted
I think I'm missing something fundamental here ... any suggestions.
Have you checked that your BDM configuration file is disabling the watchdog
when releasing the board from reset?
Also check that DER is zero'd when running with the debugger.
That was my situation in some previous posts.
-Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Ralph Blach <hidden> Date: 2000-05-19 11:39:31
Daniel,
Although I am not an expert, I really think the lowest kernel base is
0x80000000.
This is because the Linux which we have assumes that we have memory from
0x0 - 0x7fffffff
avaliable for tasks. So I think the kernel will have to move above
0x80000000.
Chip
Daniel Wu wrote:
Hi,
I have a question about the embedded ppc port of Linux which I hope you can
help me with.
I compiled the mpc8xx-2.2.13 sources using the attached configuration for a
MPC860T based board with 32MB of RAM. The output vmlinux file was downloaded to
the target using a BDM debugger. I changed the KERNELLOAD and KERNELBASE to
1000000 instead of c0000000 so that the code is located at the start of the
16MB region.
When I step through the code (.../arch/ppc/kernel/head.S), I see that the code
is crashing after the rfi. The PC is 0x02000000 (32MB), which is greater than
the available RAM. But I checked the value of r0 and it looks reasonable, ie.
where the start_here is defined.
*** Line 1753 ***
lis r0,start_here@h
ori r0,r0,start_here@l
1010: mtspr SRR0,r0
SYNC
rfi /* enables MMU */
#ifdef CONFIG_SMP
.globl __secondary_start_psurge
__secondary_start_psurge:
li r24,1 /* cpu # */
b __secondary_start
etc.
Do you have any suggestions to how to track down this problem? Is this
introduced by the fact that I changed the address of the KERNELBASE?
I hope you can help me here or point me in the right direction for
documentation.
Thanks in advance for your comments.
Kind regards,
Daniel
PS. Please reply directly to me as I am not subscribed to the mailing list.
------------------------------------------------------------------------
#
# Automatically generated make config: don't edit
#
#
# Platform support
#
CONFIG_PPC=y
# CONFIG_6xx is not set
# CONFIG_PPC64 is not set
CONFIG_8xx=y
# CONFIG_MPC821 is not set
# CONFIG_MPC823 is not set
# CONFIG_MPC850 is not set
# CONFIG_MPC860 is not set
CONFIG_MPC860T=y
CONFIG_SERIAL_CONSOLE=y
# CONFIG_PMAC is not set
# CONFIG_PREP is not set
# CONFIG_CHRP is not set
# CONFIG_ALL_PPC is not set
# CONFIG_APUS is not set
CONFIG_MBX=y
# CONFIG_RPXLITE is not set
# CONFIG_RPXCLASSIC is not set
# CONFIG_BSEIP is not set
# CONFIG_SMP is not set
CONFIG_MACH_SPECIFIC=y
#
# General setup
#
# CONFIG_EXPERIMENTAL is not set
CONFIG_MODULES=y
# CONFIG_MODVERSIONS is not set
CONFIG_KMOD=y
# CONFIG_PCI is not set
# CONFIG_PCI_QUIRKS is not set
CONFIG_NET=y
CONFIG_SYSCTL=y
CONFIG_SYSVIPC=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_BINFMT_ELF=y
CONFIG_KERNEL_ELF=y
# CONFIG_BINFMT_MISC is not set
# CONFIG_BINFMT_JAVA is not set
# CONFIG_PARPORT is not set
# CONFIG_VGA_CONSOLE is not set
# CONFIG_FB is not set
#
# Plug and Play support
#
# CONFIG_PNP is not set
#
# Block devices
#
# CONFIG_BLK_DEV_FD is not set
CONFIG_BLK_DEV_IDE=y
#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_BLK_DEV_IDECD=y
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
# CONFIG_BLK_DEV_IDESCSI is not set
# CONFIG_BLK_DEV_CMD640 is not set
# CONFIG_IDE_CHIPSETS is not set
#
# Additional Block Devices
#
# CONFIG_BLK_DEV_LOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_MD is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_INITRD=y
# CONFIG_BLK_DEV_XD is not set
CONFIG_PARIDE_PARPORT=y
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_DEV_HD is not set
#
# Networking options
#
CONFIG_PACKET=y
CONFIG_NETLINK=y
# CONFIG_RTNETLINK is not set
# CONFIG_NETLINK_DEV is not set
# CONFIG_FIREWALL is not set
# CONFIG_FILTER is not set
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
# CONFIG_IP_ROUTER is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
CONFIG_IP_ALIAS=y
# CONFIG_SYN_COOKIES is not set
#
# (it is safe to leave these untouched)
#
CONFIG_INET_RARP=y
CONFIG_SKB_LARGE=y
#
#
#
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
#
# SCSI support
#
# CONFIG_SCSI is not set
# CONFIG_SCSI_G_NCR5380_PORT is not set
# CONFIG_SCSI_G_NCR5380_MEM is not set
#
# Network device support
#
CONFIG_NETDEVICES=y
#
# ARCnet devices
#
# CONFIG_ARCNET is not set
# CONFIG_DUMMY is not set
# CONFIG_EQUALIZER is not set
# CONFIG_NET_SB1000 is not set
#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
# CONFIG_MACE is not set
# CONFIG_BMAC is not set
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_LANCE is not set
# CONFIG_NET_VENDOR_SMC is not set
# CONFIG_NET_VENDOR_RACAL is not set
# CONFIG_NET_ISA is not set
# CONFIG_NET_EISA is not set
# CONFIG_NET_POCKET is not set
# CONFIG_FDDI is not set
CONFIG_PPP=y
#
# CCP compressors for PPP are only built as modules.
#
CONFIG_SLIP=y
# CONFIG_SLIP_COMPRESSED is not set
# CONFIG_SLIP_SMART is not set
# CONFIG_SLIP_MODE_SLIP6 is not set
# CONFIG_NET_RADIO is not set
#
# Token ring devices
#
# CONFIG_TR is not set
# CONFIG_NET_FC is not set
#
# Wan interfaces
#
# CONFIG_HOSTESS_SV11 is not set
# CONFIG_COSA is not set
# CONFIG_SEALEVEL_4021 is not set
# CONFIG_DLCI is not set
# CONFIG_WAN_DRIVERS is not set
# CONFIG_SBNI is not set
#
# Amateur Radio support
#
# CONFIG_HAMRADIO is not set
#
# ISDN subsystem
#
# CONFIG_ISDN is not set
#
# Old CD-ROM drivers (not SCSI, not IDE)
#
# CONFIG_CD_NO_IDESCSI is not set
#
# Console drivers
#
#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
# CONFIG_SERIAL is not set
# CONFIG_SERIAL_EXTENDED is not set
# CONFIG_SERIAL_NONSTANDARD is not set
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256
# CONFIG_MOUSE is not set
# CONFIG_QIC02_TAPE is not set
# CONFIG_WATCHDOG is not set
# CONFIG_NVRAM is not set
# CONFIG_RTC is not set
#
# Video For Linux
#
# CONFIG_VIDEO_DEV is not set
#
# Joystick support
#
# CONFIG_JOYSTICK is not set
# CONFIG_DTLK is not set
#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
# CONFIG_FT_NORMAL_DEBUG is not set
# CONFIG_FT_FULL_DEBUG is not set
# CONFIG_FT_NO_TRACE is not set
# CONFIG_FT_NO_TRACE_AT_ALL is not set
# CONFIG_FT_STD_FDC is not set
# CONFIG_FT_MACH2 is not set
# CONFIG_FT_PROBE_FC10 is not set
# CONFIG_FT_ALT_FDC is not set
#
# USB drivers - not for the faint of heart
#
#
# Filesystems
#
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
# CONFIG_UMSDOS_FS is not set
CONFIG_VFAT_FS=y
# CONFIG_ISO9660_FS is not set
# CONFIG_JOLIET is not set
# CONFIG_MINIX_FS is not set
# CONFIG_NTFS_FS is not set
# CONFIG_HPFS_FS is not set
CONFIG_PROC_FS=y
CONFIG_DEVPTS_FS=y
# CONFIG_ROMFS_FS is not set
CONFIG_EXT2_FS=y
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
#
# Network File Systems
#
# CONFIG_CODA_FS is not set
CONFIG_NFS_FS=y
CONFIG_SUNRPC=y
CONFIG_LOCKD=y
# CONFIG_SMB_FS is not set
# CONFIG_NCP_FS is not set
#
# Partition Types
#
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MAC_PARTITION is not set
# CONFIG_SMD_DISKLABEL is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
CONFIG_NLS=y
#
# Native Language Support
#
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_1 is not set
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=y
# CONFIG_NLS_KOI8_R is not set
#
# Sound
#
# CONFIG_SOUND is not set
#
# MPC8xx CPM Options
#
# CONFIG_SCC_ENET is not set
# CONFIG_FEC_ENET is not set
# CONFIG_CPM_IIC is not set
# CONFIG_UCODE_PATCH is not set
# CONFIG_RPXLCD is not set
#
# Kernel hacking
#
# CONFIG_MAGIC_SYSRQ is not set
# CONFIG_KGDB is not set
# CONFIG_XMON is not set
From: Daris A Nevil <hidden> Date: 2000-05-19 12:57:45
Graham,
I fell vicitm to the same mistake when I was writing boot code
for MPC850. I think adding that to the HOWTO is a great
idea. It would have save me 2 or 3 weeks of effort :-).
Daris Nevil
SiSIC Inc/SNMC
Graham Stoney wrote:
Hi Daniel,
Daniel Wu writes:
quoted
I compiled the mpc8xx-2.2.13 sources using the attached configuration for a
MPC860T based board with 32MB of RAM. The output vmlinux file was downloaded
to the target using a BDM debugger. I changed the KERNELLOAD and KERNELBASE
to 1000000 instead of c0000000 so that the code is located at the start of
the 16MB region.
To quote Grant Erickson in
http://lists.linuxppc.org/listarcs/linuxppc-embedded/200001/msg00123.html:
"You don't ever want to change KERNELLOAD or KERNELBASE, otherwise the
virtual memory and MMU code will all break."
This seems to be a common error, so I might add mention of it in the HOWTO.
Regards,
Graham
--
Daris A Nevil
SiSIC, Inc., f.k.a. Simple Network Magic Corporation
401 Kentucky Lane
McKinney, TX 75069
214-793-7757
dnevil@snmc.com
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Ralph Blach <hidden> Date: 2000-05-19 13:09:31
Daris,
I disagree. I beleive that the Kernel load simply must be above
0x80000000.
And I you want to put a lot of memory in one of these systems, it had
better be movable down from 0xc0000000. On the IBM405gp and I assume,
the 8xx systems, all of real memory is pinned
into a to TLB's. Well, if one can't move the memory base down the the
real memory available is from 0xc0000000 to whereve the IO starts. In
the IBM405gp, this is at 0xe80000000.
Chip
Daris A Nevil wrote:
Graham,
I fell vicitm to the same mistake when I was writing boot code
for MPC850. I think adding that to the HOWTO is a great
idea. It would have save me 2 or 3 weeks of effort :-).
Daris Nevil
SiSIC Inc/SNMC
Graham Stoney wrote:
quoted
Hi Daniel,
Daniel Wu writes:
quoted
I compiled the mpc8xx-2.2.13 sources using the attached configuration for a
MPC860T based board with 32MB of RAM. The output vmlinux file was downloaded
to the target using a BDM debugger. I changed the KERNELLOAD and KERNELBASE
to 1000000 instead of c0000000 so that the code is located at the start of
the 16MB region.
To quote Grant Erickson in
http://lists.linuxppc.org/listarcs/linuxppc-embedded/200001/msg00123.html:
"You don't ever want to change KERNELLOAD or KERNELBASE, otherwise the
virtual memory and MMU code will all break."
This seems to be a common error, so I might add mention of it in the HOWTO.
Regards,
Graham
--
Daris A Nevil
SiSIC, Inc., f.k.a. Simple Network Magic Corporation
401 Kentucky Lane
McKinney, TX 75069
214-793-7757
dnevil@snmc.com
From: Dan Malek <hidden> Date: 2000-05-19 15:50:38
Ralph Blach wrote:
I disagree. I beleive that the Kernel load simply must be above
0x80000000.
OK, time for another memory map lesson........
Virtual addresses from 0 to 0x7fffffff are for user context. Above
this are the kernel virtual addresses. The PowerPC processors have
more than 32-bits of addressing, but I won't go into that since it
is not important for this discussion.
During the early kernel initialization, the kernel virtual memory
allocator is not operational. Prior to this KVM initialization, we
choose to map virtual to physical addresses 1:1. That is, the kernel
virtual address exactly matches the physical address on the bus. These
mappings are typically done in arch/ppc/kernel/head.S, or
arch/ppc/mm/init.c. Only absolutely necessary mappings should be
done at this time, for example board control registers or a serial
uart. Normal device driver initialization should map resources
later when necessary.
Although platform dependent, and certainly the case for embedded 8xx,
traditionally memory is mapped at physical address zero, and I/O
devices above phsical address 0x80000000. The lowest and highest
(above 0xf0000000) I/O addresses are traditionally used for devices
or registers we need to map during kernel initialization and prior
to KVM operation. For this reason, and since it followed prior PowerPC
platform examples, I chose to map the embedded 8xx kernel to the
0xc0000000 virtual address. This way, we can enable the MMU to map the
kernel for proper operation, and still map a few windows before the
KVM is operational.
On some systems, you could possibly run the kernel at the 0x80000000
or any other virtual address. It just depends upon mapping that must
be done prior to KVM operational. You can never map devices or
kernel spaces that overlap with the user virtual space. This is why
default IMMR mapping used by most BDM tools won't work. They put
the IMMR at something like 0x10000000 or 0x02000000 for example. You
simply can't map these addresses early in the kernel, and continue
proper system operation.
The embedded 8xx/82xx kernel is mature enough that all you should need
to do is map the IMMR someplace at or above 0xf0000000 and it should
boot far enough to get serial console messages and KGDB connected on
any platform. There are lots of other subtle memory management design
features that you simply don't need to worry about. If you are changing
functions related to MMU initialization, you are likely breaking things
that are known to work and are heading down a path of disaster and
frustration. Your changes should be to make the flexibility of the
processor fit Linux, not force arbitrary and non-workable memory
mappings into Linux.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Daniel Wu <hidden> Date: 2000-05-23 07:18:36
Hi,
Thanks to all who responsed to my last qeustion. The problem was that the immr
was not setup correctly. Also since it is a custom board (MPC860T based), I had
to rewrite code to fill in the bd_t structure. The board is now sending
characters to the console, which is good but I still have one of the original
problems: I can only step through the code using the BDM debugger, but when I
run the code, it generates a software emulation exception and stops.
After some investigation, it seems that I can run the code up to the point
where the instructure cache is enabled - actually only a few lines at the top
of the startup code. My question is: are there any restrictions on when the
cache can be enabled? Are there anything else I've missed.
Thanks,
Daniel
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Richard Hendricks <hidden> Date: 2000-05-23 21:01:21
Are you using a custom UPM table? This can happen when your UPM burst
table is not proper. Since bursts are not used by the core until
caching is disabled, problems usually come from the UPM table.
Daniel Wu wrote:
Hi,
Thanks to all who responsed to my last qeustion. The problem was that the immr
was not setup correctly. Also since it is a custom board (MPC860T based), I had
to rewrite code to fill in the bd_t structure. The board is now sending
characters to the console, which is good but I still have one of the original
problems: I can only step through the code using the BDM debugger, but when I
run the code, it generates a software emulation exception and stops.
After some investigation, it seems that I can run the code up to the point
where the instructure cache is enabled - actually only a few lines at the top
of the startup code. My question is: are there any restrictions on when the
cache can be enabled? Are there anything else I've missed.
Thanks,
Daniel
--
MPC823 Applications Engineering Development
Get help from other MPC823 customers on the
comp.sys.powerpc.tech newsgroup!
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Richard Hendricks <hidden> Date: 2000-05-23 22:00:18
Err, I meant bursts are not used by the core until caching is ENABLED.
"Richard Hendricks (ra6353)" wrote:
Are you using a custom UPM table? This can happen when your UPM burst
table is not proper. Since bursts are not used by the core until
caching is disabled, problems usually come from the UPM table.
Daniel Wu wrote:
quoted
Hi,
Thanks to all who responsed to my last qeustion. The problem was that the immr
was not setup correctly. Also since it is a custom board (MPC860T based), I had
to rewrite code to fill in the bd_t structure. The board is now sending
characters to the console, which is good but I still have one of the original
problems: I can only step through the code using the BDM debugger, but when I
run the code, it generates a software emulation exception and stops.
After some investigation, it seems that I can run the code up to the point
where the instructure cache is enabled - actually only a few lines at the top
of the startup code. My question is: are there any restrictions on when the
cache can be enabled? Are there anything else I've missed.
Thanks,
Daniel
--
MPC823 Applications Engineering Development
Get help from other MPC823 customers on the
comp.sys.powerpc.tech newsgroup!
--
MPC823 Applications Engineering Development
Get help from other MPC823 customers on the
comp.sys.powerpc.tech newsgroup!
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/