Downloading Linux image using Riscwatch
Hi I have ported rom monitor code[Openbios from IBM] for my custom board[PPC440GP Processor]. The custom board doesn't support ethernet. Now I want to download a linux image to the RAM of my custom board. What linux image I have to build to download to RAM using JTAG of Riscwatch Debugger . Thanking you in advance Regards Aman - Original Message - From: Wolfgang Denk [EMAIL PROTECTED] To: Aman aman at mistralsoftware.com Cc: linuxppc embedded linuxppc-embedded at lists.linuxppc.org Sent: Wednesday, October 02, 2002 12:10 AM Subject: Re: Downloading Linux image using Riscwatch In message 001b01c26976$233e0640$370da8c0 at aman you wrote: I am using PPC 440GP processor on custom board. This board doesnt not have Ethernet support and there is no rom monitor code in the board. Is it possible to download the Linux image to the board using JTAG . If so what type of image should I build. You can download the kernel, but it will not run ;-) The Linux kernel relies on a lot of initialization to be done by the firmware - things like initializing and sizing the memory, passing boot arguments etc. I suggest you start porting PPCBoot. 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 first 90% of a project takes 90% of the time, the last 10% takes the other 90% of the time. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
very minor 405GP and 405GPr PCI difference
On Tue, Oct 22, 2002 at 02:55:47PM -0700, Todd Poynor wrote: David Gibson wrote (regarding Rainier PMM1 bios_fixup in MVL): Well, it may be in a different place, but it looks like it has the same problem. It is still establishing a PCI window at PLB address 0x8000, which is the same address used for the PMM0 window - or is that also different in the MV kernel? I'd be trying to work out what that mapping's actually for, first. I still can't see how it can possibly work - if there are overlapping PMM windows, what actually happens to accesses in that (PLB) range? Yes, it looks like MVL only sets up the one window using PMM1... we've started an effort to have the Rainier-knowedgeable folks get the code sync'ed up with the community and this should happen soon. Hang on, so just to clarify - MVL sets up PMM1 with the code you posted, but doesn't set up PMM0 anywhere? From my reading of that code, it sets up a window at the same address as the standard (Walnut) mapping, except that it is only 128kB instead of 1GB. Is there a reason that Rainier must have such a small window? -- David Gibson| For every complex problem there is a david at gibson.dropbear.id.au | solution which is simple, neat and | wrong. http://www.ozlabs.org/people/dgibson ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Involking SysRq functions
At 01:47 PM 10/22/2002, you wrote: How do you access the SysRq functions, such as kernel backtrace, when running the serial port with a terminal emulator? (minicom) Well, RTFM. Documentation/sysrq.txt: On the serial console (PC style standard serial ports only) - You send a BREAK, then within 5 seconds a command key. Sending BREAK twice is interpreted as a normal BREAK. How to send BREAK from minicom? # man minicom /BREAK you'll find: Ctrl-A F Enjoy. Eugene Surovegin mailto:ebs at innocent.com ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Monta Vista Linux Supporting Floating Point operations
Hi All, I am working on 440GP using Monta Vista Linux 2.1. I need floating point operation support (for eg. function sqrt() for calculating square root of given float variable) on Linux. I didn't find math emualtion on the Linux. Can anyone tell me how can I get floating point support ? Thanks in advance. Regards, Vishwanath ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Monta Vista Linux Supporting Floating Point operations
At 12:37 AM 10/23/2002, you wrote:
I am working on 440GP using Monta Vista Linux 2.1. I need floating point
operation support (for eg. function sqrt() for calculating square root of
given float variable) on Linux. I didn't find math emualtion on the Linux.
This is strange.
Floating point emulation IS available in MVL2.1 on 440.
You probably forgot to link with libm.
I just typed trivial test and ran it on our custom 440 board:
main.cpp:
--
#include stdio.h
#include math.h
int main(int argc, char* argv[]){
printf(sqrt(10) = %f\n, sqrt(10.0));
return 0;
}
--
Compile and run:
# gcc test.cpp -lm
# ./a.out
sqrt(10) = 3.162278
#
Regards,
Eugene Surovegin mailto:ebs at innocent.com
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] arch/ppc/8xx_io/enet.c
On Monday 21 October 2002 15:13, Joakim Tjernlund wrote: Hi Here is a patch to drop the expensive memcpy of received ethernet frames in interrupt context. I have not done any bench marking, but mounting a NFS rootfs feels faster. I am using a heavily modified enet.c in my system, but I think I got the patch correct. Also fixed a bug in set_multicast_list(), move the dmi list forward when walking it(dmi = dmi-next;) Comments? Anyone care to do some benchmarking? No comments so far, no one interested in this? A question, why do enet.c pass bad frames to netif_rx? Only late collisions are disregarded, the rest is passed on. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
8260 CPM commands, need better resource ctrl?
Dan, different contexts in which drivers send these commands. It doesn't make sense for a driver to continue without waiting for the command to complete, so there isn't any need to wait for this prior to sending a command. I think that a driver should not wait forever for a CPM command to complete, as this could possibly halt the entire kernel. Granted, if this happens then the state of the system is flaky at best, but it might still be possible to function, maybe even enough to debug the real problem. Since the CPM is a shared resource between different drivers, I don't think it is such a bad idea to have some software help in sharing it, as opposed to just hoping everyone behaves properly. Actually, on a complicated CPU such as the 8260, there are many common resources that are shared that might be better protected in software, e.g. io port pins, internal dpram, baud rate generators, timers, mutually exclusive features, etc. Along the same lines, what is the current vision of future linux support for the 8260? Pete ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
very minor 405GP and 405GPr PCI difference
The MontVista Linux disables disable PMM1, which is correct. It then writes a 0 PMM0 enable bit, which on the 405gp is OK because the enable bit is hardwired to a 1. ON the 405gpr, the bit is writeable and this then disables PMM0. The correct action is to write a 1 to the PMM0 enable bit on both the 405 and the 405gpr and the problem is solved. Chip David Gibson david at gibson.dropbear.id.au@lists.linuxppc.org on 10/23/2002 12:08:50 AM Sent by:owner-linuxppc-embedded at lists.linuxppc.org To:Todd Poynor tpoynor at mvista.com cc:linuxppc-embedded at lists.linuxppc.org Subject:Re: very minor 405GP and 405GPr PCI difference On Tue, Oct 22, 2002 at 02:55:47PM -0700, Todd Poynor wrote: David Gibson wrote (regarding Rainier PMM1 bios_fixup in MVL): Well, it may be in a different place, but it looks like it has the same problem. It is still establishing a PCI window at PLB address 0x8000, which is the same address used for the PMM0 window - or is that also different in the MV kernel? I'd be trying to work out what that mapping's actually for, first. I still can't see how it can possibly work - if there are overlapping PMM windows, what actually happens to accesses in that (PLB) range? Yes, it looks like MVL only sets up the one window using PMM1... we've started an effort to have the Rainier-knowedgeable folks get the code sync'ed up with the community and this should happen soon. Hang on, so just to clarify - MVL sets up PMM1 with the code you posted, but doesn't set up PMM0 anywhere? From my reading of that code, it sets up a window at the same address as the standard (Walnut) mapping, except that it is only 128kB instead of 1GB. Is there a reason that Rainier must have such a small window? -- David Gibson | For every complex problem there is a david at gibson.dropbear.id.au | solution which is simple, neat and | wrong. http://www.ozlabs.org/people/dgibson ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
8xx enet collision counter
Collisions in 8xx scc ethernet are not reported
correctly IMHO.
From enet.c :
/* Deferred means some collisions occurred during transmit,
* but we eventually sent the packet OK.
*/
if (bdp-cbd_sc BD_ENET_TX_DEF)
cep-stats.collisions++;
From Table 28-8 in 860 UM:
--
6 DEF Defer indication. The frame was deferred before being sent
successfully,
that is, the transmitter had to wait for carrier sense before sending
because the line was busy.
This is not a collision indication; collisions are indicated in RC.
--
10-13 RC Retry count. Indicates the number of retries required before
the frame was sent successfully. If RC = 0, the frame was sent correctly
the first time. If RC = 15 and RET_LIM = 15 in the parameter RAM, 15
retries were required. Because the counter saturates at 15, if RC = 15
and RET_LIM 15, then 15 or more retries were required. The controller
writes this field after it successfully sends the buffer.
--
The correct way to do it would be to use the RC value,
something like this:
/* Check retry counter, i.e. collision counter */
if (bdp-cbd_sc BD_ENET_TX_RCMASK){
/* Note that counter cannot go higher than 15 */
cep-stats.collisions+=(bdp-cbd_sc BD_ENET_TX_RCMASK)2;
}
I have tried this and it looks much better. That is, when
tranceiver led signals collision, the collision counter actually
moves ;-)
/Thomas
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Monta Vista Linux Supporting Floating Point operations
Vishwanath wrote: Hi All, I am working on 440GP using Monta Vista Linux 2.1. I need floating point operation support (for eg. function sqrt() for calculating square root of given float variable) on Linux. I didn't find math emualtion on the Linux. Can anyone tell me how can I get floating point support ? Floating point support in MontaVista Linux is handled by the compiler and _NOT_ the kernel. In architecting our system we have weighed the tradeoffs between soft-floating point, or hard-floating point using kernel exceptions. Soft-floating point was found to be superior so we use it on all platforms without a hardware FPU. One thing to note, because of this the ABI is slightly different then the binaries you would download off of a random community website. You need to use our compiler (or a community compiler configured appropriatly) to build soft-float. (On a non-MontaVista compiler, you usually need to pass -msoft-float on the command line to gcc.) --Mark ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Illegal instructions in swapper during nfs mount
An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20021023/1bd65808/attachment.txt
[PATCH] arch/ppc/8xx_io/enet.c
On Wednesday 23 October 2002 05:51, Joakim Tjernlund wrote:
On Monday 21 October 2002 15:13, Joakim Tjernlund wrote:
Hi
Here is a patch to drop the expensive memcpy of received ethernet frames
in interrupt context. I have not done any bench marking, but mounting a
NFS rootfs feels faster.
I am using a heavily modified enet.c in my system, but I think I got the
patch correct.
Also fixed a bug in set_multicast_list(), move the dmi list forward when
walking it(dmi = dmi-next;)
Comments? Anyone care to do some benchmarking?
No comments so far, no one interested in this?
I'm interested! Indeed, I adapted and tested your patch in a 8260 FCC fast
ethernet driver and it worked fine I had a 20% increase in routing
throughput with the patch installed!
The bug fix in set_multicast_list worked too. But, since there's a continue
clause inside the for command in this routine, I would suggest that the
(dmi=dmi-next) command go inside the for increment clause, instead of the
place you've put it; that is:
for (...;...; i++, dmi = dmi-next) {...}
A question, why do enet.c pass bad frames to netif_rx? Only late collisions
are disregarded, the rest is passed on.
IMHO, this is another bug...
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] arch/ppc/8xx_io/enet.c
On Wednesday 23 October 2002 13:32, Ricardo Scop wrote: On Wednesday 23 October 2002 05:51, Joakim Tjernlund wrote: [snip] No comments so far, no one interested in this? I'm interested! Indeed, I adapted and tested your patch in a 8260 FCC fast ethernet driver and it worked fine I had a 20% increase in routing throughput with the patch installed! I forgot to mention the bad news. The increase mentioned above was obtained with large packets (1500 bytes) traversing our board. With very small packets (64 bytes), we experimented a 10% DEcrease in PPS (packets per second). We're still testing, but I guess the overall performance will be better with the patch installed. -Scop ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
MPC8260 serial on SCC support
Dejan Jovanovic wrote Now that I boot I get the following output. After the 'starting xinetd' is completed sucessfuly, my serial output is stuck. However I can telnet to my board. This means that there is some problem with the serial? (maybe 'getc' or something like this). I suspect you have not enabled a getty on your serial port (see /etc/inittab). Without that you will not see a login prompt there. -Hollis ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
MPC8260 serial on SCC support
In message 006c01c27aac$fda185e0$db0a at dejanj you wrote: Is there support for serial console on SCC for MPC8260 in latest kernel distributions included in the ELDK or kernel version on the ftp://ftp.denx.de? Yes, of course. See arch/ppc/8260_io/uart.c Serial is configured once I configured CONFIG_CPU86. Keep in mind that this is a board-specific configuration which is intended for the MicroSys CPU86 board only. If it actually works on your hardware you are really, really lucky. After the 'starting xinetd' is completed sucessfuly, my serial output is stuck. However I can telnet to my board. This means that there is some problem with the serial? (maybe 'getc' or something like this). Usually it just means that your console is not where you configured it. For example, on the CPU86 board you include this code: ... #elif defined(CONFIG_CPU86) #define CONFIG_SERIAL_CONSOLE_PORT 2 #else ... which maps to SCC2. Do you really have your console port on SCC2? I think it is generally a BAD idea to copy some board-specific code without checking CAREFULLY what you're doing. You tried, and you got what you deserved: a non-working system ;-) 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 Weekends were made for programming. - Karl Lehenbauer ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
