Date: Wed, 08 Aug 2007 19:08:48 +0300 From: Krassimir Slavchev <krassi@bulinfo.net> To: ticso@cicely.de Cc: freebsd-arm@freebsd.org Subject: Re: CENTIPAD boot Message-ID: <46B9EA90.3050508@bulinfo.net> In-Reply-To: <20070808154756.GN41893@cicely12.cicely.de> References: <46B9C68E.2010000@bulinfo.net> <20070808.074028.-749249084.imp@bsdimp.com> <46B9CAD8.4040103@bulinfo.net> <20070808144152.GM41893@cicely12.cicely.de> <46B9DD23.70608@bulinfo.net> <20070808154756.GN41893@cicely12.cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
-----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: 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.
>
I have had such problem.
>> 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
> 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.
I will add link negotiation here.
>
>>> 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (FreeBSD)
iD8DBQFGueqQxJBWvpalMpkRAoLVAKCcBecAXRpOXHWEASqaXoEh3rPRJQCfTQ8e
a9DzYBLsSVFnnmsgWEFGxww=
=wQMs
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46B9EA90.3050508>