> -----Original Message----- > From: Michael Walle [mailto:mich...@walle.cc] > Sent: 27 March 2012 16:22 > To: Prafulla Wadaskar > Cc: Michael Walle; u-boot@lists.denx.de > Subject: RE: [PATCH v2] lsxl: add support for lschlv2 and lsxhl > > 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].
You need special environment variables by default, u-boot development policy does not allow this, so you can have clean code mainlined and keep this customization patch private to you. This is what I think the solution could be :-( > > > >> +#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). AFAIK, for ram boot you need u-boot ELF image, you can use u-boot.bin but u-boot.kwb image cannot be used for boot from RAM, kwbimage.cfg helps to create u-boot.kwb target which is useless for boot from RAM use case. So you need to remove it. Regards.. Prafulla . . . _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot