Hi Prafulla, thanks for the review.
>> +++ b/board/buffalo/lsxl/kwbimage-lsxhl.cfg > BTW: What is difference between them? if it is very small you can manage > it through c file. mh? arent these the values which end up in the head of an SPI image, the SoC bootstrap rom will execute? how can these be changed with a c file? I extracted these values from the original vendor supplied uboot binary / SPI dump. >> +/* >> + * Rescue mode >> + * >> + * Selected by holding the push button for 3 seconds, while powering on >> + * the device. >> + * >> + * These linkstations don't have a (populated) serial port. There is no >> + * way to access an (unmodified) board other than using the netconsole. >> If >> + * you want to recover from a bad environment setting or an empty > environment, >> + * you can do this only with a working network connection. Therefore, the >> + * following network configuration will be set when rescue mode is stared. >> + * Additionally, the bootsource is set to 'cli'. >> + */ >> +#define RESCUE_ETHADDR "02:00:01:00:00:00" >> +#define RESCUE_IPADDR "192.168.11.150" >> +#define RESCUE_NETMASK "255.255.255.0" >> +#define RESCUE_SERVERIP "192.168.11.1" > NAK, no hardcoding please. Unfortunately, this is not possible. As described in the comment above, you have to have a working network to use the netconsole. Also have a look at: http://lists.denx.de/pipermail/u-boot/2012-January/114547.html I removed the hardcoded values from the environment and put it into a special rescue mode, so it won't show up until the user is explicitly choosing that mode. I can understand, that hardcoded values are bad but in this case i cannot think of any other (easy and reliable) way to get access to a misconfigured linkstation. Do you have any other idea? again, the only interfaces you have are ethernet, one button, two (multiple color leds), one switch with three positions [and an usb port, only available on older linkstations]. >> +#define RESCUE_NCIP RESCUE_SERVERIP >> + >> +#ifndef CONFIG_ENV_OVERWRITE >> +# error "You need to set CONFIG_ENV_OVERWRITE" >> +#endif >> + >> +DECLARE_GLOBAL_DATA_PTR; >> + >> +int board_early_init_f(void) >> +{ >> + /* >> + * default gpio configuration >> + * There are maximum 64 gpios controlled through 2 sets of registers >> + * the below configuration configures mainly initial LED status + */ >> + kw_config_gpio(LSXL_OE_VAL_LOW, >> + LSXL_OE_VAL_HIGH, >> + LSXL_OE_LOW, LSXL_OE_HIGH); >> + >> + /* Multi-Purpose Pins Functionality configuration */ >> + u32 kwmpp_config[] = { >> + MPP0_SPI_SCn, >> + MPP1_SPI_MOSI, >> + MPP2_SPI_SCK, >> + MPP3_SPI_MISO, >> + MPP4_UART0_RXD, >> + MPP5_UART0_TXD, >> + MPP6_SYSRST_OUTn, >> + MPP7_GPO, >> + MPP8_GPIO, >> + MPP9_GPIO, >> + MPP10_GPO, >> + MPP11_GPIO, >> + MPP12_SD_CLK, >> + MPP13_SD_CMD, >> + MPP14_SD_D0, >> + MPP15_SD_D1, >> + MPP16_SD_D2, >> + MPP17_SD_D3, >> + MPP18_GPO, >> + MPP19_GPO, >> + MPP20_GE1_0, >> + MPP21_GE1_1, >> + MPP22_GE1_2, >> + MPP23_GE1_3, >> + MPP24_GE1_4, >> + MPP25_GE1_5, >> + MPP26_GE1_6, >> + MPP27_GE1_7, >> + MPP28_GPIO, >> + MPP29_GPIO, >> + MPP30_GE1_10, >> + MPP31_GE1_11, >> + MPP32_GE1_12, >> + MPP33_GE1_13, >> + MPP34_GPIO, >> + MPP35_GPIO, >> + MPP36_GPIO, >> + MPP37_GPIO, >> + MPP38_GPIO, >> + MPP39_GPIO, >> + MPP40_GPIO, >> + MPP41_GPIO, >> + MPP42_GPIO, >> + MPP43_GPIO, >> + MPP44_GPIO, >> + MPP45_GPIO, >> + MPP46_GPIO, >> + MPP47_GPIO, >> + MPP48_GPIO, >> + MPP49_GPIO, > are you using all there MFPs on your board, it's better to comment about GPIOs for their usage i guess i can only describe a subset of these gpios, as it is a proprietary board by linksys i have no documenation about ;) but i'll add the ones i know. >> --- a/boards.cfg >> +++ b/boards.cfg >> @@ -137,6 +137,9 @@ hawkboard_uart arm arm926ejs > da8xxevm davinci >> enbw_cmc arm arm926ejs enbw_cmc > enbw davinci >> calimain arm arm926ejs calimain > omicron davinci >> dns325 arm arm926ejs - >> d- > link kirkwood >> +lschlv2 arm arm926ejs lsxl > buffalo kirkwood lsxl:LSCHLV2 >> +lschlv2_ramboot arm arm926ejs lsxl > buffalo kirkwood > lsxl:LSCHLV2,SYS_RAMBOOT,SYS_TEXT_BASE=0x00700000 >> +lsxhl arm arm926ejs lsxl > Again, if the board is boot from RAM, you dont need kwbimage.cfg for that > particular board. mh? the lschlv2_ramboot is just for testing purposes. So you can try the bootloader without actually overwriting it in the boot flash. The actual images are the lschlv2 and lsxhl targets. I guess i should add a lsxhl_ramboot, too. There was no need for the latter because i have a jtag connector on my lsxhl (but not on the lschlv2). >> +#define CONFIG_SYS_KWD_CONFIG $(SRCTREE)/$(CONFIG_BOARDDIR)/kwbimage- > lschl.cfg >> +#define CONFIG_MACH_TYPE 3006 >> +#define CONFIG_SYS_TCLK 166666667 /* 166 MHz */ > No hardcoding, why you want to run kirkwood at 166? mh, is there any autodetection, i don't know? if i run it without the TCLK set to 166mhz the serial out is screwed up. FYI, the LS-CHLv2 is basically a stripped down version of the LS-XHL (running at TCLK=200MHz). I guess Linksys is running the CPU at 166MHz, although i couldn't find such a strapping in the manual. > Is the chip 6281/6282 or 6192? I'll have a look later. Don't have a board right now. -- michael _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot