CENTIPAD boot

[Bernd Walter]

On Wed, Aug 08, 2007 at 07:08:48PM +0300, Krassimir Slavchev wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Bernd Walter wrote:
> > 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: 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?
> 
> rlphy

I would assume a RTL8201BL or RTL8201C?
I have code for the RTL8201BL, which I use with the AT91SAM7X256, but
it is likely not correct, since I tried a 10BASET link once and it
failed, but I just took the original code without modification though.
Anyway - Realtek has datasheets available online.

> >>> 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.
> > 
> 
> Yes, but the the current arm boot code needs these changes at least more
> people to be able to test it.

I'm not against to seeing it fixed :)
But as long as we are in freeze and Warner takes care about it...

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