Question about linker -Ttext option
In the arch/ppc/boot directory, one of the linker options is -Ttext 0x0080. What does this mean ? The base virtual address of the kernel is c000. I've been using my own hand-rolled bootloader to load the zImage.bin file into an address allocated by the VxWorks malloc and jumping to that address. Second question. arch/ppc/boot/simple/head.S says it expects the load address in r3. It seems strange that it would need its own (start) starting address. What is this routine expecting ? Regards, Bob Beck ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[Fwd: Question about linker -Ttext option]
FYI - I'm using version 2.4.18 of the linux kernel with the ppc patches. Bob -Forwarded Message- From: Bob Beck [EMAIL PROTECTED] To: linuxppc-embedded at lists.linuxppc.org Subject: Question about linker -Ttext option Date: 09 Mar 2004 14:10:26 +1400 In the arch/ppc/boot directory, one of the linker options is -Ttext 0x0080. What does this mean ? The base virtual address of the kernel is c000. I've been using my own hand-rolled bootloader to load the zImage.bin file into an address allocated by the VxWorks malloc and jumping to that address. Second question. arch/ppc/boot/simple/head.S says it expects the load address in r3. It seems strange that it would need its own (start) starting address. What is this routine expecting ? Regards, Bob Beck ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Compiling glibc-2.3.2 (debian) on mpc8xx ;-)
Hi all, I proudly announce that we finally have the first two prototypes of our boards based on the MPC852T running. Until now it looks like one of those lucky one-time-right designs, since it went flawless until now. We have 64 MByte SDRAM on-board, an ethernet Phy (FEC), 4 Mbyte Flash, etc... Since I'm quite crazy, and love running big-stuff on small-things I decided to install Debian-unstable (sid) on an nfs-mounted root. So far, so good. I compiled a kernel with FPU-emulation just in case, and went through the installation of the base system using glibc-2.3.1 from ELDK binaries plugged on top of the version from debian, to avoid further incompatibilities. Now, after apt-getting a hell of a lot of fancy software (all running quite fine until now - except floating-point-libc stuff), the time has come to recompile GlibC. on the target! Question: What do I have to patch exactly before compiling? I want to leave floating-point stuff in there for now to stay compatible with debian-binaries. AFAIK there is (was?) an issue with sysdeps/powerpc/powerpc32/memset.S and sysdeps/powerpc/powerpc32/dl-machine.c containing code that assumed a cache-line of different size than that of the MPC8xx. Is this still the case in glibc-2.3.2? Hasn't this been patched in the official sources? What else do I have to look out for? What other patches to apply? Where to get them from? Greetings, -- David Jander Protonic Holland. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
searchplugin (off topic)
Hi, For anybody interested, I've attached a mozilla/firefox/etc. searchplugin for this mailing list. Just put in your browser install/searchplugins directory and restart. Jaap-Jan -- J.G.J. Boor Anton Philipsweg 1 Software Engineer 1223 KZ Hilversum AimSys bv tel. +31 35 689 1941 Postbus 2194, 1200 CD Hilversum mailto:jjboor at aimsys.nl -- next part -- # linuxppc-embedded Sherlock for Mozilla # # jjboor at aimsys dot nl March 2004 # search name=linuxppc-embedded description=LinuxPPC - Mail List Archives action=http://lists.linuxppc.org/results.html; searchForm=http://lists.linuxppc.org/results.html; method=GET input name=restrict value=linuxppc-embedded input name=words user interpret resultListStart=!-- RESULT LIST START -- resultListEnd=!-- RESULT LIST END -- resultItemStart=!-- RESULT ITEM START -- resultItemEnd=!-- RESULT ITEM END -- /search
Compiling glibc-2.3.2 (debian) on mpc8xx ;-)
In message 200403090953.54598.david.jander at protonic.nl you wrote: So far, so good. I compiled a kernel with FPU-emulation just in case, and went through the installation of the base system using glibc-2.3.1 from ELDK binaries plugged on top of the version from debian, to avoid further incompatibilities. You have just created a bunch of incompatibilities here. You cannot use binaries and shared libraries that don't fit to each other. Question: What do I have to patch exactly before compiling? I want to leave floating-point stuff in there for now to stay compatible with What do you mean by leave floating-point stuff in? Since the MPC8xx does not have a FPU, you cannot use hardware floating point. Oh yes, there is the FP emulation in the kernel. But this has never been working reliably. debian-binaries. AFAIK there is (was?) an issue with sysdeps/powerpc/powerpc32/memset.S and sysdeps/powerpc/powerpc32/dl-machine.c containing code that assumed a cache-line of different size than that of the MPC8xx. Is this still the case in glibc-2.3.2? Hasn't this been patched in the official sources? What else do I have to look out for? What other patches to apply? Where to get them from? See the patches in the ELDK build environment. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de The greatest threat towards future is indifference. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
uncached user space mapping with mmap() ???
Fillod Stephane wrote: The bigger the mmap, the better, and the lesser entries in page table there will be. That's not true though. I went along with the rest of your mail, but the above just does not make sense to me. Are you somehow assuming you can have variable page sizes or will necessarily be using BATs to map in large regions? If this is the case then do bear in mind the fixed 4K page size on most platforms and the fact that many architectures like 4xx do not have any BATs anyway. Cheers, Jon. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
IBM OCP IDE fixes
Hi,
it seems that there's a bug in drivers/ide/ppc/ibm_ocp_ide.c, in
ocp_ide_build_dmatable in the current (linuxppc) 2.6.
Explanation: pvprv gets initialized to NULL, and for each bio segment
BIOVEC_PHYS_MERGEABLE will be called to see if it can be merged with the
previous one. In the first iteration, this will fail, giving a
null-pointer to BIOVEC_PHYS_MERGEABLE, which doesn't check for this
condition, leading to an Oops.
As the first segment can never be merged with something else, checking
for a null pvprv should be enough.
Speaking of the ibm_ocp_ide.c, it should be inserted into the Makefile
in drivers/ide (ide-core-$(CONFIG_BLK_DEV_IDE_STB04xxx) +=
ppc/ibm_ocp_ide.o), and the std_ide_cntl must be called. Not sure if my
patch is the correct way here.
Additionally, the ocp driver issues IDE commands on his own in dma mode,
which is wrong for 48bit addressing. I made simple workaround, but a
more generic function might be called instead.
Then there are some simple compile fixes (missing headerfile, which
isn't of any use anyway and replacement of hw_init_dma_channel against
ppc4xx_init_dma_channel). ide_dma_off seems to be not required anymore.
Finally, the udelay(1000*1000) have to be replaced by mdelay(1000) in
the spinup wait. Maybe this loop should be replaced by the more generic
IDE spinup loop.
Comments?
Felix
diff -Naur linuxppc-2.5-vanilla/drivers/ide/Makefile
linux-2.6/drivers/ide/Makefile
--- linuxppc-2.5-vanilla/drivers/ide/Makefile2004-03-02
22:17:17.0 +0100
+++ linux-2.6/drivers/ide/Makefile2004-03-04 18:33:12.0 +0100
@@ -37,6 +37,7 @@
ide-core-$(CONFIG_BLK_DEV_MPC8xx_IDE)+= ppc/mpc8xx.o
ide-core-$(CONFIG_BLK_DEV_IDE_PMAC)+= ppc/pmac.o
ide-core-$(CONFIG_BLK_DEV_IDE_SWARM)+= ppc/swarm.o
+ide-core-$(CONFIG_BLK_DEV_IDE_STB04xxx) += ppc/ibm_ocp_ide.o
obj-$(CONFIG_BLK_DEV_IDE)+= ide-core.o
obj-$(CONFIG_IDE_GENERIC)+= ide-generic.o
diff -Naur linuxppc-2.5-vanilla/drivers/ide/ide.c
linux-2.6/drivers/ide/ide.c
--- linuxppc-2.5-vanilla/drivers/ide/ide.c2004-03-02
22:16:11.0 +0100
+++ linux-2.6/drivers/ide/ide.c2004-03-04 18:33:12.0 +0100
@@ -2156,7 +2156,7 @@
pnpide_init(1);
}
#endif /* CONFIG_BLK_DEV_IDEPNP */
-#ifdef CONFIG_BLK_DEV_STD
+#if defined(CONFIG_BLK_DEV_STD) || defined(CONFIG_BLK_DEV_IDE_STB04xxx)
{
extern void std_ide_cntl_scan(void);
std_ide_cntl_scan();
--- linuxppc-2.5-vanilla/drivers/ide/ppc/ibm_ocp_ide.c2004-03-02
22:16:52.0 +0100
+++ linux-2.6/drivers/ide/ppc/ibm_ocp_ide.c2004-03-04
19:04:29.0 +0100
@@ -23,7 +23,7 @@
#include asm/scatterlist.h
#include asm/ppc4xx_dma.h
-#include ide_modes.h
+// #include ide_modes.h
#define IDE_VER2.0
ppc_dma_ch_t dma_ch;
@@ -383,8 +383,8 @@
else
consistent_sync((void *)vaddr,
size, PCI_DMA_FROMDEVICE);
-if (!BIOVEC_PHYS_MERGEABLE(bvprv, bvec)) {
+if (bvprv !BIOVEC_PHYS_MERGEABLE(bvprv, bvec)) {
if (ocp_ide_build_prd_entry(table,
prd_paddr,
prd_size,
@@ -581,12 +580,18 @@
{
if (!ocp_ide_build_dmatable(drive, writing))
return 1;
+
+int lba48bit;
drive-waiting_for_dma = 1;
if (drive-media != ide_disk)
return 0;
+
+lba48bit = ((drive-id-cfs_enable_2 0x0400) ? 1 : 0)
(drive-addressing);
+
ide_set_handler(drive, ocp_ide_dma_intr, WAIT_CMD, NULL);
-HWIF(drive)-OUTB(writing ? WIN_WRITEDMA : WIN_READDMA,
+HWIF(drive)-OUTB(writing ? (lba48bit ? WIN_WRITEDMA_EXT :
WIN_WRITEDMA)
+: (lba48bit ? WIN_READDMA_EXT : WIN_READDMA),
IDE_COMMAND_REG);
return __ocp_ide_dma_begin(drive, writing);
}
@@ -642,7 +647,7 @@
if ((stat 0x80) == 0) {
break;
}
-udelay(1000 * 1000);/* 1 second */
+mdelay(1000);/* 1 second */
}
printk(.);
@@ -657,7 +662,7 @@
if ((stat 0x80) == 0) {
break;
}
-udelay(1000 * 1000);/* 1 second */
+mdelay(1000);/* 1 second */
}
if( i 30){
outb_p(0xa0, io_ports[6]);
@@ -715,7 +720,7 @@
dma_ch.ch_enable = 0;/* No chaining */
dma_ch.tcd_disable = 1;/* No chaining */
-if (hw_init_dma_channel(IDE_DMACH, dma_ch) != DMA_STATUS_GOOD)
+if (ppc4xx_init_dma_channel(IDE_DMACH, dma_ch) != DMA_STATUS_GOOD)
return -EBUSY;
/* init CIC select2 reg to connect external DMA port 3 to internal
@@ -772,8 +777,10 @@
if(!ocp_ide_spinup(hwif-index))
return 0;
-
-return 1;
+
+ probe_hwif_init(hwif);
+
+return 1;
}
@@ -821,7 +829,6 @@
ide_hwifs[index].tuneproc = ocp_ide_tune_drive;
ide_hwifs[index].drives[0].autotune = 1;
ide_hwifs[index].autodma = 1;
-ide_hwifs[index].ide_dma_off = ocp_ide_dma_off;
Compiling glibc-2.3.2 (debian) on mpc8xx ;-)
In message 200403091240.40660.david.jander at protonic.nl you wrote: You have just created a bunch of incompatibilities here. You cannot use binaries and shared libraries that don't fit to each other. I know. Strange thing is: it kinda works fine... until you hit code with calles to FP-related functions in the library. For example the following does No. it does not work at all fine. It just does not crash immediately, and some errors my be subtle and go through unnoticed. The math works fine, but printf screws up. You re just lucky and working on a slightly loaded system if this appears to be fine. Another observation: while ps aux shows correct percentage numbers (FP I assume), top shows only nan values for CPU and memory. Any explanation to why ps works fine? I haven't looked at the sources yet. I don't care. What you see is undefined behaviour, and you know that. floating point. Oh yes, there is the FP emulation in the kernel. But this has never been working reliably. Wow! That sounds strong! How comes that? What are we waiting to get it working better? I assume the emulation on this processor works similar to the 386 through exception handling, am I right? You are right. Simply: it does not make sense to spend effort in fixing the remainingproblems since this is so awafully slow and using -msoft-float on bianries and libraries is a mauch better way to deal with the FP problem. Can I leave the patches involving FP-stuff out and rely on emulation? I guess IMHO you cannot rely on the emulation at all. It never wroked reliably in our tests. not for what you said earlier, but if the emulation worked well enough, whouldn't that be enough? Of course it will be slow as hell, but speed is not as important as actually running the code. If running the code includes a certain level of reliability I would not try to do that. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de Winners never talk about glorious victories. That's because they're the ones who see what the battlefield looks like afterwards. It's only the losers who have glorious victories. - Terry Pratchett, _Small Gods_ ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
uncached user space mapping with mmap() ???
Jon Masters wrote: The bigger the mmap, the better, and the lesser entries in page table there will be. That's not true though. I went along with the rest of your mail, but the above just does not make sense to me. Indeed! I should have written: The bigger the mmap, the better, and the lesser vma entries there will be. The idea is: mmap(N*pagesize()) is better than N times mmap(pagesize()), provided you do need to address all this space. Are you somehow assuming you can have variable page sizes or will necessarily be using BATs to map in large regions? If this is the case then do bear in mind the fixed 4K page size on most platforms and the fact that many architectures like 4xx do not have any BATs anyway. You're right. To have less entries in the page table, we would need variable page sizes, since 4xx does not have BAT. Hence my remark in form of question about ability of hugetlb. The answer must be in the archive. Thanks for the correction :-) Regards, Stephane ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Linux 2.4.24 on PQ2FADS
Dear colleagues, I'm trying to have Linux 2.4.24 working on my evaluation board PQ2FADS-VR with ppc8275, but I'm suffering of a lot of instability problems. The Boot-loader I use is Uboot-1.0.0 witch initialise correctly the board at speed 66,133,199 and correctly fills bd_info struct. But when I issue the command = bootm 10 I observe every time a different behaviour: sometimes I don't see anything, sometimes the board stops in Calibrating delay loop, sometimes after having written the line: Memory: 30936k available (984k kernel code, 344k data, 52k init, 0k highmem) Or the line POSIX conformance testing by UNIFIX Only occasionally it reaches the init program (stopping here). The same behaviour I observed with the images delivered by the Arabella distribution! Do you have any suggestion? MMU? Cache? Hardware? Thanks in advance for your advice. With best regards, Stefano ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
AW: Compiling glibc-2.3.2 (debian) on mpc8xx ;-)
On Tuesday 09 March 2004 10:20, you wrote: Dear David, sadly I have got no answer to your question, but I want to ask you something: Are you using U-Boot for starting Linux? If you do, can you give me a short roadmap, how to port to new board? Yes, we are using u-boot. Well, here's a list of suggestions based on what we did: 1.- Read the README of u-boot. 2.- Assuming there are already other boards with the same CPU and at least a more or less similar setup that are supported, pick one of them, and copy the directory boards/ to boards/ (where is the name of your board). 3.- Go to include/configs and make a copy of the .h file. Don't forget to add your board also to the Makefile. 4.- Watch out for special stuff for the board you are using as start, it could get in your way. 5.- Check if the 's config and board support files are indeed a good starting point (clean documented sources, using the newest format of config files and most important, get to fully understand the source). 6.- Look at several other examples to pick up ideas and learn from the sources. 7.- Configure your board with the design information, and from what you learned reading README and the examples. 8.- Leave SDRAM configuration for later (assuming you use a MPC8xx processor, where SDRAM is a special issue), and look if you get something out of your serial port first. 9.- Use Jtag or BDM interfaces to place the bootloader into flash. (We used a homebrewed Jtag interface to program the on-board flash, although everyone and ther brother in this list will probably say that you MUST do it with the BDI2000 from abatron via the BDM port). 10.- Have a Scope at hand to examine the CS and address lines (if at all possible). This may help to see what's going on before the serial port comes into play. 11.- If you have a mpc8xx processor, read the technical notes from Micron about how to interface SDRAM to the MPC8xx, and how to program the UPM correctly. There's a tool from Motorola that let's you draw the waveforms on screen and obtain the corresponding byte-code for the UPM. This might be handy. Again look at and learn from what others did. Good Luck! Best regards, -- David Jander Protonic Holland. tel.: +31 (0) 229 212928 fax.: +31 (0) 229 210930 Factorij 36 / 1628 AL Zwaag ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
MPX8xx: MMC over SPI....
Hi all, I know that Wolfgang Denk is going to flame me right away for this, but I'll do it anyway :-) I am going to write a SPI driver and on top of that a MMC driver for linux for the MPC852T, unless there is something already out there. Anyone tried this before and has some sources to share? Or pointers to sources? Greetings, -- David Jander Protonic Holland. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
MPX8xx: MMC over SPI....
On Tuesday 09 March 2004 14:18, David Jander wrote: Hi all, I know that Wolfgang Denk is going to flame me right away for this, but I'll do it anyway :-) I am going to write a SPI driver and on top of that a MMC driver for linux for the MPC852T, unless there is something already out there. the SPI driver is there. It's in the Denx kernel src Jaap-Jan Anyone tried this before and has some sources to share? Or pointers to sources? Greetings, -- David Jander Protonic Holland. -- J.G.J. Boor Anton Philipsweg 1 Software Engineer 1223 KZ Hilversum AimSys bv tel. +31 35 689 1941 Postbus 2194, 1200 CD Hilversum mailto:jjboor at aimsys.nl ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
searchplugin
Hi, Slightly off topic, but for anybody interested, I've attached a mozilla/firefox/etc. searchplugin for this mailing list. Just untgz it and put it in your browser install/searchplugins directory. Jaap-Jan -- J.G.J. Boor Anton Philipsweg 1 Software Engineer 1223 KZ Hilversum AimSys bv tel. +31 35 689 1941 Postbus 2194, 1200 CD Hilversum mailto:jjboor at aimsys.nl -- next part -- A non-text attachment was scrubbed... Name: linuxppc.tar.gz Type: application/x-tgz Size: 1326 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20040309/b0888c63/attachment.bin
remote access via shell
I have a ppc 5100 that is currently running Linux. I also have downloaded and looked at the ELDK. Neither appear to have a telnet nor a ssh daemon. What daemon for remote access is recommended? Are there small versions especially appropriate for embedded use? Versions that have Make files conducive to cross-compilation for PPC? Thanks, Kevin Dankwardt ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
remote access via shell
You are probably running busybox (or should be). Busybox includes a telnetd telnet daemon. http://www.busybox.net/ gvb -Original Message- From: owner-linuxppc-embedded at lists.linuxppc.org [mailto:owner-linuxppc-embedded at lists.linuxppc.org]On Behalf Of Kevin P. Dankwardt Sent: Tuesday, March 09, 2004 9:21 AM To: linuxppc-embedded at lists.linuxppc.org Subject: remote access via shell I have a ppc 5100 that is currently running Linux. I also have downloaded and looked at the ELDK. Neither appear to have a telnet nor a ssh daemon. What daemon for remote access is recommended? Are there small versions especially appropriate for embedded use? Versions that have Make files conducive to cross-compilation for PPC? Thanks, Kevin Dankwardt ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
remote access via shell
In message KCEOLLHGFJIAFNAMGACHEEPJDFAA.k at kcomputing.com you wrote: I have a ppc 5100 that is currently running Linux. I also have downloaded and looked at the ELDK. Neither appear to have a telnet nor a ssh daemon. You didn't look very carefully. telnetd is included with the ELDK as /usr/sbin/in.telnetd; this is part of the telnet-server-ppc_???-0.17-23_1 RPM. What daemon for remote access is recommended? Are there small versions Secure Shell of course - if you can afford the size. especially appropriate for embedded use? Versions that have Make files conducive to cross-compilation for PPC? ;-) Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de The evolution of the human race will not be accomplished in the ten thousand years of tame animals, but in the million years of wild animals, because man is and will always be a wild animal. - Charles Galton Darwin ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
MPX8xx: MMC over SPI....
Dear David, in message 200403091418.22891.david.jander at protonic.nl you wrote: I know that Wolfgang Denk is going to flame me right away for this, but I'll do it anyway :-) I'm sorry if I caused the impression I would flame people for using SPI. This was definitely not my intention. But I think it is only fair to share some experience, and warn you not to run into well- known problems. I am going to write a SPI driver and on top of that a MMC driver for linux for the MPC852T, unless there is something already out there. Anyone tried this before and has some sources to share? Or pointers to sources? The SPI driver is there, but I don't recommend to use it for any type of data transfers that require any significant bandwidth. Motorola writes: The SPI was not designed to be a high-bandwidth channel. It can run very quickly for bursts of up to 16-bits. But the peripheral has no FIFO and low priority in the MPC860 and thus you cannot burst lots of data quickly through the interface. ... Note that the SPI is of lower priority internally than the SCCs, thus, the SPI will be the first device to be starved. Since it has no FIFO, it is especially sensitive to underruns. The best way to prevent this is to use a buffer size of 1 character (of size programmed in the mode register). ... Also, you should be aware that the SPI protocol is implemented as microcode running on the CPM, so any high-speed data transfers will suck up CPM performance. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de ...and the fully armed nuclear warheads, are, of course, merely a courtesy detail. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
AW: Linux 2.4.24 on PQ2FADS
Thomas,
I had not an entry for Hip7 such that you send me! Thak you very much for
your help.
I'm going to chek my SDRAM initialization because, now, I see corrupted
stamps, like these:
## Booting image at 0010 ...
Image Name: 2.2.4 Kernel for PQ2FADS
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size:571353 Bytes = 558 kB
Load Address:
Entry Point:
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Memory BAT mapping: BAT2=32Mb, BAT3=0Mb, residual: 0Mb
?Linux version 2.4.24
(gai
otto at gexs22) (gcc version 3.3.2) #5 Tue Mar 9 17:00:09 CET 2004
?ADS setup
arch
?O
n node 0 totalpages: 8192
?zone(0): 8192 pages.
?zone(1): 0 pages.
?zone(2): 0
page
s.
?Kernel command line: root=/dev/nfs rw
nfsroot=172.16.246.111:/home/gaiotto/fa
dsroot nobats ip=172.16.119.3
????$ ?ADS init IRQ. NR_IR?
Regards,
Stefano
Thomas Sch?fer tschaefer at giga-stream.de on 09/03/2004 14:24:39
Please respond to tschaefer at giga-stream.de
To:Stefano Gaiotto Stefano.Gaiotto at marconi.com
cc:linuxppc-embedded at lists.linuxppc.org
Subject:AW: Linux 2.4.24 on PQ2FADS
Hi Stefano,
just a wild guess:
check the cpu_specs[] array in your arch/ppc/kernel/cputable.c file. It
should
contain something like this entry for your 8275 CPU:
{ /* 82xx (Hip7 603e cores) */
0x, 0x8082, 82xx (Hip7),
CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_CAN_DOZE | CPU_FTR_USE_TB |
CPU_FTR_CAN_NAP,
COMMON_PPC,
32, 32,
__setup_cpu_603
}
The CPU ID (0x8082 in this case) must match your 8275 CPU ID.
Otherwise, generic PPC
will be assumed which leads to strange behaviour as soon as the MMU will be
enabled by
the kernel.
second guess:
Because of the random errors you described I would check the SDRAM settings
of the board:
- check ALL settings of the memory controller against the settings
described in the
data sheet of your SDRAM.
- check memory controller initialization sequence against the sequence
described in the
data sheet of the SDRAM and the memory controller of the CPU
- if both are correct: check signal integrity on your board
hope this helps.
Best regards,
Thomas Schaefer
-Urspr?ngliche Nachricht-
Von: owner-linuxppc-embedded at lists.linuxppc.org
[mailto:owner-linuxppc-embedded at lists.linuxppc.org]Im Auftrag von
Stefano Gaiotto
Gesendet: Dienstag, 9. M?rz 2004 13:53
An: linuxppc-embedded at lists.linuxppc.org
Betreff: Linux 2.4.24 on PQ2FADS
Dear colleagues,
I'm trying to have Linux 2.4.24 working on my evaluation board PQ2FADS-VR
with ppc8275, but I'm suffering of a lot of instability problems.
The Boot-loader I use is Uboot-1.0.0 witch initialise correctly the board
at speed 66,133,199 and correctly fills bd_info struct.
But when I issue the command = bootm 10 I observe every time a
different behaviour: sometimes I don't see anything, sometimes the board
stops in Calibrating delay loop, sometimes after having written
the line:
Memory: 30936k available (984k kernel code, 344k data, 52k init, 0k
highmem)
Or the line
POSIX conformance testing by UNIFIX
Only occasionally it reaches the init program (stopping here).
The same behaviour I observed with the images delivered by the Arabella
distribution!
Do you have any suggestion? MMU? Cache? Hardware?
Thanks in advance for your advice.
With best regards,
Stefano
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
remote access via shell
I'm using sshd (OpenSSH 3.8-p1 i believe) and sftp-server which are 394k and 60k in size. Their makefiles are not well adapted but if you have Building embedded linux systems of O'Reilly, you'll build it without any problem Kind regards, Gerrit Van de Velde Kevin P. Dankwardt wrote: I have a ppc 5100 that is currently running Linux. I also have downloaded and looked at the ELDK. Neither appear to have a telnet nor a ssh daemon. What daemon for remote access is recommended? Are there small versions especially appropriate for embedded use? Versions that have Make files conducive to cross-compilation for PPC? Thanks, Kevin Dankwardt -- Kind regards, ing. Gerrit Van de Velde Onderzoeksgroep Digitale Technieken W K, Campus De Nayer J. De Nayerlaan 5 2860 Sint-Katelijne-Waver Tel. 015 / 31 69 44 Fax. 015 / 31 74 53 http://emsys.denayer.wenk.be ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
AW: AW: Linux 2.4.24 on PQ2FADS
Stefano,
-Urspr?ngliche Nachricht-
Von: Stefano Gaiotto [mailto:Stefano.Gaiotto at marconi.com]
Gesendet: Dienstag, 9. M?rz 2004 17:05
Betreff: Re: AW: Linux 2.4.24 on PQ2FADS
I had not an entry for Hip7 such that you send me! Thak you very much
for your help.
I'm not sure if MPC8275 is actually a HIP7 core. We used a MPC8280 on
our boards. It is important that the CPU ID is correct in the cputable
file. In our case, with the missing CPU ID the board always hang in the
init program.
I'm going to chek my SDRAM initialization because, now, I see
corrupted stamps, like these:
## Booting image at 0010 ...
Image Name: 2.2.4 Kernel for PQ2FADS
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size:571353 Bytes = 558 kB
Load Address:
Entry Point:
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Memory BAT mapping: BAT2=32Mb, BAT3=0Mb, residual: 0Mb
?Linux
version 2.4.24
(gai
otto at gexs22) (gcc version 3.3.2) #5 Tue Mar 9 17:00:09 CET 2004
?ADS setup
arch
?O
n node 0 totalpages: 8192
?zone(0): 8192 pages.
?zone(1): 0 pages.
?zone(2): 0
page
s.
?Kernel command line: root=/dev/nfs rw
nfsroot=172.16.246.111:/home/gaiotto/fa
dsroot nobats ip=172.16.119.3
????$ ?ADS init IRQ. NR_IR?
Maybe that your load address (0x10) is too low and is overwritten
when the kernel is uncompressed
Best regards,
Thomas
Thomas Sch?fer tschaefer at giga-stream.de on 09/03/2004 14:24:39
just a wild guess:
check the cpu_specs[] array in your arch/ppc/kernel/cputable.c file.
It should contain something like this entry for your 8275 CPU:
{ /* 82xx (Hip7 603e cores) */
0x, 0x8082, 82xx (Hip7),
CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_CAN_DOZE | CPU_FTR_USE_TB |
CPU_FTR_CAN_NAP,
COMMON_PPC,
32, 32,
__setup_cpu_603
}
The CPU ID (0x8082 in this case) must match your 8275 CPU ID.
Otherwise, generic PPC will be assumed which leads to strange
behaviour as soon as the MMU will be enabled by the kernel.
second guess:
Because of the random errors you described I would check the SDRAM
settings of the board:
- check ALL settings of the memory controller against the settings
described in the data sheet of your SDRAM.
- check memory controller initialization sequence against the sequence
described in the data sheet of the SDRAM and the memory controller
of the CPU
- if both are correct: check signal integrity on your board
-Urspr?ngliche Nachricht-
Von: Stefano Gaiotto
Gesendet: Dienstag, 9. M?rz 2004 13:53
Betreff: Linux 2.4.24 on PQ2FADS
I'm trying to have Linux 2.4.24 working on my evaluation board
PQ2FADS-VR with ppc8275, but I'm suffering of a lot of instability
problems. The Boot-loader I use is Uboot-1.0.0 witch initialise
correctly the board at speed 66,133,199 and correctly fills bd_info
struct. But when I issue the command = bootm 10 I observe
every time a different behaviour: sometimes I don't see anything,
sometimes the board stops in Calibrating delay loop, sometimes
after having written the line:
Memory: 30936k available (984k kernel code, 344k data, 52k init, 0k
highmem)
Or the line
POSIX conformance testing by UNIFIX
Only occasionally it reaches the init program (stopping here).
The same behaviour I observed with the images delivered by the
Arabella distribution!
Do you have any suggestion? MMU? Cache? Hardware?
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
