Re: eCos GNU tools 4.6.2-20120125 ready for testing

[Alex Schuilenburg <alexs@ecoscentric.com>]

John,

On 2012-03-10 17:16, John Dallaway wrote:
> Hi Alex
>
> Alex Schuilenburg wrote:
>
>> I have finally got a limping version of RedBoot generated from anoncvs
>> running on this platform in our test farm, and it does run tests
>> generated from anoncvs ecos.  Unfortunately both ethernet and flash
>> support for this board appears broken, so lwip and bsd testing is out. 
> Just to be sure, did you set
> CYGHWR_HAL_ARM_LPC24XX_EA2468_DATA_BUS_WIDTH == 32 in both the RedBoot
> and eCos test application builds for use with your Embedded Artists
> LPC2468-32 OEM board?

Yes and both anoncvs builds (32 bit and thumb) have

echo cdl_option CYGHWR_HAL_ARM_LPC24XX_EA2468_DATA_BUS_WIDTH { user_value 32 } | ecosconfig import /dev/stdin

as part of their build script.  Don't be misled by the target name
ea_lpc2468_32 as I just added this as an alias to ecos.db for the board
so it would be easier to simply add into the farm without having to
create a new platform and board.

> Very little has changed in the HAL and driver packages for the ea2468
> target since the port was first contributed, although the LPC2xxx
> ethernet driver has been extended for use with LPC17xx parts.

On a hunch following the above remarks I rebuilt RedBoot without
ethernet support.  The same "heaptest" test that failed in the farm
passes on this newer RedBoot on a second board I have in the office.
Previously, when it came up it complained:

+
LPC2XXX_ETH: Initialising 0xFFE00000
LPC2XXX_ETH - Warning! ESA unknown
LPC2XXX_ETH: 12:34:56:78:9a:bc
No network interfaces found

RedBoot(tm) bootstrap and debug environment [ROM]
Non-certified release, version UNKNOWN - built 18:10:14, Mar  7 2012


Now it gives no such complaints. It could be down to the boards though
because we know one of these boards was a bit fragile when run in the
farm last time, although we think it was for resetting only and we
thought it was the one I have here that was fragile. 

Alternatively, unless there is an undocumented ethernet option for
configuring ethernet support for RedBoot for this board, ethernet
support could have suffered bitrot since the extension for LPC17xx parts
and this *may* be affecting the test results. The ethernet is connected
to the board in the farm.

We will hopefully swap the boards over tomorrow in the farm so some of
these failures will start passing.  The timeouts are killing progress. I
will restart the tests in the farm which will clean up tests like
"heaptest" which appear effected by either the "faulty ethernet RedBoot"
or the board and will re-run "heaptest" once I have replaced RedBoot
when I get this board back to confirm which is at fault (board or RedBoot).

Cheers
-- Alex

Managing Director/CEO                                eCosCentric Limited

  **  Visit us at the ESC Expo at Design West in San Jose  **
  **  27-29 March, McEnery Convention Center - Stand #846  *