Assembly code in RTEMS C program on MVME162 VME CPU Board

[AJAI KUMAR MEDHAVI]

Hi


I am using RTEMS 4.10.2 with Windows Based MinGW. I wish to use following
Asssembly code within my RTEMS C application :


rtems_device_driver ISOADC_write(rtems_device_major_number major,
rtems_device_minor_number minor, void *arg)
{

----
----

asm volatile (" movea.l #$F0850010,%A1 ; "
" add.l #2,%A1 ; "
" move.w #2,(%A1) ; "
);

----

---

}


The program is getting compiled without error, but on linking it is giving
"undefined reference to F085010"


Then I tried following piece of asm code :


asm volatile (" move.l BaseAdd,%A1 ; "
" add.l #2,%A1 ; "
" move.w #2,(%A1) ; "
" BaseAdd: dc.l $F0850010 ";
);

then it is giving error on line " BaseAdd: dc.l $F0850010 ";


Let me know exactly how to use following code in C file :


asm volatile (" move.l BaseAdd,%A1 ; "
" add.l #2,%A1 ; "
" move.w #2,(%A1) ; "
" BaseAdd: dc.l $F0850010 ";
);



OR


asm volatile (" BaseAdd equ $FO850010;"
" movea.l #BaseAdd, %A1;"
" add.l #2,%A1 ; "
" move.w #2,(%A1) ; "
" BaseAdd: dc.l $F0850010 ";
);


Thanks in advance.




AJAI KUMAR MEDHAVI
SCIENTIFIC OFFICER
RAJA RAMMANNA CENTRE FOR ADVANCED TECHNOLGY
DEPARTMENT OF ATOMIC ENERGY, GOV. OF INDIA,
PO : CAT, INDORE-452013, INDIA
PH. 91-731-2488052




--

[Sebastian Huber]

Post by AJAI KUMAR MEDHAVI
I am using RTEMS 4.10.2 with Windows Based MinGW. I wish to use following
rtems_device_driver ISOADC_write(rtems_device_major_number major,
rtems_device_minor_number minor, void *arg)
{
----
----
asm volatile (" movea.l #$F0850010,%A1 ; "
" add.l #2,%A1 ; "
" move.w #2,(%A1) ; "
);

Why do you use inline assembler for this? You can write this in C. The
volatile keyword exists for this purpose.
--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : [phone]
Fax : [phone]
E-Mail : sebastian.huber-L1vi/***@public.gmane.org
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

[Charlie Strohman]

I recently bought 2 new MVME5500 boards from Emerson. They have changed
the chip that supports the 1 Gbit ethernet interface from an Intel
82544EI to an Intel 82545GM. As a consequence, the 1 Gbit interface no
longer works, and the BSP issues the message:

"i82544EI device ID not found"

Has anyone seen and fixed this? Might it be as simple as accepting the
PCI Device ID of the new chip? I'm using RTEMS 4.10.2. I looked at the
newest version and it seems to be the same code. I have not yet probed
into the hardware to see what ID value is being returned.

The ID of the older 82544EI is 0x1008 (from
"cpukit/include/rtems/pci.h), which according to the 410 page Software
Developer's Manual is the default value if the EEPROM is not programmed.

Thanks,

Charlie Strohman
231 Wilson Lab
Cornell University
Ithaca, NY 14853
607-255-0687

[Joel Sherrill]

Post by Charlie Strohman
I recently bought 2 new MVME5500 boards from Emerson. They have changed
the chip that supports the 1 Gbit ethernet interface from an Intel
82544EI to an Intel 82545GM. As a consequence, the 1 Gbit interface no
"i82544EI device ID not found"
Has anyone seen and fixed this? Might it be as simple as accepting the
PCI Device ID of the new chip? I'm using RTEMS 4.10.2. I looked at the
newest version and it seems to be the same code. I have not yet probed
into the hardware to see what ID value is being returned.
The ID of the older 82544EI is 0x1008 (from
"cpukit/include/rtems/pci.h), which according to the 410 page Software
Developer's Manual is the default value if the EEPROM is not programmed.

Is there debug code in the driver or pci bus code to print out all the IDs?
It sounds like this is a newer revision of the same NIC and has a
different ID
which the driver doesn't know and thus ignores.

Also it is possible that just adding the ID to the list in the driver is
not enough.
But recognizing the card is the first step. If it doesn't work, the
newest FreeBSD
driver will need to be looked at to see what the new ID implies for
differences.

Post by Charlie Strohman
Thanks,
Charlie Strohman
231 Wilson Lab
Cornell University
Ithaca, NY 14853
607-255-0687
_______________________________________________
rtems-users mailing list
http://www.rtems.org/mailman/listinfo/rtems-users

[Till Straumann]

Post by Joel Sherrill

Post by Charlie Strohman
I recently bought 2 new MVME5500 boards from Emerson. They have changed
the chip that supports the 1 Gbit ethernet interface from an Intel
82544EI to an Intel 82545GM. As a consequence, the 1 Gbit interface no
"i82544EI device ID not found"
Has anyone seen and fixed this? Might it be as simple as accepting the
PCI Device ID of the new chip? I'm using RTEMS 4.10.2. I looked at the
newest version and it seems to be the same code. I have not yet probed
into the hardware to see what ID value is being returned.
The ID of the older 82544EI is 0x1008 (from
"cpukit/include/rtems/pci.h), which according to the 410 page Software
Developer's Manual is the default value if the EEPROM is not programmed.

Is there debug code in the driver or pci bus code to print out all the IDs?
It sounds like this is a newer revision of the same NIC and has a
different ID
which the driver doesn't know and thus ignores.
Also it is possible that just adding the ID to the list in the driver is
not enough.
But recognizing the card is the first step. If it doesn't work, the
newest FreeBSD
driver will need to be looked at to see what the new ID implies for
differences.

FWIW: the driver I ported for the beatnik BSP is almost 10 years old
and it seems to support the 82545GM (IDs 0x1026, 0x1027, 0x1028).
You could use this BSP or you could also use the driver from the
libbsdport addon package (which is newer than the one in beatnik).

- T.

Post by Joel Sherrill

Post by Charlie Strohman
Thanks,
Charlie Strohman
231 Wilson Lab
Cornell University
Ithaca, NY 14853
607-255-0687
_______________________________________________
rtems-users mailing list
http://www.rtems.org/mailman/listinfo/rtems-users

[Peter Dufault]

Till, does SLAC use a mixture of 5500 and 6100 painlessly with Beatnik? I've told my client that uses the MVME5500 with Beatnik to get a 6100 in-house and test it out with their RTEMS software. As long as things are changing on the MVME5500 (slower cache, different ethernet controller) they should evaluate using the 6100 instead (faster processor, two gig-E ethernets, etc) to see if that can be used on new systems and as a replacement part (with the replacement maybe tied to recent software releases, they can hoard the older boards for really old systems).

Post by Till Straumann
FWIW: the driver I ported for the beatnik BSP is almost 10 years old
and it seems to support the 82545GM (IDs 0x1026, 0x1027, 0x1028).
You could use this BSP or you could also use the driver from the
libbsdport addon package (which is newer than the one in beatnik).

Peter
-----------------
Peter Dufault
HD Associates, Inc. Software and System Engineering

[Till Straumann]

We almost exclusively use 6100s at this point. I used 5500s mainly for
testing.
The BSP is certainly better tested on the 6100 although most code
(except for
the NIC drivers) is the same (which is why the BSP is run-time
compatible with
both boards).

- T.

Post by Peter Dufault
Till, does SLAC use a mixture of 5500 and 6100 painlessly with Beatnik? I've told my client that uses the MVME5500 with Beatnik to get a 6100 in-house and test it out with their RTEMS software. As long as things are changing on the MVME5500 (slower cache, different ethernet controller) they should evaluate using the 6100 instead (faster processor, two gig-E ethernets, etc) to see if that can be used on new systems and as a replacement part (with the replacement maybe tied to recent software releases, they can hoard the older boards for really old systems).

Post by Till Straumann
FWIW: the driver I ported for the beatnik BSP is almost 10 years old
and it seems to support the 82545GM (IDs 0x1026, 0x1027, 0x1028).
You could use this BSP or you could also use the driver from the
libbsdport addon package (which is newer than the one in beatnik).

Peter
-----------------
Peter Dufault
HD Associates, Inc. Software and System Engineering

[Kate Feng]

In USA, the original version of mvme5500 is still available for
purchasing.
I was in the process of adding the software support for the new NIC on
the mvme5500 board, then here is the discussion.....

According to the manufacture specification of the Discovery
system controllers (i.e. controllers for mvme5500 and mvme6100),
"GPP interrupt value register" should be used to monitor the interrupts.
However, Beatnik BSP uses the "GPP interrupt cause register" to
monitor the interrupts. I started to write a disco BSP to add supports
for discovery based boards such as mvme6100 to be run-time
compatible with the mvme5500 BSP that I wrote.

1) I prefer to follow the manufacture's specification.
2) I read the code of the beatnik network drivers years ago.
The code for the 100 MHz NIC on mvme5500 and 1 GHz NIC
on mvme6100 was patched with workarounds. If I recall
correctly, I tested the network performance of the beatnik BSP on the
100 MHz NIC on an image processing application, it delivered only
50% of performance as compared with that of the mvme5500 BSP.
I do not recall if I tested the performance of beatnik BSP on mvme6100.

With the assigned tasks I had back then,
a) I needed to test the performance, especially that of the DMA,
on the mvme6100 without compromising its performance and the
code (i.e. no workarounds !!! ).
b) It is painless to add supports for other discovery based boards because
I had the mvme5500 BSP handy.

The mvme5500 BSP supports the operations at NSLS smoothly. I never
needed to write any workarounds in my applications, including the code
for DMA. If there were any bug in the applications, I could be so confident
that it was not due to the BSP. The mvme6100 functions smoothly with the
disco BSP, too. However, the performance delivered by the mvme5500 BSP
is fast enough for most of my applications.

Cheers,
Kate Feng

Post by Peter Dufault
Till, does SLAC use a mixture of 5500 and 6100 painlessly with Beatnik?
I've told my client that uses the MVME5500 with Beatnik to get a 6100
in-house and test it out with their RTEMS software. As long as things are
changing on the MVME5500 (slower cache, different ethernet controller) they
should evaluate using the 6100 instead (faster processor, two gig-E
ethernets, etc) to see if that can be used on new systems and as a
replacement part (with the replacement maybe tied to recent software
releases, they can hoard the older boards for really old systems).

Post by Till Straumann
FWIW: the driver I ported for the beatnik BSP is almost 10 years old
and it seems to support the 82545GM (IDs 0x1026, 0x1027, 0x1028).
You could use this BSP or you could also use the driver from the
libbsdport addon package (which is newer than the one in beatnik).

Peter
-----------------
Peter Dufault
HD Associates, Inc. Software and System Engineering
_______________________________________________
rtems-users mailing list
http://www.rtems.org/mailman/listinfo/rtems-users

[Kate Feng]

Hi all,

The mvme5500 BSP is updated and tested on RTEMS4.10.2 to support the
new 1 Gbit Ethernet interface chip: Intel 82545GM. It can be
downloaded as mvme5500.tar.gz at
http://sourceforge.net/projects/rtemsdiscobsp4mvme5500mvme6100/files/?source=typ_redirect
The new support is added for the disco BSP as well for the RTEMS4.10.2.
It can be downloaded as disco-1.2.tar.gz at the same URL. Packed in
the disco-1.2.tar.gz tarball,
the code for mvme6100 was tested in RTEMS4.10.0 a while ago. I
currently do not have the board
to test it for RTEMS4.10.2.

Cheers,
Kate Feng

In USA, the original version of mvme5500 is still available for purchasing.
I was in the process of adding the software support for the new NIC on
the mvme5500 board, then here is the discussion.....
According to the manufacture specification of the Discovery
system controllers (i.e. controllers for mvme5500 and mvme6100),
"GPP interrupt value register" should be used to monitor the interrupts.
However, Beatnik BSP uses the "GPP interrupt cause register" to
monitor the interrupts. I started to write a disco BSP to add supports
for discovery based boards such as mvme6100 to be run-time
compatible with the mvme5500 BSP that I wrote.
1) I prefer to follow the manufacture's specification.
2) I read the code of the beatnik network drivers years ago.
The code for the 100 MHz NIC on mvme5500 and 1 GHz NIC
on mvme6100 was patched with workarounds. If I recall
correctly, I tested the network performance of the beatnik BSP on the
100 MHz NIC on an image processing application, it delivered only
50% of performance as compared with that of the mvme5500 BSP.
I do not recall if I tested the performance of beatnik BSP on mvme6100.
With the assigned tasks I had back then,
a) I needed to test the performance, especially that of the DMA,
on the mvme6100 without compromising its performance and the
code (i.e. no workarounds !!! ).
b) It is painless to add supports for other discovery based boards because
I had the mvme5500 BSP handy.
The mvme5500 BSP supports the operations at NSLS smoothly. I never
needed to write any workarounds in my applications, including the code
for DMA. If there were any bug in the applications, I could be so confident
that it was not due to the BSP. The mvme6100 functions smoothly with the
disco BSP, too. However, the performance delivered by the mvme5500 BSP
is fast enough for most of my applications.
Cheers,
Kate Feng

Post by Peter Dufault
Till, does SLAC use a mixture of 5500 and 6100 painlessly with Beatnik? I've told my client that uses the MVME5500 with Beatnik to get a 6100 in-house and test it out with their RTEMS software. As long as things are changing on the MVME5500 (slower cache, different ethernet controller) they should evaluate using the 6100 instead (faster processor, two gig-E ethernets, etc) to see if that can be used on new systems and as a replacement part (with the replacement maybe tied to recent software releases, they can hoard the older boards for really old systems).

Post by Till Straumann
FWIW: the driver I ported for the beatnik BSP is almost 10 years old
and it seems to support the 82545GM (IDs 0x1026, 0x1027, 0x1028).
You could use this BSP or you could also use the driver from the
libbsdport addon package (which is newer than the one in beatnik).

Peter
-----------------
Peter Dufault
HD Associates, Inc. Software and System Engineering
_______________________________________________
rtems-users mailing list
http://www.rtems.org/mailman/listinfo/rtems-users