Re: [U-Boot] [PATCH][v2] powerpc/T1040EMU: Add T1040 emulator support
Hi,
Dependency of below patch marked under ---
[U-Boot] powerpc/t1040qds: Add DDR Raw Timing support
http://patchwork.ozlabs.org/patch/286112/
no longer holds true as thi patch has been deferred.
But below emulator patch will work as it is with SPD method.
No changes required.
Regards
Priyanka
-Original Message-
From: Jain Priyanka-B32167
Sent: Monday, October 28, 2013 3:53 PM
To: u-boot@lists.denx.de; w...@denx.de
Cc: sun york-R58495; Jain Priyanka-B32167; Aggrwal Poonam-B10812;
Kushwaha Prabhakar-B32579
Subject: [PATCH][v2] powerpc/T1040EMU: Add T1040 emulator support
Add emulator support for T1040. Emulator has limited peripherals and
interfaces.
Difference between T1040QDS and emulator includes:
-ECC for DDR is disabled due to procedure to load images -Depends on raw
timing for DDR initialization -No board FPGA (Qixis) -No PCI -No SPI -No
flash support
Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com
Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
Signed-off-by: Priyanka Jain priyanka.j...@freescale.com
---
Changes for v2: Incorporated Wolfgang Denk's review comments
Based on u-boot-mpc85xx/next branch.
This patch depends upon following patches:
1)[U-Boot] powerpc/t1040qds: Add DDR Raw Timing support
http://patchwork.ozlabs.org/patch/286112/
2)[U-Boot] powerpc/t1040qds: Correct Maintainer name in boards.cfg
http://patchwork.ozlabs.org/patch/286113/
board/freescale/t1040qds/Makefile |3 +-
board/freescale/t1040qds/ddr.c |3 +
board/freescale/t1040qds/ddr.h | 13 ++
board/freescale/t1040qds/t1040emu.c | 75
board/freescale/t1040qds/tlb.c |4 +
boards.cfg |1 +
include/configs/T1040EMU.h | 344
+++
7 files changed, 442 insertions(+), 1 deletions(-) create mode 100644
board/freescale/t1040qds/t1040emu.c
create mode 100644 include/configs/T1040EMU.h
diff --git a/board/freescale/t1040qds/Makefile
b/board/freescale/t1040qds/Makefile
index 8f0057b..4bd7103 100644
--- a/board/freescale/t1040qds/Makefile
+++ b/board/freescale/t1040qds/Makefile
@@ -8,7 +8,8 @@ include $(TOPDIR)/config.mk
LIB = $(obj)lib$(BOARD).o
-COBJS-y += $(BOARD).o
+COBJS-$(CONFIG_T1040QDS) += t1040qds.o
+COBJS-$(CONFIG_T1040EMU) += t1040emu.o
COBJS-y += ddr.o
COBJS-$(CONFIG_PCI) += pci.o
COBJS-y += law.o
diff --git a/board/freescale/t1040qds/ddr.c
b/board/freescale/t1040qds/ddr.c index 16ab829..d46021b 100644
--- a/board/freescale/t1040qds/ddr.c
+++ b/board/freescale/t1040qds/ddr.c
@@ -123,6 +123,9 @@ phys_size_t initdram(int board_type)
puts(Initializingusing SPD\n);
dram_size = fsl_ddr_sdram();
+#ifdef CONFIG_T1040EMU
+ dram_size = CONFIG_SYS_SDRAM_SIZE * 1024 * 1024; #endif
dram_size = setup_ddr_tlbs(dram_size / 0x10);
dram_size *= 0x10;
diff --git a/board/freescale/t1040qds/ddr.h
b/board/freescale/t1040qds/ddr.h index 4a4f76a..5e0a078 100644
--- a/board/freescale/t1040qds/ddr.h
+++ b/board/freescale/t1040qds/ddr.h
@@ -54,6 +54,18 @@ struct board_specific_parameters {
* for each n_ranks group.
*/
+#ifdef CONFIG_T1040EMU
+static const struct board_specific_parameters udimm0[] = {
+ /*
+ * memory controller 0
+ * num| hi| rank| clk| wrlvl | wrlvl | wrlvl | cpo
|wrdata|2T
+ * ranks| mhz| GB |adjst| start | ctl2| ctl3 | |delay
|
+ */
+ {2, 2140, 4, 4, 8, 0x0, 0x0, 0xff,2, 0},
+ {1, 2140, 4, 4, 8, 0x0, 0x0, 0xff,2, 0},
+ {}
+};
+#else
static const struct board_specific_parameters udimm0[] = {
/*
* memory controller 0
@@ -72,6 +84,7 @@ static const struct board_specific_parameters udimm0[]
= {
{1, 2140, 0, 4, 8, 0x090a0b0c, 0x0e0f100b, 0xff,2, 0},
{}
};
+#endif
static const struct board_specific_parameters *udimms[] = {
udimm0,
diff --git a/board/freescale/t1040qds/t1040emu.c
b/board/freescale/t1040qds/t1040emu.c
new file mode 100644
index 000..e9362d6
--- /dev/null
+++ b/board/freescale/t1040qds/t1040emu.c
@@ -0,0 +1,75 @@
+/*
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include common.h
+#include command.h
+#include i2c.h
+#include netdev.h
+#include linux/compiler.h
+#include asm/mmu.h
+#include asm/processor.h
+#include asm/cache.h
+#include asm/immap_85xx.h
+#include asm/fsl_law.h
+#include asm/fsl_serdes.h
+#include asm/fsl_portals.h
+#include asm/fsl_liodn.h
+#include fm_eth.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+int checkboard(void)
+{
+ struct cpu_type *cpu = gd-arch.cpu;
+ printf(Board: %sEMU\n, cpu-name);
+ return 0;
+}
+
+int board_early_init_r(void)
+{
+ const unsigned int flashbase = CONFIG_SYS_FLASH_BASE;
+ const u8 flash_esel =
Re: [U-Boot] [PATCH] powerpc/t1040qds: Add DDR Raw Timing support
Ok, I will drop this patch and maintain it locally. Regards Priyanka -Original Message- From: sun york-R58495 Sent: Thursday, October 31, 2013 10:50 AM To: Jain Priyanka-B32167 Cc: sun york-R58495; u-boot@lists.denx.de; Aggrwal Poonam-B10812 Subject: Re: [PATCH] powerpc/t1040qds: Add DDR Raw Timing support On Oct 30, 2013, at 9:55 PM, Jain Priyanka-B32167 wrote: -Original Message- From: sun york-R58495 Sent: Wednesday, October 30, 2013 10:14 PM To: Jain Priyanka-B32167; u-boot@lists.denx.de Cc: Aggrwal Poonam-B10812 Subject: Re: [PATCH] powerpc/t1040qds: Add DDR Raw Timing support On 10/25/2013 02:49 AM, Priyanka Jain wrote: T1040QDS-D3 has dual-rank DDR: Micron, MT18KSF51272AZ-1G6 (4GB, x72, CL=10). Add Raw Timing structure for this DDR. Typically SPD method is used for getting DDR parameter and calculating values for various DDR controller registers. But somentimes it may happen that SPD present on DDR may get accidently erased or is not working properly during initial bring-up. In that circumnstance, DDR raw timing structure can be use as fallback option for getting DDR parameters. Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com Signed-off-by: Priyanka Jain priyanka.j...@freescale.com --- I don't think it is appropriate to use raw timing for this application. This board use DIMMs, not soldered DDR chips. In normal cases, this piece of code is not used. It is only useful if you have a DIMM without a valid SPD. You could get another DIMM. I am not saying this patch is wrong, it is just useless for general public. York [Jain Priyanka-B32167] You are right that in case of DIMM type of memories, raw timing may not be required. But there are certain scenarios in which keeping raw timing is useful like 1)During initial bring-up, there is a possibility that I2C bus may be broken, In that case boot-loader has to rely on the fallback option of raw timing. 2)Also raw timings are used in emulator to test t1040. So, we prefer to keep raw timing as fallback option. It is a debug technique, not an implementation. You can use fixed register setting as well for debugging. But it doesn't mean you have to keep it in the final code. After you cleaning up the code, all fixed code should be removed, including the raw timing parameters you are using. Emulator target also has I2C EEPROM modeled. You should use SPD as well. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [mips] malta configuration works in qemu-1.5 does not in qemu-1.6
Hello, master is: 15c5cdf from Fri Nov 8 15:25:29 2013 -0500 u-boot-2013.10 Working in qemu-1.5.3. Does not work in qemu-1.6.1. The command prompt is not displayed, 100% cpu consumption. --- $ qemu-system-mips -M malta -nographic -drive if=pflash,file=/tmp/flash -m 256 U-Boot 2013.10-00249-g15c5cdf (Nov 10 2013 - 18:00:48) Board: MIPS Malta CoreLV (Qemu) DRAM: 256 MiB --- Any idea what the difference? any fix pending somewhere? Regards, Alon Bar-Lev ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] usb: dfu: make nand upload working
Hi Heiko, On 11/11/2013 02:46 PM, Heiko Schocher wrote: Hello Lukasz, Am 08.11.2013 16:41, schrieb Lukasz Majewski: Hi Bo, Nowhere pass a value to len, which always 0, make no transfer which cause uploading failed. This patch make nand upload working. However it needs enough malloc buffer to store read data, that means the buffer at least equal to the upload partition size, or else it doesn't work. Signed-off-by: Bo Shenvoice.s...@atmel.com I would kindly ask some users of NAND part of the DFU (Tom, Heiko) to test if this change doesn't break anything. I sent a tested-by for this patch, see: http://lists.denx.de/pipermail/u-boot/2013-November/166552.html without this patch nand upload didn;t worked on the rut board, with this patch it worked :-) Thanks for testing it. bye, Heiko Best Regards, Bo Shen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-boot] not support parsing Android's boot.img format ?
Hi tiger...@viatech.com.cn, On Mon, 11 Nov 2013 13:12:04 +0800, tiger...@viatech.com.cn wrote: Hi, experts: It seems current uboot does not support parse boot.img which saved in NAND chip. Boot.img contains : kernel.img and ramdisk.img [...] Nand boot cmd usually should retrieve kernel.img from boot.img. Not sure what the purpose of your message is. Are you asking if U-Boot is able to parse android's img forat, as your message's subject implies? But in the body you seem to know it does not. Are you asking for someone to provide a patch? There is no indication of such a request in your message, and besides, I don't think this U-Boot tehcnical list would be the place to make such requests for volunteer work. Are you considering whether this change is valuable or not, in order to determine if you should submit a patch? If so, the I suggest that you don't ask questions first, since anyway you'll have to post the patch eventually, so just post it directly, and list any explanations, questions, etc below the '---' line. Best wishes, Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-boot] not support parsing Android's boot.img format ?
Hi, Albert: Sorry for making trouble for you! I just wants to make sure uboot not support this feature now. Maybe i will submit a patch in the future. Best wishes, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [mips] malta configuration works in qemu-1.5 does not in qemu-1.6
2013/11/10 Alon Bar-Lev alon.bar...@gmail.com: Hello, master is: 15c5cdf from Fri Nov 8 15:25:29 2013 -0500 u-boot-2013.10 Working in qemu-1.5.3. Does not work in qemu-1.6.1. The command prompt is not displayed, 100% cpu consumption. --- $ qemu-system-mips -M malta -nographic -drive if=pflash,file=/tmp/flash -m 256 U-Boot 2013.10-00249-g15c5cdf (Nov 10 2013 - 18:00:48) Board: MIPS Malta CoreLV (Qemu) DRAM: 256 MiB --- Any idea what the difference? any fix pending somewhere? it is obviously am upstream change in qemu, which requires a fix in u-boot. Paul or Gabor, do you have an idea? -- - Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 05/18] pcnet: enable the NOUFLO feature
On 10/11/13 20:02, Marek Vasut wrote: Dear Paul Burton, On relatively slow boards (such as the MIPS Malta with an FPGA core card) it can be extremely common for transmits to underflow - to the point where it appears they simply do not work at all. Setting the NOUFLO bit causes the ethernet controller to not begin transmission on the wire until a transmit start point is reached. Setting that transmit start point to the full packet will cause the controller to only transmit the packet once it has buffered it entirely thus preventing any transmit underflows from occuring and allowing the controller to function on slower boards. Signed-off-by: Paul Burton paul.bur...@imgtec.com --- Changes in v2: - rebase atop master --- drivers/net/pcnet.c | 15 +++ 1 file changed, 15 insertions(+) diff --git a/drivers/net/pcnet.c b/drivers/net/pcnet.c index 7b87660..5b248be 100644 --- a/drivers/net/pcnet.c +++ b/drivers/net/pcnet.c @@ -312,6 +312,21 @@ static int pcnet_init(struct eth_device *dev, bd_t *bis) pcnet_write_bcr(dev, 32, val); /* +* Enable NOUFLO on supported controllers, with the transmit +* start point set to the full packet. This will cause entire +* packets to be buffered by the ethernet controller before +* transmission, eliminating underflows which are common on +* slower devices. Controllers which do not support NOUFLO will +* simply be left with a larger transmit FIFO threshold. +*/ + val = pcnet_read_bcr(dev, 18); + val |= 1 11; + pcnet_write_bcr(dev, 18, val); + val = pcnet_read_csr(dev, 80); + val |= 0x3 10; + pcnet_write_csr(dev, 80, val); Would be nice to fix this so we don't have so many magic numbers there. Best regards, Marek Vasut I agree, the whole file is full of them. I'll submit a cleanup patch later if nobody else beats me to it. Thanks, Paul ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 07/18] qemu-malta: rename to just malta
On 10/11/13 20:05, Marek Vasut wrote: Dear Paul Burton, This is in preparation for adapting this board to function correctly on a physical MIPS Malta board. The board is moved into an imgtec vendor directory at the same time in order to ready us for any other boards supported by Imagination in the future. Signed-off-by: Paul Burton paul.bur...@imgtec.com Will the board still work in QEMU? Best regards, Marek Vasut Yes. It doesn't work in current QEMU master either with or without this series, but it works in older QEMU releases (v1.5.3 for example). Thanks, Paul ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [mips] malta configuration works in qemu-1.5 does not in qemu-1.6
2013.11.11. 10:52 keltezéssel, Daniel Schwierzeck írta: 2013/11/10 Alon Bar-Lev alon.bar...@gmail.com: Hello, master is: 15c5cdf from Fri Nov 8 15:25:29 2013 -0500 u-boot-2013.10 Working in qemu-1.5.3. Does not work in qemu-1.6.1. The command prompt is not displayed, 100% cpu consumption. --- $ qemu-system-mips -M malta -nographic -drive if=pflash,file=/tmp/flash -m 256 U-Boot 2013.10-00249-g15c5cdf (Nov 10 2013 - 18:00:48) Board: MIPS Malta CoreLV (Qemu) DRAM: 256 MiB --- Any idea what the difference? any fix pending somewhere? it is obviously am upstream change in qemu, which requires a fix in u-boot. Paul or Gabor, do you have an idea? It is broken since the following change in qemu: commit a427338b222b43197c2776cbc996936df0302f51 Author: Paul Burton paul.bur...@imgtec.com Date: Fri Jun 14 08:30:44 2013 +0100 mips_malta: correct reading MIPS revision at 0x1fc00010 Rather than modifying the BIOS code at its original location, copy it for the 0x1fc0 region modify the copy. This means the original ROM code is correctly readable at 0x1e10 whilst the MIPS revision is readable at 0x1fc00010. Additionally the code previously operated on target memory which would later be overwritten by the BIOS image upon CPU reset if the -bios argument was used to specify the BIOS image. This led to the written MIPS revision being lost. Copying using rom_copy when -bios is used fixes this issue. Signed-off-by: Paul Burton paul.bur...@imgtec.com Signed-off-by: Leon Alrae leon.al...@imgtec.com Signed-off-by: Aurelien Jarno aurel...@aurel32.net Due to that change, we are getting a CPU exception while probing the flash at the 0x1fc0 address. Changing the MALTA_FLASH_BASE constant to 0x1e00 in 'arch/mips/include/asm/malta.h' fixes the problem. I will send a patch for that. -Gabor ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 08/18] malta: setup super I/O UARTs
Grepping all I found was board/mpl/common/isa.c which seems to do something similar. However calling this a driver is quite generous - all it does it write some board-specific values to some registers. So there's really not much to be shared. Thanks, Paul On 10/11/13 20:06, Marek Vasut wrote: Dear Paul Burton, On a real Malta the Super I/O needs to be configured before we are able to access the UARTs. This patch performs that configuration, setting up the UARTs in the same way that YAMON would. [...] --- /dev/null +++ b/board/imgtec/malta/superio.c Do we not already have some kind of a superIO controller driver in U-Boot ? Just wondering, I seem to remember seeing a few. Is this driver re-usable by other boards too maybe? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 09/18] malta: support for coreFPGA6 boards
On 10/11/13 20:07, Marek Vasut wrote: Dear Paul Burton, This patch adds support for running on Malta boards using coreFPGA6 core cards, including support for the msc01 system controller used with them. The system controller is detected at runtime allowing one U-boot binary to run on a Malta with either. Due to the PCI I/O base differing between Maltas using gt64120 msc01 system controllers, the UART setup is modified slightly. A second UART is added so that there is one pointing at the correct address for each system controller. The Malta board then defines its own default_serial_console function to select the correct one at runtime. The incorrect UART will simply not function. Tested on: - A coreFPGA6 Malta running interAptiv and proAptiv bitstreams, both with and without an L2 cache. - QEMU. Signed-off-by: Paul Burton paul.bur...@imgtec.com --- Changes in v3: - rebase atop master - remove commit message note about not working in QEMU, this does work in older QEMU versions as noted by Gabor Juhos Changes in v2: - rebased after malta moved to board/imgtec/malta - removed unused status variable from msc01_config_access --- arch/mips/include/asm/malta.h | 35 ++-- board/imgtec/malta/lowlevel_init.S | 164 - board/imgtec/malta/malta.c | 126 ++-- drivers/pci/Makefile | 1 + drivers/pci/pci_msc01.c| 125 include/configs/malta.h| 4 +- include/msc01.h| 135 ++ include/pci_ids.h | 3 + include/pci_msc01.h| 17 9 files changed, 594 insertions(+), 16 deletions(-) create mode 100644 drivers/pci/pci_msc01.c create mode 100644 include/msc01.h create mode 100644 include/pci_msc01.h diff --git a/arch/mips/include/asm/malta.h b/arch/mips/include/asm/malta.h index d4d44a2..0b50a66 100644 --- a/arch/mips/include/asm/malta.h +++ b/arch/mips/include/asm/malta.h You are missing license in some files. Best regards, Marek Vasut Which files? The only files this patch adds are: drivers/pci/pci_msc01.c include/msc01.h include/pci_msc01.h ...and all 3 of them contain GPL-2.0+ SPDX tags. Thanks, Paul ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [mips] malta configuration works in qemu-1.5 does not in qemu-1.6
On Mon, Nov 11, 2013 at 12:25 PM, Gabor Juhos juh...@openwrt.org wrote: 2013.11.11. 10:52 keltezéssel, Daniel Schwierzeck írta: 2013/11/10 Alon Bar-Lev alon.bar...@gmail.com: Hello, master is: 15c5cdf from Fri Nov 8 15:25:29 2013 -0500 u-boot-2013.10 Working in qemu-1.5.3. Does not work in qemu-1.6.1. The command prompt is not displayed, 100% cpu consumption. --- $ qemu-system-mips -M malta -nographic -drive if=pflash,file=/tmp/flash -m 256 U-Boot 2013.10-00249-g15c5cdf (Nov 10 2013 - 18:00:48) Board: MIPS Malta CoreLV (Qemu) DRAM: 256 MiB --- Any idea what the difference? any fix pending somewhere? it is obviously am upstream change in qemu, which requires a fix in u-boot. Paul or Gabor, do you have an idea? It is broken since the following change in qemu: commit a427338b222b43197c2776cbc996936df0302f51 Author: Paul Burton paul.bur...@imgtec.com Date: Fri Jun 14 08:30:44 2013 +0100 mips_malta: correct reading MIPS revision at 0x1fc00010 Rather than modifying the BIOS code at its original location, copy it for the 0x1fc0 region modify the copy. This means the original ROM code is correctly readable at 0x1e10 whilst the MIPS revision is readable at 0x1fc00010. Additionally the code previously operated on target memory which would later be overwritten by the BIOS image upon CPU reset if the -bios argument was used to specify the BIOS image. This led to the written MIPS revision being lost. Copying using rom_copy when -bios is used fixes this issue. Signed-off-by: Paul Burton paul.bur...@imgtec.com Signed-off-by: Leon Alrae leon.al...@imgtec.com Signed-off-by: Aurelien Jarno aurel...@aurel32.net Due to that change, we are getting a CPU exception while probing the flash at the 0x1fc0 address. Changing the MALTA_FLASH_BASE constant to 0x1e00 in 'arch/mips/include/asm/malta.h' fixes the problem. I will send a patch for that. -Gabor Thanks for quick response! I confirm this works in qemu-1.5 and qemu-1.6. Regards, Alon Bar-Lev. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 10/18] malta: display U-boot on the LCD screen
On 10/11/13 20:08, Marek Vasut wrote:
Dear Paul Burton,
Displaying a message on the LCD screen is a simple yet effective way to
show the user that the board has booted successfully.
Signed-off-by: Paul Burton paul.bur...@imgtec.com
---
Changes in v3:
- rebase atop master
Changes in v2:
- rebased after malta moved to board/imgtec/malta
---
arch/mips/include/asm/malta.h | 10 ++
board/imgtec/malta/malta.c| 19 +++
2 files changed, 29 insertions(+)
diff --git a/arch/mips/include/asm/malta.h b/arch/mips/include/asm/malta.h
index 0b50a66..d8ec57c 100644
--- a/arch/mips/include/asm/malta.h
+++ b/arch/mips/include/asm/malta.h
@@ -32,6 +32,16 @@
#define MALTA_MSC01_PCIIO_MAP 0x
#define MALTA_MSC01_UART0_BASE(MALTA_MSC01_PCIIO_BASE + 0x3f8)
+#define MALTA_ASCIIWORD0x1f000410
+#define MALTA_ASCIIPOS00x1f000418
+#define MALTA_ASCIIPOS10x1f000420
+#define MALTA_ASCIIPOS20x1f000428
+#define MALTA_ASCIIPOS30x1f000430
+#define MALTA_ASCIIPOS40x1f000438
+#define MALTA_ASCIIPOS50x1f000440
+#define MALTA_ASCIIPOS60x1f000448
+#define MALTA_ASCIIPOS70x1f000450
+
#define MALTA_RESET_BASE 0x1f000500
#define GORESET 0x42
diff --git a/board/imgtec/malta/malta.c b/board/imgtec/malta/malta.c
index 2af0067..119546a 100644
--- a/board/imgtec/malta/malta.c
+++ b/board/imgtec/malta/malta.c
@@ -29,6 +29,24 @@ enum sys_con {
SYSCON_MSC01,
};
+static void malta_lcd_puts(const char *str)
+{
+ int i;
+ void *reg = (void *)CKSEG1ADDR(MALTA_ASCIIPOS0);
+
+ /* print up to 8 characters of the string */
+ for (i = 0; i min(strlen(str), 8); i++) {
+ __raw_writel(str[i], reg);
+ reg += MALTA_ASCIIPOS1 - MALTA_ASCIIPOS0;
+ }
+
+ /* fill the rest of the display with spaces */
+ for (; i 8; i++) {
+ __raw_writel(' ', reg);
+ reg += MALTA_ASCIIPOS1 - MALTA_ASCIIPOS0;
+ }
+}
+
static enum core_card malta_core_card(void)
{
u32 corid, rev;
@@ -71,6 +89,7 @@ int checkboard(void)
{
enum core_card core;
+ malta_lcd_puts(U-boot);
puts(Board: MIPS Malta);
core = malta_core_card();
Can this not be implemented as a regular framebuffer console maybe?
Best regards,
Marek Vasut
We're talking about an 8 character segmented LCD display here - it's not
something you can draw (non-ASCII) graphics on, nor something you want
to be interacting with even if you hooked up some input.
Thanks,
Paul
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 09/18] malta: support for coreFPGA6 boards
2013/11/11 Paul Burton paul.bur...@imgtec.com: On 10/11/13 20:07, Marek Vasut wrote: Dear Paul Burton, This patch adds support for running on Malta boards using coreFPGA6 core cards, including support for the msc01 system controller used with them. The system controller is detected at runtime allowing one U-boot binary to run on a Malta with either. Due to the PCI I/O base differing between Maltas using gt64120 msc01 system controllers, the UART setup is modified slightly. A second UART is added so that there is one pointing at the correct address for each system controller. The Malta board then defines its own default_serial_console function to select the correct one at runtime. The incorrect UART will simply not function. Tested on: - A coreFPGA6 Malta running interAptiv and proAptiv bitstreams, both with and without an L2 cache. - QEMU. Signed-off-by: Paul Burton paul.bur...@imgtec.com --- Changes in v3: - rebase atop master - remove commit message note about not working in QEMU, this does work in older QEMU versions as noted by Gabor Juhos Changes in v2: - rebased after malta moved to board/imgtec/malta - removed unused status variable from msc01_config_access --- arch/mips/include/asm/malta.h | 35 ++-- board/imgtec/malta/lowlevel_init.S | 164 - board/imgtec/malta/malta.c | 126 ++-- drivers/pci/Makefile | 1 + drivers/pci/pci_msc01.c| 125 include/configs/malta.h| 4 +- include/msc01.h| 135 ++ include/pci_ids.h | 3 + include/pci_msc01.h| 17 9 files changed, 594 insertions(+), 16 deletions(-) create mode 100644 drivers/pci/pci_msc01.c create mode 100644 include/msc01.h create mode 100644 include/pci_msc01.h diff --git a/arch/mips/include/asm/malta.h b/arch/mips/include/asm/malta.h index d4d44a2..0b50a66 100644 --- a/arch/mips/include/asm/malta.h +++ b/arch/mips/include/asm/malta.h You are missing license in some files. Best regards, Marek Vasut Which files? The only files this patch adds are: drivers/pci/pci_msc01.c include/msc01.h include/pci_msc01.h ...and all 3 of them contain GPL-2.0+ SPDX tags. Thanks, Paul only arch/mips/include/asm/malta.h is missing the SPDX tag. Paul, could you send a patch? Maybe you want to add your copyright, because you modified parts of that file. -- - Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 16/18] malta: setup PIIX4 interrupt route
On 10/11/13 20:09, Marek Vasut wrote: Dear Paul Burton, Without setting up the PIRQ[A:D] interrupt routes, PCI interrupts will be left disabled. Linux does not set up this routing but relies upon it having been set up by the bootloader, reading back the IRQ lines which the PIRQ[A:D] signals have been routed to. Did you also submit a fix to Linux guys? Best regards, Marek Vasut No, I haven't. Although Linux is reliant upon these values having been programmed it's quite clear from reading its code that that depence is intentional. It explicitely reads the route setup by the bootloader rather than clobbering it, and to me that does make sense in this case. However the pcnet32 ethernet driver seems to be reliant upon the interrupt and doesn't handle the case of a PCI device with no assigned interrupt, so I'll send a patch to fail its probe in that case shortly. Thanks, Paul ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] malta: arch/mips/include/asm/malta.h SPDX license tag
This patch replaces the GPL-2.0 text with a GPL-2.0 SPDX-License-Identifier tag, and adds Imagination Technologies copyright following my recent changes. Signed-off-by: Paul Burton paul.bur...@imgtec.com --- arch/mips/include/asm/malta.h | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/arch/mips/include/asm/malta.h b/arch/mips/include/asm/malta.h index e141eb0..9b1100b 100644 --- a/arch/mips/include/asm/malta.h +++ b/arch/mips/include/asm/malta.h @@ -1,9 +1,8 @@ /* * Copyright (C) 2013 Gabor Juhos juh...@openwrt.org + * Copyright (C) 2013 Imagination Technologies * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License version 2 as published - * by the Free Software Foundation. + * SPDX-License-Identifier:GPL-2.0 */ #ifndef _MIPS_ASM_MALTA_H -- 1.8.4.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] arm: at91: support for the Calao USB-A9263 board (based on AT91SAM9263)
Dear Mateusz Kulikowski,
On 11/02/2013 12:19 AM, Mateusz Kulikowski wrote:
Add support for USB-A9263 board manufactured by Calao Systems
(http://www.calao-systems.com/).
Code is based on old U-Boot sources (2010.09) released by Calao and
existing AT92SAM9263-EK code.
Signed-off-by: Mateusz Kulikowski mateusz.kulikow...@gmail.com
---
board/calao/usb_a9263/Makefile| 34
board/calao/usb_a9263/usb_a9263.c | 167 +
boards.cfg| 1 +
include/configs/usb_a9263.h | 168
++
4 files changed, 370 insertions(+)
create mode 100644 board/calao/usb_a9263/Makefile
create mode 100644 board/calao/usb_a9263/usb_a9263.c
create mode 100644 include/configs/usb_a9263.h
diff --git a/board/calao/usb_a9263/Makefile b/board/calao/usb_a9263/Makefile
new file mode 100644
index 000..dc87684
--- /dev/null
+++ b/board/calao/usb_a9263/Makefile
@@ -0,0 +1,34 @@
+#
+# (C) Copyright 2003-2008
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# (C) Copyright 2008
+# Stelian Pop stel...@popies.net
+# Lead Tech Design www.leadtechdesign.com
+#
+# (C) Copyright 2013
+# Mateusz Kulikowski mateusz.kulikow...@gmail.com
+#
+# SPDX-License-Identifier: GPL-2.0+
+
+include $(TOPDIR)/config.mk
+
+LIB = $(obj)lib$(BOARD).o
+
+COBJS-y += usb_a9263.o
+
+SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS-y))
+SOBJS:= $(addprefix $(obj),$(SOBJS))
+
+$(LIB): $(obj).depend $(OBJS) $(SOBJS)
+ $(call cmd_link_o_target, $(OBJS) $(SOBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
please adopt all Makefiles to latest KBuild changes in u-boot/master.
diff --git a/board/calao/usb_a9263/usb_a9263.c
b/board/calao/usb_a9263/usb_a9263.c
new file mode 100644
index 000..bbc1e25
--- /dev/null
+++ b/board/calao/usb_a9263/usb_a9263.c
@@ -0,0 +1,167 @@
+/*
+ * (C) Copyright 2007-2013
+ * Stelian Pop stelian@leadtechdesign.com
+ * Lead Tech Design www.leadtechdesign.com
+ * Thomas Petazzoni, Free Electrons, thomas.petazz...@free-electrons.com
+ * Mateusz Kulikowski mateusz.kulikow...@gmail.com
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include common.h
+#include asm/arch/at91sam9_smc.h
+#include asm/arch/at91_common.h
+#include asm/arch/at91_pmc.h
+#include asm/arch/at91_rstc.h
+#include asm/arch/at91_matrix.h
+#include asm/arch/at91_pio.h
+#include asm/arch/clk.h
+#include asm/arch/gpio.h
+#include asm/arch/hardware.h
+#if defined(CONFIG_MACB)
I think we can include the headers unconditionally, or is there a problem?
+#include net.h
+#endif
+#include netdev.h
+#if defined(CONFIG_HAS_DATAFLASH)
+#include dataflash.h
+#endif
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#ifdef CONFIG_HAS_DATAFLASH
+AT91S_DATAFLASH_INFO dataflash_info[CONFIG_SYS_MAX_DATAFLASH_BANKS];
+
+struct dataflash_addr cs[CONFIG_SYS_MAX_DATAFLASH_BANKS] = {
+ {CONFIG_SYS_DATAFLASH_LOGIC_ADDR_CS0, 0}, /* Logical adress, CS */
+};
+
+/*define the area offsets*/
+dataflash_protect_t area_list[NB_DATAFLASH_AREA] = {
+ {0x, 0x1FFF, FLAG_PROTECT_SET, 0, Bootstrap},
+ {0x2000, 0x3FFF, FLAG_PROTECT_CLEAR, 0, Environment},
+ {0x4000, 0x, FLAG_PROTECT_CLEAR, 0, U-Boot},
+};
+#endif
+
+#ifdef CONFIG_CMD_NAND
+static void usb_a9263_nand_hw_init(void)
+{
+ unsigned long csa;
+ at91_smc_t *smc = (at91_smc_t *)ATMEL_BASE_SMC0;
+ at91_matrix_t *matrix = (at91_matrix_t *)ATMEL_BASE_MATRIX;
+ at91_pmc_t *pmc = (at91_pmc_t *)ATMEL_BASE_PMC;
+
+ /* Enable CS3 */
+ csa = readl(matrix-csa[0]) | AT91_MATRIX_CSA_EBI_CS3A;
+ writel(csa, matrix-csa[0]);
+
+ /* Configure SMC CS3 for NAND/SmartMedia */
+ writel(AT91_SMC_SETUP_NWE(1) | AT91_SMC_SETUP_NCS_WR(0) |
+AT91_SMC_SETUP_NRD(1) | AT91_SMC_SETUP_NCS_RD(0),
+smc-cs[3].setup);
+
+ writel(AT91_SMC_PULSE_NWE(3) | AT91_SMC_PULSE_NCS_WR(3) |
+AT91_SMC_PULSE_NRD(3) | AT91_SMC_PULSE_NCS_RD(3),
+smc-cs[3].pulse);
+
+ writel(AT91_SMC_CYCLE_NWE(5) | AT91_SMC_CYCLE_NRD(5),
+smc-cs[3].cycle);
+
+ writel(AT91_SMC_MODE_RM_NRD | AT91_SMC_MODE_WM_NWE |
+AT91_SMC_MODE_EXNW_DISABLE |
+AT91_SMC_MODE_DBW_8 |
+AT91_SMC_MODE_TDF_CYCLE(2), smc-cs[3].mode);
+
+ writel(1 ATMEL_ID_PIOA | 1 ATMEL_ID_PIOCDE, pmc-pcer);
+
+ /* Configure RDY/BSY */
+ at91_set_gpio_input(CONFIG_SYS_NAND_READY_PIN, 1);
Could you please use the generic GPIO API here? Is it Ok for you to not
mux the pullup for the ready pin?
+
+ /* Enable NandFlash */
+
Re: [U-Boot] [mips] malta configuration works in qemu-1.5 does not in qemu-1.6
On 11/11/13 10:25, Gabor Juhos wrote: 2013.11.11. 10:52 keltezéssel, Daniel Schwierzeck írta: 2013/11/10 Alon Bar-Lev alon.bar...@gmail.com: Hello, master is: 15c5cdf from Fri Nov 8 15:25:29 2013 -0500 u-boot-2013.10 Working in qemu-1.5.3. Does not work in qemu-1.6.1. The command prompt is not displayed, 100% cpu consumption. --- $ qemu-system-mips -M malta -nographic -drive if=pflash,file=/tmp/flash -m 256 U-Boot 2013.10-00249-g15c5cdf (Nov 10 2013 - 18:00:48) Board: MIPS Malta CoreLV (Qemu) DRAM: 256 MiB --- Any idea what the difference? any fix pending somewhere? it is obviously am upstream change in qemu, which requires a fix in u-boot. Paul or Gabor, do you have an idea? It is broken since the following change in qemu: commit a427338b222b43197c2776cbc996936df0302f51 Author: Paul Burton paul.bur...@imgtec.com Date: Fri Jun 14 08:30:44 2013 +0100 mips_malta: correct reading MIPS revision at 0x1fc00010 Rather than modifying the BIOS code at its original location, copy it for the 0x1fc0 region modify the copy. This means the original ROM code is correctly readable at 0x1e10 whilst the MIPS revision is readable at 0x1fc00010. Additionally the code previously operated on target memory which would later be overwritten by the BIOS image upon CPU reset if the -bios argument was used to specify the BIOS image. This led to the written MIPS revision being lost. Copying using rom_copy when -bios is used fixes this issue. Signed-off-by: Paul Burton paul.bur...@imgtec.com Signed-off-by: Leon Alrae leon.al...@imgtec.com Signed-off-by: Aurelien Jarno aurel...@aurel32.net Due to that change, we are getting a CPU exception while probing the flash at the 0x1fc0 address. Changing the MALTA_FLASH_BASE constant to 0x1e00 in 'arch/mips/include/asm/malta.h' fixes the problem. I will send a patch for that. -Gabor Aha, thanks for tracking that down. I guess if flash commands need to work at 0x1fc0 then my QEMU patch fixed one bug but causes another... I'll try to find the time to fix that in QEMU soon. Thanks, Paul ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] A question about unconfigured pads check in omap24xx_i2c
On 11/08/2013 11:26 PM, Lubomir Popov wrote:
Hi Nikita,
On 11/06/2013 03:19 PM, Lubomir Popov wrote:
On 06-Nov-13 14:12, Nikita Kiryanov wrote:
In drivers/i2c/omap24xx_i2c.c there are a few checks that attempt to
detect unconfigured pads for the i2c bus in use. These checks are
all in the form of
if (status == I2C_STAT_XRDY) {
printf(unconfigured pads\n);
return -1;
}
This check seems peculiar to me since the meaning of I2C_STAT_XRDY is
that new data is requested for transmission. Why is that indication that
the bus is not padconf'd for I2C?
Hi Nikita,
This has been empirically confirmed on OMAP4 and OMAP5. When the pads
are not
configured, the I2C controller is actually disconnected from the bus.
The clock
input for its state machine has to come from the bus however due to
stretching
etc., although it is internally generated. So actually nothing changes
within
the controller after a transaction attempt is made, and it keeps its
initial
state with XRDY set only (ready to accept transmit data). I use this as an
indicator. Not perfect, but works in most cases.
Regards,
Lubo
Thanks for the quick reply.
The reason I stumbled across this is that this check hasn't been working
well on our OMAP3 based devices. Some I2C transactions work fine, but
some of them fail this check in the address phase, especially if the I2C
transactions happen in quick successions.
You mean that you occasionally get this error on an otherwise properly
configured and working bus, right?
Yes.
Does this happen with particular
slave devices only, or randomly? And is it happening in the SPL, or in
regular U-Boot?
It happens in U-Boot when communicating with the PMIC (TPS65930),
but like I said, it worked in the driver's previous version, on the
same module.
We did not have any I2C issues
with the previous driver, and while this behavior is symptomatic of
timing issues playing around with the delays didn't help.
Which delays did you modify? Did you try to increase I2C_WAIT/I2C_TIMEOUT?
I tried to increase both I2C_WAIT and I2C_TIMEOUT, and place my own
delays as well.
I was wondering if you might have some insights as to what may cause the
controller to behave this way other than unconfigured pads?
Unfortunately I don't have any hands-on experience with OMAP3 (apart from
some very quick testing on a AM3359 derivative), and cannot guarantee that
the I2C controller IP on OMAP3 is absolutely the same as on OMAP4/5 (most
probably it isn't; shall check this on Monday). Anyway, if everything else
is OK (muxmode/pad config, pull-ups, power, etc.), the only reasonable
explanation would be that there is not enough time for the controller to
update its status register under certain conditions, and these would be
either a slower clock rate (that makes byte transmission time come close
to the timeout), or clock stretching by some slaves; btw, the latter
seems probable, judging from your words that this happens in the address
phase, when some devices could take longer to prepare for action, and they
do this by stretching the clock. That is why I'm asking if you tried to
increase I2C_TIMEOUT. Did you do any measurements on the bus to see if all
is OK and the clock rate is right, and if it gets stretched by some slaves?
I believe I found the cause of the problem. In the new version of the
driver the following line was added to the exit sequence of i2c_write:
writew(0, i2c_base-cnt);
Removing this line solved the problem (module has been doing I2C
transactions for the last 16 hours or so without failing), and I
believe the reason has to do with Advisory 1.2 in the DM3730 errata:
Advisory 1.2I2C Module Does Not Allow 0-Byte Data Requests
Revision(s) Affected1.2, 1.1 and 1.0
Details When configured as the master, the I2C module
does not allow 0-byte data transfers.
Programming I2Ci.I2C_CNT[15:0]: DCOUNT = 0 will
cause undefined behavior.
Workaround(s) There is no workaround for this issue. Do not
use 0-byte data requests.
While the mentioned write is done at the end of i2c_write, perhaps the
driver's MO still triggers this issue. It certainly is plausible
that this line was missing from the old i2c_write exit sequence on
purpose, and not by accident (i2c_read, i2c_probe, and i2c_init all
had it in the old driver).
Regards,
Lubo
--
Regards,
Nikita.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v1 6/6] Driver/IFC: Move Freescale IFC driver to a common driver
On 11/9/2013 6:30 AM, Scott Wood wrote: On Sat, 2013-11-09 at 06:22 +0530, Prabhakar Kushwaha wrote: On 11/9/2013 6:14 AM, Scott Wood wrote: On Thu, 2013-10-31 at 08:57 +0530, Prabhakar Kushwaha wrote: On 10/31/2013 7:37 AM, York Sun wrote: Freescale IFC controller has been used for mpc8xxx. It will be used for ARM-based SoC as well. This patch moves the driver to driver/mtd and fix the header file includes. Signed-off-by: York Sun york...@freescale.com Thanks York for this patch. This was pending from long time. This patch moves fsl_ifc.c from powerpc to driver/mtd I am not sure having 2 files for IFC controller in driver/mtd/ is correct. Although fsl_ifc.c is for IFC Controller(NOR, NAND machine) and fsl_ifc_nand.c is only for IFC - NAND machine. I am asking this question as same changes will be applicable in Linux also. Also, We have to move changes of arch/powerpc/cpu/mpc85xx/speed.c to fsl_ifc.c . This will make a IFC driver generic. As this patch has impact on all IFC platforms, has this been tested on few platforms? I'm not sure that drivers/mtd is the right place for it as it doesn't expose an mtd interface. Yes Scott, I am also agree with you. But we are not sure about the right place for it. This is similar to the question of where to put CPM/QE code. A place will need to be identified for glue code that doesn't fit cleanly into an existing subsystem. drivers/misc is probably the right place, though IIRC on the Linux side the drivers/misc maintainer was generally opposed to its existence and pushed back on new things being added to it. looks like putting fsl_ifc.c in driver/mtd is not good way of handle it. I should sent on RFC of putting this in driver/misc for Linux and see the response. May be I get a better solution there. Regards, Prabhakar ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] malta: arch/mips/include/asm/malta.h SPDX license tag
2013/11/11 Paul Burton paul.bur...@imgtec.com: This patch replaces the GPL-2.0 text with a GPL-2.0 SPDX-License-Identifier tag, and adds Imagination Technologies copyright following my recent changes. Signed-off-by: Paul Burton paul.bur...@imgtec.com --- arch/mips/include/asm/malta.h | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) applied to u-boot-mips/master, thanks -- - Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC] imx: add multi-architecture README
Eric, this documentation is a very good initiative. In overall I agree with what you have sketched, and it in many ways what we have demonstrated working in practice. There are a few question marks I have around your suggestion. Mainly around how the pinmuxing is suggested to be done. See the comments inline. On Sat, 9 Nov 2013 13:12:42 -0700 Eric Nelson eric.nel...@boundarydevices.com wrote: Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com --- doc/README.imx6-multi-arch | 254 + 1 file changed, 254 insertions(+) create mode 100644 doc/README.imx6-multi-arch diff --git a/doc/README.imx6-multi-arch b/doc/README.imx6-multi-arch new file mode 100644 index 000..a31718c --- /dev/null +++ b/doc/README.imx6-multi-arch @@ -0,0 +1,254 @@ +Supporting multiple architectures on Freescale i.MX6 + +This file describes how to support multiple CPU architectures +(i.MX6DQ and i.MX6DLS) in a single U-Boot image. + +Because memory configuration differs between architectures, +auto-configuration of DDR is also covered. + +1. BACKGROUND +- +The Freescale i.MX6 processor family contains four processors which are pin +compatible. Refer to http://freescale.com/imx6series for details and reference +manuals, but the highlights from a U-Boot perspective are as follows: + +i.MX6Q - Quad core, 64-bit DDR1066, 256K OCRAM +i.MX6D - Dual core, 64-bit DDR1066, 256K OCRAM +i.MX6DL - Dual core, 64-bit DDR800, 128K OCRAM +i.MX6S - Single core, 32-bit DDR800, 128K OCRAM + +These processors are also largely register-compatible, but not completely. +In particular, the IOMUX registers for common functions are in different +locations and have different selector values. + Let's not assume that list supported CPUs is complete yet (and you haven't). +The register addresses and values are consistent between the first +two processors in the list above (i.MX6DQ processors) and the second +two (i.MX6DLS for Dual-Lite/Solo). + +The i.MX6SL (Solo-Lite) processor is not pin compatible, so this +document does not describe support for that variant. + +Because of the pin-compatibility, a number of manufacturers produce +identical boards with BOM options for two or more of the processors. + +Similarly, identical boards are offered in a number of different +memory layouts, whether by partially populating the DRAM sockets +or by populating them with different densities of DDR. + +By following the conventions described in this document, a board +can support each of these options in a single boot image, and +decrease the overhead for managing images. + +Note that adding multi-arch support will add to the size of the +bootable image and slow the boot process slightly. If size and +speed are critical, a configuration-specific build can be produced +that removes this overhead. + +2. BOOT FLOW + +The boot process for i.MX6 processors begins with execution of a first +level loader in the processor's internal ROM. This loader samples +boot pins and on-chip fuses to determine the source of the secondary +boot image. + +The boot image itself consists of a header (the DCD) which describes +the load address and payload (the U-Boot firmware). It also contains +a set of register/value pairs used to initialize the CPU prior +to execution of U-Boot. + +The boot image is produced in a final stage of the build process +by the imximage tool by processing a configuration (.cfg) file. + +In a single-architecture, single memory-layout image, the DCD +can include DDR memory initialization values and the load address +may be DDR directly. + +In order to support multiple processors, the DCD must contain +a load address for the i.MX6's internal RAM (OCRAM) because the +DDR memory speed (at least) will be dependent on the processor +variant. Thankfully, the DCD items needed to load this binary +are consistent between all of the processors. + +For this reason, support for SPL (secondary program loader) is +a requirement in order to support multiple architectures in the +same image. The SPL image will determine the processor variant +and memory configuration, configure the IOMUX controller and +DDR appropriately, then load either a full version of U-Boot +or an O/S. + +3. DDR configuration + + +The DDR configuration data for single architecture boards is defined +within .cfg files in the various board directories. + +As of this writing, most boards use the structure defined in +board/boundary/nitrogen6x/ that separates the pieces of DCD +data according to function, with this general form: + + #include ddr-setup.cfg + #include 1066mhz_4x128mx16.cfg + #include clocks.cfg + +Note that only the second of these is specific to the CPU +variant or memory-layout, and the multi-arch equivalent +can simply omit that for later
Re: [U-Boot] patman drops Cc tag
On Mon, Nov 11, 2013 at 4:44 AM, Masahiro Yamada yamad...@jp.panasonic.com wrote: Hello Simon I want Cc: tag not to be touched by patman. Maybe we could add a new Patch-Cc: tag for this purpose? Good. Cc: patman does nothing. (git send-email can cc patches) Patch-cc: patman cc patches and deletes this tag. I agree; I've been using the Cc for patchsets with patman but I agree it shouldn't be drop. A new tag for this is the best approach :D -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Question about patman
On Sun, Nov 10, 2013 at 11:39 PM, Masahiro Yamada yamad...@jp.panasonic.com wrote: Hello Albert. I have posted a patch to allow adding notes below the '---' line, if this is what you mean. So far, there was no comment on it. See: http://patchwork.ozlabs.org/patch/283057/ Yeah! This is the function exactly I have wanted. Neat :-) -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Exynos5: Clock: Generic api to set and get clock rate and source
This patch implements generic api for exynos5250 and exynos5420.
These api's set and get clock rate based on the peripheral id.
Signed-off-by: Andrew Bresticker abres...@chromium.org
Signed-off-by: Rajeshwari S Shinde rajeshwar...@samsung.com
---
arch/arm/cpu/armv7/exynos/clock.c | 958 -
arch/arm/include/asm/arch-exynos/clk.h | 30 +-
drivers/mmc/exynos_dw_mmc.c| 15 +-
3 files changed, 385 insertions(+), 618 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/clock.c
b/arch/arm/cpu/armv7/exynos/clock.c
index b52e61a..09e156c 100644
--- a/arch/arm/cpu/armv7/exynos/clock.c
+++ b/arch/arm/cpu/armv7/exynos/clock.c
@@ -16,46 +16,97 @@
#define PLL_DIV_65536 65536
/* *
- * This structure is to store the src bit, div bit and prediv bit
- * positions of the peripheral clocks of the src and div registers
+ * This structure store positions of the peripheral clocks
+ * and their source, divider and predivider information.
+ * @periph_id: id of the peripheral
+ * @src_offset: offset of the source register
+ * @div_offset: offset of the divider register
+ * @prediv_offset: offset of the pre divider register
+ * @src_bit: bit location in the source register
+ * @div_bit: bit location in the divider register
+ * @pre_div_bit: bit location in the pre divider register
+ * @src_mask: mask for the source register value
+ * @div_mask: mask for the divider register value
+ * @pre_div_mask: mask for the pre divider register value
*/
struct clk_bit_info {
+ int32_t periph_id;
+ int32_t src_offset;
+ int32_t div_offset;
+ int32_t prediv_offset;
int8_t src_bit;
int8_t div_bit;
- int8_t prediv_bit;
+ int8_t pre_div_bit;
+ int8_t src_mask;
+ int32_t div_mask;
+ int32_t pre_div_mask;
};
-/* src_bit div_bit prediv_bit */
-static struct clk_bit_info clk_bit_info[PERIPH_ID_COUNT] = {
- {0, 0, -1},
- {4, 4, -1},
- {8, 8, -1},
- {12,12, -1},
- {0, 0, 8},
- {4, 16, 24},
- {8, 0, 8},
- {12,16, 24},
- {-1,-1, -1},
- {16,0, 8},
- {20,16, 24},
- {24,0, 8},
- {0, 0, 4},
- {4, 12, 16},
- {-1,-1, -1},
- {-1,-1, -1},
- {-1,24, 0},
- {-1,24, 0},
- {-1,24, 0},
- {-1,24, 0},
- {-1,24, 0},
- {-1,24, 0},
- {-1,24, 0},
- {-1,24, 0},
- {24,0, -1},
- {24,0, -1},
- {24,0, -1},
- {24,0, -1},
- {24,0, -1},
+static struct clk_bit_info exynos5_bit_info_table[] = {
+ {PERIPH_ID_UART0, 0x10250, 0x10558, -1, 0, 0, -1, 0xf, 0xf, -1},
+ {PERIPH_ID_UART1, 0x10250, 0x10558, -1, 4, 4, -1, 0xf, 0xf, -1},
+ {PERIPH_ID_UART2, 0x10250, 0x10558, -1, 8, 8, -1, 0xf, 0xf, -1},
+ {PERIPH_ID_UART3, 0x10250, 0x10558, -1, 12, 12, -1, 0xf, 0xf, -1},
+ {PERIPH_ID_I2C0, -1, 0x10514, 0x10510, -1, 24, 0, -1, 0x7, 0x7},
+ {PERIPH_ID_I2C1, -1, 0x10514, 0x10510, -1, 24, 0, -1, 0x7, 0x7},
+ {PERIPH_ID_I2C2, -1, 0x10514, 0x10510, -1, 24, 0, -1, 0x7, 0x7},
+ {PERIPH_ID_I2C3, -1, 0x10514, 0x10510, -1, 24, 0, -1, 0x7, 0x7},
+ {PERIPH_ID_I2C4, -1, 0x10514, 0x10510, -1, 24, 0, -1, 0x7, 0x7},
+ {PERIPH_ID_I2C5, -1, 0x10514, 0x10510, -1, 24, 0, -1, 0x7, 0x7},
+ {PERIPH_ID_I2C6, -1, 0x10514, 0x10510, -1, 24, 0, -1, 0x7, 0x7},
+ {PERIPH_ID_I2C7, -1, 0x10514, 0x10510, -1, 24, 0, -1, 0x7, 0x7},
+ {PERIPH_ID_I2C8, -1, 0x10514, 0x10510, -1, 24, 0, -1, 0x7, 0x7},
+ {PERIPH_ID_I2C9, -1, 0x10514, 0x10510, -1, 24, 0, -1, 0x7, 0x7},
+ {PERIPH_ID_I2C10, -1, 0x10514, 0x10510, -1, 24, 0, -1, 0x7, 0x7},
+ {PERIPH_ID_SPI0, 0x10254, 0x1055c, 0x1055c, 16, 0, 8, 0xf, 0xf, 0xff},
+ {PERIPH_ID_SPI1, 0x10254, 0x1055c, 0x1055c, 20, 16, 24, 0xf, 0xf, 0xff},
+ {PERIPH_ID_SPI2, 0x10254, 0x10560, 0x10560, 24, 0, 8, 0xf, 0xf, 0xff},
+ {PERIPH_ID_SPI3, 0x10270, 0x10580, 0x10580, 0, 0, 4, 0xf, 0xf, 0xff},
+ {PERIPH_ID_SPI4, 0x10270, 0x10580, 0x10580, 4, 12, 16, 0xf, 0xf, 0xff},
+ {PERIPH_ID_SDMMC0, 0x10244, 0x1054c, 0x1054c, 0, 0, 8, 0xf, 0xf, 0xff},
+ {PERIPH_ID_SDMMC1, 0x10244, 0x1054c, 0x1054c, 4, 16, 24, 0xf, 0xf,
+0xff},
+ {PERIPH_ID_SDMMC2, 0x10244, 0x10550, 0x10550, 8, 0, 8, 0xf, 0xf, 0xff},
+ {PERIPH_ID_SDMMC3, 0x10244, 0x10550, 0x10550, 12, 16, 24, 0xf, 0xf,
+0xff},
+ {PERIPH_ID_PWM0, 0x10250, 0x10564, -1, 24, 0, 0xf, 0xf, -1},
+ {PERIPH_ID_PWM1, 0x10250, 0x10564, -1, 24, 0, 0xf, 0xf, -1},
+ {PERIPH_ID_PWM2, 0x10250, 0x10564, -1, 24, 0, 0xf, 0xf, -1},
+ {PERIPH_ID_PWM3, 0x10250, 0x10564, -1, 24, 0, 0xf, 0xf, -1},
+ {PERIPH_ID_PWM4, 0x10250, 0x10564, -1, 24, 0, 0xf, 0xf, -1},
+
Re: [U-Boot] [PATCH] Exynos5: Clock: Generic api to set and get clock rate and source
Hi All,
This patch is based on:
[U-Boot] [PATCH 00/10 V6] EXYNOS5420: Add SMDK5420 board support
--
Regards,
Rajeshwari Shinde
On Mon, Nov 11, 2013 at 6:23 PM, Rajeshwari S Shinde
rajeshwar...@samsung.com wrote:
This patch implements generic api for exynos5250 and exynos5420.
These api's set and get clock rate based on the peripheral id.
Signed-off-by: Andrew Bresticker abres...@chromium.org
Signed-off-by: Rajeshwari S Shinde rajeshwar...@samsung.com
---
arch/arm/cpu/armv7/exynos/clock.c | 958
-
arch/arm/include/asm/arch-exynos/clk.h | 30 +-
drivers/mmc/exynos_dw_mmc.c| 15 +-
3 files changed, 385 insertions(+), 618 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/clock.c
b/arch/arm/cpu/armv7/exynos/clock.c
index b52e61a..09e156c 100644
--- a/arch/arm/cpu/armv7/exynos/clock.c
+++ b/arch/arm/cpu/armv7/exynos/clock.c
@@ -16,46 +16,97 @@
#define PLL_DIV_65536 65536
/* *
- * This structure is to store the src bit, div bit and prediv bit
- * positions of the peripheral clocks of the src and div registers
+ * This structure store positions of the peripheral clocks
+ * and their source, divider and predivider information.
+ * @periph_id: id of the peripheral
+ * @src_offset: offset of the source register
+ * @div_offset: offset of the divider register
+ * @prediv_offset: offset of the pre divider register
+ * @src_bit: bit location in the source register
+ * @div_bit: bit location in the divider register
+ * @pre_div_bit: bit location in the pre divider register
+ * @src_mask: mask for the source register value
+ * @div_mask: mask for the divider register value
+ * @pre_div_mask: mask for the pre divider register value
*/
struct clk_bit_info {
+ int32_t periph_id;
+ int32_t src_offset;
+ int32_t div_offset;
+ int32_t prediv_offset;
int8_t src_bit;
int8_t div_bit;
- int8_t prediv_bit;
+ int8_t pre_div_bit;
+ int8_t src_mask;
+ int32_t div_mask;
+ int32_t pre_div_mask;
};
-/* src_bit div_bit prediv_bit */
-static struct clk_bit_info clk_bit_info[PERIPH_ID_COUNT] = {
- {0, 0, -1},
- {4, 4, -1},
- {8, 8, -1},
- {12,12, -1},
- {0, 0, 8},
- {4, 16, 24},
- {8, 0, 8},
- {12,16, 24},
- {-1,-1, -1},
- {16,0, 8},
- {20,16, 24},
- {24,0, 8},
- {0, 0, 4},
- {4, 12, 16},
- {-1,-1, -1},
- {-1,-1, -1},
- {-1,24, 0},
- {-1,24, 0},
- {-1,24, 0},
- {-1,24, 0},
- {-1,24, 0},
- {-1,24, 0},
- {-1,24, 0},
- {-1,24, 0},
- {24,0, -1},
- {24,0, -1},
- {24,0, -1},
- {24,0, -1},
- {24,0, -1},
+static struct clk_bit_info exynos5_bit_info_table[] = {
+ {PERIPH_ID_UART0, 0x10250, 0x10558, -1, 0, 0, -1, 0xf, 0xf, -1},
+ {PERIPH_ID_UART1, 0x10250, 0x10558, -1, 4, 4, -1, 0xf, 0xf, -1},
+ {PERIPH_ID_UART2, 0x10250, 0x10558, -1, 8, 8, -1, 0xf, 0xf, -1},
+ {PERIPH_ID_UART3, 0x10250, 0x10558, -1, 12, 12, -1, 0xf, 0xf, -1},
+ {PERIPH_ID_I2C0, -1, 0x10514, 0x10510, -1, 24, 0, -1, 0x7, 0x7},
+ {PERIPH_ID_I2C1, -1, 0x10514, 0x10510, -1, 24, 0, -1, 0x7, 0x7},
+ {PERIPH_ID_I2C2, -1, 0x10514, 0x10510, -1, 24, 0, -1, 0x7, 0x7},
+ {PERIPH_ID_I2C3, -1, 0x10514, 0x10510, -1, 24, 0, -1, 0x7, 0x7},
+ {PERIPH_ID_I2C4, -1, 0x10514, 0x10510, -1, 24, 0, -1, 0x7, 0x7},
+ {PERIPH_ID_I2C5, -1, 0x10514, 0x10510, -1, 24, 0, -1, 0x7, 0x7},
+ {PERIPH_ID_I2C6, -1, 0x10514, 0x10510, -1, 24, 0, -1, 0x7, 0x7},
+ {PERIPH_ID_I2C7, -1, 0x10514, 0x10510, -1, 24, 0, -1, 0x7, 0x7},
+ {PERIPH_ID_I2C8, -1, 0x10514, 0x10510, -1, 24, 0, -1, 0x7, 0x7},
+ {PERIPH_ID_I2C9, -1, 0x10514, 0x10510, -1, 24, 0, -1, 0x7, 0x7},
+ {PERIPH_ID_I2C10, -1, 0x10514, 0x10510, -1, 24, 0, -1, 0x7, 0x7},
+ {PERIPH_ID_SPI0, 0x10254, 0x1055c, 0x1055c, 16, 0, 8, 0xf, 0xf, 0xff},
+ {PERIPH_ID_SPI1, 0x10254, 0x1055c, 0x1055c, 20, 16, 24, 0xf, 0xf,
0xff},
+ {PERIPH_ID_SPI2, 0x10254, 0x10560, 0x10560, 24, 0, 8, 0xf, 0xf, 0xff},
+ {PERIPH_ID_SPI3, 0x10270, 0x10580, 0x10580, 0, 0, 4, 0xf, 0xf, 0xff},
+ {PERIPH_ID_SPI4, 0x10270, 0x10580, 0x10580, 4, 12, 16, 0xf, 0xf,
0xff},
+ {PERIPH_ID_SDMMC0, 0x10244, 0x1054c, 0x1054c, 0, 0, 8, 0xf, 0xf,
0xff},
+ {PERIPH_ID_SDMMC1, 0x10244, 0x1054c, 0x1054c, 4, 16, 24, 0xf, 0xf,
+0xff},
+ {PERIPH_ID_SDMMC2, 0x10244, 0x10550, 0x10550, 8, 0, 8, 0xf, 0xf,
0xff},
+ {PERIPH_ID_SDMMC3, 0x10244, 0x10550, 0x10550, 12, 16, 24, 0xf, 0xf,
+0xff},
+ {PERIPH_ID_PWM0,
Re: [U-Boot] [RFC][PATCH 0/5] SATA support for OMAP5 uevm
Aneesh,
On 11/07/2013 07:15 PM, V, Aneesh wrote:
Hi Roger,
-Original Message-
From: Quadros, Roger
Sent: Thursday, November 07, 2013 2:45 AM
To: Enric Balletbo Serra
Cc: u-boot@lists.denx.de; Rini, Tom; Krishnamoorthy, Balaji T;
rob.herr...@calxeda.com; V, Aneesh
Subject: Re: [U-Boot] [RFC][PATCH 0/5] SATA support for OMAP5 uevm
+Aneesh.
Hi Enric,
On 11/07/2013 10:52 AM, Enric Balletbo Serra wrote:
Hi Roger,
Thanks for the patches!
2013/11/6 Roger Quadros rog...@ti.com:
Hi,
This series adds SATA support for OMAP5 uevm board.
This is an RFC patchset for review only. Patches are based on
v2013.10.
cheers,
-roger
---
Roger Quadros (5):
ahci: Error out with message on malloc() failure
ARM: OMAP5: Add Pipe3 PHY driver
ARM: OMAP5: Add PRCM and Control information for SATA
ARM: OMAP5: Add SATA platform glue
ARM: omap5_uevm: Add SATA support
arch/arm/cpu/armv7/omap-common/Makefile| 7 +
arch/arm/cpu/armv7/omap-common/pipe3-phy.c | 233
+ arch/arm/cpu/armv7/omap-
common/pipe3-phy.h | 36 +
arch/arm/cpu/armv7/omap-common/sata.c | 78 ++
arch/arm/cpu/armv7/omap5/prcm-regs.c | 5 +
arch/arm/include/asm/arch-omap5/clock.h| 3 +
arch/arm/include/asm/arch-omap5/omap.h | 3 +
arch/arm/include/asm/arch-omap5/sata.h | 48 ++
arch/arm/include/asm/omap_common.h | 3 +
board/ti/omap5_uevm/evm.c | 7 +
drivers/block/ahci.c | 16 +-
include/configs/omap5_uevm.h | 10 ++
12 files changed, 447 insertions(+), 2 deletions(-) create mode
100644 arch/arm/cpu/armv7/omap-common/pipe3-phy.c
create mode 100644 arch/arm/cpu/armv7/omap-common/pipe3-phy.h
create mode 100644 arch/arm/cpu/armv7/omap-common/sata.c
create mode 100644 arch/arm/include/asm/arch-omap5/sata.h
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
I applied your patches and worked perfectly, however I've two small issues.
The first issue is that I see the following error:
scanning bus for devices...
ERROR: v7_dcache_inval_range - start address is not aligned - 0xfee48618
ERROR: v7_dcache_inval_range - stop address is not aligned -
0xfee48818
I'm seeing this too. Not sure how to fix it.
Aneesh, any pointers?
The issue is that the dcache invalidation is requested for a buffer that is
not aligned to cache-line
boundary. The cpu instructions for cache invalidation operate on cache lines,
so a cache line can
not be invalidated partially. So in this case the invalidation function will
refuse to invalidate the
first and last cache lines.
The solution is to align your DMA buffer correctly. Take a look at :
ALLOC_CACHE_ALIGN_BUFFER() and DEFINE_CACHE_ALIGN_BUFFER() in
include/common.h
Also, doc/README.arm-caches has instructions for handling cached buffers for
DMA.
Thanks for this tip, it helped.
One more thing. While I was looking at arch/arm/cpu/armv7/cache_v7.c
I failed to understand how you convert the cache line size from words to byte.
e.g.
static void v7_maint_dcache_level_setway(u32 level, u32 operation)
{
u32 ccsidr;
u32 num_sets, num_ways, log2_line_len, log2_num_ways;
u32 way_shift;
set_csselr(level, ARMV7_CSSELR_IND_DATA_UNIFIED);
ccsidr = get_ccsidr();
log2_line_len = ((ccsidr CCSIDR_LINE_SIZE_MASK)
CCSIDR_LINE_SIZE_OFFSET) + 2;
/* Converting from words to bytes */
log2_line_len += 2;
Shouldn't this be
log2_line_len += 1;
cheers,
-roger
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH v14 07/10] arm64: core support
Hi David, On Mon, Oct 14, 2013 at 9:34 PM, feng...@phytium.com.cn wrote: From: David Feng feng...@phytium.com.cn Relocation code based on a patch by Scott Wood, which is: Signed-off-by: Scott Wood scottw...@freescale.com Signed-off-by: David Feng feng...@phytium.com.cn --- arch/arm/config.mk |3 +- arch/arm/cpu/armv8/Makefile | 38 + arch/arm/cpu/armv8/cache.S | 130 + arch/arm/cpu/armv8/cache_v8.c | 218 arch/arm/cpu/armv8/config.mk| 15 ++ arch/arm/cpu/armv8/cpu.c| 67 + arch/arm/cpu/armv8/exceptions.S | 112 +++ arch/arm/cpu/armv8/start.S | 234 +++ arch/arm/cpu/armv8/timer.c | 80 +++ arch/arm/cpu/armv8/tlb.S| 30 arch/arm/cpu/armv8/u-boot.lds | 89 arch/arm/include/asm/armv8/mmu.h| 110 +++ arch/arm/include/asm/byteorder.h| 12 ++ arch/arm/include/asm/cache.h|5 + arch/arm/include/asm/config.h |6 + arch/arm/include/asm/global_data.h |6 +- arch/arm/include/asm/io.h | 15 +- arch/arm/include/asm/macro.h| 36 + arch/arm/include/asm/posix_types.h | 10 ++ arch/arm/include/asm/proc-armv/ptrace.h | 21 +++ arch/arm/include/asm/proc-armv/system.h | 59 +++- arch/arm/include/asm/system.h | 77 ++ arch/arm/include/asm/types.h|4 + arch/arm/include/asm/u-boot.h |4 + arch/arm/include/asm/unaligned.h|2 +- arch/arm/lib/Makefile | 14 ++ arch/arm/lib/board.c|7 +- arch/arm/lib/bootm.c| 16 +++ arch/arm/lib/crt0_64.S | 113 +++ arch/arm/lib/interrupts_64.c| 120 arch/arm/lib/relocate_64.S | 58 common/image.c |1 + doc/README.arm64| 45 ++ examples/standalone/stubs.c | 15 ++ include/image.h |1 + 35 files changed, 1762 insertions(+), 11 deletions(-) I think this series needs to be rebased to mainline now. I also found that it did not build for armv7 past this commit - if it helps I did a bit of tweaking and pushed a branch to 'armv8' at u-boot-x86.git. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/8] ahci: Error out with message on malloc() failure
If malloc() fails, we don't want to continue in ahci_init() and
ahci_init_one(). Also print a more informative error message on
malloc() failures.
CC: Rob Herring rob.herr...@calxeda.com
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/block/ahci.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/block/ahci.c b/drivers/block/ahci.c
index 0daad36..e24d634 100644
--- a/drivers/block/ahci.c
+++ b/drivers/block/ahci.c
@@ -379,6 +379,11 @@ static int ahci_init_one(pci_dev_t pdev)
int rc;
probe_ent = malloc(sizeof(struct ahci_probe_ent));
+ if (!probe_ent) {
+ printf(%s: No memory for probe_ent\n, __func__);
+ return -ENOMEM;
+ }
+
memset(probe_ent, 0, sizeof(struct ahci_probe_ent));
probe_ent-dev = pdev;
@@ -503,7 +508,7 @@ static int ahci_port_start(u8 port)
mem = (u32) malloc(AHCI_PORT_PRIV_DMA_SZ + 2048);
if (!mem) {
free(pp);
- printf(No mem for table!\n);
+ printf(%s: No mem for table!\n, __func__);
return -ENOMEM;
}
@@ -638,8 +643,10 @@ static int ata_scsiop_inquiry(ccb *pccb)
/* Read id from sata */
port = pccb-target;
tmpid = malloc(ATA_ID_WORDS * 2);
- if (!tmpid)
+ if (!tmpid) {
+ printf(%s: No memory for tmpid\n, __func__);
return -ENOMEM;
+ }
if (ahci_device_data_io(port, (u8 *) fis, sizeof(fis), (u8 *)tmpid,
ATA_ID_WORDS * 2, 0)) {
@@ -889,6 +896,11 @@ int ahci_init(u32 base)
u32 linkmap;
probe_ent = malloc(sizeof(struct ahci_probe_ent));
+ if (!probe_ent) {
+ printf(%s: No memory for probe_ent\n, __func__);
+ return -ENOMEM;
+ }
+
memset(probe_ent, 0, sizeof(struct ahci_probe_ent));
probe_ent-host_flags = ATA_FLAG_SATA
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/8] SATA support for omap5_uevm and dra7_evm
Hi, This series adds SATA support for OMAP5 uevm and DRA7 evm. Patches are also availabe at g...@github.com:rogerq/u-boot.git sata v2: - Address review comments in the RFC series - Fix cache align error in the ahci driver - Added dra7 support cheers, -roger Roger Quadros (8): ahci: Error out with message on malloc() failure ahci: Fix cache align error messages ARM: OMAP5: Add Pipe3 PHY driver ARM: OMAP5: Add PRCM and Control information for SATA ARM: OMAP5: Add SATA platform glue ARM: omap5_uevm: Add SATA support ARM: DRA7xx: Add PRCM and Control information for SATA ARM: dra7_evm: Add SATA support arch/arm/cpu/armv7/omap-common/Makefile| 5 + arch/arm/cpu/armv7/omap-common/pipe3-phy.c | 233 + arch/arm/cpu/armv7/omap-common/pipe3-phy.h | 36 + arch/arm/cpu/armv7/omap-common/sata.c | 75 ++ arch/arm/cpu/armv7/omap5/prcm-regs.c | 7 + arch/arm/include/asm/arch-omap5/clock.h| 3 + arch/arm/include/asm/arch-omap5/omap.h | 3 + arch/arm/include/asm/arch-omap5/sata.h | 48 ++ arch/arm/include/asm/omap_common.h | 2 + board/ti/dra7xx/evm.c | 7 + board/ti/omap5_uevm/evm.c | 7 + drivers/block/ahci.c | 18 ++- include/configs/dra7xx_evm.h | 11 ++ include/configs/omap5_uevm.h | 10 ++ 14 files changed, 459 insertions(+), 6 deletions(-) create mode 100644 arch/arm/cpu/armv7/omap-common/pipe3-phy.c create mode 100644 arch/arm/cpu/armv7/omap-common/pipe3-phy.h create mode 100644 arch/arm/cpu/armv7/omap-common/sata.c create mode 100644 arch/arm/include/asm/arch-omap5/sata.h -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/8] ahci: Fix cache align error messages
Align the ATA ID buffer to the cache-line boundary. This gets rid
of the below error mesages on ARM v7 platforms.
scanning bus for devices...
ERROR: v7_dcache_inval_range - start address is not aligned - 0xfee48618
ERROR: v7_dcache_inval_range - stop address is not aligned - 0xfee48818
CC: Aneesh V ane...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/block/ahci.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/block/ahci.c b/drivers/block/ahci.c
index e24d634..e64df4f 100644
--- a/drivers/block/ahci.c
+++ b/drivers/block/ahci.c
@@ -623,7 +623,7 @@ static int ata_scsiop_inquiry(ccb *pccb)
95 - 4,
};
u8 fis[20];
- u16 *tmpid;
+ ALLOC_CACHE_ALIGN_BUFFER(u16, tmpid, ATA_ID_WORDS);
u8 port;
/* Clean ccb data buffer */
@@ -642,16 +642,10 @@ static int ata_scsiop_inquiry(ccb *pccb)
/* Read id from sata */
port = pccb-target;
- tmpid = malloc(ATA_ID_WORDS * 2);
- if (!tmpid) {
- printf(%s: No memory for tmpid\n, __func__);
- return -ENOMEM;
- }
if (ahci_device_data_io(port, (u8 *) fis, sizeof(fis), (u8 *)tmpid,
ATA_ID_WORDS * 2, 0)) {
debug(scsi_ahci: SCSI inquiry command failure.\n);
- free(tmpid);
return -EIO;
}
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/8] ARM: OMAP5: Add Pipe3 PHY driver
Pipe3 PHY is used by SATA, USB3 and PCIe modules. This is
a driver for the Pipe3 PHY.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/cpu/armv7/omap-common/Makefile| 4 +
arch/arm/cpu/armv7/omap-common/pipe3-phy.c | 233 +
arch/arm/cpu/armv7/omap-common/pipe3-phy.h | 36 +
3 files changed, 273 insertions(+)
create mode 100644 arch/arm/cpu/armv7/omap-common/pipe3-phy.c
create mode 100644 arch/arm/cpu/armv7/omap-common/pipe3-phy.h
diff --git a/arch/arm/cpu/armv7/omap-common/Makefile
b/arch/arm/cpu/armv7/omap-common/Makefile
index 4d3a165..bfaf814 100644
--- a/arch/arm/cpu/armv7/omap-common/Makefile
+++ b/arch/arm/cpu/armv7/omap-common/Makefile
@@ -17,6 +17,10 @@ obj-y+= vc.o
obj-y += abb.o
endif
+ifneq ($(CONFIG_OMAP54XX),)
+COBJS += pipe3-phy.o
+endif
+
ifeq ($(CONFIG_OMAP34XX),)
obj-y += boot-common.o
obj-y += lowlevel_init.o
diff --git a/arch/arm/cpu/armv7/omap-common/pipe3-phy.c
b/arch/arm/cpu/armv7/omap-common/pipe3-phy.c
new file mode 100644
index 000..d9906ee
--- /dev/null
+++ b/arch/arm/cpu/armv7/omap-common/pipe3-phy.c
@@ -0,0 +1,233 @@
+/*
+ * TI PIPE3 PHY
+ *
+ * (C) Copyright 2013
+ * Texas Instruments, www.ti.com
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include common.h
+#include sata.h
+#include asm/arch/clock.h
+#include asm/arch/sys_proto.h
+#include asm/io.h
+#include asm/errno.h
+#include pipe3-phy.h
+
+/* PLLCTRL Registers */
+#define PLL_STATUS 0x0004
+#define PLL_GO 0x0008
+#define PLL_CONFIGURATION1 0x000C
+#define PLL_CONFIGURATION2 0x0010
+#define PLL_CONFIGURATION3 0x0014
+#define PLL_CONFIGURATION4 0x0020
+
+#define PLL_REGM_MASK 0x001FFE00
+#define PLL_REGM_SHIFT 9
+#define PLL_REGM_F_MASK 0x0003
+#define PLL_REGM_F_SHIFT0
+#define PLL_REGN_MASK 0x01FE
+#define PLL_REGN_SHIFT 1
+#define PLL_SELFREQDCO_MASK 0x000E
+#define PLL_SELFREQDCO_SHIFT1
+#define PLL_SD_MASK 0x0003FC00
+#define PLL_SD_SHIFT10
+#define SET_PLL_GO 0x1
+#define PLL_TICOPWDNBIT(16)
+#define PLL_LDOPWDN BIT(15)
+#define PLL_LOCK0x2
+#define PLL_IDLE0x1
+
+/* PHY POWER CONTROL Register */
+#define OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_CMD_MASK 0x003FC000
+#define OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_CMD_SHIFT0xE
+
+#define OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_FREQ_MASK0xFFC0
+#define OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_FREQ_SHIFT 0x16
+
+#define OMAP_CTRL_PIPE3_PHY_TX_RX_POWERON 0x3
+#define OMAP_CTRL_PIPE3_PHY_TX_RX_POWEROFF 0x0
+
+
+#define PLL_IDLE_TIME 100 /* in milliseconds */
+#define PLL_LOCK_TIME 100 /* in milliseconds */
+
+#define perror(fmt, args...) printf(%s: fmt, __func__ , ##args)
+
+static inline u32 omap_pipe3_readl(void __iomem *addr, unsigned offset)
+{
+ return __raw_readl(addr + offset);
+}
+
+static inline void omap_pipe3_writel(void __iomem *addr, unsigned offset,
+ u32 data)
+{
+ __raw_writel(data, addr + offset);
+}
+
+static struct pipe3_dpll_params *omap_pipe3_get_dpll_params(struct omap_pipe3
+ *pipe3)
+{
+ u32 rate;
+ struct pipe3_dpll_map *dpll_map = pipe3-dpll_map;
+
+ rate = get_sys_clk_freq();
+
+ for (; dpll_map-rate; dpll_map++) {
+ if (rate == dpll_map-rate)
+ return dpll_map-params;
+ }
+
+ perror(%s: No DPLL configuration for %u Hz SYS CLK\n,
+ __func__, rate);
+ return NULL;
+}
+
+
+static int omap_pipe3_wait_lock(struct omap_pipe3 *phy)
+{
+ u32 val;
+ int timeout = PLL_LOCK_TIME;
+
+ do {
+ mdelay(1);
+ val = omap_pipe3_readl(phy-pll_ctrl_base, PLL_STATUS);
+ if (val PLL_LOCK)
+ break;
+ } while (--timeout);
+
+ if (!(val PLL_LOCK)) {
+ perror(%s: DPLL failed to lock\n, __func__);
+ return -EBUSY;
+ }
+
+ return 0;
+}
+
+static int omap_pipe3_dpll_program(struct omap_pipe3 *phy)
+{
+ u32 val;
+ struct pipe3_dpll_params *dpll_params;
+
+ dpll_params = omap_pipe3_get_dpll_params(phy);
+ if (!dpll_params) {
+ perror(%s: Invalid DPLL parameters\n, __func__);
+ return -EINVAL;
+ }
+
+ val = omap_pipe3_readl(phy-pll_ctrl_base, PLL_CONFIGURATION1);
+ val = ~PLL_REGN_MASK;
+ val |= dpll_params-n PLL_REGN_SHIFT;
+ omap_pipe3_writel(phy-pll_ctrl_base, PLL_CONFIGURATION1, val);
+
+ val = omap_pipe3_readl(phy-pll_ctrl_base, PLL_CONFIGURATION2);
+ val = ~PLL_SELFREQDCO_MASK;
+ val |= dpll_params-freq PLL_SELFREQDCO_SHIFT;
+
[U-Boot] [PATCH v2 4/8] ARM: OMAP5: Add PRCM and Control information for SATA
Adds the necessary PRCM and Control register information for
SATA on OMAP5.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/cpu/armv7/omap5/prcm-regs.c| 4
arch/arm/include/asm/arch-omap5/clock.h | 3 +++
arch/arm/include/asm/arch-omap5/omap.h | 3 +++
arch/arm/include/asm/omap_common.h | 2 ++
4 files changed, 12 insertions(+)
diff --git a/arch/arm/cpu/armv7/omap5/prcm-regs.c
b/arch/arm/cpu/armv7/omap5/prcm-regs.c
index 304ac1c..5c60d74 100644
--- a/arch/arm/cpu/armv7/omap5/prcm-regs.c
+++ b/arch/arm/cpu/armv7/omap5/prcm-regs.c
@@ -203,8 +203,10 @@ struct prcm_regs const omap5_es1_prcm = {
.cm_l3init_hsusbotg_clkctrl = 0x4a009360,
.cm_l3init_hsusbtll_clkctrl = 0x4a009368,
.cm_l3init_p1500_clkctrl = 0x4a009378,
+ .cm_l3init_sata_clkctrl = 0x4a009388,
.cm_l3init_fsusb_clkctrl = 0x4a0093d0,
.cm_l3init_ocp2scp1_clkctrl = 0x4a0093e0,
+ .cm_l3init_ocp2scp3_clkctrl = 0x4a0093e8,
/* cm2.l4per */
.cm_l4per_clkstctrl = 0x4a009400,
@@ -296,6 +298,7 @@ struct omap_sys_ctrl_regs const omap5_ctrl = {
.control_status = 0x4A002134,
.control_std_fuse_opp_vdd_mpu_2 = 0x4A0021B4,
.control_phy_power_usb = 0x4A002370,
+ .control_phy_power_sata = 0x4A002374,
.control_padconf_core_base = 0x4A002800,
.control_paconf_global = 0x4A002DA0,
.control_paconf_mode= 0x4A002DA4,
@@ -698,6 +701,7 @@ struct prcm_regs const omap5_es2_prcm = {
.cm_l3init_hsusbotg_clkctrl = 0x4a009660,
.cm_l3init_hsusbtll_clkctrl = 0x4a009668,
.cm_l3init_p1500_clkctrl = 0x4a009678,
+ .cm_l3init_sata_clkctrl = 0x4a009688,
.cm_l3init_fsusb_clkctrl = 0x4a0096d0,
.cm_l3init_ocp2scp1_clkctrl = 0x4a0096e0,
.cm_l3init_ocp2scp3_clkctrl = 0x4a0096e8,
diff --git a/arch/arm/include/asm/arch-omap5/clock.h
b/arch/arm/include/asm/arch-omap5/clock.h
index 8869b50..2dfe4ef 100644
--- a/arch/arm/include/asm/arch-omap5/clock.h
+++ b/arch/arm/include/asm/arch-omap5/clock.h
@@ -137,6 +137,9 @@
#define HSMMC_CLKCTRL_CLKSEL_MASK (1 24)
#define HSMMC_CLKCTRL_CLKSEL_DIV_MASK (1 25)
+/* CM_L3INIT_SATA_CLKCTRL */
+#define SATA_CLKCTRL_OPTFCLKEN_MASK(1 8)
+
/* CM_WKUP_GPTIMER1_CLKCTRL */
#define GPTIMER1_CLKCTRL_CLKSEL_MASK (1 24)
diff --git a/arch/arm/include/asm/arch-omap5/omap.h
b/arch/arm/include/asm/arch-omap5/omap.h
index 414d37a..150db0f 100644
--- a/arch/arm/include/asm/arch-omap5/omap.h
+++ b/arch/arm/include/asm/arch-omap5/omap.h
@@ -64,6 +64,9 @@
/* QSPI */
#define QSPI_BASE 0x4B30
+/* SATA */
+#define DWC_AHSATA_BASE0x4A14
+
/*
* Hardware Register Details
*/
diff --git a/arch/arm/include/asm/omap_common.h
b/arch/arm/include/asm/omap_common.h
index 8a395e8..382da90 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -226,6 +226,7 @@ struct prcm_regs {
u32 cm_l3init_hsusbotg_clkctrl;
u32 cm_l3init_hsusbtll_clkctrl;
u32 cm_l3init_p1500_clkctrl;
+ u32 cm_l3init_sata_clkctrl;
u32 cm_l3init_fsusb_clkctrl;
u32 cm_l3init_ocp2scp1_clkctrl;
u32 cm_l3init_ocp2scp3_clkctrl;
@@ -366,6 +367,7 @@ struct omap_sys_ctrl_regs {
u32 control_ldosram_mpu_voltage_ctrl;
u32 control_ldosram_core_voltage_ctrl;
u32 control_usbotghs_ctrl;
+ u32 control_phy_power_sata;
u32 control_padconf_core_base;
u32 control_paconf_global;
u32 control_paconf_mode;
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 5/8] ARM: OMAP5: Add SATA platform glue
Add platform glue logic for the SATA controller.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/cpu/armv7/omap-common/Makefile | 1 +
arch/arm/cpu/armv7/omap-common/sata.c | 75 +
arch/arm/include/asm/arch-omap5/sata.h | 48 +
3 files changed, 124 insertions(+)
create mode 100644 arch/arm/cpu/armv7/omap-common/sata.c
create mode 100644 arch/arm/include/asm/arch-omap5/sata.h
diff --git a/arch/arm/cpu/armv7/omap-common/Makefile
b/arch/arm/cpu/armv7/omap-common/Makefile
index bfaf814..679c1a1 100644
--- a/arch/arm/cpu/armv7/omap-common/Makefile
+++ b/arch/arm/cpu/armv7/omap-common/Makefile
@@ -19,6 +19,7 @@ endif
ifneq ($(CONFIG_OMAP54XX),)
COBJS += pipe3-phy.o
+obj-$(CONFIG_SCSI_AHCI_PLAT) += sata.o
endif
ifeq ($(CONFIG_OMAP34XX),)
diff --git a/arch/arm/cpu/armv7/omap-common/sata.c
b/arch/arm/cpu/armv7/omap-common/sata.c
new file mode 100644
index 000..86cdc3c
--- /dev/null
+++ b/arch/arm/cpu/armv7/omap-common/sata.c
@@ -0,0 +1,75 @@
+/*
+ * TI SATA platform driver
+ *
+ * (C) Copyright 2013
+ * Texas Instruments, www.ti.com
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include common.h
+#include ahci.h
+#include scsi.h
+#include asm/arch/clock.h
+#include asm/arch/sata.h
+#include asm/io.h
+#include pipe3-phy.h
+
+static struct pipe3_dpll_map dpll_map_sata[] = {
+ {1200, {1000, 7, 4, 6, 0} },/* 12 MHz */
+ {1680, {714, 7, 4, 6, 0} }, /* 16.8 MHz */
+ {1920, {625, 7, 4, 6, 0} }, /* 19.2 MHz */
+ {2000, {600, 7, 4, 6, 0} }, /* 20 MHz */
+ {2600, {461, 7, 4, 6, 0} }, /* 26 MHz */
+ {3840, {312, 7, 4, 6, 0} }, /* 38.4 MHz */
+ { },/* Terminator */
+};
+
+struct omap_pipe3 sata_phy = {
+ .pll_ctrl_base = (void __iomem *)TI_SATA_PLLCTRL_BASE,
+ /* .power_reg is updated at runtime */
+ .dpll_map = dpll_map_sata,
+};
+
+int omap_sata_init(void)
+{
+ int ret;
+ u32 val;
+
+ u32 const clk_domains_sata[] = {
+ 0
+ };
+
+ u32 const clk_modules_hw_auto_sata[] = {
+ (*prcm)-cm_l3init_ocp2scp3_clkctrl,
+ 0
+ };
+
+ u32 const clk_modules_explicit_en_sata[] = {
+ (*prcm)-cm_l3init_sata_clkctrl,
+ 0
+ };
+
+ do_enable_clocks(clk_domains_sata,
+ clk_modules_hw_auto_sata,
+ clk_modules_explicit_en_sata,
+ 0);
+
+ /* Enable optional functional clock for SATA */
+ setbits_le32((*prcm)-cm_l3init_sata_clkctrl,
+ SATA_CLKCTRL_OPTFCLKEN_MASK);
+
+ sata_phy.power_reg = (void __iomem *)(*ctrl)-control_phy_power_sata;
+
+ /* Power up the PHY */
+ phy_pipe3_power_on(sata_phy);
+
+ /* Enable SATA module, No Idle, No Standby */
+ val = TI_SATA_IDLE_NO | TI_SATA_STANDBY_NO;
+ writel(val, TI_SATA_WRAPPER_BASE + TI_SATA_SYSCONFIG);
+
+ ret = ahci_init(DWC_AHSATA_BASE);
+ scsi_scan(1);
+
+ return ret;
+}
diff --git a/arch/arm/include/asm/arch-omap5/sata.h
b/arch/arm/include/asm/arch-omap5/sata.h
new file mode 100644
index 000..2ca8947
--- /dev/null
+++ b/arch/arm/include/asm/arch-omap5/sata.h
@@ -0,0 +1,48 @@
+/*
+ * SATA Wrapper Register map
+ *
+ * (C) Copyright 2013
+ * Texas Instruments, www.ti.com
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#ifndef _TI_SATA_H
+#define _TI_SATA_H
+
+/* SATA Wrapper module */
+#define TI_SATA_WRAPPER_BASE (OMAP54XX_L4_CORE_BASE + 0x141100)
+/* SATA PHY Module */
+#define TI_SATA_PLLCTRL_BASE (OMAP54XX_L4_CORE_BASE + 0x96800)
+
+/* SATA Wrapper register offsets */
+#define TI_SATA_SYSCONFIG 0x00
+#define TI_SATA_CDRLOCK0x04
+
+/* Register Set */
+#define TI_SATA_SYSCONFIG_OVERRIDE0(1 16)
+#define TI_SATA_SYSCONFIG_STANDBY_MASK (0x3 4)
+#define TI_SATA_SYSCONFIG_IDLE_MASK(0x3 2)
+
+/* Standby modes */
+#define TI_SATA_STANDBY_FORCE 0x0
+#define TI_SATA_STANDBY_NO (0x1 4)
+#define TI_SATA_STANDBY_SMART_WAKE (0x3 4)
+#define TI_SATA_STANDBY_SMART (0x2 4)
+
+/* Idle modes */
+#define TI_SATA_IDLE_FORCE 0x0
+#define TI_SATA_IDLE_NO(0x1 2)
+#define TI_SATA_IDLE_SMART_WAKE(0x3 2)
+#define TI_SATA_IDLE_SMART (0x2 2)
+
+#ifdef CONFIG_SCSI_AHCI_PLAT
+int omap_sata_init(void);
+#else
+static inline int omap_sata_init(void)
+{
+ return 0;
+}
+#endif /* CONFIG_SCSI_AHCI_PLAT */
+
+#endif /* _TI_SATA_H */
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 8/8] ARM: dra7_evm: Add SATA support
The evm has a SATA port. Enable SATA configuration and
inititialize the SATA controller.
Signed-off-by: Roger Quadros rog...@ti.com
---
board/ti/dra7xx/evm.c| 7 +++
include/configs/dra7xx_evm.h | 11 +++
2 files changed, 18 insertions(+)
diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
index 9657c75..9ae88c5 100644
--- a/board/ti/dra7xx/evm.c
+++ b/board/ti/dra7xx/evm.c
@@ -14,6 +14,7 @@
#include palmas.h
#include asm/arch/sys_proto.h
#include asm/arch/mmc_host_def.h
+#include asm/arch/sata.h
#include mux_data.h
@@ -77,6 +78,12 @@ int board_init(void)
return 0;
}
+int board_late_init(void)
+{
+ omap_sata_init();
+ return 0;
+}
+
/**
* @brief misc_init_r - Configure EVM board specific configurations
* such as power configurations, ethernet initialization as phase2 of
diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h
index a9f39f2..6fadffb 100644
--- a/include/configs/dra7xx_evm.h
+++ b/include/configs/dra7xx_evm.h
@@ -78,4 +78,15 @@
#define CONFIG_OMAP_USB_PHY
#define CONFIG_OMAP_USB2PHY2_HOST
+/* SATA */
+#define CONFIG_BOARD_LATE_INIT
+#define CONFIG_CMD_SCSI
+#define CONFIG_LIBATA
+#define CONFIG_SCSI_AHCI
+#define CONFIG_SCSI_AHCI_PLAT
+#define CONFIG_SYS_SCSI_MAX_SCSI_ID1
+#define CONFIG_SYS_SCSI_MAX_LUN1
+#define CONFIG_SYS_SCSI_MAX_DEVICE (CONFIG_SYS_SCSI_MAX_SCSI_ID * \
+ CONFIG_SYS_SCSI_MAX_LUN)
+
#endif /* __CONFIG_DRA7XX_EVM_H */
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 6/8] ARM: omap5_uevm: Add SATA support
The uevm has a SATA port. Inititialize the SATA controller.
Signed-off-by: Roger Quadros rog...@ti.com
---
board/ti/omap5_uevm/evm.c| 7 +++
include/configs/omap5_uevm.h | 10 ++
2 files changed, 17 insertions(+)
diff --git a/board/ti/omap5_uevm/evm.c b/board/ti/omap5_uevm/evm.c
index bb3a699..af854da 100644
--- a/board/ti/omap5_uevm/evm.c
+++ b/board/ti/omap5_uevm/evm.c
@@ -20,6 +20,7 @@
#include asm/arch/clock.h
#include asm/arch/ehci.h
#include asm/ehci-omap.h
+#include asm/arch/sata.h
#define DIE_ID_REG_BASE (OMAP54XX_L4_CORE_BASE + 0x2000)
#define DIE_ID_REG_OFFSET 0x200
@@ -67,6 +68,12 @@ int board_init(void)
return 0;
}
+int board_late_init(void)
+{
+ omap_sata_init();
+ return 0;
+}
+
int board_eth_init(bd_t *bis)
{
return 0;
diff --git a/include/configs/omap5_uevm.h b/include/configs/omap5_uevm.h
index 4d3a800..2f128b8 100644
--- a/include/configs/omap5_uevm.h
+++ b/include/configs/omap5_uevm.h
@@ -69,4 +69,14 @@
/* Max time to hold reset on this board, see doc/README.omap-reset-time */
#define CONFIG_OMAP_PLATFORM_RESET_TIME_MAX_USEC 16296
+#define CONFIG_BOARD_LATE_INIT
+#define CONFIG_CMD_SCSI
+#define CONFIG_LIBATA
+#define CONFIG_SCSI_AHCI
+#define CONFIG_SCSI_AHCI_PLAT
+#define CONFIG_SYS_SCSI_MAX_SCSI_ID1
+#define CONFIG_SYS_SCSI_MAX_LUN1
+#define CONFIG_SYS_SCSI_MAX_DEVICE (CONFIG_SYS_SCSI_MAX_SCSI_ID * \
+ CONFIG_SYS_SCSI_MAX_LUN)
+
#endif /* __CONFIG_OMAP5_EVM_H */
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 7/8] ARM: DRA7xx: Add PRCM and Control information for SATA
Adds the necessary PRCM and Control register information for
SATA on DRA7xx.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/cpu/armv7/omap5/prcm-regs.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/cpu/armv7/omap5/prcm-regs.c
b/arch/arm/cpu/armv7/omap5/prcm-regs.c
index 5c60d74..77c428b 100644
--- a/arch/arm/cpu/armv7/omap5/prcm-regs.c
+++ b/arch/arm/cpu/armv7/omap5/prcm-regs.c
@@ -376,6 +376,7 @@ struct omap_sys_ctrl_regs const omap5_ctrl = {
struct omap_sys_ctrl_regs const dra7xx_ctrl = {
.control_status = 0x4A002134,
+ .control_phy_power_sata = 0x4A002374,
.control_core_mac_id_0_lo = 0x4A002514,
.control_core_mac_id_0_hi = 0x4A002518,
.control_core_mac_id_1_lo = 0x4A00251C,
@@ -895,9 +896,11 @@ struct prcm_regs const dra7xx_prcm = {
.cm_l3init_hsusbhost_clkctrl= 0x4a009340,
.cm_l3init_hsusbotg_clkctrl = 0x4a009348,
.cm_l3init_hsusbtll_clkctrl = 0x4a009350,
+ .cm_l3init_sata_clkctrl = 0x4a009388,
.cm_gmac_clkstctrl = 0x4a0093c0,
.cm_gmac_gmac_clkctrl = 0x4a0093d0,
.cm_l3init_ocp2scp1_clkctrl = 0x4a0093e0,
+ .cm_l3init_ocp2scp3_clkctrl = 0x4a0093e8,
/* cm2.l4per */
.cm_l4per_clkstctrl = 0x4a009700,
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 05/18] pcnet: enable the NOUFLO feature
Dear Paul Burton, On 10/11/13 20:02, Marek Vasut wrote: Dear Paul Burton, On relatively slow boards (such as the MIPS Malta with an FPGA core card) it can be extremely common for transmits to underflow - to the point where it appears they simply do not work at all. Setting the NOUFLO bit causes the ethernet controller to not begin transmission on the wire until a transmit start point is reached. Setting that transmit start point to the full packet will cause the controller to only transmit the packet once it has buffered it entirely thus preventing any transmit underflows from occuring and allowing the controller to function on slower boards. Signed-off-by: Paul Burton paul.bur...@imgtec.com --- Changes in v2: - rebase atop master --- drivers/net/pcnet.c | 15 +++ 1 file changed, 15 insertions(+) diff --git a/drivers/net/pcnet.c b/drivers/net/pcnet.c index 7b87660..5b248be 100644 --- a/drivers/net/pcnet.c +++ b/drivers/net/pcnet.c @@ -312,6 +312,21 @@ static int pcnet_init(struct eth_device *dev, bd_t *bis) pcnet_write_bcr(dev, 32, val); /* + * Enable NOUFLO on supported controllers, with the transmit + * start point set to the full packet. This will cause entire + * packets to be buffered by the ethernet controller before + * transmission, eliminating underflows which are common on + * slower devices. Controllers which do not support NOUFLO will + * simply be left with a larger transmit FIFO threshold. + */ + val = pcnet_read_bcr(dev, 18); + val |= 1 11; + pcnet_write_bcr(dev, 18, val); + val = pcnet_read_csr(dev, 80); + val |= 0x3 10; + pcnet_write_csr(dev, 80, val); Would be nice to fix this so we don't have so many magic numbers there. Best regards, Marek Vasut I agree, the whole file is full of them. I'll submit a cleanup patch later if nobody else beats me to it. Thank you, that'd be really nice of you to do. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 08/18] malta: setup super I/O UARTs
Dear Paul Burton, Grepping all I found was board/mpl/common/isa.c which seems to do something similar. However calling this a driver is quite generous - all it does it write some board-specific values to some registers. So there's really not much to be shared. Thanks for clearing this. So all super-IOs do share among themselves is the name ;-) Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 07/18] qemu-malta: rename to just malta
Dear Paul Burton, On 10/11/13 20:05, Marek Vasut wrote: Dear Paul Burton, This is in preparation for adapting this board to function correctly on a physical MIPS Malta board. The board is moved into an imgtec vendor directory at the same time in order to ready us for any other boards supported by Imagination in the future. Signed-off-by: Paul Burton paul.bur...@imgtec.com Will the board still work in QEMU? Best regards, Marek Vasut Yes. It doesn't work in current QEMU master either with or without this series, but it works in older QEMU releases (v1.5.3 for example). OK, nice, thanks! Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] usb: dfu: make nand upload working
Dear Bo Shen, Hi Heiko, On 11/11/2013 02:46 PM, Heiko Schocher wrote: Hello Lukasz, Am 08.11.2013 16:41, schrieb Lukasz Majewski: Hi Bo, Nowhere pass a value to len, which always 0, make no transfer which cause uploading failed. This patch make nand upload working. However it needs enough malloc buffer to store read data, that means the buffer at least equal to the upload partition size, or else it doesn't work. Signed-off-by: Bo Shenvoice.s...@atmel.com I would kindly ask some users of NAND part of the DFU (Tom, Heiko) to test if this change doesn't break anything. I sent a tested-by for this patch, see: http://lists.denx.de/pipermail/u-boot/2013-November/166552.html without this patch nand upload didn;t worked on the rut board, with this patch it worked :-) Thanks for testing it. Thanks guys, PR is already on it's way to mainline. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 16/18] malta: setup PIIX4 interrupt route
Dear Paul Burton, On 10/11/13 20:09, Marek Vasut wrote: Dear Paul Burton, Without setting up the PIRQ[A:D] interrupt routes, PCI interrupts will be left disabled. Linux does not set up this routing but relies upon it having been set up by the bootloader, reading back the IRQ lines which the PIRQ[A:D] signals have been routed to. Did you also submit a fix to Linux guys? Best regards, Marek Vasut No, I haven't. Although Linux is reliant upon these values having been programmed it's quite clear from reading its code that that depence is intentional. It explicitely reads the route setup by the bootloader rather than clobbering it, and to me that does make sense in this case. Can this setup not be passed via a well-designed DT binding then? However the pcnet32 ethernet driver seems to be reliant upon the interrupt and doesn't handle the case of a PCI device with no assigned interrupt, so I'll send a patch to fail its probe in that case shortly. Thanks! Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 10/18] malta: display U-boot on the LCD screen
Dear Paul Burton,
On 10/11/13 20:08, Marek Vasut wrote:
Dear Paul Burton,
Displaying a message on the LCD screen is a simple yet effective way to
show the user that the board has booted successfully.
Signed-off-by: Paul Burton paul.bur...@imgtec.com
---
Changes in v3:
- rebase atop master
Changes in v2:
- rebased after malta moved to board/imgtec/malta
---
arch/mips/include/asm/malta.h | 10 ++
board/imgtec/malta/malta.c| 19 +++
2 files changed, 29 insertions(+)
diff --git a/arch/mips/include/asm/malta.h
b/arch/mips/include/asm/malta.h index 0b50a66..d8ec57c 100644
--- a/arch/mips/include/asm/malta.h
+++ b/arch/mips/include/asm/malta.h
@@ -32,6 +32,16 @@
#define MALTA_MSC01_PCIIO_MAP0x
#define MALTA_MSC01_UART0_BASE (MALTA_MSC01_PCIIO_BASE +
0x3f8)
+#define MALTA_ASCIIWORD 0x1f000410
+#define MALTA_ASCIIPOS0 0x1f000418
+#define MALTA_ASCIIPOS1 0x1f000420
+#define MALTA_ASCIIPOS2 0x1f000428
+#define MALTA_ASCIIPOS3 0x1f000430
+#define MALTA_ASCIIPOS4 0x1f000438
+#define MALTA_ASCIIPOS5 0x1f000440
+#define MALTA_ASCIIPOS6 0x1f000448
+#define MALTA_ASCIIPOS7 0x1f000450
+
#define MALTA_RESET_BASE 0x1f000500
#define GORESET 0x42
diff --git a/board/imgtec/malta/malta.c b/board/imgtec/malta/malta.c
index 2af0067..119546a 100644
--- a/board/imgtec/malta/malta.c
+++ b/board/imgtec/malta/malta.c
@@ -29,6 +29,24 @@ enum sys_con {
SYSCON_MSC01,
};
+static void malta_lcd_puts(const char *str)
+{
+ int i;
+ void *reg = (void *)CKSEG1ADDR(MALTA_ASCIIPOS0);
+
+ /* print up to 8 characters of the string */
+ for (i = 0; i min(strlen(str), 8); i++) {
+ __raw_writel(str[i], reg);
+ reg += MALTA_ASCIIPOS1 - MALTA_ASCIIPOS0;
+ }
+
+ /* fill the rest of the display with spaces */
+ for (; i 8; i++) {
+ __raw_writel(' ', reg);
+ reg += MALTA_ASCIIPOS1 - MALTA_ASCIIPOS0;
+ }
+}
+
static enum core_card malta_core_card(void)
{
u32 corid, rev;
@@ -71,6 +89,7 @@ int checkboard(void)
{
enum core_card core;
+ malta_lcd_puts(U-boot);
puts(Board: MIPS Malta);
core = malta_core_card();
Can this not be implemented as a regular framebuffer console maybe?
Best regards,
Marek Vasut
We're talking about an 8 character segmented LCD display here - it's not
something you can draw (non-ASCII) graphics on, nor something you want
to be interacting with even if you hooked up some input.
Oh OK, I see.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] ARM: OMAP5: Add Pipe3 PHY driver
On Thu, Nov 07, 2013 at 02:23:32PM +0200, Roger Quadros wrote: On 11/06/2013 11:48 PM, Tom Rini wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/06/2013 09:47 AM, Roger Quadros wrote: Pipe3 PHY is used by SATA, USB3 and PCIe modules. This is a driver for the Pipe3 PHY. Signed-off-by: Roger Quadros rog...@ti.com [snip] +#define perror(fmt, args...) printf(%s: fmt, __func__ , ##args) Please use the debug macro. But I want the message to be printed and not hidden if DEBUG is not defined. Then just call printf please. Or is this kernel-adapted code? [snip[ + perror(%s: No DPLL configuration for %u Hz SYS CLK\n, + __func__, rate); Indent is wrong, we do like the kernel (and checkpatch.pl is in tools/ and will catch these). Thanks. you mean the function arguments '__func__' and 'rate' should be on the same line where perror is? perror(\n, __func_, ...); -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/8] ahci: Fix cache align error messages
On Mon, Nov 11, 2013 at 03:31:16PM +0200, Roger Quadros wrote:
Align the ATA ID buffer to the cache-line boundary. This gets rid
of the below error mesages on ARM v7 platforms.
scanning bus for devices...
ERROR: v7_dcache_inval_range - start address is not aligned - 0xfee48618
ERROR: v7_dcache_inval_range - stop address is not aligned - 0xfee48818
CC: Aneesh V ane...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/block/ahci.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/block/ahci.c b/drivers/block/ahci.c
index e24d634..e64df4f 100644
--- a/drivers/block/ahci.c
+++ b/drivers/block/ahci.c
@@ -623,7 +623,7 @@ static int ata_scsiop_inquiry(ccb *pccb)
95 - 4,
};
u8 fis[20];
- u16 *tmpid;
+ ALLOC_CACHE_ALIGN_BUFFER(u16, tmpid, ATA_ID_WORDS);
[snip]
- tmpid = malloc(ATA_ID_WORDS * 2);
- if (!tmpid) {
- printf(%s: No memory for tmpid\n, __func__);
- return -ENOMEM;
- }
if (ahci_device_data_io(port, (u8 *) fis, sizeof(fis), (u8 *)tmpid,
ATA_ID_WORDS * 2, 0)) {
We should be calling ALLOC_CACHE_ALIGN_BUFFER with ATA_ID_WORDS * 2,
right?
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/8] ahci: Fix cache align error messages
On 11/11/2013 03:56 PM, Tom Rini wrote:
On Mon, Nov 11, 2013 at 03:31:16PM +0200, Roger Quadros wrote:
Align the ATA ID buffer to the cache-line boundary. This gets rid
of the below error mesages on ARM v7 platforms.
scanning bus for devices...
ERROR: v7_dcache_inval_range - start address is not aligned - 0xfee48618
ERROR: v7_dcache_inval_range - stop address is not aligned - 0xfee48818
CC: Aneesh V ane...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/block/ahci.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/block/ahci.c b/drivers/block/ahci.c
index e24d634..e64df4f 100644
--- a/drivers/block/ahci.c
+++ b/drivers/block/ahci.c
@@ -623,7 +623,7 @@ static int ata_scsiop_inquiry(ccb *pccb)
95 - 4,
};
u8 fis[20];
-u16 *tmpid;
+ALLOC_CACHE_ALIGN_BUFFER(u16, tmpid, ATA_ID_WORDS);
[snip]
-tmpid = malloc(ATA_ID_WORDS * 2);
-if (!tmpid) {
-printf(%s: No memory for tmpid\n, __func__);
-return -ENOMEM;
-}
if (ahci_device_data_io(port, (u8 *) fis, sizeof(fis), (u8 *)tmpid,
ATA_ID_WORDS * 2, 0)) {
We should be calling ALLOC_CACHE_ALIGN_BUFFER with ATA_ID_WORDS * 2,
right?
No, as is u16.
cheers,
-roger
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] ARM: OMAP5: Add Pipe3 PHY driver
On 11/11/2013 03:52 PM, Tom Rini wrote: On Thu, Nov 07, 2013 at 02:23:32PM +0200, Roger Quadros wrote: On 11/06/2013 11:48 PM, Tom Rini wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/06/2013 09:47 AM, Roger Quadros wrote: Pipe3 PHY is used by SATA, USB3 and PCIe modules. This is a driver for the Pipe3 PHY. Signed-off-by: Roger Quadros rog...@ti.com [snip] +#define perror(fmt, args...) printf(%s: fmt, __func__ , ##args) Please use the debug macro. But I want the message to be printed and not hidden if DEBUG is not defined. Then just call printf please. Or is this kernel-adapted code? OK. No this isn't in the kernel. [snip[ + perror(%s: No DPLL configuration for %u Hz SYS CLK\n, + __func__, rate); Indent is wrong, we do like the kernel (and checkpatch.pl is in tools/ and will catch these). Thanks. you mean the function arguments '__func__' and 'rate' should be on the same line where perror is? perror(\n, __func_, ...); OK. I'll wait some more time for comments on v2 before I send out a v3 with these changes. cheers, -roger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/8] SATA support for omap5_uevm and dra7_evm
On Mon, Nov 11, 2013 at 03:31:14PM +0200, Roger Quadros wrote: Hi, This series adds SATA support for OMAP5 uevm and DRA7 evm. Patches are also availabe at g...@github.com:rogerq/u-boot.gitsata v2: - Address review comments in the RFC series - Fix cache align error in the ahci driver - Added dra7 support Please run ./tools/checkpatch.pl over the series and correct the issues there, thanks. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 16/18] malta: setup PIIX4 interrupt route
On 11/11/13 13:33, Marek Vasut wrote: Dear Paul Burton, On 10/11/13 20:09, Marek Vasut wrote: Dear Paul Burton, Without setting up the PIRQ[A:D] interrupt routes, PCI interrupts will be left disabled. Linux does not set up this routing but relies upon it having been set up by the bootloader, reading back the IRQ lines which the PIRQ[A:D] signals have been routed to. Did you also submit a fix to Linux guys? Best regards, Marek Vasut No, I haven't. Although Linux is reliant upon these values having been programmed it's quite clear from reading its code that that depence is intentional. It explicitely reads the route setup by the bootloader rather than clobbering it, and to me that does make sense in this case. Can this setup not be passed via a well-designed DT binding then? I'm sure the information could be passed via DT but the Malta board currently doesn't use DT at all either in Linux or U-boot, and I don't have the time right now to convert them both to DT. However the pcnet32 ethernet driver seems to be reliant upon the interrupt and doesn't handle the case of a PCI device with no assigned interrupt, so I'll send a patch to fail its probe in that case shortly. Thanks! Best regards, Marek Vasut Thanks, Paul ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 16/18] malta: setup PIIX4 interrupt route
Dear Paul Burton, On 11/11/13 13:33, Marek Vasut wrote: Dear Paul Burton, On 10/11/13 20:09, Marek Vasut wrote: Dear Paul Burton, Without setting up the PIRQ[A:D] interrupt routes, PCI interrupts will be left disabled. Linux does not set up this routing but relies upon it having been set up by the bootloader, reading back the IRQ lines which the PIRQ[A:D] signals have been routed to. Did you also submit a fix to Linux guys? Best regards, Marek Vasut No, I haven't. Although Linux is reliant upon these values having been programmed it's quite clear from reading its code that that depence is intentional. It explicitely reads the route setup by the bootloader rather than clobbering it, and to me that does make sense in this case. Can this setup not be passed via a well-designed DT binding then? I'm sure the information could be passed via DT but the Malta board currently doesn't use DT at all either in Linux or U-boot, and I don't have the time right now to convert them both to DT. That's unfortunate, but OK. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [mips] malta configuration works in qemu-1.5 does not in qemu-1.6
2013.11.11. 12:14 keltezéssel, Paul Burton írta: ... Aha, thanks for tracking that down. I guess if flash commands need to work at 0x1fc0 I assume that it is working on a real Malta board, so it should be emulated correctly if possible. then my QEMU patch fixed one bug but causes another... Correct, it was working in previous versions. I'll try to find the time to fix that in QEMU soon. Thanks in advance! BTW, I have just found another weird thing in qemu 1.6.x. Pressing Ctrl+C in U-Boot terminates qemu: U-Boot 2013.10-00270-g4a45abb (Nov 11 2013 - 11:34:34) Board: MIPS Malta CoreLV DRAM: 256 MiB Flash: 4 MiB *** Warning - bad CRC, using default environment In:serial Out: serial Err: serial Net: pcnet#0 Warning: pcnet#0 using MAC address from net device malta # qemu: terminating on signal 2 With older versions of qemu it works correctly: U-Boot 2013.10-00270-g4a45abb (Nov 11 2013 - 11:34:34) Board: MIPS Malta CoreLV DRAM: 256 MiB Flash: 4 MiB *** Warning - bad CRC, using default environment In:serial Out: serial Err: serial Net: pcnet#0 Warning: pcnet#0 using MAC address from net device malta # INTERRUPT malta # I did not have time to track it down yet. -Gabor ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] malta: use unmapped flash base address
The physical base address of the NOR flash is 0x1e00 on the Malta boards. The hardware also maps the first 4MiB of the flash into the 0x1fc0-0x1fff range. Currently, U-Boot uses the mapped address to access the flash, which does not work in recent qemu versions. Since commit a427338b222b43197c2776cbc996936df0302f51 (mips_malta: correct reading MIPS revision at 0x1fc00010) writing to the mapped address space causes a CPU exception. Due to the exception, U-Boot hangs during boot when it tries to detect the CFI flash chip. Use the correct physical address for the MALTA_FLASH_BASE constant to avoid the problem. The change makes it possible to start U-Boot on a Malta board emulated with Qemu 1.6.1 and 1.7.0-rc0. It also works on older versions (tested with 1.1.1, 1.2.2, 1.4.2, 1.5.3). The change is not tested on a real Malta board. Signed-off-by: Gabor Juhos juh...@openwrt.org Cc: Daniel Schwierzeck daniel.schwierz...@gmail.com Cc: Paul Burton paul.bur...@imgtec.com --- arch/mips/include/asm/malta.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/mips/include/asm/malta.h b/arch/mips/include/asm/malta.h index 9b1100b..bd9043d 100644 --- a/arch/mips/include/asm/malta.h +++ b/arch/mips/include/asm/malta.h @@ -44,7 +44,7 @@ #define MALTA_RESET_BASE 0x1f000500 #define GORESET0x42 -#define MALTA_FLASH_BASE 0x1fc0 +#define MALTA_FLASH_BASE 0x1e00 #define MALTA_REVISION 0x1fc00010 #define MALTA_REVISION_CORID_SHF 10 -- 1.7.10 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] malta: use unmapped flash base address
On 11/11/13 14:05, Gabor Juhos wrote: The physical base address of the NOR flash is 0x1e00 on the Malta boards. The hardware also maps the first 4MiB of the flash into the 0x1fc0-0x1fff range. Currently, U-Boot uses the mapped address to access the flash, which does not work in recent qemu versions. Since commit a427338b222b43197c2776cbc996936df0302f51 (mips_malta: correct reading MIPS revision at 0x1fc00010) writing to the mapped address space causes a CPU exception. Due to the exception, U-Boot hangs during boot when it tries to detect the CFI flash chip. Use the correct physical address for the MALTA_FLASH_BASE constant to avoid the problem. The change makes it possible to start U-Boot on a Malta board emulated with Qemu 1.6.1 and 1.7.0-rc0. It also works on older versions (tested with 1.1.1, 1.2.2, 1.4.2, 1.5.3). The change is not tested on a real Malta board. Signed-off-by: Gabor Juhos juh...@openwrt.org Cc: Daniel Schwierzeck daniel.schwierz...@gmail.com Cc: Paul Burton paul.bur...@imgtec.com --- arch/mips/include/asm/malta.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/mips/include/asm/malta.h b/arch/mips/include/asm/malta.h index 9b1100b..bd9043d 100644 --- a/arch/mips/include/asm/malta.h +++ b/arch/mips/include/asm/malta.h @@ -44,7 +44,7 @@ #define MALTA_RESET_BASE 0x1f000500 #define GORESET 0x42 -#define MALTA_FLASH_BASE 0x1fc0 +#define MALTA_FLASH_BASE 0x1e00 #define MALTA_REVISION0x1fc00010 #define MALTA_REVISION_CORID_SHF 10 Hmm, this does run on a real Malta but it takes around a minute to run relocate_code... With the 0x1fc0 base address it's much faster. I'll see if I can figure out why... Paul ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 3/8] ARM: OMAP5: Add Pipe3 PHY driver
Pipe3 PHY is used by SATA, USB3 and PCIe modules. This is
a driver for the Pipe3 PHY.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/cpu/armv7/omap-common/Makefile| 4 +
arch/arm/cpu/armv7/omap-common/pipe3-phy.c | 231 +
arch/arm/cpu/armv7/omap-common/pipe3-phy.h | 36 +
3 files changed, 271 insertions(+)
create mode 100644 arch/arm/cpu/armv7/omap-common/pipe3-phy.c
create mode 100644 arch/arm/cpu/armv7/omap-common/pipe3-phy.h
diff --git a/arch/arm/cpu/armv7/omap-common/Makefile
b/arch/arm/cpu/armv7/omap-common/Makefile
index 4d3a165..bfaf814 100644
--- a/arch/arm/cpu/armv7/omap-common/Makefile
+++ b/arch/arm/cpu/armv7/omap-common/Makefile
@@ -17,6 +17,10 @@ obj-y+= vc.o
obj-y += abb.o
endif
+ifneq ($(CONFIG_OMAP54XX),)
+COBJS += pipe3-phy.o
+endif
+
ifeq ($(CONFIG_OMAP34XX),)
obj-y += boot-common.o
obj-y += lowlevel_init.o
diff --git a/arch/arm/cpu/armv7/omap-common/pipe3-phy.c
b/arch/arm/cpu/armv7/omap-common/pipe3-phy.c
new file mode 100644
index 000..b71d769
--- /dev/null
+++ b/arch/arm/cpu/armv7/omap-common/pipe3-phy.c
@@ -0,0 +1,231 @@
+/*
+ * TI PIPE3 PHY
+ *
+ * (C) Copyright 2013
+ * Texas Instruments, www.ti.com
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include common.h
+#include sata.h
+#include asm/arch/clock.h
+#include asm/arch/sys_proto.h
+#include asm/io.h
+#include asm/errno.h
+#include pipe3-phy.h
+
+/* PLLCTRL Registers */
+#define PLL_STATUS 0x0004
+#define PLL_GO 0x0008
+#define PLL_CONFIGURATION1 0x000C
+#define PLL_CONFIGURATION2 0x0010
+#define PLL_CONFIGURATION3 0x0014
+#define PLL_CONFIGURATION4 0x0020
+
+#define PLL_REGM_MASK 0x001FFE00
+#define PLL_REGM_SHIFT 9
+#define PLL_REGM_F_MASK 0x0003
+#define PLL_REGM_F_SHIFT0
+#define PLL_REGN_MASK 0x01FE
+#define PLL_REGN_SHIFT 1
+#define PLL_SELFREQDCO_MASK 0x000E
+#define PLL_SELFREQDCO_SHIFT1
+#define PLL_SD_MASK 0x0003FC00
+#define PLL_SD_SHIFT10
+#define SET_PLL_GO 0x1
+#define PLL_TICOPWDNBIT(16)
+#define PLL_LDOPWDN BIT(15)
+#define PLL_LOCK0x2
+#define PLL_IDLE0x1
+
+/* PHY POWER CONTROL Register */
+#define OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_CMD_MASK 0x003FC000
+#define OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_CMD_SHIFT0xE
+
+#define OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_FREQ_MASK0xFFC0
+#define OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_FREQ_SHIFT 0x16
+
+#define OMAP_CTRL_PIPE3_PHY_TX_RX_POWERON 0x3
+#define OMAP_CTRL_PIPE3_PHY_TX_RX_POWEROFF 0x0
+
+
+#define PLL_IDLE_TIME 100 /* in milliseconds */
+#define PLL_LOCK_TIME 100 /* in milliseconds */
+
+static inline u32 omap_pipe3_readl(void __iomem *addr, unsigned offset)
+{
+ return __raw_readl(addr + offset);
+}
+
+static inline void omap_pipe3_writel(void __iomem *addr, unsigned offset,
+ u32 data)
+{
+ __raw_writel(data, addr + offset);
+}
+
+static struct pipe3_dpll_params *omap_pipe3_get_dpll_params(struct omap_pipe3
+ *pipe3)
+{
+ u32 rate;
+ struct pipe3_dpll_map *dpll_map = pipe3-dpll_map;
+
+ rate = get_sys_clk_freq();
+
+ for (; dpll_map-rate; dpll_map++) {
+ if (rate == dpll_map-rate)
+ return dpll_map-params;
+ }
+
+ printf(%s: No DPLL configuration for %u Hz SYS CLK\n,
+ __func__, rate);
+ return NULL;
+}
+
+
+static int omap_pipe3_wait_lock(struct omap_pipe3 *phy)
+{
+ u32 val;
+ int timeout = PLL_LOCK_TIME;
+
+ do {
+ mdelay(1);
+ val = omap_pipe3_readl(phy-pll_ctrl_base, PLL_STATUS);
+ if (val PLL_LOCK)
+ break;
+ } while (--timeout);
+
+ if (!(val PLL_LOCK)) {
+ printf(%s: DPLL failed to lock\n, __func__);
+ return -EBUSY;
+ }
+
+ return 0;
+}
+
+static int omap_pipe3_dpll_program(struct omap_pipe3 *phy)
+{
+ u32 val;
+ struct pipe3_dpll_params *dpll_params;
+
+ dpll_params = omap_pipe3_get_dpll_params(phy);
+ if (!dpll_params) {
+ printf(%s: Invalid DPLL parameters\n, __func__);
+ return -EINVAL;
+ }
+
+ val = omap_pipe3_readl(phy-pll_ctrl_base, PLL_CONFIGURATION1);
+ val = ~PLL_REGN_MASK;
+ val |= dpll_params-n PLL_REGN_SHIFT;
+ omap_pipe3_writel(phy-pll_ctrl_base, PLL_CONFIGURATION1, val);
+
+ val = omap_pipe3_readl(phy-pll_ctrl_base, PLL_CONFIGURATION2);
+ val = ~PLL_SELFREQDCO_MASK;
+ val |= dpll_params-freq PLL_SELFREQDCO_SHIFT;
+ omap_pipe3_writel(phy-pll_ctrl_base, PLL_CONFIGURATION2, val);
+
+ val = omap_pipe3_readl(phy-pll_ctrl_base,
[U-Boot] [PATCH v3 0/8] SATA support for omap5_uevm and dra7_evm
Hi, This series adds SATA support for OMAP5 uevm and DRA7 evm. Patches are also availabe at g...@github.com:rogerq/u-boot.git sata v3: - get rid of custom perror() macro, use printf - Fixed coding sytle issues v2: - Address review comments in the RFC series - Fix cache align error in the ahci driver - Added dra7 support cheers, -roger Roger Quadros (8): ahci: Error out with message on malloc() failure ahci: Fix cache align error messages ARM: OMAP5: Add Pipe3 PHY driver ARM: OMAP5: Add PRCM and Control information for SATA ARM: OMAP5: Add SATA platform glue ARM: omap5_uevm: Add SATA support ARM: DRA7xx: Add PRCM and Control information for SATA ARM: dra7_evm: Add SATA support arch/arm/cpu/armv7/omap-common/Makefile| 5 + arch/arm/cpu/armv7/omap-common/pipe3-phy.c | 231 + arch/arm/cpu/armv7/omap-common/pipe3-phy.h | 36 + arch/arm/cpu/armv7/omap-common/sata.c | 75 ++ arch/arm/cpu/armv7/omap5/prcm-regs.c | 7 + arch/arm/include/asm/arch-omap5/clock.h| 3 + arch/arm/include/asm/arch-omap5/omap.h | 3 + arch/arm/include/asm/arch-omap5/sata.h | 48 ++ arch/arm/include/asm/omap_common.h | 2 + board/ti/dra7xx/evm.c | 7 + board/ti/omap5_uevm/evm.c | 7 + drivers/block/ahci.c | 18 ++- include/configs/dra7xx_evm.h | 11 ++ include/configs/omap5_uevm.h | 10 ++ 14 files changed, 457 insertions(+), 6 deletions(-) create mode 100644 arch/arm/cpu/armv7/omap-common/pipe3-phy.c create mode 100644 arch/arm/cpu/armv7/omap-common/pipe3-phy.h create mode 100644 arch/arm/cpu/armv7/omap-common/sata.c create mode 100644 arch/arm/include/asm/arch-omap5/sata.h -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 1/8] ahci: Error out with message on malloc() failure
If malloc() fails, we don't want to continue in ahci_init() and
ahci_init_one(). Also print a more informative error message on
malloc() failures.
CC: Rob Herring rob.herr...@calxeda.com
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/block/ahci.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/block/ahci.c b/drivers/block/ahci.c
index 0daad36..e24d634 100644
--- a/drivers/block/ahci.c
+++ b/drivers/block/ahci.c
@@ -379,6 +379,11 @@ static int ahci_init_one(pci_dev_t pdev)
int rc;
probe_ent = malloc(sizeof(struct ahci_probe_ent));
+ if (!probe_ent) {
+ printf(%s: No memory for probe_ent\n, __func__);
+ return -ENOMEM;
+ }
+
memset(probe_ent, 0, sizeof(struct ahci_probe_ent));
probe_ent-dev = pdev;
@@ -503,7 +508,7 @@ static int ahci_port_start(u8 port)
mem = (u32) malloc(AHCI_PORT_PRIV_DMA_SZ + 2048);
if (!mem) {
free(pp);
- printf(No mem for table!\n);
+ printf(%s: No mem for table!\n, __func__);
return -ENOMEM;
}
@@ -638,8 +643,10 @@ static int ata_scsiop_inquiry(ccb *pccb)
/* Read id from sata */
port = pccb-target;
tmpid = malloc(ATA_ID_WORDS * 2);
- if (!tmpid)
+ if (!tmpid) {
+ printf(%s: No memory for tmpid\n, __func__);
return -ENOMEM;
+ }
if (ahci_device_data_io(port, (u8 *) fis, sizeof(fis), (u8 *)tmpid,
ATA_ID_WORDS * 2, 0)) {
@@ -889,6 +896,11 @@ int ahci_init(u32 base)
u32 linkmap;
probe_ent = malloc(sizeof(struct ahci_probe_ent));
+ if (!probe_ent) {
+ printf(%s: No memory for probe_ent\n, __func__);
+ return -ENOMEM;
+ }
+
memset(probe_ent, 0, sizeof(struct ahci_probe_ent));
probe_ent-host_flags = ATA_FLAG_SATA
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 2/8] ahci: Fix cache align error messages
Align the ATA ID buffer to the cache-line boundary. This gets rid
of the below error mesages on ARM v7 platforms.
scanning bus for devices...
ERROR: v7_dcache_inval_range - start address is not aligned - 0xfee48618
ERROR: v7_dcache_inval_range - stop address is not aligned - 0xfee48818
CC: Aneesh V ane...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/block/ahci.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/block/ahci.c b/drivers/block/ahci.c
index e24d634..e64df4f 100644
--- a/drivers/block/ahci.c
+++ b/drivers/block/ahci.c
@@ -623,7 +623,7 @@ static int ata_scsiop_inquiry(ccb *pccb)
95 - 4,
};
u8 fis[20];
- u16 *tmpid;
+ ALLOC_CACHE_ALIGN_BUFFER(u16, tmpid, ATA_ID_WORDS);
u8 port;
/* Clean ccb data buffer */
@@ -642,16 +642,10 @@ static int ata_scsiop_inquiry(ccb *pccb)
/* Read id from sata */
port = pccb-target;
- tmpid = malloc(ATA_ID_WORDS * 2);
- if (!tmpid) {
- printf(%s: No memory for tmpid\n, __func__);
- return -ENOMEM;
- }
if (ahci_device_data_io(port, (u8 *) fis, sizeof(fis), (u8 *)tmpid,
ATA_ID_WORDS * 2, 0)) {
debug(scsi_ahci: SCSI inquiry command failure.\n);
- free(tmpid);
return -EIO;
}
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 6/8] ARM: omap5_uevm: Add SATA support
The uevm has a SATA port. Inititialize the SATA controller.
Signed-off-by: Roger Quadros rog...@ti.com
---
board/ti/omap5_uevm/evm.c| 7 +++
include/configs/omap5_uevm.h | 10 ++
2 files changed, 17 insertions(+)
diff --git a/board/ti/omap5_uevm/evm.c b/board/ti/omap5_uevm/evm.c
index bb3a699..af854da 100644
--- a/board/ti/omap5_uevm/evm.c
+++ b/board/ti/omap5_uevm/evm.c
@@ -20,6 +20,7 @@
#include asm/arch/clock.h
#include asm/arch/ehci.h
#include asm/ehci-omap.h
+#include asm/arch/sata.h
#define DIE_ID_REG_BASE (OMAP54XX_L4_CORE_BASE + 0x2000)
#define DIE_ID_REG_OFFSET 0x200
@@ -67,6 +68,12 @@ int board_init(void)
return 0;
}
+int board_late_init(void)
+{
+ omap_sata_init();
+ return 0;
+}
+
int board_eth_init(bd_t *bis)
{
return 0;
diff --git a/include/configs/omap5_uevm.h b/include/configs/omap5_uevm.h
index 4d3a800..2f128b8 100644
--- a/include/configs/omap5_uevm.h
+++ b/include/configs/omap5_uevm.h
@@ -69,4 +69,14 @@
/* Max time to hold reset on this board, see doc/README.omap-reset-time */
#define CONFIG_OMAP_PLATFORM_RESET_TIME_MAX_USEC 16296
+#define CONFIG_BOARD_LATE_INIT
+#define CONFIG_CMD_SCSI
+#define CONFIG_LIBATA
+#define CONFIG_SCSI_AHCI
+#define CONFIG_SCSI_AHCI_PLAT
+#define CONFIG_SYS_SCSI_MAX_SCSI_ID1
+#define CONFIG_SYS_SCSI_MAX_LUN1
+#define CONFIG_SYS_SCSI_MAX_DEVICE (CONFIG_SYS_SCSI_MAX_SCSI_ID * \
+ CONFIG_SYS_SCSI_MAX_LUN)
+
#endif /* __CONFIG_OMAP5_EVM_H */
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 4/8] ARM: OMAP5: Add PRCM and Control information for SATA
Adds the necessary PRCM and Control register information for
SATA on OMAP5.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/cpu/armv7/omap5/prcm-regs.c| 4
arch/arm/include/asm/arch-omap5/clock.h | 3 +++
arch/arm/include/asm/arch-omap5/omap.h | 3 +++
arch/arm/include/asm/omap_common.h | 2 ++
4 files changed, 12 insertions(+)
diff --git a/arch/arm/cpu/armv7/omap5/prcm-regs.c
b/arch/arm/cpu/armv7/omap5/prcm-regs.c
index 304ac1c..5c60d74 100644
--- a/arch/arm/cpu/armv7/omap5/prcm-regs.c
+++ b/arch/arm/cpu/armv7/omap5/prcm-regs.c
@@ -203,8 +203,10 @@ struct prcm_regs const omap5_es1_prcm = {
.cm_l3init_hsusbotg_clkctrl = 0x4a009360,
.cm_l3init_hsusbtll_clkctrl = 0x4a009368,
.cm_l3init_p1500_clkctrl = 0x4a009378,
+ .cm_l3init_sata_clkctrl = 0x4a009388,
.cm_l3init_fsusb_clkctrl = 0x4a0093d0,
.cm_l3init_ocp2scp1_clkctrl = 0x4a0093e0,
+ .cm_l3init_ocp2scp3_clkctrl = 0x4a0093e8,
/* cm2.l4per */
.cm_l4per_clkstctrl = 0x4a009400,
@@ -296,6 +298,7 @@ struct omap_sys_ctrl_regs const omap5_ctrl = {
.control_status = 0x4A002134,
.control_std_fuse_opp_vdd_mpu_2 = 0x4A0021B4,
.control_phy_power_usb = 0x4A002370,
+ .control_phy_power_sata = 0x4A002374,
.control_padconf_core_base = 0x4A002800,
.control_paconf_global = 0x4A002DA0,
.control_paconf_mode= 0x4A002DA4,
@@ -698,6 +701,7 @@ struct prcm_regs const omap5_es2_prcm = {
.cm_l3init_hsusbotg_clkctrl = 0x4a009660,
.cm_l3init_hsusbtll_clkctrl = 0x4a009668,
.cm_l3init_p1500_clkctrl = 0x4a009678,
+ .cm_l3init_sata_clkctrl = 0x4a009688,
.cm_l3init_fsusb_clkctrl = 0x4a0096d0,
.cm_l3init_ocp2scp1_clkctrl = 0x4a0096e0,
.cm_l3init_ocp2scp3_clkctrl = 0x4a0096e8,
diff --git a/arch/arm/include/asm/arch-omap5/clock.h
b/arch/arm/include/asm/arch-omap5/clock.h
index 8869b50..2dfe4ef 100644
--- a/arch/arm/include/asm/arch-omap5/clock.h
+++ b/arch/arm/include/asm/arch-omap5/clock.h
@@ -137,6 +137,9 @@
#define HSMMC_CLKCTRL_CLKSEL_MASK (1 24)
#define HSMMC_CLKCTRL_CLKSEL_DIV_MASK (1 25)
+/* CM_L3INIT_SATA_CLKCTRL */
+#define SATA_CLKCTRL_OPTFCLKEN_MASK(1 8)
+
/* CM_WKUP_GPTIMER1_CLKCTRL */
#define GPTIMER1_CLKCTRL_CLKSEL_MASK (1 24)
diff --git a/arch/arm/include/asm/arch-omap5/omap.h
b/arch/arm/include/asm/arch-omap5/omap.h
index 414d37a..150db0f 100644
--- a/arch/arm/include/asm/arch-omap5/omap.h
+++ b/arch/arm/include/asm/arch-omap5/omap.h
@@ -64,6 +64,9 @@
/* QSPI */
#define QSPI_BASE 0x4B30
+/* SATA */
+#define DWC_AHSATA_BASE0x4A14
+
/*
* Hardware Register Details
*/
diff --git a/arch/arm/include/asm/omap_common.h
b/arch/arm/include/asm/omap_common.h
index 8a395e8..382da90 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -226,6 +226,7 @@ struct prcm_regs {
u32 cm_l3init_hsusbotg_clkctrl;
u32 cm_l3init_hsusbtll_clkctrl;
u32 cm_l3init_p1500_clkctrl;
+ u32 cm_l3init_sata_clkctrl;
u32 cm_l3init_fsusb_clkctrl;
u32 cm_l3init_ocp2scp1_clkctrl;
u32 cm_l3init_ocp2scp3_clkctrl;
@@ -366,6 +367,7 @@ struct omap_sys_ctrl_regs {
u32 control_ldosram_mpu_voltage_ctrl;
u32 control_ldosram_core_voltage_ctrl;
u32 control_usbotghs_ctrl;
+ u32 control_phy_power_sata;
u32 control_padconf_core_base;
u32 control_paconf_global;
u32 control_paconf_mode;
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 8/8] ARM: dra7_evm: Add SATA support
The evm has a SATA port. Enable SATA configuration and
inititialize the SATA controller.
Signed-off-by: Roger Quadros rog...@ti.com
---
board/ti/dra7xx/evm.c| 7 +++
include/configs/dra7xx_evm.h | 11 +++
2 files changed, 18 insertions(+)
diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
index 9657c75..9ae88c5 100644
--- a/board/ti/dra7xx/evm.c
+++ b/board/ti/dra7xx/evm.c
@@ -14,6 +14,7 @@
#include palmas.h
#include asm/arch/sys_proto.h
#include asm/arch/mmc_host_def.h
+#include asm/arch/sata.h
#include mux_data.h
@@ -77,6 +78,12 @@ int board_init(void)
return 0;
}
+int board_late_init(void)
+{
+ omap_sata_init();
+ return 0;
+}
+
/**
* @brief misc_init_r - Configure EVM board specific configurations
* such as power configurations, ethernet initialization as phase2 of
diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h
index a9f39f2..6fadffb 100644
--- a/include/configs/dra7xx_evm.h
+++ b/include/configs/dra7xx_evm.h
@@ -78,4 +78,15 @@
#define CONFIG_OMAP_USB_PHY
#define CONFIG_OMAP_USB2PHY2_HOST
+/* SATA */
+#define CONFIG_BOARD_LATE_INIT
+#define CONFIG_CMD_SCSI
+#define CONFIG_LIBATA
+#define CONFIG_SCSI_AHCI
+#define CONFIG_SCSI_AHCI_PLAT
+#define CONFIG_SYS_SCSI_MAX_SCSI_ID1
+#define CONFIG_SYS_SCSI_MAX_LUN1
+#define CONFIG_SYS_SCSI_MAX_DEVICE (CONFIG_SYS_SCSI_MAX_SCSI_ID * \
+ CONFIG_SYS_SCSI_MAX_LUN)
+
#endif /* __CONFIG_DRA7XX_EVM_H */
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 7/8] ARM: DRA7xx: Add PRCM and Control information for SATA
Adds the necessary PRCM and Control register information for
SATA on DRA7xx.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/cpu/armv7/omap5/prcm-regs.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/cpu/armv7/omap5/prcm-regs.c
b/arch/arm/cpu/armv7/omap5/prcm-regs.c
index 5c60d74..77c428b 100644
--- a/arch/arm/cpu/armv7/omap5/prcm-regs.c
+++ b/arch/arm/cpu/armv7/omap5/prcm-regs.c
@@ -376,6 +376,7 @@ struct omap_sys_ctrl_regs const omap5_ctrl = {
struct omap_sys_ctrl_regs const dra7xx_ctrl = {
.control_status = 0x4A002134,
+ .control_phy_power_sata = 0x4A002374,
.control_core_mac_id_0_lo = 0x4A002514,
.control_core_mac_id_0_hi = 0x4A002518,
.control_core_mac_id_1_lo = 0x4A00251C,
@@ -895,9 +896,11 @@ struct prcm_regs const dra7xx_prcm = {
.cm_l3init_hsusbhost_clkctrl= 0x4a009340,
.cm_l3init_hsusbotg_clkctrl = 0x4a009348,
.cm_l3init_hsusbtll_clkctrl = 0x4a009350,
+ .cm_l3init_sata_clkctrl = 0x4a009388,
.cm_gmac_clkstctrl = 0x4a0093c0,
.cm_gmac_gmac_clkctrl = 0x4a0093d0,
.cm_l3init_ocp2scp1_clkctrl = 0x4a0093e0,
+ .cm_l3init_ocp2scp3_clkctrl = 0x4a0093e8,
/* cm2.l4per */
.cm_l4per_clkstctrl = 0x4a009700,
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 5/8] ARM: OMAP5: Add SATA platform glue
Add platform glue logic for the SATA controller.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/cpu/armv7/omap-common/Makefile | 1 +
arch/arm/cpu/armv7/omap-common/sata.c | 75 +
arch/arm/include/asm/arch-omap5/sata.h | 48 +
3 files changed, 124 insertions(+)
create mode 100644 arch/arm/cpu/armv7/omap-common/sata.c
create mode 100644 arch/arm/include/asm/arch-omap5/sata.h
diff --git a/arch/arm/cpu/armv7/omap-common/Makefile
b/arch/arm/cpu/armv7/omap-common/Makefile
index bfaf814..679c1a1 100644
--- a/arch/arm/cpu/armv7/omap-common/Makefile
+++ b/arch/arm/cpu/armv7/omap-common/Makefile
@@ -19,6 +19,7 @@ endif
ifneq ($(CONFIG_OMAP54XX),)
COBJS += pipe3-phy.o
+obj-$(CONFIG_SCSI_AHCI_PLAT) += sata.o
endif
ifeq ($(CONFIG_OMAP34XX),)
diff --git a/arch/arm/cpu/armv7/omap-common/sata.c
b/arch/arm/cpu/armv7/omap-common/sata.c
new file mode 100644
index 000..f5468c4
--- /dev/null
+++ b/arch/arm/cpu/armv7/omap-common/sata.c
@@ -0,0 +1,75 @@
+/*
+ * TI SATA platform driver
+ *
+ * (C) Copyright 2013
+ * Texas Instruments, www.ti.com
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include common.h
+#include ahci.h
+#include scsi.h
+#include asm/arch/clock.h
+#include asm/arch/sata.h
+#include asm/io.h
+#include pipe3-phy.h
+
+static struct pipe3_dpll_map dpll_map_sata[] = {
+ {1200, {1000, 7, 4, 6, 0} },/* 12 MHz */
+ {1680, {714, 7, 4, 6, 0} }, /* 16.8 MHz */
+ {1920, {625, 7, 4, 6, 0} }, /* 19.2 MHz */
+ {2000, {600, 7, 4, 6, 0} }, /* 20 MHz */
+ {2600, {461, 7, 4, 6, 0} }, /* 26 MHz */
+ {3840, {312, 7, 4, 6, 0} }, /* 38.4 MHz */
+ { },/* Terminator */
+};
+
+struct omap_pipe3 sata_phy = {
+ .pll_ctrl_base = (void __iomem *)TI_SATA_PLLCTRL_BASE,
+ /* .power_reg is updated at runtime */
+ .dpll_map = dpll_map_sata,
+};
+
+int omap_sata_init(void)
+{
+ int ret;
+ u32 val;
+
+ u32 const clk_domains_sata[] = {
+ 0
+ };
+
+ u32 const clk_modules_hw_auto_sata[] = {
+ (*prcm)-cm_l3init_ocp2scp3_clkctrl,
+ 0
+ };
+
+ u32 const clk_modules_explicit_en_sata[] = {
+ (*prcm)-cm_l3init_sata_clkctrl,
+ 0
+ };
+
+ do_enable_clocks(clk_domains_sata,
+clk_modules_hw_auto_sata,
+clk_modules_explicit_en_sata,
+0);
+
+ /* Enable optional functional clock for SATA */
+ setbits_le32((*prcm)-cm_l3init_sata_clkctrl,
+SATA_CLKCTRL_OPTFCLKEN_MASK);
+
+ sata_phy.power_reg = (void __iomem *)(*ctrl)-control_phy_power_sata;
+
+ /* Power up the PHY */
+ phy_pipe3_power_on(sata_phy);
+
+ /* Enable SATA module, No Idle, No Standby */
+ val = TI_SATA_IDLE_NO | TI_SATA_STANDBY_NO;
+ writel(val, TI_SATA_WRAPPER_BASE + TI_SATA_SYSCONFIG);
+
+ ret = ahci_init(DWC_AHSATA_BASE);
+ scsi_scan(1);
+
+ return ret;
+}
diff --git a/arch/arm/include/asm/arch-omap5/sata.h
b/arch/arm/include/asm/arch-omap5/sata.h
new file mode 100644
index 000..2ca8947
--- /dev/null
+++ b/arch/arm/include/asm/arch-omap5/sata.h
@@ -0,0 +1,48 @@
+/*
+ * SATA Wrapper Register map
+ *
+ * (C) Copyright 2013
+ * Texas Instruments, www.ti.com
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#ifndef _TI_SATA_H
+#define _TI_SATA_H
+
+/* SATA Wrapper module */
+#define TI_SATA_WRAPPER_BASE (OMAP54XX_L4_CORE_BASE + 0x141100)
+/* SATA PHY Module */
+#define TI_SATA_PLLCTRL_BASE (OMAP54XX_L4_CORE_BASE + 0x96800)
+
+/* SATA Wrapper register offsets */
+#define TI_SATA_SYSCONFIG 0x00
+#define TI_SATA_CDRLOCK0x04
+
+/* Register Set */
+#define TI_SATA_SYSCONFIG_OVERRIDE0(1 16)
+#define TI_SATA_SYSCONFIG_STANDBY_MASK (0x3 4)
+#define TI_SATA_SYSCONFIG_IDLE_MASK(0x3 2)
+
+/* Standby modes */
+#define TI_SATA_STANDBY_FORCE 0x0
+#define TI_SATA_STANDBY_NO (0x1 4)
+#define TI_SATA_STANDBY_SMART_WAKE (0x3 4)
+#define TI_SATA_STANDBY_SMART (0x2 4)
+
+/* Idle modes */
+#define TI_SATA_IDLE_FORCE 0x0
+#define TI_SATA_IDLE_NO(0x1 2)
+#define TI_SATA_IDLE_SMART_WAKE(0x3 2)
+#define TI_SATA_IDLE_SMART (0x2 2)
+
+#ifdef CONFIG_SCSI_AHCI_PLAT
+int omap_sata_init(void);
+#else
+static inline int omap_sata_init(void)
+{
+ return 0;
+}
+#endif /* CONFIG_SCSI_AHCI_PLAT */
+
+#endif /* _TI_SATA_H */
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Non-trivial merge conflicts between u-boot/master and u-boot-arm/master
On Sun, Nov 10, 2013 at 06:52:08PM +0100, Gerhard Sittig wrote: On Sat, Nov 09, 2013 at 14:50 -0500, Tom Rini wrote: On Sat, Nov 09, 2013 at 06:49:01PM +0100, Albert ARIBAUD wrote: Which 'not-a-diff-exactly' do you mean? Well, for example 'git show c0bb110' shows how arch/blackfin/cpu/Makefile was merged as a conflict I had to fixup. The ' -' lines are how the blackfin tree was, the ' +' lines are how master was and '- ' is what came out from the blackfin side and '++' is what came in with my resolution (saved to master) (the ' ' lines are common to both). It's not a diff exactly but it's understandable. I would not call it not a diff exactly. Instead I always thought of it as two diffs in one. You get this representation upon 'git diff' in rebase conflicts before they are resolved as well (which are just merges, too). Consider the two first characters on each line as as the diff you introduce (leftmost column) and the diff of the conflicting upstream patch (second column). So you can derive whether your local change follows the upstream's direction (flows with it) or is contrary and needs re-consideration (re-introduces what has gone, or uses what no longer is there). Applying this interpretation to the 'git show c0bb110' you cite above, the upstream does s/COBJ/obj/ (plus some more) for most of the Makefile and you do s/CONFIG_ADI_GPIO1/y/ for gpio.o, while both changes work towards Kbuild style. Does this mental model of mine fit what's happening? Or am I missing something, or misinterpreting? Your mental model fits whats happening as well. I just think of it as not a diff exactly since 'patch' would fail :) -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC] imx: add multi-architecture README
Thanks Tapani,
On 11/11/2013 05:03 AM, Tapani wrote:
Eric,
this documentation is a very good initiative. In overall I agree with what you
have sketched, and it in many ways what we have demonstrated working in
practice.
Yeah. You've already gone through two patch submissions and Troy went
through the same over a year ago with our first submission of Nitrogen6.
It's clear that we need to nail this down and I hope a README will be
easier to work with and a bit lighter than patches.
There are a few question marks I have around your suggestion. Mainly around how
the pinmuxing is suggested to be done.
See the comments inline.
On Sat, 9 Nov 2013 13:12:42 -0700
Eric Nelson eric.nel...@boundarydevices.com wrote:
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
---
doc/README.imx6-multi-arch | 254 +
1 file changed, 254 insertions(+)
create mode 100644 doc/README.imx6-multi-arch
diff --git a/doc/README.imx6-multi-arch b/doc/README.imx6-multi-arch
new file mode 100644
index 000..a31718c
--- /dev/null
+++ b/doc/README.imx6-multi-arch
@@ -0,0 +1,254 @@
+Supporting multiple architectures on Freescale i.MX6
+
+This file describes how to support multiple CPU architectures
+(i.MX6DQ and i.MX6DLS) in a single U-Boot image.
+
+Because memory configuration differs between architectures,
+auto-configuration of DDR is also covered.
+
+1. BACKGROUND
+-
+The Freescale i.MX6 processor family contains four processors which are pin
+compatible. Refer to http://freescale.com/imx6series for details and reference
+manuals, but the highlights from a U-Boot perspective are as follows:
+
+i.MX6Q - Quad core, 64-bit DDR1066, 256K OCRAM
+i.MX6D - Dual core, 64-bit DDR1066, 256K OCRAM
+i.MX6DL- Dual core, 64-bit DDR800, 128K OCRAM
+i.MX6S - Single core, 32-bit DDR800, 128K OCRAM
+
+These processors are also largely register-compatible, but not completely.
+In particular, the IOMUX registers for common functions are in different
+locations and have different selector values.
+
Let's not assume that list supported CPUs is complete yet (and you haven't).
snip
+3. IOMUX declarations
+-
+
+The declarations inside the header files
+ arch/arm/include/asm/arch-mx6/mx6q_pins.h
+and
+ arch/arm/include/asm/arch-mx6/mx6dl_pins.h
+
+are used to configure the pads usage for a particular
+board design.
+
+As mentioned earlier, the register addresses and values
+are different between the 6DQ and 6DLS processor sets,
+and these differences are expressed in two header files:
+
The wording is a little imprecise here :-)
Change the formulation to can be different (unless you know for sure
they can never bee the same, even for the upcoming imx6 models).
The header files contain the padconfigs rather than differences.
Okay.
The two sets of registers are different, but there may be
some which are exactly the same.
+For i.MX6Q and i.MX6D:
+ arch/arm/include/asm/arch-mx6/mx6q_pins.h
+
+and for i.MX6DL and i.MX6S:
+ arch/arm/include/asm/arch-mx6/mx6dls_pins.h
+
+For example, the SD3_DAT2 pad is used for SD card data
+on all currently supported i.MX6 boards.
+
+On i.MX6DQ, this is selected by writing a zero to the
+mux register at address 0x020E02C8. On i.MX6DLS, the
+address is 0x020E031C.
+
+The header files mx6q_pins.h and mx6dls_pins consolidate
+the settings through a macro providing a common name
+of SD3_DAT2__USDHC3_DAT2:
+
+ MX6_PAD_DECL(SD3_DAT2__USDHC3_DAT2,...)
+
+By using the MX6_PAD_DECL macro, this can be expanded
+in one of three ways, depending on the declarations of
+CONFIG_MX6x by a board file. Valid options are:
+
+ MX6Q- single architecture for i.MX6DQ
+ MX6DL - single architecture for i.MX6DL/S
+ MX6QDL - multi-architecture
+
+In the first two cases, the MX6_PAD_DECL macro will
+be expanded into a declararation with the MX6_PAD_
+prefix:
+ MX6_PAD_name = IOMUX_PAD(...)
+
+In the last case, the MX6_PAD_DECL macro will be
+expanded into two sets of declarations, with the
+prefix MX6Q_PAD_ for the i.MX6DQ pads and the
+prefix MX6DL_PAD_ for the i.MX6DLS pads.
+
+This is accomplished by the header file mx6-pins.h:
+
+ #ifdef CONFIG_MX6QDL
+ enum {
+ #define MX6_PAD_DECL ...
+ #include mx6q_pins.h
+
+ #define MX6_PAD_DECL ...
+ #include mx6dl_pins.h
+ };
+ #elif defined(CONFIG_MX6Q)
+ enum {
+ #define MX6_PAD_DECL ...
+ #include mx6q_pins.h
+ };
+ #elif defined(CONFIG_MX6DL)
+ enum {
+ #define MX6_PAD_DECL ...
+ #include mx6dl_pins.h
+ };
+ #endif
+
Opinion: This is a terrible macro kludge to begin with. However, I'm afraid
there
is no solutions completely free macro hacks, but maybe we can have less of them?
Agreed, but I don't see a way around it.
If we want to
Re: [U-Boot] A question about unconfigured pads check in omap24xx_i2c
Hi Nikita,
On 11-Nov-13 13:15, Nikita Kiryanov wrote:
On 11/08/2013 11:26 PM, Lubomir Popov wrote:
Hi Nikita,
On 11/06/2013 03:19 PM, Lubomir Popov wrote:
On 06-Nov-13 14:12, Nikita Kiryanov wrote:
In drivers/i2c/omap24xx_i2c.c there are a few checks that attempt to
detect unconfigured pads for the i2c bus in use. These checks are
all in the form of
if (status == I2C_STAT_XRDY) {
printf(unconfigured pads\n);
return -1;
}
This check seems peculiar to me since the meaning of I2C_STAT_XRDY is
that new data is requested for transmission. Why is that
indication that
the bus is not padconf'd for I2C?
Hi Nikita,
This has been empirically confirmed on OMAP4 and OMAP5. When the pads
are not
configured, the I2C controller is actually disconnected from the bus.
The clock
input for its state machine has to come from the bus however due to
stretching
etc., although it is internally generated. So actually nothing changes
within
the controller after a transaction attempt is made, and it keeps its
initial
state with XRDY set only (ready to accept transmit data). I use
this as an
indicator. Not perfect, but works in most cases.
Regards,
Lubo
Thanks for the quick reply.
The reason I stumbled across this is that this check hasn't been
working
well on our OMAP3 based devices. Some I2C transactions work fine, but
some of them fail this check in the address phase, especially if the
I2C
transactions happen in quick successions.
You mean that you occasionally get this error on an otherwise properly
configured and working bus, right?
Yes.
Does this happen with particular
slave devices only, or randomly? And is it happening in the SPL, or in
regular U-Boot?
It happens in U-Boot when communicating with the PMIC (TPS65930),
but like I said, it worked in the driver's previous version, on the
same module.
We did not have any I2C issues
with the previous driver, and while this behavior is symptomatic of
timing issues playing around with the delays didn't help.
Which delays did you modify? Did you try to increase
I2C_WAIT/I2C_TIMEOUT?
I tried to increase both I2C_WAIT and I2C_TIMEOUT, and place my own
delays as well.
I was wondering if you might have some insights as to what may cause
the
controller to behave this way other than unconfigured pads?
Unfortunately I don't have any hands-on experience with OMAP3 (apart
from
some very quick testing on a AM3359 derivative), and cannot guarantee
that
the I2C controller IP on OMAP3 is absolutely the same as on OMAP4/5
(most
probably it isn't; shall check this on Monday). Anyway, if everything
else
is OK (muxmode/pad config, pull-ups, power, etc.), the only reasonable
explanation would be that there is not enough time for the controller to
update its status register under certain conditions, and these would be
either a slower clock rate (that makes byte transmission time come close
to the timeout), or clock stretching by some slaves; btw, the latter
seems probable, judging from your words that this happens in the address
phase, when some devices could take longer to prepare for action, and
they
do this by stretching the clock. That is why I'm asking if you tried to
increase I2C_TIMEOUT. Did you do any measurements on the bus to see
if all
is OK and the clock rate is right, and if it gets stretched by some
slaves?
I believe I found the cause of the problem. In the new version of the
driver the following line was added to the exit sequence of i2c_write:
writew(0, i2c_base-cnt);
Removing this line solved the problem (module has been doing I2C
transactions for the last 16 hours or so without failing), and I
believe the reason has to do with Advisory 1.2 in the DM3730 errata:
Advisory 1.2I2C Module Does Not Allow 0-Byte Data Requests
Revision(s) Affected1.2, 1.1 and 1.0
DetailsWhen configured as the master, the I2C module
does not allow 0-byte data transfers.
Programming I2Ci.I2C_CNT[15:0]: DCOUNT = 0 will
cause undefined behavior.
Workaround(s)There is no workaround for this issue. Do not
use 0-byte data requests.
While the mentioned write is done at the end of i2c_write, perhaps the
driver's MO still triggers this issue. It certainly is plausible
that this line was missing from the old i2c_write exit sequence on
purpose, and not by accident (i2c_read, i2c_probe, and i2c_init all
had it in the old driver).
Many thanks for catching this. Feel free to post a patch.
Lubo
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/5] ARM: lib: Add cpu_clock_teardown() call
Add cpu_clock_teardown() call before the Linux kernel is started,
so the CPU code can stop clock that may hinder the Linux's boot.
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Albert Aribaud albert.u.b...@aribaud.net
Cc: Stefano Babic sba...@denx.de
---
arch/arm/cpu/armv7/cpu.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/cpu/armv7/cpu.c b/arch/arm/cpu/armv7/cpu.c
index 01cdb7e..75f8a33 100644
--- a/arch/arm/cpu/armv7/cpu.c
+++ b/arch/arm/cpu/armv7/cpu.c
@@ -23,6 +23,7 @@
#include linux/compiler.h
void __weak cpu_cache_initialization(void){}
+void __weak cpu_clock_teardown(void) {}
int cleanup_before_linux(void)
{
@@ -66,5 +67,8 @@ int cleanup_before_linux(void)
*/
cpu_cache_initialization();
+ /* Let CPUs stop clock that might hinder Linux's boot. */
+ cpu_clock_teardown();
+
return 0;
}
--
1.8.4.rc3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/5] ARM: armv7: Make indirect vector addresses globl
Make indirect vectors addresses global, so they can be replaced by various code that needs to do so. For example the MX6 PCI express driver needs to temporarily replace data abort handler when reading the config space. Signed-off-by: Marek Vasut ma...@denx.de Cc: Albert Aribaud albert.u.b...@aribaud.net Cc: Stefano Babic sba...@denx.de --- arch/arm/cpu/armv7/start.S | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S index 6c9b11a..5aac773 100644 --- a/arch/arm/cpu/armv7/start.S +++ b/arch/arm/cpu/armv7/start.S @@ -38,12 +38,19 @@ _irq: .word _irq _fiq: .word _fiq _pad: .word 0x12345678 /* now 16*4=64 */ #else +.globl _undefined_instruction _undefined_instruction: .word undefined_instruction +.globl _software_interrupt _software_interrupt: .word software_interrupt +.globl _prefetch_abort _prefetch_abort: .word prefetch_abort +.globl _data_abort _data_abort: .word data_abort +.globl _not_used _not_used: .word not_used +.globl _irq _irq: .word irq +.globl _fiq _fiq: .word fiq _pad: .word 0x12345678 /* now 16*4=64 */ #endif /* CONFIG_SPL_BUILD */ -- 1.8.4.rc3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/5] ARM: mx6: Enable PCIe on Sabrelite
Enable PCI express on MX6 Sabrelite. Signed-off-by: Marek Vasut ma...@denx.de Cc: Albert Aribaud albert.u.b...@aribaud.net Cc: Eric Nelson eric.nel...@boundarydevices.com Cc: Fabio Estevam fabio.este...@freescale.com Cc: Stefano Babic sba...@denx.de --- board/boundary/nitrogen6x/nitrogen6x.c | 7 ++- include/configs/nitrogen6x.h | 11 +++ 2 files changed, 17 insertions(+), 1 deletion(-) diff --git a/board/boundary/nitrogen6x/nitrogen6x.c b/board/boundary/nitrogen6x/nitrogen6x.c index 1712908..46be51e 100644 --- a/board/boundary/nitrogen6x/nitrogen6x.c +++ b/board/boundary/nitrogen6x/nitrogen6x.c @@ -369,7 +369,12 @@ int board_eth_init(bd_t *bis) free(bus); } #endif - return 0; + +#ifdef CONFIG_PCI + ret = pci_eth_init(bis); +#endif + + return ret; } static void setup_buttons(void) diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h index 3454b86..ccde896 100644 --- a/include/configs/nitrogen6x.h +++ b/include/configs/nitrogen6x.h @@ -355,4 +355,15 @@ #define CONFIG_SUPPORT_RAW_INITRD #define CONFIG_CMD_FS_GENERIC +/* + * PCI express + */ +#define CONFIG_CMD_PCI +#ifdef CONFIG_CMD_PCI +#define CONFIG_PCI +#define CONFIG_PCI_PNP +#define CONFIG_PCI_SCAN_SHOW +#define CONFIG_PCIE_IMX +#endif + #endif/* __CONFIG_H */ -- 1.8.4.rc3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/5] ARM: mx6: Add PCI express clock configuration
Split the SATA clock enabling function and add PCI express clock
enabling function. The SATA clock enabling function starts up the
100MHz SATA reference PLL in ENET_PLL register, but the code can
be re-used to enable the 125MHz PCIe reference in ENET_PLL, so pull
this code into separate function. Moreover, add the PCIe clock
enabling code.
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Albert Aribaud albert.u.b...@aribaud.net
Cc: Fabio Estevam fabio.este...@freescale.com
Cc: Stefano Babic sba...@denx.de
---
arch/arm/cpu/armv7/mx6/clock.c| 84 ++-
arch/arm/include/asm/arch-mx6/clock.h | 1 +
2 files changed, 75 insertions(+), 10 deletions(-)
diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c
index df11678..3101cb9 100644
--- a/arch/arm/cpu/armv7/mx6/clock.c
+++ b/arch/arm/cpu/armv7/mx6/clock.c
@@ -376,17 +376,12 @@ u32 imx_get_fecclk(void)
return decode_pll(PLL_ENET, MXC_HCLK);
}
-int enable_sata_clock(void)
+static int enable_enet_pll(uint32_t en)
{
- u32 reg = 0;
- s32 timeout = 10;
struct mxc_ccm_reg *const imx_ccm
= (struct mxc_ccm_reg *) CCM_BASE_ADDR;
-
- /* Enable sata clock */
- reg = readl(imx_ccm-CCGR5); /* CCGR5 */
- reg |= MXC_CCM_CCGR5_SATA_MASK;
- writel(reg, imx_ccm-CCGR5);
+ s32 timeout = 10;
+ u32 reg = 0;
/* Enable PLLs */
reg = readl(imx_ccm-analog_pll_enet);
@@ -401,10 +396,79 @@ int enable_sata_clock(void)
return -EIO;
reg = ~BM_ANADIG_PLL_SYS_BYPASS;
writel(reg, imx_ccm-analog_pll_enet);
- reg |= BM_ANADIG_PLL_ENET_ENABLE_SATA;
+ reg |= en;
writel(reg, imx_ccm-analog_pll_enet);
+ return 0;
+}
+
+static void ungate_sata_clock(void)
+{
+ struct mxc_ccm_reg *const imx_ccm =
+ (struct mxc_ccm_reg *) CCM_BASE_ADDR;
+
+ /* Enable SATA clock. */
+ setbits_le32(imx_ccm-CCGR5, MXC_CCM_CCGR5_SATA_MASK);
+}
+
+static void ungate_pcie_clock(void)
+{
+ struct mxc_ccm_reg *const imx_ccm =
+ (struct mxc_ccm_reg *) CCM_BASE_ADDR;
+
+ /* Enable PCIe clock. */
+ setbits_le32(imx_ccm-CCGR4, MXC_CCM_CCGR4_PCIE_MASK);
+}
+
+int enable_sata_clock(void)
+{
+ ungate_sata_clock();
+ return enable_enet_pll(BM_ANADIG_PLL_ENET_ENABLE_SATA);
+}
+
+int enable_pcie_clock(void)
+{
+ struct anatop_regs *anatop_regs =
+ (struct anatop_regs *)ANATOP_BASE_ADDR;
+ struct mxc_ccm_reg *ccm_regs = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
+
+ /*
+* Here be dragons!
+*
+* The register ANATOP_MISC1 is not documented in the Freescale
+* MX6RM. The register that is mapped in the ANATOP space and
+* marked as ANATOP_MISC1 is actually documented in the PMU section
+* of the datasheet as PMU_MISC1.
+*
+* Switch LVDS clock source to SATA (0xb), disable clock INPUT and
+* enable clock OUTPUT. This is important for PCI express link that
+* is clocked from the i.MX6.
+*/
+#define ANADIG_ANA_MISC1_LVDSCLK1_IBEN (1 12)
+#define ANADIG_ANA_MISC1_LVDSCLK1_OBEN (1 10)
+#define ANADIG_ANA_MISC1_LVDS1_CLK_SEL_MASK0x001F
+ clrsetbits_le32(anatop_regs-ana_misc1,
+ ANADIG_ANA_MISC1_LVDSCLK1_IBEN |
+ ANADIG_ANA_MISC1_LVDS1_CLK_SEL_MASK,
+ ANADIG_ANA_MISC1_LVDSCLK1_OBEN | 0xb);
+
+ /* PCIe reference clock sourced from AXI. */
+ clrbits_le32(ccm_regs-cbcmr, MXC_CCM_CBCMR_PCIE_AXI_CLK_SEL);
+
+ /* Party time! Ungate the clock to the PCIe. */
+ ungate_sata_clock();
+ ungate_pcie_clock();
+
+ return enable_enet_pll(BM_ANADIG_PLL_ENET_ENABLE_SATA |
+ BM_ANADIG_PLL_ENET_ENABLE_PCIE);
+}
+
+void cpu_clock_teardown(void)
+{
+ struct anatop_regs *anatop_regs =
+ (struct anatop_regs *)ANATOP_BASE_ADDR;
- return 0 ;
+ /* Stop the PCIe/LVDS clock source before booting Linux. */
+ writel(0, anatop_regs-ana_misc1);
}
unsigned int mxc_get_clock(enum mxc_clock clk)
diff --git a/arch/arm/include/asm/arch-mx6/clock.h
b/arch/arm/include/asm/arch-mx6/clock.h
index 93f29a7..95b1270 100644
--- a/arch/arm/include/asm/arch-mx6/clock.h
+++ b/arch/arm/include/asm/arch-mx6/clock.h
@@ -48,6 +48,7 @@ unsigned int mxc_get_clock(enum mxc_clock clk);
void enable_ocotp_clk(unsigned char enable);
void enable_usboh3_clk(unsigned char enable);
int enable_sata_clock(void);
+int enable_pcie_clock(void);
int enable_i2c_clk(unsigned char enable, unsigned i2c_num);
void enable_ipu_clock(void);
int enable_fec_anatop_clock(void);
--
1.8.4.rc3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/5] ARM: mx6: Add PCI express driver
Add PCIe driver for the Freescale i.MX6 SoC . This driver operates the PCIe block in RC mode only, the EP mode is NOT supported. The driver is tested with the Intel e1000 NIC driver. Signed-off-by: Marek Vasut ma...@denx.de Cc: Albert Aribaud albert.u.b...@aribaud.net Cc: Fabio Estevam fabio.este...@freescale.com Cc: Stefano Babic sba...@denx.de --- arch/arm/include/asm/arch-mx6/iomux.h | 30 ++ drivers/pci/Makefile | 1 + drivers/pci/pcie_imx.c| 560 ++ 3 files changed, 591 insertions(+) create mode 100644 drivers/pci/pcie_imx.c diff --git a/arch/arm/include/asm/arch-mx6/iomux.h b/arch/arm/include/asm/arch-mx6/iomux.h index ff13a1e..bf727a9 100644 --- a/arch/arm/include/asm/arch-mx6/iomux.h +++ b/arch/arm/include/asm/arch-mx6/iomux.h @@ -10,6 +10,36 @@ #define MX6_IOMUXC_GPR70x020e001c /* + * IOMUXC_GPR1 bit fields + */ +#define IOMUXC_GPR1_REF_SSP_EN (1 16) +#define IOMUXC_GPR1_TEST_POWERDOWN (1 18) + +/* + * IOMUXC_GPR8 bit fields + */ +#define IOMUXC_GPR8_PCS_TX_DEEMPH_GEN1_MASK(0x3f 0) +#define IOMUXC_GPR8_PCS_TX_DEEMPH_GEN1_OFFSET 0 +#define IOMUXC_GPR8_PCS_TX_DEEMPH_GEN2_3P5DB_MASK (0x3f 6) +#define IOMUXC_GPR8_PCS_TX_DEEMPH_GEN2_3P5DB_OFFSET6 +#define IOMUXC_GPR8_PCS_TX_DEEMPH_GEN2_6DB_MASK(0x3f 12) +#define IOMUXC_GPR8_PCS_TX_DEEMPH_GEN2_6DB_OFFSET 12 +#define IOMUXC_GPR8_PCS_TX_SWING_FULL_MASK (0x7f 18) +#define IOMUXC_GPR8_PCS_TX_SWING_FULL_OFFSET 18 +#define IOMUXC_GPR8_PCS_TX_SWING_LOW_MASK (0x7f 25) +#define IOMUXC_GPR8_PCS_TX_SWING_LOW_OFFSET25 + +/* + * IOMUXC_GPR12 bit fields + */ +#define IOMUXC_GPR12_LOS_LEVEL_9 (0x9 4) +#define IOMUXC_GPR12_LOS_LEVEL_MASK(0x1f 4) +#define IOMUXC_GPR12_APPS_LTSSM_ENABLE (1 10) +#define IOMUXC_GPR12_DEVICE_TYPE_EP(0x0 12) +#define IOMUXC_GPR12_DEVICE_TYPE_RC(0x2 12) +#define IOMUXC_GPR12_DEVICE_TYPE_MASK (0xf 12) + +/* * IOMUXC_GPR13 bit fields */ #define IOMUXC_GPR13_SDMA_STOP_REQ (130) diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile index be26b60..46c5c9a 100644 --- a/drivers/pci/Makefile +++ b/drivers/pci/Makefile @@ -13,6 +13,7 @@ COBJS-$(CONFIG_FSL_PCI_INIT) += fsl_pci_init.o COBJS-$(CONFIG_PCI) += pci.o pci_auto.o COBJS-$(CONFIG_PCI_INDIRECT_BRIDGE) += pci_indirect.o COBJS-$(CONFIG_PCI_GT64120) += pci_gt64120.o +COBJS-$(CONFIG_PCIE_IMX) += pcie_imx.o COBJS-$(CONFIG_FTPCI100) += pci_ftpci100.o COBJS-$(CONFIG_IXP_PCI) += pci_ixp.o COBJS-$(CONFIG_SH4_PCI) += pci_sh4.o diff --git a/drivers/pci/pcie_imx.c b/drivers/pci/pcie_imx.c new file mode 100644 index 000..12e3546 --- /dev/null +++ b/drivers/pci/pcie_imx.c @@ -0,0 +1,560 @@ +/* + * Freescale i.MX6 PCI Express Root-Complex driver + * + * Copyright (C) 2013 Marek Vasut ma...@denx.de + * + * Based on upstream Linux kernel driver: + * pci-imx6.c: Sean Cross x...@kosagi.com + * pcie-designware.c: Jingoo Han jg1@samsung.com + * + * SPDX-License-Identifier:GPL-2.0 + */ + +#include common.h +#include pci.h +#include asm/arch/clock.h +#include asm/arch/iomux.h +#include asm/arch/crm_regs.h +#include asm/io.h +#include asm/sizes.h +#include errno.h + +#define PCI_ACCESS_READ 0 +#define PCI_ACCESS_WRITE 1 + +#define MX6_DBI_ADDR 0x01ffc000 +#define MX6_DBI_SIZE 0x4000 +#define MX6_IO_ADDR0x0100 +#define MX6_IO_SIZE0x10 +#define MX6_MEM_ADDR 0x0110 +#define MX6_MEM_SIZE 0xe0 +#define MX6_ROOT_ADDR 0x01f0 +#define MX6_ROOT_SIZE 0xfc000 + +/* PCIe Port Logic registers (memory-mapped) */ +#define PL_OFFSET 0x700 +#define PCIE_PHY_DEBUG_R0 (PL_OFFSET + 0x28) +#define PCIE_PHY_DEBUG_R1 (PL_OFFSET + 0x2c) + +#define PCIE_PHY_CTRL (PL_OFFSET + 0x114) +#define PCIE_PHY_CTRL_DATA_LOC 0 +#define PCIE_PHY_CTRL_CAP_ADR_LOC 16 +#define PCIE_PHY_CTRL_CAP_DAT_LOC 17 +#define PCIE_PHY_CTRL_WR_LOC 18 +#define PCIE_PHY_CTRL_RD_LOC 19 + +#define PCIE_PHY_STAT (PL_OFFSET + 0x110) +#define PCIE_PHY_STAT_DATA_LOC 0 +#define PCIE_PHY_STAT_ACK_LOC 16 + +/* PHY registers (not memory-mapped) */ +#define PCIE_PHY_RX_ASIC_OUT 0x100D + +#define PHY_RX_OVRD_IN_LO 0x1005 +#define PHY_RX_OVRD_IN_LO_RX_DATA_EN (1 5) +#define PHY_RX_OVRD_IN_LO_RX_PLL_EN (1 3) + +/* iATU registers */ +#define PCIE_ATU_VIEWPORT 0x900 +#define PCIE_ATU_REGION_INBOUND(0x1 31) +#define PCIE_ATU_REGION_OUTBOUND (0x0 31) +#define PCIE_ATU_REGION_INDEX1 (0x1 0) +#define PCIE_ATU_REGION_INDEX0 (0x0 0) +#define PCIE_ATU_CR1 0x904 +#define PCIE_ATU_TYPE_MEM (0x0 0) +#define PCIE_ATU_TYPE_IO (0x2 0) +#define PCIE_ATU_TYPE_CFG0 (0x4 0) +#define PCIE_ATU_TYPE_CFG1 (0x5 0) +#define PCIE_ATU_CR2 0x908 +#define PCIE_ATU_ENABLE(0x1
Re: [U-Boot] [PATCH 1/5] ARM: armv7: Make indirect vector addresses globl
Hi +Cc Sinan Make indirect vectors addresses global, so they can be replaced by various code that needs to do so. For example the MX6 PCI express driver needs to temporarily replace data abort handler when reading the config space. Signed-off-by: Marek Vasut ma...@denx.de Cc: Albert Aribaud albert.u.b...@aribaud.net Cc: Stefano Babic sba...@denx.de --- arch/arm/cpu/armv7/start.S | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S index 6c9b11a..5aac773 100644 --- a/arch/arm/cpu/armv7/start.S +++ b/arch/arm/cpu/armv7/start.S @@ -38,12 +38,19 @@ _irq: .word _irq _fiq:.word _fiq _pad:.word 0x12345678 /* now 16*4=64 */ #else +.globl _undefined_instruction _undefined_instruction: .word undefined_instruction +.globl _software_interrupt _software_interrupt: .word software_interrupt +.globl _prefetch_abort _prefetch_abort: .word prefetch_abort +.globl _data_abort _data_abort: .word data_abort +.globl _not_used _not_used: .word not_used +.globl _irq _irq:.word irq +.globl _fiq _fiq:.word fiq _pad:.word 0x12345678 /* now 16*4=64 */ #endif /* CONFIG_SPL_BUILD */ Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/2] video: bcm2835: respect the pitch value
On 11/09/2013 03:07 AM, Anatolij Gustschin wrote: From: Andre Heider a.hei...@gmail.com Depending on the firmware's video options [1] the active SDTV or HDTV mode can yield a framebuffer with noncontiguous horizontal lines, giving a messed up display, for both, u-boot and the loaded kernel. Fix this by setting lcd_line_length to the pitch value of the configured framebuffer. [1] http://elinux.org/RPiconfig#Video_mode_options Acked-by: Stephen Warren swar...@wwwdotorg.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v1 1/4] udoo: Move and optimize platform register setting.
Previous uDoo configuration adopts register settings for DDR3, clock, muxing, etc. taken from Nitrogen6x. uDoo schematics is rather different from that board, and it needs customized setting for most of the registers. All this changes can be considered atomical since it is part of initial support of the board. Patch changes uDoo configuration files path to a specific one, and adopt optimized value for every configured register. Signed-off-by: Giuseppe Pagano giuseppe.pag...@seco.com CC: Stefano Babic sba...@denx.de CC: Fabio Estevam fabio.este...@freescale.com --- board/udoo/1066mhz_4x256mx16.cfg | 56 board/udoo/clocks.cfg| 32 ++ board/udoo/ddr-setup.cfg | 87 ++ board/udoo/udoo.cfg | 29 + boards.cfg |2 +- 5 files changed, 205 insertions(+), 1 deletion(-) create mode 100644 board/udoo/1066mhz_4x256mx16.cfg create mode 100644 board/udoo/clocks.cfg create mode 100644 board/udoo/ddr-setup.cfg create mode 100644 board/udoo/udoo.cfg diff --git a/board/udoo/1066mhz_4x256mx16.cfg b/board/udoo/1066mhz_4x256mx16.cfg new file mode 100644 index 000..539e3f6 --- /dev/null +++ b/board/udoo/1066mhz_4x256mx16.cfg @@ -0,0 +1,56 @@ +/* + * Copyright (C) 2013 Boundary Devices + * + * SPDX-License-Identifier:GPL-2.0+ + */ + + +DATA 4, MX6_MMDC_P0_MDPDC, 0x00020036 +DATA 4, MX6_MMDC_P0_MDOTC, 0x09444040 + +DATA 4, MX6_MMDC_P0_MDCFG0, 0x54597955 +DATA 4, MX6_MMDC_P0_MDCFG1, 0xFF328F64 +DATA 4, MX6_MMDC_P0_MDCFG2, 0x01FF00DB + +DATA 4, MX6_MMDC_P0_MDMISC, 0x1740 +DATA 4, MX6_MMDC_P0_MDSCR, 0x8000 +DATA 4, MX6_MMDC_P0_MDRWD, 0x26D2 + +DATA 4, MX6_MMDC_P0_MDOR, 0x00591023 +DATA 4, MX6_MMDC_P0_MDASP, 0x0027 +DATA 4, MX6_MMDC_P0_MDCTL, 0x831A + +DATA 4, MX6_MMDC_P0_MDSCR, 0x04088032 +DATA 4, MX6_MMDC_P0_MDSCR, 0x8033 + +DATA 4, MX6_MMDC_P0_MDSCR, 0x00048031 +DATA 4, MX6_MMDC_P0_MDSCR, 0x09408030 +DATA 4, MX6_MMDC_P0_MDSCR, 0x04008040 +DATA 4, MX6_MMDC_P0_MPZQHWCTRL, 0xA1380003 +DATA 4, MX6_MMDC_P1_MPZQHWCTRL, 0xA1380003 +DATA 4, MX6_MMDC_P0_MDREF, 0x5800 +DATA 4, MX6_MMDC_P0_MPODTCTRL, 0x0007 +DATA 4, MX6_MMDC_P1_MPODTCTRL, 0x0007 + +DATA 4, MX6_MMDC_P0_MPDGCTRL0, 0x43510360 +DATA 4, MX6_MMDC_P0_MPDGCTRL1, 0x0342033F +DATA 4, MX6_MMDC_P1_MPDGCTRL0, 0x033F033F +DATA 4, MX6_MMDC_P1_MPDGCTRL1, 0x03290266 + +DATA 4, MX6_MMDC_P0_MPRDDLCTL, 0x4B3E4141 +DATA 4, MX6_MMDC_P1_MPRDDLCTL, 0x47413B4A +DATA 4, MX6_MMDC_P0_MPWRDLCTL, 0x42404843 +DATA 4, MX6_MMDC_P1_MPWRDLCTL, 0x4C3F4C45 + +DATA 4, MX6_MMDC_P0_MPWLDECTRL0, 0x00350035 +DATA 4, MX6_MMDC_P0_MPWLDECTRL1, 0x001F001F +DATA 4, MX6_MMDC_P1_MPWLDECTRL0, 0x00010001 +DATA 4, MX6_MMDC_P1_MPWLDECTRL1, 0x00010001 + +DATA 4, MX6_MMDC_P0_MPMUR0, 0x0800 +DATA 4, MX6_MMDC_P1_MPMUR0, 0x0800 + +DATA 4, MX6_MMDC_P0_MDPDC, 0x00025576 +DATA 4, MX6_MMDC_P0_MAPSR, 0x00011006 +DATA 4, MX6_MMDC_P0_MDSCR, 0x + diff --git a/board/udoo/clocks.cfg b/board/udoo/clocks.cfg new file mode 100644 index 000..9cd1af1 --- /dev/null +++ b/board/udoo/clocks.cfg @@ -0,0 +1,32 @@ +/* + * Copyright (C) 2013 Boundary Devices + * + * SPDX-License-Identifier:GPL-2.0+ + * + * Device Configuration Data (DCD) + * + * Each entry must have the format: + * Addr-type AddressValue + * + * where: + * Addr-type register length (1,2 or 4 bytes) + * Address absolute address of the register + * value value to be stored in the register + */ + +/* set the default clock gate to save power */ +DATA 4, CCM_CCGR0, 0x00C03F3F +DATA 4, CCM_CCGR1, 0x0030FC03 +DATA 4, CCM_CCGR2, 0x0FFFC000 +DATA 4, CCM_CCGR3, 0x3FF0 +DATA 4, CCM_CCGR4, 0x00FFF300 +DATA 4, CCM_CCGR5, 0x0FC3 +DATA 4, CCM_CCGR6, 0x03FF + +/* enable AXI cache for VDOA/VPU/IPU */ +DATA 4, MX6_IOMUXC_GPR4, 0xF0FF + +/* set IPU AXI-id0 Qos=0xf(bypass) AXI-id1 Qos=0x7 */ +DATA 4, MX6_IOMUXC_GPR6, 0x007F007F +DATA 4, MX6_IOMUXC_GPR7, 0x007F007F + diff --git a/board/udoo/ddr-setup.cfg b/board/udoo/ddr-setup.cfg new file mode 100644 index 000..78cbe17 --- /dev/null +++ b/board/udoo/ddr-setup.cfg @@ -0,0 +1,87 @@ +/* + * Copyright (C) 2013 Boundary Devices + * + * SPDX-License-Identifier:GPL-2.0+ + * + * Device Configuration Data (DCD) + * + * Each entry must have the format: + * Addr-type AddressValue + * + * where: + * Addr-type register length (1,2 or 4 bytes) + * Address absolute address of the register + * value value to be stored in the register + */ + +/* + * DDR3 settings + * MX6Qddr is limited to 1066 Mhz currently 1056 MHz(528 MHz clock), + *memory bus width: 64 bitsx16/x32/x64 + * MX6DL ddr is limited to 800 MHz(400 MHz clock) + *memory bus width: 64 bitsx16/x32/x64 + * MX6SOLO ddr is limited to 800 MHz(400 MHz clock) + *memory bus width: 32 bitsx16/x32 + */ +DATA 4,
[U-Boot] [PATCH v1 2/4] udoo: Add ethernet support (FEC + Micrel KSZ9031).
Add Ethernet and networking support on uDoo board (FEC + phy Micrel KSZ9031).
Signed-off-by: Giuseppe Pagano giuseppe.pag...@seco.com
CC: Stefano Babic sba...@denx.de
CC: Fabio Estevam fabio.este...@freescale.com
---
board/udoo/udoo.c | 140
include/configs/udoo.h | 16 ++
include/micrel.h |5 ++
3 files changed, 161 insertions(+)
diff --git a/board/udoo/udoo.c b/board/udoo/udoo.c
index e9d6375..ca49ebb 100644
--- a/board/udoo/udoo.c
+++ b/board/udoo/udoo.c
@@ -9,6 +9,7 @@
#include asm/arch/clock.h
#include asm/arch/imx-regs.h
#include asm/arch/iomux.h
+#include malloc.h
#include asm/arch/mx6-pins.h
#include asm/errno.h
#include asm/gpio.h
@@ -18,6 +19,9 @@
#include asm/arch/crm_regs.h
#include asm/io.h
#include asm/arch/sys_proto.h
+#include micrel.h
+#include miiphy.h
+#include netdev.h
DECLARE_GLOBAL_DATA_PTR;
@@ -25,6 +29,9 @@ DECLARE_GLOBAL_DATA_PTR;
PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | \
PAD_CTL_SRE_FAST | PAD_CTL_HYS)
+#define ENET_PAD_CTRL (PAD_CTL_PUS_100K_UP | \
+ PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_HYS)
+
#define USDHC_PAD_CTRL (PAD_CTL_PUS_47K_UP | \
PAD_CTL_SPEED_LOW | PAD_CTL_DSE_80ohm | \
PAD_CTL_SRE_FAST | PAD_CTL_HYS)
@@ -58,6 +65,99 @@ static iomux_v3_cfg_t const wdog_pads[] = {
MX6_PAD_EIM_D19__GPIO_3_19,
};
+int mx6_rgmii_rework(struct phy_device *phydev)
+{
+ /*
+* Bug: Apparently uDoo does not works with Gigabit switches...
+* Limiting speed to 10/100Mbps, and setting master mode, seems to
+* be the only way to have a successfull PHY auto negotiation.
+* How to fix: Understand why Linux kernel do not have this issue.
+*/
+ phy_write(phydev, MDIO_DEVAD_NONE, MII_CTRL1000, 0x1c00);
+
+ /* control data pad skew - devaddr = 0x02, register = 0x04 */
+ ksz9031_phy_extended_write(phydev, 0x02,
+ MII_KSZ9031_EXT_RGMII_CTRL_SIG_SKEW,
+ MII_KSZ9031_MOD_DATA_NO_POST_INC, 0x);
+ /* rx data pad skew - devaddr = 0x02, register = 0x05 */
+ ksz9031_phy_extended_write(phydev, 0x02,
+ MII_KSZ9031_EXT_RGMII_RX_DATA_SKEW,
+ MII_KSZ9031_MOD_DATA_NO_POST_INC, 0x);
+ /* tx data pad skew - devaddr = 0x02, register = 0x05 */
+ ksz9031_phy_extended_write(phydev, 0x02,
+ MII_KSZ9031_EXT_RGMII_TX_DATA_SKEW,
+ MII_KSZ9031_MOD_DATA_NO_POST_INC, 0x);
+ /* gtx and rx clock pad skew - devaddr = 0x02, register = 0x08 */
+ ksz9031_phy_extended_write(phydev, 0x02,
+ MII_KSZ9031_EXT_RGMII_CLOCK_SKEW,
+ MII_KSZ9031_MOD_DATA_NO_POST_INC, 0x03FF);
+ return 0;
+}
+
+static iomux_v3_cfg_t const enet_pads1[] = {
+ MX6_PAD_ENET_MDIO__ENET_MDIO| MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6_PAD_ENET_MDC__ENET_MDC | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6_PAD_RGMII_TXC__ENET_RGMII_TXC | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6_PAD_RGMII_TD0__ENET_RGMII_TD0 | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6_PAD_RGMII_TD1__ENET_RGMII_TD1 | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6_PAD_RGMII_TD2__ENET_RGMII_TD2 | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6_PAD_RGMII_TD3__ENET_RGMII_TD3 | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6_PAD_RGMII_TX_CTL__RGMII_TX_CTL | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6_PAD_ENET_REF_CLK__ENET_TX_CLK | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6_PAD_RGMII_RXC__ENET_RGMII_RXC | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ /* RGMII reset */
+ MX6_PAD_EIM_D23__GPIO_3_23 | MUX_PAD_CTRL(NO_PAD_CTRL),
+ /* alimentazione ethernet*/
+ MX6_PAD_EIM_EB3__GPIO_2_31 | MUX_PAD_CTRL(NO_PAD_CTRL),
+ /* pin 32 - 1 - (MODE0) all */
+ MX6_PAD_RGMII_RD0__GPIO_6_25| MUX_PAD_CTRL(NO_PAD_CTRL),
+ /* pin 31 - 1 - (MODE1) all */
+ MX6_PAD_RGMII_RD1__GPIO_6_27| MUX_PAD_CTRL(NO_PAD_CTRL),
+ /* pin 28 - 1 - (MODE2) all */
+ MX6_PAD_RGMII_RD2__GPIO_6_28| MUX_PAD_CTRL(NO_PAD_CTRL),
+ /* pin 27 - 1 - (MODE3) all */
+ MX6_PAD_RGMII_RD3__GPIO_6_29| MUX_PAD_CTRL(NO_PAD_CTRL),
+ /* pin 33 - 1 - (CLK125_EN) 125Mhz clockout enabled */
+ MX6_PAD_RGMII_RX_CTL__GPIO_6_24 | MUX_PAD_CTRL(NO_PAD_CTRL),
+};
+
+static iomux_v3_cfg_t const enet_pads2[] = {
+ MX6_PAD_RGMII_RD0__ENET_RGMII_RD0 | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6_PAD_RGMII_RD1__ENET_RGMII_RD1 | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6_PAD_RGMII_RD2__ENET_RGMII_RD2 | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6_PAD_RGMII_RD3__ENET_RGMII_RD3 |
[U-Boot] [PATCH,v1,4/4] udoo: Fix watchdog during kernel boot.
uDoo uses APX823-31W5 watchdog chip. Timeout is about 1.2 seconds.
To disabled watchdog during kernel boot, WDI pin of that chip needs to be in
high impedance state.
I.mx6 gpio configuration does not contemplate tristate, so pin is set as input
in high impedance.
Signed-off-by: Giuseppe Pagano giuseppe.pag...@seco.com
CC: Stefano Babic sba...@denx.de
CC: Fabio Estevam fabio.este...@freescale.com
---
board/udoo/udoo.c |1 +
1 file changed, 1 insertion(+)
diff --git a/board/udoo/udoo.c b/board/udoo/udoo.c
index b53f70c..af8004e 100644
--- a/board/udoo/udoo.c
+++ b/board/udoo/udoo.c
@@ -169,6 +169,7 @@ static void setup_iomux_wdog(void)
imx_iomux_v3_setup_multiple_pads(wdog_pads, ARRAY_SIZE(wdog_pads));
gpio_direction_output(WDT_TRG, 0);
gpio_direction_output(WDT_EN, 1);
+ gpio_direction_input(WDT_TRG);
}
static struct fsl_esdhc_cfg usdhc_cfg = { USDHC3_BASE_ADDR };
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v1 3/4] udoo: Add SATA support on uDoo Board.
Adds SATA support on uDoo Board.
Moves sata_setup function definition from nitrogen6x.c and udoo.c to
arch/arm/imx-common/sata.c to avoid code duplication.
Signed-off-by: Giuseppe Pagano giuseppe.pag...@seco.com
CC: Stefano Babic sba...@denx.de
CC: Fabio Estevam fabio.este...@freescale.com
CC: Eric Nelson eric.nel...@boundarydevices.com
---
arch/arm/imx-common/Makefile |1 +
arch/arm/imx-common/sata.c | 33
arch/arm/include/asm/imx-common/sata.h | 17
board/boundary/nitrogen6x/nitrogen6x.c | 27 +-
board/udoo/udoo.c |4
include/configs/udoo.h | 12
6 files changed, 68 insertions(+), 26 deletions(-)
create mode 100644 arch/arm/imx-common/sata.c
create mode 100644 arch/arm/include/asm/imx-common/sata.h
diff --git a/arch/arm/imx-common/Makefile b/arch/arm/imx-common/Makefile
index 727a052..6f85c42 100644
--- a/arch/arm/imx-common/Makefile
+++ b/arch/arm/imx-common/Makefile
@@ -17,6 +17,7 @@ endif
ifeq ($(SOC),$(filter $(SOC),mx5 mx6))
COBJS-y+= timer.o cpu.o speed.o
COBJS-$(CONFIG_I2C_MXC) += i2c-mxv7.o
+COBJS-$(CONFIG_CMD_SATA) += sata.o
endif
ifeq ($(SOC),$(filter $(SOC),mx6 mxs))
COBJS-y+= misc.o
diff --git a/arch/arm/imx-common/sata.c b/arch/arm/imx-common/sata.c
new file mode 100644
index 000..00b3d92
--- /dev/null
+++ b/arch/arm/imx-common/sata.c
@@ -0,0 +1,33 @@
+/*
+ * Copyright 2011 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include asm/imx-common/iomux-v3.h
+#include asm/arch/iomux.h
+#include asm/io.h
+
+int sata_setup(void)
+{
+ struct iomuxc_base_regs *const iomuxc_regs
+ = (struct iomuxc_base_regs *)IOMUXC_BASE_ADDR;
+
+ int ret = enable_sata_clock();
+ if (ret)
+ return ret;
+
+ clrsetbits_le32(iomuxc_regs-gpr[13],
+ IOMUXC_GPR13_SATA_MASK,
+ IOMUXC_GPR13_SATA_PHY_8_RXEQ_3P0DB
+ |IOMUXC_GPR13_SATA_PHY_7_SATA2M
+ |IOMUXC_GPR13_SATA_SPEED_3G
+ |(3IOMUXC_GPR13_SATA_PHY_6_SHIFT)
+ |IOMUXC_GPR13_SATA_SATA_PHY_5_SS_DISABLED
+ |IOMUXC_GPR13_SATA_SATA_PHY_4_ATTEN_9_16
+ |IOMUXC_GPR13_SATA_PHY_3_TXBOOST_0P00_DB
+ |IOMUXC_GPR13_SATA_PHY_2_TX_1P104V
+ |IOMUXC_GPR13_SATA_PHY_1_SLOW);
+
+ return 0;
+}
diff --git a/arch/arm/include/asm/imx-common/sata.h
b/arch/arm/include/asm/imx-common/sata.h
new file mode 100644
index 000..40fbf77
--- /dev/null
+++ b/arch/arm/include/asm/imx-common/sata.h
@@ -0,0 +1,17 @@
+/*
+ * Copyright 2011 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __IMX_SATA_H_
+#define __IMX_SATA_H_
+
+/*
+ * SATA setup for i.mx6 quad based platform
+ */
+
+int sata_setup(void);
+
+#endif
+
diff --git a/board/boundary/nitrogen6x/nitrogen6x.c
b/board/boundary/nitrogen6x/nitrogen6x.c
index 1712908..0c26bcb 100644
--- a/board/boundary/nitrogen6x/nitrogen6x.c
+++ b/board/boundary/nitrogen6x/nitrogen6x.c
@@ -17,6 +17,7 @@
#include asm/gpio.h
#include asm/imx-common/iomux-v3.h
#include asm/imx-common/mxc_i2c.h
+#include asm/imx-common/sata.h
#include asm/imx-common/boot_mode.h
#include mmc.h
#include fsl_esdhc.h
@@ -378,32 +379,6 @@ static void setup_buttons(void)
ARRAY_SIZE(button_pads));
}
-#ifdef CONFIG_CMD_SATA
-
-int setup_sata(void)
-{
- struct iomuxc_base_regs *const iomuxc_regs
- = (struct iomuxc_base_regs *) IOMUXC_BASE_ADDR;
- int ret = enable_sata_clock();
- if (ret)
- return ret;
-
- clrsetbits_le32(iomuxc_regs-gpr[13],
- IOMUXC_GPR13_SATA_MASK,
- IOMUXC_GPR13_SATA_PHY_8_RXEQ_3P0DB
- |IOMUXC_GPR13_SATA_PHY_7_SATA2M
- |IOMUXC_GPR13_SATA_SPEED_3G
- |(3IOMUXC_GPR13_SATA_PHY_6_SHIFT)
- |IOMUXC_GPR13_SATA_SATA_PHY_5_SS_DISABLED
- |IOMUXC_GPR13_SATA_SATA_PHY_4_ATTEN_9_16
- |IOMUXC_GPR13_SATA_PHY_3_TXBOOST_0P00_DB
- |IOMUXC_GPR13_SATA_PHY_2_TX_1P104V
- |IOMUXC_GPR13_SATA_PHY_1_SLOW);
-
- return 0;
-}
-#endif
-
#if defined(CONFIG_VIDEO_IPUV3)
static iomux_v3_cfg_t const backlight_pads[] = {
diff --git a/board/udoo/udoo.c b/board/udoo/udoo.c
index ca49ebb..b53f70c 100644
--- a/board/udoo/udoo.c
+++ b/board/udoo/udoo.c
@@ -14,6 +14,7 @@
#include asm/errno.h
#include asm/gpio.h
#include asm/imx-common/iomux-v3.h
+#include asm/imx-common/sata.h
#include mmc.h
#include fsl_esdhc.h
#include asm/arch/crm_regs.h
@@ -239,6 +240,9 @@ int board_init(void)
/* address of boot parameters */
Re: [U-Boot] [GIT PULL] u-boot-mips/master
On Sat, Nov 09, 2013 at 09:53:23PM +0100, Daniel Schwierzeck wrote: Hi Tom, The following changes since commit 15c5cdf5aa6b292145e5e3e220ec1f42b11eff6f: Merge branch 'master' of git://www.denx.de/git/u-boot-usb (2013-11-08 15:25:29 -0500) are available in the git repository at: git://git.denx.de/u-boot-mips.git master [snip] Paul Burton (18): mips32: detect L1 cache sizes if they're not defined pcnet: code style cleanup pcnet: s/le16_to_cpu/cpu_to_le16/ in pcnet_send pcnet: add cache flushing invalidation So, adding cache flushing and invalidation breaks the PN62 because mpc824x doesn't have cache flushing support. I'm inclined to take this PR now and then remove PN62 support if it's not fixed. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC] imx: add multi-architecture README
On 11/11/2013 08:12 AM, Eric Nelson wrote: Thanks Tapani, On 11/11/2013 05:03 AM, Tapani wrote: snip We have suggested an alternative solution, but somehow nobody seem to notice. We avoid almost all the preprocessor messing, and have the definitions only once. And it would scale for even more cpu types. Admittedly, the drawback is duplicate padconf macro definitions (or having to convert the existing boards padconfigs). Somehow I missed it. What I recall involved duplicating code and data. Whoops. I should have said logic and declarations... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 3/4] udoo: Add SATA support on uDoo Board.
Hello Giuseppe, On Mon, Nov 11, 2013 at 3:11 PM, Giuseppe Pagano giuseppe.pag...@seco.com wrote: Adds SATA support on uDoo Board. Moves sata_setup function definition from nitrogen6x.c and udoo.c to arch/arm/imx-common/sata.c to avoid code duplication. Signed-off-by: Giuseppe Pagano giuseppe.pag...@seco.com Your patches should have the long description split in 80 cols; please do the nitrogen code move in a separated patch so it is clear what you did to include support for uDoo board. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v1 1/6] Driver/DDR: Moving Freescale DDR driver to a common driver
On Fri, 2013-11-08 at 20:25 -0600, sun york-R58495 wrote: On Nov 8, 2013, at 4:48 PM, Scott Wood wrote: On Wed, 2013-10-30 at 19:07 -0700, York Sun wrote: + CONFIG_SYS_FSL_DDR + Freescale DDR driver in use. This type of DDR controller is + found in mpc83xx, mpc85xx, mpc86xx as well as some ARM core + SoCs. + + CONFIG_SYS_FSL_DDR_ADDR + Freescale DDR memory-mapped register base. + + CONFIG_SYS_FSL_DDR_EMU + Specify emulator support for DDR. Some DDR features such as + deskew training are not available. + + CONFIG_SYS_FSL_DDR_PPC_GEN1 + Freescale DDR1 controller. + + CONFIG_SYS_FSL_DDR_PPC_GEN2 + Freescale DDR2 controller. + + CONFIG_SYS_FSL_DDR_PPC_GEN3 + Freescale DDR3 controller. Why is there PPC in the name if this is to be common for PPC and ARM? The description is more generic than the config symbol... This patch moves the DDR driver out of powerpc. I should deal with the common part for ARM and PPC later. Good point. + CONFIG_FSL_DDR1 + User config to use DDR1. It can be enabled for SoCs with + Freescale DDR1 or DDR2 controllers. + + CONFIG_FSL_DDR2 + User config to use DDR2. It can be eanbeld for SoCs with + Freescale DDR2 or DDR3 controllers. + + CONFIG_FSL_DDR3 + User config to use DDR3. It can be enabled for SoCs with + Freescale DDR3 controllers. How is this user config, rather than a description of the type of DDR that is present? The DDR controller may support more than one type of memory. DDR2 controllers support both DDR1 and DDR2, and some DDR3 controllers support both DDR2 and DDR3. It's user's option to choose which type of DDR devices to use. The driver needs to deal with them differently. You may argue the driver should detect them and choose the algorithm differently. But that will increase the code size considerably. It makes less sense to do so because once the board is designed, it is either this or that. My point is that the type of DDR that is present is hardware description, just as much as the type of DDR controller. User config means things users can choose purely in software, without a corresponding hardware change. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] malta: use unmapped flash base address
2013.11.11. 15:22 keltezéssel, Paul Burton írta: ... diff --git a/arch/mips/include/asm/malta.h b/arch/mips/include/asm/malta.h index 9b1100b..bd9043d 100644 --- a/arch/mips/include/asm/malta.h +++ b/arch/mips/include/asm/malta.h @@ -44,7 +44,7 @@ #define MALTA_RESET_BASE0x1f000500 #define GORESET0x42 -#define MALTA_FLASH_BASE0x1fc0 +#define MALTA_FLASH_BASE0x1e00 #define MALTA_REVISION0x1fc00010 #define MALTA_REVISION_CORID_SHF10 Hmm, this does run on a real Malta but it takes around a minute to run relocate_code... With the 0x1fc0 base address it's much faster. I'll see if I can figure out why... Hm, you are right. Although I did not notice that before, but with this patch U-Boot starts slower also in qemu. It seems that the problem is in the relocation code. I'm preparing a patch to fix that. -Gabor ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT PULL] u-boot-mips/master
2013/11/11 Tom Rini tr...@ti.com: On Sat, Nov 09, 2013 at 09:53:23PM +0100, Daniel Schwierzeck wrote: Hi Tom, The following changes since commit 15c5cdf5aa6b292145e5e3e220ec1f42b11eff6f: Merge branch 'master' of git://www.denx.de/git/u-boot-usb (2013-11-08 15:25:29 -0500) are available in the git repository at: git://git.denx.de/u-boot-mips.git master [snip] Paul Burton (18): mips32: detect L1 cache sizes if they're not defined pcnet: code style cleanup pcnet: s/le16_to_cpu/cpu_to_le16/ in pcnet_send pcnet: add cache flushing invalidation So, adding cache flushing and invalidation breaks the PN62 because mpc824x doesn't have cache flushing support. I'm inclined to take this PR now and then remove PN62 support if it's not fixed. -- Tom hm, I thought qemu-malta was the sole user of pcnet. To fix pn62, we could add a stub implementation like it is done in arch/powerpc/cpu/mpc83xx/cache.c. -- - Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] MIPS: use CONFIG_SYS_TEXT_BASE in relocation calculations
The relocation code uses the CONFIG_SYS_MONITOR_BASE
constant for calculating the reserved memory size and
relocation offset values. Along with these predefined
values the code also uses several other constants which
are computed by the linker from the CONFIG_SYS_TEXT_BASE
value. Due to this, the relocation code works incorreclty
if the CONFIG_SYS_TEXT_BASE and CONFIG_SYS_MONITOR_BASE
values are different.
Change the relocation code to use the CONFIG_SYS_TEXT_BASE
constant in the calculations to avoid the problem.
Only tested in qemu with the 'malta' and 'qemu_mips{,el}'
targets.
Signed-off-by: Gabor Juhos juh...@openwrt.org
Cc: Daniel Schwierzeck daniel.schwierz...@gmail.com
Cc: Paul Burton paul.bur...@imgtec.com
---
Daniel,
This should be merged before my 'malta: use unmapped flash base address'
patch.
Thanks,
Gabor
---
arch/mips/cpu/mips32/start.S |2 +-
arch/mips/cpu/mips64/start.S |2 +-
arch/mips/cpu/xburst/start.S |2 +-
arch/mips/lib/board.c|2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/mips/cpu/mips32/start.S b/arch/mips/cpu/mips32/start.S
index 68e59b5..13e2de7 100644
--- a/arch/mips/cpu/mips32/start.S
+++ b/arch/mips/cpu/mips32/start.S
@@ -159,7 +159,7 @@ relocate_code:
moves0, a1 # save gd in s0
moves2, a2 # save destination address in s2
- li t0, CONFIG_SYS_MONITOR_BASE
+ li t0, CONFIG_SYS_TEXT_BASE
sub s1, s2, t0 # s1 -- relocation offset
la t3, in_ram
diff --git a/arch/mips/cpu/mips64/start.S b/arch/mips/cpu/mips64/start.S
index 92954e1..4fa8bb1 100644
--- a/arch/mips/cpu/mips64/start.S
+++ b/arch/mips/cpu/mips64/start.S
@@ -153,7 +153,7 @@ relocate_code:
moves0, a1 # save gd in s0
moves2, a2 # save destination address in s2
- dli t0, CONFIG_SYS_MONITOR_BASE
+ dli t0, CONFIG_SYS_TEXT_BASE
dsubs1, s2, t0 # s1 -- relocation offset
dla t3, in_ram
diff --git a/arch/mips/cpu/xburst/start.S b/arch/mips/cpu/xburst/start.S
index 10dffb4..e9d9679 100644
--- a/arch/mips/cpu/xburst/start.S
+++ b/arch/mips/cpu/xburst/start.S
@@ -50,7 +50,7 @@ relocate_code:
moves0, a1 # save gd in s0
moves2, a2 # save destination address in s2
- li t0, CONFIG_SYS_MONITOR_BASE
+ li t0, CONFIG_SYS_TEXT_BASE
sub s1, s2, t0 # s1 -- relocation offset
la t3, in_ram
diff --git a/arch/mips/lib/board.c b/arch/mips/lib/board.c
index 9e6ba15..82efa5a 100644
--- a/arch/mips/lib/board.c
+++ b/arch/mips/lib/board.c
@@ -160,7 +160,7 @@ void board_init_f(ulong bootflag)
/* Reserve memory for U-Boot code, data bss
* round down to next 16 kB limit
*/
- len = bss_end() - CONFIG_SYS_MONITOR_BASE;
+ len = bss_end() - CONFIG_SYS_TEXT_BASE;
addr -= len;
addr = ~(16 * 1024 - 1);
--
1.7.10
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v1 1/6] Driver/DDR: Moving Freescale DDR driver to a common driver
On 11/11/2013 10:49 AM, Scott Wood wrote: On Fri, 2013-11-08 at 20:25 -0600, sun york-R58495 wrote: On Nov 8, 2013, at 4:48 PM, Scott Wood wrote: On Wed, 2013-10-30 at 19:07 -0700, York Sun wrote: + CONFIG_SYS_FSL_DDR + Freescale DDR driver in use. This type of DDR controller is + found in mpc83xx, mpc85xx, mpc86xx as well as some ARM core + SoCs. + + CONFIG_SYS_FSL_DDR_ADDR + Freescale DDR memory-mapped register base. + + CONFIG_SYS_FSL_DDR_EMU + Specify emulator support for DDR. Some DDR features such as + deskew training are not available. + + CONFIG_SYS_FSL_DDR_PPC_GEN1 + Freescale DDR1 controller. + + CONFIG_SYS_FSL_DDR_PPC_GEN2 + Freescale DDR2 controller. + + CONFIG_SYS_FSL_DDR_PPC_GEN3 + Freescale DDR3 controller. Why is there PPC in the name if this is to be common for PPC and ARM? The description is more generic than the config symbol... This patch moves the DDR driver out of powerpc. I should deal with the common part for ARM and PPC later. Good point. + CONFIG_FSL_DDR1 + User config to use DDR1. It can be enabled for SoCs with + Freescale DDR1 or DDR2 controllers. + + CONFIG_FSL_DDR2 + User config to use DDR2. It can be eanbeld for SoCs with + Freescale DDR2 or DDR3 controllers. + + CONFIG_FSL_DDR3 + User config to use DDR3. It can be enabled for SoCs with + Freescale DDR3 controllers. How is this user config, rather than a description of the type of DDR that is present? The DDR controller may support more than one type of memory. DDR2 controllers support both DDR1 and DDR2, and some DDR3 controllers support both DDR2 and DDR3. It's user's option to choose which type of DDR devices to use. The driver needs to deal with them differently. You may argue the driver should detect them and choose the algorithm differently. But that will increase the code size considerably. It makes less sense to do so because once the board is designed, it is either this or that. My point is that the type of DDR that is present is hardware description, just as much as the type of DDR controller. User config means things users can choose purely in software, without a corresponding hardware change. This is a board-level configuration, not SoC level. Should we use CONFIG_SYS_ as well? If so, we need to come up with a new name, such as CONFIG_SYS_FSL_DDR_MEM_GEN3. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT PULL] u-boot-mips/master
On Mon, Nov 11, 2013 at 08:00:01PM +0100, Daniel Schwierzeck wrote: 2013/11/11 Tom Rini tr...@ti.com: On Sat, Nov 09, 2013 at 09:53:23PM +0100, Daniel Schwierzeck wrote: Hi Tom, The following changes since commit 15c5cdf5aa6b292145e5e3e220ec1f42b11eff6f: Merge branch 'master' of git://www.denx.de/git/u-boot-usb (2013-11-08 15:25:29 -0500) are available in the git repository at: git://git.denx.de/u-boot-mips.git master [snip] Paul Burton (18): mips32: detect L1 cache sizes if they're not defined pcnet: code style cleanup pcnet: s/le16_to_cpu/cpu_to_le16/ in pcnet_send pcnet: add cache flushing invalidation So, adding cache flushing and invalidation breaks the PN62 because mpc824x doesn't have cache flushing support. I'm inclined to take this PR now and then remove PN62 support if it's not fixed. hm, I thought qemu-malta was the sole user of pcnet. To fix pn62, we could add a stub implementation like it is done in arch/powerpc/cpu/mpc83xx/cache.c. After talking with Wolfgang on IRC, he's just going to delete the platform (and more mpc824x) as mpc824x is just dead. I'll be pushing the MIPS PR shortly. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] MPC824x: remove obsolete PN62 board
The MPC824x processors have long reached EOL, and the PN62 board has
not seen any board-specific updates for more than a decade. It is now
causing build issues. Instead of wasting time on things nobody is
interested in any more, we rather drop this board.
Signed-off-by: Wolfgang Denk w...@denx.de
Cc: Wolfgang Grandegger w...@grandegger.com
cc: Tom Rini tr...@ti.com
---
Tom, as there is zero activity for the MPC82xx tree I don't invest the
efforts in pushing this patch there and then sending a pull request.
Can you please apply it directly? Thanks in advance -- wd
CREDITS | 2 +-
arch/powerpc/cpu/mpc824x/cpu_init.c | 6 +-
board/pn62/Makefile | 8 -
board/pn62/cmd_pn62.c | 146 --
board/pn62/misc.c | 219 ---
board/pn62/pn62.c | 171 --
board/pn62/pn62.h | 145 --
boards.cfg | 1 -
doc/README.scrapyard| 3 +-
drivers/net/pcnet.c | 10 --
include/configs/PN62.h | 285
11 files changed, 5 insertions(+), 991 deletions(-)
delete mode 100644 board/pn62/Makefile
delete mode 100644 board/pn62/cmd_pn62.c
delete mode 100644 board/pn62/misc.c
delete mode 100644 board/pn62/pn62.c
delete mode 100644 board/pn62/pn62.h
delete mode 100644 include/configs/PN62.h
diff --git a/CREDITS b/CREDITS
index 3b657e9..52f289e 100644
--- a/CREDITS
+++ b/CREDITS
@@ -143,7 +143,7 @@ W: www.freescale.com
N: Dr. Wolfgang Grandegger
E: w...@denx.de
-D: Support for Interphase 4539 T1/E1/J1 PMC, PN62, CCM, SCM boards
+D: Support for Interphase 4539 T1/E1/J1 PMC, CCM, SCM boards
W: www.denx.de
N: Peter Figuli
diff --git a/arch/powerpc/cpu/mpc824x/cpu_init.c
b/arch/powerpc/cpu/mpc824x/cpu_init.c
index 37d796e..47ac18e 100644
--- a/arch/powerpc/cpu/mpc824x/cpu_init.c
+++ b/arch/powerpc/cpu/mpc824x/cpu_init.c
@@ -52,7 +52,7 @@ cpu_init_f (void)
CONFIG_WRITE_HALFWORD(PCICR, 0x06); /* Bus Master, respond to PCI memory
space acesses*/
/*CONFIG_WRITE_HALFWORD(PCISR, 0x); */ /*reset PCISR*/
-#if defined(CONFIG_MUSENKI) || defined(CONFIG_PN62)
+#if defined(CONFIG_MUSENKI)
/* Why is this here, you ask? Try, just try setting 0x8000
* in PCIACR with CONFIG_WRITE_HALFWORD()
* this one was a stumper, and we are annoyed
@@ -142,9 +142,7 @@ cpu_init_f (void)
CONFIG_READ_WORD(PICR2, val);
val= val ~ (PICR2_CF_SNOOP_WS_MASK | PICR2_CF_APHASE_WS_MASK); /*mask
off waitstate bits*/
-#ifndef CONFIG_PN62
val |= PICR2_CF_SNOOP_WS_1WS | PICR2_CF_APHASE_WS_1WS; /*1 wait state*/
-#endif
CONFIG_WRITE_WORD(PICR2, val);
CONFIG_WRITE_WORD(EUMBBAR, CONFIG_SYS_EUMB_ADDR);
@@ -186,7 +184,7 @@ cpu_init_f (void)
* should define CONFIG_SYS_ACTORW to 0 if they don't want to set it, or
even, if
* its not set, we define it to zero in this file
*/
-#if defined(CONFIG_CU824) || defined(CONFIG_PN62)
+#if defined(CONFIG_CU824)
CONFIG_WRITE_WORD(MCCR4,
(CONFIG_SYS_PRETOACT MCCR4_PRETOACT_SHIFT) |
(CONFIG_SYS_ACTTOPRE MCCR4_ACTTOPRE_SHIFT) |
diff --git a/board/pn62/Makefile b/board/pn62/Makefile
deleted file mode 100644
index 7572ed8..000
--- a/board/pn62/Makefile
+++ /dev/null
@@ -1,8 +0,0 @@
-#
-# (C) Copyright 2000-2006
-# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
-#
-# SPDX-License-Identifier: GPL-2.0+
-#
-
-obj-y = pn62.o cmd_pn62.o misc.o
diff --git a/board/pn62/cmd_pn62.c b/board/pn62/cmd_pn62.c
deleted file mode 100644
index a0326b4..000
--- a/board/pn62/cmd_pn62.c
+++ /dev/null
@@ -1,146 +0,0 @@
-/*
- * (C) Copyright 2002
- * Wolfgang Grandegger, DENX Software Engineering, w...@denx.de.
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#include common.h
-#include malloc.h
-#include net.h
-#include asm/io.h
-#include pci.h
-#include command.h
-#include pn62.h
-
-#if defined(CONFIG_CMD_BSP)
-
-/*
- * Command led: controls the various LEDs 0..11 on the PN62 card.
- */
-int do_led(cmd_tbl_t * cmdtp, int flag, int argc, char *const argv[])
-{
- unsigned int number, function;
-
- if (argc != 3)
- return cmd_usage(cmdtp);
-
- number = simple_strtoul(argv[1], NULL, 10);
- if (number PN62_LED_MAX)
- return 1;
-
- function = simple_strtoul(argv[2], NULL, 16);
- set_led(number, function);
- return 0;
-}
-U_BOOT_CMD(
- led,3, 1, do_led,
- set LED 0..11 on the PN62 board,
- i fun
- - set 'i'th LED to function 'fun'
-);
-
-/*
- * Command loadpci: loads a image over PCI.
- */
-#define CMD_MOVE_WINDOW 0x1
-#define CMD_BOOT_IMAGE 0x2
-
-int do_loadpci (cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
-{
-char *s;
-ulong addr = 0, count = 0;
-u32 off;
-int cmd, rcode = 0;
-
-/* pre-set
Re: [U-Boot] Pull request: u-boot-arm/master
On Sat, Nov 09, 2013 at 11:53:22PM +0100, Albert ARIBAUD wrote: Hi Tom, The following changes since commit 15c5cdf5aa6b292145e5e3e220ec1f42b11eff6f: Merge branch 'master' of git://www.denx.de/git/u-boot-usb (2013-11-08 15:25:29 -0500) are available in the git repository at: git://git.denx.de/u-boot-arm master for you to fetch changes up to 85b8c5c4bf80025de4632ae6c9a8a606e51508a4: Merge branch 'iu-boot/master' into 'u-boot-arm/master' (2013-11-09 22:59:47 +0100) NOTE 1: the top of u-boot-arm/master is a merge from u-boot/master with non-trivial conflict resolutions, involving some changes to non-conflicting files too. See 'git show 85b8c5c4' for details. NOTE 2: eleven ARM targets fail with a warning about CONFIG_SYS_HZ: omap730p2_cs3boot omap730p2_cs0boot scb9328 palmtc balloon3 mini2440 zipitz2 palmld omap730p2 omap3_zoom2 mx1ads. These failures already happen on u-boot/master and are thus not due to the ARM branch. Albert ARIBAUD (3): Merge branch 'u-boot-atmel/master' into 'u-boot-arm/master' Merge branch 'u-boot-imx/master' into 'u-boot-arm/master' Merge branch 'iu-boot/master' into 'u-boot-arm/master' Anatolij Gustschin (1): imx_watchdog: do not soft-reset while watchdog init Andreas Bie??mann (10): tricorder: update flash partitioning tricorder: use generic provided loadaddr tricorder: add configuration for a flashcard u-boot tricorder: add cmdline history tricorder: add mtdparts to environment tricorder: add tricordereeprom command tricorder: panic() on unknown board tricorder: add led support tricorder: read kernel directly from NAND tricorder: support 256MiB SDRAM on revision D Bo Shen (3): net: macb: get DMA bus width from design config register arm: atmel: at91sam9n12ek: add usb host support arm: atmel: get rid of too many ifdeffery Christoph G. Baumann (1): ARM: mxs: Configure 2 Gbit DDR2 RAM for BG0900 Eric Nelson (1): i.MX6: nitrogen6x: fix erase size in 6x_upgrade.txt Fabio Estevam (5): udoo: Add initial support for mx6q udoo board ARM: mx5: Enable L2 cache mx5: lowlevel_init: Remove unused macro configs: imx: Make CONFIG_SYS_PROMPT uniform across FSL boards wandboard: README: Include the quad version Heiko Schocher (2): nand, davinci: add special UBL ecc position arm, da85x: update for the ipam390 board Igor Grinberg (2): cm-t35: move the eeprom code to common place cm-t35: move the display code to common place Javier Martinez Canillas (2): ARM: IGEP0033: rename config file to am335x_igep0033.h OMAP3: igep00x0: rename config file to omap3_igep00x0.h Jens Scharsig (BuS Elektronik) (1): ARM: ATMEL: eb_cpux9k2: fix TEXT_BASE for ramboot target Lokesh Vutla (1): ARM: OMAP4: Convert to ti_armv7_common.h Marek Vasut (4): ARM: mxs: tools: Use mkimage for BootStream generation ARM: mxs: Add PPC-AG BG0900 board ARM: mxs: Setup stack in JTAG mode ARM: mxs: Enable DCDC converter for battery boot Michal Simek (1): zynq: Use arch_cpu_init() instead of lowlevel_init() Minal Shah (1): dra7xx_evm: Enabled UART-boot mode and add dra7xx_evm_uart3 build Nikita Kiryanov (3): cm_t35: reduce default bootdelay to 3 seconds cm_t35: turn on GPIO commands cm_t35: update lcd predefines Otavio Salvador (1): mx6: Remove PAD_CTL_DSE_120ohm from i.MX6DL's IPU1_DI0_PIN4 pin Pierre Aubert (1): mx6: compute PLL PFD frequencies rather than using defines Roger Meier (1): at91: add defines for reset type SRICHARAN R (1): ARM: OMAP5: DDR3: Change io settings Stefan Roese (1): arm: Remove IXP425 boards pdnb3 and scpu Stefano Babic (1): Revert configs: imx: Make CONFIG_SYS_PROMPT uniform across FSL boards Thomas Weber (3): tricorder: remove lcdmode from bootargs tricorder: Make u-boot faster tricorder: switch to alternative memtest Tom Rini (7): drivers/rtc/davinci.c: Reference DAVINCI_RTC_BASE more directly am33xx, davinci: Create and use asm/davinci_rtc.h bootcount_davinci: Switch to scratch register #2 TI:am33xx: Add bootcount support to ti_am335x_common.h am335x: Enable CONFIG_OMAP_WATCHDOG support TI:armv7: Change CONFIG_SYS_SPL_ARGS_ADDR to a higher address TI:omap5: Add rdaddr, use consistent loadaddr values arch/arm/cpu/arm926ejs/mxs/Makefile | 10 ++-- arch/arm/cpu/arm926ejs/mxs/mxsimage.mx23.cfg| 4 +- arch/arm/cpu/arm926ejs/mxs/mxsimage.mx28.cfg| 4 +- arch/arm/cpu/arm926ejs/mxs/spl_power_init.c | 2 +
Re: [U-Boot] [GIT PULL] u-boot-mips/master
On Sat, Nov 09, 2013 at 09:53:23PM +0100, Daniel Schwierzeck wrote:
Hi Tom,
The following changes since commit 15c5cdf5aa6b292145e5e3e220ec1f42b11eff6f:
Merge branch 'master' of git://www.denx.de/git/u-boot-usb
(2013-11-08 15:25:29 -0500)
are available in the git repository at:
git://git.denx.de/u-boot-mips.git master
for you to fetch changes up to ab41305d3b7c1afa29c0b7fafce854c24445423a:
malta: define CONFIG_MEMSIZE_IN_BYTES (2013-11-09 17:21:02 +0100)
Gabor Juhos (1):
malta: define CONFIG_MEMSIZE_IN_BYTES
Paul Burton (18):
mips32: detect L1 cache sizes if they're not defined
pcnet: code style cleanup
pcnet: s/le16_to_cpu/cpu_to_le16/ in pcnet_send
pcnet: add cache flushing invalidation
pcnet: enable the NOUFLO feature
pci.h: allow inclusion in assembly source
qemu-malta: rename to just malta
malta: setup super I/O UARTs
malta: support for coreFPGA6 boards
malta: display U-boot on the LCD screen
malta: enable CONFIG_PCNET_79C973, PCNET_HAS_PROM, CONFIG_CMD_DHCP
malta: remove cache size definitions
malta: disable L2 caches
malta: enable RTC support
malta: store environment in flash
malta: setup PIIX4 interrupt route
malta: add script instructions to flash U-boot
malta: add myself to maintainers
arch/mips/cpu/mips32/cache.S| 90
+---
arch/mips/cpu/mips32/cpu.c | 73
+---
arch/mips/cpu/mips32/start.S| 2 +-
arch/mips/include/asm/malta.h | 50 ++---
arch/mips/include/asm/mipsregs.h| 6 +++
arch/mips/lib/bootm.c | 12 +++---
board/{qemu-malta = imgtec/malta}/Makefile | 3 +-
board/imgtec/malta/flash-malta-boot.tcl | 40
board/imgtec/malta/lowlevel_init.S | 238
board/imgtec/malta/malta.c | 208
+
board/imgtec/malta/superio.c| 63
+++
board/imgtec/malta/superio.h| 15
board/qemu-malta/lowlevel_init.S| 69
--
board/qemu-malta/qemu-malta.c | 47 ---
boards.cfg | 4 +-
doc/README.malta| 16
drivers/net/pcnet.c | 279
+++-
drivers/pci/Makefile| 1 +
drivers/pci/pci_msc01.c | 125
+
drivers/rtc/mc146818.c | 2 +-
include/configs/{qemu-malta.h = malta.h} | 45 +-
include/msc01.h | 135
++
include/pci.h | 6 ++-
include/pci_ids.h | 3 ++
include/pci_msc01.h | 17 +
25 files changed, 1254 insertions(+), 295 deletions(-)
rename board/{qemu-malta = imgtec/malta}/Makefile (81%)
create mode 100644 board/imgtec/malta/flash-malta-boot.tcl
create mode 100644 board/imgtec/malta/lowlevel_init.S
create mode 100644 board/imgtec/malta/malta.c
create mode 100644 board/imgtec/malta/superio.c
create mode 100644 board/imgtec/malta/superio.h
delete mode 100644 board/qemu-malta/lowlevel_init.S
delete mode 100644 board/qemu-malta/qemu-malta.c
create mode 100644 doc/README.malta
create mode 100644 drivers/pci/pci_msc01.c
rename include/configs/{qemu-malta.h = malta.h} (72%)
create mode 100644 include/msc01.h
create mode 100644 include/pci_msc01.h
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] time: fix gcc warnings on MIPS64
On Sat, Nov 09, 2013 at 12:30:14AM +0100, Daniel Schwierzeck wrote: Commit 8dfafdde88eb3e71d5569846396ae67a91017232 introduced new gcc warnings on MIPS64: time.c: In function 'tick_to_time': time.c:59:2: warning: comparison of distinct pointer types lacks a cast [enabled by default] time.c:59:2: warning: passing argument 1 of '__div64_32' from incompatible pointer type [enabled by default] In file included from time.c:10:0: ./u-boot-mips/include/div64.h:22:17: note: expected 'uint64_t *' but argument is of type 'long long unsigned int *' time.c: In function 'usec_to_tick': time.c:76:2: warning: comparison of distinct pointer types lacks a cast [enabled by default] time.c:76:2: warning: passing argument 1 of '__div64_32' from incompatible pointer type [enabled by default] In file included from time.c:10:0: ./u-boot-mips/include/div64.h:22:17: note: expected 'uint64_t *' but argument is of type 'long long unsigned int *' Signed-off-by: Daniel Schwierzeck daniel.schwierz...@gmail.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MIPS: use CONFIG_SYS_TEXT_BASE in relocation calculations
2013/11/11 Gabor Juhos juh...@openwrt.org:
The relocation code uses the CONFIG_SYS_MONITOR_BASE
constant for calculating the reserved memory size and
relocation offset values. Along with these predefined
values the code also uses several other constants which
are computed by the linker from the CONFIG_SYS_TEXT_BASE
value. Due to this, the relocation code works incorreclty
if the CONFIG_SYS_TEXT_BASE and CONFIG_SYS_MONITOR_BASE
values are different.
Change the relocation code to use the CONFIG_SYS_TEXT_BASE
constant in the calculations to avoid the problem.
Only tested in qemu with the 'malta' and 'qemu_mips{,el}'
targets.
Signed-off-by: Gabor Juhos juh...@openwrt.org
Cc: Daniel Schwierzeck daniel.schwierz...@gmail.com
Cc: Paul Burton paul.bur...@imgtec.com
---
Daniel,
This should be merged before my 'malta: use unmapped flash base address'
patch.
Thanks,
Gabor
thanks, I'll test it on real hardware.
--
- Daniel
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC] imx: add multi-architecture README
Hi all,
On 11/11/2013 11:42 AM, Eric Nelson wrote:
On 11/11/2013 08:12 AM, Eric Nelson wrote:
On 11/11/2013 05:03 AM, Tapani wrote:
On Sat, 9 Nov 2013 13:12:42 -0700
Eric Nelson eric.nel...@boundarydevices.com wrote:
...
The following is a diff with some updates, and I've attached a complete
updated version.
Can you tell me whether this bit is better, worse, similar?
...
+Or since the arrays are guaranteed to be the same size, the somewhat
+simpler form:
imx_iomux_v3_setup_multiple_pads(
-MX6REF(nitrogen_pads),
-ARRAY_SIZE(MX6REF(nitrogen_pads))
+is_cpu_type(MXC_CPU_MX6Q)
+? mx6q_nitrogen_pads
+: mx6dl_nitrogen_pads,
+ARRAY_SIZE(mx6q_nitrogen_pads)
);
-N.B. This doesn't work, since ARRAY_SIZE can't be passed this kind of
-reference...
As mentioned in my original e-mail, I wanted to get some feedback
about the most important questions:
1. Whether to turn declarations in mx6q_pins.h/mx6dl_pins.h into macros
2. Whether to double-include the same in mx6-pins.h
3. Whether to define baseline pads (the 90% case) in a header and
double-include it, and
4. Whether to macro-fy the memory layout files like
1066mhz_4x128mx16.cfg so they can be used by imximage and gcc.
I also started veering off into policy questions that need the
answers to the bits above first.
I did draft some additional notes about the straggling, un-addressed
10% of the pads though, and listed the details below.
Regards,
Eric
-
The remaining 10% of references can't be resolved in such a
simple way, and require some additional run-time logic.
In general, these are places where the pad configuration
changes at run-time, and there are two prominent instances
in the code base: ethernet pads and I2C pads.
In the ethernet case, two sets of pad settings are used
to first defines the pads as GPIOs during reset of a PHY,
and the second configures the pads for use as RGMII pins.
It is possible to use the multiple #include approach for
these as well, but there are only six pads for the second
configuration, and duplicating them is not very onerous,
so it is recommended that the initial settings be placed
into boardname-pads.h along with the others, and that
the second simply be duplicated:
static iomux_v3_cfg_t const mx6q_enet2_pads[] = {
MX6Q_PAD_RGMII_RXC__ENET_RGMII_RXC...
MX6Q_PAD_RGMII_RD0__ENET_RGMII_RD0...
...
};
static iomux_v3_cfg_t const mx6dl_enet2_pads[] = {
MX6DL_PAD_RGMII_RXC__ENET_RGMII_RXC...
MX6DL_PAD_RGMII_RD0__ENET_RGMII_RD0...
...
};
The eth_init() routine can then make a choice at run-time between
the two.
The I2C case is a bit different, in that the I2C driver will switch
between the I2C and GPIO modes. GPIO mode is used during recovery
from I2C bus, and the mux and pad settings are defined in
the i2c_pads_info structure:
struct i2c_pads_info i2c_pad_info0 = {
.scl = {
.i2c_mode = MX6_PAD_EIM_D21__I2C1_SCL | PC,
.gpio_mode = MX6_PAD_EIM_D21__GPIO_3_21 | PC,
},
.sda = {
...
I'm torn about this one. There are a total of 12 pad references (3 I2C
structures with 4 pads per structure) in some board files, and I'm
not sure whether the entire structures should be simply declared twice
or if some other macro configuration is appropriate.
This is common enough (exists in every i.MX6 board) that we should
all be doing it the same way.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Separate EBV Socrates board from Altera Cyclone 5 board
Altera Cyclone 5 board is very different board (big, rectangular,
expensive) than EBV Socrates (small, circular, cheap) board. Different
parts are used there, too, but same configuration of u-boot works on
both. Nevertheless, printing wrong name confuses users.
Therefore this splits the configuration so that u-boot knows they are
different. So far it is only used for correcting the puts, but there
may be other uses in future.
Signed-off-by: Pavel Machek pa...@denx.de
diff --git a/board/altera/socfpga/socfpga_cyclone5.c
b/board/altera/socfpga/socfpga_cyclone5.c
index 576066b..4540b1b 100644
--- a/board/altera/socfpga/socfpga_cyclone5.c
+++ b/board/altera/socfpga/socfpga_cyclone5.c
@@ -26,7 +26,7 @@ int print_cpuinfo(void)
*/
int checkboard(void)
{
- puts(BOARD : Altera SOCFPGA Cyclone5 Board\n);
+ puts(BOARD : ALTERA_BOARD_NAME \n);
return 0;
}
diff --git a/boards.cfg b/boards.cfg
index 375f2d4..20534c3 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -340,6 +340,7 @@ Active arm armv7 rmobile kmc
kzm9g
Active arm armv7 s5pc1xx samsung goni
s5p_goni -
Minkyu Kang mk7.k...@samsung.com
Active arm armv7 s5pc1xx samsung smdkc100
smdkc100 -
Minkyu Kang mk7.k...@samsung.com
Active arm armv7 socfpga altera socfpga
socfpga_cyclone5 -
-
+Active arm armv7 socfpga altera socfpga
socfpga_socrates -
-
Active arm armv7 u8500 st-ericsson snowball
snowball -
Mathieu Poirier mathieu.poir...@linaro.org
Active arm armv7 u8500 st-ericsson u8500
u8500_href -
-
Active arm armv7 vf610 freescale vf610twr
vf610twr
vf610twr:IMX_CONFIG=board/freescale/vf610twr/imximage.cfg
Alison Wang
b18...@freescale.com
diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h
new file mode 100644
index 000..6d4dfcf
--- /dev/null
+++ b/include/configs/socfpga_common.h
@@ -0,0 +1,240 @@
+/*
+ * Copyright (C) 2012 Altera Corporation www.altera.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#ifndef __CONFIG_COMMON_H
+#define __CONFIG_COMMON_H
+
+#include asm/arch/socfpga_base_addrs.h
+#include ../../board/altera/socfpga/pinmux_config.h
+
+/*
+ * High level configuration
+ */
+/* Virtual target or real hardware */
+#define CONFIG_SOCFPGA_VIRTUAL_TARGET
+
+#define CONFIG_ARMV7
+#define CONFIG_L2_OFF
+#define CONFIG_SYS_DCACHE_OFF
+#undef CONFIG_USE_IRQ
+
+#define CONFIG_MISC_INIT_R
+#define CONFIG_SINGLE_BOOTLOADER
+#define CONFIG_SOCFPGA
+
+/* base address for .text section */
+#ifdef CONFIG_SOCFPGA_VIRTUAL_TARGET
+#define CONFIG_SYS_TEXT_BASE 0x0840
+#else
+#define CONFIG_SYS_TEXT_BASE 0x0140
+#endif
+#define CONFIG_SYS_LOAD_ADDR 0x7fc0
+
+/* Console I/O Buffer Size */
+#define CONFIG_SYS_CBSIZE 256
+/* Monitor Command Prompt */
+#define CONFIG_SYS_PROMPT SOCFPGA_CYCLONE5 #
+#define CONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE + \
+ sizeof(CONFIG_SYS_PROMPT) + 16)
+
+/*
+ * Display CPU and Board Info
+ */
+#define CONFIG_DISPLAY_CPUINFO
+#define CONFIG_DISPLAY_BOARDINFO
+
+/*
+ * Enable early stage initialization at C environment
+ */
+#define CONFIG_BOARD_EARLY_INIT_F
+
+/* flat device tree */
+#define CONFIG_OF_LIBFDT
+/* skip updating the FDT blob */
+#define CONFIG_FDT_BLOB_SKIP_UPDATE
+/* Initial Memory map size for Linux, minus 4k alignment for DFT blob */
+#define CONFIG_SYS_BOOTMAPSZ ((256*1024*1024) - (4*1024))
+
+#define CONFIG_SPL_RAM_DEVICE
+#define CONFIG_SPL_STACK CONFIG_SYS_INIT_SP_ADDR
+#define CONFIG_SYS_SPL_MALLOC_START ((unsigned long) (__malloc_start))
+#define CONFIG_SYS_SPL_MALLOC_SIZE (__malloc_end -
Re: [U-Boot] [Patch v1 1/6] Driver/DDR: Moving Freescale DDR driver to a common driver
On Mon, 2013-11-11 at 11:05 -0800, York Sun wrote: On 11/11/2013 10:49 AM, Scott Wood wrote: My point is that the type of DDR that is present is hardware description, just as much as the type of DDR controller. User config means things users can choose purely in software, without a corresponding hardware change. This is a board-level configuration, not SoC level. Should we use CONFIG_SYS_ as well? Yes. If so, we need to come up with a new name, such as CONFIG_SYS_FSL_DDR_MEM_GEN3. How about CONFIG_SYS_FSL_DDR3 for the memory, and CONFIG_SYS_FSL_DDR_CTRL3 for the controller? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MIPS: use CONFIG_SYS_TEXT_BASE in relocation calculations
2013/11/11 Gabor Juhos juh...@openwrt.org: The relocation code uses the CONFIG_SYS_MONITOR_BASE constant for calculating the reserved memory size and relocation offset values. Along with these predefined values the code also uses several other constants which are computed by the linker from the CONFIG_SYS_TEXT_BASE value. Due to this, the relocation code works incorreclty if the CONFIG_SYS_TEXT_BASE and CONFIG_SYS_MONITOR_BASE values are different. to be consistent with all other architectures, we should keep CONFIG_SYS_MONITOR_BASE. I think it is neither valid nor intentional to use a value different from CONFIG_SYS_TEXT_BASE. Instead we should change include/configs/malta.h: -#define CONFIG_SYS_MONITOR_BASECONFIG_SYS_FLASH_BASE +#define CONFIG_SYS_MONITOR_BASECONFIG_SYS_TEXT_BASE Comments? -- - Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC] imx: add multi-architecture README
Hello all,
On 11/11/2013 12:18 PM, Eric Nelson wrote:
snip
As mentioned in my original e-mail, I wanted to get some feedback
about the most important questions:
1. Whether to turn declarations in mx6q_pins.h/mx6dl_pins.h into macros
2. Whether to double-include the same in mx6-pins.h
3. Whether to define baseline pads (the 90% case) in a header and
double-include it, and
4. Whether to macro-fy the memory layout files like
1066mhz_4x128mx16.cfg so they can be used by imximage and gcc.
I also started veering off into policy questions that need the
answers to the bits above first.
I did draft some additional notes about the straggling, un-addressed
10% of the pads though, and listed the details below.
snip
The I2C case is a bit different, in that the I2C driver will switch
between the I2C and GPIO modes. GPIO mode is used during recovery
from I2C bus, and the mux and pad settings are defined in
the i2c_pads_info structure:
struct i2c_pads_info i2c_pad_info0 = {
.scl = {
.i2c_mode = MX6_PAD_EIM_D21__I2C1_SCL | PC,
.gpio_mode = MX6_PAD_EIM_D21__GPIO_3_21 | PC,
},
.sda = {
...
I'm torn about this one. There are a total of 12 pad references (3 I2C
structures with 4 pads per structure) in some board files, and I'm
not sure whether the entire structures should be simply declared twice
or if some other macro configuration is appropriate.
This is common enough (exists in every i.MX6 board) that we should
all be doing it the same way.
If you've followed along with all of this, there's another alternative
to consider, which is the approach we've used in our Linux 3.0.35
kernels.
If you look at pads-mx6_nitrogen6x.h in our 3.0.35 kernel tree:
http://bit.ly/1eECBxm
You'll see something different from what I proposed for
boardname-pads.h.
Instead of simply containing a series of macro calls, this file
contains complete declarations with the names of each variable
wrapped with the macro MX6NAME():
static iomux_v3_cfg_t MX6NAME(csi0_sensor_pads)[] = {
MX6NAME is defined based on whether the FOR_DL_SOLO macro
is defined.
#ifdef FOR_DL_SOLO
#define MX6(a) MX6DL_##a
#define MX6PAD(a) MX6DL_PAD_##a
#define MX6NAME(a) mx6dl_solo_##a
#else
#define MX6(a) MX6Q_##a
#define MX6PAD(a) MX6Q_PAD_##a
#define MX6NAME(a) mx6q_##a
#endif
And the board file includes the pad header twice:
http://bit.ly/1dYWpbU
This approach requires a bit more effort to understand, but almost
completely isolates the body of the code from the question of
whether the build is for a single processor variant or supports
multiple variants.
It also addresses the question of what to do with the i2c
and ethernet pad declarations above.
Using this approach, they move into boardname-pads.h.
Regards,
Eric
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v1 1/6] Driver/DDR: Moving Freescale DDR driver to a common driver
On 11/11/2013 11:35 AM, Scott Wood wrote: On Mon, 2013-11-11 at 11:05 -0800, York Sun wrote: On 11/11/2013 10:49 AM, Scott Wood wrote: My point is that the type of DDR that is present is hardware description, just as much as the type of DDR controller. User config means things users can choose purely in software, without a corresponding hardware change. This is a board-level configuration, not SoC level. Should we use CONFIG_SYS_ as well? Yes. If so, we need to come up with a new name, such as CONFIG_SYS_FSL_DDR_MEM_GEN3. How about CONFIG_SYS_FSL_DDR3 for the memory, and CONFIG_SYS_FSL_DDR_CTRL3 for the controller? I am reluctant to change existing macro to different meaning. How about CONFIG_SYS_FSL_DDR3_MEM, or CONFIG_SYS_FSL_MEM_DDR3? York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v1 1/6] Driver/DDR: Moving Freescale DDR driver to a common driver
On Mon, 2013-11-11 at 11:37 -0800, York Sun wrote: On 11/11/2013 11:35 AM, Scott Wood wrote: On Mon, 2013-11-11 at 11:05 -0800, York Sun wrote: On 11/11/2013 10:49 AM, Scott Wood wrote: My point is that the type of DDR that is present is hardware description, just as much as the type of DDR controller. User config means things users can choose purely in software, without a corresponding hardware change. This is a board-level configuration, not SoC level. Should we use CONFIG_SYS_ as well? Yes. If so, we need to come up with a new name, such as CONFIG_SYS_FSL_DDR_MEM_GEN3. How about CONFIG_SYS_FSL_DDR3 for the memory, and CONFIG_SYS_FSL_DDR_CTRL3 for the controller? I am reluctant to change existing macro to different meaning. How about CONFIG_SYS_FSL_DDR3_MEM, or CONFIG_SYS_FSL_MEM_DDR3? CONFIG_SYS_FSL_DDR3 is not an existing macro. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v1 1/6] Driver/DDR: Moving Freescale DDR driver to a common driver
On 11/11/2013 11:59 AM, Scott Wood wrote: On Mon, 2013-11-11 at 11:37 -0800, York Sun wrote: On 11/11/2013 11:35 AM, Scott Wood wrote: On Mon, 2013-11-11 at 11:05 -0800, York Sun wrote: On 11/11/2013 10:49 AM, Scott Wood wrote: My point is that the type of DDR that is present is hardware description, just as much as the type of DDR controller. User config means things users can choose purely in software, without a corresponding hardware change. This is a board-level configuration, not SoC level. Should we use CONFIG_SYS_ as well? Yes. If so, we need to come up with a new name, such as CONFIG_SYS_FSL_DDR_MEM_GEN3. How about CONFIG_SYS_FSL_DDR3 for the memory, and CONFIG_SYS_FSL_DDR_CTRL3 for the controller? I am reluctant to change existing macro to different meaning. How about CONFIG_SYS_FSL_DDR3_MEM, or CONFIG_SYS_FSL_MEM_DDR3? CONFIG_SYS_FSL_DDR3 is not an existing macro. Oh. My mistake. We can use CONFIG_SYS_FSL_DDR3 for the memory. But I prefer to keep CONFIG_SYS_FSL_DDR_PPC_GEN3 or use CONFIG_SYS_FSL_DDRC_GEN3 if it can be merged with ARM controller. CTRL3 is misleading. It makes me thinking of controller #3. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v1 1/6] Driver/DDR: Moving Freescale DDR driver to a common driver
On Mon, 2013-11-11 at 12:15 -0800, York Sun wrote: On 11/11/2013 11:59 AM, Scott Wood wrote: On Mon, 2013-11-11 at 11:37 -0800, York Sun wrote: On 11/11/2013 11:35 AM, Scott Wood wrote: On Mon, 2013-11-11 at 11:05 -0800, York Sun wrote: On 11/11/2013 10:49 AM, Scott Wood wrote: My point is that the type of DDR that is present is hardware description, just as much as the type of DDR controller. User config means things users can choose purely in software, without a corresponding hardware change. This is a board-level configuration, not SoC level. Should we use CONFIG_SYS_ as well? Yes. If so, we need to come up with a new name, such as CONFIG_SYS_FSL_DDR_MEM_GEN3. How about CONFIG_SYS_FSL_DDR3 for the memory, and CONFIG_SYS_FSL_DDR_CTRL3 for the controller? I am reluctant to change existing macro to different meaning. How about CONFIG_SYS_FSL_DDR3_MEM, or CONFIG_SYS_FSL_MEM_DDR3? CONFIG_SYS_FSL_DDR3 is not an existing macro. Oh. My mistake. We can use CONFIG_SYS_FSL_DDR3 for the memory. But I prefer to keep CONFIG_SYS_FSL_DDR_PPC_GEN3 or use CONFIG_SYS_FSL_DDRC_GEN3 if it can be merged with ARM controller. CTRL3 is misleading. It makes me thinking of controller #3. OK. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
