Re: Re: [Etherboot-users] Sporadic eepro(10) RX problems after reboot

Timothy Legge wrote:

>> Hmm - etherboot 5.3.x didn't work on my board, 5.0.10 back from the 
>> simple days did
>> (something during the early relocation failed - I didn't really have 
>> the time to debug it.
>
>
> That is interesting to know.  I fixed relocation in a lot of the 
> drivers, but I never had a eepro to try.  This is the first report we 
> have had (to my knowledge) about this driver.

It's not a card/driver issue. The thing froze before entering 'main'. If 
I remember right,
the very first move out of EPROM suceeds but then it goes into the woods 
on the way
of relocating itself.

My system is an older embedded board with no disk. So every change in 
code involved
walking to the EPROM burner which is located 15min away, i.e., the 
turnaround time for
every change is ~45min. I was glad 4.0.10 worked out of the box (apart 
from the driver bug).

Ultimately, the goal was porting the RTEMS (open-source real-time OS) 
which involved
porting a eepro driver also. RTEMS ran out of the box, porting the 
driver took me 2-3
days, getting etherboot to work took almost as long...

Now, everything is up + running. :-)

>
>> BTW: one change I noted was the introduction of 'virt_to_bus' and 
>> 'bus_to_virt'
>>           conversions which don't really seem to make sense. The 
>> memory that
>>           is addresses by the pointers in question doesn't live in 
>> the CPU's address space
>>           or on a bus accessible to the CPU but exists only 'inside' 
>> the eepro controller
>>           and is accessed by the CPU by setting a 'address register' 
>> on the eepro and
>>           subsequently reading/writing from/to a 'data port register'.
>>           I don't think the conversions do any harm since they should 
>> cancel but
>>           conceptually it seems wrong.
>
>
> Did you try removing them?  

No. Since the 5.3 version I was testing didn't even come up that didn't 
make sense.
I don't think it's a card issue. Rather something that is 
bios/motherboard dependent.

> Some of the older cards just worked when relocation was introduced 
> without changes.  I don't think anyone would have made changes without 
> testing the driver but I am not sure.
>
> BTW, if you have an extra card that you would like to send me I can 
> try to fix the issue in 5.4. 

The chip is soldered into the board. If you're really interested I can 
maybe (would have to ask)
arrange sending you an entire board - you'd need a multibus crate + a 
set of breakout
cables (I believe we have only one set of these we need ourselves), however.

Thanks anyways.

BTW: I added something that I found missing from etherboot [maybe later 
verions feature it?]:
           The option for manually providing IP configuration + boot 
file info.

--Till

>
>
> TIm
> Tim






-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click