[U-Boot] [PATCH v2] lsxl: add support for lschlv2 and lsxhl
Michael Walle
michael at walle.cc
Tue Mar 27 12:51:37 CEST 2012
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
More information about the U-Boot
mailing list