Date: Wed, 8 Aug 2007 17:47:57 +0200 From: Bernd Walter <ticso@cicely12.cicely.de> To: Krassimir Slavchev <krassi@bulinfo.net> Cc: freebsd-arm@freebsd.org, ticso@cicely.de Subject: Re: CENTIPAD boot Message-ID: <20070808154756.GN41893@cicely12.cicely.de> In-Reply-To: <46B9DD23.70608@bulinfo.net> References: <46B9C68E.2010000@bulinfo.net> <20070808.074028.-749249084.imp@bsdimp.com> <46B9CAD8.4040103@bulinfo.net> <20070808144152.GM41893@cicely12.cicely.de> <46B9DD23.70608@bulinfo.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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@bwct.de info@bwct.de support@fizon.de
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070808154756.GN41893>