ltib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Ltib] phy3250 uboot environment in eeprom


From: Kevin Wells
Subject: RE: [Ltib] phy3250 uboot environment in eeprom
Date: Sat, 19 Dec 2009 01:42:09 +0100

Hi Mike,

I think your on the right track...

This mailing lists focuses more on LTIB than any platform in
general, you can get better 3250 related help on the lpc3000
Yahoo news group (I'm there too).

>I have seen your u-boot patch, especially in board/phy3250/lowlevels_init.c 
>function phy3250_get_board_info.
>For example, here is implemented mac address reading from EEPROM, but when I 
>run "bdinfo" command, it shows: ethaddr     = 00:00:00:00:00:00 Any 
>suggestions? Where mac address saves?

On the Phytec board, the MAC address is preprogrammed into the SPI
FLASH at the factory. You'll probably want to save it there also.

>So, I think it is possible to implement reading address from EEPROM, where 
>unbroken kernel is placed.
>It is also need to modify include/configs/phy3250.h this string for all three 
>u-boot images in NAND, this string:
>#define CONFIG_ENV_OFFSET    0x168000 /* Block 90 */

Might I suggest the following EEPROM partitioning?
16K-kickstart
128K-S1L
128K-u-boot
8K-u-boot parametres
All the rest-kernel image

You can actually get rid of S1L if you want and boot to u-boot
directly from the kickstart loader. You'll have to move the
board init code from S1L into u-boot, but it will save you
about 120K if space is at a premium.

thanks,
Kevin


>Hello, Kevin.
>
>Thank you for your message. I am developing reliable device on lpc3250 core.
>kickstart is placed to the EEPROM now, because NAND flash is not reliable.
>S1L, u-boot and linux kernel will be placed in NAND by following way:
>block 1: S1L S1L S1L    u-boot u-boot u-boot    kernel kernel kernel
>
>kickstart is modified and now it counts CRC checksum for S1L, u-boot and 
>kernel, compares it with CRC saved in the EEPROM. It is still less than 15,5 
>kb.
>
>so, modified kickstart algorithm should be as follows:
>1. find unbroken S1L
>2. find unbroken uboot
>3. modify S1L config in EEPROM so it will link to unbroken uboot
>4. find unbroken kernel
>5. modify uboot config so t will load unbroken linux kernel
>6. copy S1L to RAM and start it  (this is default kickstart functionality)
>
>I have already modified S1L so it is now reads from EEPROM number of block 
>where u-boot is placed and loads it from that place.
>
>
>I have seen your u-boot patch, especially in board/phy3250/lowlevels_init.c 
>function phy3250_get_board_info.
>For example, here is implemented mac address reading from EEPROM, but when I 
>run "bdinfo" command, it shows: ethaddr     = 00:00:00:00:00:00 Any 
>suggestions? Where mac address saves?
>
>So, I think it is possible to implement reading address from EEPROM, where 
>unbroken kernel is placed.
>It is also need to modify include/configs/phy3250.h this string for all three 
>u-boot images in NAND, this string:
>#define CONFIG_ENV_OFFSET    0x168000 /* Block 90 */
>
>The root file system also will be placed in NAND and it will be jffs2.
>
>With best regards, 
> Mike
>
>2009/12/16 Kevin Wells <address@hidden>
>
>Hi Mike,
>
>There is some simple code in that port of u-boot for
>reading a SPI based EEPROM device that can easily be
>updated with additional write support. This is
>initially used with the SPI EEPROM to get board data.
>You can also get a rw example at the chip vendor's
>website.
>
>I can't help you too much with the u-boot implemention,
>but you'll also probably want to look at the u-boot
>spi or mtd support.
>
>Kevin
>
>> Subject: Re: [Ltib] phy3250 uboot environment in eeprom
>>
>> Hi Mike,
>>
>> You may get some help on the u-boot list, maybe someone has done this
>> before?
>>
>> As I recall the u-boot configuration data is often saved in it's own
>> Flash sector, so you could look a this code and re-work it (the savenenv
>> command).
>>
>> Regards, Stuart
>>
>> Mike RA9FTM wrote:
>> > Hello
>> >
>> > I whant to save phy3250 uboot configuration data in EEPROM, not in NAND
>> > flash.
>> > I think it is possible with some u-boot code modification.
>> > So, is it really hard to implement this feature or not?
>> >
>> > I think that most hard is to load SPI driver...
>> >
>> >
>> > --
>> > 73! Mike RA9FTM
>> >
>> >
>>
>>
>> _______________________________________________
>> LTIB home page: http://ltib.org
>>
>> Ltib mailing list
>> address@hidden
>> http://lists.nongnu.org/mailman/listinfo/ltib



-- 
73! Mike RA9FTM




reply via email to

[Prev in Thread] Current Thread [Next in Thread]