Re: [U-Boot] [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].
+#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.
-----Original Message----- From: Michael Walle [mailto:michael@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 ofregisters
* the below configuration configures mainly initial LEDstatus
*/
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 . . .
Hi,
Am Dienstag 27 März 2012, 13:05:05 schrieb Prafulla Wadaskar:
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 :-(
Wolfgang, what do you think about relaxing this policy a bit and allowing this class of devices (no service port/serial port available, no storage for the MAC address besides the environment) to use hardcoded values (maybe defined in a place common to all boards). Again, i don't think my device is the only one with this problem.
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.
The elf/bin is just for testing and the kwb image will be written into the spi flash, i need both (at least i need the kwb image). I could remove the ramboot target, but i think its really handy if someone likes to play with a self compiled uboot.
Dear Michael,
In message 201203272255.59259.michael@walle.cc you wrote:
Wolfgang, what do you think about relaxing this policy a bit and allowing this class of devices (no service port/serial port available, no storage for the MAC address besides the environment) to use hardcoded values (maybe defined in a place common to all boards). Again, i don't think my device is the only one with this problem.
Probably it is not the only device, but eventually all the others found other working solutions?
I still fail to understand why you would need fixed network settings. Evenin emergency cases, the only parameter you really need is a MAC address, all others can be fetched for example from a DHCP server.
As for the MAC address, it is in such emergencies OK to use a random locally administered Ethernet address. Note the "random" - hard- coding the same address for all devices is definitely a No-Go.
Best regards,
Wolfgang Denk
Hi Wolfgang,
I still fail to understand why you would need fixed network settings. Evenin emergency cases, the only parameter you really need is a MAC address, all others can be fetched for example from a DHCP server.
bootp/dhcp should work for getting the ip address. My initial thought was that you need to hardcode the ncip anyway, which means you need the ipaddr etc, too. Using DHCP and setting the ncip to the delivered serverip should be ok, i think.
As for the MAC address, it is in such emergencies OK to use a random locally administered Ethernet address. Note the "random" - hard- coding the same address for all devices is definitely a No-Go.
Is 02:00:00:RR:RR:RR, where RR is a random byte, ok?
participants (3)
-
Michael Walle -
Prafulla Wadaskar -
Wolfgang Denk