does bus snooping, you might not need uncached
memory references or explicit flushes to read DMA data. But embedded and
non-SMP systems are unlikely to do it.
Tom Roberts tjroberts at lucent.com
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Adrian Cox wrote:
> Tom Roberts wrote:
> > 1) Does Linux/PPC handle the PCI bus properly?
> Short answer, yes. Long answer, how strange a PCI system do you want to
> build?
Nothing obscure, I hope. We need a local PCI bus to interface to
two ethernet MACs, some HDLC interfaces
DRAM to be "embedded", we certainly do. But it is a
BIG step up from an 860]
Any comments or suggestions you have will be appreciated.
Tom Roberts tjroberts at lucent.com
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
via
register_console(). The serial I/O device needs to appear in the filesystem
for the kernel to open it for init, so should be a standard char device.
> In which file I can find it ?
kernel/printk.c
Tom Roberts tjroberts at lucent.com
** Sent via the linuxppc-embedded mail list. Se
e has to be aware of
the hardware platform's details (:-().
I have only 1 board with 7400s, and we are modifying it to
try and evaluate SMP architecture
Tom Roberts tjroberts at lucent.com
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
on for a process which takes the "FP not avail" trap. The
optimization occurs in context switches where the FP registers are
not saved or restored for processes with this bit off.
This is, of course, for CPUs which have FP units IIRC the CPUs
without FP units have the bit hardwired
ivate directory and symlink it
back where it belongs; ditto for the half-dozen other files I had
to change.
Tom Roberts tjroberts at lucent.com
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
this strictly for the pmac or some specific BootROM?
I have never figured it out, and don't use it.
Note that everything I have learned about this came from reading the
code and playing with it to make it work on our boards. It is possible
that I have some details wrong, and likely that my
I had it working reasonably
well. As you can tell, my method relied heavily on my experience
in writing and implementing our proprietary OS, and on my knowledge
and abilities as a low-level PowerPC assembly programmer. YMMV.
Tom Roberts tjroberts at lucent.com
** Sent via the linuxppc-embedde
erything_
is actually a good design decision, IMHO, because it avoids users
having to configure it, picking and choosing among thousands of
library functions.
Tom Roberts tjroberts at lucent.com
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
of course share all logins.
This board is a 200 MHz 750 with 64 MBytes SDRAM, so it is just a bit
bigger than most embedded systems. Now to get the other two CPUs
running
Tom Roberts tjroberts at lucent.com
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
ficulty using Linux. At a guess, assuming your system does
have valid RAM there, this machine check is probably unrelated to the
link and/or load address of Linux; it is probably attempting to
reference some non-existant I/O device.
Tom Roberts tjroberts at lucent.com
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
em-level code for your board does not already use
these BATs (write a module to dump the BATs, or inspect
the Linux startup code VERY carefully). This may be what
you are looking for.
Tom Roberts tjroberts at lucnet.com
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
re essentially embedded supercomputers;
the only devices they have are the drivers I wrote, which
use memory buffers to/from the host PCI as a 'serial'
console and a network interface.
Tom Roberts tjroberts at lucent.com
** Sent via the linuxppc-embe
our existing boards would be a big plus, even though it will
not be the same as the new boards. There is also the obvious
attraction of a standard, POSIX-compliant OS
Tom Roberts tjroberts at lucent.com
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Tom Roberts wrote:
> I am trying to write a network driver [...]
> In particular, I am trying to use non-ethernet headers, and cannot
> get the kernel to deliver a ping packet (ICMP protocol) back to the
> ping program even though the driver delivers the packets OK. BUT --
> essen
do indeed transfer the data unchanged, and I think
I set all the required skb fields above WHAT AM I MISSING???
Tom Roberts tjroberts at lucent.com
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
ng).
You do need to ensure you are not mapping the same _virtual_ address
(i.e. the effective address, in the language of Motorola's manuals),
but the kernel routines will probably take care of that for you....
Tom Roberts tjroberts at lucent.com
** Sent via the linuxppc-embedded ma
erious errors, like incompatible libraries
Tom Roberts tjroberts at lucent.com
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
not an issue -- it takes just 3.1 seconds from the
of my boot command to a bash prompt from the board).
HEY -- IS THAT A RECORD??? has anyone ever booted Linux faster
than 3.1 seconds? Of course this is a _VERY_ bare-bones system
with just a console and a 4 MB initrd-ram
g a sufficient initrd image to actually use
the network driver I have written (:-(). So far, I cannot even ping
myself using the loopback device (no inetd, I suppose).
Tom Roberts tjroberts at lucent.com
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
cated to one-way traffic, so no locking is needed.
I still need the uncached address to reference the queue pointers,
but that is done using simple pointer dereferencing and is OK.
Tom Roberts tjroberts at lucent.com
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
22 matches
Mail list logo
