Hi Etherboot hackers.
I have the problem downloading the OS kernel image to 1MB
(0x00100000), via GRUB / tftpboot (*** not etherboot here ! ***)
Booting the same kernel from the disk works !
So I tried to analyse the etherboot eepro100 stuff to
analyse, if the kernel is overwritten per packets per
accident, as a transfer buffer or similar is on that address.
While code reading of eepro100.c I got a problem in understanding
one detail:
In the probe section of the driver, the RxFD structure is
initialized. Here the field
ACCESS(rxfd)rx_buf_addr = (int) &nic->packet;
is setup with the address of the packet frame POINTER inside
the nic structure.
What does the field rx_buf_addr expect ?
The address to a buffer, or the address to a pointer, indicating
the the buffer ?
The point I cannot understand here is the following.
The setup in the probe functions sets the `rx_buf_addr' to the
packet buffer, defined in `config.c'. This means, that an received
packet is transfered there by the i8255[789] chip. On the
other hand, in the `poll' routine, I found following code:
nic->packetlen = ACCESS(rxfd)count & 0x3fff;
memcpy (nic->packet, ACCESS(rxfd)packet, nic->packetlen);
Here the contents from the packet field of the `rxfd' is copied into
the nic->packet frame. But how does the frame come in `rxfd'-packet
field ?? The hardware has to send the data directly to nic->packet.
Why does this code work on booting Linux, etc.... ?
Please help me to understand that point !
With friendly regards
Christoph Plattner
Ask if my explanations as questions are unclear ...
-----------------------------------------------------------------
private: [EMAIL PROTECTED]
company: [EMAIL PROTECTED]
_______________________________________________
Bug-grub mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-grub
