CENTIPAD boot

[Bernd Walter]

On Wed, Aug 08, 2007 at 06:11:31PM +0300, Krassimir Slavchev wrote:
> Bernd Walter wrote:
> > On Wed, Aug 08, 2007 at 04:53:28PM +0300, Krassimir Slavchev wrote:
> Index: bootspi/loader_prompt.c
> ===================================================================
> RCS file: /home/ncvs/src/sys/boot/arm/at91/bootspi/loader_prompt.c,v
> retrieving revision 1.4
> diff -u -r1.4 loader_prompt.c
> - --- bootspi/loader_prompt.c	15 Mar 2007 03:31:48 -0000	1.4
> +++ bootspi/loader_prompt.c	8 Aug 2007 13:49:21 -0000
> @@ -29,7 +29,6 @@
>  #include "env_vars.h"
>  #include "lib.h"
>  #include "spi_flash.h"
> - -#include "ee.h"
> 
>  /******************************* GLOBALS
> *************************************/
> 
> @@ -286,8 +285,9 @@
>  	{
>  	    char buf[25];
>  		printf("Testing Config EEPROM\n");
> - -		EEWrite(0, "This is a test", 15);
> - -		EERead(0, buf, 15);
> +		strcpy(buf,"This is a test!");
> +		WriteEEPROM(0, buf, 15);
> +		ReadEEPROM(0, buf, 15);
>  		printf("Found '%s'\n", buf);
>  		break;
>  	}
> 
> > Why remove ee.h and then access the eeprom?
> > I never used the eeprom code, so I'm unshure about it.
> > At least the following line should be added befor printing:
> > buf[15] = '\0';
> 
> WriteEEPROM() and ReadEEPROM() functions are in libat91. May be ee.c
> should be removed too.
> Yes, The '!' char should be removed from the string.

Oh - this wasn't abnout the '!' - it was just in case there is
a problem with the eeprom to limit the output.
But after rethinking it would be better to bzero the whole buf
between write and read, since a failure to read the eeprom might
leave the old content completely intact, without anyone to notice.

> Index: libat91/Makefile
> ===================================================================
> RCS file: /home/ncvs/src/sys/boot/arm/at91/libat91/Makefile,v
> retrieving revision 1.9
> diff -u -r1.9 Makefile
> - --- libat91/Makefile	13 Jul 2007 14:27:04 -0000	1.9
> +++ libat91/Makefile	8 Aug 2007 13:49:22 -0000
> @@ -8,7 +8,7 @@
>  	putchar.c printf.c reset.c spi_flash.c xmodem.c \
>  	sd-card.c strcvt.c strlen.c strcmp.c memcpy.c strcpy.c \
>  	memset.c memcmp.c
> - -SRCS+=ashldi3.c divsi3.c
> +SRCS+=ashldi3.c divsi3.S
>  NO_MAN=
> 
>  .if ${MK_TAG_LIST} != "no"
> 
> > Why is the filename change needed?
> > This is obviously unrelated to the board support.
> > Do we have a Makefile error in CVS?
> 
> I can't find divsi3.c in the source tree. Yes it seems to be Makefile error.

I guess these things happen because most of us use perforce code, at
least when building bootcode.
It is likely correct there.

> Yes, I should do the link negotiation.

What PHY do you have?
The link/speed registers are always the same with a few exceptions,
which are usually just integrated PHY.
Even in my case with the switch I get sensible values with Warners
code, but this is for the external port 0, which is unrelated to the
speed between the MAC and the switch.

> > Although this is correct with our current code.
> > Please split BOOT_BWCT and BOOT_CENTIPAD here, since I localy have
> > 0xAC added as a valid status:
> > #ifdef BOOT_BWCT
> >         value = GetFlashStatus();
> >         if ((value  & 0xFC) != 0xAC
> >             && (value  & 0xFC) != 0xB4)
> >                 printf(" Bad SPI status: 0x%x\n", value);
> > #else
> > This is because I use AT45DB161D chips in production.
> > The 0xB4 is from the AT45DB321C, which I'd used in prototypes only.
> > I might use other SPI types for special purspose as well.
> 
> Feel free to change anything you wish!

Since we are in freeze and this is Warners code and he has a blanket
approval, I leave it up to him.
If I would ask RE he will likely have to review it anyway.

-- 
B.Walter                http://www.bwct.de      http://www.fizon.de
bernd at bwct.de           info at bwct.de            support at fizon.de