[U-Boot] [PATCH 4/4] mmc: tegra2: Implement card-detect hook.
On Tegra2, card-detection is implemented by passing the card-detection
GPIOs to the MMC driver at initialization time. Instead of implementing
the board_mmc_getcd() function, use the card-detect hook and allow
boards to override it by providing their own board_mmc_getcd()
implementation.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
drivers/mmc/tegra2_mmc.c | 28 +---
1 files changed, 13 insertions(+), 15 deletions(-)
diff --git a/drivers/mmc/tegra2_mmc.c b/drivers/mmc/tegra2_mmc.c
index fe562ed..5b4c9f6 100644
--- a/drivers/mmc/tegra2_mmc.c
+++ b/drivers/mmc/tegra2_mmc.c
@@ -474,6 +474,18 @@ static int mmc_core_init(struct mmc *mmc)
return 0;
}
+int tegra2_mmc_getcd(struct mmc *mmc)
+{
+ struct mmc_host *host = (struct mmc_host *)mmc-priv;
+
+ debug(tegra2_mmc_getcd called\n);
+
+ if (host-cd_gpio = 0)
+ return !gpio_get_value(host-cd_gpio);
+
+ return 1;
+}
+
int tegra2_mmc_init(int dev_index, int bus_width, int pwr_gpio, int cd_gpio)
{
struct mmc_host *host;
@@ -512,6 +524,7 @@ int tegra2_mmc_init(int dev_index, int bus_width, int
pwr_gpio, int cd_gpio)
mmc-send_cmd = mmc_send_cmd;
mmc-set_ios = mmc_set_ios;
mmc-init = mmc_core_init;
+ mmc-getcd = tegra2_mmc_getcd;
mmc-voltages = MMC_VDD_32_33 | MMC_VDD_33_34 | MMC_VDD_165_195;
if (bus_width == 8)
@@ -535,18 +548,3 @@ int tegra2_mmc_init(int dev_index, int bus_width, int
pwr_gpio, int cd_gpio)
return 0;
}
-
-/* this is a weak define that we are overriding */
-int board_mmc_getcd(u8 *cd, struct mmc *mmc)
-{
- struct mmc_host *host = (struct mmc_host *)mmc-priv;
-
- debug(board_mmc_getcd called\n);
-
- if (host-cd_gpio = 0)
- *cd = !gpio_get_value(host-cd_gpio);
- else
- *cd = 1;
-
- return 0;
-}
--
1.7.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] mmc: Change board_mmc_getcd() signature.
The new API no longer uses the extra cd parameter that was used to store
the card presence state. Instead, this information is returned via the
function's return value. board_mmc_getcd() returns -1 to indicate that
no card-detection mechanism is implemented; 0 indicates that no card is
present and 1 is returned if it was detected that a card is present.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
board/efikamx/efikamx.c |8 +++-
board/emk/top9000/top9000.c | 12 ++--
board/freescale/mx51evk/mx51evk.c |8 +++-
board/freescale/mx53ard/mx53ard.c |8 +++-
board/freescale/mx53evk/mx53evk.c |8 +++-
board/freescale/mx53loco/mx53loco.c |8 +++-
board/freescale/mx53smd/mx53smd.c |6 ++
doc/README.atmel_mci| 12 ++--
drivers/mmc/fsl_esdhc.c |8 +---
drivers/mmc/mmc.c |4 ++--
include/mmc.h |2 +-
11 files changed, 29 insertions(+), 55 deletions(-)
diff --git a/board/efikamx/efikamx.c b/board/efikamx/efikamx.c
index b78bf6c..451d709 100644
--- a/board/efikamx/efikamx.c
+++ b/board/efikamx/efikamx.c
@@ -309,17 +309,15 @@ static inline uint32_t efika_mmc_cd(void)
return MX51_PIN_EIM_CS2;
}
-int board_mmc_getcd(u8 *absent, struct mmc *mmc)
+int board_mmc_getcd(struct mmc *mmc)
{
struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc-priv;
uint32_t cd = efika_mmc_cd();
if (cfg-esdhc_base == MMC_SDHC1_BASE_ADDR)
- *absent = gpio_get_value(IOMUX_TO_GPIO(cd));
- else
- *absent = gpio_get_value(IOMUX_TO_GPIO(MX51_PIN_GPIO1_8));
+ return !gpio_get_value(IOMUX_TO_GPIO(cd));
- return 0;
+ return !gpio_get_value(IOMUX_TO_GPIO(MX51_PIN_GPIO1_8));
}
int board_mmc_init(bd_t *bis)
diff --git a/board/emk/top9000/top9000.c b/board/emk/top9000/top9000.c
index 61dee62..d156e32 100644
--- a/board/emk/top9000/top9000.c
+++ b/board/emk/top9000/top9000.c
@@ -108,17 +108,9 @@ int board_mmc_init(bd_t *bd)
}
/* this is a weak define that we are overriding */
-int board_mmc_getcd(u8 *cd, struct mmc *mmc)
+int board_mmc_getcd(struct mmc *mmc)
{
- /*
-* the only currently existing use of this function
-* (fsl_esdhc.c) suggests this function must return
-* *cs = TRUE if a card is NOT detected - in most
-* cases the value of the pin when the detect switch
-* closes to GND
-*/
- *cd = at91_get_gpio_value(CONFIG_SYS_MMC_CD_PIN) ? 1 : 0;
- return 0;
+ return !at91_get_gpio_value(CONFIG_SYS_MMC_CD_PIN);
}
#endif
diff --git a/board/freescale/mx51evk/mx51evk.c
b/board/freescale/mx51evk/mx51evk.c
index 37e6e4d..bc03496 100644
--- a/board/freescale/mx51evk/mx51evk.c
+++ b/board/freescale/mx51evk/mx51evk.c
@@ -261,16 +261,14 @@ static void power_init(void)
}
#ifdef CONFIG_FSL_ESDHC
-int board_mmc_getcd(u8 *cd, struct mmc *mmc)
+int board_mmc_getcd(struct mmc *mmc)
{
struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc-priv;
if (cfg-esdhc_base == MMC_SDHC1_BASE_ADDR)
- *cd = gpio_get_value(0);
- else
- *cd = gpio_get_value(6);
+ return !gpio_get_value(0);
- return 0;
+ return !gpio_get_value(6);
}
int board_mmc_init(bd_t *bis)
diff --git a/board/freescale/mx53ard/mx53ard.c
b/board/freescale/mx53ard/mx53ard.c
index be32aee..786770a 100644
--- a/board/freescale/mx53ard/mx53ard.c
+++ b/board/freescale/mx53ard/mx53ard.c
@@ -83,16 +83,14 @@ struct fsl_esdhc_cfg esdhc_cfg[2] = {
{MMC_SDHC2_BASE_ADDR, 1 },
};
-int board_mmc_getcd(u8 *cd, struct mmc *mmc)
+int board_mmc_getcd(struct mmc *mmc)
{
struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc-priv;
if (cfg-esdhc_base == MMC_SDHC1_BASE_ADDR)
- *cd = gpio_get_value(1); /*GPIO1_1*/
- else
- *cd = gpio_get_value(4); /*GPIO1_4*/
+ return !gpio_get_value(1); /*GPIO1_1*/
- return 0;
+ return !gpio_get_value(4); /*GPIO1_4*/
}
int board_mmc_init(bd_t *bis)
diff --git a/board/freescale/mx53evk/mx53evk.c
b/board/freescale/mx53evk/mx53evk.c
index 335661f..a4cd983 100644
--- a/board/freescale/mx53evk/mx53evk.c
+++ b/board/freescale/mx53evk/mx53evk.c
@@ -208,16 +208,14 @@ struct fsl_esdhc_cfg esdhc_cfg[2] = {
{MMC_SDHC3_BASE_ADDR, 1},
};
-int board_mmc_getcd(u8 *cd, struct mmc *mmc)
+int board_mmc_getcd(struct mmc *mmc)
{
struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc-priv;
if (cfg-esdhc_base == MMC_SDHC1_BASE_ADDR)
- *cd = gpio_get_value(77); /*GPIO3_13*/
- else
- *cd = gpio_get_value(75); /*GPIO3_11*/
+ return !gpio_get_value(77); /*GPIO3_13*/
- return 0;
+ return !gpio_get_value(75); /*GPIO3_11*/
}
int board_mmc_init(bd_t *bis)
diff
[U-Boot] [PATCH 2/4] mmc: Implement card detection.
Check for card detect each time an MMC/SD device is initialized. If card
detection is not implemented, this code behaves as before and continues
assuming a card is present. If no card is detected, has_init is reset
for the MMC/SD device (to force initialization next time) and an error
is returned.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
drivers/mmc/arm_pl180_mmci.c |1 +
drivers/mmc/bfin_sdh.c |1 +
drivers/mmc/davinci_mmc.c|1 +
drivers/mmc/ftsdc010_esdhc.c |1 +
drivers/mmc/gen_atmel_mci.c |1 +
drivers/mmc/mmc.c| 18 ++
drivers/mmc/mmc_spi.c|1 +
drivers/mmc/mxcmmc.c |1 +
drivers/mmc/mxsmmc.c |1 +
drivers/mmc/omap_hsmmc.c |1 +
drivers/mmc/pxa_mmc_gen.c|1 +
drivers/mmc/s5p_mmc.c|1 +
drivers/mmc/sdhci.c |1 +
drivers/mmc/sh_mmcif.c |1 +
include/mmc.h|2 ++
15 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/arm_pl180_mmci.c b/drivers/mmc/arm_pl180_mmci.c
index e6467a2..09d443e 100644
--- a/drivers/mmc/arm_pl180_mmci.c
+++ b/drivers/mmc/arm_pl180_mmci.c
@@ -385,6 +385,7 @@ static int arm_pl180_mmci_host_init(struct mmc *dev)
dev-send_cmd = host_request;
dev-set_ios = host_set_ios;
dev-init = mmc_host_reset;
+ dev-getcd = NULL;
dev-host_caps = 0;
dev-voltages = VOLTAGE_WINDOW_MMC;
dev-f_min = dev-clock;
diff --git a/drivers/mmc/bfin_sdh.c b/drivers/mmc/bfin_sdh.c
index bc9057f..08fc5c1 100644
--- a/drivers/mmc/bfin_sdh.c
+++ b/drivers/mmc/bfin_sdh.c
@@ -250,6 +250,7 @@ int bfin_mmc_init(bd_t *bis)
mmc-send_cmd = bfin_sdh_request;
mmc-set_ios = bfin_sdh_set_ios;
mmc-init = bfin_sdh_init;
+ mmc-getcd = NULL;
mmc-host_caps = MMC_MODE_4BIT;
mmc-voltages = MMC_VDD_32_33 | MMC_VDD_33_34;
diff --git a/drivers/mmc/davinci_mmc.c b/drivers/mmc/davinci_mmc.c
index ce96736..ee8f261 100644
--- a/drivers/mmc/davinci_mmc.c
+++ b/drivers/mmc/davinci_mmc.c
@@ -387,6 +387,7 @@ int davinci_mmc_init(bd_t *bis, struct davinci_mmc *host)
mmc-send_cmd = dmmc_send_cmd;
mmc-set_ios = dmmc_set_ios;
mmc-init = dmmc_init;
+ mmc-getcd = NULL;
mmc-f_min = 20;
mmc-f_max = 2500;
diff --git a/drivers/mmc/ftsdc010_esdhc.c b/drivers/mmc/ftsdc010_esdhc.c
index e38dd87..0eb7196 100644
--- a/drivers/mmc/ftsdc010_esdhc.c
+++ b/drivers/mmc/ftsdc010_esdhc.c
@@ -645,6 +645,7 @@ int ftsdc010_mmc_init(int dev_index)
mmc-send_cmd = ftsdc010_request;
mmc-set_ios = ftsdc010_set_ios;
mmc-init = ftsdc010_core_init;
+ mmc-getcd = NULL;
mmc-voltages = MMC_VDD_32_33 | MMC_VDD_33_34;
diff --git a/drivers/mmc/gen_atmel_mci.c b/drivers/mmc/gen_atmel_mci.c
index f346b24..4968c5e 100644
--- a/drivers/mmc/gen_atmel_mci.c
+++ b/drivers/mmc/gen_atmel_mci.c
@@ -337,6 +337,7 @@ int atmel_mci_init(void *regs)
mmc-send_cmd = mci_send_cmd;
mmc-set_ios = mci_set_ios;
mmc-init = mci_init;
+ mmc-getcd = NULL;
/* need to be able to pass these in on a board by board basis */
mmc-voltages = MMC_VDD_32_33 | MMC_VDD_33_34;
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 936259f..cf06d05 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -674,6 +674,18 @@ int mmc_switch_part(int dev_num, unsigned int part_num)
| (part_num PART_ACCESS_MASK));
}
+int mmc_getcd(struct mmc *mmc)
+{
+ int cd;
+
+ cd = board_mmc_getcd(mmc);
+
+ if ((cd 0) mmc-getcd)
+ cd = mmc-getcd(mmc);
+
+ return cd;
+}
+
int sd_switch(struct mmc *mmc, int mode, int group, u8 value, u8 *resp)
{
struct mmc_cmd cmd;
@@ -1192,6 +1204,12 @@ int mmc_init(struct mmc *mmc)
{
int err, retry = 3;
+ if (mmc_getcd(mmc) == 0) {
+ mmc-has_init = 0;
+ printf(MMC: no card present\n);
+ return NO_CARD_ERR;
+ }
+
if (mmc-has_init)
return 0;
diff --git a/drivers/mmc/mmc_spi.c b/drivers/mmc/mmc_spi.c
index 49fb9e0..de43a85 100644
--- a/drivers/mmc/mmc_spi.c
+++ b/drivers/mmc/mmc_spi.c
@@ -272,6 +272,7 @@ struct mmc *mmc_spi_init(uint bus, uint cs, uint speed,
uint mode)
mmc-send_cmd = mmc_spi_request;
mmc-set_ios = mmc_spi_set_ios;
mmc-init = mmc_spi_init_p;
+ mmc-getcd = NULL;
mmc-host_caps = MMC_MODE_SPI;
mmc-voltages = MMC_SPI_VOLTAGE;
diff --git a/drivers/mmc/mxcmmc.c b/drivers/mmc/mxcmmc.c
index ab1fc82..8afb221 100644
--- a/drivers/mmc/mxcmmc.c
+++ b/drivers/mmc/mxcmmc.c
@@ -500,6 +500,7 @@ static int mxcmci_initialize(bd_t *bis)
mmc-send_cmd = mxcmci_request;
mmc-set_ios = mxcmci_set_ios;
mmc-init = mxcmci_init;
+ mmc-getcd = NULL;
mmc-host_caps = MMC_MODE_4BIT;
host-base = (struct
[U-Boot] [PATCH 3/4] mmc: fsl_esdhc: Implement card-detect hook.
This card-detect hook probably doesn't work. Perhaps somebody with more
knowledge about the hardware can comment on this. I think that perhaps
even the complete code from esdhc_init() could go into the getcd()
function instead or mmc_getcd() needs to be called at some later time
after mmc_init(), which, however, would require many other drivers to
change.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
drivers/mmc/fsl_esdhc.c | 29 -
1 files changed, 12 insertions(+), 17 deletions(-)
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index f719afd..b46bf9f 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -412,7 +412,6 @@ static int esdhc_init(struct mmc *mmc)
struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc-priv;
struct fsl_esdhc *regs = (struct fsl_esdhc *)cfg-esdhc_base;
int timeout = 1000;
- int ret = 0;
/* Reset the entire host controller */
esdhc_write32(regs-sysctl, SYSCTL_RSTA);
@@ -439,24 +438,19 @@ static int esdhc_init(struct mmc *mmc)
/* Set timout to the maximum value */
esdhc_clrsetbits32(regs-sysctl, SYSCTL_TIMEOUT_MASK, 14 16);
- /* Check if there is a callback for detecting the card */
- ret = board_mmc_getcd(mmc);
- if (ret 0) {
- timeout = 1000;
- while (!(esdhc_read32(regs-prsstat) PRSSTAT_CINS)
- --timeout)
- udelay(1000);
+ return 0;
+}
- if (timeout = 0)
- ret = NO_CARD_ERR;
- } else {
- if (ret == 0)
- ret = NO_CARD_ERR;
- else
- ret = 0;
- }
+static int esdhc_getcd(struct mmc *mmc)
+{
+ struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc-priv;
+ struct fsl_esdhc *regs = (struct fsl_esdhc *)cfg-esdhc_base;
+ int timeout = 1000;
+
+ while (!(esdhc_read32(regs-prsstat) PRSSTAT_CINS) --timeout)
+ udelay(1000);
- return ret;
+ return timeout 0;
}
static void esdhc_reset(struct fsl_esdhc *regs)
@@ -494,6 +488,7 @@ int fsl_esdhc_initialize(bd_t *bis, struct fsl_esdhc_cfg
*cfg)
mmc-send_cmd = esdhc_send_cmd;
mmc-set_ios = esdhc_set_ios;
mmc-init = esdhc_init;
+ mmc-getcd = esdhc_getcd;
voltage_caps = 0;
caps = regs-hostcapblt;
--
1.7.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v7] Add generic ULPI layer
Although it is a single patch, I felt that a cover letter will
definetly not hurt here, also the patch version history is so big, so
I decided to move it here.
The ULPI (UTMI Low Pin (count) Interface) PHYs are widely used on
variety of boards. This requires a generic architecture independant
implementation which can be reused and will eliminate the need for
direct write of arbitrary values to the ULPI transciever.
Although, the generic implementation can be reused on any architecture,
the access to ULPI PHY must be done in a platform specific way.
The platform specific way is in majority of case called a viewport.
Also, the ULPI specification defines a hybrid aproach for managing the
ULPI PHY. That is, the PHY must be managed through both the PHY registers
and control lines.
The proposed patch provides a partial implementation of the ULPI
specification, which should be enough for boot loader use cases,
and a viewport implementation for Chipidea/ARC based controllers,
which, AFAIK, are used on imx and tegra SoCs.
It is based on the Wolfgang's master branch (4 Dec 2012),
compile tested and checkpatch clean.
What is still missing, IMO:
- documentation for the CONFIG_* macros (I can add it in a separate
patch)
- a way to make most of the initialization in one ulpi_init() call
- viewport extension to be able to implement resume,
reset and disabling the serial mode
The change log:
Changes for v2:
- make code EHCI-independent
- use udelay() in waiting loop
- mark static functions as static
- naming changes
Changes for v3:
- merge with patch ulpi: add generic ULPI support header file
- rewrite ULPI interface in more functionality-oriented way
Changes for v4:
- add error-checking
- add waiting for completion into ulpi_reset() function
Changes for v5:
- CodingStyle changes
- add comments
- simplify implemenation of the ULPI interface functions
Changes for v6:
- cleanup function ulpi_drive_vbus()
Changes for v7:
- ulpi-viewport.c:
- reorder bit definitions
- split ulpi_request() to two functions
- reuse ulpi_wakeup() from ulpi_request()
to remove duplicated calls from ulpi_{read|write}()
- inline ulpi_*_mask as it is simple and used only once
- ulpi.c:
- move several defines into c file
- rework all the functions to propagate error values
- move function description comments into ulpi.h
along with declarations
- check arguments validity (as suggested by Simon)
- fix cases when using the *_set register,
bits cannot be cleared
- shorten several arguments names (e.g. ulpi_set_vbus())
- add ability to disable VBUS
- clean up ulpi_set_pd()
- add ability to enter the serial mode
- add verbosity in error cases
- remove ulpi_resume() as it were wrong and
must be implemented in a viewport specific way
- rework ulpi_reset() as it must be implemented in a
viewport specific way, but provide kind of generic
implementation which should work in most of the cases
- ulpi.h:
- add default timeout value
- remove unused defines
- move several defines inside c files
- add description for each function
- move the API declaration to the top of the header file
Jana Rapava (1):
USB: Add generic ULPI layer and a viewport
Makefile |1 +
drivers/usb/ulpi/Makefile| 44 ++
drivers/usb/ulpi/ulpi-viewport.c | 118 +++
drivers/usb/ulpi/ulpi.c | 227 +
include/usb/ulpi.h | 298 ++
5 files changed, 688 insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/ulpi/Makefile
create mode 100644 drivers/usb/ulpi/ulpi-viewport.c
create mode 100644 drivers/usb/ulpi/ulpi.c
create mode 100644 include/usb/ulpi.h
--
1.7.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v7] USB: Add generic ULPI layer and a viewport
From: Jana Rapava ferma...@gmail.com
Add partial ULPI specification implementation that should be enough to
interface the ULPI PHYs in the boot loader context.
Add a viewport implementation for Chipidea/ARC based controllers.
Signed-off-by: Jana Rapava ferma...@gmail.com
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
Cc: Remy Bohmer li...@bohmer.net
Cc: Stefano Babic sba...@denx.de
Cc: Wolfgang Grandegger w...@denx.de
Cc: Simon Glass s...@chromium.org
---
Makefile |1 +
drivers/usb/ulpi/Makefile| 44 ++
drivers/usb/ulpi/ulpi-viewport.c | 118 +++
drivers/usb/ulpi/ulpi.c | 227 +
include/usb/ulpi.h | 298 ++
5 files changed, 688 insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/ulpi/Makefile
create mode 100644 drivers/usb/ulpi/ulpi-viewport.c
create mode 100644 drivers/usb/ulpi/ulpi.c
create mode 100644 include/usb/ulpi.h
diff --git a/Makefile b/Makefile
index d84b350..ab7a269 100644
--- a/Makefile
+++ b/Makefile
@@ -283,6 +283,7 @@ LIBS += drivers/usb/gadget/libusb_gadget.o
LIBS += drivers/usb/host/libusb_host.o
LIBS += drivers/usb/musb/libusb_musb.o
LIBS += drivers/usb/phy/libusb_phy.o
+LIBS += drivers/usb/ulpi/libusb_ulpi.o
LIBS += drivers/video/libvideo.o
LIBS += drivers/watchdog/libwatchdog.o
LIBS += common/libcommon.o
diff --git a/drivers/usb/ulpi/Makefile b/drivers/usb/ulpi/Makefile
new file mode 100644
index 000..d43b229
--- /dev/null
+++ b/drivers/usb/ulpi/Makefile
@@ -0,0 +1,44 @@
+#
+# Copyright (C) 2011 Jana Rapava ferma...@gmail.com
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc.
+#
+
+include $(TOPDIR)/config.mk
+
+LIB:= $(obj)libusb_ulpi.o
+
+COBJS-$(CONFIG_USB_ULPI) += ulpi.o
+COBJS-$(CONFIG_USB_ULPI_VIEWPORT) += ulpi-viewport.o
+
+COBJS := $(COBJS-y)
+SRCS := $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+
+all: $(LIB)
+
+$(LIB):$(obj).depend $(OBJS)
+ $(call cmd_link_o_target, $(OBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/drivers/usb/ulpi/ulpi-viewport.c b/drivers/usb/ulpi/ulpi-viewport.c
new file mode 100644
index 000..fa2e004
--- /dev/null
+++ b/drivers/usb/ulpi/ulpi-viewport.c
@@ -0,0 +1,118 @@
+/*
+ * Copyright (C) 2011 Jana Rapava ferma...@gmail.com
+ * Copyright (C) 2011 CompuLab, Ltd. www.compulab.co.il
+ *
+ * Authors: Jana Rapava ferma...@gmail.com
+ * Igor Grinberg grinb...@compulab.co.il
+ *
+ * Based on:
+ * linux/drivers/usb/otg/ulpi_viewport.c
+ *
+ * Original Copyright follow:
+ * Copyright (C) 2011 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include common.h
+#include asm/io.h
+#include usb/ulpi.h
+
+/* ULPI viewport control bits */
+#define ULPI_SS(1 27)
+#define ULPI_RWCTRL(1 29)
+#define ULPI_RWRUN (1 30)
+#define ULPI_WU(1 31)
+
+/*
+ * Wait for the ULPI request to complete
+ *
+ * @ulpi_viewport - the address of the viewport
+ * @mask - expected value to wait for
+ *
+ * returns 0 on mask match, ULPI_ERROR on time out.
+ */
+static int ulpi_wait(u32 ulpi_viewport, u32 mask)
+{
+ int timeout = CONFIG_USB_ULPI_TIMEOUT;
+
+ /* Wait for the bits in mask to become zero. */
+ while (--timeout) {
+ if ((readl(ulpi_viewport) mask) == 0)
+ return 0;
+
+ udelay(1);
+ }
+
+ return ULPI_ERROR;
+}
+
+/*
+ * Wake the ULPI PHY up for communication
+ *
+ * returns 0 on success.
+ */
+static int ulpi_wakeup(u32 ulpi_viewport)
+{
+ int err;
+
+ if (readl(ulpi_viewport)
Re: [U-Boot] [PATCH 1/4] mmc: Change board_mmc_getcd() signature.
The new API no longer uses the extra cd parameter that was used to store the card presence state. Instead, this information is returned via the function's return value. board_mmc_getcd() returns -1 to indicate that no card-detection mechanism is implemented; 0 indicates that no card is present and 1 is returned if it was detected that a card is present. Signed-off-by: Thierry Reding thierry.red...@avionic-design.de A silly question -- why do we need this change ? Can you explain it in the changelog of V2 too? M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] mmc: Change board_mmc_getcd() signature.
* Marek Vasut wrote: The new API no longer uses the extra cd parameter that was used to store the card presence state. Instead, this information is returned via the function's return value. board_mmc_getcd() returns -1 to indicate that no card-detection mechanism is implemented; 0 indicates that no card is present and 1 is returned if it was detected that a card is present. Signed-off-by: Thierry Reding thierry.red...@avionic-design.de A silly question -- why do we need this change ? Can you explain it in the changelog of V2 too? It's the first step in implementing card-detection. I discussed this with Andy and he came up with the idea that board_mmc_getcd() should really have had the mmc parameter as first argument in the first place instead of the cd parameter. Furthermore, the cd parameter is used inconsistently in individual implementations. After some discussion we came to the conclusion that the cd parameter wasn't required at all and the same information can be represented in the return value. The whole discussion is in this thread: http://lists.denx.de/pipermail/u-boot/2011-November/110180.html It's not really a necessary change, but it makes board_mmc_getcd() much more consistent with other MMC-related functions. Perhaps this last sentence would be a good explanation to put in the v2 commit message? Thierry pgpFJthpXEohi.pgp Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [ARM]: File type for u-boot elf file
I have OMAP L138 Hawkboard which is loaded with some other program. I am new to this hawkboard and tried to boot as per instructions from user guide in http://www.hawkboard.org/ , system is not coming to hawkboard.org to access command. It is coming as follows. Please help me to make it ready. Switch positions made as follows Pin1 = ON Pin2 = OFF Pin3 = OFF Pin4 = OFF Terminal data as follows: U-Boot 2009.01-dirty (Nov 26 2009 - 02:15:00) DRAM: 128 MB NAND: NAND device: Manufacturer ID: 0x2c, Chip ID: 0xa1 (Micron NAND 128MiB 1,8 V 8-bit) Bad block table found at page 65472, version 0x01 Bad block table found at page 65408, version 0x01 nand_read_bbt: Bad block at 0x0350 nand_read_bbt: Bad block at 0x049a 128 MiB In:serial Out: serial Err: serial ARM Clock : 3 Hz DDR Clock : 15000 Hz Ethernet PHY: GENERIC @ 0x07 Hit any key to stop autoboot: 0 NAND read: device 0 offset 0x20, size 0x30 .. Regards, Rojan Joy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] having trouble booting a simple kernel on a TQM860 board
Dear Robert, In message alpine.DEB.2.02.1112042100270.15118@oneiric you wrote: i believe i've solved this issue, at least. i downloaded ELDK 4.2 and installed the ppc_8xx- toolchain. with that, i managed to compile u-boot 2010.12 and flashed it to my TQM860, reset and, lo and behold, i have a 2010.12 u-boot. so my u-boot issue seems to be resolved. You update U-Boot, but to a version 4 releases old. Why not to current code? which generated a uImage file. but as i understand it, i want a cuImage-format file as i used with my lite5200, so i edited the file No. Now you don't need a cuImage nay more. Just use the DT as I showed you in the builkd and boot log I sent before. look reasonable? so i download to the board to address 20, ... but at this point, any attempt to bootm 20 gives me (as before): ... immediately followed by a long line of diamonds with question marks You may want to read the FAQ: http://www.denx.de/wiki/view/DULG/LinuxUncompressingError Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It was the Law of the Sea, they said. Civilization ends at the wa- terline. Beyond that, we all enter the food chain, and not always right at the top. - Hunter S. Thompson ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 13/15] arm, da850evm: Add an SPL for SPI boot
Hi Tom, On Sat, Dec 3, 2011 at 6:49 AM, Christian Riesch christian.rie...@omicron.at wrote: Hi Tom, Thanks for your comments. On Friday, December 2, 2011, Tom Rini tr...@ti.com wrote: On 12/02/2011 09:12 AM, Christian Riesch wrote: [snip] include/configs/da850evm.h | 87 + [snip] +#define CONFIG_SYS_DA850_DDR2_SDTIMR (0 | \ + (14 DV_DDR_SDTMR1_RFC_SHIFT) | \ + (2 DV_DDR_SDTMR1_RP_SHIFT) | \ + (2 DV_DDR_SDTMR1_RCD_SHIFT) | \ + (1 DV_DDR_SDTMR1_WR_SHIFT) | \ + (5 DV_DDR_SDTMR1_RAS_SHIFT) | \ + (8 DV_DDR_SDTMR1_RC_SHIFT) | \ + (1 DV_DDR_SDTMR1_RRD_SHIFT) | \ + (0 DV_DDR_SDTMR1_WTR_SHIFT)) '0 | ..' and '0 ...' don't help readability over just value saying it (same with shifting 0). Also, unless the manual these come from uses decimal here, hex is preferred. Thanks! '0 | ...'. I agree, I'll remove this. '0 ...' Aaaahhh... Yes, that's pretty useless here, the WTR bits are reserved bits :-/ Uh, sorry, they are not reserved. But a zero value here means that we have one clock cycle (because it's number of clock cycles minus one). So I'd like to keep the line because it will help others to see that WTR is set to one clock cycle. Christian Decimal values: I'd like to keep them. This is DDR timing, the numbers mean number of clock cycles minus one. So actually (1 DV_DDR_SDTMR1_RRD_SHIFT) means that trrd=13.... ns (two clock cycles) at 150 MHz. So I must calculate with these numbers and this is why I prefer decimal over hex. I am lazy ;-) Christian -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] having trouble booting a simple kernel on a TQM860 board
On Mon, 5 Dec 2011, Wolfgang Denk wrote: Dear Robert, In message alpine.DEB.2.02.1112042100270.15118@oneiric you wrote: i believe i've solved this issue, at least. i downloaded ELDK 4.2 and installed the ppc_8xx- toolchain. with that, i managed to compile u-boot 2010.12 and flashed it to my TQM860, reset and, lo and behold, i have a 2010.12 u-boot. so my u-boot issue seems to be resolved. You update U-Boot, but to a version 4 releases old. Why not to current code? i have a number of lite5200s as well that all have 2010.12 on them and since they work fine for now, i just wanted to make everything consistent for some people who will be using those boards this week. once this session is over, everything will be reflashed to the current version. your point is, of course, well taken. which generated a uImage file. but as i understand it, i want a cuImage-format file as i used with my lite5200, so i edited the file No. Now you don't need a cuImage nay more. Just use the DT as I showed you in the builkd and boot log I sent before. ah, gotcha. i'll do that, thanks. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] mmc: fsl_esdhc: Implement card-detect hook.
On 05/12/2011 09:23, Thierry Reding wrote:
This card-detect hook probably doesn't work. Perhaps somebody with more
knowledge about the hardware can comment on this. I think that perhaps
even the complete code from esdhc_init() could go into the getcd()
The reason was only that the SDHC controller returns (up now) if the car
is inserted or not. However, there is no hardware related reason to make
this function called by the esdhc_init().
function instead or mmc_getcd() needs to be called at some later time
after mmc_init(), which, however, would require many other drivers to
change.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
drivers/mmc/fsl_esdhc.c | 29 -
1 files changed, 12 insertions(+), 17 deletions(-)
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index f719afd..b46bf9f 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -412,7 +412,6 @@ static int esdhc_init(struct mmc *mmc)
struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc-priv;
struct fsl_esdhc *regs = (struct fsl_esdhc *)cfg-esdhc_base;
int timeout = 1000;
- int ret = 0;
/* Reset the entire host controller */
esdhc_write32(regs-sysctl, SYSCTL_RSTA);
@@ -439,24 +438,19 @@ static int esdhc_init(struct mmc *mmc)
/* Set timout to the maximum value */
esdhc_clrsetbits32(regs-sysctl, SYSCTL_TIMEOUT_MASK, 14 16);
- /* Check if there is a callback for detecting the card */
- ret = board_mmc_getcd(mmc);
- if (ret 0) {
- timeout = 1000;
- while (!(esdhc_read32(regs-prsstat) PRSSTAT_CINS)
- --timeout)
- udelay(1000);
+ return 0;
+}
This is wrong, we have on fsl_esdhc.c at least two cases:
- the Card Detect is executed directly by the controller reading the
prsstat register - this happens for most (or all) PowerPC SOC haveing a
ESDHC controller.
- The Card Detect is done via GPIOs, as most of MX5 boards are doing
now, and as you implemented for Tegra (next patch).
You drop the way via GPIOs, breaking several boards.
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools/envcrc: fix compile breakage
ping!
This fixes a compile breakage and
IMO should be applied before 2011.12 is out.
Can someone, please apply it?
On 11/28/11 09:57, Igor Grinberg wrote:
When ENV_IS_EMBEDDED is not set, but CONFIG_BUILD_ENVCRC is set,
the environment.h file does not get included resulting in unrecognized
env_t type.
Fix this by moving the include directive.
Reported-by: Mike Frysinger vap...@gentoo.org
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
tools/envcrc.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/envcrc.c b/tools/envcrc.c
index 111d9f6..51e3f54 100644
--- a/tools/envcrc.c
+++ b/tools/envcrc.c
@@ -61,7 +61,6 @@
#endif /* CONFIG_ENV_IS_IN_FLASH */
#if defined(ENV_IS_EMBEDDED) !defined(CONFIG_BUILD_ENVCRC)
-# include environment.h
# define CONFIG_BUILD_ENVCRC 1
#endif
@@ -74,13 +73,14 @@
#define ENV_SIZE (CONFIG_ENV_SIZE - ENV_HEADER_SIZE)
-extern uint32_t crc32 (uint32_t, const unsigned char *, unsigned int);
-
#ifdef CONFIG_BUILD_ENVCRC
+# include environment.h
extern unsigned int env_size;
extern env_t environment;
#endif /* CONFIG_BUILD_ENVCRC */
+extern uint32_t crc32 (uint32_t, const unsigned char *, unsigned int);
+
int main (int argc, char **argv)
{
#ifdef CONFIG_BUILD_ENVCRC
--
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] mmc: Change board_mmc_getcd() signature.
On 05/12/2011 11:00, Thierry Reding wrote: * Marek Vasut wrote: The new API no longer uses the extra cd parameter that was used to store the card presence state. Instead, this information is returned via the function's return value. board_mmc_getcd() returns -1 to indicate that no card-detection mechanism is implemented; 0 indicates that no card is present and 1 is returned if it was detected that a card is present. Signed-off-by: Thierry Reding thierry.red...@avionic-design.de A silly question -- why do we need this change ? Can you explain it in the changelog of V2 too? It's the first step in implementing card-detection. I discussed this with Andy and he came up with the idea that board_mmc_getcd() should really have had the mmc parameter as first argument in the first place instead of the cd parameter. Ok, I get it now. Furthermore, the cd parameter is used inconsistently in individual implementations. After some discussion we came to the conclusion that the cd parameter wasn't required at all and the same information can be represented in the return value. The whole discussion is in this thread: http://lists.denx.de/pipermail/u-boot/2011-November/110180.html It's not really a necessary change, but it makes board_mmc_getcd() much more consistent with other MMC-related functions. Perhaps this last sentence would be a good explanation to put in the v2 commit message? Ok, thanks - this explains much better which is your intention for the patchset. It is also not bad to add a reference to the above thread. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 4/6] arm, da850evm: Add an SPL for SPI boot
Signed-off-by: Christian Riesch christian.rie...@omicron.at
Cc: Heiko Schocher h...@denx.de
Cc: Sandeep Paulraj s-paul...@ti.com
Cc: Tom Rini tr...@ti.com
Cc: Sudhakar Rajashekhara sudhakar@ti.com
---
board/davinci/da8xxevm/da850evm.c |4 +-
board/davinci/da8xxevm/u-boot-spl.lds | 73 +++
doc/README.davinci|9 +++
include/configs/da850evm.h| 87 +
4 files changed, 172 insertions(+), 1 deletions(-)
create mode 100644 board/davinci/da8xxevm/u-boot-spl.lds
diff --git a/board/davinci/da8xxevm/da850evm.c
b/board/davinci/da8xxevm/da850evm.c
index e827256..8e66c35 100644
--- a/board/davinci/da8xxevm/da850evm.c
+++ b/board/davinci/da8xxevm/da850evm.c
@@ -108,7 +108,7 @@ static const struct pinmux_config gpio_pins[] = {
#endif
};
-static const struct pinmux_resource pinmuxes[] = {
+const struct pinmux_resource pinmuxes[] = {
#ifdef CONFIG_DRIVER_TI_EMAC
PINMUX_ITEM(emac_pins_mdio),
#ifdef CONFIG_DRIVER_TI_EMAC_USE_RMII
@@ -135,6 +135,8 @@ static const struct pinmux_resource pinmuxes[] = {
PINMUX_ITEM(gpio_pins),
};
+const int pinmuxes_size = ARRAY_SIZE(pinmuxes);
+
static const struct lpsc_resource lpsc[] = {
{ DAVINCI_LPSC_AEMIF }, /* NAND, NOR */
{ DAVINCI_LPSC_SPI1 }, /* Serial Flash */
diff --git a/board/davinci/da8xxevm/u-boot-spl.lds
b/board/davinci/da8xxevm/u-boot-spl.lds
new file mode 100644
index 000..6f6e065
--- /dev/null
+++ b/board/davinci/da8xxevm/u-boot-spl.lds
@@ -0,0 +1,73 @@
+/*
+ * (C) Copyright 2002
+ * Gary Jennejohn, DENX Software Engineering, ga...@denx.de
+ *
+ * (C) Copyright 2008
+ * Guennadi Liakhovetki, DENX Software Engineering, l...@denx.de
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+MEMORY { .sram : ORIGIN = CONFIG_SPL_TEXT_BASE,\
+ LENGTH = CONFIG_SPL_MAX_SIZE }
+
+OUTPUT_FORMAT(elf32-littlearm, elf32-littlearm, elf32-littlearm)
+OUTPUT_ARCH(arm)
+ENTRY(_start)
+SECTIONS
+{
+ . = 0x;
+
+ . = ALIGN(4);
+ .text :
+ {
+ __start = .;
+ arch/arm/cpu/arm926ejs/start.o(.text)
+ *(.text*)
+ } .sram
+
+ . = ALIGN(4);
+ .rodata : { *(SORT_BY_ALIGNMENT(.rodata*)) } .sram
+
+ . = ALIGN(4);
+ .data : { *(SORT_BY_ALIGNMENT(.data*)) } .sram
+ . = ALIGN(4);
+ .rel.dyn : {
+ __rel_dyn_start = .;
+ *(.rel*)
+ __rel_dyn_end = .;
+ } .sram
+
+ .dynsym : {
+ __dynsym_start = .;
+ *(.dynsym)
+ } .sram
+
+ .bss :
+ {
+ . = ALIGN(4);
+ __bss_start = .;
+ *(.bss*)
+ . = ALIGN(4);
+ __bss_end__ = .;
+ } .sram
+
+ __image_copy_end = .;
+ _end = .;
+}
diff --git a/doc/README.davinci b/doc/README.davinci
index 5f1bdc8..aa7c850 100644
--- a/doc/README.davinci
+++ b/doc/README.davinci
@@ -95,6 +95,15 @@ into the RAM.
The programmers and UBL are always released as part of any standard TI
software release associated with an SOC.
+Alternative boot method (DA850 EVM only):
+For the DA850 EVM an SPL (secondary program loader, see doc/README.SPL)
+is provided to load U-Boot directly from SPI flash. In this case, the
+SPL does the low level initialization that is otherwise done by the SPL.
+To build U-Boot with this SPL, do
+make da850evm_config
+make u-boot.ais
+and program the resulting u-boot.ais file to the SPI flash of the DA850 EVM.
+
Environment Variables
=
diff --git a/include/configs/da850evm.h b/include/configs/da850evm.h
index 2e2aa19..b30696a 100644
--- a/include/configs/da850evm.h
+++ b/include/configs/da850evm.h
@@ -65,6 +65,75 @@
#define CONFIG_NR_DRAM_BANKS 1 /* we have 1 bank of DRAM */
#define CONFIG_STACKSIZE (256*1024) /* regular stack */
+#define CONFIG_SYS_DA850_SYSCFG_SUSPSRC ( \
+ DAVINCI_SYSCFG_SUSPSRC_TIMER0 | \
+ DAVINCI_SYSCFG_SUSPSRC_SPI1 | \
+ DAVINCI_SYSCFG_SUSPSRC_UART2 | \
+ DAVINCI_SYSCFG_SUSPSRC_EMAC | \
+ DAVINCI_SYSCFG_SUSPSRC_I2C)
+
+/*
+ * PLL
[U-Boot] [PATCH v5 5/6] mkimage: Fix variable length header support
Support for variable length images like AIS image was introduced
in commit f0662105b674a3874227316abf8536bebc9b5995. A parameter
-s was also introduced to prohibit copying of the image file
automatically in the main program. However, this parameter
was implemented incorrectly and the image file was copied
nevertheless.
Signed-off-by: Christian Riesch christian.rie...@omicron.at
Cc: Stefano Babic sba...@denx.de
Cc: Heiko Schocher h...@denx.de
Acked-by: Stefano Babic sba...@denx.de
---
tools/mkimage.c | 97 ---
1 files changed, 49 insertions(+), 48 deletions(-)
diff --git a/tools/mkimage.c b/tools/mkimage.c
index 36e28ec..eeb1b10 100644
--- a/tools/mkimage.c
+++ b/tools/mkimage.c
@@ -383,65 +383,66 @@ NXTARG: ;
exit (EXIT_FAILURE);
}
- if (!params.skipcpy
- (params.type == IH_TYPE_MULTI ||
- params.type == IH_TYPE_SCRIPT)) {
- char *file = params.datafile;
- uint32_t size;
-
- for (;;) {
- char *sep = NULL;
-
- if (file) {
- if ((sep = strchr(file, ':')) != NULL) {
- *sep = '\0';
+ if (!params.skipcpy) {
+ if (params.type == IH_TYPE_MULTI ||
+ params.type == IH_TYPE_SCRIPT) {
+ char *file = params.datafile;
+ uint32_t size;
+
+ for (;;) {
+ char *sep = NULL;
+
+ if (file) {
+ if ((sep = strchr(file, ':')) != NULL) {
+ *sep = '\0';
+ }
+
+ if (stat (file, sbuf) 0) {
+ fprintf (stderr, %s: Can't
stat %s: %s\n,
+params.cmdname, file,
strerror(errno));
+ exit (EXIT_FAILURE);
+ }
+ size = cpu_to_uimage (sbuf.st_size);
+ } else {
+ size = 0;
}
- if (stat (file, sbuf) 0) {
- fprintf (stderr, %s: Can't stat %s:
%s\n,
- params.cmdname, file,
strerror(errno));
+ if (write(ifd, (char *)size, sizeof(size)) !=
sizeof(size)) {
+ fprintf (stderr, %s: Write error on
%s: %s\n,
+params.cmdname,
params.imagefile,
+strerror(errno));
exit (EXIT_FAILURE);
}
- size = cpu_to_uimage (sbuf.st_size);
- } else {
- size = 0;
- }
- if (write(ifd, (char *)size, sizeof(size)) !=
sizeof(size)) {
- fprintf (stderr, %s: Write error on %s: %s\n,
- params.cmdname, params.imagefile,
- strerror(errno));
- exit (EXIT_FAILURE);
- }
+ if (!file) {
+ break;
+ }
- if (!file) {
- break;
+ if (sep) {
+ *sep = ':';
+ file = sep + 1;
+ } else {
+ file = NULL;
+ }
}
- if (sep) {
- *sep = ':';
- file = sep + 1;
- } else {
- file = NULL;
- }
- }
+ file = params.datafile;
- file = params.datafile;
-
- for (;;) {
- char *sep = strchr(file, ':');
- if (sep) {
- *sep = '\0';
- copy_file (ifd, file, 1);
- *sep++ = ':';
- file = sep;
- } else {
- copy_file (ifd, file, 0);
- break;
+ for (;;) {
+ char *sep = strchr(file,
[U-Boot] [PATCH v5 3/6] arm, davinci: Add SPL support for DA850 SoCs
This code adds an SPL for booting from SPI flash on DA850 SoCs.
Signed-off-by: Christian Riesch christian.rie...@omicron.at
Cc: Heiko Schocher h...@denx.de
Cc: Sandeep Paulraj s-paul...@ti.com
Cc: Tom Rini tr...@ti.com
Acked-by: Tom Rini tr...@ti.com
---
arch/arm/cpu/arm926ejs/davinci/Makefile |3 +-
arch/arm/cpu/arm926ejs/davinci/spl.c| 34 ++-
2 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/davinci/Makefile
b/arch/arm/cpu/arm926ejs/davinci/Makefile
index 5ae89df..da7efac 100644
--- a/arch/arm/cpu/arm926ejs/davinci/Makefile
+++ b/arch/arm/cpu/arm926ejs/davinci/Makefile
@@ -38,7 +38,8 @@ COBJS-$(CONFIG_DRIVER_TI_EMAC)+= lxt972.o dp83848.o
et1011c.o ksz8873.o
ifdef CONFIG_SPL_BUILD
COBJS-y+= spl.o
-COBJS-y+= dm365_lowlevel.o
+COBJS-$(CONFIG_SOC_DM365) += dm365_lowlevel.o
+COBJS-$(CONFIG_SOC_DA8XX) += da850_lowlevel.o
endif
SOBJS = reset.o
diff --git a/arch/arm/cpu/arm926ejs/davinci/spl.c
b/arch/arm/cpu/arm926ejs/davinci/spl.c
index d9b9398..20f798e 100644
--- a/arch/arm/cpu/arm926ejs/davinci/spl.c
+++ b/arch/arm/cpu/arm926ejs/davinci/spl.c
@@ -26,6 +26,16 @@
#include nand.h
#include asm/arch/dm365_lowlevel.h
#include ns16550.h
+#include malloc.h
+#include spi_flash.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* Define global data structure pointer to it*/
+static gd_t gdata __attribute__ ((section(.data)));
+static bd_t bdata __attribute__ ((section(.data)));
+
+#ifndef CONFIG_SPL_LIBCOMMON_SUPPORT
void puts(const char *str)
{
@@ -41,6 +51,8 @@ void putc(char c)
NS16550_putc((NS16550_t)(CONFIG_SYS_NS16550_COM1), c);
}
+#endif /* CONFIG_SPL_LIBCOMMON_SUPPORT */
+
inline void hang(void)
{
puts(### ERROR ### Please RESET the board ###\n);
@@ -50,14 +62,34 @@ inline void hang(void)
void board_init_f(ulong dummy)
{
+#ifdef CONFIG_SOC_DM365
dm36x_lowlevel_init(0);
+#endif
+#ifdef CONFIG_SOC_DA8XX
+ arch_cpu_init();
+#endif
relocate_code(CONFIG_SPL_STACK, NULL, CONFIG_SPL_TEXT_BASE);
}
void board_init_r(gd_t *id, ulong dummy)
{
-
+#ifdef CONFIG_SOC_DM365
nand_init();
puts(Nand boot...\n);
nand_boot();
+#endif
+#ifdef CONFIG_SOC_DA8XX
+ mem_malloc_init(CONFIG_SYS_TEXT_BASE - CONFIG_SYS_MALLOC_LEN,
+ CONFIG_SYS_MALLOC_LEN);
+
+ gd = gdata;
+ gd-bd = bdata;
+ gd-flags |= GD_FLG_RELOC;
+ gd-baudrate = CONFIG_BAUDRATE;
+ serial_init(); /* serial communications setup */
+ gd-have_console = 1;
+
+ puts(SPI boot...\n);
+ spi_boot();
+#endif
}
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 2/6] sf: Add spi_boot() to allow booting from SPI flash in an SPL
Signed-off-by: Christian Riesch christian.rie...@omicron.at
Cc: Heiko Schocher h...@denx.de
Cc: Mike Frysinger vap...@gentoo.org
Cc: Scott Wood scottw...@freescale.com
Acked-by: Mike Frysinger vap...@gentoo.org
---
doc/README.SPL |1 +
drivers/mtd/spi/Makefile |4 +++
drivers/mtd/spi/spi_spl_load.c | 58
include/spi_flash.h|3 ++
4 files changed, 66 insertions(+), 0 deletions(-)
create mode 100644 drivers/mtd/spi/spi_spl_load.c
diff --git a/doc/README.SPL b/doc/README.SPL
index 89d24a7..f01a8bd 100644
--- a/doc/README.SPL
+++ b/doc/README.SPL
@@ -65,3 +65,4 @@ CONFIG_SPL_NAND_SUPPORT (drivers/mtd/nand/libnand.o)
CONFIG_SPL_DMA_SUPPORT (drivers/dma/libdma.o)
CONFIG_SPL_POST_MEM_SUPPORT (post/drivers/memory.o)
CONFIG_SPL_NAND_LOAD (drivers/mtd/nand/nand_spl_load.o)
+CONFIG_SPL_SPI_LOAD (drivers/mtd/spi/spi_spl_load.o)
diff --git a/drivers/mtd/spi/Makefile b/drivers/mtd/spi/Makefile
index 57112af..90f8392 100644
--- a/drivers/mtd/spi/Makefile
+++ b/drivers/mtd/spi/Makefile
@@ -25,6 +25,10 @@ include $(TOPDIR)/config.mk
LIB:= $(obj)libspi_flash.o
+ifdef CONFIG_SPL_BUILD
+COBJS-$(CONFIG_SPL_SPI_LOAD) += spi_spl_load.o
+endif
+
COBJS-$(CONFIG_SPI_FLASH) += spi_flash.o
COBJS-$(CONFIG_SPI_FLASH_ATMEL)+= atmel.o
COBJS-$(CONFIG_SPI_FLASH_EON) += eon.o
diff --git a/drivers/mtd/spi/spi_spl_load.c b/drivers/mtd/spi/spi_spl_load.c
new file mode 100644
index 000..1aa30ac
--- /dev/null
+++ b/drivers/mtd/spi/spi_spl_load.c
@@ -0,0 +1,58 @@
+/*
+ * Copyright (C) 2011 OMICRON electronics GmbH
+ *
+ * based on drivers/mtd/nand/nand_spl_load.c
+ *
+ * Copyright (C) 2011
+ * Heiko Schocher, DENX Software Engineering, h...@denx.de.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include common.h
+#include spi_flash.h
+
+/*
+ * The main entry for SPI booting. It's necessary that SDRAM is already
+ * configured and available since this code loads the main U-Boot image
+ * from SPI into SDRAM and starts it from there.
+ */
+void spi_boot(void)
+{
+ struct spi_flash *flash;
+ void (*uboot)(void) __noreturn;
+
+ /*
+* Load U-Boot image from SPI flash into RAM
+*/
+
+ flash = spi_flash_probe(CONFIG_SPL_SPI_BUS, CONFIG_SPL_SPI_CS,
+ CONFIG_SF_DEFAULT_SPEED, SPI_MODE_3);
+ if (!flash) {
+ puts(failed.\n);
+ hang();
+ }
+
+ spi_flash_read(flash, CONFIG_SYS_SPI_U_BOOT_OFFS,
+ CONFIG_SYS_SPI_U_BOOT_SIZE,
+ (void *) CONFIG_SYS_TEXT_BASE);
+
+ /*
+* Jump to U-Boot image
+*/
+ uboot = (void *) CONFIG_SYS_TEXT_BASE;
+ (*uboot)();
+}
diff --git a/include/spi_flash.h b/include/spi_flash.h
index 2671ab5..9da9062 100644
--- a/include/spi_flash.h
+++ b/include/spi_flash.h
@@ -25,6 +25,7 @@
#include spi.h
#include linux/types.h
+#include linux/compiler.h
struct spi_flash {
struct spi_slave *spi;
@@ -68,4 +69,6 @@ static inline int spi_flash_erase(struct spi_flash *flash,
u32 offset,
return flash-erase(flash, offset, len);
}
+void spi_boot(void) __noreturn;
+
#endif /* _SPI_FLASH_H_ */
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 6/6] arm, davinci: Add support for generating AIS images to the Makefile
Signed-off-by: Christian Riesch christian.rie...@omicron.at
Cc: Stefano Babic sba...@denx.de
Cc: Heiko Schocher h...@denx.de
Cc: Mike Frysinger vap...@gentoo.org
---
.gitignore |1 +
Makefile | 13 +
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/.gitignore b/.gitignore
index ff4bae0..e4e95e2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -35,6 +35,7 @@
/u-boot.dis
/u-boot.lds
/u-boot.ubl
+/u-boot.ais
/u-boot.dtb
/u-boot.sb
diff --git a/Makefile b/Makefile
index fb658f4..5fe54c6 100644
--- a/Makefile
+++ b/Makefile
@@ -417,6 +417,18 @@ $(obj)u-boot.ubl: $(obj)spl/u-boot-spl.bin
$(obj)u-boot.bin
rm $(obj)u-boot-ubl.bin
rm $(obj)spl/u-boot-spl-pad.bin
+$(obj)u-boot.ais: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
+ $(obj)tools/mkimage -s -n /dev/null -T aisimage \
+ -e $(CONFIG_SPL_TEXT_BASE) \
+ -d $(obj)spl/u-boot-spl.bin \
+ $(obj)spl/u-boot-spl.ais
+ $(OBJCOPY) ${OBJCFLAGS} -I binary \
+ --pad-to=$(CONFIG_SPL_MAX_SIZE) -O binary \
+ $(obj)spl/u-boot-spl.ais $(obj)spl/u-boot-spl-pad.ais
+ cat $(obj)spl/u-boot-spl-pad.ais $(obj)u-boot.bin \
+ $(obj)u-boot.ais
+ rm $(obj)spl/u-boot-spl{,-pad}.ais
+
$(obj)u-boot.sb: $(obj)u-boot.bin $(obj)spl/u-boot-spl.bin
elftosb -zdf imx28 -c $(TOPDIR)/board/$(BOARDDIR)/u-boot.bd \
-o $(obj)u-boot.sb
@@ -788,6 +800,7 @@ clobber:clean
@rm -f $(obj)u-boot.kwb
@rm -f $(obj)u-boot.imx
@rm -f $(obj)u-boot.ubl
+ @rm -f $(obj)u-boot.ais
@rm -f $(obj)u-boot.dtb
@rm -f $(obj)u-boot.sb
@rm -f $(obj)tools/{env/crc32.c,inca-swap-bytes}
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 0/6] Add an SPL to boot the da850evm from SPI
Hi, this is v5 of the last part of my recent patchset [PATCH v3 00/15] Add an SPL to boot the da850evm from SPI http://lists.denx.de/pipermail/u-boot/2011-November/82.html Most of the other parts are already merged, together with this patchset they introduce an SPL for the da850evm to run u-boot directly without the need of a UBL (see doc/README.davinci). The first patches fix dependencies and introduce a function to load the u-boot image from SPI flash. Patch #4 adds an SPL to the da850evm configuration. Finally, a simple AIS (Application Image Script) is required to start the SPL. This AIS is generated by mkimage. Patch #5 fixes mkimage for building AIS. Finally the last patch introduces a u-boot.ais target in the Makefile. This patchset applies on top of git://git.denx.de/u-boot-ti.git Changes for v5: - changed formatting (indentation) of the $(obj)u-boot.ais target in the Makefile - removed useless '0 | ... ' from include/configs/da850evm.h - added Acked-bys Changes for v4: - added documentation for the SPL to doc/README.davinci - split patchset because it got too big - use COBJS-$(CONFIG_SPL_SPI_LOAD) instead of ifdefs in drivers/mtd/spi/Makefile - use __noreturn instead of __attribute__((noreturn)) - added Acked-by Changes for v3: - removed noise and hardcoded values from drivers/mtd/spi/spi_spl_load.c - replaced $(PAD_TO) in Makefile by $(CONFIG_SPL_MAX_SIZE) Major changes for v2: - Added code that actually loads u-boot from SPI flash and starts it. To build run make da850evm_config make u-boot.ais Then program u-boot.ais to the SPI flash on the da850evm. Best regards, Christian Cc: Heiko Schocher h...@denx.de Cc: Sandeep Paulraj s-paul...@ti.com Cc: Tom Rini tr...@ti.com Christian Riesch (6): spl: display_options.o is required for SPI flash support in SPL sf: Add spi_boot() to allow booting from SPI flash in an SPL arm, davinci: Add SPL support for DA850 SoCs arm, da850evm: Add an SPL for SPI boot mkimage: Fix variable length header support arm, davinci: Add support for generating AIS images to the Makefile .gitignore |1 + Makefile| 13 arch/arm/cpu/arm926ejs/davinci/Makefile |3 +- arch/arm/cpu/arm926ejs/davinci/spl.c| 34 +++- board/davinci/da8xxevm/da850evm.c |4 +- board/davinci/da8xxevm/u-boot-spl.lds | 73 +++ doc/README.SPL |1 + doc/README.davinci |9 +++ drivers/mtd/spi/Makefile|4 + drivers/mtd/spi/spi_spl_load.c | 58 ++ include/configs/da850evm.h | 87 +++ include/spi_flash.h |3 + lib/Makefile|2 + tools/mkimage.c | 97 --- 14 files changed, 338 insertions(+), 51 deletions(-) create mode 100644 board/davinci/da8xxevm/u-boot-spl.lds create mode 100644 drivers/mtd/spi/spi_spl_load.c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] mmc: Change board_mmc_getcd() signature.
On 05/12/2011 11:00, Thierry Reding wrote: * Marek Vasut wrote: The new API no longer uses the extra cd parameter that was used to store the card presence state. Instead, this information is returned via the function's return value. board_mmc_getcd() returns -1 to indicate that no card-detection mechanism is implemented; 0 indicates that no card is present and 1 is returned if it was detected that a card is present. Signed-off-by: Thierry Reding thierry.red...@avionic-design.de A silly question -- why do we need this change ? Can you explain it in the changelog of V2 too? It's the first step in implementing card-detection. I discussed this with Andy and he came up with the idea that board_mmc_getcd() should really have had the mmc parameter as first argument in the first place instead of the cd parameter. Ok, I get it now. Furthermore, the cd parameter is used inconsistently in individual implementations. After some discussion we came to the conclusion that the cd parameter wasn't required at all and the same information can be represented in the return value. The whole discussion is in this thread: http://lists.denx.de/pipermail/u-boot/2011-November/110180.html It's not really a necessary change, but it makes board_mmc_getcd() much more consistent with other MMC-related functions. Perhaps this last sentence would be a good explanation to put in the v2 commit message? Ok, thanks - this explains much better which is your intention for the patchset. It is also not bad to add a reference to the above thread. Best regards, Stefano Babic Yep, and when/if submitting V2, also make a cover letter (while also adding the explanation to this patch's commit message). Thanks! M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 1/6] spl: display_options.o is required for SPI flash support in SPL
Signed-off-by: Christian Riesch christian.rie...@omicron.at Cc: Heiko Schocher h...@denx.de Cc: Mike Frysinger vap...@gentoo.org --- lib/Makefile |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/lib/Makefile b/lib/Makefile index 54708c2..35ba7ff 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -50,6 +50,8 @@ COBJS-$(CONFIG_SHA1) += sha1.o COBJS-$(CONFIG_SHA256) += sha256.o COBJS-y+= strmhz.o COBJS-$(CONFIG_RBTREE) += rbtree.o +else +COBJS-$(CONFIG_SPL_SPI_FLASH_SUPPORT) += display_options.o endif COBJS-y += ctype.o -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] mkenvimage: Fix some typos
Signed-off-by: Horst Kronstorfer hkron...@frequentis.com
---
tools/mkenvimage.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/mkenvimage.c b/tools/mkenvimage.c
index 9c32f4a..b7b0e0f 100644
--- a/tools/mkenvimage.c
+++ b/tools/mkenvimage.c
@@ -116,7 +116,7 @@ int main(int argc, char **argv)
/* Check datasize and allocate the data */
if (datasize == 0) {
fprintf(stderr,
- Please specify the size of the envrionnment
+ Please specify the size of the environment
partition.\n);
usage(argv[0]);
return EXIT_FAILURE;
@@ -182,12 +182,12 @@ int main(int argc, char **argv)
ret = close(txt_fd);
}
/*
-* The right test to do is = (not ) because of the additionnal
+* The right test to do is = (not ) because of the additional
* ending \0. See below.
*/
if (filesize = envsize) {
fprintf(stderr, The input file is larger than the
- envrionnment partition size\n);
+ environment partition size\n);
return EXIT_FAILURE;
}
@@ -196,7 +196,7 @@ int main(int argc, char **argv)
if (filebuf[fp] == '\n') {
if (fp == 0) {
/*
-* Newline at the beggining of the file ?
+* Newline at the beginning of the file ?
* Ignore it.
*/
continue;
--
1.7.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] mkenvimage: Print program basename instead of whole path in usage()
Signed-off-by: Horst Kronstorfer hkron...@frequentis.com --- tools/mkenvimage.c | 13 + 1 files changed, 9 insertions(+), 4 deletions(-) diff --git a/tools/mkenvimage.c b/tools/mkenvimage.c index 22d1b88..3e7f967 100644 --- a/tools/mkenvimage.c +++ b/tools/mkenvimage.c @@ -79,6 +79,11 @@ int main(int argc, char **argv) struct stat txt_file_stat; int fp, ep; + const char *prg; + + /* Parse program basename */ + prg = strrchr(argv[0], '/'); + prg = (prg) ? prg + 1 : argv[0]; /* Turn off getopt()'s internal error message */ opterr = 0; @@ -107,16 +112,16 @@ int main(int argc, char **argv) padbyte = strtol(optarg, NULL, 0); break; case 'h': - usage(argv[0]); + usage(prg); return EXIT_SUCCESS; case ':': fprintf(stderr, Missing argument for option -%c\n, optopt); - usage(argv[0]); + usage(prg); return EXIT_FAILURE; default: fprintf(stderr, Wrong option -%c\n, optopt); - usage(argv[0]); + usage(prg); return EXIT_FAILURE; } } @@ -126,7 +131,7 @@ int main(int argc, char **argv) fprintf(stderr, Please specify the size of the environment partition.\n); - usage(argv[0]); + usage(prg); return EXIT_FAILURE; } -- 1.7.7.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] mkenvimage: Fix getopt() error handling
Since the original implementation indicates explicit error handling
we turn off getopt()'s internal error messaging to avoid duplicate
error messages. Additionally we add ':' (missing option argument)
error handling.
Signed-off-by: Horst Kronstorfer hkron...@frequentis.com
---
tools/mkenvimage.c | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/tools/mkenvimage.c b/tools/mkenvimage.c
index b7b0e0f..22d1b88 100644
--- a/tools/mkenvimage.c
+++ b/tools/mkenvimage.c
@@ -80,8 +80,11 @@ int main(int argc, char **argv)
int fp, ep;
+ /* Turn off getopt()'s internal error message */
+ opterr = 0;
+
/* Parse the cmdline */
- while ((option = getopt(argc, argv, s:o:rbp:h)) != -1) {
+ while ((option = getopt(argc, argv, :s:o:rbp:h)) != -1) {
switch (option) {
case 's':
datasize = strtol(optarg, NULL, 0);
@@ -106,8 +109,13 @@ int main(int argc, char **argv)
case 'h':
usage(argv[0]);
return EXIT_SUCCESS;
+ case ':':
+ fprintf(stderr, Missing argument for option -%c\n,
+ optopt);
+ usage(argv[0]);
+ return EXIT_FAILURE;
default:
- fprintf(stderr, Wrong option -%c\n, option);
+ fprintf(stderr, Wrong option -%c\n, optopt);
usage(argv[0]);
return EXIT_FAILURE;
}
--
1.7.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] mkenvimage: Add version info switch (-V)
Signed-off-by: Horst Kronstorfer hkron...@frequentis.com
---
tools/mkenvimage.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/tools/mkenvimage.c b/tools/mkenvimage.c
index 3e7f967..046661d 100644
--- a/tools/mkenvimage.c
+++ b/tools/mkenvimage.c
@@ -36,6 +36,7 @@
#include sys/stat.h
#include u-boot/crc.h
+#include version.h
#define CRC_SIZE sizeof(uint32_t)
@@ -56,6 +57,7 @@ static void usage(const char *exec_name)
\t-b : the target is big endian (default is little endian)\n
\t-p byte : fill the image with byte bytes instead of
0xff bytes\n
+ \t-V : print version information and exit\n
\n
If the input file is \-\, data is read from standard input\n,
exec_name);
@@ -89,7 +91,7 @@ int main(int argc, char **argv)
opterr = 0;
/* Parse the cmdline */
- while ((option = getopt(argc, argv, :s:o:rbp:h)) != -1) {
+ while ((option = getopt(argc, argv, :s:o:rbp:hV)) != -1) {
switch (option) {
case 's':
datasize = strtol(optarg, NULL, 0);
@@ -114,6 +116,9 @@ int main(int argc, char **argv)
case 'h':
usage(prg);
return EXIT_SUCCESS;
+ case 'V':
+ printf(%s version %s\n, prg, PLAIN_VERSION);
+ return EXIT_SUCCESS;
case ':':
fprintf(stderr, Missing argument for option -%c\n,
optopt);
--
1.7.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] having trouble booting a simple kernel on a TQM860 board
On Mon, 5 Dec 2011, Wolfgang Denk wrote: Dear Robert, In message alpine.DEB.2.02.1112042100270.15118@oneiric you wrote: i believe i've solved this issue, at least. i downloaded ELDK 4.2 and installed the ppc_8xx- toolchain. with that, i managed to compile u-boot 2010.12 and flashed it to my TQM860, reset and, lo and behold, i have a 2010.12 u-boot. so my u-boot issue seems to be resolved. You update U-Boot, but to a version 4 releases old. Why not to current code? which generated a uImage file. but as i understand it, i want a cuImage-format file as i used with my lite5200, so i edited the file No. Now you don't need a cuImage nay more. Just use the DT as I showed you in the builkd and boot log I sent before. for the sake of clarification, you write that i don't *need* cuImages anymore, but that's not the same as saying that i *must* move to using device trees. in fact, a cuImage file still works just fine for my lite5200 boards, so obviously the version of u-boot that i've flashed to my TQM boards can still handle that format. so while it's probably a good idea to move to the device tree recipe, that still doesn't explain why i can't use a cuImage file for my tqm boards. so i'll test the device tree process later today, but i'm still curious as to why a cuImage format file still fails in this case when it works just fine for the other boards. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] mmc: fsl_esdhc: Implement card-detect hook.
* Stefano Babic wrote:
On 05/12/2011 09:23, Thierry Reding wrote:
This card-detect hook probably doesn't work. Perhaps somebody with more
knowledge about the hardware can comment on this. I think that perhaps
even the complete code from esdhc_init() could go into the getcd()
The reason was only that the SDHC controller returns (up now) if the car
is inserted or not. However, there is no hardware related reason to make
this function called by the esdhc_init().
Does that mean that the prsstat register work even if the controller hasn't
been initialized? If so, then the hook should work as is.
function instead or mmc_getcd() needs to be called at some later time
after mmc_init(), which, however, would require many other drivers to
change.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
drivers/mmc/fsl_esdhc.c | 29 -
1 files changed, 12 insertions(+), 17 deletions(-)
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index f719afd..b46bf9f 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -412,7 +412,6 @@ static int esdhc_init(struct mmc *mmc)
struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc-priv;
struct fsl_esdhc *regs = (struct fsl_esdhc *)cfg-esdhc_base;
int timeout = 1000;
- int ret = 0;
/* Reset the entire host controller */
esdhc_write32(regs-sysctl, SYSCTL_RSTA);
@@ -439,24 +438,19 @@ static int esdhc_init(struct mmc *mmc)
/* Set timout to the maximum value */
esdhc_clrsetbits32(regs-sysctl, SYSCTL_TIMEOUT_MASK, 14 16);
- /* Check if there is a callback for detecting the card */
- ret = board_mmc_getcd(mmc);
- if (ret 0) {
- timeout = 1000;
- while (!(esdhc_read32(regs-prsstat) PRSSTAT_CINS)
- --timeout)
- udelay(1000);
+ return 0;
+}
This is wrong, we have on fsl_esdhc.c at least two cases:
- the Card Detect is executed directly by the controller reading the
prsstat register - this happens for most (or all) PowerPC SOC haveing a
ESDHC controller.
- The Card Detect is done via GPIOs, as most of MX5 boards are doing
now, and as you implemented for Tegra (next patch).
You drop the way via GPIOs, breaking several boards.
No, patch 2 already moved board_mmc_getcd() to mmc_getcd() and calls
mmc_getcd() before mmc_init() is even called. So all boards should work as
before. This really only removes the duplicate check. Perhaps I should
mention that in the commit message.
Thierry
pgpjU26ypp94Y.pgp
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/4] mmc: Change board_mmc_getcd() signature.
* Stefano Babic wrote:
On 05/12/2011 09:23, Thierry Reding wrote:
[...]
diff --git a/board/efikamx/efikamx.c b/board/efikamx/efikamx.c
index b78bf6c..451d709 100644
--- a/board/efikamx/efikamx.c
+++ b/board/efikamx/efikamx.c
@@ -309,17 +309,15 @@ static inline uint32_t efika_mmc_cd(void)
return MX51_PIN_EIM_CS2;
}
-int board_mmc_getcd(u8 *absent, struct mmc *mmc)
+int board_mmc_getcd(struct mmc *mmc)
{
struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc-priv;
uint32_t cd = efika_mmc_cd();
if (cfg-esdhc_base == MMC_SDHC1_BASE_ADDR)
- *absent = gpio_get_value(IOMUX_TO_GPIO(cd));
- else
- *absent = gpio_get_value(IOMUX_TO_GPIO(MX51_PIN_GPIO1_8));
+ return !gpio_get_value(IOMUX_TO_GPIO(cd));
It seems to me you are inverting the logic. In you commit message, 1
means that a card is detected, exactly as it is done now. Am I wrong ?
The reason is that the fsl_esdhc driver actually calls the cd parameter
absent, so the logic is inverted in that driver. This change merely brings
the board implementation in line with the new API. Perhaps it would help if
the meaning of the return value should be documented explicitly in mmc.h?
Thierry
pgpKmjBqcKAlu.pgp
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] having trouble booting a simple kernel on a TQM860 board
Dear Robert, In message alpine.DEB.2.02.1112050701340.21244@oneiric you wrote: No. Now you don't need a cuImage nay more. Just use the DT as I showed you in the builkd and boot log I sent before. for the sake of clarification, you write that i don't *need* cuImages anymore, but that's not the same as saying that i *must* move to using device trees. in fact, a cuImage file still works just fine True, you don't have to use the DT. You don't have to use the most straightforward way that has been well tested for a ton of combinations of recent U-Boot releases against recent kernel releases. You are free to chose any untested, unsupported way you like. It's perfectly fine to ignore all good advice you get here. But eventually you should then also stop asking further questions here. for my lite5200 boards, so obviously the version of u-boot that i've flashed to my TQM boards can still handle that format. Of course U-Boot can handle this. so while it's probably a good idea to move to the device tree recipe, that still doesn't explain why i can't use a cuImage file for my tqm boards. so i'll test the device tree process later today, but i'm still curious as to why a cuImage format file still fails in this case when it works just fine for the other boards. Because this code has never been adapted for nor tested with any TQM8xx boards? But frankly, who cares? This code simply is not needed for these boards. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de grep me no patterns and I'll tell you no lines. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] i.mx: i.mx6q: add the initial support for i.mx6q Sabre Lite board
From: Dirk Behme dirk.be...@de.bosch.com Add the initial support for Freescale i.MX6Q Sabre Lite board Signed-off-by: Dirk Behme dirk.be...@de.bosch.com Signed-off-by: Jason Liu jason@linaro.org Cc: Stefano Babic sba...@denx.de --- MAINTAINERS |1 + board/freescale/mx6qsabrelite/Makefile| 42 ++ board/freescale/mx6qsabrelite/imximage.cfg| 170 + board/freescale/mx6qsabrelite/mx6qsabrelite.c | 150 ++ boards.cfg|1 + include/configs/mx6qsabrelite.h | 158 +++ 6 files changed, 522 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 52d86bd..8a4060f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -569,6 +569,7 @@ Jason Liu r64...@freescale.com mx53evk i.MX53 mx53locoi.MX53 mx6qarm2i.MX6Q + mx6qsabrelite i.MX6Q Enric Balletbo i Serra eballe...@iseebcn.com diff --git a/board/freescale/mx6qsabrelite/Makefile b/board/freescale/mx6qsabrelite/Makefile new file mode 100644 index 000..9b3c493 --- /dev/null +++ b/board/freescale/mx6qsabrelite/Makefile @@ -0,0 +1,42 @@ +# +# Copyright (C) 2007, Guennadi Liakhovetski l...@denx.de +# +# (C) Copyright 2011 Freescale Semiconductor, Inc. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).o + +COBJS := mx6qsabrelite.o + +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB):$(obj).depend $(OBJS) $(SOBJS) + $(call cmd_link_o_target, $(OBJS) $(SOBJS)) + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/freescale/mx6qsabrelite/imximage.cfg b/board/freescale/mx6qsabrelite/imximage.cfg new file mode 100644 index 000..8d3848f --- /dev/null +++ b/board/freescale/mx6qsabrelite/imximage.cfg @@ -0,0 +1,170 @@ +# Copyright (C) 2011 Freescale Semiconductor, Inc. +# Jason Liu r64...@freescale.com +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not write to the Free Software +# Foundation Inc. 51 Franklin Street Fifth Floor Boston, +# MA 02110-1301 USA +# +# Refer docs/README.imxmage for more details about how-to configure +# and create imximage boot image +# +# The syntax is taken as close as possible with the kwbimage + +# image version + +IMAGE_VERSION 2 + +# Boot Device : one of +# spi, sd (the board has no nand neither onenand) + +BOOT_FROM sd + +# Device Configuration Data (DCD) +# +# Each entry must have the format: +# Addr-type AddressValue +# +# where: +# Addr-type register length (1,2 or 4 bytes) +# Address absolute address of the register +# value value to be stored in the register +DATA 4 0x020e05a8 0x0030 +DATA 4 0x020e05b0 0x0030 +DATA 4 0x020e0524 0x0030 +DATA 4 0x020e051c 0x0030 + +DATA 4 0x020e0518 0x0030 +DATA 4 0x020e050c 0x0030 +DATA 4 0x020e05b8 0x0030 +DATA 4 0x020e05c0 0x0030 + +DATA 4 0x020e05ac 0x00020030 +DATA 4 0x020e05b4 0x00020030 +DATA 4 0x020e0528 0x00020030 +DATA 4 0x020e0520 0x00020030 + +DATA 4 0x020e0514 0x00020030 +DATA 4 0x020e0510 0x00020030 +DATA 4 0x020e05bc 0x00020030 +DATA 4 0x020e05c4 0x00020030 + +DATA 4 0x020e056c 0x00020030 +DATA 4 0x020e0578 0x00020030 +DATA 4 0x020e0588 0x00020030 +DATA 4 0x020e0594 0x00020030 + +DATA 4 0x020e057c 0x00020030 +DATA 4 0x020e0590
Re: [U-Boot] [PATCH] i.mx: i.mx6q: add the initial support for i.mx6q Sabre Lite board
On Mon, Dec 5, 2011 at 10:57 AM, Jason Liu jason@linaro.org wrote: +IMAGE_VERSION 2 + +# Boot Device : one of +# spi, sd (the board has no nand neither onenand) + +BOOT_FROM sd This board does not boot from sd, only from SPI NOR. Could you please let me know how it was tested? It would be nice to add a README that tells how to flash the SPI NOR. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] i.mx: i.mx6q: add the initial support for i.mx6q Sabre Lite board
On 05.12.2011 14:23, Fabio Estevam wrote: On Mon, Dec 5, 2011 at 10:57 AM, Jason Liu jason@linaro.org wrote: +IMAGE_VERSION 2 + +# Boot Device : one of +# spi, sd (the board has no nand neither onenand) + +BOOT_FROM sd This board does not boot from sd, only from SPI NOR. Could you please let me know how it was tested? There is a 'workaround/patch' available from Freescale which switches the board to SD boot. It's a small program written to the SPI NOR replacing the U-Boot in SPI NOR, which then itself jumps back to the SD boot routines. From user point of view the boards boots from SD then. With a small, invisible indirection via the SPI NOR. Best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] i.mx: i.mx6q: add the initial support for i.mx6q Sabre Lite board
On 05.12.2011 13:57, Jason Liu wrote: From: Dirk Behme dirk.be...@de.bosch.com Add the initial support for Freescale i.MX6Q Sabre Lite board Please note that this patch relies on the basic i.mx6q core support introduced with the patch series http://lists.denx.de/pipermail/u-boot/2011-November/63.html So it would be nice if this patch could be handled together with the above patch series as proposed in http://lists.denx.de/pipermail/u-boot/2011-December/111881.html Many thanks Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] i.mx: i.mx6q: add the initial support for i.mx6q Sabre Lite board
On Mon, Dec 5, 2011 at 11:26 AM, Dirk Behme dirk.be...@de.bosch.com wrote: On 05.12.2011 14:23, Fabio Estevam wrote: On Mon, Dec 5, 2011 at 10:57 AM, Jason Liu jason@linaro.org wrote: +IMAGE_VERSION 2 + +# Boot Device : one of +# spi, sd (the board has no nand neither onenand) + +BOOT_FROM sd This board does not boot from sd, only from SPI NOR. Could you please let me know how it was tested? There is a 'workaround/patch' available from Freescale which switches the board to SD boot. It's a small program written to the SPI NOR replacing the U-Boot in SPI NOR, which then itself jumps back to the SD boot routines. From user point of view the boards boots from SD then. With a small, invisible indirection via the SPI NOR. I would be glad to test the mx6sabrelite U-boot patch if you can provide me the FSL workaround/patch that replaces SPI NOR with SD boot. Thanks, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 13/15] arm, da850evm: Add an SPL for SPI boot
On 12/05/2011 03:20 AM, Christian Riesch wrote: Hi Tom, On Sat, Dec 3, 2011 at 6:49 AM, Christian Riesch christian.rie...@omicron.at wrote: Hi Tom, Thanks for your comments. On Friday, December 2, 2011, Tom Rini tr...@ti.com wrote: On 12/02/2011 09:12 AM, Christian Riesch wrote: [snip] include/configs/da850evm.h| 87 + [snip] +#define CONFIG_SYS_DA850_DDR2_SDTIMR (0 |\ + (14 DV_DDR_SDTMR1_RFC_SHIFT) | \ + (2 DV_DDR_SDTMR1_RP_SHIFT) | \ + (2 DV_DDR_SDTMR1_RCD_SHIFT) |\ + (1 DV_DDR_SDTMR1_WR_SHIFT) | \ + (5 DV_DDR_SDTMR1_RAS_SHIFT) |\ + (8 DV_DDR_SDTMR1_RC_SHIFT) | \ + (1 DV_DDR_SDTMR1_RRD_SHIFT) |\ + (0 DV_DDR_SDTMR1_WTR_SHIFT)) '0 | ..' and '0 ...' don't help readability over just value saying it (same with shifting 0). Also, unless the manual these come from uses decimal here, hex is preferred. Thanks! '0 | ...'. I agree, I'll remove this. '0 ...' Aaaahhh... Yes, that's pretty useless here, the WTR bits are reserved bits :-/ Uh, sorry, they are not reserved. But a zero value here means that we have one clock cycle (because it's number of clock cycles minus one). So I'd like to keep the line because it will help others to see that WTR is set to one clock cycle. I'd say it's not obvious that a value of zero means one clock cycle, so drop the define and just comment what the full value contains. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/9] arch/arm/cpu/armv7/omap-common/clocks-common.c: Fix GCC 4.6 warnings
On 12/03/2011 09:46 AM, Anatolij Gustschin wrote:
Fix:
clocks-common.c: In function 'setup_dplls':
clocks-common.c:256:6: warning: variable 'sysclk_ind' set but not used
[-Wunused-but-set-variable]
clocks-common.c: In function 'setup_non_essential_dplls':
clocks-common.c:292:6: warning: variable 'sysclk_ind' set but not used
[-Wunused-but-set-variable]
Signed-off-by: Anatolij Gustschin ag...@denx.de
Cc: sricharan r.sricha...@ti.com
Cc: Tom Rini tr...@ti.com
---
arch/arm/cpu/armv7/omap-common/clocks-common.c |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c
b/arch/arm/cpu/armv7/omap-common/clocks-common.c
index 1e7e20e..1da90a4 100644
--- a/arch/arm/cpu/armv7/omap-common/clocks-common.c
+++ b/arch/arm/cpu/armv7/omap-common/clocks-common.c
@@ -253,11 +253,10 @@ void configure_mpu_dpll(void)
static void setup_dplls(void)
{
- u32 sysclk_ind, temp;
+ u32 temp;
const struct dpll_params *params;
- debug(setup_dplls\n);
- sysclk_ind = get_sys_clk_index();
+ debug(setup_dplls\n);
/* CORE dpll */
params = get_core_dpll_params();/* default - safest */
Hand-editing the diffs? Not sure why the debug print looks like it
moved. But regardless...
Acked-by: Tom Rini tr...@ti.com
And will be queued to u-boot-ti/master once Albert pulls /comments on my
current request.
--
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/9] arch/arm/cpu/armv7/omap-common/spl.c: Fix GCC 4.2 warnings
On 12/04/2011 04:28 AM, Marek Vasut wrote: Fix: spl.c: In function 'jump_to_image_no_args': spl.c:103: warning: assignment makes pointer from integer without a cast spl.c:105: warning: dereferencing type-punned pointer will break strict-aliasing rules Signed-off-by: Anatolij Gustschin ag...@denx.de Cc: sricharan r.sricha...@ti.com Cc: Tom Rini tr...@ti.com --- arch/arm/cpu/armv7/omap-common/spl.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/arm/cpu/armv7/omap-common/spl.c b/arch/arm/cpu/armv7/omap-common/spl.c index 25f04ed..9c35a09 100644 --- a/arch/arm/cpu/armv7/omap-common/spl.c +++ b/arch/arm/cpu/armv7/omap-common/spl.c @@ -100,9 +100,10 @@ static void jump_to_image_no_args(void) debug(image entry point: 0x%X\n, spl_image.entry_point); /* Pass the saved boot_params from rom code */ #if defined(CONFIG_VIRTIO) || defined(CONFIG_ZEBU) -image_entry = 0x8010; +image_entry = (image_entry_noargs_t)0x8010; #endif -image_entry((u32 *)boot_params_ptr); +u32 boot_params_ptr_addr = (u32)boot_params_ptr; +image_entry((u32 *)boot_params_ptr_addr); } void jump_to_image_no_args(void) __attribute__ ((noreturn)); Acked-by: Marek Vasut marek.va...@gmail.com Acked-by: Tom Rini tr...@ti.com And will be queued to u-boot-ti/master once the current pull request is dealt with. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 9/9] arch/arm/include/asm/arch-omap5/clocks.h: Fix GCC 4.2 warnings
On 12/04/2011 06:59 AM, Anatolij Gustschin wrote:
On Sun, 4 Dec 2011 12:30:40 +0100
Marek Vasut marek.va...@gmail.com wrote:
Fix:
clocks.c: In function 'setup_post_dividers':
clocks.c:175: warning: comparison is always true due to limited range of
data type
clocks.c:177: warning: comparison is always true due to limited range of
data type
clocks.c:179: warning: comparison is always true due to limited range of
data type
clocks.c:181: warning: comparison is always true due to limited range of
data type
clocks.c:183: warning: comparison is always true due to limited range of
data type
clocks.c:185: warning: comparison is always true due to limited range of
data type
clocks.c:187: warning: comparison is always true due to limited range of
data type
clocks.c:189: warning: comparison is always true due to limited range of
data type
Signed-off-by: Anatolij Gustschin ag...@denx.de
Cc: sricharan r.sricha...@ti.com
Cc: Tom Rini tr...@ti.com
---
Some notes:
- GCC v4.5.1 didn't warn here
- GCC v4.6.1 seems to have a bug and can't compile this code:
clocks.c: In function 'enable_non_essential_clocks':
clocks.c:349:13: internal compiler error: in decode_addr_const, at
varasm.c:2632
arch/arm/include/asm/arch-omap5/clocks.h | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/include/asm/arch-omap5/clocks.h
b/arch/arm/include/asm/arch-omap5/clocks.h index fa99f65..d0e6dd6 100644
--- a/arch/arm/include/asm/arch-omap5/clocks.h
+++ b/arch/arm/include/asm/arch-omap5/clocks.h
@@ -686,14 +686,14 @@ struct dpll_regs {
struct dpll_params {
u32 m;
u32 n;
- u8 m2;
- u8 m3;
- u8 h11;
- u8 h12;
- u8 h13;
- u8 h14;
- u8 h22;
- u8 h23;
+ s8 m2;
+ s8 m3;
+ s8 h11;
+ s8 h12;
+ s8 h13;
+ s8 h14;
+ s8 h22;
+ s8 h23;
};
extern struct omap5_prcm_regs *const prcm;
Make clock registers a signed type? whoa
No, we don't make registers a signed type. This is parameters structure
for some parameter tables containing -1 as an indicator that the
parameter shouldn't be written to the register. Using unsigned type
for structure field results in parameter value 255:
static const struct dpll_params per_dpll_params_768mhz[NUM_SYS_CLKS] = {
{32, 0, 4, 3, 6, 4, -1, 2, -1, -1}, /* 12 MHz */
{-1, -1, -1, -1, -1, -1, -1, -1, -1, -1}, /* 13 MHz */
{160, 6, 4, 3, 6, 4, -1, 2, -1, -1},/* 16.8 MHz */
{20, 0, 4, 3, 6, 4, -1, 2, -1, -1}, /* 19.2 MHz */
{192, 12, 4, 3, 6, 4, -1, 2, -1, -1}, /* 26 MHz */
{-1, -1, -1, -1, -1, -1, -1, -1, -1, -1}, /* 27 MHz */
{10, 0, 4, 3, 6, 4, -1, 2, -1, -1} /* 38.4 MHz */
};
The code then checks:
void setup_post_dividers(u32 *const base, const struct dpll_params *params)
{
struct dpll_regs *const dpll_regs = (struct dpll_regs *)base;
/* Setup post-dividers */
if (params-m2 = 0)
writel(params-m2, dpll_regs-cm_div_m2_dpll);
if (params-m3 = 0)
writel(params-m3, dpll_regs-cm_div_m3_dpll);
if (params-h11 = 0)
writel(params-h11, dpll_regs-cm_div_h11_dpll);
if (params-h12 = 0)
writel(params-h12, dpll_regs-cm_div_h12_dpll);
if (params-h13 = 0)
writel(params-h13, dpll_regs-cm_div_h13_dpll);
if (params-h14 = 0)
writel(params-h14, dpll_regs-cm_div_h14_dpll);
if (params-h22 = 0)
writel(params-h22, dpll_regs-cm_div_h22_dpll);
if (params-h23 = 0)
writel(params-h23, dpll_regs-cm_div_h23_dpll);
}
The result is that the registers will always be written to, since
the comparison is always true. This is apparently not intended in
the code.
The actual registers structure 'struct dpll_regs' uses unsigned type.
This sneaked in in the commit 2e5ba489 adding omap5 clock support.
The similar parameter structure for omap4 used signed type for the
fields in question.
Newer gcc doesn't warn here unless -Wextra option is used.
Sricharan, my examination, this analysis is correct, can you confirm
that omap5 is supposed to work like omap4 in this case? Thanks.
--
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 4/6] arm, da850evm: Add an SPL for SPI boot
On 12/05/2011 03:58 AM, Christian Riesch wrote: [snip] include/configs/da850evm.h| 87 + [snip] +#define CONFIG_SYS_DA850_DDR2_SDTIMR2 ( \ + (7 DV_DDR_SDTMR2_RASMAX_SHIFT) | \ + (0 DV_DDR_SDTMR2_XP_SHIFT) | \ + (0 DV_DDR_SDTMR2_ODT_SHIFT) |\ + (17 DV_DDR_SDTMR2_XSNR_SHIFT) | \ + (199 DV_DDR_SDTMR2_XSRD_SHIFT) | \ + (0 DV_DDR_SDTMR2_RTP_SHIFT) |\ + (0 DV_DDR_SDTMR2_CKE_SHIFT)) Last time I guess I wasn't clear enough, sorry, there's 0 shifts other places I disagree with two. I really think in some cases we're best off just saying Please look at the ... section of the TRM for this part for an explanation of all bit fields. and not calculate or'ing in 0 here or there. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ARM]: File type for u-boot elf file
On Mon, Dec 5, 2011 at 2:19 AM, rojan rojan@bpltelecom.com wrote: I have OMAP L138 Hawkboard which is loaded with some other program. I am new to this hawkboard and tried to boot as per instructions from user guide in http://www.hawkboard.org/ , system is not coming to hawkboard.org to access command. It is coming as follows. Please help me to make it ready. Switch positions made as follows Pin1 = ON Pin2 = OFF Pin3 = OFF Pin4 = OFF Terminal data as follows: U-Boot 2009.01-dirty (Nov 26 2009 - 02:15:00) DRAM: 128 MB NAND: NAND device: Manufacturer ID: 0x2c, Chip ID: 0xa1 (Micron NAND 128MiB 1,8 V 8-bit) Bad block table found at page 65472, version 0x01 Bad block table found at page 65408, version 0x01 nand_read_bbt: Bad block at 0x0350 nand_read_bbt: Bad block at 0x049a 128 MiB In: serial Out: serial Err: serial ARM Clock : 3 Hz DDR Clock : 15000 Hz Ethernet PHY: GENERIC @ 0x07 Hit any key to stop autoboot: 0 During this countdown you need to 'hit any key' to stop the boot from happening and give you the U-Boot prompt. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/9] arch/arm/cpu/armv7/omap-common/clocks-common.c: Fix GCC 4.6 warnings
On Mon, 5 Dec 2011 08:02:53 -0700
Tom Rini tr...@ti.com wrote:
On 12/03/2011 09:46 AM, Anatolij Gustschin wrote:
Fix:
clocks-common.c: In function 'setup_dplls':
clocks-common.c:256:6: warning: variable 'sysclk_ind' set but not used
[-Wunused-but-set-variable]
clocks-common.c: In function 'setup_non_essential_dplls':
clocks-common.c:292:6: warning: variable 'sysclk_ind' set but not used
[-Wunused-but-set-variable]
Signed-off-by: Anatolij Gustschin ag...@denx.de
Cc: sricharan r.sricha...@ti.com
Cc: Tom Rini tr...@ti.com
---
arch/arm/cpu/armv7/omap-common/clocks-common.c |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c
b/arch/arm/cpu/armv7/omap-common/clocks-common.c
index 1e7e20e..1da90a4 100644
--- a/arch/arm/cpu/armv7/omap-common/clocks-common.c
+++ b/arch/arm/cpu/armv7/omap-common/clocks-common.c
@@ -253,11 +253,10 @@ void configure_mpu_dpll(void)
static void setup_dplls(void)
{
- u32 sysclk_ind, temp;
+ u32 temp;
const struct dpll_params *params;
- debug(setup_dplls\n);
- sysclk_ind = get_sys_clk_index();
+ debug(setup_dplls\n);
/* CORE dpll */
params = get_core_dpll_params();/* default - safest */
Hand-editing the diffs? Not sure why the debug print looks like it
moved. But regardless...
No, not this time. I moved the debug print intentionally to fix the
coding style, while at it. It doesn't make sense to send separate
patch for this coding style fix. I should have mentioned this in the
commit log, sorry.
Thanks for review!
Anatolij
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] global_data: unify global flag defines
On Monday 05 December 2011 00:47:12 Graeme Russ wrote: Hi Mike, On Mon, Dec 5, 2011 at 5:39 PM, Mike Frysinger vap...@gentoo.org wrote: On Sunday 04 December 2011 22:47:59 Graeme Russ wrote: On Mon, Dec 5, 2011 at 2:43 PM, Mike Frysinger wrote: +/* + * Base for arches to start adding their own: + * #define GD_FLG_FOO (GD_FLG_ARCH_BASE 0) + * #define GD_FLG_BAR (GD_FLG_ARCH_BASE 1) + * #define GD_FLG_COW (GD_FLG_ARCH_BASE 2) + */ +#define GD_FLG_ARCH_BASE 0x00100 + +#endif This doesn't leave any room for new standard flags - flags is a u32, so why not define the low 16 bits as standard and the high 16 bit as arch specific - Maybe even split the high 16 bits into low 8 bits for arch specific, high 8 bits for board specific? when we add a new common flag, we simply update GD_FLG_ARCH_BASE. i don't see the need for this complexity. So the flags can change depending on the build - What is the implication for stand-alone apps (we have gone over the impact of changing gd before without a 100% concrete conclusion) i did go through the research effort and posted all the details: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/114029 but no one responded And you must rember to update GD_FLG_ARCH_BASE if anyone adds a new flag - Not immediately obvious (no comments to that effect) i can add a comment I don't see any complexity in: #define GD_FLG_ARCH_BASE 0x0001 #define GD_FLG_BOARD_BASE 0x0100 Gives us 16 common flags (we have only used 8 so far) 8 arch flags and 8 board flags i'm fine with simply adding defines and leaving the rest up to people. but adding any additional macro code is overkill imo. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT PULL] Pull request: u-boot-imx
Hi Stefano, Le 01/12/2011 17:14, Stefano Babic a écrit : Hi Albert, please pull from u-boot-imx, thanks. The following changes since commit 3be4bab07b614c23f3bffaa6febca9a5a2c4dfa6: vision2: Fix checkpatch warning (2011-11-28 13:10:36 +0100) are available in the git repository at: git://www.denx.de/git/u-boot-imx.git master Fabio Estevam (5): mx53loco: Configure the pins as GPIOs prior to using gpio_get_value mx53ard: Configure the pins as GPIOs prior to using gpio_get_value mx53evk: Configure the pins as GPIOs prior to using gpio_get_value mx53smd: Configure the pins as GPIOs prior to using gpio_get_value mx51evk: Configure the pins as GPIOs prior to using gpio_get_value Marek Vasut (3): MC13892: Add REGMODE0 bits definitions Efika: Configure additional regulators for HDMI output MXS: Add static annotations to dma driver Robert Deliën (1): M28: Fix OB1 bug in GPIO driver Simon Glass (1): mx5: Correct a warning in clock.c Stefano Babic (2): MX: serial_mxc: cleanup removing nasty #ifdef MX35: flea3: changes due to hardware revision B Wolfram Sang (1): apbh_dma: return error value on timeout Hmm... Your master is based on my next, not on my master. Do you intend me to add these onto my 'next' or 'master' branch? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-pxa / master
Hi Marek,
Le 02/12/2011 11:11, Marek Vasut a écrit :
I see no comments on my patchset for a while, so:
The following changes since commit f2695a272849764cda09bcce6f86d03105e9e46d:
PXA: Drop XM250 board (2011-11-25 20:44:24 +0100)
are available in the git repository at:
git://git.denx.de/u-boot-pxa.git master
Marek Vasut (19):
PXA: Rework start.S to be closer to other ARMs
PXA: Re-add the Dcache locking as RAM for pxa250
PXA: Fixup PXA25x boards after start.S update
PXA: Drop Voipac PXA270 OneNAND IPL
PXA: Adapt Voipac PXA270 to OneNAND SPL
PXA: Enable command line editing for vpac270
PXA: Unify vpac270 environment size
PXA: Rename CONFIG_PXA2[57]X to CONFIG_CPU_PXA2[57]X
PXA: Separate PXA2xx CPU init
PXA: Add cpuinfo display for PXA2xx
PXA: Replace timer driver
PXA: Cleanup Colibri PXA270
PXA: Export cpu_is_ and pxa_dram_init functions
PXA: Squash extern pxa_dram_init()
PXA: Rename pxa_dram_init to pxa2xx_dram_init
PXA: Introduce common configuration header for PXA
PXA: Flip colibri_pxa27x to pxa-common.h
PXA: Move colibri_pxa270 to board/toradex/
GCC4.6: PXA: Squash warning in xaeniax
arch/arm/cpu/pxa/Makefile |7 +-
arch/arm/cpu/pxa/cpuinfo.c | 132 ++
arch/arm/cpu/pxa/{cpu.c = pxa2xx.c} | 119 ++
arch/arm/cpu/pxa/start.S | 456 ++--
arch/arm/cpu/pxa/timer.c | 91 ++---
arch/arm/cpu/pxa/u-boot.lds|6 +
arch/arm/cpu/pxa/usb.c | 12 +-
arch/arm/include/asm/arch-pxa/pxa-regs.h | 48 +-
.../arm/include/asm/arch-pxa/pxa.h | 31 +-
board/balloon3/balloon3.c |4 +-
board/lubbock/lubbock.c|4 +-
board/palmld/palmld.c |4 +-
board/palmtc/palmtc.c |4 +-
board/pxa255_idp/pxa_idp.c |4 +-
board/{ = toradex}/colibri_pxa270/Makefile|0
.../{ = toradex}/colibri_pxa270/colibri_pxa270.c | 36 +-
board/trizepsiv/conxs.c|4 +-
board/vpac270/Makefile |4 +
board/vpac270/onenand.c| 65 +++
board/vpac270/u-boot-spl.lds | 92
board/vpac270/vpac270.c|6 +-
board/xaeniax/flash.c |7 +-
board/xaeniax/xaeniax.c|4 +-
board/zipitz2/zipitz2.c|4 +-
boards.cfg |2 +-
common/lcd.c | 14 +-
drivers/mmc/pxa_mmc.c |7 +-
drivers/mmc/pxa_mmc_gen.c |4 +-
drivers/net/lan91c96.h |4 +-
drivers/net/smc9.h |6 +-
drivers/serial/serial_pxa.c|4 +-
drivers/serial/usbtty.h|2 +-
drivers/usb/gadget/Makefile|2 +-
include/configs/balloon3.h |2 +-
include/configs/colibri_pxa270.h | 103 ++---
include/configs/lubbock.h |4 +-
include/configs/palmld.h |2 +-
include/configs/palmtc.h |4 +-
include/configs/pxa-common.h | 60 +++
include/configs/pxa255_idp.h |4 +-
include/configs/trizepsiv.h|2 +-
include/configs/vpac270.h | 43 ++-
include/configs/xaeniax.h |4 +-
include/configs/zipitz2.h |2 +-
include/lcd.h |5 +-
onenand_ipl/board/vpac270/Makefile | 79
onenand_ipl/board/vpac270/config.mk|1 -
onenand_ipl/board/vpac270/u-boot.onenand.lds | 51 ---
48 files changed, 851 insertions(+), 704 deletions(-)
create mode 100644 arch/arm/cpu/pxa/cpuinfo.c
rename arch/arm/cpu/pxa/{cpu.c = pxa2xx.c} (76%)
rename onenand_ipl/board/vpac270/vpac270.c = arch/arm/include/asm/arch-
pxa/pxa.h (54%)
rename board/{ = toradex}/colibri_pxa270/Makefile (100%)
rename board/{ = toradex}/colibri_pxa270/colibri_pxa270.c (81%)
create mode 100644 board/vpac270/onenand.c
create mode 100644 board/vpac270/u-boot-spl.lds
create mode 100644 include/configs/pxa-common.h
delete mode 100644 onenand_ipl/board/vpac270/Makefile
delete mode 100644 onenand_ipl/board/vpac270/config.mk
delete mode 100644
Re: [U-Boot] [PATCH v6] arm, arm926ejs: Fix clear bss loop for zero length bss
Hi Christian, Le 01/12/2011 09:27, Christian Riesch a écrit : This patch fixes the clear bss loop for bss sections that have zero length, i.e., where __bss_start == __bss_end__. Signed-off-by: Christian Rieschchristian.rie...@omicron.at Cc: Albert Aribaudalbert.u.b...@aribaud.net --- Hi, this is v6 of a patch out of my recent patchset [PATCH v3 00/15] Add an SPL to boot the da850evm from SPI http://lists.denx.de/pipermail/u-boot/2011-November/82.html Changes for v6: - replace beq clbss_e to allow for cases where r1-r0 is not a multiple of 4, as suggested by Albert Aribaud. Changes for v5: - correct subject line Changes for v4: - split the patchset since it is getting quite big Regards, Christian arch/arm/cpu/arm926ejs/start.S |8 +--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S index 8b5355b..6a09c02 100644 --- a/arch/arm/cpu/arm926ejs/start.S +++ b/arch/arm/cpu/arm926ejs/start.S @@ -299,10 +299,12 @@ clear_bss: #endif mov r2, #0x /* clear*/ -clbss_l:strr2, [r0]/* clear loop...*/ +clbss_l:cmpr0, r1 /* clear loop... */ + bhs clbss_e /* if reached end of bss, exit */ + str r2, [r0] add r0, r0, #4 - cmp r0, r1 - bne clbss_l + b clbss_l +clbss_e: #ifndef CONFIG_SPL_BUILD bl coloured_LED_init Applied to u-boot-arm/master, thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ti/master
Hi Tom, Le 29/11/2011 23:53, Tom Rini a écrit : The following changes since commit f2695a272849764cda09bcce6f86d03105e9e46d: Marek Vasut (1): PXA: Drop XM250 board are available in the git repository at: git://git.denx.de/u-boot-ti.git master Anatolij Gustschin (1): ARM: davinci_dm6467Tevm: Fix build breakage Aneesh V (13): armv7: disable L2 cache in cleanup_before_linux() armv7: include armv7/cpu.c in SPL build armv7: setup vector start.S: remove omap3 specific code from start.S omap: Improve PLL parameter calculation tool omap4: ttyO2 instead of ttyS2 in default bootargs omap: fix cache line size for omap3/omap4 boards omap4460: fix TPS initialization omap: remove I2C from SPL omap4: emif: fix error in driver omap4460: add ES1.1 identification omap4+: streamline CONFIG_SYS_TEXT_BASE and other SDRAM addresses omap4: fix IO setting Christian Riesch (8): arm, davinci: Move pinmux functions from board to arch tree arm, hawkboard: Remove obsolete struct pinmux_config i2c_pins arm, da850evm: Do pinmux configuration for EMAC together with other pinmuxes arm, da850: Add pinmux configurations to the arch tree arm, da850evm: Use the pinmux configurations defined in the arch tree arm, hawkboard: Use the pinmux configurations defined in the arch tree arm, davinci: Remove duplication of pinmux configuration code arm: printf() is not available in some SPL configurations Heiko Schocher (6): arm, arm926ejs: always do cpu critical inits arm, davinci: move davinci_rtc struct to hardware.h arm, davinci, da850: add uart1 tx rx pinmux config arm, board/davinci/common/misc.c: Codingstyle cleanup arm, davinci: move misc function in arch tree arm, davinci: add support for am1808 based enbw_cmc board Ilya Yanok (10): davinci_emac: move arch-independent defines to separate header davinci_emac: use internal addresses in buffer descriptors davinci_emac: conditionally compile specific PHY support arm926ejs: add noop implementation for dcache ops davinci_emac: fix for running with dcache enabled davinci_emac: hardcode 100Mbps for AM35xx and RMII AM35xx: add EMAC support AM3517: move AM3517 specific mux defines to generic header nand_spl_simple: add support for software ECC omap_gpmc: use SOFTECC in SPL if it's enabled Koen Kooi (1): BeagleBoard: config: Really switch to ttyO2 Prabhakar Lad (1): ARM: davici_emac: Fix condition for number of phy detects Thomas Weber (3): ARM: OMAP3: Remove unused define CONFIG_OMAP3430 ARM: OMAP3: Remove unused define SDRC_R_C_B ARM: OMAP: Remove STACKSIZE for IRQ and FIQ if unused Tom Rini (15): omap3: mem: Comment enable_gpmc_cs_config more OMAP3: Update SDRC dram_init to always call make_cs1_contiguous() OMAP3: Add a helper function to set timings in SDRC OMAP3: Change mem_ok to clear again after reading back OMAP3: Remove get_mem_type prototype omap3: mem: Add MCFG helper macro OMAP3: Add optimal SDRC autorefresh control values OMAP3: Suffix all Micron memory timing parts with their speed OMAP3 SPL: Rework memory initalization and devkit8000 support OMAP3 SPL: Add identify_nand_chip function OMAP3: Add SPL support to Beagleboard OMAP3: Add SPL support to omap3_evm AM3517: Add SPL support AM3517 CraneBoard: Add SPL support OMAP3: Add SPL_BOARD_INIT hook Applied to u-boot-arm/master, thanks. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] undefined reference to `abort'
This is a follow-up to my issue, re: /opt/embedded/tools/usr/bin/../lib/gcc/powerpc-linux/4.2.2/m8540/libgcc.a(divsf3.o): In function `__divsf3': /opt/eldk/build/ppc-2008-04-01/work/usr/src/denx/BUILD/crosstool-0.43/build/gcc-4.2.2-glibc-20070515T2025-eldk/powerpc-linux/gcc-4.2.2/gcc/config/soft-fp/divsf3.c:44: undefined reference to `abort' /opt/embedded/tools/usr/bin/../lib/gcc/powerpc-linux/4.2.2/m8540/libgcc.a(mulsf3.o): In function `__mulsf3': /opt/eldk/build/ppc-2008-04-01/work/usr/src/denx/BUILD/crosstool-0.43/build/gcc-4.2.2-glibc-20070515T2025-eldk/powerpc-linux/gcc-4.2.2/gcc/config/soft-fp/mulsf3.c:44: undefined reference to `abort' /opt/embedded/tools/usr/bin/../lib/gcc/powerpc-linux/4.2.2/m8540/libgcc.a(divdf3.o): In function `__divdf3': /opt/eldk/build/ppc-2008-04-01/work/usr/src/denx/BUILD/crosstool-0.43/build/gcc-4.2.2-glibc-20070515T2025-eldk/powerpc-linux/gcc-4.2.2/gcc/config/soft-fp/divdf3.c:44: undefined reference to `abort' /opt/embedded/tools/usr/bin/../lib/gcc/powerpc-linux/4.2.2/m8540/libgcc.a(muldf3.o): In function `__muldf3': /opt/eldk/build/ppc-2008-04-01/work/usr/src/denx/BUILD/crosstool-0.43/build/gcc-4.2.2-glibc-20070515T2025-eldk/powerpc-linux/gcc-4.2.2/gcc/config/soft-fp/muldf3.c:44: undefined reference to `abort' It was suggested that I should migrate to a newer version of u-boot to resolve the issue. I downloaded and compiled with u-boot-2011.03-rc and the compiler reported the same errors. We thought that maybe the rc release was not the best choice so we tried the port with u-boot 1.3.1. and again, got the same compile errors. I did a little more digging and found that anywhere that I perform a multiply or divide operation using a float variable, the code will compile as a muldf3 or divdf3 call. So, I'm guessing that the libgcc in ELDK4.2.2 differs from that in ELDK 4.0. Is there some option I need to add to the compile expression in the Makefile to satisfy the new libgcc-floating math functions? Thank you in advance for your assistance, Bill. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/9] arch/arm/cpu/armv7/omap-common/clocks-common.c: Fix GCC 4.6 warnings
On 12/05/2011 09:32 AM, Anatolij Gustschin wrote:
On Mon, 5 Dec 2011 08:02:53 -0700
Tom Rini tr...@ti.com wrote:
On 12/03/2011 09:46 AM, Anatolij Gustschin wrote:
Fix:
clocks-common.c: In function 'setup_dplls':
clocks-common.c:256:6: warning: variable 'sysclk_ind' set but not used
[-Wunused-but-set-variable]
clocks-common.c: In function 'setup_non_essential_dplls':
clocks-common.c:292:6: warning: variable 'sysclk_ind' set but not used
[-Wunused-but-set-variable]
Signed-off-by: Anatolij Gustschin ag...@denx.de
Cc: sricharan r.sricha...@ti.com
Cc: Tom Rini tr...@ti.com
---
arch/arm/cpu/armv7/omap-common/clocks-common.c |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c
b/arch/arm/cpu/armv7/omap-common/clocks-common.c
index 1e7e20e..1da90a4 100644
--- a/arch/arm/cpu/armv7/omap-common/clocks-common.c
+++ b/arch/arm/cpu/armv7/omap-common/clocks-common.c
@@ -253,11 +253,10 @@ void configure_mpu_dpll(void)
static void setup_dplls(void)
{
- u32 sysclk_ind, temp;
+ u32 temp;
const struct dpll_params *params;
- debug(setup_dplls\n);
- sysclk_ind = get_sys_clk_index();
+ debug(setup_dplls\n);
/* CORE dpll */
params = get_core_dpll_params();/* default - safest */
Hand-editing the diffs? Not sure why the debug print looks like it
moved. But regardless...
No, not this time. I moved the debug print intentionally to fix the
coding style, while at it. It doesn't make sense to send separate
patch for this coding style fix. I should have mentioned this in the
commit log, sorry.
Ah, OK, now I see it, thanks (and will still merge as-is).
--
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] arm, arm926ejs: always do cpu critical inits
Le 29/11/2011 20:27, Tom Rini a écrit : On Wed, Nov 9, 2011 at 11:06 PM, Heiko Schocherh...@denx.de wrote: always do the cpu critical inits in cpu_init_crit, and only jump to lowlevel_init, if CONFIG_SKIP_LOWLEVEL_INIT is not defined. Signed-off-by: Heiko Schocherh...@denx.de Cc: Albert ARIBAUDalbert.u.b...@aribaud.net Cc: Wolfgang Denkh...@denx.de Cc: Sandeep Paulrajs-paul...@ti.com Cc: Tom Rinitom.r...@gmail.com Cc: Christian Rieschchristian.rie...@omicron.at (Will be) queued to u-boot-ti, thanks. Hmm... This commit alters the effect of CONFIG_SKIP_LOWLEVEL_INIT without making it possible to recreate it through configuration -- you now have to alter the source code to get the same effect as before. I'd prefer the CPU init crit code to be kept under a config option, and another option to be added for finer control. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT PULL] Pull request: u-boot-imx
On 05/12/2011 17:57, Albert ARIBAUD wrote: Hmm... Your master is based on my next, not on my master. Do you intend me to add these onto my 'next' or 'master' branch? Sorry, I have applied the wrong script, I presume. I will send a new pull request soon. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [GIT PULL] Pull request: u-boot-imx
Hi Albert, please pull from u-boot-imx (this time rebased on u-boot-arm/master..) The following changes since commit d4870a914b73884f2f3e8fb082ae50f75fc01ebc: arm, arm926ejs: Fix clear bss loop for zero length bss (2011-12-05 18:03:51 +0100) are available in the git repository at: git://www.denx.de/git/u-boot-imx.git master Fabio Estevam (5): mx53loco: Configure the pins as GPIOs prior to using gpio_get_value mx53ard: Configure the pins as GPIOs prior to using gpio_get_value mx53evk: Configure the pins as GPIOs prior to using gpio_get_value mx53smd: Configure the pins as GPIOs prior to using gpio_get_value mx51evk: Configure the pins as GPIOs prior to using gpio_get_value Marek Vasut (3): MC13892: Add REGMODE0 bits definitions Efika: Configure additional regulators for HDMI output MXS: Add static annotations to dma driver Robert Deliën (1): M28: Fix OB1 bug in GPIO driver Simon Glass (1): mx5: Correct a warning in clock.c Stefano Babic (2): MX: serial_mxc: cleanup removing nasty #ifdef MX35: flea3: changes due to hardware revision B Wolfram Sang (1): apbh_dma: return error value on timeout arch/arm/cpu/arm1136/mx31/devices.c |4 - arch/arm/cpu/armv7/mx5/clock.c|2 +- arch/arm/include/asm/arch-mx25/imx-regs.h | 10 +- arch/arm/include/asm/arch-mx27/imx-regs.h |8 +- arch/arm/include/asm/arch-mx28/dma.h | 25 arch/arm/include/asm/arch-mx31/imx-regs.h |6 + arch/arm/include/asm/arch-mx35/imx-regs.h |6 +- arch/arm/include/asm/arch-mx5/imx-regs.h |6 +- board/CarMediaLab/flea3/flea3.c |4 +- board/efikamx/efikamx.c | 15 ++- board/freescale/mx51evk/mx51evk.c |3 + board/freescale/mx53ard/mx53ard.c |3 + board/freescale/mx53evk/mx53evk.c |3 + board/freescale/mx53loco/mx53loco.c |3 + board/freescale/mx53smd/mx53smd.c |1 + drivers/dma/apbh_dma.c| 211 +++-- drivers/gpio/mxs_gpio.c |2 +- drivers/serial/serial_mxc.c | 37 +- include/configs/efikamx.h |2 +- include/configs/flea3.h | 22 ++-- include/configs/imx27lite-common.h|2 +- include/configs/imx31_litekit.h |4 +- include/configs/imx31_phycore.h |2 +- include/configs/mx25pdk.h |2 +- include/configs/mx31ads.h |4 +- include/configs/mx31pdk.h |2 +- include/configs/mx35pdk.h |2 +- include/configs/mx51evk.h |2 +- include/configs/mx53ard.h |2 +- include/configs/mx53evk.h |2 +- include/configs/mx53loco.h|2 +- include/configs/mx53smd.h |2 +- include/configs/qong.h|4 +- include/configs/tt01.h|2 +- include/configs/tx25.h|2 +- include/configs/vision2.h |2 +- include/configs/zmx25.h |2 +- include/mc13892.h | 16 +++ 38 files changed, 153 insertions(+), 276 deletions(-) -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT PULL] Pull request: u-boot-imx
Hi Stefano, Le 05/12/2011 18:22, Stefano Babic a écrit : Hi Albert, please pull from u-boot-imx (this time rebased on u-boot-arm/master..) The following changes since commit d4870a914b73884f2f3e8fb082ae50f75fc01ebc: arm, arm926ejs: Fix clear bss loop for zero length bss (2011-12-05 18:03:51 +0100) are available in the git repository at: git://www.denx.de/git/u-boot-imx.git master Fabio Estevam (5): mx53loco: Configure the pins as GPIOs prior to using gpio_get_value mx53ard: Configure the pins as GPIOs prior to using gpio_get_value mx53evk: Configure the pins as GPIOs prior to using gpio_get_value mx53smd: Configure the pins as GPIOs prior to using gpio_get_value mx51evk: Configure the pins as GPIOs prior to using gpio_get_value Marek Vasut (3): MC13892: Add REGMODE0 bits definitions Efika: Configure additional regulators for HDMI output MXS: Add static annotations to dma driver Robert Deliën (1): M28: Fix OB1 bug in GPIO driver Simon Glass (1): mx5: Correct a warning in clock.c Stefano Babic (2): MX: serial_mxc: cleanup removing nasty #ifdef MX35: flea3: changes due to hardware revision B Wolfram Sang (1): apbh_dma: return error value on timeout Applied tu u-boot-arm/master, thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] undefined reference to `abort'
On Monday 05 December 2011 11:43:09 Shadid, Bill wrote: /opt/embedded/tools/usr/bin/../lib/gcc/powerpc-linux/4.2.2/m8540/libgcc.a(d ivsf3.o): In function `__divsf3': /opt/eldk/build/ppc-2008-04-01/work/usr/src/denx/BUILD/crosstool-0.43/buil d/gcc-4.2.2-glibc-20070515T2025-eldk/powerpc-linux/gcc-4.2.2/gcc/config/sof t-fp/divsf3.c:44: undefined reference to `abort' looks like you should be using a diff cross-compiler. or ppc should grow private libgcc support. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] having trouble booting a simple kernel on a TQM860 board
On Mon, 5 Dec 2011, Wolfgang Denk wrote: Dear Robert, In message alpine.DEB.2.02.1112050701340.21244@oneiric you wrote: No. Now you don't need a cuImage nay more. Just use the DT as I showed you in the builkd and boot log I sent before. for the sake of clarification, you write that i don't *need* cuImages anymore, but that's not the same as saying that i *must* move to using device trees. in fact, a cuImage file still works just fine True, you don't have to use the DT. You don't have to use the most straightforward way that has been well tested for a ton of combinations of recent U-Boot releases against recent kernel releases. You are free to chose any untested, unsupported way you like. It's perfectly fine to ignore all good advice you get here. But eventually you should then also stop asking further questions here. please stop being so defensive, wolfgang, it doesn't become you. i have no doubt that using a separate device tree is a better idea. but i also like to be very careful with my terminology. if someone says using a device tree is better, i'm fine with that. but an earlier claim of yours seemed to suggest that one *needed* to use a DT, and if that's the case, i just want to know that. i simply like to know what my options are in case Plan A doesn't work, i can try Plan B. also, i was *given* material to work with, and i'm making an effort to change as little of it as possible if i don't have to, at the request of the person who gave it to me. and sometimes, political reasons might trump technical reasons, as much as we don't want them to. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] undefined reference to `abort'
Am 05.12.2011 18:28, schrieb Mike Frysinger: On Monday 05 December 2011 11:43:09 Shadid, Bill wrote: /opt/embedded/tools/usr/bin/../lib/gcc/powerpc-linux/4.2.2/m8540/libgcc.a(d ivsf3.o): In function `__divsf3': /opt/eldk/build/ppc-2008-04-01/work/usr/src/denx/BUILD/crosstool-0.43/buil d/gcc-4.2.2-glibc-20070515T2025-eldk/powerpc-linux/gcc-4.2.2/gcc/config/sof t-fp/divsf3.c:44: undefined reference to `abort' looks like you should be using a diff cross-compiler. or ppc should grow private libgcc support. -mike Or just don't use any floating point operations in a bootloader. There seems to be some usages of floats around in u-boot but most (all?) of them are compile time calculations. Just curious: Bill, what is the use case for float at runtime? Matthias ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [ARM] Pending patches for december release?
Hi all, As I don't have much time and the december release is coming soon, I would appreciate that anyone with a patch that they think should go to ARM master now please send me an e-mail with the link to the patchwork patch page so that I delegate the patch to myself. If the patch is already delegated to me, then nothing need be done. Of course, if you can directly delegate a patchwork patch to me, just do so. Patches than can go into ARM master now are: - build fixes and bug fixes submitted even after merge window close; - other patches if their 1st version was submitted before merge window close. Thanks in advance for your kind help! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ARM] Pending patches for december release?
On Mon, Dec 5, 2011 at 11:05 AM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi all, As I don't have much time and the december release is coming soon, I would appreciate that anyone with a patch that they think should go to ARM master now please send me an e-mail with the link to the patchwork patch page so that I delegate the patch to myself. If the patch is already delegated to me, then nothing need be done. Of course, if you can directly delegate a patchwork patch to me, just do so. Patches than can go into ARM master now are: - build fixes and bug fixes submitted even after merge window close; - other patches if their 1st version was submitted before merge window close. Thanks in advance for your kind help! There is a v2 of the devkit8000+SPL+MMC bugfix that I am expecting RSN now and if it doesn't appear in another day or so I'll just v2 myself (it was expanding the comment really) and put into u-boot-ti for you, along with gcc 4.6 related warning fixes. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] undefined reference to `abort'
I've added a test suite to the build that can be accessed while at the u-boot prompt. The suite allows folks to verify various h/w components without running an OS. The suite contains some algorithms to convert sensor data to voltage, current, power and temperature. I can modify some of these calculations to use integer math instead but in 1 case there is a polynomial with larger exponents. I'm almost ready to give up, so this is my last stab at resolving the issue. Its surprising that this code compiled and ran fine with ELDK 4.0 but has compile issues with 4.2. I guess some floating-point support was removed. I'm still not clear why the abort function is called and I say called because when we do throw in our own abort function that calls printf or forever loops, its gets executed and hangs u-boot. Thanks for your help, Bill. -Original Message- From: Matthias Weißer [mailto:m.weisse...@googlemail.com] Sent: December 5, 2011 12:57 PM To: Mike Frysinger Cc: u-boot@lists.denx.de; Shadid, Bill Subject: Re: [U-Boot] undefined reference to `abort' Am 05.12.2011 18:28, schrieb Mike Frysinger: On Monday 05 December 2011 11:43:09 Shadid, Bill wrote: /opt/embedded/tools/usr/bin/../lib/gcc/powerpc-linux/4.2.2/m8540/libg cc.a(d ivsf3.o): In function `__divsf3': /opt/eldk/build/ppc-2008-04-01/work/usr/src/denx/BUILD/crosstool-0.43 /buil d/gcc-4.2.2-glibc-20070515T2025-eldk/powerpc-linux/gcc-4.2.2/gcc/conf ig/sof t-fp/divsf3.c:44: undefined reference to `abort' looks like you should be using a diff cross-compiler. or ppc should grow private libgcc support. -mike Or just don't use any floating point operations in a bootloader. There seems to be some usages of floats around in u-boot but most (all?) of them are compile time calculations. Just curious: Bill, what is the use case for float at runtime? Matthias ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] mtd/nand: Add ONFI support for FSL NAND controller
On 12/03/2011 03:25 AM, Liu Shengzhou-B36685 wrote: -Original Message- From: Wood Scott-B07421 Sent: 2011年12月3日 2:45 To: Liu Shengzhou-B36685 Cc: u-boot@lists.denx.de; Gala Kumar-B11780 Subject: Re: [PATCH 4/4] mtd/nand: Add ONFI support for FSL NAND controller On 12/02/2011 03:17 AM, Shengzhou Liu wrote: + case NAND_CMD_PARAM: + dbg(fsl_elbc_cmdfunc: NAND_CMD_PARAM.\n); + out_be32(lbc-fir, (FIR_OP_CM0 FIR_OP0_SHIFT) | + (FIR_OP_UA FIR_OP1_SHIFT) | + (FIR_OP_RBW FIR_OP2_SHIFT)); + out_be32(lbc-fcr, NAND_CMD_PARAM FCR_CMD0_SHIFT); + out_be32(lbc-fbcr, 256); + ctrl-read_bytes = 256; + ctrl-use_mdr = 1; + ctrl-mdr = column; + set_addr(mtd, 0, 0, 0); + fsl_elbc_run_command(mtd); + return; This could share code with NAND_CMD_READID -- always read 256 bytes (we'll need to read more than 5 bytes for non-ONFI as well, when we pull in the newer Linux NAND code), and use command FCR_CMD0_SHIFT for FCR. BTW, has anyone tested the eLBC driver with 16-bit NAND? I think our read_byte() implementation is not going to do the right thing here -- it needs to read a 16-bit word when the chip is 16-bit, and discard the upper half. -Scott There was already NAND_CMD_PARAM command which is called in mtd/nand/nand_base.c, it's not new created. NAND_CMD_PARAM is defined in spec, we should not share it with NAND_CMD_READID, if so, we'll have to intrusive to nand_base.c. Huh? All I'm saying is that you could do this in fsl_elbc_nand.c: case NAND_CMD_READID: case NAND_CMD_PARAM: out_be32(lbc-fir, (FIR_OP_CM0 FIR_OP0_SHIFT) | (FIR_OP_UA FIR_OP1_SHIFT) | (FIR_OP_RBW FIR_OP2_SHIFT)); out_be32(lbc-fcr, command FCR_CMD0_SHIFT); out_be32(lbc-fbcr, 256); ctrl-read_bytes = 256; ctrl-use_mdr = 1; ctrl-mdr = column; set_addr(mtd, 0, 0, 0); fsl_elbc_run_command(mtd); return; -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 2/6] sf: Add spi_boot() to allow booting from SPI flash in an SPL
On 12/05/2011 04:58 AM, Christian Riesch wrote: Signed-off-by: Christian Riesch christian.rie...@omicron.at Cc: Heiko Schocher h...@denx.de Cc: Mike Frysinger vap...@gentoo.org Cc: Scott Wood scottw...@freescale.com Acked-by: Mike Frysinger vap...@gentoo.org --- doc/README.SPL |1 + drivers/mtd/spi/Makefile |4 +++ drivers/mtd/spi/spi_spl_load.c | 58 include/spi_flash.h|3 ++ 4 files changed, 66 insertions(+), 0 deletions(-) create mode 100644 drivers/mtd/spi/spi_spl_load.c I'm not sure if you're the one assigning this to me in Patchwork (would be nice if it had a history log), but I'm not the maintainer of SPI, nor of SPL generically -- just NAND. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] undefined reference to `abort'
Dear Shadid, Bill, In message e7f97b349c2a6843b718b2ddf2f9a8f016941...@email.corp.neptec.com you wrote: It was suggested that I should migrate to a newer version of u-boot to resolve the issue. I downloaded and compiled with u-boot-2011.03-rc and the compiler reported the same errors. Would you please be so kind and explain why you decided to consider this a newer version? ANd why you, for example, did not use v2011.09, or later code? We thought that maybe the rc release was not the best choice so we tried the port with u-boot 1.3.1. and again, got the same compile errors. v1.3.1 is more than 4 years old. Please update, and use _recent_ code, i. e. at least v2011.09, or later. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de What the scientists have in their briefcases is terrifying. - Nikita Khrushchev ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 2/6] sf: Add spi_boot() to allow booting from SPI flash in an SPL
On Monday 05 December 2011 14:33:40 Scott Wood wrote:
On 12/05/2011 04:58 AM, Christian Riesch wrote:
Signed-off-by: Christian Riesch christian.rie...@omicron.at
Cc: Heiko Schocher h...@denx.de
Cc: Mike Frysinger vap...@gentoo.org
Cc: Scott Wood scottw...@freescale.com
Acked-by: Mike Frysinger vap...@gentoo.org
---
doc/README.SPL |1 +
drivers/mtd/spi/Makefile |4 +++
drivers/mtd/spi/spi_spl_load.c | 58
include/spi_flash.h
|3 ++
4 files changed, 66 insertions(+), 0 deletions(-)
create mode 100644 drivers/mtd/spi/spi_spl_load.c
I'm not sure if you're the one assigning this to me in Patchwork (would
be nice if it had a history log), but I'm not the maintainer of SPI, nor
of SPL generically -- just NAND.
i don't plan on running these through my SPI branch ... seems like it should
go through the SPL with everything else here.
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] having trouble booting a simple kernel on a TQM860 board
Dear Robert, In message alpine.DEB.2.02.1112051242090.4383@oneiric you wrote: True, you don't have to use the DT. You don't have to use the most straightforward way that has been well tested for a ton of combinations of recent U-Boot releases against recent kernel releases. You are free to chose any untested, unsupported way you like. ... please stop being so defensive, wolfgang, it doesn't become you. i have no doubt that using a separate device tree is a better idea. but i also like to be very careful with my terminology. I was very careful, actually. if someone says using a device tree is better, i'm fine with that. but an earlier claim of yours seemed to suggest that one *needed* to use a DT, and if that's the case, i just want to know that. i simply like to know what my options are in case Plan A doesn't work, i can try Plan B. I told you, several times, and I repeat it here again, for the last time, promised: If you want to have an easy start, use a separate device tree. This is what has been tested all the time, and what is known to be working. If you go for cuImage, this is completely untested code on TQM8xx, and you are on your own - this may work, but it is more likely that it doesn't. Your choice. also, i was *given* material to work with, and i'm making an effort to change as little of it as possible if i don't have to, at the request of the person who gave it to me. and sometimes, political reasons might trump technical reasons, as much as we don't want them to. You already updated U-Boot successfully, so there is no need to continue trying cuImages. But it's your choice. Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It is easier to change the specification to fit the program than vice versa. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 2/6] sf: Add spi_boot() to allow booting from SPI flash in an SPL
On Mon, Dec 5, 2011 at 12:56 PM, Mike Frysinger vap...@gentoo.org wrote: On Monday 05 December 2011 14:33:40 Scott Wood wrote: On 12/05/2011 04:58 AM, Christian Riesch wrote: Signed-off-by: Christian Riesch christian.rie...@omicron.at Cc: Heiko Schocher h...@denx.de Cc: Mike Frysinger vap...@gentoo.org Cc: Scott Wood scottw...@freescale.com Acked-by: Mike Frysinger vap...@gentoo.org --- doc/README.SPL | 1 + drivers/mtd/spi/Makefile | 4 +++ drivers/mtd/spi/spi_spl_load.c | 58 include/spi_flash.h | 3 ++ 4 files changed, 66 insertions(+), 0 deletions(-) create mode 100644 drivers/mtd/spi/spi_spl_load.c I'm not sure if you're the one assigning this to me in Patchwork (would be nice if it had a history log), but I'm not the maintainer of SPI, nor of SPL generically -- just NAND. i don't plan on running these through my SPI branch ... seems like it should go through the SPL with everything else here. How about this? I don't see SPL nor SPI on the Custodians page, but there is TI and this is SPL for DaVinci (TI) stuff, so once everyone is happy with the whole series I'll take this for u-boot-ti/master and try for v2011.12 (since this series has been around for a while). -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] undefined reference to `abort'
Dear Shadid, Bill, In message e7f97b349c2a6843b718b2ddf2f9a8f016941...@email.corp.neptec.com you wrote: Its surprising that this code compiled and ran fine with ELDK 4.0 but has compile issues with 4.2. I guess some floating-point support was removed. I'm still not clear why the abort function is called and I say called because when we do throw in our own abort function that calls printf or forever loops, its gets executed and hangs u-boot. On contrary. ELDK 4.2 added VFP floating point support, so now you are actually generating such code while before with ELDk 4.0 everything was soft-float. Fact is, U-Boot does not support floating point code. Don't use it. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Einstein argued that there must be simplified explanations of nature, because God is not capricious or arbitrary. No such faith comforts the software engineer. - Fred Brooks, Jr. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 0/6] Add an SPL to boot the da850evm from SPI
On Mon, Dec 5, 2011 at 3:58 AM, Christian Riesch christian.rie...@omicron.at wrote: Hi, this is v5 of the last part of my recent patchset Following on to my last email in 2/6 of the series, if there's no objections other than mine about commenting and not doing 0 bit shifts, and that's an agreeable change, if there's no other objections within 24h I'll put the series into u-boot-ti/master and send a pull request to Albert. Thanks! -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] global_data: unify global flag defines
Hi Mike, On Dec 6, 2011 3:44 AM, Mike Frysinger vap...@gentoo.org wrote: On Monday 05 December 2011 00:47:12 Graeme Russ wrote: Hi Mike, On Mon, Dec 5, 2011 at 5:39 PM, Mike Frysinger vap...@gentoo.org wrote: On Sunday 04 December 2011 22:47:59 Graeme Russ wrote: On Mon, Dec 5, 2011 at 2:43 PM, Mike Frysinger wrote: +/* + * Base for arches to start adding their own: + * #define GD_FLG_FOO (GD_FLG_ARCH_BASE 0) + * #define GD_FLG_BAR (GD_FLG_ARCH_BASE 1) + * #define GD_FLG_COW (GD_FLG_ARCH_BASE 2) + */ +#define GD_FLG_ARCH_BASE 0x00100 + +#endif This doesn't leave any room for new standard flags - flags is a u32, so why not define the low 16 bits as standard and the high 16 bit as arch specific - Maybe even split the high 16 bits into low 8 bits for arch specific, high 8 bits for board specific? when we add a new common flag, we simply update GD_FLG_ARCH_BASE. i don't see the need for this complexity. So the flags can change depending on the build - What is the implication for stand-alone apps (we have gone over the impact of changing gd before without a 100% concrete conclusion) i did go through the research effort and posted all the details: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/114029 but no one responded And you must rember to update GD_FLG_ARCH_BASE if anyone adds a new flag - Not immediately obvious (no comments to that effect) i can add a comment I don't see any complexity in: #define GD_FLG_ARCH_BASE 0x0001 #define GD_FLG_BOARD_BASE 0x0100 Gives us 16 common flags (we have only used 8 so far) 8 arch flags and 8 board flags i'm fine with simply adding defines and leaving the rest up to people. but adding any additional macro code is overkill imo. To be honest, I would not even bother with the macro or #define. I would just comment that the low 16 bits are reserved at let arch maintainters manage the upper 16 bits Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-sh
Dear Nobuhiro Iwamatsu, In message CABMQnVKLWn+hPcfFY_Gq=b9xcx1v9rmgk+5zs3mtrkchp1b...@mail.gmail.com you wrote: Dear Wolfgang Denk. Please pull from git://git.denx.de/u-boot-sh master. Best regards, Nobuhiro The following changes since commit 7708d8b352e9e595f6f08afd3206af6495c7dc09= : Merge branch 'master' of ssh://gemini/home/wd/git/u-boot/master (2011-12-02 00:17:49 +0100) are available in the git repository at: git://git.denx.de/u-boot-sh master Mike Frysinger (2): sh: only add -mno-fdpic if the compiler supports it sh: avoid multiple definition errors with cache funcs Nobuhiro Iwamatsu (4): sh: Add a flag which controls the DDR ECC mode of sh7757lcr sh: Add updating method of SPI ROM to README of sh7757lcr sh: Add support Renesas SH7724 sh: Add support for ecovec board Phil Edworthy (1): sh: Add ashrsi3 libgcc function Yoshihiro Shimoda (4): net: sh_eth: use miiphybb instead of own mii functions sh7757lcr: change config for new sh_eth driver sh7763rdp: change config for new sh_eth driver sh: espt: change config for new sh_eth driver MAINTAINERS |1 + arch/sh/cpu/sh2/config.mk |3 +- arch/sh/cpu/sh4/cache.c | 22 +++ arch/sh/include/asm/cache.h | 24 +--- arch/sh/include/asm/cpu_sh4.h |2 + arch/sh/include/asm/cpu_sh7724.h| 234 arch/sh/lib/Makefile|1 + arch/sh/lib/ashrsi3.S | 185 +++ board/renesas/ecovec/Makefile | 38 board/renesas/ecovec/ecovec.c | 124 + board/renesas/ecovec/lowlevel_init.S| 211 ++ board/renesas/sh7757lcr/lowlevel_init.S |3 +- boards.cfg |1 + doc/README.sh7757lcr| 14 ++ drivers/net/sh_eth.c| 293 +++= drivers/net/sh_eth.h| 59 +-- include/configs/ecovec.h| 200 + include/configs/espt.h |4 + include/configs/sh7757lcr.h |5 + include/configs/sh7763rdp.h |4 + 20 files changed, 1157 insertions(+), 271 deletions(-) create mode 100644 arch/sh/include/asm/cpu_sh7724.h create mode 100644 arch/sh/lib/ashrsi3.S create mode 100644 board/renesas/ecovec/Makefile create mode 100644 board/renesas/ecovec/ecovec.c create mode 100644 board/renesas/ecovec/lowlevel_init.S create mode 100644 include/configs/ecovec.h Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Don't tell me how hard you work. Tell me how much you get done. - James J. Ling ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-staging / marek.va...@gmail.com
Dear Marek Vasut, In message 201112021101.18529.marek.va...@gmail.com you wrote: Hi Wolfgang, let's see how this works :) The following changes since commit 7708d8b352e9e595f6f08afd3206af6495c7dc09: Merge branch 'master' of ssh://gemini/home/wd/git/u-boot/master (2011-12-= 02=20 00:17:49 +0100) are available in the git repository at: git://git.denx.de/u-boot-staging.git marek.va...@gmail.com Andreas Bie=DFmann (1): tools/os_support: add OS X Lion support Matthias Fuchs (2): board/esd/common/xilinx_jtag_micro.c: Fix GCC 4.6 warning board/esd/dasa_sim/flash.c: Fix GCC 4.6 warning board/esd/common/xilinx_jtag/micro.c |2 -- board/esd/dasa_sim/flash.c |3 --- tools/os_support.c |2 +- tools/os_support.h |2 +- 4 files changed, 2 insertions(+), 7 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I often quote myself; it adds spice to my conversation. - G. B. Shaw ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] matrix vision: fix MVBLM7, MVSMR build error
Dear Kim Phillips, In message 2004164356.5ab650e3a7af28de76f55...@freescale.com you wrote: when a mkimage binary isn't present in the default system PATH, we get this error: $ ./MAKEALL MVBLM7 Configuring for MVBLM7 board... make[1]: mkimage: Command not found make[1]: *** [libmvblm7.o] Error 127 make: *** [board/matrix_vision/mvblm7/libmvblm7.o] Error 2 powerpc-linux-gnu-size: './u-boot': No such file fix by referencing u-boot's built-in mkimage instead. Signed-off-by: Kim Phillips kim.phill...@freescale.com --- board/matrix_vision/mvblm7/Makefile |2 +- board/matrix_vision/mvsmr/Makefile |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/board/matrix_vision/mvblm7/Makefile b/board/matrix_vision/mvblm7/Makefile index 81761ca..48a602c 100644 --- a/board/matrix_vision/mvblm7/Makefile +++ b/board/matrix_vision/mvblm7/Makefile @@ -32,7 +32,7 @@ SOBJS := $(addprefix $(obj),$(SOBJS)) $(LIB): $(obj).depend $(OBJS) $(call cmd_link_o_target, $(OBJS)) - @mkimage -T script -C none -n M7_script -d bootscript $(obj)bootscript.img + @$(OBJTREE)/tools/mkimage -T script -C none -n M7_script -d bootscript $(obj)bootscript.img If we do that, should then $(OBJTREE)/tools/mkimage not be listed as dependency for this step? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de There are three principal ways to lose money: wine, women, and engi- neers. While the first two are more pleasant, the third is by far the more certain. - Baron Rothschild, ca. 1800 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Phy/Marvell: Rewrite the MV88E1111 phy config function based on kernel code
Dear Roy Zang, In message 1319777529-28654-1-git-send-email-tie-fei.z...@freescale.com you wrote: The original m88es_config() does not do the SGMII mode initialization and is buggy. Rewrite the function according to 3.0.6 kernel function m88e_config_init() in drivers/net/phy/marvell.c Signed-off-by: Roy Zang tie-fei.z...@freescale.com Acked-by: Andy Fleming aflem...@freescale.com Cc: Kumar Gala ga...@kernel.crashing.org --- v2: Use timeout instead of infinite loop drivers/net/phy/marvell.c | 113 ++-- 1 files changed, 107 insertions(+), 6 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Never ascribe to malice that which can adequately be explained by stupidity. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Makefile: add tools/mkenvimage to target 'clean'
On Tue, 29 Nov 2011 10:42:14 +0100 Horst Kronstorfer hkron...@frequentis.com wrote: Signed-off-by: Horst Kronstorfer hkron...@frequentis.com --- Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Applied to u-boot-staging/ag...@denx.de. Thanks! Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] net: tweak eth_device layout to simplify enetaddr use
Dear Mike Frysinger, In message 20111003.15436.vap...@gentoo.org you wrote: I'm OK with expanding the name[] field, but as Thomas pointed out, providing convenient u32 / u16 variables for the MAC address is actually a faux ami that misleads people into using these variables without thinking about endianess and such. Please omit this part. there's always the endian issue. i'd wager that the vast majority of the time, the endian of the target hardware is the same as the core. so omitting this for odd devices or device driver writers who aren't careful is being too pessimistic imo. i can add qualifiers to the name like enetaddr_cpu32 if you No. Please drop this. want. looking at the generated code shows really nice improvements: a single cpu load instead of 4 loads interspersed with bitshifts. This is neither memory nor performance critical, but it is easy to misuse and thus dangerous. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de There's no honorable way to kill, no gentle way to destroy. There is nothing good in war. Except its ending. -- Abraham Lincoln, The Savage Curtain, stardate 5906.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] video: cfb_console: Make the software cursor non-destructive
On Thu, 1 Dec 2011 00:50:50 +0100 Anatolij Gustschin ag...@denx.de wrote: From: Gabe Black gabebl...@chromium.org When printing the string \r\n to the framebuffer console, the first character of the current line was being replaced with a space. The boot prompt would become the oot prompt. This change makes the cursor non-destructive so that no matter where it goes on its way to where it's supposed to be, the end result is that the cursor is where it's supposed to be with the other text preserved. Signed-off-by: Gabe Black gabebl...@chromium.org Acked-by: Mike Frysinger vap...@gentoo.org Signed-off-by: Anatolij Gustschin ag...@denx.de --- Changes in v3: - fixed checkpatch errors - slightly modified subject line - fixed cursor position if video logo is used Changes in v2: - Tidy up commit message wording. - Undo change to documenting comment. - Undo minor whitespace tweak. - Consolidate CONFIG_CONSOLE_CURSOR and CONFIG_VIDEO_SW_CURSOR. - Get rid of a space between video_invertchar and its (. drivers/video/cfb_console.c | 109 +-- 1 files changed, 53 insertions(+), 56 deletions(-) Applied to u-boot-video/master. Thanks! Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] miiphy: Note that miiphy_* API is deprecated
Dear Andy Fleming, In message 1320072373-367-1-git-send-email-aflem...@freescale.com you wrote: We want to move everything to phylib, and we definitely don't want new drivers using the miiphy infrastructure. Signed-off-by: Andy Fleming aflem...@freescale.com --- common/miiphyutil.c | 10 ++ doc/feature-removal-schedule.txt | 11 +++ 2 files changed, 21 insertions(+), 0 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Niklaus Wirth has lamented that, whereas Europeans pronounce his name correctly (Ni-klows Virt), Americans invariably mangle it into (Nick- les Worth). Which is to say that Europeans call him by name, but Americans call him by value. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 2/6] sf: Add spi_boot() to allow booting from SPI flash in an SPL
On Monday 05 December 2011 15:03:44 Tom Rini wrote: On Mon, Dec 5, 2011 at 12:56 PM, Mike Frysinger vap...@gentoo.org wrote: On Monday 05 December 2011 14:33:40 Scott Wood wrote: On 12/05/2011 04:58 AM, Christian Riesch wrote: Signed-off-by: Christian Riesch christian.rie...@omicron.at Cc: Heiko Schocher h...@denx.de Cc: Mike Frysinger vap...@gentoo.org Cc: Scott Wood scottw...@freescale.com Acked-by: Mike Frysinger vap...@gentoo.org --- doc/README.SPL |1 + drivers/mtd/spi/Makefile |4 +++ drivers/mtd/spi/spi_spl_load.c | 58 include/spi_flash.h |3 ++ 4 files changed, 66 insertions(+), 0 deletions(-) create mode 100644 drivers/mtd/spi/spi_spl_load.c I'm not sure if you're the one assigning this to me in Patchwork (would be nice if it had a history log), but I'm not the maintainer of SPI, nor of SPL generically -- just NAND. i don't plan on running these through my SPI branch ... seems like it should go through the SPL with everything else here. How about this? I don't see SPL nor SPI on the Custodians page, but there is TI and this is SPL for DaVinci (TI) stuff, so once everyone is happy with the whole series I'll take this for u-boot-ti/master and try for v2011.12 (since this series has been around for a while). that's fine by me -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/17] fdt: Tidy up a few fdtdec problems
On 12/02/2011 07:11 PM, Simon Glass wrote:
...
+int fdtdec_get_is_enabled(const void *blob, int node)
{
const char *cell;
cell = fdt_getprop(blob, node, status, NULL);
if (cell)
- return 0 == strcmp(cell, ok);
- return default_val;
+ return 0 == strcmp(cell, okay);
+ return 1;
}
The kernel accepts both okay (standard) and ok (non-standard). I assume
the latter is required for some in-use-but-technically-incorrect .dts
files. I imagine U-Boot should act like the kernel here.
(Sorry if I wasn't clear here before; that's certainly what I intended
to mean)
--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 10/14] tegra: usb: Add support for USB peripheral
On 12/02/2011 05:59 PM, Simon Glass wrote:
Hi Stephen,
Here are my comments on the rest of your email.
On Mon, Nov 28, 2011 at 11:21 AM, Stephen Warren swar...@nvidia.com wrote:
On 11/23/2011 08:54 PM, Simon Glass wrote:
This adds basic support for the Tegra2 USB controller. Board files should
call board_usb_init() to set things up.
+ config-enabled = fdtdec_get_is_enabled(blob, node);
+ config-periph_id = fdtdec_get_int(blob, node, periph-id, -1);
periph-id is a U-Boot specific concept, not HW description. The DT
shouldn't contain that value.
See my previous comments as to why this is desirable. We can change
over to a clock-based approach once the kernel implements it.
That will cause backwards-compatibility problems; older FDTs won't work
with newer U-Boots. We should avoid incompatible changes like this if at
all possible.
+int board_usb_init(const void *blob)
+{
+#ifdef CONFIG_OF_CONTROL
+ struct fdt_usb config;
+ int clk_done = 0;
+ int node, upto = 0;
+ unsigned osc_freq = clock_get_rate(CLOCK_ID_OSC);
+
+ do {
+ node = fdtdec_next_alias(blob, usb,
+COMPAT_NVIDIA_TEGRA20_USB, upto);
Why only initialize USB controllers with aliases? Surely this should
enumerate all nodes with a specific compatible flag?
See my other comments - we want to know that port 0 is USB3 on Seaboard.
Why does U-Boot care? Everything should be enumerating which peripherals
happen to appear on the various USB busses, and not care which host
controller they're attached to.
(With the exception of USB port 0 being device-capable, but that should
be configured by an explicit property, not based on aliases or anything
like that)
--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/17] fdt: Tidy up a few fdtdec problems
Hi Stephen,
On Mon, Dec 5, 2011 at 1:27 PM, Stephen Warren swar...@nvidia.com wrote:
On 12/02/2011 07:11 PM, Simon Glass wrote:
...
+int fdtdec_get_is_enabled(const void *blob, int node)
{
const char *cell;
cell = fdt_getprop(blob, node, status, NULL);
if (cell)
- return 0 == strcmp(cell, ok);
- return default_val;
+ return 0 == strcmp(cell, okay);
+ return 1;
}
The kernel accepts both okay (standard) and ok (non-standard). I assume
the latter is required for some in-use-but-technically-incorrect .dts
files. I imagine U-Boot should act like the kernel here.
Given that we are just starting out with fdt, do you think it would be
better to not bloat the code in this way? I don't mind either way -
just asking :-)
Regards,
Simon
(Sorry if I wasn't clear here before; that's certainly what I intended
to mean)
--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4] Ethernut 5 board support
Dear Harald Kipp, In message 4ec6b254.80...@egnite.de you wrote: Dear Maintainers, On 02.11.2011 10:55, Tim Schendekehl wrote: Add support for the Ethernut 5 open hardware design, based on Atmel's AT91SAM9XE512 SoC. Any chance to get this patch reviewed before it's becoming outdated again? It might help to put the responsible custodian on Cc: Also, sticking to the correct patch format (like putting comments not into the commitm essage, but into the comment section, i. e. _below_ the --- line) increases your chances. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I object to intellect without discipline; I object to power without constructive purpose. -- Spock, The Squire of Gothos, stardate 2124.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 10/14] tegra: usb: Add support for USB peripheral
Hi Stephen,
On Mon, Dec 5, 2011 at 1:33 PM, Stephen Warren swar...@nvidia.com wrote:
On 12/02/2011 05:59 PM, Simon Glass wrote:
Hi Stephen,
Here are my comments on the rest of your email.
On Mon, Nov 28, 2011 at 11:21 AM, Stephen Warren swar...@nvidia.com wrote:
On 11/23/2011 08:54 PM, Simon Glass wrote:
This adds basic support for the Tegra2 USB controller. Board files should
call board_usb_init() to set things up.
+ config-enabled = fdtdec_get_is_enabled(blob, node);
+ config-periph_id = fdtdec_get_int(blob, node, periph-id, -1);
periph-id is a U-Boot specific concept, not HW description. The DT
shouldn't contain that value.
See my previous comments as to why this is desirable. We can change
over to a clock-based approach once the kernel implements it.
That will cause backwards-compatibility problems; older FDTs won't work
with newer U-Boots. We should avoid incompatible changes like this if at
all possible.
At the moment the fdts are in the U-Boot tree, so we should be able to
change them at the same time. But of course when we update the fdt we
need to update the U-Boot code. Is there any alternative other than
doing nothing until the kernel decides everything?
+int board_usb_init(const void *blob)
+{
+#ifdef CONFIG_OF_CONTROL
+ struct fdt_usb config;
+ int clk_done = 0;
+ int node, upto = 0;
+ unsigned osc_freq = clock_get_rate(CLOCK_ID_OSC);
+
+ do {
+ node = fdtdec_next_alias(blob, usb,
+ COMPAT_NVIDIA_TEGRA20_USB, upto);
Why only initialize USB controllers with aliases? Surely this should
enumerate all nodes with a specific compatible flag?
See my other comments - we want to know that port 0 is USB3 on Seaboard.
Why does U-Boot care? Everything should be enumerating which peripherals
happen to appear on the various USB busses, and not care which host
controller they're attached to.
At present we do:
'usb start 0'
'usb start 1'
to select between the ports. There is a patch in the works to change
that but it hasn't gone upstream yet, or at least wasn't accepted.
There is a problem with adopting that approach in general - e.g.
*which* UART you write to has a big effect on whether the user sees
any output.
(With the exception of USB port 0 being device-capable, but that should
be configured by an explicit property, not based on aliases or anything
like that)
Yes it is - in fact I added that property.
Regards,
Simon
--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 04/17] fdt: Add basic support for decoding GPIO definitions
On 12/02/2011 07:11 PM, Simon Glass wrote:
This adds some support into fdtdec for reading GPIO definitions from
the fdt. We permit up to FDT_GPIO_MAX GPIOs in the system. Each GPIO
is of the form:
gpio-function-name = phandle gpio_num flags;
where:
phandle is a pointer to the GPIO node
gpio_num is the number of the GPIO (0 to 223)
flags is some flags, proposed as follows:
bitmeaning
0 0=input, 1=output
1 for output only: inital value of output
2 0=polarity normal, 1=active low (inverted)
The meaning of the flags (and even whether there are any flags any if so
how many cells there are to contain them) is defined by the GPIO
controller's binding. It's not something that can be interpreted in
isolation by a generic DT parsing function. See for example #gpio-cells
in tegra20.dtsi's gpio node and kernel file
Documentation/devicetree/bindings/gpio/gpio_nvidia.txt.
This implies that a lot of the code isn't correct, but I haven't
explicitly mentioned this everywhere for brevity.
An example is:
enable-propounder = gpio 43 1;
I /think/ convention is to name such properties foo-gpios rather than
just foo. Still, this is only a comment on the example and not the code,
since the complete property name is passed into the new functions by the
caller.
+/* For now we allow 224 GPIOs. We can extend this later if required */
+enum {
+ FDT_GPIO_NONE = 255,/* an invalid GPIO used to end our list */
Can't you use 0 for that? (the kernel currently uses -1, but it seems
there's agreement that was a mistake). If you use 255, the number will
have to keep getting bumped as more complex systems become supported. If
not 0, perhaps U32_MAX or whatever the relevant ${type}_MAX is?
--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 1/5] serial: cosmetic checkpatch compliance
Dear Gerlando Falauto, In message 1321634955-5561-2-git-send-email-gerlando.fala...@keymile.com you wrote: Signed-off-by: Gerlando Falauto gerlando.fala...@keymile.com --- common/serial.c | 51 +-- include/serial.h | 19 ++- 2 files changed, 35 insertions(+), 35 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de You can't evaluate a man by logic alone. -- McCoy, I, Mudd, stardate 4513.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 2/5] serial: constify serial_assign()
Dear Gerlando Falauto, In message 1321634955-5561-3-git-send-email-gerlando.fala...@keymile.com you wrote: Signed-off-by: Gerlando Falauto gerlando.fala...@keymile.com --- common/serial.c |2 +- include/serial.h |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The human mind ordinarily operates at only ten percent of its capacity. The rest is overhead for the operating system. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] CPCI750: Fix GCC 4.6 warning in board/esd/cpci750/mv_eth.c
Dear Reinhard Arlt, In message 4ec6a749.1020...@esd.eu you wrote: From: Reinhard Arlt reinhard.a...@esd.eu This patch fix the GCC 4.6 warnings in in what? and which warnings? Signed-off-by: Reinhard Arlt reinhard.a...@esd.eu -- diff --git a/board/esd/cpci750/mv_eth.c b/board/esd/cpci750/mv_eth.c index 781ad23..69b4a91 100644 --- a/board/esd/cpci750/mv_eth.c +++ b/board/esd/cpci750/mv_eth.c @@ -100,6 +100,8 @@ extern void NetReceive (volatile uchar *, int); extern unsigned int INTERNAL_REG_BASE_ADDR; +u32 port_status; What is this needed for? I see a port_status locally used in mv64360_eth_print_phy_status(), but except from that it never gets read. Sorry, but his does not appear to be a good fix. You may want to have a look at what I did to the same driver for the Marvell boards. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Though a program be but three lines long, someday it will have to be maintained. - The Tao of Programming ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] CPCI750: Do not enable data cache in start.S
Dear Reinhard Arlt, In message 4ec6a8e3.7050...@esd.eu you wrote: From: Reinhard Arlt reinhard.a...@esd.eu Do not enable the data cache in start.S, the decrementer do not work. Signed-off-by: Reinhard Arlt reinhard.a...@esd.eu -- diff --git a/arch/powerpc/cpu/74xx_7xx/start.S b/arch/powerpc/cpu/74xx_7xx/start.S index 75fb773..131fc14 100644 --- a/arch/powerpc/cpu/74xx_7xx/start.S +++ b/arch/powerpc/cpu/74xx_7xx/start.S @@ -247,11 +247,12 @@ in_flash: /* enable address translation */ bl enable_addr_trans sync - +#if !defined(CONFIG_CPCI750) /* enable and invalidate the data cache */ bl l1dcache_enable sync #endif +#endif #ifdef CONFIG_SYS_INIT_RAM_LOCK bl lock_ram_in_cache sync Sorry, but I don't want to have board specific code in arch/powerpc/cpu/74xx_7xx/start.S Please turn this into a feature dependent define, if it is really needed. Also, can you provide a rational explanation how the decrementer depends on data cache being enabled? This sounds pretty strange to me. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de News is what a chap who doesn't care much about anything wants to read. And it's only news until he's read it. After that it's dead. - Evelyn Waugh _Scoop_ (1938) bk. 1, ch. 5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 04/17] fdt: Add basic support for decoding GPIO definitions
Hi Stephen,
On Mon, Dec 5, 2011 at 1:46 PM, Stephen Warren swar...@nvidia.com wrote:
On 12/02/2011 07:11 PM, Simon Glass wrote:
This adds some support into fdtdec for reading GPIO definitions from
the fdt. We permit up to FDT_GPIO_MAX GPIOs in the system. Each GPIO
is of the form:
gpio-function-name = phandle gpio_num flags;
where:
phandle is a pointer to the GPIO node
gpio_num is the number of the GPIO (0 to 223)
flags is some flags, proposed as follows:
bit meaning
0 0=input, 1=output
1 for output only: inital value of output
2 0=polarity normal, 1=active low (inverted)
The meaning of the flags (and even whether there are any flags any if so
how many cells there are to contain them) is defined by the GPIO
controller's binding. It's not something that can be interpreted in
isolation by a generic DT parsing function. See for example #gpio-cells
in tegra20.dtsi's gpio node and kernel file
Documentation/devicetree/bindings/gpio/gpio_nvidia.txt.
I see this in my version:
Required properties:
- compatible : nvidia,tegra20-gpio
- #gpio-cells : Should be two. The first cell is the pin number and the
second cell is used to specify optional parameters:
- bit 0 specifies polarity (0 for normal, 1 for inverted)
- gpio-controller : Marks the device node as a GPIO controller.
so how do I go about adding the other two bits?
This implies that a lot of the code isn't correct, but I haven't
explicitly mentioned this everywhere for brevity.
Well it's ok - these flags are only used in one place, and only the
input/output flag in fact.
It would be nice to use constants for these in the fdt instead of
numbers. Is that in progress?
enable-propounder = gpio 43 OUTPUT;
An example is:
enable-propounder = gpio 43 1;
I /think/ convention is to name such properties foo-gpios rather than
just foo. Still, this is only a comment on the example and not the code,
since the complete property name is passed into the new functions by the
caller.
ok, will update.
+/* For now we allow 224 GPIOs. We can extend this later if required */
+enum {
+ FDT_GPIO_NONE = 255, /* an invalid GPIO used to end our list */
Can't you use 0 for that? (the kernel currently uses -1, but it seems
there's agreement that was a mistake). If you use 255, the number will
have to keep getting bumped as more complex systems become supported. If
not 0, perhaps U32_MAX or whatever the relevant ${type}_MAX is?
But 0 is a valid GPIO isn't it?
I currently use the max value available to the u8. We can change it at
will when we update the u8 type to u16 which is why I made it a
constant.
Thanks for all your help with this.
Regards,
Simon
--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 02/17] fdt: Add functions to access phandles, arrays and bools
On 12/02/2011 07:11 PM, Simon Glass wrote:
Add a function to look up a property which is a phandle in a node, and
another to read a fixed-length integer array from an fdt property.
Also add a function to read boolean properties, although there is no
actual boolean type in U-Boot.
+/**
+ * Look up a boolean property in a node and return it.
+ *
+ * A boolean properly is true if present in the device tree and false if not
+ * present, or present with a 0 value.
+ *
+ * @param blob FDT blob
+ * @param node node to examine
+ * @param prop_name name of property to find
+ * @return 1 if the properly is present; 0 if it isn't present or is 0
+ */
+int fdtdec_get_bool(const void *blob, int node, const char *prop_name)
+{
+ const s32 *cell;
+ int len;
+
+ debug(%s: %s\n, __func__, prop_name);
+ cell = fdt_getprop(blob, node, prop_name, len);
+ if (!cell)
+ return 0;
+ if (len = sizeof(u32) *cell == 0)
+ return 0;
+
+ return 1;
+}
I'm still slightly worried that this implementation may interpret the
FDT differently to the kernel. At least the code I've written for
boolean properties /only/ looks at the presence of the property, and
never at the contents even if there is one.
That said, the ePAPR specification does only say that boolean properties
/might/ have an empty value, thus implying that a non-zero length is
permissible. so, perhaps this is fine.
Actually no, I'm more than worried now I think it through. You'd argued
for being able to write 0/1 to the property so that U-Boot could modify
the value in-place without having to add/remove nodes to/from the FDT
image, but rather just change their content. However, if this modified
FDT is then passed to the kernel (rather than some other fresh FDT),
then it's imperative that U-Boot and the kernel represent boolean
properties in the exact same way. Hence, we either can't have U-Boot use
this edit-in-place optimization, or U-Boot needs some cleanup of the
FDT image before passing it to the kernel. However, the latter is
impossible, since by then since the boot-the-kernel code has no idea
whether a property is a boolean or not, and hence implementing such a
cleanup is impossible.
--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] env_nand: Remove DEBUG definition
Dear Thomas Weber, In message 1320912600-3170-1-git-send-email-we...@corscience.de you wrote: When compiling with -DDEBUG enabled this caused a warning about multiple definition of DEBUG. Signed-off-by: Thomas Weber we...@corscience.de --- common/env_nand.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/common/env_nand.c b/common/env_nand.c index 14446a6..e71a229 100644 --- a/common/env_nand.c +++ b/common/env_nand.c @@ -30,7 +30,7 @@ * MA 02111-1307 USA */ -#define DEBUG +/* #define DEBUG */ No - please simply delete this. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de You can observe a lot just by watchin'. - Yogi Berra ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers/net/mvgbe.c: Fix GCC 4.6 warnings
Dear Anatolij Gustschin, In message 1321729176-5520-1-git-send-email-ag...@denx.de you wrote: Fix: mvgbe.c: In function 'mvgbe_send': mvgbe.c:555:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] mvgbe.c: In function 'mvgbe_recv': mvgbe.c:640:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] Signed-off-by: Anatolij Gustschin ag...@denx.de Cc: Prafulla Wadaskar prafu...@marvell.com --- drivers/net/mvgbe.c |9 ++--- 1 files changed, 6 insertions(+), 3 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Your csh still thinks true is false. Write to your vendor today and tell them that next year Configure ought to rm /bin/csh unless they fix their blasted shell. :-) - Larry Wall in Configure from the perl distribution ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Fix tsize warning in tools/aisimage.c
Dear Simon Glass, In message 1321726854-18400-1-git-send-email-...@chromium.org you wrote: This fixes the following warning with gcc 4.4.3. aisimage.c: In function 'aisimage_generate': aisimage.c:365: warning: 'tsize' may be used uninitialized in this function Signed-off-by: Simon Glass s...@chromium.org --- tools/aisimage.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Karl's version of Parkinson's Law: Work expands to exceed the time alloted it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/17] fdt: Tidy up a few fdtdec problems
On 12/05/2011 02:40 PM, Simon Glass wrote:
Hi Stephen,
On Mon, Dec 5, 2011 at 1:27 PM, Stephen Warren swar...@nvidia.com wrote:
On 12/02/2011 07:11 PM, Simon Glass wrote:
...
+int fdtdec_get_is_enabled(const void *blob, int node)
{
const char *cell;
cell = fdt_getprop(blob, node, status, NULL);
if (cell)
- return 0 == strcmp(cell, ok);
- return default_val;
+ return 0 == strcmp(cell, okay);
+ return 1;
}
The kernel accepts both okay (standard) and ok (non-standard). I assume
the latter is required for some in-use-but-technically-incorrect .dts
files. I imagine U-Boot should act like the kernel here.
Given that we are just starting out with fdt, do you think it would be
better to not bloat the code in this way? I don't mind either way -
just asking :-)
My point is that there are probably .dts files using ok instead of
okay or the kernel wouldn't support ok. People will probably want to
use those with U-Boot without changing anything else. So, U-Boot should
interpret the FDT in the same way as the kernel.
--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 02/17] fdt: Add functions to access phandles, arrays and bools
Hi Stephen,
On Mon, Dec 5, 2011 at 1:59 PM, Stephen Warren swar...@nvidia.com wrote:
On 12/02/2011 07:11 PM, Simon Glass wrote:
Add a function to look up a property which is a phandle in a node, and
another to read a fixed-length integer array from an fdt property.
Also add a function to read boolean properties, although there is no
actual boolean type in U-Boot.
+/**
+ * Look up a boolean property in a node and return it.
+ *
+ * A boolean properly is true if present in the device tree and false if not
+ * present, or present with a 0 value.
+ *
+ * @param blob FDT blob
+ * @param node node to examine
+ * @param prop_name name of property to find
+ * @return 1 if the properly is present; 0 if it isn't present or is 0
+ */
+int fdtdec_get_bool(const void *blob, int node, const char *prop_name)
+{
+ const s32 *cell;
+ int len;
+
+ debug(%s: %s\n, __func__, prop_name);
+ cell = fdt_getprop(blob, node, prop_name, len);
+ if (!cell)
+ return 0;
+ if (len = sizeof(u32) *cell == 0)
+ return 0;
+
+ return 1;
+}
I'm still slightly worried that this implementation may interpret the
FDT differently to the kernel. At least the code I've written for
boolean properties /only/ looks at the presence of the property, and
never at the contents even if there is one.
That said, the ePAPR specification does only say that boolean properties
/might/ have an empty value, thus implying that a non-zero length is
permissible. so, perhaps this is fine.
OK
Actually no, I'm more than worried now I think it through. You'd argued
for being able to write 0/1 to the property so that U-Boot could modify
the value in-place without having to add/remove nodes to/from the FDT
image, but rather just change their content. However, if this modified
FDT is then passed to the kernel (rather than some other fresh FDT),
then it's imperative that U-Boot and the kernel represent boolean
properties in the exact same way. Hence, we either can't have U-Boot use
this edit-in-place optimization, or U-Boot needs some cleanup of the
FDT image before passing it to the kernel. However, the latter is
impossible, since by then since the boot-the-kernel code has no idea
whether a property is a boolean or not, and hence implementing such a
cleanup is impossible.
Hang on - this fdt cannot be passed to the kernel! It is for U-Boot's
use, for it's own configuration. There is no mechanism to fix up
U-Boot's internal fdt and pass it to the kernel. U-Boot scripts can't
even find its address!
That side of U-Boot is a complete different use of fdt and I have been
careful (so far) to keep them apart.
Regards,
Simon
--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 3/6] x86: Add support for booting Linux using the 32 bit boot protocol
This change conditionally modifies the zboot command so that it can use the
32 bit boot protocol. This is necessary because the 16 bit realmode entry
point assumes that it can call BIOS services which neither coreboot nor
u-boot provide.
Signed-off-by: Gabe Black gabebl...@chromium.org
---
Changes in v2:
- Moved the coreboot specific e820 function into a different patch.
Changes in v3:
- Moved the coreboot specific e820 function declaration out of the header.
arch/x86/include/asm/zimage.h |9 -
arch/x86/lib/bootm.c |6 ++-
arch/x86/lib/zimage.c | 64
3 files changed, 62 insertions(+), 17 deletions(-)
diff --git a/arch/x86/include/asm/zimage.h b/arch/x86/include/asm/zimage.h
index 1a77e00..3a68bb0 100644
--- a/arch/x86/include/asm/zimage.h
+++ b/arch/x86/include/asm/zimage.h
@@ -24,6 +24,8 @@
#ifndef _ASM_ZIMAGE_H_
#define _ASM_ZIMAGE_H_
+#include asm/e820.h
+
/* linux i386 zImage/bzImage header. Offsets relative to
* the start of the image */
@@ -44,10 +46,13 @@
#define BZIMAGE_LOAD_ADDR 0x10
#define ZIMAGE_LOAD_ADDR 0x1
+/* Implementation defined function to install an e820 map. */
+unsigned install_e820_map(unsigned max_entries, struct e820entry *);
+
void *load_zimage(char *image, unsigned long kernel_size,
unsigned long initrd_addr, unsigned long initrd_size,
- int auto_boot);
+ int auto_boot, void **load_address);
-void boot_zimage(void *setup_base);
+void boot_zimage(void *setup_base, void *load_address);
#endif
diff --git a/arch/x86/lib/bootm.c b/arch/x86/lib/bootm.c
index bac7b4f..ba3875b 100644
--- a/arch/x86/lib/bootm.c
+++ b/arch/x86/lib/bootm.c
@@ -38,6 +38,7 @@ int do_bootm_linux(int flag, int argc, char * const argv[],
void*base_ptr = NULL;
ulong os_data, os_len;
image_header_t *hdr;
+ void*load_address;
#if defined(CONFIG_FIT)
const void *data;
@@ -75,7 +76,8 @@ int do_bootm_linux(int flag, int argc, char * const argv[],
#ifdef CONFIG_CMD_ZBOOT
base_ptr = load_zimage((void *)os_data, os_len,
- images-rd_start, images-rd_end - images-rd_start, 0);
+ images-rd_start, images-rd_end - images-rd_start,
+ 0, load_address);
#endif
if (NULL == base_ptr) {
@@ -92,7 +94,7 @@ int do_bootm_linux(int flag, int argc, char * const argv[],
/* we assume that the kernel is in place */
printf(\nStarting kernel ...\n\n);
- boot_zimage(base_ptr);
+ boot_zimage(base_ptr, load_address);
/* does not return */
error:
diff --git a/arch/x86/lib/zimage.c b/arch/x86/lib/zimage.c
index 98e7507..b5597ec 100644
--- a/arch/x86/lib/zimage.c
+++ b/arch/x86/lib/zimage.c
@@ -52,6 +52,16 @@
#define COMMAND_LINE_SIZE 2048
+unsigned generic_install_e820_map(unsigned max_entries,
+ struct e820entry *entries)
+{
+ return 0;
+}
+
+unsigned install_e820_map(unsigned max_entries,
+ struct e820entry *entries)
+ __attribute__((weak, alias(generic_install_e820_map)));
+
static void build_command_line(char *command_line, int auto_boot)
{
char *env_command_line;
@@ -81,13 +91,12 @@ static void build_command_line(char *command_line, int
auto_boot)
void *load_zimage(char *image, unsigned long kernel_size,
unsigned long initrd_addr, unsigned long initrd_size,
- int auto_boot)
+ int auto_boot, void **load_address)
{
struct boot_params *setup_base;
int setup_size;
int bootproto;
int big_image;
- void *load_address;
struct boot_params *params = (struct boot_params *)image;
struct setup_header *hdr = params-hdr;
@@ -134,14 +143,23 @@ void *load_zimage(char *image, unsigned long kernel_size,
/* Determine load address */
if (big_image)
- load_address = (void *)BZIMAGE_LOAD_ADDR;
+ *load_address = (void *)BZIMAGE_LOAD_ADDR;
else
- load_address = (void *)ZIMAGE_LOAD_ADDR;
+ *load_address = (void *)ZIMAGE_LOAD_ADDR;
+#if defined CONFIG_ZBOOT_32
+ printf(Building boot_params at 0x%8.8lx\n, (ulong)setup_base);
+ memset(setup_base, 0, sizeof(*setup_base));
+ setup_base-hdr = params-hdr;
+
+ setup_base-e820_entries = install_e820_map(
+ ARRAY_SIZE(setup_base-e820_map), setup_base-e820_map);
+#else
/* load setup */
printf(Moving Real-Mode Code to 0x%8.8lx (%d bytes)\n,
(ulong)setup_base, setup_size);
memmove(setup_base, image, setup_size);
+#endif
printf(Using boot protocol version %x.%02x\n,
(bootproto 0xff00) 8, bootproto 0xff);
@@ -180,7 +198,7 @@ void *load_zimage(char *image, unsigned long kernel_size,
[U-Boot] [PATCH v3 6/6] x86: Add support for specifying an initrd with the zboot command
This change finishes plumbing the initrd support built into the zboot
mechanism out to the command interface.
It also fixes a bug in the command declaration where the kernel size could
be passed as an optional second parameter but not enough arguments were
allowed.
Signed-off-by: Gabe Black gabebl...@chromium.org
---
Changes in v2:
- Add a help message to the zboot command.
arch/x86/lib/zimage.c | 23 +++
1 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/arch/x86/lib/zimage.c b/arch/x86/lib/zimage.c
index 0cbb571..bb40517 100644
--- a/arch/x86/lib/zimage.c
+++ b/arch/x86/lib/zimage.c
@@ -321,6 +321,8 @@ int do_zboot(cmd_tbl_t *cmdtp, int flag, int argc, char
*const argv[])
void *load_address;
char *s;
ulong bzImage_size = 0;
+ ulong initrd_addr = 0;
+ ulong initrd_size = 0;
disable_interrupts();
@@ -337,9 +339,15 @@ int do_zboot(cmd_tbl_t *cmdtp, int flag, int argc, char
*const argv[])
if (s)
bzImage_addr = (void *)simple_strtoul(s, NULL, 16);
- if (argc = 3)
+ if (argc = 3) {
/* argv[2] holds the size of the bzImage */
bzImage_size = simple_strtoul(argv[2], NULL, 16);
+ }
+
+ if (argc = 4)
+ initrd_addr = simple_strtoul(argv[3], NULL, 16);
+ if (argc = 5)
+ initrd_size = simple_strtoul(argv[4], NULL, 16);
/* Lets look for */
base_ptr = load_zimage(bzImage_addr, bzImage_size, load_address);
@@ -349,7 +357,7 @@ int do_zboot(cmd_tbl_t *cmdtp, int flag, int argc, char
*const argv[])
return -1;
}
if (setup_zimage(base_ptr, (char *)base_ptr + COMMAND_LINE_OFFSET,
- 0, 0, 0)) {
+ 0, initrd_addr, initrd_size)) {
printf(Setting up boot parameters failed ...\n);
return -1;
}
@@ -366,7 +374,14 @@ int do_zboot(cmd_tbl_t *cmdtp, int flag, int argc, char
*const argv[])
}
U_BOOT_CMD(
- zboot, 2, 0,do_zboot,
+ zboot, 5, 0,do_zboot,
Boot bzImage,
-
+ [addr] [size] [initrd addr] [initrd size]\n
+ addr -The optional starting address of the bzimage.\n
+ If not set it defaults to the environment\n
+ variable \fileaddr\.\n
+ size -The optional size of the bzimage. Defaults to\n
+ zero.\n
+ initrd addr - The address of the initrd image to use, if any.\n
+ initrd size - The size of the initrd image to use, if any.\n
);
--
1.7.3.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 1/6] x86: Import code from coreboot's libpayload to parse the coreboot table
This change also forces the lib_sysinfo structure to be in the .data
section. Otherwise it ends up in the .bss section. U-boot assumes that it
doesn't need to copy it over during relocation, and instead fills that
whole section with zeroes. If we really were booting from ROM that would be
appropriate, but we need some information from the coreboot tables (memory
size) before then and have to fill that structure before relocation. We
skirt u-boot's assumption by putting this in .data where it assumes there
is still read only but non-zero data.
Signed-off-by: Gabe Black gabebl...@chromium.org
---
Changes in v2:
- Move arch/x86/include/asm/ic/coreboot/* to
arch/x86/include/asm/arch-coreboot/*
- Merge the lib_sysinfo change into this one.
arch/x86/cpu/coreboot/Makefile |3 +
arch/x86/cpu/coreboot/ipchecksum.c | 54 +
arch/x86/cpu/coreboot/sysinfo.c | 39
arch/x86/cpu/coreboot/tables.c | 183 +
arch/x86/include/asm/arch-coreboot/ipchecksum.h | 37
arch/x86/include/asm/arch-coreboot/sysinfo.h| 64 ++
arch/x86/include/asm/arch-coreboot/tables.h | 241 +++
board/chromebook-x86/coreboot/coreboot.c| 10 +
8 files changed, 631 insertions(+), 0 deletions(-)
create mode 100644 arch/x86/cpu/coreboot/ipchecksum.c
create mode 100644 arch/x86/cpu/coreboot/sysinfo.c
create mode 100644 arch/x86/cpu/coreboot/tables.c
create mode 100644 arch/x86/include/asm/arch-coreboot/ipchecksum.h
create mode 100644 arch/x86/include/asm/arch-coreboot/sysinfo.h
create mode 100644 arch/x86/include/asm/arch-coreboot/tables.h
diff --git a/arch/x86/cpu/coreboot/Makefile b/arch/x86/cpu/coreboot/Makefile
index 0444399..13f5f8a 100644
--- a/arch/x86/cpu/coreboot/Makefile
+++ b/arch/x86/cpu/coreboot/Makefile
@@ -33,7 +33,10 @@ include $(TOPDIR)/config.mk
LIB:= $(obj)lib$(SOC).o
+COBJS-$(CONFIG_SYS_COREBOOT) += tables.o
+COBJS-$(CONFIG_SYS_COREBOOT) += ipchecksum.o
COBJS-$(CONFIG_SYS_COREBOOT) += sdram.o
+COBJS-$(CONFIG_SYS_COREBOOT) += sysinfo.o
SOBJS-$(CONFIG_SYS_COREBOOT) += coreboot_car.o
diff --git a/arch/x86/cpu/coreboot/ipchecksum.c
b/arch/x86/cpu/coreboot/ipchecksum.c
new file mode 100644
index 000..57733d8
--- /dev/null
+++ b/arch/x86/cpu/coreboot/ipchecksum.c
@@ -0,0 +1,54 @@
+/*
+ * This file is part of the libpayload project.
+ *
+ * It has originally been taken from the FreeBSD project.
+ *
+ * Copyright (c) 2001 Charles Mott c...@linktel.net
+ * Copyright (c) 2008 coresystems GmbH
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+#include compiler.h
+#include asm/arch-coreboot/ipchecksum.h
+
+unsigned short ipchksum(const void *vptr, unsigned long nbytes)
+{
+ int sum, oddbyte;
+ const unsigned short *ptr = vptr;
+
+ sum = 0;
+ while (nbytes 1) {
+ sum += *ptr++;
+ nbytes -= 2;
+ }
+ if (nbytes == 1) {
+ oddbyte = 0;
+ ((u8 *)oddbyte)[0] = *(u8 *) ptr;
+ ((u8 *)oddbyte)[1] = 0;
+ sum += oddbyte;
+ }
+ sum = (sum 16) + (sum 0x);
+ sum += (sum 16);
+ return ~sum;
+}
diff --git a/arch/x86/cpu/coreboot/sysinfo.c b/arch/x86/cpu/coreboot/sysinfo.c
new file mode 100644
index 000..9b3e660
--- /dev/null
+++ b/arch/x86/cpu/coreboot/sysinfo.c
@@ -0,0 +1,39 @@
+/*
+ * This file is part of the libpayload project.
+ *
+ * Copyright (C) 2008 Advanced Micro Devices, Inc.
+ * Copyright (C) 2009 coresystems GmbH
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ *
[U-Boot] [PATCH v3 2/6] x86: Clean up the x86 zimage code in preparation to extend it
This change cleans up some formatting issues in the zimage handling code, and
converts it from using offsets added to a base pointer to using the available
structure definitions which were already being included.
Signed-off-by: Gabe Black gabebl...@chromium.org
---
Changes in v2:
- Changed includes to match ic/coreboot = arch-coreboot move.
- Merged a previous change that used the coreboot tables to approximate
total RAM size into this one.
arch/x86/include/asm/zimage.h | 21 --
arch/x86/lib/zimage.c | 82 ++--
2 files changed, 45 insertions(+), 58 deletions(-)
diff --git a/arch/x86/include/asm/zimage.h b/arch/x86/include/asm/zimage.h
index a02637f..1a77e00 100644
--- a/arch/x86/include/asm/zimage.h
+++ b/arch/x86/include/asm/zimage.h
@@ -27,27 +27,6 @@
/* linux i386 zImage/bzImage header. Offsets relative to
* the start of the image */
-#define CMD_LINE_MAGIC_OFF 0x020 /* Magic 0xa33f if the offset below is valid
*/
-#define CMD_LINE_OFFSET_OFF 0x022 /* Offset to comandline */
-#define SETUP_SECTS_OFF 0x1F1 /* The size of the setup in sectors */
-#define ROOT_FLAGS_OFF 0x1F2 /* If set, the root is mounted readonly */
-#define VID_MODE_OFF0x1FA /* Video mode control */
-#define ROOT_DEV_OFF0x1FC /* Default root device number */
-#define BOOT_FLAG_OFF 0x1FE /* 0xAA55 magic number */
-#define HEADER_OFF 0x202 /* Magic signature HdrS */
-#define VERSION_OFF 0x206 /* Boot protocol version supported */
-#define REALMODE_SWTCH_OFF 0x208 /* Boot loader hook (see below) */
-#define START_SYS_OFF 0x20C /* Points to kernel version string */
-#define TYPE_OF_LOADER_OFF 0x210 /* Boot loader identifier */
-#define LOADFLAGS_OFF 0x211 /* Boot protocol option flags */
-#define SETUP_MOVE_SIZE_OFF 0x212 /* Move to high memory size (used with
hooks) */
-#define CODE32_START_OFF0x214 /* Boot loader hook (see below) */
-#define RAMDISK_IMAGE_OFF 0x218 /* initrd load address (set by boot loader)
*/
-#define RAMDISK_SIZE_OFF0x21C /* initrd size (set by boot loader) */
-#define HEAP_END_PTR_OFF0x224 /* Free memory after setup end */
-#define CMD_LINE_PTR_OFF0x228 /* 32-bit pointer to the kernel command line
*/
-
-
#define HEAP_FLAG 0x80
#define BIG_KERNEL_FLAG 0x01
diff --git a/arch/x86/lib/zimage.c b/arch/x86/lib/zimage.c
index 8b42b5c..98e7507 100644
--- a/arch/x86/lib/zimage.c
+++ b/arch/x86/lib/zimage.c
@@ -1,4 +1,5 @@
/*
+ * Copyright (c) 2011 The Chromium OS Authors.
* (C) Copyright 2002
* Daniel Engström, Omicron Ceti AB, dan...@omicron.se
*
@@ -82,21 +83,22 @@ void *load_zimage(char *image, unsigned long kernel_size,
unsigned long initrd_addr, unsigned long initrd_size,
int auto_boot)
{
- void *setup_base;
+ struct boot_params *setup_base;
int setup_size;
int bootproto;
int big_image;
void *load_address;
- struct setup_header *hdr;
- hdr = (struct setup_header *)(image + SETUP_SECTS_OFF);
+ struct boot_params *params = (struct boot_params *)image;
+ struct setup_header *hdr = params-hdr;
/* base address for real-mode segment */
- setup_base = (void *)DEFAULT_SETUP_BASE;
+ setup_base = (struct boot_params *)DEFAULT_SETUP_BASE;
if (KERNEL_MAGIC != hdr-boot_flag) {
- printf(Error: Invalid Boot Flag (found 0x%04x, expected
0x%04x)\n,
- hdr-boot_flag, KERNEL_MAGIC);
+ printf(Error: Invalid Boot Flag
+ (found 0x%04x, expected 0x%04x)\n,
+ hdr-boot_flag, KERNEL_MAGIC);
return 0;
} else {
printf(Valid Boot Flag\n);
@@ -131,9 +133,10 @@ void *load_zimage(char *image, unsigned long kernel_size,
(hdr-loadflags BIG_KERNEL_FLAG);
/* Determine load address */
- load_address = (void *)(big_image ?
- BZIMAGE_LOAD_ADDR :
- ZIMAGE_LOAD_ADDR);
+ if (big_image)
+ load_address = (void *)BZIMAGE_LOAD_ADDR;
+ else
+ load_address = (void *)ZIMAGE_LOAD_ADDR;
/* load setup */
printf(Moving Real-Mode Code to 0x%8.8lx (%d bytes)\n,
@@ -144,8 +147,8 @@ void *load_zimage(char *image, unsigned long kernel_size,
(bootproto 0xff00) 8, bootproto 0xff);
if (bootproto == 0x0100) {
- *(u16 *)(setup_base + CMD_LINE_MAGIC_OFF) = COMMAND_LINE_MAGIC;
- *(u16 *)(setup_base + CMD_LINE_OFFSET_OFF) =
COMMAND_LINE_OFFSET;
+ setup_base-screen_info.cl_magic = COMMAND_LINE_MAGIC;
+ setup_base-screen_info.cl_offset = COMMAND_LINE_OFFSET;
/*
* A very old kernel MUST have its real-mode code
@@ -157,33 +160,36 @@ void *load_zimage(char *image, unsigned long
[U-Boot] [PATCH v3 0/6] Add support for the 32 bit boot protocol and coreboot table parsing.
Add functionality for reading in the coreboot tables and storing their contents in a structure for easy access. These four patches add support for the 32 bit Linux boot protocol to the zboot command. They also add support for an initrd. Changes in v2: - Move arch/x86/include/asm/ic/coreboot/* to arch/x86/include/asm/arch-coreboot/* - Merge the lib_sysinfo change into this one. - Changed includes to match ic/coreboot = arch-coreboot move. - Merged a previous change that used the coreboot tables to approximate total RAM size into this one. - Moved the coreboot specific e820 function into a different patch. - Moved the coreboot specific e820 function into this patch. - Add a help message to the zboot command. Changes in v3: - Moved the coreboot specific e820 function declaration out of the header. - Moved the coreboot specific e820 function declaration into this patch. Gabe Black (6): x86: Import code from coreboot's libpayload to parse the coreboot table x86: Clean up the x86 zimage code in preparation to extend it x86: Add support for booting Linux using the 32 bit boot protocol x86: Add infrastructure to extract an e820 table from the coreboot tables x86: Refactor the zboot innards so they can be reused with a vboot image x86: Add support for specifying an initrd with the zboot command arch/x86/cpu/coreboot/Makefile |3 + arch/x86/cpu/coreboot/ipchecksum.c | 54 + arch/x86/cpu/coreboot/sdram.c | 38 +++- arch/x86/cpu/coreboot/sysinfo.c | 39 arch/x86/cpu/coreboot/tables.c | 183 +++ arch/x86/include/asm/arch-coreboot/ipchecksum.h | 37 +++ arch/x86/include/asm/arch-coreboot/sysinfo.h| 64 ++ arch/x86/include/asm/arch-coreboot/tables.h | 241 arch/x86/include/asm/zimage.h | 36 +-- arch/x86/lib/bootm.c| 21 ++- arch/x86/lib/zimage.c | 276 +++ board/chromebook-x86/coreboot/coreboot.c| 10 + 12 files changed, 874 insertions(+), 128 deletions(-) create mode 100644 arch/x86/cpu/coreboot/ipchecksum.c create mode 100644 arch/x86/cpu/coreboot/sysinfo.c create mode 100644 arch/x86/cpu/coreboot/tables.c create mode 100644 arch/x86/include/asm/arch-coreboot/ipchecksum.h create mode 100644 arch/x86/include/asm/arch-coreboot/sysinfo.h create mode 100644 arch/x86/include/asm/arch-coreboot/tables.h -- 1.7.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
