[U-Boot] [PATCH v2] lsxl: add support for lschlv2 and lsxhl
Prafulla Wadaskar
prafulla at marvell.com
Tue Mar 27 13:05:05 CEST 2012
> -----Original Message-----
> From: Michael Walle [mailto:michael at walle.cc]
> Sent: 27 March 2012 16:22
> To: Prafulla Wadaskar
> Cc: Michael Walle; u-boot at 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 . . .
More information about the U-Boot
mailing list