RE: [ECOS] NPE ethernet not working with Redboot v2.04

["Ravi R" <rr94ca at gmail dot com>]

I tried your recommendation of testing the board in Big Endian.
The board works fine in Big Endian. All devices (UART, PCI, FLASH,
NPE/ETH) are recognized, setup, redboot boots up fine and I am able to
ping other hosts via the ethernet - NPE-B Phy 0.

In LE mode where the NPE/ETH does not work, It seems only the NPE/QMgr
component registers are being byte swapped and written incorrectly.
All other registers, EXPB, PCI, UART are written and work correctly.

With the CPU and debugger set in LE mode all the bit fields
constructed in CPU registers in preperation for writing to component
registers (UART, PCI, EXPB) match the bit field order defined in the
developer manual for these components. Since all of these are accessed
via the South AHB I expect the Bit field order for the QMGR registers
to be treated the same. So I do not understand the need to swap bytes
when writing to the QMGR registers, except when transferring ethernet
'data' that needs to be byte swapped. Even if the NPE reads the QMGR
registers in big endian, I would think the QMGR register bit field
definition is constant(?).

In anycase tried changing IXP_MAP_IO_DC to IXP_MAP_IO for
IXP425_QMGR_BASE in _platform_setup1, thinking that this ( the P bit
in the page table) may reverse the effect of the IX_OSAL_WRITE_LONG()
byte swap just for the QMGR component, but this did not seem to have
any effect.

I also tried forcing IX_OSAL_WRITE_LONG() to not do byte swapping by
removing the IX_COMPONENT_NAME definition in
IxOsalOsalIxp400CustomizedMappings.h to define IX_OSAL_LE_AC_MAPPING
instead of IX_OSAL_LE_DC_MAPPING.
This seems to write the QMgr registers with values that makes sense
but also causes other problems that I was not able
to track down/resolve.

Given that the Redboot code V2.04 has been thoroughly tested in LE and
BE mode and all byte swapping should be
dealt with by setting CYGHWR_HAL_ARM_BIGENDIAN I am at a loss as to
how to explain what I am seeing.

Our memory map has not changed from the IXDP425 - our board has a few
less devices and smaller RAM.

I must be doing something wrong/mis understanding something.
Any guidance would be appreciated.
Ravi

>
> LE mode is just plain weird on the IXP4xx family. There are
> actually two forms of LE (address coherent and data
> coherent). A bit in the page table controls which form of LE
> is used for a given mapped area.
>
> BE and LE have been thoroughly tested on the IXDP425 and
> other boards so all the details of byte-swapping have already
> been worked out and just setting CYGHWR_HAL_ARM_BIGENDIAN
> should be all that needs to be done.
>
> If at all possible, the initial debugging of RedBoot and the
> npe support should be done in BE mode. That is the natural
> ordering and you won't have to worry about the byte-swapping
> mess with LE mode.
>
> In LE mode, the MMU has to provide two views of memory. If
> your memory map has changed from the IXDP425, then you may
> have to change some of the values in IxOsalOsIxp400.h to
> match those memory map changes. Also, there was errata on
> some early versions of the IXP425 which did not correctly
> handle LE mode. But if you're using a new board, I doubt that
> is the problem.
>
> All you need to read/write the PHY regs are mdc and mdio
> signals. That doesn't mean that txclk/txdata/rxclk/rxdata/etc
> are correctly connected.
>
> --Mark

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss