headers
Alexander A. V'ushkov | 17 Sep 2002 11:07
Picon
Favicon

ofppc port is started on MPC8260 FADS board

Hi, All
Recently I've executed ofppc port on MPC8260 FADS board. Now it starts
in single user mode and executed simple command, such as ls and ps :-).

The details:
Ofppc port is started unchanged. Devices are accepted through Open
Firmware Generic Drivers. Now supported only network device (Ethernet)
on FCC2 and console device on SCC. ATM drivers and virtual disk to be
implemented in future. Root device is mounted on network device.
Open Firmware implementation for this board is written as my diploma
project and now is going to be published. The exact location is become
to be defined more precisely.

The problems:
1. There are problems with NFS access. Every request is sent twice. So
time of access to NFS disk is incredible high. I suppose there is a bug
in my implementation of Open Firmware, but I don't know exactly. Now I'm
seeking for the error.

2. There is a problem with ofnet driver. According to Open Firmware
standard,
network device should return 0 as len of received packet, if
there are no new packets received. (addition requirements for the read
method).

The code from ofnet.c, function ofnet_read()
----------
while(1){
  if ((len =3D OF_read(of->sc_ihandle, buf, sizeof buf)) < 0) {
   if (len =3D=3D -2 || len =3D=3D 0)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alexander A. V'ushkov | 11 Sep 2002 14:47
Picon
Favicon

RE: Ofnet driver patch

> well, the code certainly doesn't make sense as it is.
> however, the firepower box that I used to revive the ofppc port recently
> returns -2 if there's no packet to read.  maybe this is another of those
> FIRMWORKSBUGS things.  at any rate, does the attached patch fix this for you?

Yes, you patch is working fine.
Permalink | Reply | 0 comments |
headers
Alexander A. V'ushkov | 17 Sep 2002 13:28
Picon
Favicon

Ethernet driver bug?

Hi, All!

I'm continuing to start ofppc port of NetBSD on MPC8260.

I'm deal with erratic NFS behavior, and as I suppose, there is a bug in the implementation of the Ethernet
driver (function ether_input, file /net/if_ether_subr.c) Sometimes software interrupt,
responsible for processing IP-queue of IP-stack (ip_intr() function) is called BEFORE than packet is
really placed into IP-queue ("ipintrq" variable). As a result, the packet will be processed only when the
next packet arrives.

I suppose that such behavior is tied with the specificity of the call of read function of the "ofnet" driver.
It is called with assistance of callout mechinism. Probably, the current interrupt priority level lets
software interrupt to occur (unlike calling the read function from hardware interrupt).

I've changed the order of actions. At first I've putted packet into IP-queue, and then set interrupt
request. The error has disappeared.

So, I want to know you opinion about the problem.
Permalink | Reply | 0 comments |

Gmane