Re: [U-Boot] U-boot with USB storage support for WonderMedia WM8505
Hi Albert, Sorry for the confusion. I did try several u-boots. None of them appeared to have any USB support as far as I could tell because u-boot didnt respond to any usb commands - e.g. usbinit however I have been successful if restoring functionality to my netbook. It appears the netbook was preloaded with WonderMedia Technologies U-Boot. I attempted to contact WonderMedia to request the U-Boot again. They havent replied. I then found a link to the WonderMedia U-Boot source. The source appeared to include a compiled u-boot, I tried it, it was very basic. It didnt even have LCD support. I then did a lot of digging around the internet, I downloaded about 700 megs of operating system files from similar netbooks and I found a WMT U-Boot which works. The working version is: U-Boot 1.1.4 (Oct 8 2010 - 10:39:28) WonderMedia Technologies, Inc. WMT U-Boot Version : 0.12.01.00.27 So I'm pretty happy right now because U-Boot can finally access the internal storage. The only downside to using the internal usb storage is the usb subsystem in u-boot appears to be quite slow. The command usbinit must be called first which appears to load the driver, and then scan the bus for devices. Once it is done the system can then boot from the usb storage. It easily adds atleast 5 seconds to the bootup, especially if the logo is loaded from usb. The next step is to load an operating system onto the internal storage. Thanks for your help. On Mon, Jul 4, 2011 at 3:50 PM, Albert ARIBAUD albert.u.b...@aribaud.netwrote: Hi Chris, Le 04/07/2011 00:29, Chris Barnes a écrit : Hi Albert, I dont know of any u-boot board configs that were used for this device. That was my original purpose for emailing this mailing list - hoping that someone may have experience with this netbook and may be able to point me in the right direction but at this point its not looking hopeful. Understood. But you have said you attempted install of several u-boot binaries, none of which had USB mass storage support; however if they have some sort of USB support other than mass storage, then maybe they could be rebuilt from source with mass storage support added. Can you list the boards for which you tried some binaries? Amicalement, -- Albert. -- Kind Regards, Christopher Barnes Microsoft Certified Systems Engineer Microsoft Certified Technology Specialist e. chris.p.bar...@gmail.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH][ATMEL] Fix compiler error for cpu at91sam9, if lowlevel init is enabled
Am 2011-07-03 23:06, schrieb Albert ARIBAUD: Hi Jens, Le 30/06/2011 11:51, Jens Scharsig a écrit : Am 2011-06-30 10:54, schrieb Reinhard Meyer: PS: for better readability of Submitter it would be nice to have real names with the e-Mail address ;) Dear Reinhard Meyer, sorry about this. I used a different computer than usual to create this patch. While I am fixing author names in commits, do you want me to fix this one, and if so, which e-mail address should I put as an author? Jens Scharsig e...@bus-elektronik.de Best regards Jens Scharsig ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot with USB storage support for WonderMedia WM8505
Le 04/07/2011 08:02, Chris Barnes a écrit : however I have been successful if restoring functionality to my netbook. Great! The working version is: U-Boot 1.1.4 (Oct 8 2010 - 10:39:28) Not that old if you look at the date, quite old if you look at the version number. But hey, IIAB(any more)DFI. :) WonderMedia Technologies, Inc. WMT U-Boot Version : 0.12.01.00.27 So I'm pretty happy right now because U-Boot can finally access the internal storage. The only downside to using the internal usb storage is the usb subsystem in u-boot appears to be quite slow. The command usbinit must be called first which appears to load the driver, and then scan the bus for devices. Once it is done the system can then boot from the usb storage. It easily adds atleast 5 seconds to the bootup, especially if the logo is loaded from usb. There is no loading a driver in U-Boot (the binary is self-contained), so the slowness is probably due to the USB driver or line speed (or both). Anyway, that'll be a problem only while you boot things via USB; once you have R/W access to the internal storage Flash, booting from Flash should be (hopefully) quicker. The next step is to load an operating system onto the internal storage. Thanks for your help. You did all the hard work, just thank yourself. :) Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] using a GPIO to toggle tftp boot mode
Hi Chris, Le 04/07/2011 07:50, Chris Gray a écrit : I'm hoping to come up with a way to configure a recovery mechanism using uboot. the idea is if the main OS image needs to be reflashed, or for recovery options. what are my options for configuring uboot to use a different set of configuration options based on the state of a GPIO line (button)? The cleanest and simplest course would be to use script commands to set up GPIO if it is not already done by the U-Boot code, and set the bootcmd variable to test the GPIO port value on boot and run an internal or tftp boot accordingly. You may want to make sure your board has the HUSH command line interpreter enabled. thanks! np. -CG Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] imx: Add support for zmx25 board
Hi Stefano
Am 30.06.2011 17:36, schrieb Stefano Babic:
On 06/30/2011 11:57 AM, Matthias Weisser wrote:
zmx25 is a board based on imx25 SoC, 64 Megs of LPDDR, 32 Megs of NOR flash,
an
optional NAND flash.
Hi Matthias,
diff --git a/board/syteco/zmx25/lowlevel_init.S
b/board/syteco/zmx25/lowlevel_init.S
new file mode 100644
index 000..4f3b756
+#includeasm/macro.h
+#includeasm/arch/imx-regs.h
+#includeasm/arch/asm-offsets.h
+
+.macro init_aips
+write32 IMX_AIPS1_BASE + AIPS_MPR_0_7, 0x
+write32 IMX_AIPS1_BASE + AIPS_MPR_8_15, 0x
+write32 IMX_AIPS2_BASE + AIPS_MPR_0_7, 0x
+write32 IMX_AIPS2_BASE + AIPS_MPR_8_15, 0x
+.endm
+
+.macro init_max
+write32 IMX_MAX_BASE + MAX_MPR0, 0x43210
+write32 IMX_MAX_BASE + MAX_MPR1, 0x43210
+write32 IMX_MAX_BASE + MAX_MPR2, 0x43210
+write32 IMX_MAX_BASE + MAX_MPR3, 0x43210
+write32 IMX_MAX_BASE + MAX_MPR4, 0x43210
+
+write32 IMX_MAX_BASE + MAX_SGPCR0, 0x10
+write32 IMX_MAX_BASE + MAX_SGPCR1, 0x10
+write32 IMX_MAX_BASE + MAX_SGPCR2, 0x10
+write32 IMX_MAX_BASE + MAX_SGPCR3, 0x10
+write32 IMX_MAX_BASE + MAX_SGPCR4, 0x10
+
+write32 IMX_MAX_BASE + MAX_MGPCR0, 0x0
+write32 IMX_MAX_BASE + MAX_MGPCR1, 0x0
+write32 IMX_MAX_BASE + MAX_MGPCR2, 0x0
+write32 IMX_MAX_BASE + MAX_MGPCR3, 0x0
+write32 IMX_MAX_BASE + MAX_MGPCR4, 0x0
+.endm
All these macro are in common with karo/tx25 and you added useful names
instead of raw hexadecimal values. This code is not strictly related to
the board, but it is part of the processor initialisation.
I am thinking about if we can factorize this stuff. What about to have a
file in asm/arch/ that can be included by all i.MX25 boards ?
I can do that. Would you suggest a name of this new file? Is there any
convention of file extensions for asm files that can be included and
define macros? Both .h and .S seems no the right extension to me.
+/*
+ * Set up LAN-RESET and FEC_RX_ERR
+ *
+ * LAN-RESET: gpio3[16] is ALT 5 mode of pin U20
+ * FEC_RX_ERR: FEC_RX_ERR is ALT 2 mode of pin R2
+ */
+muxctl = (struct iomuxc_mux_ctl *)IMX_IOPADMUX_BASE;
+padctl = (struct iomuxc_pad_ctl *)IMX_IOPADCTL_BASE;
+
+writel(gpio_mux_mode5,muxctl-pad_upll_bypclk);
+writel(gpio_mux_mode2,muxctl-pad_uart2_cts);
+
+/* assert PHY reset (low) */
+val = readl(gpio3-dr) ~(1 16);
+writel(val,gpio3-dr);
+val = readl(gpio3-dir) | (1 16);
+writel(val,gpio3-dir);
For i.MX there are accessors to access gpios (mxc_gpio_*). They are not
yet extended to the i.MX25, but I see the internal structure is the same
as for other i.MX processors. As far as I can see, it should be enough
to change the i.MX25 imx-reg-h using the same defines gor GPIO base
addresses already used by other microprocessors.
Yes, this can be done. But it will break at least tx25 board. I can fix
tx25 and build test it. But as I have no hardware I can't runtime test
it. What would be right way to do this?
+void dram_init_banksize(void)
+{
+gd-bd-bi_dram[0].start = PHYS_SDRAM;
+gd-bd-bi_dram[0].size = gd-ram_size;
+}
You copy the same function that is defined as weak in
arch/arm/lib/board.c. You could rely on that function and drop this one.
OK
+#define CONFIG_CMDLINE_TAG 1 /* enable passing of ATAGs */
You do not need to set this to 1, it is enough to define it. The same
for most of the defines in this file.
OK
Thanks for you review. As soon as I have answers to my questions above I
will come up with a v2 of the series.
Regards,
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot SPL direct Linux boot
On Fri, Jul 1, 2011 at 10:42 AM, Simon Schwarz simonschwarz...@googlemail.com wrote: Addition: As I read a bit about FDT it does not replace ATAGS (http://elinux.org/Device_Trees) - it is more a supplement to it. So it would not harm to implement minimal ATAGS support and later add the FDT to it. That was true in an early prototype, but it is not actually true anymore. Passing a DT replaces ATAGs on arm now, and that code is in mainline. I started a prototype for ATAGS creation by modifying bootm.c - which seems (so long) not be too hard. If this works and doesn't add too much overhead FDT support is not that much a problem IMHO. Regards Simon (Sorry Detlev for the repost - forgot the ML...) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm: auto gen asm-offsets.h for mb86r0x
auto gen asm-offsets.h for mb86r0x
Signed-off-by: Matthias Weisser weiss...@arcor.de
---
This patch needs http://patchwork.ozlabs.org/patch/102773/ to be applied first.
arch/arm/cpu/arm926ejs/mb86r0x/Makefile |2 +
arch/arm/cpu/arm926ejs/mb86r0x/asm-offsets.c| 65
arch/arm/include/asm/arch-mb86r0x/asm-offsets.h | 74 ---
3 files changed, 67 insertions(+), 74 deletions(-)
create mode 100644 arch/arm/cpu/arm926ejs/mb86r0x/asm-offsets.c
delete mode 100644 arch/arm/include/asm/arch-mb86r0x/asm-offsets.h
diff --git a/arch/arm/cpu/arm926ejs/mb86r0x/Makefile
b/arch/arm/cpu/arm926ejs/mb86r0x/Makefile
index bab048b..974d0be 100644
--- a/arch/arm/cpu/arm926ejs/mb86r0x/Makefile
+++ b/arch/arm/cpu/arm926ejs/mb86r0x/Makefile
@@ -37,6 +37,8 @@ all: $(obj).depend $(LIB)
$(LIB):$(OBJS)
$(call cmd_link_o_target, $(OBJS))
+$(OBJS) : $(TOPDIR)/include/asm/arch/asm-offsets.h
+
#
# defines $(obj).depend target
diff --git a/arch/arm/cpu/arm926ejs/mb86r0x/asm-offsets.c
b/arch/arm/cpu/arm926ejs/mb86r0x/asm-offsets.c
new file mode 100644
index 000..6f9c722
--- /dev/null
+++ b/arch/arm/cpu/arm926ejs/mb86r0x/asm-offsets.c
@@ -0,0 +1,65 @@
+/*
+ * Adapted from Linux v2.6.36 kernel: arch/powerpc/kernel/asm-offsets.c
+ *
+ * This program is used to generate definitions needed by
+ * assembly language modules.
+ *
+ * We use the technique used in the OSF Mach kernel code:
+ * generate asm statements containing #defines,
+ * compile this file to assembler, and then extract the
+ * #defines from the assembly-language output.
+ *
+ * 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.
+ */
+
+#include common.h
+#include asm/arch/mb86r0x.h
+
+#include linux/kbuild.h
+
+int main(void)
+{
+ /* ddr2 controller */
+ DEFINE(DDR2_DRIC, offsetof(struct mb86r0x_ddr2c, dric));
+ DEFINE(DDR2_DRIC1, offsetof(struct mb86r0x_ddr2c, dric1));
+ DEFINE(DDR2_DRIC2, offsetof(struct mb86r0x_ddr2c, dric2));
+ DEFINE(DDR2_DRCA, offsetof(struct mb86r0x_ddr2c, drca));
+ DEFINE(DDR2_DRCM, offsetof(struct mb86r0x_ddr2c, drcm));
+ DEFINE(DDR2_DRCST1, offsetof(struct mb86r0x_ddr2c, drcst1));
+ DEFINE(DDR2_DRCST2, offsetof(struct mb86r0x_ddr2c, drcst2));
+ DEFINE(DDR2_DRCR, offsetof(struct mb86r0x_ddr2c, drcr));
+ DEFINE(DDR2_DRCF, offsetof(struct mb86r0x_ddr2c, drcf));
+ DEFINE(DDR2_DRASR, offsetof(struct mb86r0x_ddr2c, drasr));
+ DEFINE(DDR2_DRIMS, offsetof(struct mb86r0x_ddr2c, drims));
+ DEFINE(DDR2_DROS, offsetof(struct mb86r0x_ddr2c, dros));
+ DEFINE(DDR2_DRIBSODT1, offsetof(struct mb86r0x_ddr2c, dribsodt1));
+ DEFINE(DDR2_DROABA, offsetof(struct mb86r0x_ddr2c, droaba));
+ DEFINE(DDR2_DROBS, offsetof(struct mb86r0x_ddr2c, drobs));
+
+ /* clock reset generator */
+ DEFINE(CRG_CRPR, offsetof(struct mb86r0x_crg, crpr));
+ DEFINE(CRG_CRHA, offsetof(struct mb86r0x_crg, crha));
+ DEFINE(CRG_CRPA, offsetof(struct mb86r0x_crg, crpa));
+ DEFINE(CRG_CRPB, offsetof(struct mb86r0x_crg, crpb));
+ DEFINE(CRG_CRHB, offsetof(struct mb86r0x_crg, crhb));
+ DEFINE(CRG_CRAM, offsetof(struct mb86r0x_crg, cram));
+
+ /* chip control module */
+ DEFINE(CCNT_CDCRC, offsetof(struct mb86r0x_ccnt, cdcrc));
+
+ /* external bus interface */
+ DEFINE(MEMC_MCFMODE0, offsetof(struct mb86r0x_memc, mcfmode[0]));
+ DEFINE(MEMC_MCFMODE2, offsetof(struct mb86r0x_memc, mcfmode[2]));
+ DEFINE(MEMC_MCFMODE4, offsetof(struct mb86r0x_memc, mcfmode[4]));
+ DEFINE(MEMC_MCFTIM0, offsetof(struct mb86r0x_memc, mcftim[0]));
+ DEFINE(MEMC_MCFTIM2, offsetof(struct mb86r0x_memc, mcftim[2]));
+ DEFINE(MEMC_MCFTIM4, offsetof(struct mb86r0x_memc, mcftim[4]));
+ DEFINE(MEMC_MCFAREA0, offsetof(struct mb86r0x_memc, mcfarea[0]));
+ DEFINE(MEMC_MCFAREA2, offsetof(struct mb86r0x_memc, mcfarea[2]));
+ DEFINE(MEMC_MCFAREA4, offsetof(struct mb86r0x_memc, mcfarea[4]));
+
+ return 0;
+}
diff --git a/arch/arm/include/asm/arch-mb86r0x/asm-offsets.h
b/arch/arm/include/asm/arch-mb86r0x/asm-offsets.h
deleted file mode 100644
index 0bc5279..000
--- a/arch/arm/include/asm/arch-mb86r0x/asm-offsets.h
+++ /dev/null
@@ -1,74 +0,0 @@
-/*
- * (C) Copyright 2010
- * Matthias Weisser weiss...@arcor.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
Re: [U-Boot] [PATCH][ATMEL] Fix author names
Dear Albert, thanks for fixing the names. My assumption of needing an afteernoon to get a new GIT up and running was too optimistic... After ubuntu 10.10 offered an automated upgrade to 11.04, I happyly accepted this and ended up with a broken installation that stops in grub, complaining there is no kernel... Now installing 11.04 from scratch... Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] USB tty corrupted stream on Beagleboard xM.
Hi, I am trying to get u-boot console out of USB OTG included in Beagleboard XM. For that purpose I'm using u-boot v2011.03 compiled for omap3_beagle. I just boot my board and stop u-boot's booting process and enter the following: setenv stdout usbtty; setenv stdin usbtty; setenv stderr usbtty Then I connect my USB OTG cable and get a /dev/ttyACM0 device in my host PC. However, while I am able to send commands, it seems the stream gets corrupted. I've seen some people seeing the same issue before here without response: http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/99482 Has anyone found a solution for this? Thank you. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: nand flash
Dear Scott Wood, In message 20110701220254.ga27...@schlenkerla.am.freescale.net you wrote: The following changes since commit 2c4ed7d2506621574284ee66da27ce88b7c21a06: Merge branch 'next' of git://git.denx.de/u-boot-nios (2011-07-01 09:42:25 +0200) are available in the git repository at: git://git.denx.de/u-boot-nand-flash.git master Alex Waterman (1): NAND: Add 16bit NAND support for the NDFC Ben Gardiner (5): nand_base: trivial: fix comment read/write comment nand_util: convert nand_write_skip_bad() to flags nand_util: treat WITH_YAFFS_OOB as a mode nand_util: drop trailing all-0xff pages if requested cmd_nand: add nand write.trimffs command Kumar Gala (1): Makefile: need to remove generated u-boot-nand_spl.lds Makefile |2 +- README |8 ++ common/cmd_nand.c| 19 ++- doc/README.nand | 10 drivers/mtd/nand/nand_base.c |2 +- drivers/mtd/nand/nand_util.c | 51 - drivers/mtd/nand/ndfc.c | 33 +++--- include/nand.h |8 +- nand_spl/nand_boot.c | 11 ++-- 9 files changed, 126 insertions(+), 18 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 What is mind? No matter. What is matter? Never mind. -- Thomas Hewitt Key, 1799-1875 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/8] Update at91sam9m10g45_devices.c to fix compile errors.
Dear Alex Waterman,
Move this file to the new ATMEL_BASE_* and ATMEL_ID_* defines.
Also fixed a problem appearing in the ethernet initialization where
the entire board was being reset, not just the ethernet controller.
This at least makes ethernet work on my board if the correct
environment (mac address, ip address, etc) is available on boot.
Signed-off-by: Alex Waterman awater...@dawning.com
---
.../cpu/arm926ejs/at91/at91sam9m10g45_devices.c| 26
++--
1 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/at91/at91sam9m10g45_devices.c
b/arch/arm/cpu/arm926ejs/at91/at91sam9m10g45_devices.c
index 4ad9b1f..9ef8966 100644
--- a/arch/arm/cpu/arm926ejs/at91/at91sam9m10g45_devices.c
+++ b/arch/arm/cpu/arm926ejs/at91/at91sam9m10g45_devices.c
@@ -26,42 +26,42 @@
#include asm/arch/at91_common.h
#include asm/arch/at91_pmc.h
#include asm/arch/gpio.h
-#include asm/arch/io.h
+#include asm/io.h
void at91_serial0_hw_init(void)
{
- at91_pmc_t *pmc= (at91_pmc_t *) AT91_PMC_BASE;
+ at91_pmc_t *pmc= (at91_pmc_t *) ATMEL_BASE_PMC;
at91_set_a_periph(AT91_PIO_PORTB, 19, 1); /* TXD0 */
at91_set_a_periph(AT91_PIO_PORTB, 18, 0); /* RXD0 */
- writel(1 AT91SAM9G45_ID_US0, pmc-pcer);
+ writel(1 ATMEL_ID_USART0, pmc-pcer);
}
void at91_serial1_hw_init(void)
{
- at91_pmc_t *pmc= (at91_pmc_t *) AT91_PMC_BASE;
+ at91_pmc_t *pmc= (at91_pmc_t *) ATMEL_BASE_PMC;
at91_set_a_periph(AT91_PIO_PORTB, 4, 1);/* TXD1 */
at91_set_a_periph(AT91_PIO_PORTB, 5, 0);/* RXD1 */
- writel(1 AT91SAM9G45_ID_US1, pmc-pcer);
+ writel(1 ATMEL_ID_USART1, pmc-pcer);
}
void at91_serial2_hw_init(void)
{
- at91_pmc_t *pmc= (at91_pmc_t *) AT91_PMC_BASE;
+ at91_pmc_t *pmc= (at91_pmc_t *) ATMEL_BASE_PMC;
at91_set_a_periph(AT91_PIO_PORTD, 6, 1);/* TXD2 */
at91_set_a_periph(AT91_PIO_PORTD, 7, 0);/* RXD2 */
- writel(1 AT91SAM9G45_ID_US2, pmc-pcer);
+ writel(1 ATMEL_ID_USART2, pmc-pcer);
}
void at91_serial3_hw_init(void)
{
- at91_pmc_t *pmc= (at91_pmc_t *) AT91_PMC_BASE;
+ at91_pmc_t *pmc= (at91_pmc_t *) ATMEL_BASE_PMC;
at91_set_a_periph(AT91_PIO_PORTB, 12, 0); /* DRXD */
at91_set_a_periph(AT91_PIO_PORTB, 13, 1); /* DTXD */
- writel(1 AT91_ID_SYS, pmc-pcer);
+ writel(1 ATMEL_ID_USART3, pmc-pcer);
}
If this is the debug UART, ID_USART3 is definitely wrong here. Also
following the example set up by at91sam9260_devives.c, this function
should be named at91_seriald_hw_init.
void at91_serial_hw_init(void)
There should be no such function left after rework.
@@ -86,14 +86,14 @@ void at91_serial_hw_init(void)
#ifdef CONFIG_ATMEL_SPI
void at91_spi0_hw_init(unsigned long cs_mask)
{
- at91_pmc_t *pmc= (at91_pmc_t *) AT91_PMC_BASE;
+ at91_pmc_t *pmc= (at91_pmc_t *) ATMEL_BASE_PMC;
at91_set_a_periph(AT91_PIO_PORTB, 0, 0);/* SPI0_MISO */
at91_set_a_periph(AT91_PIO_PORTB, 1, 0);/* SPI0_MOSI */
at91_set_a_periph(AT91_PIO_PORTB, 2, 0);/* SPI0_SPCK */
/* Enable clock */
- writel(1 AT91SAM9G45_ID_SPI0, pmc-pcer);
+ writel(1 ATMEL_ID_SPI0, pmc-pcer);
if (cs_mask (1 0)) {
at91_set_a_periph(AT91_PIO_PORTB, 3, 0);
@@ -123,14 +123,14 @@ void at91_spi0_hw_init(unsigned long cs_mask)
void at91_spi1_hw_init(unsigned long cs_mask)
{
- at91_pmc_t *pmc= (at91_pmc_t *) AT91_PMC_BASE;
+ at91_pmc_t *pmc= (at91_pmc_t *) ATMEL_BASE_PMC;
at91_set_a_periph(AT91_PIO_PORTB, 14, 0); /* SPI1_MISO */
at91_set_a_periph(AT91_PIO_PORTB, 15, 0); /* SPI1_MOSI */
at91_set_a_periph(AT91_PIO_PORTB, 16, 0); /* SPI1_SPCK */
/* Enable clock */
- writel(1 AT91SAM9G45_ID_SPI1, pmc-pcer);
+ writel(1 ATMEL_ID_SPI1, pmc-pcer);
if (cs_mask (1 0)) {
at91_set_a_periph(AT91_PIO_PORTB, 17, 0);
Those also miss the pull-up option like in at91sam9260_devices.c.
Please fix this file in the style done by at91sam9260_devices.c or
wait until I have done so.
Best Regards,
Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8] Fix compile problem for some boards in the clock code.
Dear Alex Waterman,
Some boards use AT91_SLOW_CLOCK and other use
CONFIG_SYS_AT91_SLOW_CLOCK. This patch makes it so the arm926ejs
clock code will return which ever is set.
Signed-off-by: Alex Waterman awater...@dawning.com
---
arch/arm/cpu/arm926ejs/at91/clock.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/at91/clock.c
b/arch/arm/cpu/arm926ejs/at91/clock.c
index 608af2c..0083bd2 100644
--- a/arch/arm/cpu/arm926ejs/at91/clock.c
+++ b/arch/arm/cpu/arm926ejs/at91/clock.c
@@ -57,7 +57,11 @@ static unsigned long at91_css_to_rate(unsigned long css)
{
switch (css) {
case AT91_PMC_MCKR_CSS_SLOW:
+#ifdef AT91_SLOW_CLOCK
+ return AT91_SLOW_CLOCK;
+#else
return CONFIG_SYS_AT91_SLOW_CLOCK;
+#endif
case AT91_PMC_MCKR_CSS_MAIN:
return gd-main_clk_rate_hz;
case AT91_PMC_MCKR_CSS_PLLA:
NAK. Compile problems for some boards shall not be fixed by hacks
into common source. Fix the board's definition file instead.
Best Regards,
Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/8] Adds wait to atmel_usart serial_init function
Dear Alex Waterman,
Adds a short busy loop wait to the atmel_usart.c serial_init()
function.
Signed-off-by: Alex Waterman awater...@dawning.com
---
drivers/serial/atmel_usart.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/serial/atmel_usart.c b/drivers/serial/atmel_usart.c
index e326b2b..e355706 100644
--- a/drivers/serial/atmel_usart.c
+++ b/drivers/serial/atmel_usart.c
@@ -47,6 +47,8 @@ void serial_setbrg(void)
int serial_init(void)
{
+
+ volatile int i = 0;
atmel_usart3_t *usart = (atmel_usart3_t *)CONFIG_USART_BASE;
writel(USART3_BIT(RSTRX) | USART3_BIT(RSTTX), usart-cr);
@@ -61,6 +63,10 @@ int serial_init(void)
| USART3_BF(NBSTOP, USART3_NBSTOP_1)),
usart-mr);
+ /* Short wait to let the serial port init. */
+ for (; i 1; i++)
+ ;
+
return 0;
}
1. Why is this delay needed in the first place?
Apparently it has not been required before.
2. Such a delay loop is highly dependant on toolchain,
cache and page situation and processor speed. It can not be
accepted as a solution. If a delay is really required here
and cannot be substituting by reading the UARTs status
register, udelay() must be used.
Best Regards,
Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/8] Updates the at91sam9m10g45ek.h config file.
Dear Alex Waterman, Moves to using newer defines and adds possible support for the second bank of RAM (if so desired). Also, some coding clean up: removed the needless define to 1s for defines that just act as flags. Signed-off-by: Alex Waterman awater...@dawning.com --- include/configs/at91sam9m10g45ek.h | 188 +-- 1 files changed, 113 insertions(+), 75 deletions(-) diff --git a/include/configs/at91sam9m10g45ek.h b/include/configs/at91sam9m10g45ek.h index de74dcf..5e02dde 100644 --- a/include/configs/at91sam9m10g45ek.h +++ b/include/configs/at91sam9m10g45ek.h @@ -27,48 +27,65 @@ #ifndef __CONFIG_H #define __CONFIG_H +/*#define DEBUG*/ + #define CONFIG_AT91_LEGACY +#define CONFIG_ATMEL_LEGACY /* ARM asynchronous clock */ -#define CONFIG_SYS_AT91_MAIN_CLOCK 1200/* from 12 MHz crystal */ +#define CONFIG_SYS_AT91_MAIN_CLOCK 1200 /* from 12 MHz crystal */ +#define AT91_SLOW_CLOCK 32768 Must be CONFIG_SYS_AT91_SLOW_CLOCK here. #define CONFIG_SYS_HZ1000 -#define CONFIG_ARM926EJS 1 /* This is an ARM926EJS Core*/ -#ifdef CONFIG_AT91SAM9M10G45EK -#define CONFIG_AT91SAM9M10G451 /* It's an Atmel AT91SAM9M10G45 SoC*/ -#else -#define CONFIG_AT91SAM9G45 1 /* It's an Atmel AT91SAM9G45 SoC*/ -#endif +#define CONFIG_AT91SAM9M10G45 +#define CONFIG_AT91FAMILY #define CONFIG_ARCH_CPU_INIT +#define CONFIG_BOARD_EARLY_INIT_F #undef CONFIG_USE_IRQ/* we don't need IRQ/FIQ stuff */ -#define CONFIG_CMDLINE_TAG 1 /* enable passing of ATAGs */ -#define CONFIG_SETUP_MEMORY_TAGS 1 -#define CONFIG_INITRD_TAG1 +#define CONFIGMDLINE_TAG /* enable passing of ATAGs */ +#define CONFIG_SETUP_MEMORY_TAGS +#define CONFIG_INITRD_TAG #define CONFIG_SKIP_LOWLEVEL_INIT +#define ATMEL_PIO_PORTS 5 /* 5 PIO ports. */ +#define CONFIG_SYS_SDRAM_BASE 0x7000 + /* * Hardware drivers */ -#define CONFIG_AT91_GPIO 1 -#define CONFIG_ATMEL_USART 1 +#define CONFIG_AT91_GPIO +#define CONFIG_ATMEL_USART #undef CONFIG_USART0 #undef CONFIG_USART1 #undef CONFIG_USART2 -#define CONFIG_USART31 /* USART 3 is DBGU */ +#define CONFIG_USART3/* USART 3 is DBGU */ +#define CONFIG_USART_BASE0xee00 /* Use the DBGU hardware. */ +#define CONFIG_USART_ID 10 Please follow the examples in at91sam9260ek.h There is no CONFIG_USARTx anymore. Just defining BASE and ID is sufficient. + +/* + * This needs to be defined for the OHCI code to work but it is defined as + * ATMEL_ID_UHPHS in the CPU specific header files. + */ +#define ATMEL_ID_UHP ATMEL_ID_UHPHS + +/* + * Specify the clock enable bit in the PMC_SCER register. + */ +#define ATMEL_PMC_UHPAT91SAM926x_PMC_UHP /* LCD */ -#define CONFIG_LCD 1 +#define CONFIG_LCD #define LCD_BPP LCD_COLOR8 -#define CONFIG_LCD_LOGO 1 +#define CONFIG_LCD_LOGO #undef LCD_TEST_PATTERN -#define CONFIG_LCD_INFO 1 -#define CONFIG_LCD_INFO_BELOW_LOGO 1 -#define CONFIG_SYS_WHITE_ON_BLACK1 -#define CONFIG_ATMEL_LCD 1 -#define CONFIG_ATMEL_LCD_RGB565 1 -#define CONFIG_SYS_CONSOLE_IS_IN_ENV 1 +#define CONFIG_LCD_INFO +#define CONFIG_LCD_INFO_BELOW_LOGO +#define CONFIG_SYS_WHITE_ON_BLACK +#define CONFIG_ATMEL_LCD +#define CONFIG_ATMEL_LCD_RGB565 +#define CONFIG_SYS_CONSOLE_IS_IN_ENV /* board specific(not enough SRAM) */ #define CONFIG_AT91SAM9G45_LCD_BASE 0x73E0 @@ -82,10 +99,10 @@ /* * BOOTP options */ -#define CONFIG_BOOTP_BOOTFILESIZE1 -#define CONFIG_BOOTP_BOOTPATH1 -#define CONFIG_BOOTP_GATEWAY 1 -#define CONFIG_BOOTP_HOSTNAME1 +#define CONFIG_BOOTP_BOOTFILESIZE +#define CONFIG_BOOTP_BOOTPATH +#define CONFIG_BOOTP_GATEWAY +#define CONFIG_BOOTP_HOSTNAME Thanks for removing the 1s ! /* * Command line configuration. @@ -98,35 +115,37 @@ #undef CONFIG_CMD_AUTOSCRIPT #undef CONFIG_CMD_LOADS -#define CONFIG_CMD_PING 1 -#define CONFIG_CMD_DHCP 1 -#define CONFIG_CMD_NAND 1 -#define CONFIG_CMD_USB 1 +#define CONFIG_CMD_PING +#define CONFIG_CMD_DHCP +#define CONFIG_CMD_NAND +#define CONFIG_CMD_USB /* SDRAM */ -#define CONFIG_NR_DRAM_BANKS 1 +#define CONFIG_NR_DRAM_BANKS 2 #define PHYS_SDRAM 0x7000 #define PHYS_SDRAM_SIZE 0x0800 /* 128 megs */ +#define PHYS_SDRAM_2 0x2000 +#define PHYS_SDRAM_SIZE_20x0800 /* 128 megs */ Preferably those numeric constants should be replaced by defines from a proper at91sam10g45.h /*
Re: [U-Boot] [PATCH 8/8] Updates the boards.cfg file
Dear Alex Waterman, Add the default generic at91sam9m10g45ek_config target to the new config system. Not all possible configurations of u-boot for the at91sam9m10g45ek are included yet. Add them as needed. Signed-off-by: Alex Waterman awater...@dawning.com --- boards.cfg |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/boards.cfg b/boards.cfg index dfefc3f..470bc18 100644 --- a/boards.cfg +++ b/boards.cfg @@ -72,6 +72,7 @@ netstar arm arm925t voicebluearm arm925t omap1510inn arm arm925t - ti aspenite arm arm926ejs - Marvellarmada100 +at91sam9m10g45ek arm arm926ejs at91sam9m10g45ek atmel at91 afeb9260 arm arm926ejs - - at91 at91cap9adk arm arm926ejs - atmel at91 at91sam9260ek_nandflash arm arm926ejs at91sam9260ek atmel at91at91sam9260ek:AT91SAM9260,SYS_USE_NANDFLASH Please sort by manufacturer. The at91sam9m10 would be behind any atmel at91sam926x boards. Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] arm: omap: innovator: use common code for machine type
Innovator and H2 boards used machine_is_* macros for setting the machine
type. These macros are expanded in compile time and thus leaves
unreachable code (though gcc might optimize it).
Switch them to use common code for machine type setting.
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
board/ti/omap1610inn/omap1610innovator.c |7 ---
include/configs/omap1610h2.h |3 ++-
include/configs/omap1610inn.h|3 ++-
3 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/board/ti/omap1610inn/omap1610innovator.c
b/board/ti/omap1610inn/omap1610innovator.c
index 44818bb..16e8237 100644
--- a/board/ti/omap1610inn/omap1610innovator.c
+++ b/board/ti/omap1610inn/omap1610innovator.c
@@ -63,13 +63,6 @@ static inline void delay (unsigned long loops)
int board_init (void)
{
- if (machine_is_omap_h2())
- gd-bd-bi_arch_number = MACH_TYPE_OMAP_H2;
- else if (machine_is_omap_innovator())
- gd-bd-bi_arch_number = MACH_TYPE_OMAP_INNOVATOR;
- else
- gd-bd-bi_arch_number = MACH_TYPE_OMAP_GENERIC;
-
/* adress of boot parameters */
gd-bd-bi_boot_params = 0x1100;
diff --git a/include/configs/omap1610h2.h b/include/configs/omap1610h2.h
index cb2a07f..9fa3317 100644
--- a/include/configs/omap1610h2.h
+++ b/include/configs/omap1610h2.h
@@ -34,7 +34,8 @@
#define CONFIG_OMAP1 /* in a TI OMAP core */
#define CONFIG_OMAP16101 /* which is in a 1610 */
#define CONFIG_H2_OMAP1610 1 /* on an H2 Board */
-#define CONFIG_MACH_OMAP_H2/* Select board mach-type */
+
+#define CONFIG_MACH_TYPE MACH_TYPE_OMAP_H2
/* input clock of PLL */
/* the OMAP1610 H2 has 12MHz input clock */
diff --git a/include/configs/omap1610inn.h b/include/configs/omap1610inn.h
index e82b4b2..e3f3487 100644
--- a/include/configs/omap1610inn.h
+++ b/include/configs/omap1610inn.h
@@ -34,7 +34,8 @@
#define CONFIG_OMAP1 /* in a TI OMAP core*/
#define CONFIG_OMAP16101 /* which is in a 1610 */
#define CONFIG_INNOVATOROMAP1610 1 /* a Innovator Board */
-#define CONFIG_MACH_OMAP_INNOVATOR /* Select board mach-type */
+
+#define CONFIG_MACH_TYPE MACH_TYPE_OMAP_INNOVATOR
/* input clock of PLL */
/* the OMAP1610 Innovator has 12MHz input clock */
--
1.7.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] arm: nvidia and smdk6400: use common code for machine type
NVIDIA boards and Samsung SMDK6400 already use a local variant of
CONFIG_MACH_TYPE option.
Switch to use the new common code.
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
board/nvidia/common/board.c |2 --
board/samsung/smdk6400/smdk6400.c |1 -
include/configs/smdk6400.h|2 +-
3 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/board/nvidia/common/board.c b/board/nvidia/common/board.c
index 3d6c248..7c838e8 100644
--- a/board/nvidia/common/board.c
+++ b/board/nvidia/common/board.c
@@ -205,8 +205,6 @@ int board_init(void)
{
/* boot param addr */
gd-bd-bi_boot_params = (NV_PA_SDRAM_BASE + 0x100);
- /* board id for Linux */
- gd-bd-bi_arch_number = CONFIG_MACH_TYPE;
return 0;
}
diff --git a/board/samsung/smdk6400/smdk6400.c
b/board/samsung/smdk6400/smdk6400.c
index 13c7ed5..c40d1f9 100644
--- a/board/samsung/smdk6400/smdk6400.c
+++ b/board/samsung/smdk6400/smdk6400.c
@@ -72,7 +72,6 @@ int board_init(void)
/* Enable WAIT */
SROM_BW_REG |= 4 | 8 | 1;
- gd-bd-bi_arch_number = MACH_TYPE;
gd-bd-bi_boot_params = PHYS_SDRAM_1 + 0x100;
return 0;
diff --git a/include/configs/smdk6400.h b/include/configs/smdk6400.h
index c9acf58..d175ed6 100644
--- a/include/configs/smdk6400.h
+++ b/include/configs/smdk6400.h
@@ -65,7 +65,7 @@
/*
* Architecture magic and machine type
*/
-#define MACH_TYPE 1270
+#define CONFIG_MACH_TYPE 1270
#define CONFIG_DISPLAY_CPUINFO
#define CONFIG_DISPLAY_BOARDINFO
--
1.7.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] arm: add CONFIG_MACH_TYPE option and documentation
CONFIG_MACH_TYPE can be used to set the machine type number in the common arm code instead of setting it in the board code. Signed-off-by: Igor Grinberg grinb...@compulab.co.il --- README | 12 arch/arm/lib/board.c |5 + 2 files changed, 17 insertions(+), 0 deletions(-) diff --git a/README b/README index 446966d..a9ccb0a 100644 --- a/README +++ b/README @@ -442,6 +442,18 @@ The following options need to be configured: crash. This is needed for buggy hardware (uc101) where no pull down resistor is connected to the signal IDE5V_DD7. + CONFIG_MACH_TYPE[relevant for ARM only] + + This option can be used to specify the machine type number + as it appears in the ARM machine registry + (see http://www.arm.linux.org.uk/developer/machines/). + If this option is not defined, then your board code + will have to set this up like: + gd-bd-bi_arch_number = mach type; + Note: This option is not suitable if you have multiple + boards supported in a single configuration file and the + machine type is runtime discoverable. + - vxWorks boot parameters: bootvx constructs a valid bootline using the following diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c index 169dfeb..ee77d05 100644 --- a/arch/arm/lib/board.c +++ b/arch/arm/lib/board.c @@ -451,6 +451,11 @@ void board_init_r (gd_t *id, ulong dest_addr) monitor_flash_len = _end_ofs; debug (monitor flash len: %08lX\n, monitor_flash_len); + +#ifdef CONFIG_MACH_TYPE + bd-bi_arch_number = CONFIG_MACH_TYPE; /* board id for Linux */ +#endif + board_init(); /* Setup chipselects */ #ifdef CONFIG_SERIAL_MULTI -- 1.7.3.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-arm/master
Hi Wolfgang, The following changes since commit ff6b47ad23365964f7d75f8878f17388a024dc8d: Makefile: need to remove generated u-boot-nand_spl.lds (2011-07-01 15:58:46 -0500) are available in the git repository at: git://git.denx.de/u-boot-arm.git master Andreas Bießmann (9): at91rm9200.h: fix ATMEL_PMX_AA_TXD2 arm920t/at91: add clock.c arm920t/at91: use new clock.c features arm920t/at91: add at91rm9200_devices.c at91rm9200ek: use atmel_usart eb_cpux9k2: use atmel_usart cpuat91: use atmel_usart driver/serial: delete at91rm9200_usart atstk100x: switch to common cfi driver Aneesh V (9): arm: make default implementation of cache_flush() weakly linked armv7: cache maintenance operations for armv7 armv7: rename cache related CONFIG flags armv7: integrate cache maintenance support arm: minor fixes for cache and mmu handling armv7: add PL310 support to u-boot armv7: adapt omap4 to the new cache maintenance framework armv7: adapt omap3 to the new cache maintenance framework armv7: adapt s5pc1xx to the new cache maintenance framework David Müller (ELSOFT AG) (3): VCMA9: remove unneeded config.mk VCMA9: use CFI driver (and remove the old one) VCMA9: various cleanups/code style fixes Fabio Estevam (5): MX5: Make the weim structure complete MX5: Add iomux structure MX5: Introduce a function for setting the chip select size MX53: Add initial support for MX53ARD vision2: Fix build due to WEIM registers name change Holger Brunck (4): arm/kirkwood: if CONFIG_SOFT_I2C is set don't set CONFIG_I2C_MVTWSI arm/km: fix u-boot.kwb build breakage arm/km: remove unneeded define arm/km: replace suenx targets with km_kirkwood Igor Grinberg (1): arm: omap2: apollon: fix broken build Jens Scharsig (1): Fix compiler error for cpu at91sam9, if lowlevel init is enabled John Rigby (1): OMAP[34]: fix broken timer Matthias Weisser (1): arm: Update jadecpu board Simon Guinot (1): Add support for Network Space v2 and parents Tom Warren (2): GPIO: Tegra2: add GPIO driver for Tegra2 arm: Tegra2: GPIO: enable GPIO for Tegra2 boards Valentin Longchamp (3): arm/km: use board KM_ENV_BUS for CONFIG_I2C_ENV_EEPROM_BUS arm/km: ethernet support for mgcoge3un arm/km: add support for portl2 board MAINTAINERS | 14 +- MAKEALL |3 +- README | 11 + arch/arm/cpu/arm1136/start.S |4 +- arch/arm/cpu/arm920t/at91/Makefile |3 + arch/arm/cpu/arm920t/at91/at91rm9200_devices.c | 85 arch/arm/cpu/arm920t/at91/clock.c| 160 +++ arch/arm/cpu/arm920t/at91/cpu.c | 43 ++ arch/arm/cpu/arm926ejs/at91/clock.c | 35 +-- arch/arm/cpu/armv7/Makefile |2 +- arch/arm/cpu/armv7/cache_v7.c| 394 arch/arm/cpu/armv7/cpu.c | 50 +-- arch/arm/cpu/armv7/mx5/soc.c | 30 ++ arch/arm/cpu/armv7/omap-common/timer.c |7 +- arch/arm/cpu/armv7/omap3/Makefile|1 - arch/arm/cpu/armv7/omap3/board.c | 136 +- arch/arm/cpu/armv7/omap3/cache.S | 263 --- arch/arm/cpu/armv7/omap3/lowlevel_init.S | 32 ++ arch/arm/cpu/armv7/omap4/board.c | 12 + arch/arm/cpu/armv7/omap4/lowlevel_init.S |9 + arch/arm/cpu/armv7/s5pc1xx/cache.S | 88 + arch/arm/cpu/armv7/start.S | 18 +- arch/arm/include/asm/arch-at91/at91rm9200.h | 12 +- arch/arm/include/asm/arch-at91/at91sam9_sdramc.h |2 +- arch/arm/include/asm/arch-at91/clk.h | 42 ++- arch/arm/include/asm/arch-kirkwood/config.h |2 + arch/arm/include/asm/arch-mx5/imx-regs.h | 159 ++- arch/arm/include/asm/arch-mx5/sys_proto.h|2 +- arch/arm/include/asm/arch-omap3/omap3.h | 20 + arch/arm/include/asm/arch-omap3/sys_proto.h | 10 +- arch/arm/include/asm/arch-omap4/sys_proto.h |2 +- arch/arm/include/asm/arch-s5pc1xx/sys_proto.h|3 - arch/arm/include/asm/arch-tegra2/gpio.h | 250 ++- arch/arm/include/asm/armv7.h | 67 +++ arch/arm/include/asm/global_data.h |2 +- arch/arm/include/asm/gpio.h | 38 ++ arch/arm/include/asm/pl310.h | 73 +++ arch/arm/include/asm/utils.h | 56 +++ arch/arm/lib/Makefile|3 +- arch/arm/lib/board.c |8 +-
[U-Boot] CF Card Driver on MPC8548
Hi,I've got a problem here. There is a CF card on my board, which is connecting to the Local Bus of MPC8548 using UPM mode. The CF card is connecting in PCcard Memory mode. But I can't find an available or a propriate reference driver. What can I do? Where can I find a reference CF card driver. Thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: Update maintainer of board scb9328
Torsten Koschorrek wrote: Signed-off-by: Torsten Koschorrekkoschor...@synertronixx.de --- MAINTAINERS |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index c462ae2..fe578ef 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -684,7 +684,7 @@ Matthias Kaehlckematth...@kaehlcke.net edb9315 ARM920T (EP9315) edb9315aARM920T (EP9315) -Konstantin Kletschkekletsc...@synertronixx.de +Torsten Koschorrekkoschor...@synertronixx.de scb9328 ARM920T Nishant Kamatnska...@ti.com What about this patch? I don't see it in master yet... Torsten ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] scb9328: Add ARM relocation support
Torsten Koschorrek wrote: Hello, Stefano Babic wrote: On 06/10/2011 07:44 AM, Torsten Koschorrek wrote: Hi Torsten, send your answer to the ML, too. Someone else can help you ;-) Oh, yes, right. This little 'Reply All' Button, sorry :-) size1 = get_ram_size((volatile void *)SCB9328_SDRAM_1, SCB9328_SDRAM_1_SIZE); #if ( CONFIG_NR_DRAM_BANKS1 ) size2 = get_ram_size((volatile void *)SCB9328_SDRAM_2, SCB9328_SDRAM_2_SIZE); . and then: gd-ram_size = size1 + size2 + size3 + size4; Yes, I thought about it. The thing is, we only have one bank on the system. So, dram_init_banksize() needs a cleanup, but that's a problem for another cleanup-patch, which will be committed in a next step. (If it's needed I could do a minor cleanup first...) You decide. However, the code in the patch is wrong. If you have only one bank, you could directly simplify your code, I think. Good point. Unfortunately I have to work on another project today and next week and I think I'm not able to solve the hanging problem. Understood, I tried only to give you some hints where to check ;-) ... and I appreciate that very much :-) Above all, your answers showed me, that I was looking in the right direction so far. Minor fixes (such as config.mk) for the above patch should be possible, though. Ok, agree. Fix first the problem to make MAKEALL happy and build the board again. OK, I just tested it again, MAKEALL is happy. 'include/configs/scb9328.h' is the only file that has to be patched with the patch already send to the ml. 'board/scb9328/config.mk' and 'board/scb9328/scb9328.c' definately need a cleanup, but compilation is ok. The cleanup of those two files 'll be done next week. And hopefully I find some time next week to work on the hangup problem, too. What's the status of this patch? Do I need to resend a modified version without config.mk and scb9328.c? Or I could do a small cleanup as discussed in this thread. But as I said, MAKEALL is happy with the modified scb9328.h thanks Torsten ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC] smc911x: enable mii commands
On 06/30/2011 04:02 PM, Luca Ceresoli wrote:
+static int smc911x_miiphy_read_byname(char *devname, unsigned char addr,
+ unsigned char reg, unsigned short *value)
+{
+ struct eth_device *dev;
+
+ if (devname == NULL)
+ return -1;
+
+ dev = eth_get_dev_by_name(devname);
You're right. eth_get_dev_by_name() is not safe for devname == NULL as
it uses strcmp().
Best would be to fix this there, I'll adjust my patch accordingly.
+
+ if (dev == NULL) {
+ printf(DRIVERNAME : device %s not found\n, devname);
+ return -1;
+ }
None of the other drivers in drivers/net add this kind of verbosity, so
I tend to leave it at that.
Helmut
--
Scanned by MailScanner.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] scb9328: Add ARM relocation support
On 07/04/2011 11:34 AM, Torsten Koschorrek wrote: Hi Torsten, What's the status of this patch? Do I need to resend a modified version without config.mk and scb9328.c? Or I could do a small cleanup as discussed in this thread. But as I said, MAKEALL is happy with the modified scb9328.h The patch is set to Changed requested, that means, you have to fix the issues we discuss in the thread. It will not be merged as it is. You can alwasy check the status of the patches you submit on patchworks.ozlabs.org. 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 3/6] arm: add __ilog2 function
Dear Rob Herring, In message 1309275583-11763-4-git-send-email-robherri...@gmail.com you wrote: From: Rob Herring rob.herr...@calxeda.com Add __ilog2 function for ARM. Needed for ahci.c Signed-off-by: Rob Herring rob.herr...@calxeda.com Cc: Albert ARIBAUD albert.arib...@free.fr --- arch/arm/include/asm/bitops.h |9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/arch/arm/include/asm/bitops.h b/arch/arm/include/asm/bitops.h index 270f163..0420182 100644 --- a/arch/arm/include/asm/bitops.h +++ b/arch/arm/include/asm/bitops.h @@ -106,6 +106,15 @@ static inline int test_bit(int nr, const void * addr) return ((unsigned char *) addr)[nr 3] (1U (nr 7)); } +extern __inline__ int __ilog2(unsigned int x) checkpatch says: WARNING: plain inline is preferred over __inline__ 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 X11 source code style is ATROCIOUS and should not be used as a model. - Doug Gwyn ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6] scsi/ahci: add support for non-PCI controllers
Dear Rob Herring,
In message 1309275583-11763-6-git-send-email-robherri...@gmail.com you wrote:
From: Rob Herring rob.herr...@calxeda.com
Add support for AHCI controllers that are not PCI based.
Signed-off-by: Rob Herring rob.herr...@calxeda.com
Cc: Wolfgang Denk w...@denx.de
---
common/cmd_scsi.c|6 +++-
drivers/block/ahci.c | 70 +++--
include/ahci.h |4 +++
include/scsi.h |1 +
4 files changed, 70 insertions(+), 11 deletions(-)
diff --git a/common/cmd_scsi.c b/common/cmd_scsi.c
index be4fe74..25a8299 100644
--- a/common/cmd_scsi.c
+++ b/common/cmd_scsi.c
@@ -47,7 +47,8 @@
#define SCSI_DEV_ID 0x5288
#else
-#error no scsi device defined
+#define SCSI_VEND_ID 0
+#define SCSI_DEV_ID 0
#endif
I'm not sure if this is a good idea. Please explain.
Also, checkpatch says:
ERROR: trailing whitespace
WARNING: please, no spaces at the start of a line
#287: FILE: include/ahci.h:193:
+ $
+#ifdef CONFIG_PCI
pci_read_config_word(pdev, 0x0a, cc);
if (cc == 0x0101)
scc_s = IDE;
@@ -222,7 +227,9 @@ static void ahci_print_info(struct ahci_probe_ent
*probe_ent)
scc_s = RAID;
else
scc_s = unknown;
-
+#else
+ scc_s = SATA;
+#endif
Is SATA really the only possible option here?
+int ahci_init(u32 base)
+{
...
+}
Should this always be compiled in?
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
Ill-chosen abstraction is particularly evident in the design of the
ADA runtime system. The interface to the ADA runtime system is so
opaque that it is impossible to model or predict its performance,
making it effectively useless for real-time systems.
- Marc D. Donner and David H. Jameson.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/6] Add Highbank platform
Dear Rob Herring, In message 1309275583-11763-1-git-send-email-robherri...@gmail.com you wrote: From: Rob Herring rob.herr...@calxeda.com This series enables non-PCI AHCI controllers and adds support for Calxeda Highbank platform which uses the AHCI changes. Changes from v3: - Added Highbank to MAINTAINERS - Added back patch to fix CONFIG_SKIP_LOWLEVEL_INIT (mistakenly dropped from v2) Wolfgang, Albert, Can you apply these to your trees for v2011.09? All review comments have been addressed. I have to admit that I dislike the way you are working. If I'm not wrong, there have been several versions of your patches around, but you repost again and again without any indication that these are reposts, nor what exactly has been changed between versions. For example, I see three different posts here: 06/11 Rob Herring[U-Boot] [PATCH 8/8] ARM: Add Calxeda Highbank platform http://article.gmane.org/gmane.comp.boot-loaders.u-boot/101435 06/21 Rob Herring[U-Boot] [PATCH 1/5] ARM: Add Calxeda Highbank platform http://article.gmane.org/gmane.comp.boot-loaders.u-boot/101867 06/28 Rob Herring[U-Boot] [PATCH 2/6] ARM: Add Calxeda Highbank platform http://article.gmane.org/gmane.comp.boot-loaders.u-boot/102124 None of these adheres to the requirements as documented here: http://www.denx.de/wiki/view/U-Boot/Patches#Sending_updated_patch_versions Please be aware that NOT documentaing what you changed means that all (potential) reviewers of your code have to spend additional time figuring out what you might have changed, and checking back in the history if you really implemented all earlier review comments. Speaking for me, I must state that being notoriously short of time I am not willing to waste additional time on such postings, so I tend to ignore them. In short: please stick to the rules if you want your patches to go into mainline. 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 ... bacteriological warfare ... hard to believe we were once foolish enough to play around with that. -- McCoy, The Omega Glory, stardate unknown ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] net/eth.c: make eth_get_dev_by_name(NULL) safe
From: Helmut Raiger helmut.rai...@hale.at
eth_get_dev_by_name() is not safe to use for devname being NULL
as it uses strcmp. This patch makes it return NULL if devname NULL
is passed.
Signed-off-by: Helmut Raiger helmut.rai...@hale.at
---
net/eth.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/eth.c b/net/eth.c
index 6523834..c75b7c9 100644
--- a/net/eth.c
+++ b/net/eth.c
@@ -107,7 +107,7 @@ struct eth_device *eth_get_dev_by_name(const char *devname)
{
struct eth_device *dev, *target_dev;
- if (!eth_devices)
+ if (!eth_devices || !devname)
return NULL;
dev = eth_devices;
--
1.7.4.4
--
Scanned by MailScanner.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] smc911x MII made available
From: Helmut Raiger helmut.rai...@hale.at
The driver already had the MII functions, but they have not been
registered using miiphy_register().
Signed-off-by: Helmut Raiger helmut.rai...@hale.at
---
drivers/net/smc911x.c | 36 ++--
1 files changed, 30 insertions(+), 6 deletions(-)
diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
index aeafeba..6cc236c 100644
--- a/drivers/net/smc911x.c
+++ b/drivers/net/smc911x.c
@@ -50,7 +50,7 @@ static void smc911x_handle_mac_address(struct eth_device *dev)
printf(DRIVERNAME : MAC %pM\n, m);
}
-static int smc911x_miiphy_read(struct eth_device *dev,
+static int smc911x_eth_phy_read(struct eth_device *dev,
u8 phy, u8 reg, u16 *val)
{
while (smc911x_get_mac_csr(dev, MII_ACC) MII_ACC_MII_BUSY)
@@ -67,7 +67,7 @@ static int smc911x_miiphy_read(struct eth_device *dev,
return 0;
}
-static int smc911x_miiphy_write(struct eth_device *dev,
+static int smc911x_eth_phy_write(struct eth_device *dev,
u8 phy, u8 reg, u16 val)
{
while (smc911x_get_mac_csr(dev, MII_ACC) MII_ACC_MII_BUSY)
@@ -103,10 +103,10 @@ static void smc911x_phy_configure(struct eth_device *dev)
smc911x_phy_reset(dev);
- smc911x_miiphy_write(dev, 1, MII_BMCR, BMCR_RESET);
+ smc911x_eth_phy_write(dev, 1, MII_BMCR, BMCR_RESET);
mdelay(1);
- smc911x_miiphy_write(dev, 1, MII_ADVERTISE, 0x01e1);
- smc911x_miiphy_write(dev, 1, MII_BMCR, BMCR_ANENABLE |
+ smc911x_eth_phy_write(dev, 1, MII_ADVERTISE, 0x01e1);
+ smc911x_eth_phy_write(dev, 1, MII_BMCR, BMCR_ANENABLE |
BMCR_ANRESTART);
timeout = 5000;
@@ -115,7 +115,7 @@ static void smc911x_phy_configure(struct eth_device *dev)
if ((timeout--) == 0)
goto err_out;
- if (smc911x_miiphy_read(dev, 1, MII_BMSR, status) != 0)
+ if (smc911x_eth_phy_read(dev, 1, MII_BMSR, status) != 0)
goto err_out;
} while (!(status BMSR_LSTATUS));
@@ -235,6 +235,25 @@ static int smc911x_rx(struct eth_device *dev)
return 0;
}
+#if defined(CONFIG_MII) || defined(CONFIG_CMD_MII)
+/* wrapper for smc911x_eth_phy_read */
+static int smc911x_miiphy_read(char *devname, u8 phy, u8 reg, u16 *val)
+{
+ struct eth_device *dev = eth_get_dev_by_name(devname);
+ if (dev)
+ return smc911x_eth_phy_read(dev, phy, reg, val);
+ return -1;
+}
+/* wrapper for smc911x_eth_phy_write */
+static int smc911x_miiphy_write(char *devname, u8 phy, u8 reg, u16 val)
+{
+ struct eth_device *dev = eth_get_dev_by_name(devname);
+ if (dev)
+ return smc911x_eth_phy_write(dev, phy, reg, val);
+ return -1;
+}
+#endif
+
int smc911x_initialize(u8 dev_num, int base_addr)
{
unsigned long addrl, addrh;
@@ -273,5 +292,10 @@ int smc911x_initialize(u8 dev_num, int base_addr)
sprintf(dev-name, %s-%hu, DRIVERNAME, dev_num);
eth_register(dev);
+
+#if defined(CONFIG_MII) || defined(CONFIG_CMD_MII)
+ miiphy_register(dev-name, smc911x_miiphy_read, smc911x_miiphy_write);
+#endif
+
return 1;
}
--
1.7.4.4
--
Scanned by MailScanner.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] sending updated patch versions
Hi Wolfgang, I have a short question about sending updated patch versions. I have read: http://www.denx.de/wiki/view/U-Boot/Patches#Sending_updated_patch_versions and I wonder if it is needed to update the history of *all* patches in a serie even if for different specific patches nothing was changed. Or if it sufficient if only the subject indicates the version number for such patches. E.g patch serie where only 1 patch has changes requested, do I need to update all other patches with the history: Changes for v2: - nothing In the past I did this, but I ask myself if this is really needed. Please let me know what the rules are in such a case. I think the wiki page did not describe what to do with unchanged but version updated patches. Best regards Holger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] scb9328: Add ARM relocation support
This patch fixes compiler errors due to missing definitions of
CONFIG_SYS_SDRAM_BASE and CONFIG_SYS_INIT_SP_ADDR.
It also does some cleanup: CONFIG_SYS_TEXT_BASE was moved to scb9328.h,
obsolete config.mk was removed. The scb9328 board has 1 DRAM bank, so don't
ask for more banks. CONFIG_NR_DRAM_BANKS will ever be 1.
Signed-off-by: Torsten Koschorrek koschor...@synertronixx.de
---
board/scb9328/config.mk | 10 --
board/scb9328/scb9328.c | 24 +---
include/configs/scb9328.h |5 +
3 files changed, 14 insertions(+), 25 deletions(-)
delete mode 100644 board/scb9328/config.mk
diff --git a/board/scb9328/config.mk b/board/scb9328/config.mk
deleted file mode 100644
index 7c5e067..000
--- a/board/scb9328/config.mk
+++ /dev/null
@@ -1,10 +0,0 @@
-#
-# This config file is used for compilation of scb93328 sources
-#
-# You might change location of U-Boot in memory by setting right
CONFIG_SYS_TEXT_BASE.
-# This allows for example having one copy located at the end of ram and
stored
-# in flash device and later on while developing use other location to test
-# the code in RAM device only.
-#
-
-CONFIG_SYS_TEXT_BASE = 0x08f0
diff --git a/board/scb9328/scb9328.c b/board/scb9328/scb9328.c
index 428e8c9..e959b99 100644
--- a/board/scb9328/scb9328.c
+++ b/board/scb9328/scb9328.c
@@ -39,23 +39,17 @@ int board_init (void)
int dram_init (void)
{
-#if ( CONFIG_NR_DRAM_BANKS 0 )
+ /* dram_init must store complete ramsize in gd-ram_size */
+ gd-ram_size = get_ram_size((volatile void *)SCB9328_SDRAM_1,
+ SCB9328_SDRAM_1_SIZE);
+
+ return 0;
+}
+
+void dram_init_banksize (void)
+{
gd-bd-bi_dram[0].start = SCB9328_SDRAM_1;
gd-bd-bi_dram[0].size = SCB9328_SDRAM_1_SIZE;
-#endif
-#if ( CONFIG_NR_DRAM_BANKS 1 )
- gd-bd-bi_dram[1].start = SCB9328_SDRAM_2;
- gd-bd-bi_dram[1].size = SCB9328_SDRAM_2_SIZE;
-#endif
-#if ( CONFIG_NR_DRAM_BANKS 2 )
- gd-bd-bi_dram[2].start = SCB9328_SDRAM_3;
- gd-bd-bi_dram[2].size = SCB9328_SDRAM_3_SIZE;
-#endif
-#if ( CONFIG_NR_DRAM_BANKS 3 )
- gd-bd-bi_dram[3].start = SCB9328_SDRAM_4;
- gd-bd-bi_dram[3].size = SCB9328_SDRAM_4_SIZE;
-#endif
- return 0;
}
/**
diff --git a/include/configs/scb9328.h b/include/configs/scb9328.h
index 6a92ec3..839d0e3 100644
--- a/include/configs/scb9328.h
+++ b/include/configs/scb9328.h
@@ -126,6 +126,11 @@
#define SCB9328_SDRAM_1 0x0800 /* SDRAM bank #1
*/
#define SCB9328_SDRAM_1_SIZE 0x0100 /* 16 MB */
+#define CONFIG_SYS_TEXT_BASE 0x1000
+
+#define CONFIG_SYS_SDRAM_BASE SCB9328_SDRAM_1
+#define CONFIG_SYS_INIT_SP_ADDRSCB9328_SDRAM_1 + 0xf0
+
/*
* Configuration for FLASH memory for the Synertronixx board
*/
--
1.7.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] debugging with XDS100v2 Omap 3530
On 02/07/11 14:47, Amit kumar wrote: Hi, I am new to U-Boot and my task involves porting U-Boot to Omap3530. I have XDS100v2 but I don't have a JTAG Software to support this on Ubuntu host PC. Please, suggest an open source Jtag Software for this. TI's debugger CCSv5.1.x (not open source) plugs into Eclipse (which is) and, I understand, comes with a license to use XDS100. So it is free to use, but not 100% open source. I've only used it on OMAP-L137. And I have and XDS510 not XDS100 because the 100 is very slow. We have 3530s also but most people are still using CCSv4 here. Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] debugging with XDS100v2 Omap 3530
Hi, I found openocd and xds100v2 working with omap3530, the issue was related to libusb version (0.1.12 works fine). Still trying to use it fully. Thanks very much. On Mon, Jul 4, 2011 at 7:11 PM, Nick Thompson nick.thomp...@ge.com wrote: On 02/07/11 14:47, Amit kumar wrote: Hi, I am new to U-Boot and my task involves porting U-Boot to Omap3530. I have XDS100v2 but I don't have a JTAG Software to support this on Ubuntu host PC. Please, suggest an open source Jtag Software for this. TI's debugger CCSv5.1.x (not open source) plugs into Eclipse (which is) and, I understand, comes with a license to use XDS100. So it is free to use, but not 100% open source. I've only used it on OMAP-L137. And I have and XDS510 not XDS100 because the 100 is very slow. We have 3530s also but most people are still using CCSv4 here. Nick. -- Thanking you. From: Amit kumar ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] arm: add __ilog2 function
Wolfgang, On 07/04/2011 05:13 AM, Wolfgang Denk wrote: Dear Rob Herring, In message 1309275583-11763-4-git-send-email-robherri...@gmail.com you wrote: From: Rob Herring rob.herr...@calxeda.com Add __ilog2 function for ARM. Needed for ahci.c Signed-off-by: Rob Herring rob.herr...@calxeda.com Cc: Albert ARIBAUD albert.arib...@free.fr --- arch/arm/include/asm/bitops.h |9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/arch/arm/include/asm/bitops.h b/arch/arm/include/asm/bitops.h index 270f163..0420182 100644 --- a/arch/arm/include/asm/bitops.h +++ b/arch/arm/include/asm/bitops.h @@ -106,6 +106,15 @@ static inline int test_bit(int nr, const void * addr) return ((unsigned char *) addr)[nr 3] (1U (nr 7)); } +extern __inline__ int __ilog2(unsigned int x) checkpatch says: WARNING: plain inline is preferred over __inline__ Sorry about this. I thought I was running checkpatch, but there was a problem in my script I used and it was failing silently. Rob ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] MUSB timeout broken
The following construct (musb_hcd.c, usb_lowlevel_init) timeout = musb_cfg.timeout; while (timeout--) if (readb(musbr-devctl) MUSB_DEVCTL_HM) break; will leave timeout == -1 when the timeout is reached, hence the timeout detecting code that follows will not trigger: /* if musb core is not in host mode, then return */ if (!timeout) return -1; Without the patch below, doing a 'usb reset' without a device connected makes it impossible to discover connected devices later. I have not investigated why this happens since the timeout logic was broken (and correcting that fixed the issue at hand). Changed to pre-decrement since I assume the timeout value is not *that* exact. Thanks, Orjan diff --git a/drivers/usb/musb/musb_hcd.c b/drivers/usb/musb/musb_hcd.c index 974bb31..adcf7f7 100644 --- a/drivers/usb/musb/musb_hcd.c +++ b/drivers/usb/musb/musb_hcd.c @@ -1114,7 +1114,7 @@ int usb_lowlevel_init(void) * should be a usb device connected. */ timeout = musb_cfg.timeout; - while (timeout--) + while (--timeout) if (readb(musbr-devctl) MUSB_DEVCTL_HM) break; -- Orjan Friberg FlatFrog Laboratories AB ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6] scsi/ahci: add support for non-PCI controllers
Wolfgang,
On 07/04/2011 05:17 AM, Wolfgang Denk wrote:
Dear Rob Herring,
In message 1309275583-11763-6-git-send-email-robherri...@gmail.com you
wrote:
From: Rob Herring rob.herr...@calxeda.com
Add support for AHCI controllers that are not PCI based.
Signed-off-by: Rob Herring rob.herr...@calxeda.com
Cc: Wolfgang Denk w...@denx.de
---
common/cmd_scsi.c|6 +++-
drivers/block/ahci.c | 70
+++--
include/ahci.h |4 +++
include/scsi.h |1 +
4 files changed, 70 insertions(+), 11 deletions(-)
diff --git a/common/cmd_scsi.c b/common/cmd_scsi.c
index be4fe74..25a8299 100644
--- a/common/cmd_scsi.c
+++ b/common/cmd_scsi.c
@@ -47,7 +47,8 @@
#define SCSI_DEV_ID 0x5288
#else
-#error no scsi device defined
+#define SCSI_VEND_ID 0
+#define SCSI_DEV_ID 0
#endif
I'm not sure if this is a good idea. Please explain.
This is the PCI ID and is only used here:
common/cmd_scsi.c:183:
busdevfunc=pci_find_device(SCSI_VEND_ID,SCSI_DEV_ID,0); /* get PCI
Device ID */
For a non-PCI AHCI controller, there is no id. For PCI, I don't think 0
is a valid vendor ID anyway.
Also, checkpatch says:
ERROR: trailing whitespace
WARNING: please, no spaces at the start of a line
#287: FILE: include/ahci.h:193:
+ $
+#ifdef CONFIG_PCI
pci_read_config_word(pdev, 0x0a, cc);
if (cc == 0x0101)
scc_s = IDE;
@@ -222,7 +227,9 @@ static void ahci_print_info(struct ahci_probe_ent
*probe_ent)
scc_s = RAID;
else
scc_s = unknown;
-
+#else
+scc_s = SATA;
+#endif
Is SATA really the only possible option here?
Well I suppose anything is possible, but for embbedded SOCs with AHCI
I've seen, they are SATA only. It's purely informational.
+int ahci_init(u32 base)
+{
...
+}
Should this always be compiled in?
I can add a config option CONFIG_SCSI_AHCI_PLAT. Perhaps this would be
better than using CONFIG_PCI as I suppose you could have non-PCI AHCI
controller on a platform with PCI.
Rob
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] sending updated patch versions
Dear Holger, In message 4e119d36.7040...@keymile.com you wrote: and I wonder if it is needed to update the history of *all* patches in a serie even if for different specific patches nothing was changed. Or if it sufficient if only the subject indicates the version number for such patches. If you keep the threading of the messages intact (i. e. supply proper In-reply-to: and References: headers - like you get automatically when inserting the message ID when git send-email asks for the Message-ID to be used as In-Reply-To for the first email), then there is usually no need to resend unchanged patces at all - what for? It would be just a waste of effort and bandwidth. E.g patch serie where only 1 patch has changes requested, do I need to update all other patches with the history: Changes for v2: - nothing No. Please don't repost the unchanged patches at all. Repost just the one that you modified. There are only few cases where you have biggger or more complicated series of patches, which undergo a number of changes here and there where it may make sense to repost a clean version of the whole series. The basic rule here is once again: No news is good news. 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 is wanted is not the will to believe, but the will to find out, which is the exact opposite. - Bertrand Russell, _Sceptical_Essays_, 1928 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MUSB timeout broken
Dear Orjan Friberg, In message 4e11d02e.7030...@flatfrog.com you wrote: The following construct (musb_hcd.c, usb_lowlevel_init) timeout = musb_cfg.timeout; while (timeout--) if (readb(musbr-devctl) MUSB_DEVCTL_HM) break; will leave timeout == -1 when the timeout is reached, hence the timeout detecting code that follows will not trigger: /* if musb core is not in host mode, then return */ if (!timeout) return -1; Without the patch below, doing a 'usb reset' without a device connected makes it impossible to discover connected devices later. I have not investigated why this happens since the timeout logic was broken (and correcting that fixed the issue at hand). Changed to pre-decrement since I assume the timeout value is not *that* exact. Thanks for spotting and reporting. Thanks, Orjan diff --git a/drivers/usb/musb/musb_hcd.c b/drivers/usb/musb/musb_hcd.c index 974bb31..adcf7f7 100644 --- a/drivers/usb/musb/musb_hcd.c +++ b/drivers/usb/musb/musb_hcd.c @@ -1114,7 +1114,7 @@ int usb_lowlevel_init(void) * should be a usb device connected. */ timeout = musb_cfg.timeout; - while (timeout--) + while (--timeout) if (readb(musbr-devctl) MUSB_DEVCTL_HM) break; Unfortunately, your patch is white space corrupted, and missing a proper Signed-off-by: line. Please fix and repost. 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 Q: How many DEC repairman does it take to fix a flat ? A: Five; four to hold the car up and one to swap tires. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6] scsi/ahci: add support for non-PCI controllers
Dear Rob, In message 4e11d372.8090...@calxeda.com you wrote: -#error no scsi device defined +#define SCSI_VEND_ID 0 +#define SCSI_DEV_ID 0 #endif I'm not sure if this is a good idea. Please explain. This is the PCI ID and is only used here: common/cmd_scsi.c:183: busdevfunc=pci_find_device(SCSI_VEND_ID,SCSI_DEV_ID,0); /* get PCI Device ID */ For a non-PCI AHCI controller, there is no id. For PCI, I don't think 0 is a valid vendor ID anyway. I think we should rather skip the respective parts of the code instead of inserting invalid vendor IDs. Should this always be compiled in? I can add a config option CONFIG_SCSI_AHCI_PLAT. Perhaps this would be better than using CONFIG_PCI as I suppose you could have non-PCI AHCI controller on a platform with PCI. Yes, please. 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 ... bacteriological warfare ... hard to believe we were once foolish enough to play around with that. -- McCoy, The Omega Glory, stardate unknown ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/6] Add Highbank platform
Hi Wolfgang, Le 04/07/2011 12:28, Wolfgang Denk a écrit : Dear Albert ARIBAUD, In message4e0c63d0.9010...@aribaud.net you wrote: Seems like there are no additional comments and most of the code is for There are not much additional comments because Rob's patches should all be ignored, or do you have the time to find out which of this versions is what, and what he actually changed? It seems he did not even run checkpatch. Acked-By: Albert ARIBAUDalbert-u-b...@aribaud.net ... and I'll pull it in u-boot-arm/master once the current ARM pull request is processed. I'm not sure if this is a good idea. Understood. Best regards, Wolfgang Denk Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] sending updated patch versions
Hi, On 07/04/2011 05:05 PM, Wolfgang Denk wrote: In message 4e119d36.7040...@keymile.com you wrote: and I wonder if it is needed to update the history of *all* patches in a serie even if for different specific patches nothing was changed. Or if it sufficient if only the subject indicates the version number for such patches. If you keep the threading of the messages intact (i. e. supply proper In-reply-to: and References: headers - like you get automatically when inserting the message ID when git send-email asks for the Message-ID to be used as In-Reply-To for the first email), then there is usually no need to resend unchanged patces at all - what for? It would be just a waste of effort and bandwidth. yes I agree and thats why I am asking. Ah ok, yes I have seen the message from git send-email but wasn't sure how to use this. So if I get a request to update 4/5 from a already posted patch serie which message id I have to enter for In-Reply-To for the first email? I assume I have to use the message id from the initial 4/5 Patch Email which has hit the mailing list or? E.g patch serie where only 1 patch has changes requested, do I need to update all other patches with the history: Changes for v2: - nothing No. Please don't repost the unchanged patches at all. Repost just the one that you modified. yes this sounds reasonable and is also less work for the sender. Best regards Holger Brunck ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] sending updated patch versions
Dear Holger, In message 4e11db54.9000...@keymile.com you wrote: So if I get a request to update 4/5 from a already posted patch serie which message id I have to enter for In-Reply-To for the first email? I assume I have to use the message id from the initial 4/5 Patch Email which has hit the mailing list or? Right. If in doubt, you can see the message ID for example in patchwork. 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 Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to one instruction which doesn't work. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] MUSB timeout broken
Use pre-decrement to leave timeout at 0 when the timeout happens (which is what the timeout detecting code expects). Signed-off-by: Orjan Friberg o...@flatfrog.com --- drivers/usb/musb/musb_hcd.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/usb/musb/musb_hcd.c b/drivers/usb/musb/musb_hcd.c index 974bb31..adcf7f7 100644 --- a/drivers/usb/musb/musb_hcd.c +++ b/drivers/usb/musb/musb_hcd.c @@ -1114,7 +1114,7 @@ int usb_lowlevel_init(void) * should be a usb device connected. */ timeout = musb_cfg.timeout; - while (timeout--) + while (--timeout) if (readb(musbr-devctl) MUSB_DEVCTL_HM) break; -- 1.7.2.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] using a GPIO to toggle tftp boot mode
simple genius. thanks! On Sun, Jul 3, 2011 at 11:12 PM, Albert ARIBAUD albert.u.b...@aribaud.netwrote: Hi Chris, Le 04/07/2011 07:50, Chris Gray a écrit : I'm hoping to come up with a way to configure a recovery mechanism using uboot. the idea is if the main OS image needs to be reflashed, or for recovery options. what are my options for configuring uboot to use a different set of configuration options based on the state of a GPIO line (button)? The cleanest and simplest course would be to use script commands to set up GPIO if it is not already done by the U-Boot code, and set the bootcmd variable to test the GPIO port value on boot and run an internal or tftp boot accordingly. You may want to make sure your board has the HUSH command line interpreter enabled. thanks! np. -CG Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] part_dos: fix crash with big sector size
Hello. I wrote: Apple iPod nanos have sector sizes of 2 or 4 KiB, which crashes U-Boot when it tries to read the MBR into 512-byte buffer situated on stack. Instead use the variable length arrays to be safe with any large sector size. Signed-off-by: Sergei Shtylyov sshtyl...@ru.mvista.com Wolfgang, have you forgotten about this patch? Do I need to resend? WBR, Sergei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/5] Make u-boot a bit easier for newbies to port
After learning a bit about u-boot I created this series of patches that I thought would help people port u-boot in the future. Patches range from adding documentation for things that weren't immediately obvious to me, up to checking to make sure that values that are essential to booting the kernel are at least written to once and haven't been forgotten. Christopher Harvey (5): Added documentation for CONFIG_SYS_TEXT_BASE for ARM. Added extra documentation about how the relocation address to RAM is picked for ARM. Removed unused define, CONFIG_ARMV7. Don't compile in large memory test function by default. Warn when the machine ID isn't passed to an ARM kernel and u-boot is compiled in debug mode. The kernel cannot boot without it. README |9 + arch/arm/lib/board.c|4 arch/arm/lib/bootm.c|6 ++ common/cmd_mem.c|5 + doc/README.arm-relocation |9 - include/configs/am3517_crane.h |2 +- include/configs/am3517_evm.h|2 +- include/configs/ca9x4_ct_vxp.h |2 +- include/configs/cm_t35.h|2 +- include/configs/devkit8000.h|2 +- include/configs/dig297.h|2 +- include/configs/igep0020.h |2 +- include/configs/igep0030.h |2 +- include/configs/omap3_beagle.h |2 +- include/configs/omap3_evm.h |2 +- include/configs/omap3_overo.h |2 +- include/configs/omap3_pandora.h |2 +- include/configs/omap3_sdp3430.h |2 +- include/configs/omap3_zoom1.h |2 +- include/configs/omap3_zoom2.h |2 +- include/configs/omap4_panda.h |2 +- include/configs/omap4_sdp4430.h |2 +- include/configs/s5p_goni.h |2 +- include/configs/s5pc210_universal.h |2 +- include/configs/smdkc100.h |2 +- include/configs/smdkv310.h |2 +- 26 files changed, 53 insertions(+), 22 deletions(-) -- 1.7.3.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/5] Added documentation for CONFIG_SYS_TEXT_BASE for ARM.
Signed-off-by: Christopher Harvey char...@matrox.com --- README |9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/README b/README index a760cf3..a0090ef 100644 --- a/README +++ b/README @@ -2355,6 +2355,15 @@ Configuration Settings: - CONFIG_SYS_SDRAM_BASE: Physical start address of SDRAM. _Must_ be 0 here. +- CONFIG_SYS_TEXT_BASE: + - ARM: + Is the address of the u-boot code that is loaded in memory. + This value can be in ROM space since u-boot can run from + within ROM. CONFIG_SYS_TEXT_BASE is simply called _TEXT_BASE + in some files, like arch/arm/lib/board.c. + This value has nothing to do with the relocation destination + in RAM. See doc/README.arm-relocation for more info. + - CONFIG_SYS_MBIO_BASE: Physical start address of Motherboard I/O (if using a Cogent motherboard) -- 1.7.3.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/5] Added extra documentation about how the relocation address to RAM is picked for ARM.
Signed-off-by: Christopher Harvey char...@matrox.com --- doc/README.arm-relocation |9 - 1 files changed, 8 insertions(+), 1 deletions(-) diff --git a/doc/README.arm-relocation b/doc/README.arm-relocation index 5a9a2fb..954627d 100644 --- a/doc/README.arm-relocation +++ b/doc/README.arm-relocation @@ -22,7 +22,7 @@ At cpu level: modify linker file and add a relocation and fixup loop At board level: dram_init(): bd pointer is now at this point not accessible, so only - detect the real dramsize, and store it in gd-ram_size. Bst detected + detect the real dramsize, and store it in gd-ram_size. Best detected with get_ram_size(). TODO: move also dram initialization there on boards where it is possible. @@ -38,6 +38,13 @@ At lib level: Boards which are not fixed to support relocation will be REMOVED! +The code that picks the location in RAM for ARM can be found in the +arch/arm/lib/board.c file under the board_init_f function. +The postfix _f means executed from flash, and _r means from RAM. +The new location is picked with respect to the highest RAM address, and the +exact final value depends heavily on compile time options. The source is the +best documentation here. + - For boards which boot from nand_spl, it is possible to save one copy -- 1.7.3.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/5] Removed unused define, CONFIG_ARMV7.
Signed-off-by: Christopher Harvey char...@matrox.com --- include/configs/am3517_crane.h |2 +- include/configs/am3517_evm.h|2 +- include/configs/ca9x4_ct_vxp.h |2 +- include/configs/cm_t35.h|2 +- include/configs/devkit8000.h|2 +- include/configs/dig297.h|2 +- include/configs/igep0020.h |2 +- include/configs/igep0030.h |2 +- include/configs/omap3_beagle.h |2 +- include/configs/omap3_evm.h |2 +- include/configs/omap3_overo.h |2 +- include/configs/omap3_pandora.h |2 +- include/configs/omap3_sdp3430.h |2 +- include/configs/omap3_zoom1.h |2 +- include/configs/omap3_zoom2.h |2 +- include/configs/omap4_panda.h |2 +- include/configs/omap4_sdp4430.h |2 +- include/configs/s5p_goni.h |2 +- include/configs/s5pc210_universal.h |2 +- include/configs/smdkc100.h |2 +- include/configs/smdkv310.h |2 +- 21 files changed, 21 insertions(+), 21 deletions(-) diff --git a/include/configs/am3517_crane.h b/include/configs/am3517_crane.h index 09cb951..b809053 100644 --- a/include/configs/am3517_crane.h +++ b/include/configs/am3517_crane.h @@ -28,7 +28,7 @@ /* * High Level Configuration Options */ -#define CONFIG_ARMV7 1 /* This is an ARM V7 CPU core */ + #define CONFIG_OMAP1 /* in a TI OMAP core */ #define CONFIG_OMAP34XX1 /* which is a 34XX */ #define CONFIG_OMAP3_AM3517CRANE 1 /* working with CRANEBOARD */ diff --git a/include/configs/am3517_evm.h b/include/configs/am3517_evm.h index 80ad342..db026c4 100644 --- a/include/configs/am3517_evm.h +++ b/include/configs/am3517_evm.h @@ -28,7 +28,7 @@ /* * High Level Configuration Options */ -#define CONFIG_ARMV7 1 /* This is an ARM V7 CPU core */ + #define CONFIG_OMAP1 /* in a TI OMAP core */ #define CONFIG_OMAP34XX1 /* which is a 34XX */ #define CONFIG_OMAP3_AM3517EVM 1 /* working with AM3517EVM */ diff --git a/include/configs/ca9x4_ct_vxp.h b/include/configs/ca9x4_ct_vxp.h index 7f83249..fd92137 100644 --- a/include/configs/ca9x4_ct_vxp.h +++ b/include/configs/ca9x4_ct_vxp.h @@ -33,7 +33,7 @@ #define CONFIG_SYS_TEXT_BASE 0x6080 /* High Level Configuration Options */ -#define CONFIG_ARMV7 1 + #define CONFIG_SYS_MEMTEST_START 0x6000 #define CONFIG_SYS_MEMTEST_END 0x2000 diff --git a/include/configs/cm_t35.h b/include/configs/cm_t35.h index 93a1b26..b4cec35 100644 --- a/include/configs/cm_t35.h +++ b/include/configs/cm_t35.h @@ -36,7 +36,7 @@ /* * High Level Configuration Options */ -#define CONFIG_ARMV7 1 /* This is an ARM V7 CPU core */ + #define CONFIG_OMAP1 /* in a TI OMAP core */ #define CONFIG_OMAP34XX1 /* which is a 34XX */ #define CONFIG_OMAP34301 /* which is in a 3430 */ diff --git a/include/configs/devkit8000.h b/include/configs/devkit8000.h index 125c690..f97a4ed 100644 --- a/include/configs/devkit8000.h +++ b/include/configs/devkit8000.h @@ -32,7 +32,7 @@ #define __CONFIG_H /* High Level Configuration Options */ -#define CONFIG_ARMV7 1 /* This is an ARM V7 CPU core */ + #define CONFIG_OMAP1 /* in a TI OMAP core */ #define CONFIG_OMAP34XX1 /* which is a 34XX */ #define CONFIG_OMAP34301 /* which is in a 3430 */ diff --git a/include/configs/dig297.h b/include/configs/dig297.h index 7aeb24e..ee0c6be 100644 --- a/include/configs/dig297.h +++ b/include/configs/dig297.h @@ -35,7 +35,7 @@ /* * High Level Configuration Options */ -#define CONFIG_ARMV7 /* This is an ARM V7 CPU core */ + #define CONFIG_OMAP/* in a TI OMAP core */ #define CONFIG_OMAP34XX/* which is a 34XX */ #define CONFIG_OMAP3430/* which is in a 3430 */ diff --git a/include/configs/igep0020.h b/include/configs/igep0020.h index 5af9bec..1c36bc2 100644 --- a/include/configs/igep0020.h +++ b/include/configs/igep0020.h @@ -25,7 +25,7 @@ /* * High Level Configuration Options */ -#define CONFIG_ARMV7 1 /* This is an ARM V7 CPU core */ + #define CONFIG_OMAP1 /* in a TI OMAP core */ #define CONFIG_OMAP34XX1 /* which is a 34XX */ #define CONFIG_OMAP34301 /* which is in a 3430 */ diff --git a/include/configs/igep0030.h b/include/configs/igep0030.h index 92144af..8594b87 100644 --- a/include/configs/igep0030.h +++ b/include/configs/igep0030.h @@ -25,7 +25,7 @@ /* * High Level Configuration Options */ -#define CONFIG_ARMV7 1 /* This is an ARM V7 CPU core */ + #define CONFIG_OMAP1 /* in a TI OMAP core */ #define CONFIG_OMAP34XX
[U-Boot] [PATCH 4/5] Don't compile in large memory test function by default.
Signed-off-by: Christopher Harvey char...@matrox.com --- common/cmd_mem.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/common/cmd_mem.c b/common/cmd_mem.c index a5576aa..833af66 100644 --- a/common/cmd_mem.c +++ b/common/cmd_mem.c @@ -610,6 +610,8 @@ int do_mem_loopw (cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) } #endif /* CONFIG_LOOPW */ +#ifdef CONFIG_CMD_MTEST + /* * Perform a memory test. A more complete alternative test can be * configured using CONFIG_SYS_ALT_MEMTEST. The complete test loops until @@ -965,6 +967,7 @@ int do_mem_mtest (cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) return 0; /* not reached */ } +#endif /* CONFIG_CMD_MTEST */ /* Modify memory. * @@ -1245,11 +1248,13 @@ U_BOOT_CMD( ); #endif /* CONFIG_LOOPW */ +#ifdef CONFIG_CMD_MTEST U_BOOT_CMD( mtest, 5, 1, do_mem_mtest, simple RAM read/write test, [start [end [pattern [iterations ); +#endif /* CONFIG_CMD_MTEST */ #ifdef CONFIG_MX_CYCLIC U_BOOT_CMD( -- 1.7.3.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/5] Warn when the machine ID isn't passed to an ARM kernel and u-boot is compiled in debug mode. The kernel cannot boot without it.
Signed-off-by: Christopher Harvey char...@matrox.com
---
arch/arm/lib/board.c |4
arch/arm/lib/bootm.c |6 ++
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
index 169dfeb..dbb835a 100644
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
@@ -404,6 +404,10 @@ void board_init_f (ulong bootflag)
post_bootmode_init();
post_run (NULL, POST_ROM | post_bootmode_get(0));
#endif
+ /* 0x is used to mark is value as unset.
+ Hopefully there will never be this many machines.
+ Can't use 0 since 0 is already used as a mach-type. */
+ gd-bd-bi_arch_number = 0x;
gd-bd-bi_baudrate = gd-baudrate;
/* Ram ist board specific, so move it to board code ... */
diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index 802e833..70b3b76 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -113,6 +113,12 @@ int do_bootm_linux(int flag, int argc, char *argv[],
bootm_headers_t *images)
printf (Using machid 0x%x from environment\n, machid);
}
+#ifdef DEBUG
+ if(machid==0x) {
+ debug(\nWarning: machid not set! Linux will not finish
booting.\n\n);
+ }
+#endif
+
show_boot_progress (15);
#ifdef CONFIG_OF_LIBFDT
--
1.7.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] Removed unused define, CONFIG_ARMV7.
On Mon, Jul 04, 2011 at 01:44:26PM -0400, Christopher Harvey wrote: Signed-off-by: Christopher Harvey char...@matrox.com --- include/configs/am3517_crane.h |2 +- include/configs/am3517_evm.h|2 +- include/configs/ca9x4_ct_vxp.h |2 +- include/configs/cm_t35.h|2 +- include/configs/devkit8000.h|2 +- include/configs/dig297.h|2 +- include/configs/igep0020.h |2 +- include/configs/igep0030.h |2 +- include/configs/omap3_beagle.h |2 +- include/configs/omap3_evm.h |2 +- include/configs/omap3_overo.h |2 +- include/configs/omap3_pandora.h |2 +- include/configs/omap3_sdp3430.h |2 +- include/configs/omap3_zoom1.h |2 +- include/configs/omap3_zoom2.h |2 +- include/configs/omap4_panda.h |2 +- include/configs/omap4_sdp4430.h |2 +- include/configs/s5p_goni.h |2 +- include/configs/s5pc210_universal.h |2 +- include/configs/smdkc100.h |2 +- include/configs/smdkv310.h |2 +- 21 files changed, 21 insertions(+), 21 deletions(-) diff --git a/include/configs/am3517_crane.h b/include/configs/am3517_crane.h index 09cb951..b809053 100644 --- a/include/configs/am3517_crane.h +++ b/include/configs/am3517_crane.h @@ -28,7 +28,7 @@ /* * High Level Configuration Options */ -#define CONFIG_ARMV7 1 /* This is an ARM V7 CPU core */ + Need the empty line that wasn't there before? Same Q for every file in this patch. #define CONFIG_OMAP 1 /* in a TI OMAP core */ #define CONFIG_OMAP34XX 1 /* which is a 34XX */ #define CONFIG_OMAP3_AM3517CRANE 1 /* working with CRANEBOARD */ diff --git a/include/configs/am3517_evm.h b/include/configs/am3517_evm.h index 80ad342..db026c4 100644 --- a/include/configs/am3517_evm.h +++ b/include/configs/am3517_evm.h @@ -28,7 +28,7 @@ /* * High Level Configuration Options */ -#define CONFIG_ARMV7 1 /* This is an ARM V7 CPU core */ + #define CONFIG_OMAP 1 /* in a TI OMAP core */ #define CONFIG_OMAP34XX 1 /* which is a 34XX */ #define CONFIG_OMAP3_AM3517EVM 1 /* working with AM3517EVM */ diff --git a/include/configs/ca9x4_ct_vxp.h b/include/configs/ca9x4_ct_vxp.h index 7f83249..fd92137 100644 --- a/include/configs/ca9x4_ct_vxp.h +++ b/include/configs/ca9x4_ct_vxp.h @@ -33,7 +33,7 @@ #define CONFIG_SYS_TEXT_BASE 0x6080 /* High Level Configuration Options */ -#define CONFIG_ARMV7 1 + If that was the only remaining high level config option, should the comment be removed? #define CONFIG_SYS_MEMTEST_START 0x6000 #define CONFIG_SYS_MEMTEST_END 0x2000 diff --git a/include/configs/cm_t35.h b/include/configs/cm_t35.h index 93a1b26..b4cec35 100644 --- a/include/configs/cm_t35.h +++ b/include/configs/cm_t35.h @@ -36,7 +36,7 @@ /* * High Level Configuration Options */ -#define CONFIG_ARMV7 1 /* This is an ARM V7 CPU core */ + #define CONFIG_OMAP 1 /* in a TI OMAP core */ #define CONFIG_OMAP34XX 1 /* which is a 34XX */ #define CONFIG_OMAP3430 1 /* which is in a 3430 */ diff --git a/include/configs/devkit8000.h b/include/configs/devkit8000.h index 125c690..f97a4ed 100644 --- a/include/configs/devkit8000.h +++ b/include/configs/devkit8000.h @@ -32,7 +32,7 @@ #define __CONFIG_H /* High Level Configuration Options */ -#define CONFIG_ARMV7 1 /* This is an ARM V7 CPU core */ + #define CONFIG_OMAP 1 /* in a TI OMAP core */ #define CONFIG_OMAP34XX 1 /* which is a 34XX */ #define CONFIG_OMAP3430 1 /* which is in a 3430 */ diff --git a/include/configs/dig297.h b/include/configs/dig297.h index 7aeb24e..ee0c6be 100644 --- a/include/configs/dig297.h +++ b/include/configs/dig297.h @@ -35,7 +35,7 @@ /* * High Level Configuration Options */ -#define CONFIG_ARMV7 /* This is an ARM V7 CPU core */ + #define CONFIG_OMAP /* in a TI OMAP core */ #define CONFIG_OMAP34XX /* which is a 34XX */ #define CONFIG_OMAP3430 /* which is in a 3430 */ diff --git a/include/configs/igep0020.h b/include/configs/igep0020.h index 5af9bec..1c36bc2 100644 --- a/include/configs/igep0020.h +++ b/include/configs/igep0020.h @@ -25,7 +25,7 @@ /* * High Level Configuration Options */ -#define CONFIG_ARMV7 1 /* This is an ARM V7 CPU core */ + #define CONFIG_OMAP 1 /* in a TI OMAP core */ #define CONFIG_OMAP34XX 1 /* which is a 34XX */ #define CONFIG_OMAP3430 1 /* which is in a 3430 */ diff --git a/include/configs/igep0030.h b/include/configs/igep0030.h
Re: [U-Boot] [PATCH 5/5] Warn when the machine ID isn't passed to an ARM kernel and u-boot is compiled in debug mode. The kernel cannot boot without it.
On Mon, Jul 04, 2011 at 01:45:41PM -0400, Christopher Harvey wrote:
Signed-off-by: Christopher Harvey char...@matrox.com
---
arch/arm/lib/board.c |4
arch/arm/lib/bootm.c |6 ++
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
index 169dfeb..dbb835a 100644
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
@@ -404,6 +404,10 @@ void board_init_f (ulong bootflag)
post_bootmode_init();
post_run (NULL, POST_ROM | post_bootmode_get(0));
#endif
+ /* 0x is used to mark is value as unset.
s/mark is/mark a/
+Hopefully there will never be this many machines.
+Can't use 0 since 0 is already used as a mach-type. */
+ gd-bd-bi_arch_number = 0x;
gd-bd-bi_baudrate = gd-baudrate;
/* Ram ist board specific, so move it to board code ... */
diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index 802e833..70b3b76 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -113,6 +113,12 @@ int do_bootm_linux(int flag, int argc, char *argv[],
bootm_headers_t *images)
printf (Using machid 0x%x from environment\n, machid);
}
+#ifdef DEBUG
+ if(machid==0x) {
+ debug(\nWarning: machid not set! Linux will not finish
booting.\n\n);
s/finish/start/ ;-)
Also, shouldn't the compile fail in this case (#error)? Or, at least #warn?
+ }
+#endif
+
show_boot_progress (15);
#ifdef CONFIG_OF_LIBFDT
--
1.7.3.4
Please take comments with a grain of salt, I'm asking, not telling. I'm
fairly new to this as well.
thx,
Jason.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] Removed unused define, CONFIG_ARMV7.
On Mon, Jul 04, 2011 at 02:00:12PM -0400, Jason wrote: On Mon, Jul 04, 2011 at 01:44:26PM -0400, Christopher Harvey wrote: Signed-off-by: Christopher Harvey char...@matrox.com --- include/configs/am3517_crane.h |2 +- include/configs/am3517_evm.h|2 +- include/configs/ca9x4_ct_vxp.h |2 +- include/configs/cm_t35.h|2 +- include/configs/devkit8000.h|2 +- include/configs/dig297.h|2 +- include/configs/igep0020.h |2 +- include/configs/igep0030.h |2 +- include/configs/omap3_beagle.h |2 +- include/configs/omap3_evm.h |2 +- include/configs/omap3_overo.h |2 +- include/configs/omap3_pandora.h |2 +- include/configs/omap3_sdp3430.h |2 +- include/configs/omap3_zoom1.h |2 +- include/configs/omap3_zoom2.h |2 +- include/configs/omap4_panda.h |2 +- include/configs/omap4_sdp4430.h |2 +- include/configs/s5p_goni.h |2 +- include/configs/s5pc210_universal.h |2 +- include/configs/smdkc100.h |2 +- include/configs/smdkv310.h |2 +- 21 files changed, 21 insertions(+), 21 deletions(-) diff --git a/include/configs/am3517_crane.h b/include/configs/am3517_crane.h index 09cb951..b809053 100644 --- a/include/configs/am3517_crane.h +++ b/include/configs/am3517_crane.h @@ -28,7 +28,7 @@ /* * High Level Configuration Options */ -#define CONFIG_ARMV7 1 /* This is an ARM V7 CPU core */ + Need the empty line that wasn't there before? Same Q for every file in this patch. I generated this patch with sed actually. I could easily re-run it and tell it to remove the newlines. Lets see if it gets considered/accepted first. #define CONFIG_OMAP1 /* in a TI OMAP core */ #define CONFIG_OMAP34XX1 /* which is a 34XX */ #define CONFIG_OMAP3_AM3517CRANE 1 /* working with CRANEBOARD */ diff --git a/include/configs/am3517_evm.h b/include/configs/am3517_evm.h index 80ad342..db026c4 100644 --- a/include/configs/am3517_evm.h +++ b/include/configs/am3517_evm.h @@ -28,7 +28,7 @@ /* * High Level Configuration Options */ -#define CONFIG_ARMV7 1 /* This is an ARM V7 CPU core */ + #define CONFIG_OMAP1 /* in a TI OMAP core */ #define CONFIG_OMAP34XX1 /* which is a 34XX */ #define CONFIG_OMAP3_AM3517EVM 1 /* working with AM3517EVM */ diff --git a/include/configs/ca9x4_ct_vxp.h b/include/configs/ca9x4_ct_vxp.h index 7f83249..fd92137 100644 --- a/include/configs/ca9x4_ct_vxp.h +++ b/include/configs/ca9x4_ct_vxp.h @@ -33,7 +33,7 @@ #define CONFIG_SYS_TEXT_BASE 0x6080 /* High Level Configuration Options */ -#define CONFIG_ARMV7 1 + If that was the only remaining high level config option, should the comment be removed? I figured maintainers would get to it eventually. #define CONFIG_SYS_MEMTEST_START 0x6000 #define CONFIG_SYS_MEMTEST_END 0x2000 diff --git a/include/configs/cm_t35.h b/include/configs/cm_t35.h index 93a1b26..b4cec35 100644 --- a/include/configs/cm_t35.h +++ b/include/configs/cm_t35.h @@ -36,7 +36,7 @@ /* * High Level Configuration Options */ -#define CONFIG_ARMV7 1 /* This is an ARM V7 CPU core */ + #define CONFIG_OMAP1 /* in a TI OMAP core */ #define CONFIG_OMAP34XX1 /* which is a 34XX */ #define CONFIG_OMAP34301 /* which is in a 3430 */ diff --git a/include/configs/devkit8000.h b/include/configs/devkit8000.h index 125c690..f97a4ed 100644 --- a/include/configs/devkit8000.h +++ b/include/configs/devkit8000.h @@ -32,7 +32,7 @@ #define __CONFIG_H /* High Level Configuration Options */ -#define CONFIG_ARMV7 1 /* This is an ARM V7 CPU core */ + #define CONFIG_OMAP1 /* in a TI OMAP core */ #define CONFIG_OMAP34XX1 /* which is a 34XX */ #define CONFIG_OMAP34301 /* which is in a 3430 */ diff --git a/include/configs/dig297.h b/include/configs/dig297.h index 7aeb24e..ee0c6be 100644 --- a/include/configs/dig297.h +++ b/include/configs/dig297.h @@ -35,7 +35,7 @@ /* * High Level Configuration Options */ -#define CONFIG_ARMV7 /* This is an ARM V7 CPU core */ + #define CONFIG_OMAP/* in a TI OMAP core */ #define CONFIG_OMAP34XX/* which is a 34XX */ #define CONFIG_OMAP3430/* which is in a 3430 */ diff --git a/include/configs/igep0020.h b/include/configs/igep0020.h index 5af9bec..1c36bc2 100644 --- a/include/configs/igep0020.h +++
Re: [U-Boot] [PATCH 5/5] Warn when the machine ID isn't passed to an ARM kernel and u-boot is compiled in debug mode. The kernel cannot boot without it.
On Mon, Jul 04, 2011 at 02:08:44PM -0400, Jason wrote:
On Mon, Jul 04, 2011 at 01:45:41PM -0400, Christopher Harvey wrote:
Signed-off-by: Christopher Harvey char...@matrox.com
---
arch/arm/lib/board.c |4
arch/arm/lib/bootm.c |6 ++
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
index 169dfeb..dbb835a 100644
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
@@ -404,6 +404,10 @@ void board_init_f (ulong bootflag)
post_bootmode_init();
post_run (NULL, POST_ROM | post_bootmode_get(0));
#endif
+ /* 0x is used to mark is value as unset.
s/mark is/mark a/
Yes, what I meant was:
0x is used to mark a value as unset.
+ Hopefully there will never be this many machines.
+ Can't use 0 since 0 is already used as a mach-type. */
+ gd-bd-bi_arch_number = 0x;
gd-bd-bi_baudrate = gd-baudrate;
/* Ram ist board specific, so move it to board code ... */
diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index 802e833..70b3b76 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -113,6 +113,12 @@ int do_bootm_linux(int flag, int argc, char *argv[],
bootm_headers_t *images)
printf (Using machid 0x%x from environment\n, machid);
}
+#ifdef DEBUG
+ if(machid==0x) {
+ debug(\nWarning: machid not set! Linux will not finish
booting.\n\n);
s/finish/start/ ;-)
I'll have to disagree here. Linux will decompress and some functions
will run but it will eventually stop, hence will not finish.
Also, shouldn't the compile fail in this case (#error)? Or, at least #warn?
The compiler can't know what machid will be at runtime. Maybe a would
you like to continue? prompt could work.
+ }
+#endif
+
show_boot_progress (15);
#ifdef CONFIG_OF_LIBFDT
--
1.7.3.4
Please take comments with a grain of salt, I'm asking, not telling. I'm
fairly new to this as well.
I'm happy to clarify.
thx,
Jason.
thanks,
-Chris
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mx31pdk: cosmetic: Fix line over 80 characters
Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- include/configs/mx31pdk.h |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/include/configs/mx31pdk.h b/include/configs/mx31pdk.h index 5f70023..35ceacd 100644 --- a/include/configs/mx31pdk.h +++ b/include/configs/mx31pdk.h @@ -162,8 +162,10 @@ #define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1 #define CONFIG_SYS_INIT_RAM_ADDR IRAM_BASE_ADDR #define CONFIG_SYS_INIT_RAM_SIZE IRAM_SIZE -#define CONFIG_SYS_GBL_DATA_OFFSET (CONFIG_SYS_INIT_RAM_SIZE - GENERATED_GBL_DATA_SIZE) -#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_GBL_DATA_OFFSET) +#define CONFIG_SYS_GBL_DATA_OFFSET (CONFIG_SYS_INIT_RAM_SIZE - \ + GENERATED_GBL_DATA_SIZE) +#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_INIT_RAM_ADDR + \ + CONFIG_SYS_GBL_DATA_OFFSET) /*--- * FLASH and environment organization -- 1.6.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] Added documentation for CONFIG_SYS_TEXT_BASE for ARM.
Dear Christopher Harvey, In message 20110704174320.gb3...@harvey-pc.matrox.com you wrote: Signed-off-by: Christopher Harvey char...@matrox.com --- README |9 + 1 files changed, 9 insertions(+), 0 deletions(-) Please don't make this ARM specific. CONFIG_SYS_TEXT_BASE has the same meaning for all architectures. diff --git a/README b/README index a760cf3..a0090ef 100644 --- a/README +++ b/README @@ -2355,6 +2355,15 @@ Configuration Settings: - CONFIG_SYS_SDRAM_BASE: Physical start address of SDRAM. _Must_ be 0 here. +- CONFIG_SYS_TEXT_BASE: + - ARM: + Is the address of the u-boot code that is loaded in memory. To be precise: it is the address of the start address of U-Boot in memory. Please omit the that is loaded in memory, because for example on systems booting from ROM (or NOR flash etc.) nothing gets loaded. + This value can be in ROM space since u-boot can run from + within ROM. ... Again, not strictly correct. Only some parts of U-Boot (the part before relocation) can run from ROM. + ... CONFIG_SYS_TEXT_BASE is simply called _TEXT_BASE + in some files, like arch/arm/lib/board.c. I consider this a bad idea. It should not be documented, but rather fixed. + This value has nothing to do with the relocation destination + in RAM. See doc/README.arm-relocation for more info. Again, I'm unhappy to see this being ARM specific. It ain't so, on contrary - we changed ARM to do this so as ARMis in sync with other architectures. 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 Uncontrolled power will turn even saints into savages. And we can all be counted on to live down to our lowest impulses. -- Parmen, Plato's Stepchildren, stardate 5784.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] Added extra documentation about how the relocation address to RAM is picked for ARM.
Dear Christopher Harvey, In message 20110704174348.gc3...@harvey-pc.matrox.com you wrote: Signed-off-by: Christopher Harvey char...@matrox.com --- doc/README.arm-relocation |9 - 1 files changed, 8 insertions(+), 1 deletions(-) Please let's stop with ARM specific documatation of things that are considered generic. +The code that picks the location in RAM for ARM can be found in the +arch/arm/lib/board.c file under the board_init_f function. under the function? Who dropped that code? :-) s/under/in/ Also delete for ARM, and s/arm/arch/. This is not ARM specific. +The postfix _f means executed from flash, and _r means from RAM. Maybe we whould rather write ... from NOR flash to indicate that we actually mean ROM. +The new location is picked with respect to the highest RAM address, and the +exact final value depends heavily on compile time options. The source is the +best documentation here. This should be changed, i. e. better documentation should be provided :-) 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 Obviously, a major malfunction has occurred. -- Steve Nesbitt, voice of Mission Control, January 28, 1986, as the shuttle Challenger exploded within view of the grandstands. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] Removed unused define, CONFIG_ARMV7.
Dear Christopher Harvey, In message 20110704184659.gg3...@harvey-pc.matrox.com you wrote: Need the empty line that wasn't there before? Same Q for every file in this patch. I generated this patch with sed actually. I could easily re-run it and tell it to remove the newlines. Lets see if it gets considered/accepted first. Please fix this (and the other comments), and it goes in. #define CONFIG_SYS_TEXT_BASE 0x6080 /* High Level Configuration Options */ -#define CONFIG_ARMV7 1 + If that was the only remaining high level config option, should the comment be removed? I figured maintainers would get to it eventually. Such eventually never works. Please go through this manually and clean up. 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 Wenn Du ein' weise Antwort verlangst, Mußt Du vernünftig fragen. -- Goethe, Invektiven ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] Warn when the machine ID isn't passed to an ARM kernel and u-boot is compiled in debug mode. The kernel cannot boot without it.
Dear Christopher Harvey, In message 20110704174541.gf3...@harvey-pc.matrox.com you wrote: Signed-off-by: Christopher Harvey char...@matrox.com --- arch/arm/lib/board.c |4 arch/arm/lib/bootm.c |6 ++ 2 files changed, 10 insertions(+), 0 deletions(-) diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c index 169dfeb..dbb835a 100644 --- a/arch/arm/lib/board.c +++ b/arch/arm/lib/board.c @@ -404,6 +404,10 @@ void board_init_f (ulong bootflag) post_bootmode_init(); post_run (NULL, POST_ROM | post_bootmode_get(0)); #endif + /* 0x is used to mark is value as unset. +Hopefully there will never be this many machines. +Can't use 0 since 0 is already used as a mach-type. */ + gd-bd-bi_arch_number = 0x; Incorrect multiline comment style. Instead of using hardwired magic numbers, please use a #define'd constant (add to arch/arm/include/asm/u-boot.h close to where bi_arch_number gets defined). 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 [Braddock:] Mr. Churchill, you are drunk. [Churchill:] And you madam, are ugly. But I shall be sober tomorrow. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] Warn when the machine ID isn't passed to an ARM kernel and u-boot is compiled in debug mode. The kernel cannot boot without it.
Dear Christopher Harvey, In message 20110704185554.gh3...@harvey-pc.matrox.com you wrote: On Mon, Jul 04, 2011 at 02:08:44PM -0400, Jason wrote: On Mon, Jul 04, 2011 at 01:45:41PM -0400, Christopher Harvey wrote: Signed-off-by: Christopher Harvey char...@matrox.com --- arch/arm/lib/board.c |4 arch/arm/lib/bootm.c |6 ++ 2 files changed, 10 insertions(+), 0 deletions(-) diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c index 169dfeb..dbb835a 100644 --- a/arch/arm/lib/board.c +++ b/arch/arm/lib/board.c @@ -404,6 +404,10 @@ void board_init_f (ulong bootflag) post_bootmode_init(); post_run (NULL, POST_ROM | post_bootmode_get(0)); #endif + /* 0x is used to mark is value as unset. s/mark is/mark a/ Yes, what I meant was: 0x is used to mark a value as unset. But this is wrong. It is not unset (= undefined), it is set. More specifically, it is set to an illegal value. Also, shouldn't the compile fail in this case (#error)? Or, at least #warn? The compiler can't know what machid will be at runtime. Maybe a would you like to continue? prompt could work. No. Just print a warning message, and continue. 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 To know how another being, another creature feels - that is impos- sible. - Terry Pratchett, _The Dark Side of the Sun_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] Warn when the machine ID isn't passed to an ARM kernel and u-boot is compiled in debug mode. The kernel cannot boot without it.
On Mon, Jul 04, 2011 at 02:55:54PM -0400, Christopher Harvey wrote:
On Mon, Jul 04, 2011 at 02:08:44PM -0400, Jason wrote:
On Mon, Jul 04, 2011 at 01:45:41PM -0400, Christopher Harvey wrote:
+Hopefully there will never be this many machines.
+Can't use 0 since 0 is already used as a mach-type. */
+ gd-bd-bi_arch_number = 0x;
gd-bd-bi_baudrate = gd-baudrate;
/* Ram ist board specific, so move it to board code ... */
diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index 802e833..70b3b76 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -113,6 +113,12 @@ int do_bootm_linux(int flag, int argc, char *argv[],
bootm_headers_t *images)
printf (Using machid 0x%x from environment\n, machid);
}
+#ifdef DEBUG
+ if(machid==0x) {
+ debug(\nWarning: machid not set! Linux will not finish
booting.\n\n);
s/finish/start/ ;-)
I'll have to disagree here. Linux will decompress and some functions
will run but it will eventually stop, hence will not finish.
On further investigation, you're right, it doesn't finish
starting/booting. Sorry for the noise.
Also, shouldn't the compile fail in this case (#error)? Or, at least #warn?
The compiler can't know what machid will be at runtime. Maybe a would
you like to continue? prompt could work.
Since the kernel throws a nice fat error message when the MACH_TYPE
doesn't match what it was compiled for, I don't see the point to adding
another message at the same point in the development process.
Perhaps use the constant CONFIG_MACH_TYPE, set to 0x. Each
board config file sets it to MACH_TYPE_WHATEVER and then you could
do:
#if CONFIG_MACH_TYPE == 0x
#warning Machine type not set! Linux will not finish booting!
#endif
You could use -Werror to fail on such things. DBGFLAGS in ./config.mk
might be a good place.
If the maintainers choose to move to a menuconfig style configuration
system, this logic could be handled in there (invalid config file).
Please take comments with a grain of salt, I'm asking, not telling. I'm
fairly new to this as well.
I'm happy to clarify.
Thanks for exercising my brain before I seek out the beer and
explosives. ;-)
Jason.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] Warn when the machine ID isn't passed to an ARM kernel and u-boot is compiled in debug mode. The kernel cannot boot without it.
On Mon, Jul 04, 2011 at 04:13:49PM -0400, Jason wrote:
On Mon, Jul 04, 2011 at 02:55:54PM -0400, Christopher Harvey wrote:
On Mon, Jul 04, 2011 at 02:08:44PM -0400, Jason wrote:
On Mon, Jul 04, 2011 at 01:45:41PM -0400, Christopher Harvey wrote:
+ Hopefully there will never be this many machines.
+ Can't use 0 since 0 is already used as a mach-type. */
+ gd-bd-bi_arch_number = 0x;
gd-bd-bi_baudrate = gd-baudrate;
/* Ram ist board specific, so move it to board code ... */
diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index 802e833..70b3b76 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -113,6 +113,12 @@ int do_bootm_linux(int flag, int argc, char
*argv[], bootm_headers_t *images)
printf (Using machid 0x%x from environment\n, machid);
}
+#ifdef DEBUG
+ if(machid==0x) {
+ debug(\nWarning: machid not set! Linux will not finish
booting.\n\n);
s/finish/start/ ;-)
I'll have to disagree here. Linux will decompress and some functions
will run but it will eventually stop, hence will not finish.
On further investigation, you're right, it doesn't finish
starting/booting. Sorry for the noise.
Also, shouldn't the compile fail in this case (#error)? Or, at least
#warn?
The compiler can't know what machid will be at runtime. Maybe a would
you like to continue? prompt could work.
Since the kernel throws a nice fat error message when the MACH_TYPE
doesn't match what it was compiled for, I don't see the point to adding
another message at the same point in the development process.
I didn't see that message. Do you know what lines of code in the
kernel print it? Or maybe just the message itself?
If the kernel can check the value why would it need to be passed
in the first place?
Perhaps use the constant CONFIG_MACH_TYPE, set to 0x. Each
board config file sets it to MACH_TYPE_WHATEVER and then you could
do:
#if CONFIG_MACH_TYPE == 0x
#warning Machine type not set! Linux will not finish booting!
#endif
You could use -Werror to fail on such things. DBGFLAGS in ./config.mk
might be a good place.
If the maintainers choose to move to a menuconfig style configuration
system, this logic could be handled in there (invalid config file).
Right now CONFIG_MACH_TYPE is only used in a few boards and isn't used
in core u-boot code, so I ignored it. I would agree that perhaps
adding a CONFIG_MACH_TYPE to u-boot would be a more elegant solution
than checking to make sure that it is a valid value before boot, but
that would be another patch.
Please take comments with a grain of salt, I'm asking, not telling. I'm
fairly new to this as well.
I'm happy to clarify.
Thanks for exercising my brain before I seek out the beer and
explosives. ;-)
Jason.
-Chris
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] video: Use memset instead of loop
On Wed, 29 Jun 2011 13:57:25 +0200 Matthias Weisser weiss...@arcor.de wrote: There is a optimized version of memset in u-boot available so use it instead of the hand written loop version. Signed-off-by: Matthias Weisser weiss...@arcor.de --- drivers/video/mb86r0xgdc.c |3 +-- 1 files changed, 1 insertions(+), 2 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 1/3] arm: add CONFIG_MACH_TYPE option and documentation
On Mon, Jul 04, 2011 at 12:00:19PM +0300, Igor Grinberg wrote: CONFIG_MACH_TYPE can be used to set the machine type number in the common arm code instead of setting it in the board code. Signed-off-by: Igor Grinberg grinb...@compulab.co.il --- README | 12 arch/arm/lib/board.c |5 + 2 files changed, 17 insertions(+), 0 deletions(-) diff --git a/README b/README index 446966d..a9ccb0a 100644 --- a/README +++ b/README @@ -442,6 +442,18 @@ The following options need to be configured: crash. This is needed for buggy hardware (uc101) where no pull down resistor is connected to the signal IDE5V_DD7. + CONFIG_MACH_TYPE[relevant for ARM only] + + This option can be used to specify the machine type number + as it appears in the ARM machine registry + (see http://www.arm.linux.org.uk/developer/machines/). + If this option is not defined, then your board code + will have to set this up like: + gd-bd-bi_arch_number = mach type; + Note: This option is not suitable if you have multiple + boards supported in a single configuration file and the + machine type is runtime discoverable. + - vxWorks boot parameters: bootvx constructs a valid bootline using the following diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c index 169dfeb..ee77d05 100644 --- a/arch/arm/lib/board.c +++ b/arch/arm/lib/board.c @@ -451,6 +451,11 @@ void board_init_r (gd_t *id, ulong dest_addr) monitor_flash_len = _end_ofs; debug (monitor flash len: %08lX\n, monitor_flash_len); + +#ifdef CONFIG_MACH_TYPE + bd-bi_arch_number = CONFIG_MACH_TYPE; /* board id for Linux */ +#endif + board_init(); /* Setup chipselects */ #ifdef CONFIG_SERIAL_MULTI -- 1.7.3.4 I'm curious, is it a feature that bd-bi_arch_number can be set at runtime? Do any boards actually make a decision about what value to set this to? If not, then maybe it should be a required value. I've submitted some patches that deal with the same sort of issue, so I'm interested in seeing that happens to this one. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] Warn when the machine ID isn't passed to an ARM kernel and u-boot is compiled in debug mode. The kernel cannot boot without it.
On Mon, Jul 04, 2011 at 04:32:35PM -0400, Christopher Harvey wrote:
On Mon, Jul 04, 2011 at 04:13:49PM -0400, Jason wrote:
On Mon, Jul 04, 2011 at 02:55:54PM -0400, Christopher Harvey wrote:
On Mon, Jul 04, 2011 at 02:08:44PM -0400, Jason wrote:
On Mon, Jul 04, 2011 at 01:45:41PM -0400, Christopher Harvey wrote:
+Hopefully there will never be this many machines.
+Can't use 0 since 0 is already used as a mach-type. */
+ gd-bd-bi_arch_number = 0x;
gd-bd-bi_baudrate = gd-baudrate;
/* Ram ist board specific, so move it to board code ... */
diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index 802e833..70b3b76 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -113,6 +113,12 @@ int do_bootm_linux(int flag, int argc, char
*argv[], bootm_headers_t *images)
printf (Using machid 0x%x from environment\n, machid);
}
+#ifdef DEBUG
+ if(machid==0x) {
+ debug(\nWarning: machid not set! Linux will not finish
booting.\n\n);
s/finish/start/ ;-)
I'll have to disagree here. Linux will decompress and some functions
will run but it will eventually stop, hence will not finish.
On further investigation, you're right, it doesn't finish
starting/booting. Sorry for the noise.
Also, shouldn't the compile fail in this case (#error)? Or, at least
#warn?
The compiler can't know what machid will be at runtime. Maybe a would
you like to continue? prompt could work.
Since the kernel throws a nice fat error message when the MACH_TYPE
doesn't match what it was compiled for, I don't see the point to adding
another message at the same point in the development process.
I didn't see that message. Do you know what lines of code in the
kernel print it? Or maybe just the message itself?
In init/main.c
start_kernel() calls
setup_arch()
In arch/arm/kernel/setup.c
setup_arch() calls
setup_machine_tags() which calls
dump_machine_table()
when the value in r1 doesn't match any of the mach-types the kernel was
compiled for.
If the kernel can check the value why would it need to be passed
in the first place?
Because the kernel has no way of easily determining which arm board it's
running on without this feature.
hth,
Jason.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] video: update Makefile to include OMAP3 DSS driver
From: Jason Kridner jkrid...@beagleboard.org Adding the OMAP3 DSS video driver to the Makefile. The patch applied to u-boot-ti didn't include this for some reason. Signed-off-by: Jason Kridner jkrid...@beagleboard.org Signed-off-by: Anatolij Gustschin ag...@denx.de --- replaces patch video: DSS makefile update to - drop unconditional include of videomode.o since it is wrong - sort in alphabetical order - fix the commit message drivers/video/Makefile |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/video/Makefile b/drivers/video/Makefile index 086dc05..402f517 100644 --- a/drivers/video/Makefile +++ b/drivers/video/Makefile @@ -36,6 +36,7 @@ COBJS-$(CONFIG_VIDEO_MB862xx) += mb862xx.o videomodes.o COBJS-$(CONFIG_VIDEO_MB86R0xGDC) += mb86r0xgdc.o videomodes.o COBJS-$(CONFIG_VIDEO_MX3) += mx3fb.o COBJS-$(CONFIG_VIDEO_MX5) += mxc_ipuv3_fb.o ipu_common.o ipu_disp.o +COBJS-$(CONFIG_VIDEO_OMAP3) += omap3_dss.o COBJS-$(CONFIG_VIDEO_SED13806) += sed13806.o COBJS-$(CONFIG_SED156X) += sed156x.o COBJS-$(CONFIG_VIDEO_SM501) += sm501.o -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] OMAP3: Add DSS driver for OMAP3
On Wed, 20 Apr 2011 18:52:48 -0500 Jason Kridner jkrid...@beagleboard.org wrote: From: Syed Mohammed Khasim kha...@ti.com Supports dynamic panel configuration Supports dynamic tv standard selection Adds support for DSS register access through generic APIs Incorporated DSS register access using structures. Previous discussions are here http://www.mail-archive.com/u-boot@lists.denx.de/msg27150.html --- v2 updates: * Enable panel output for BeagleBoard * BeagleBoard: Update DVI-D orange screen frequencies for xM v3 updates: * Remove non-platform (OMAP3) updates Signed-off-by: Syed Mohammed Khasim kha...@ti.com Signed-off-by: Jason Kridner jkrid...@beagleboard.org --- arch/arm/include/asm/arch-omap3/dss.h | 173 + drivers/video/omap3_dss.c | 130 + 2 files changed, 303 insertions(+), 0 deletions(-) create mode 100644 arch/arm/include/asm/arch-omap3/dss.h create mode 100644 drivers/video/omap3_dss.c applied to u-boot-video/master after fixing the commit description to include SoB lines. Thanks! Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] arm: add CONFIG_MACH_TYPE option and documentation
Hi Harvey, Le 04/07/2011 23:06, Christopher Harvey a écrit : On Mon, Jul 04, 2011 at 12:00:19PM +0300, Igor Grinberg wrote: CONFIG_MACH_TYPE can be used to set the machine type number in the common arm code instead of setting it in the board code. Signed-off-by: Igor Grinberggrinb...@compulab.co.il --- README | 12 arch/arm/lib/board.c |5 + 2 files changed, 17 insertions(+), 0 deletions(-) diff --git a/README b/README index 446966d..a9ccb0a 100644 --- a/README +++ b/README @@ -442,6 +442,18 @@ The following options need to be configured: crash. This is needed for buggy hardware (uc101) where no pull down resistor is connected to the signal IDE5V_DD7. +CONFIG_MACH_TYPE[relevant for ARM only] + +This option can be used to specify the machine type number +as it appears in the ARM machine registry +(see http://www.arm.linux.org.uk/developer/machines/). +If this option is not defined, then your board code +will have to set this up like: +gd-bd-bi_arch_number =mach type; +Note: This option is not suitable if you have multiple +boards supported in a single configuration file and the +machine type is runtime discoverable. + - vxWorks boot parameters: bootvx constructs a valid bootline using the following diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c index 169dfeb..ee77d05 100644 --- a/arch/arm/lib/board.c +++ b/arch/arm/lib/board.c @@ -451,6 +451,11 @@ void board_init_r (gd_t *id, ulong dest_addr) monitor_flash_len = _end_ofs; debug (monitor flash len: %08lX\n, monitor_flash_len); + +#ifdef CONFIG_MACH_TYPE +bd-bi_arch_number = CONFIG_MACH_TYPE; /* board id for Linux */ +#endif + board_init(); /* Setup chipselects */ #ifdef CONFIG_SERIAL_MULTI -- 1.7.3.4 I'm curious, is it a feature that bd-bi_arch_number can be set at runtime? Do any boards actually make a decision about what value to set this to? If not, then maybe it should be a required value. I've submitted some patches that deal with the same sort of issue, so I'm interested in seeing that happens to this one. Some boards indeed have a feature to set the mach_type at runtime, for example to run both the mainline linux kernel and a manufacturer one (manufacturers tend to use/expect fancy machine types). Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] arm: add CONFIG_MACH_TYPE option and documentation
Le 05/07/2011 00:03, Albert ARIBAUD a écrit : Hi Harvey, Sorry Christopher, I mixed up. Le 04/07/2011 23:06, Christopher Harvey a écrit : On Mon, Jul 04, 2011 at 12:00:19PM +0300, Igor Grinberg wrote: CONFIG_MACH_TYPE can be used to set the machine type number in the common arm code instead of setting it in the board code. Signed-off-by: Igor Grinberggrinb...@compulab.co.il --- README | 12 arch/arm/lib/board.c |5 + 2 files changed, 17 insertions(+), 0 deletions(-) diff --git a/README b/README index 446966d..a9ccb0a 100644 --- a/README +++ b/README @@ -442,6 +442,18 @@ The following options need to be configured: crash. This is needed for buggy hardware (uc101) where no pull down resistor is connected to the signal IDE5V_DD7. + CONFIG_MACH_TYPE[relevant for ARM only] + + This option can be used to specify the machine type number + as it appears in the ARM machine registry + (see http://www.arm.linux.org.uk/developer/machines/). + If this option is not defined, then your board code + will have to set this up like: + gd-bd-bi_arch_number =mach type; + Note: This option is not suitable if you have multiple + boards supported in a single configuration file and the + machine type is runtime discoverable. + - vxWorks boot parameters: bootvx constructs a valid bootline using the following diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c index 169dfeb..ee77d05 100644 --- a/arch/arm/lib/board.c +++ b/arch/arm/lib/board.c @@ -451,6 +451,11 @@ void board_init_r (gd_t *id, ulong dest_addr) monitor_flash_len = _end_ofs; debug (monitor flash len: %08lX\n, monitor_flash_len); + +#ifdef CONFIG_MACH_TYPE + bd-bi_arch_number = CONFIG_MACH_TYPE; /* board id for Linux */ +#endif + board_init(); /* Setup chipselects */ #ifdef CONFIG_SERIAL_MULTI -- 1.7.3.4 I'm curious, is it a feature that bd-bi_arch_number can be set at runtime? Do any boards actually make a decision about what value to set this to? If not, then maybe it should be a required value. I've submitted some patches that deal with the same sort of issue, so I'm interested in seeing that happens to this one. Some boards indeed have a feature to set the mach_type at runtime, for example to run both the mainline linux kernel and a manufacturer one (manufacturers tend to use/expect fancy machine types). Amicalement, Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] arm: add CONFIG_MACH_TYPE option and documentation
Dear Christopher Harvey, In message 20110704210619.ga3...@harvey-pc.matrox.com you wrote: I'm curious, is it a feature that bd-bi_arch_number can be set at runtime? Do any boards actually make a decision about what value to Yes, this is a feature. It comes in handy in a number of cases. set this to? If not, then maybe it should be a required value. I've Why? submitted some patches that deal with the same sort of issue, so I'm interested in seeing that happens to this one. Sorry, I can't follow... 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 rule on staying alive as a program manager is to give 'em a num- ber or give 'em a date, but never give 'em both at once. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] video: mb862xx: support Coral-PA controller
On Fri, 27 May 2011 16:08:20 +0200 Anatolij Gustschin ag...@denx.de wrote: Add detection of Coral-PA and configure Coral CCF an MMR parameters using CONFIG_SYS_MB862xx_CCF and CONFIG_SYS_MB862xx_MMR macros. Use CCF and MMR parameters for Coral-P Eval. Board if the appropriate macros weren't defined. Signed-off-by: Anatolij Gustschin ag...@denx.de --- drivers/video/mb862xx.c | 32 +++- 1 files changed, 27 insertions(+), 5 deletions(-) applied to u-boot-video/master. Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-arm/master
Dear Albert ARIBAUD, In message 4e1182f8.2010...@aribaud.net you wrote: Hi Wolfgang, The following changes since commit ff6b47ad23365964f7d75f8878f17388a024dc8d: Makefile: need to remove generated u-boot-nand_spl.lds (2011-07-01 15:58:46 -0500) are available in the git repository at: git://git.denx.de/u-boot-arm.git master Andreas Bießmann (9): at91rm9200.h: fix ATMEL_PMX_AA_TXD2 arm920t/at91: add clock.c arm920t/at91: use new clock.c features arm920t/at91: add at91rm9200_devices.c at91rm9200ek: use atmel_usart eb_cpux9k2: use atmel_usart cpuat91: use atmel_usart driver/serial: delete at91rm9200_usart atstk100x: switch to common cfi driver Aneesh V (9): arm: make default implementation of cache_flush() weakly linked armv7: cache maintenance operations for armv7 armv7: rename cache related CONFIG flags armv7: integrate cache maintenance support arm: minor fixes for cache and mmu handling armv7: add PL310 support to u-boot armv7: adapt omap4 to the new cache maintenance framework armv7: adapt omap3 to the new cache maintenance framework armv7: adapt s5pc1xx to the new cache maintenance framework David Müller (ELSOFT AG) (3): VCMA9: remove unneeded config.mk VCMA9: use CFI driver (and remove the old one) VCMA9: various cleanups/code style fixes Fabio Estevam (5): MX5: Make the weim structure complete MX5: Add iomux structure MX5: Introduce a function for setting the chip select size MX53: Add initial support for MX53ARD vision2: Fix build due to WEIM registers name change Holger Brunck (4): arm/kirkwood: if CONFIG_SOFT_I2C is set don't set CONFIG_I2C_MVTWSI arm/km: fix u-boot.kwb build breakage arm/km: remove unneeded define arm/km: replace suenx targets with km_kirkwood Igor Grinberg (1): arm: omap2: apollon: fix broken build Jens Scharsig (1): Fix compiler error for cpu at91sam9, if lowlevel init is enabled John Rigby (1): OMAP[34]: fix broken timer Matthias Weisser (1): arm: Update jadecpu board Simon Guinot (1): Add support for Network Space v2 and parents Tom Warren (2): GPIO: Tegra2: add GPIO driver for Tegra2 arm: Tegra2: GPIO: enable GPIO for Tegra2 boards Valentin Longchamp (3): arm/km: use board KM_ENV_BUS for CONFIG_I2C_ENV_EEPROM_BUS arm/km: ethernet support for mgcoge3un arm/km: add support for portl2 board MAINTAINERS | 14 +- MAKEALL |3 +- README | 11 + arch/arm/cpu/arm1136/start.S |4 +- arch/arm/cpu/arm920t/at91/Makefile |3 + arch/arm/cpu/arm920t/at91/at91rm9200_devices.c | 85 arch/arm/cpu/arm920t/at91/clock.c| 160 +++ arch/arm/cpu/arm920t/at91/cpu.c | 43 ++ arch/arm/cpu/arm926ejs/at91/clock.c | 35 +-- arch/arm/cpu/armv7/Makefile |2 +- arch/arm/cpu/armv7/cache_v7.c| 394 arch/arm/cpu/armv7/cpu.c | 50 +-- arch/arm/cpu/armv7/mx5/soc.c | 30 ++ arch/arm/cpu/armv7/omap-common/timer.c |7 +- arch/arm/cpu/armv7/omap3/Makefile|1 - arch/arm/cpu/armv7/omap3/board.c | 136 +- arch/arm/cpu/armv7/omap3/cache.S | 263 --- arch/arm/cpu/armv7/omap3/lowlevel_init.S | 32 ++ arch/arm/cpu/armv7/omap4/board.c | 12 + arch/arm/cpu/armv7/omap4/lowlevel_init.S |9 + arch/arm/cpu/armv7/s5pc1xx/cache.S | 88 + arch/arm/cpu/armv7/start.S | 18 +- arch/arm/include/asm/arch-at91/at91rm9200.h | 12 +- arch/arm/include/asm/arch-at91/at91sam9_sdramc.h |2 +- arch/arm/include/asm/arch-at91/clk.h | 42 ++- arch/arm/include/asm/arch-kirkwood/config.h |2 + arch/arm/include/asm/arch-mx5/imx-regs.h | 159 ++- arch/arm/include/asm/arch-mx5/sys_proto.h|2 +- arch/arm/include/asm/arch-omap3/omap3.h | 20 + arch/arm/include/asm/arch-omap3/sys_proto.h | 10 +- arch/arm/include/asm/arch-omap4/sys_proto.h |2 +- arch/arm/include/asm/arch-s5pc1xx/sys_proto.h|3 - arch/arm/include/asm/arch-tegra2/gpio.h | 250 ++- arch/arm/include/asm/armv7.h | 67 +++ arch/arm/include/asm/global_data.h |2 +- arch/arm/include/asm/gpio.h | 38 ++ arch/arm/include/asm/pl310.h | 73 +++
Re: [U-Boot] [PATCH] [v2] video: Add SHARP LQ084S3LG01 LCD support on P1022DS
On Thu, 26 May 2011 09:02:17 -0500 Timur Tabi ti...@freescale.com wrote: The SHARP LQ084S3LG01 is a TFT LCD used on the P1022DS (revision C) board. This device only supports 800x600 resolution, so if that resolution is selected, assume that this is the device. The device is attached to the LVDS port on the P1022DS board. The existing 800x600 entry (for the PDM360NG board) is actually 800x480, so we fix that. To support two different 800x resolutions, the Y-resolution is now passed to fsl_diu_init() and both values are used to pick the proper fb_videomode structure. The data for the 800x600 video mode is originally from Jiang Yutang. Signed-off-by: Timur Tabi ti...@freescale.com Signed-off-by: Jiang Yutang b14...@freescale.com --- arch/powerpc/cpu/mpc512x/diu.c|2 +- board/freescale/mpc8610hpcd/mpc8610hpcd_diu.c |2 +- board/freescale/p1022ds/diu.c |2 +- drivers/video/fsl_diu_fb.c| 51 +--- include/fsl_diu_fb.h |2 +- 5 files changed, 40 insertions(+), 19 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] video: update Makefile to include OMAP3 DSS driver
On Mon, 4 Jul 2011 23:51:27 +0200 Anatolij Gustschin ag...@denx.de wrote: From: Jason Kridner jkrid...@beagleboard.org Adding the OMAP3 DSS video driver to the Makefile. The patch applied to u-boot-ti didn't include this for some reason. Signed-off-by: Jason Kridner jkrid...@beagleboard.org Signed-off-by: Anatolij Gustschin ag...@denx.de --- replaces patch video: DSS makefile update to - drop unconditional include of videomode.o since it is wrong - sort in alphabetical order - fix the commit message drivers/video/Makefile |1 + 1 files changed, 1 insertions(+), 0 deletions(-) applied to u-boot-video/master. Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-video/master
Hello Wolfgang, The following changes since commit 79642098a8345e2506ab0ff02e8c7ac4da405d0c: Add support for Network Space v2 and parents (2011-07-04 10:55:28 +0200) are available in the git repository at: git://git.denx.de/u-boot-video.git master Anatolij Gustschin (1): video: mb862xx: support Coral-PA controller Jason Kridner (1): video: update Makefile to include OMAP3 DSS driver Matthias Weisser (1): video: Use memset instead of loop Syed Mohammed Khasim (1): OMAP3: Add DSS driver for OMAP3 Timur Tabi (1): video: Add SHARP LQ084S3LG01 LCD support on P1022DS arch/arm/include/asm/arch-omap3/dss.h | 173 + arch/powerpc/cpu/mpc512x/diu.c|2 +- board/freescale/mpc8610hpcd/mpc8610hpcd_diu.c |2 +- board/freescale/p1022ds/diu.c |2 +- drivers/video/Makefile|1 + drivers/video/fsl_diu_fb.c| 51 +-- drivers/video/mb862xx.c | 32 - drivers/video/mb86r0xgdc.c|3 +- drivers/video/omap3_dss.c | 130 +++ include/fsl_diu_fb.h |2 +- 10 files changed, 372 insertions(+), 26 deletions(-) create mode 100644 arch/arm/include/asm/arch-omap3/dss.h create mode 100644 drivers/video/omap3_dss.c Please pull. Thanks! Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request u-boot-blackfin.git (post branch)
On Sunday, July 03, 2011 18:30:05 Wolfgang Denk wrote: Mike Frysinger wrote: i'm not ignoring any rules. you said you dont want dumps of patches that havent been changed and lack pointing back to previous sets. fine. http://www.denx.de/wiki/view/U-Boot/Patches#Sending_updated_patch_versions which is irrelevant like i already said multiple times -- these patches arent updated yet you still refuse to take the pull requests and provide no reason as to why. you only say that i'm wasting your time with no backing logic and no indication as to how to move forward. i cant go back in time and unsend the patches that have already hit the list. Unsend patches? I suggest you take a time-out of a few days, and then re-read this thread. If you still don't understand, then please ask somebody else to explain it to you. you seem to be ignoring the points i'm making -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 1/2] net/eth.c: make eth_get_dev_by_name(NULL) safe
On Monday, July 04, 2011 06:29:51 helmut.rai...@hale.at wrote: eth_get_dev_by_name() is not safe to use for devname being NULL as it uses strcmp. This patch makes it return NULL if devname NULL is passed. i'm not sure about this. passing NULL is wrong, and the caller should catch that shouldnt it ? -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] Pull request u-boot-blackfin.git (post branch)
Dear Mike Frysinger, In message 201107042125.54555.vap...@gentoo.org you wrote: http://www.denx.de/wiki/view/U-Boot/Patches#Sending_updated_patch_versions which is irrelevant like i already said multiple times -- these patches arent updated So there is zero reason for resending. you seem to be ignoring the points i'm making Wrong, twice. First, you are not making any points. You are just repeating the same rogation. Second, I'm on the verge of ignoring you. 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 was playing poker the other night... with Tarot cards. I got a full house and 4 people died. - Steven Wright ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] arm: add __ilog2 function
Hi Rob,
On Tuesday 28 June 2011 09:09 PM, Rob Herring wrote:
From: Rob Herringrob.herr...@calxeda.com
Add __ilog2 function for ARM. Needed for ahci.c
Signed-off-by: Rob Herringrob.herr...@calxeda.com
Cc: Albert ARIBAUDalbert.arib...@free.fr
---
arch/arm/include/asm/bitops.h |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/bitops.h b/arch/arm/include/asm/bitops.h
index 270f163..0420182 100644
--- a/arch/arm/include/asm/bitops.h
+++ b/arch/arm/include/asm/bitops.h
@@ -106,6 +106,15 @@ static inline int test_bit(int nr, const void * addr)
return ((unsigned char *) addr)[nr 3] (1U (nr 7));
}
+extern __inline__ int __ilog2(unsigned int x)
+{
+ int ret;
+
+ asm(clz\t%0, %1 : =r (ret) : r (x));
I tried doing the same sometime back for the same need. I had to
abandon it because CLZ seems to be added only in ARMv5. And at least
one ARMv7 SoC uses -march=armv4 while building.
best regards,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] Blackfin: dont reset SWRST on newer bf526 parts
The bug in the BF526 rom when doing a software reset exists only in older silicon versions, so don't clear SWRST on newer parts. Signed-off-by: Mike Frysinger vap...@gentoo.org --- v2 - skip 0.1 silicon as well since it seems to work arch/blackfin/cpu/reset.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/arch/blackfin/cpu/reset.c b/arch/blackfin/cpu/reset.c index e23dcc7..ff39035 100644 --- a/arch/blackfin/cpu/reset.c +++ b/arch/blackfin/cpu/reset.c @@ -51,7 +51,9 @@ static void bfin_reset(void) /* The BF526 ROM will crash during reset */ #if defined(__ADSPBF522__) || defined(__ADSPBF524__) || defined(__ADSPBF526__) - bfin_read_SWRST(); + /* Seems to be fixed with newer parts though ... */ + if (__SILICON_REVISION__ 1 bfin_revid() 1) + bfin_read_SWRST(); #endif /* Wait for the SWRST write to complete. Cannot rely on SSYNC -- 1.7.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 19/21] Blackfin: serial: move early debug strings into .rodata section
Rewrite the assembly serial_early_puts() helper to place the strings in the .rodata section rather than embedding them directly in the .text section. Using .text is a little simpler, but it doesn't let people execute out of internal L1 sram (since core reads don't work on those regions). Signed-off-by: Mike Frysinger vap...@gentoo.org --- arch/blackfin/cpu/serial.h | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/blackfin/cpu/serial.h b/arch/blackfin/cpu/serial.h index f649e40..8a076dd 100644 --- a/arch/blackfin/cpu/serial.h +++ b/arch/blackfin/cpu/serial.h @@ -288,16 +288,16 @@ static inline void serial_early_puts(const char *s) */ #ifdef CONFIG_DEBUG_EARLY_SERIAL # define serial_early_puts(str) \ - call _get_pc; \ - jump 1f; \ + .section .rodata; \ + 7: \ .ascii Early:; \ .ascii __FILE__; \ .ascii : ; \ .ascii str; \ .asciz \n; \ - .align 4; \ -1: \ - R0 += 2; \ + .previous; \ + R0.L = 7b; \ + R0.H = 7b; \ call _serial_puts; #else # define serial_early_puts(str) -- 1.7.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 20/21] Blackfin: switch to common display_options()
Use common code to output the version string rather than doing it
ourselves.
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
arch/blackfin/lib/board.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/blackfin/lib/board.c b/arch/blackfin/lib/board.c
index e00050c..14ad3e8 100644
--- a/arch/blackfin/lib/board.c
+++ b/arch/blackfin/lib/board.c
@@ -53,7 +53,7 @@ static inline void serial_early_puts(const char *s)
static int display_banner(void)
{
- printf(\n\n%s\n\n, version_string);
+ display_options();
printf(CPU: ADSP %s
(Detected Rev: 0.%d)
(%s boot)\n,
--
1.7.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 21/21] Blackfin: jtag-console: fix timer usage
Reported-by: Graeme Russ graeme.r...@gmail.com
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
arch/blackfin/cpu/jtag-console.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/blackfin/cpu/jtag-console.c b/arch/blackfin/cpu/jtag-console.c
index e0f2975..a77358a 100644
--- a/arch/blackfin/cpu/jtag-console.c
+++ b/arch/blackfin/cpu/jtag-console.c
@@ -48,11 +48,11 @@ static inline uint32_t bfin_read_emudat(void)
static bool jtag_write_emudat(uint32_t emudat)
{
static bool overflowed = false;
- ulong timeout = get_timer(0) + CONFIG_JTAG_CONSOLE_TIMEOUT;
+ ulong timeout = get_timer(0);
while (bfin_read_DBGSTAT() 0x1) {
if (overflowed)
return overflowed;
- if (timeout get_timer(0))
+ if (get_timer(timeout) CONFIG_JTAG_CONSOLE_TIMEOUT)
overflowed = true;
}
overflowed = false;
--
1.7.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
