[U-Boot] Rework the network stack
Hi all, there is an issue with the current network stack using netconsole. It's impossible to use network commands as TFTP inside netconsole, because they try to run as atomic network commands. The issue was already reported by Stefano Babic in 2010: [U-Boot] NetConsole and network API http://lists.denx.de/pipermail/u-boot/2010-August/075535.html I run into the same problem: [U-Boot] netconsole: USB Ethernet connection dropping with ping or tftpboot http://lists.denx.de/pipermail/u-boot/2015-February/203838.html I have looked at the current network stack. The stack is based on the concept of atomic network commands. The implementation for netconsole looks very confusing. Sascha Hauer has reimplemented the network stack for Barebox: http://www.spinics.net/lists/u-boot-v2/msg00914.html Looking at the current implementation of net.c looks very clean and well-designed. What do you think about porting this to U-Boot? Best regards Jörg Krause ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: fix OCR Polling
Hi, Andrew
On 3/20/2015 3:19 PM, Andrew Gabbasov wrote:
Hi Peng,
From: Peng.Fan at freescale.com (Peng Fan)
Date: Thu, 19 Mar 2015 16:22:46 +0800
Subject: [U-Boot] [PATCH] mmc: fix OCR Polling
If in mmc_send_op_cond, OCR_BUSY is set in CMD1's response, then
state is transfered to Ready state, and there is no need to send
CMD1 again. Otherwise following CMD1 will recieve no response, or
timeour error from driver such as fsl_esdhc.c.
If not into Ready state in previous CMD1, then continue CMD1 command.
In mmc_complete_op_cond, we use the value mmc-op_cond_response
from mmc_send_op_cond, since there should be no CMD1 command between
mmc_send_op_cond and mmc_complete_op_cond
Before fixing this, uboot log shows:
CMD_SEND:0
ARG 0x
MMC_RSP_NONE
CMD_SEND:8
ARG 0x01AA
MMC_RSP_R1,5,6,7 0x18EC1504
CMD_SEND:55
ARG 0x
MMC_RSP_R1,5,6,7 0x18EC1504
CMD_SEND:0
ARG 0x
MMC_RSP_NONE
CMD_SEND:1
ARG 0x
MMC_RSP_R3,4 0x00FF8080
CMD_SEND:1
ARG 0x4030
MMC_RSP_R3,4 0xC0FF8080 -- Already OCR_BUSY
set
CMD_SEND:1
ARG 0x4030
MMC_RSP_R3,4 0x0096850A -- Failed CMD1
MMC init failed
Using this patch, this issue is fixed, emmc can be detected correctly.
Signed-off-by: Peng Fan Peng.Fan at freescale.com
---
drivers/mmc/mmc.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index a13769e..43a9a8a 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -406,14 +406,23 @@ static int mmc_complete_op_cond(struct mmc *mmc)
mmc-op_cond_pending = 0;
start = get_timer(0);
-do {
+/*
+ * If in mmc_send_op_cond, OCR_BUSY is set in CMD1's response, then
+ * state is transfered to Ready state, and there is no need to
+ * send CMD1 again. Otherwise following CMD1 will recieve no
response,
+ * or timeour error from driver such as fsl_esdhc.c.
+ *
+ * If not into Ready state in previous CMD1, then continue CMD1
+ * command.
+ */
+while (!(mmc-op_cond_response OCR_BUSY)) {
err = mmc_send_op_cond_iter(mmc, cmd, 1);
if (err)
return err;
if (get_timer(start) timeout)
return UNUSABLE_ERR;
udelay(100);
-} while (!(mmc-op_cond_response OCR_BUSY));
+}
if (mmc_host_is_spi(mmc)) { /* read OCR for spi */
cmd.cmdidx = MMC_CMD_SPI_READ_OCR;
--
1.8.4
After this patch, if the busy flag is indeed already set (so that the loop
body
is not executed), and it is not an SPI case (mmc_host_is_spi(mmc) is false),
the cmd structure (which is local to mmc_complete_op_cond() function)
is left uninitialized, and using cmd.response[0] later in the function
becomes
incorrect. And the OCR register value and the high capacity flag may be set
incorrectly.
Yeah. you are right.
Maybe the following piece of code should be added to replace mmc-ocr =
cmd.response[0]:
if (mmc_host_is_spi(mmc))
mmc-ocr = cmd.response[0];
else
mmc-ocr = mmc-op_cond_response;
Thanks for correcting me.
So, this patch is not enough by itself, it needs to be modified (appended)
in order to get the correct code.
Coincidentally, the same day I submitted a patch series
([U-Boot] [PATCH 0/6] mmc: Fix OCR polling and splitted initialization),
that, among other changes, fixes the OCR polling problem too
([U-Boot] [PATCH 4/6] mmc: Continue polling MMC card for OCR only if it is
still not ready),
but in a slightly different way, that hopefully doesn't have the mentioned
issue.
Your's does not have such issue:)
Thanks.
Best regards,
Andrew
.
Thanks
Peng.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] arm: mx5: Add support for USB armory board
On 2015-03-19, Andrej Rosano wrote:
On Thu, Mar 19, 2015 at 09:55:26AM -0700, Vagrant Cascadian wrote:
On 2015-02-24, and...@inversepath.com wrote:
Add support for Inverse Path USB armory board, an open source
flash-drive sized computer based on Freescale i.MX53 SoC.
...
Would you consider patches that include config_distro_defaults.h and
config_distro_bootcmd.h, documented in doc/README.distro? It may require
adding several variables such as fdt_addr_r, fdtfile, ramdisk_addr_r,
ramdiskfile, kernel_addr_r, bootfile, pxe_addr_r and scriptaddr,
documented in README and doc/README.distro. I'd be happy to work on
patches.
...
Sure, it would be nice to have this included in the patch.
I didn't know about this, I will take a look as well. Let me know if
you need any help from my side.
Ok, here's a quick patch on top of your existing patch. It compiles, but
I haven't tested that it boots (waiting on some header pins to hook up
the serial console).
I tried to preserve default behavior, the only difference is that it
will first check for extlinux.conf and boot.scr before running the
default boot action, and has a 2 second rather than 1 second bootdelay.
Many of the things defined in config_distro_defaults.h were redundant.
Not sure if CONFIG_LOADADDR needs to be different from
kernel_addr_r/scriptaddr/pxefile_addr_r, if they can all be the same,
then they could be defined with CONFIG_LOADADDR. Hopefully
ramdisk_addr_r is at a reasonable location so it won't be clobbered by
the fdt or kernel being loaded to a lower address. It may require
removing the default bootargs to work with boot scripts.
diff --git a/include/configs/usbarmory.h b/include/configs/usbarmory.h
index e00ec7b..7e4cc68 100644
--- a/include/configs/usbarmory.h
+++ b/include/configs/usbarmory.h
@@ -22,12 +22,10 @@
#include asm/arch/imx-regs.h
#include config_cmd_default.h
+#include config_distro_defaults.h
/* U-Boot commands */
-#define CONFIG_CMD_BOOTZ
-#define CONFIG_CMD_FAT
#define CONFIG_CMD_MEMTEST
-#define CONFIG_CMD_EXT2
#undef CONFIG_CMD_IMLS
/* U-Boot environment */
@@ -39,14 +37,10 @@
#define CONFIG_SYS_MMC_ENV_DEV 0
/* U-Boot general configurations */
-#define CONFIG_SYS_LONGHELP
-#define CONFIG_SYS_HUSH_PARSER
-#define CONFIG_AUTO_COMPLETE
#define CONFIG_SYS_CBSIZE 512
#define CONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE + sizeof(CONFIG_SYS_PROMPT)
+ 16)
#define CONFIG_SYS_MAXARGS 16
#define CONFIG_SYS_BARGSIZECONFIG_SYS_CBSIZE
-#define CONFIG_CMDLINE_EDITING
/* UART */
#define CONFIG_MXC_UART
@@ -61,7 +55,6 @@
#define CONFIG_SYS_FSL_ESDHC_NUM 2
#define CONFIG_MMC
#define CONFIG_GENERIC_MMC
-#define CONFIG_DOS_PARTITION
/* USB */
#define CONFIG_CMD_USB
@@ -82,7 +75,6 @@
#define CONFIG_FSL_IIM
/* Linux boot */
-#define CONFIG_BOOTDELAY 1
#define CONFIG_LOADADDR0x7200
#define CONFIG_SYS_TEXT_BASE 0x7780
#define CONFIG_SYS_LOAD_ADDR CONFIG_LOADADDR
@@ -90,8 +82,28 @@
#define CONFIG_BOOTARGS \
console=ttymxc0,115200 root=/dev/mmcblk0p1 rootwait rw
#define CONFIG_BOOTCOMMAND \
- ext2load mmc 0:1 0x7080 /boot/uImage; ext2load mmc 0:1 \
- 0x7100 /boot/imx53-usbarmory.dtb; bootm 0x7080 - 0x7100
+ run distro_bootcmd; \
+ ext2load mmc 0:1 ${kernel_addr_r} /boot/uImage; \
+ ext2load mmc 0:1 ${fdt_addr_r} /boot/${fdtfile}; \
+ bootm ${kernel_addr_r} - ${fdt_addr_r}
+
+#define BOOT_TARGET_DEVICES(func) \
+ func(MMC, mmc, 0)
+
+#include config_distro_bootcmd.h
+
+#define MEM_LAYOUT_ENV_SETTINGS \
+ kernel_addr_r=0x7080\0 \
+ fdt_addr_r=0x7100\0 \
+ scriptaddr=0x7080\0 \
+ pxefile_addr_r=0x7080\0 \
+ ramdisk_addr_r=0x7300\0
+
+#define CONFIG_EXTRA_ENV_SETTINGS \
+ MEM_LAYOUT_ENV_SETTINGS \
+ fdtfile=imx53-usbarmory.dtb\0 \
+ console=ttymxc0,115200\0 \
+ BOOTENV
/* Physical Memory Map */
#define CONFIG_NR_DRAM_BANKS 1
live well,
vagrant
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] power: axp209: VBUS detect
Hi Paul,
On 15-03-15 18:29, Paul Kocialkowski wrote:
Signed-off-by: Paul Kocialkowski cont...@paulk.fr
---
drivers/power/axp209.c | 13 +
include/axp209.h | 3 +++
2 files changed, 16 insertions(+)
diff --git a/drivers/power/axp209.c b/drivers/power/axp209.c
index 4565398..11fe9d7 100644
--- a/drivers/power/axp209.c
+++ b/drivers/power/axp209.c
@@ -31,6 +31,7 @@ enum axp209_reg {
};
#define AXP209_POWER_STATUS_ON_BY_DC (1 0)
+#define AXP209_POWER_STATUS_VBUS_USABLE(1 4)
#define AXP209_IRQ5_PEK_UP(1 6)
#define AXP209_IRQ5_PEK_DOWN (1 5)
@@ -249,3 +250,15 @@ int axp_gpio_set_value(unsigned int pin, unsigned int val)
{
return axp_gpio_direction_output(pin, val);
}
+
+int axp_get_vbus(void)
+{
+ u8 val;
+ int rc;
+
+ rc = axp209_read(AXP209_POWER_STATUS, val);
+ if (rc)
+ return rc;
+
+ return (val AXP209_POWER_STATUS_VBUS_USABLE) ? 1 : 0;
+}
diff --git a/include/axp209.h b/include/axp209.h
index 0436249..a007958 100644
--- a/include/axp209.h
+++ b/include/axp209.h
@@ -5,6 +5,7 @@
*/
#define AXP_GPIO
+#define AXP_VBUS_DETECT
extern int axp209_set_dcdc2(int mvolt);
extern int axp209_set_dcdc3(int mvolt);
@@ -19,3 +20,5 @@ extern int axp_gpio_direction_input(unsigned int pin);
extern int axp_gpio_direction_output(unsigned int pin, unsigned int val);
extern int axp_gpio_get_value(unsigned int pin);
extern int axp_gpio_set_value(unsigned int pin, unsigned int val);
+
+extern int axp_get_vbus(void);
Thanks for this patch and for all your other sunxi u-boot patches, unfortunately
I'm afraid that I cannot take this patch as is, this stuff with all the special
axp handling is becoming too messy IMHO.
I know I started doing things this way myself, but we need to fix this and it
is better to draw a line here, and fix things right now before they become even
more messy.
What I would like to see is to have the axp vbus detect / ctrl code changed to
simply export the axp_vbus detect as a read only gpio, and vbus ctrl as a
regular gpio.
I would like to see 2 defines added to arch/arm/include/asm/arch-sunxi/gpio.h:
#define SUNXI_GPIO_AXP_VBUS_DETECT 8
#define SUNXI_GPIO_AXP_VBUS_ENABLE 9
And then in drivers/gpio/sunxi_gpio.c: sunxi_name_to_gpio() :
if (strncasecmp(name, AXP0-, 5) == 0) {
name += 5;
if (strcmp(name, VBUS-DETECT) == 0)
return SUNXI_GPIO_AXP0_START +
SUNXI_GPIO_AXP_VBUS_DETECT;
if (strcmp(name, VBUS-ENABLE) == 0)
return SUNXI_GPIO_AXP0_START +
SUNXI_GPIO_AXP_VBUS_ENABLE;
pin = simple_strtol(name, eptr, 10);
...
}
Where the 2 if (strcmp(...) ... blocks are new.
And then in drivers/power/axp221.c add gpio functions which only handle the
vbus stuff
for now, e.g. :
int axp_gpio_direction_input(unsigned int pin)
{
switch (pin) {
case SUNXI_GPIO_AXP_VBUS_DETECT:
case SUNXI_GPIO_AXP_VBUS_ENABLE:
return 0;
default:
return -EINVAL;
}
}
int axp_gpio_direction_output(unsigned int pin, unsigned int val)
{
int ret;
switch (pin) {
case SUNXI_GPIO_AXP_VBUS_ENABLE:
/* Set N_VBUSEN pin to output / DRIVEBUS function */
ret = axp221_clrbits(AXP221_MISC_CTRL,
AXP221_MISC_CTRL_N_VBUSEN_FUNC);
if (ret)
return ret;
return axp_gpio_set_value(pin, val);
default:
return -EINVAL;
}
}
And similar additions of axp_gpio_get_value / axp_gpio_set_value
And the remove the axp handling magic (and the includes) from
drivers/usb/musb-new/sunxi.c, only leaving regular gpio calls in there.
You may not have access to an axp221 using device, that is no problem, if
you can prepare a compile-tested (build for Ippo_q8h_v1_2_defconfig) patch-set
with this cleanup then I can test it and fix it up if necessary.
And then on top of this cleanup you can add axp209 vbus detect support
extending the existing axp209 gpio functions.
Regards,
Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] sunxi: musb: Return early on VBUS GPIO error instead of on a positive value
Hi,
On 15-03-15 18:27, Paul Kocialkowski wrote:
This allows printing the error message when VBUS is detected, as it would with
AXP VBUS detect.
Signed-off-by: Paul Kocialkowski cont...@paulk.fr
---
drivers/usb/musb-new/sunxi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/musb-new/sunxi.c b/drivers/usb/musb-new/sunxi.c
index 4d8c15a..90aaec6 100644
--- a/drivers/usb/musb-new/sunxi.c
+++ b/drivers/usb/musb-new/sunxi.c
@@ -261,7 +261,7 @@ static int sunxi_musb_init(struct musb *musb)
}
err = gpio_get_value(vbus_det);
- if (err) {
+ if (err 0) {
gpio_free(vbus_det);
return -EIO;
}
Good catch, thanks I've send a pull-req with this fix upstream,
please base your next patch-set on u-boot-sunxi/master, or
at least keep this patch as a base before doing the axp gpio
cleanups I asked for in my previous mail.
Regards,
Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] sunxi: Avoid any assumption between musb gadget and host but fallback to host
Hi, On 15-03-15 18:27, Paul Kocialkowski wrote: musb might be used in gadget mode on sunxi, so we don't want to assume anything related to host mode, especially USB keyboard support. However, in case gadget mode is not explicitly used, fallback to host mode. Signed-off-by: Paul Kocialkowski cont...@paulk.fr --- board/sunxi/Kconfig| 2 +- include/configs/sunxi-common.h | 5 - 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig index 9d0eb91..0b6a492 100644 --- a/board/sunxi/Kconfig +++ b/board/sunxi/Kconfig @@ -436,7 +436,7 @@ config USB_MUSB_SUNXI config USB_KEYBOARD boolean Enable USB keyboard support - default y + default n ---help--- Say Y here to add support for using a USB keyboard (typically used in combination with a graphical console). You've just disabled the usb keyboard support pretty much everywhere, please do not do that. diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index 1f7a1cb..ffd9f5c 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -297,13 +297,16 @@ extern int soft_i2c_gpio_scl; #endif #ifdef CONFIG_USB_MUSB_SUNXI +#ifndef CONFIG_MUSB_GADGET #define CONFIG_MUSB_HOST +#endif #define CONFIG_MUSB_PIO_ONLY #endif -#if defined CONFIG_USB_EHCI || defined CONFIG_USB_MUSB_SUNXI +#if defined CONFIG_USB_EHCI || defined CONFIG_MUSB_HOST #define CONFIG_CMD_USB #define CONFIG_USB_STORAGE +#define CONFIG_USB_KEYBOARD And here you are overriding something set by Kconfig which is a big no no, if you want to disable the keyboard support on boards where you use the oth port in gadget mode jsut add: CONFIG_USB_KEYBOARD=n to the (def)config. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] u-boot: OpenRD Ultimate fails to build
It seems that OpenRD Ultimate with u-boot 2015.04-rc3 and newer no longer builds from source, both in Debian and with mainline git. It appears to have overgrown the size limits set for it: OBJCOPY u-boot.srec OBJCOPY u-boot.bin u-boot.bin exceeds file size limit: limit: 393216 bytes actual: 407068 bytes excess: 13852 bytes Makefile:834: recipe for target 'u-boot.bin' failed make: *** [u-boot.bin] Error 1 Full build log: https://buildd.debian.org/status/fetch.php?pkg=u-bootarch=armelver=2015.04~rc3%2Bdfsg1-1stamp=1425849560 If you've got an openrd_ultimate and want to ensure it keeps working in Debian (and obviously mainline)... please let me know! live well, vagrant signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Compilation under Cygwin
Hello. I am attempting to compile U-Boot under Cygwin (up to date, it's not and old version or anything) and noticed that make fails due to GCC not recognising inline modifiers to functions: scripts/kconfig/list.h:81:15: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘void’ static inline void __list_add(struct list_head *_new, ^ scripts/kconfig/list.h:99:15: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘void’ static inline void list_add_tail(struct list_head *_new, struct list_head *head) ^ scripts/kconfig/list.h:111:15: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘void’ static inline void __list_del(struct list_head *prev, struct list_head *next) ^ Amongst others. See also http://www.programdevelop.com/5356097/ for another developer who experienced the same issue. Apparenly this is caused by a system-dependent condition in /Makefile, which forces GCC to run in ANSI mode, and as inline isn't C89, compilation fails. Removing this condition does the trick. Patch attached -- Marcos Vives Del Sol https://github.com/socram miniLock: NscWdW8fh2E5SBoRtrnXWrDwmQmwaR5awMKE78tQW1Ffx cygfix.patch Description: Binary data ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] sunxi: Ainol AW1 support
Hi, On 15-03-15 18:29, Paul Kocialkowski wrote: Signed-off-by: Paul Kocialkowski cont...@paulk.fr --- board/sunxi/MAINTAINERS | 5 + configs/Ainol_AW1_defconfig | 16 2 files changed, 21 insertions(+) create mode 100644 configs/Ainol_AW1_defconfig diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS index ef3c937..e486458 100644 --- a/board/sunxi/MAINTAINERS +++ b/board/sunxi/MAINTAINERS @@ -50,6 +50,11 @@ S: Maintained F:board/sunxi/dram_a20_olinuxino_l2.c F:configs/A20-OLinuXino-Lime2_defconfig +AINOL AW1 BOARD +M: Paul Kocialkowski cont...@paulk.fr +S: Maintained +F: configs/Ainol_AW1_defconfig + AMPE A76 BOARD M:Paul Kocialkowski cont...@paulk.fr S:Maintained diff --git a/configs/Ainol_AW1_defconfig b/configs/Ainol_AW1_defconfig new file mode 100644 index 000..e37e6c8 --- /dev/null +++ b/configs/Ainol_AW1_defconfig @@ -0,0 +1,16 @@ +CONFIG_SPL=y +CONFIG_SYS_EXTRA_OPTIONS=AXP209_POWER +CONFIG_FDTFILE=sun7i-a20-ainol-aw1.dtb +CONFIG_USB_MUSB_SUNXI=y +CONFIG_USB0_VBUS_PIN=PB9 +CONFIG_USB0_VBUS_DET=axp_vbus_detect +CONFIG_VIDEO_LCD_MODE=x:800,y:480,depth:18,pclk_khz:4,le:87,ri:112,up:38,lo:141,hs:1,vs:1,sync:3,vmode:0 +CONFIG_VIDEO_LCD_POWER=PH8 +CONFIG_VIDEO_LCD_BL_EN=PH7 +CONFIG_VIDEO_LCD_BL_PWM=PB2 ++S:CONFIG_ARM=y ++S:CONFIG_ARCH_SUNXI=y ++S:CONFIG_MACH_SUN7I=y ++S:CONFIG_DRAM_CLK=432 ++S:CONFIG_DRAM_ZQ=123 ++S:CONFIG_DRAM_EMR1=4 Thanks for the patch, looks good, but needs adjustment for the discussed changes to treat axp vbus-detect / vbus-enable as regular gpios. Also we no longer use the +S: magic in defconfig files as there now is a single .config for both the SPL and regular u-boot builds, so when you resubmit together with the axp cleanups, please remove the +S: prefixes. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-sunxi master
Hi Tom, Please pull u-boot-sunxi/master into master for a small bugfix which makes sure we print the right error message when a non host cable is plugged into the otg and we're configured for host mode. The following changes since commit 21866c34a1b4098a8868c9250daf01baf84c2397: at91sam9rlek_mmc_defconfig: Add CONFIG_ARCH_AT91=y (2015-03-20 10:47:38 -0400) are available in the git repository at: http://git.denx.de/u-boot-sunxi.git master for you to fetch changes up to 8a440b09f21ab8ec72b3aedf4d6f3f53494d7149: sunxi: musb: Return early on VBUS GPIO error instead of on a positive value (2015-03-21 13:51:27 +0100) Paul Kocialkowski (1): sunxi: musb: Return early on VBUS GPIO error instead of on a positive value drivers/usb/musb-new/sunxi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [PATCH] sun6i: Add support for the Mixtile LOFT-Q board
Hi, On 12-03-15 04:13, Phil Han wrote: From: Han Pengfei pengp...@sina.com The Mixtile LOFT-Q is an A31 based board with 2G RAM, 8G EMMC, sdio wifi, 1Gbit ethernet, HDMI display, toslink audio plug, 4 USB2.0 port, external USB2SATA connector, sd card plug, 3x60 external fpic expansion connector, NXP JN5168 zigbee gw, remote support. Also see http://focalcrest.com/en/pc.html#pro02 Signed-off-by: Han Pengfei pengp...@sina.com Thanks I've queued this up in u-boot-sunxi/next for merging upstream. Regards, Hans --- board/sunxi/MAINTAINERS | 5 + configs/mixtile_loftq_defconfig | 16 2 files changed, 21 insertions(+) create mode 100644 configs/mixtile_loftq_defconfig diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS index ef3c937..90a634e 100644 --- a/board/sunxi/MAINTAINERS +++ b/board/sunxi/MAINTAINERS @@ -143,3 +143,8 @@ WEXLER-TAB7200 BOARD M:Aleksei Mamlin mamli...@gmail.com S:Maintained F:configs/Wexler_TAB7200_defconfig + +MIXTILE-LOFTQ BOARD +M: Phil Han pengp...@sina.com +S: Maintained +F: configs/mixtile_loftq_defconfig diff --git a/configs/mixtile_loftq_defconfig b/configs/mixtile_loftq_defconfig new file mode 100644 index 000..94ebdc8 --- /dev/null +++ b/configs/mixtile_loftq_defconfig @@ -0,0 +1,16 @@ +CONFIG_SPL=y +CONFIG_SYS_EXTRA_OPTIONS=USB_EHCI,SUNXI_GMAC,RGMII,MACPWR=SUNXI_GPA(21) ++S:CONFIG_ARM=y ++S:CONFIG_ARCH_SUNXI=y ++S:CONFIG_MACH_SUN6I=y ++S:CONFIG_TARGET_MIXTILE_LOFTQ=y ++S:CONFIG_DRAM_CLK=312 ++S:CONFIG_DRAM_ZQ=251 ++S:CONFIG_MMC_SUNXI_SLOT=0 ++S:CONFIG_MMC_SUNXI_SLOT_EXTRA=2 +# Wifi power ++S:CONFIG_AXP221_ALDO1_VOLT=3300 +# Vbus gpio for usb1 ++S:CONFIG_USB1_VBUS_PIN=PH24 +# No Vbus gpio for usb2 ++S:CONFIG_USB2_VBUS_PIN= ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 01/14] sun7i: Remove duplicate call to psci_arch_init
Hi, On 11-03-15 16:11, Tom Rini wrote: On Mon, Mar 09, 2015 at 08:00:11AM +0100, Jan Kiszka wrote: This is already invoked a few cycles later in monitor mode by _secure_monitor. Drop it here, it serves no purpose. For clarity, because of the vector tables? Reviewed-by: Tom Rini tr...@konsulko.com I've just given this a test run on an A20 board and everything psci related still works fine, so: Tested-by: Hans de Goede hdego...@redhat.com Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2] Document config_distro_bootcmd environment variables for interactive booting.
Changes since V1: - Explicitly define the target format for storage and network targets - Include a list of all valid bootcmd targets which are currently supported - Make the commit log more verbose Karsten Merker (1): Document config_distro_bootcmd environment variables for interactive booting. doc/README.distro | 47 +++ 1 file changed, 47 insertions(+) -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] sunxi: common VBUS detection logic in usbc
Hi, On 15-03-15 18:27, Paul Kocialkowski wrote: VBUS detection could be needed not only by the musb code (to prevent host mode), but also by e.g. gadget drivers to start only when a cable is connected. In addition, this allows more flexibility in vbus detection, as it could easily be extended to other USBC indexes. Eventually, this would help making musb support independent from a hardcoded USB controller index (0). Signed-off-by: Paul Kocialkowski cont...@paulk.fr Thanks for working on this, please respin this and the next patch once the axp vbus detect / enable cleanups have been done. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2] Document config_distro_bootcmd environment variables for interactive booting.
config_distro_bootcmd.h defines a common boot environment for multiple platforms, including several environment variables that are intended for interactive use by an end-user. Document which variables are considered public interfaces that must remain compatible in future u-boot versions. Signed-off-by: Karsten Merker mer...@debian.org --- doc/README.distro | 47 +++ 1 file changed, 47 insertions(+) diff --git a/doc/README.distro b/doc/README.distro index dd0f1c7..0308a4c 100644 --- a/doc/README.distro +++ b/doc/README.distro @@ -1,6 +1,7 @@ /* * (C) Copyright 2014 Red Hat Inc. * Copyright (c) 2014-2015, NVIDIA CORPORATION. All rights reserved. + * Copyright (C) 2015 K. Merker mer...@debian.org * * SPDX-License-Identifier: GPL-2.0+ */ @@ -339,3 +340,49 @@ scan_dev_for_scripts: If you want to disable boot.scr on all disks, set the value to something innocuous, e.g. setenv scan_dev_for_scripts true. + + +Interactively booting from a specific device at the u-boot prompt += + +For interactively booting from a user-selected device at the u-boot command +prompt, the environment provides predefined bootcmd_target variables for +every target defined in boot_targets, which can be run be the user. + +If the target is a storage device, the format of the target is always +device typedevice number, e.g. mmc0. Specifying the device number is +mandatory for storage devices, even if only support for a single instance +of the storage device is actually implemented. + +For network targets (dhcp, pxe), only the device type gets specified; +they do not have a device number. + +Examples: + + - run bootcmd_usb0 + boots from the first USB mass storage device + + - run bootcmd_mmc1 + boots from the second MMC device + + - run bootcmd_pxe + boots by tftp using a pxelinux.cfg + +The list of possible targets consists of: + +- network targets + * dhcp + * pxe + +- storage targets (to which a device number must be appended) + * mmc + * sata + * scsi + * ide + * usb + +Other *boot* variables than the ones defined above are only for internal use +of the boot environment and are not guaranteed to exist or work in the same +way in future u-boot versions. In particular the device type_boot +variables (e.g. mmc_boot, usb_boot) are a strictly internal implementation +detail and must not be used as a public interface. -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 24/28] armv8/ls2085aqds: NAND boot support
On Fri, 2015-03-20 at 14:44 -0700, York Sun wrote: On 03/20/2015 02:33 PM, Scott Wood wrote: On Fri, 2015-03-20 at 14:23 -0700, York Sun wrote: On 03/20/2015 02:15 PM, Scott Wood wrote: On Fri, 2015-03-20 at 12:21 -0700, York Sun wrote: From: Scott Wood scottw...@freescale.com This adds NAND boot support for LS2085AQDS, using SPL framework. To form a NAND image, append u-boot-with-spl.bin after a proper nand boot RCW and flash to the beginning of NAND. Do we want to do it this way, or should we keep the RCW in a separate block? I would like to see RCW in a separated block. OK. In that case the offsets in this patch will need to change. What constitutes a proper nand boot RCW (those were not my words)? There are details in this patch regarding offsets that need to match details in the PBI (which is more than just RCW). It is not your original words. Yours was To form a NAND image, append u-boot-with-spl.bin after PBL_0x3_0x07_1333_nand.bin and flash to the beginning of NAND.. I try to make the message generic. A proper nand boot RCW means the RCW should contains PBI commands to set bootloc and block copy the image. Since RCW is not in the scope of u-boot, I cannot refer to any specific file. Yes, I know you can't refer to the file, but it needs to be made clear what the expectations of that PBI file are. I think a proper solution would be to put detail instruction into board README file by adding To form the NAND image, append u-boot-with-spl.bin after RCW image. The RCW image should have these PBI commands CCSR 4-byte write to 0x00e00404, data=0x CCSR 4-byte write to 0x00e00400, data=0x1800a000 Block Copy: SRC=0x0104, SRC_ADDR=0x00c0, DEST_ADDR=0x1800a000, BLOCK_SIZE=0x00014000 We need to revise the SRS_ADDR if moving u-boot to a separated block. Please advise what address is appropriate. It should be equal to the NAND block size (not to be confused with PBI block copy size). Please also advise the BLOCK_SIZE. Does it need to be fixed, or min(0x14000, sizeof(u-boot-spl.bin))? It should be fixed because we don't want it to have to be updated every time the SPL build changes. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Rework the network stack
Hi Jörg, On Sat, Mar 21, 2015 at 3:33 AM, Jörg Krause joerg.krause@embedded.rocks wrote: Hi all, there is an issue with the current network stack using netconsole. It's impossible to use network commands as TFTP inside netconsole, because they try to run as atomic network commands. The issue was already reported by Stefano Babic in 2010: [U-Boot] NetConsole and network API http://lists.denx.de/pipermail/u-boot/2010-August/075535.html I worked around this problem here: http://lists.denx.de/pipermail/u-boot/2012-August/129913.html I run into the same problem: [U-Boot] netconsole: USB Ethernet connection dropping with ping or tftpboot http://lists.denx.de/pipermail/u-boot/2015-February/203838.html I didn't understand what about your case was not able to work given the workaround I implemented previously. What was different about it? I have looked at the current network stack. The stack is based on the concept of atomic network commands. The implementation for netconsole looks very confusing. There is no doubt that netconsole is quite confusing as it exists today. Sascha Hauer has reimplemented the network stack for Barebox: http://www.spinics.net/lists/u-boot-v2/msg00914.html Looking at the current implementation of net.c looks very clean and well-designed. Thanks for pointing this out. I hadn't gone to look at the network stack in barebox. What do you think about porting this to U-Boot? I can look into this. Naturally there are many other changes to u-boot network stack since the time barebox forked, so I expect such a port to be very intensive... most likely a near complete rewrite of Sascha's series, but I will investigate further. Cheers, -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 09/27] net: Remove the bd* parameter from net stack functions
Hi Simon, On Fri, Mar 20, 2015 at 6:01 PM, Simon Glass s...@chromium.org wrote: Hi Joe, On 11 March 2015 at 17:44, Joe Hershberger joe.hershber...@ni.com wrote: This value is not used by the network stack and is available in the global data, so stop passing it around. For the one legacy function that still expects it (init op on old Ethernet drivers) pass in the global pointer version directly to avoid changing that interface. Signed-off-by: Joe Hershberger joe.hershber...@ni.com Reported-by: Simon Glass s...@chromium.org Reviewed-by: Simon Glass s...@chromium.org --- Changes in v6: -Fix compile errors for other boards due to removed parameters Unfortunately this causes several build failures: 38: net: Remove the bd* parameter from net stack functions powerpc: + PLU405 PMC440 sc3 neo acadia csb472 devconcenter sequoia arches lwmon5 t3corp walnut PMC405DE redwood katmai gdppc440etx p3p440 sycamore MIP405 zeus rainier_ramboot canyonlands MIP405T haleakala dlvision csb272 xpedite1000 io yosemite yucca makalu sequoia_ramboot dlvision-10g pcs440ep CPCI4052 sbc405 iocon ebony glacier_ramboot VOM405 bamboo luan io64 PIP405 intip glacier lcd4_lwmon5 bubinga yellowstone icon kilauea rainier e.g: $ buildman -b dm-push -s PLU405 -e ... 38: net: Remove the bd* parameter from net stack functions powerpc: + PLU405 +../drivers/net/4xx_enet.c: In function 'mal_err': +../drivers/net/4xx_enet.c:1734:2: error: too many arguments to function 'eth_init' +../include/net.h:169:5: note: declared here +make[2]: *** [drivers/net/4xx_enet.o] Error 1 +make[1]: *** [drivers/net] Error 2 +make: *** [sub-make] Error 2 ... Can you please check this and respin? Sorry about that. Are you aware of anything other than the 4xx_enet.c error? I grepped around and didn't find anything else, but I also missed this one previously using the same method. Thanks, -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
