Re: [U-Boot] Please pull u-boot-ti/master
Hi Tom, Le 23/04/2012 19:19, Tom Rini a écrit : Hello, The following changes since commit 5697158fd27c9cc938eb3e3308e3c1483a2a1ef8: Tom Rini (1): include/configs: Remove CONFIG_SYS_64BIT_STRTOUL are available in the git repository at: git://git.denx.de/u-boot-ti master Nikita Kiryanov (1): cm-t35: add I2C multi-bus support Nobuhiro Iwamatsu (2): arm: cam_enc_4xx: Change macro from BOARD_LATE_INIT to CONFIG_BOARD_LATE_INIT arm: ea20: Change macro from BOARD_LATE_INIT to CONFIG_BOARD_LATE_INIT board/cm_t35/cm_t35.c |6 ++ board/davinci/ea20/ea20.c |4 ++-- include/configs/cam_enc_4xx.h |2 +- include/configs/cm_t35.h |1 + include/configs/ea20.h|2 +- 5 files changed, 11 insertions(+), 4 deletions(-) Applied to u-boot-arm/master, thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RESEND 0/2] mmc:fix: MMC fixes for generic mmc driver running at GONI
Hi Andy, > Those two patches have been combined together for easier review. > > Both fixes corner cases caught on the Samsung's GONI target. > Namely: > - lack of call to mmc_init with fat handling > - Not setting MMC capabilities according to host capabilities > > > Lukasz Majewski (2): > mmc:fix: Set mmc width according to MMC host capabilities > mmc:fix Call mmc_init() when executing mmc_get_dev() > > drivers/mmc/mmc.c |9 +++-- > include/mmc.h |3 +++ > 2 files changed, 10 insertions(+), 2 deletions(-) > Hi Andy, Are those fixes acceptable for the mmc subsystem? Both have spent quite some time on the mailing list. -- Best regards, Lukasz Majewski Samsung Poland R&D Center | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] EXYNOS: Change bits per pixel value proper for u-boot.
On 24 April 2012 20:44, Anatolij Gustschin wrote: > Hi, > > On Tue, 24 Apr 2012 10:37:05 +0900 > Donghwa Lee wrote: > >> vl_bpix of vidinfo_t was changed proper value for u-boot. >> It is used to multiple of 2 by using NBITS() macro. >> >> Signed-off-by: Donghwa Lee >> Signed-off-by: Kyungmin Park >> --- >> board/samsung/trats/trats.c | 2 +- >> drivers/video/exynos_fb.c | 2 +- >> drivers/video/exynos_fimd.c | 6 +++--- >> 3 files changed, 5 insertions(+), 5 deletions(-) > > Acked-by: Anatolij Gustschin > applied to u-boot-samsung. Thanks Minkyu Kang. -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] please pull u-boot-samsung/master
Dear Albert, The following changes since commit 6e7c76a15753f3a5e1b94df372392a08e4b11b02: arm: ea20: Change macro from BOARD_LATE_INIT to CONFIG_BOARD_LATE_INIT (2012-04-23 09:15:23 -0700) are available in the git repository at: git://git.denx.de/u-boot-samsung master Chander Kashyap (1): EXYNOS: Rename exynos5_tzpc structure to exynos_tzpc Donghwa Lee (8): EXYNOS: definitions of system resgister and power management registers. EXYNOS: add LCD and MIPI DSI clock interface. LCD: add data structure for EXYNOS display driver EXYNOS: support EXYNOS framebuffer and FIMD display drivers. EXYNOS: support EXYNOS MIPI DSI interface driver. LCD: support S6E8AX0 amoled driver based on EXYNOS MIPI DSI EXYNOS: support TRATS board display function EXYNOS: Change bits per pixel value proper for u-boot. Jaehoon Chung (1): TRATS: modify the trats's configuration Minkyu Kang (1): SMDK5250: fix compiler warning Łukasz Majewski (3): ARM: Exynos4: ADC: Universal_C210: Enable LDO4 power line for ADC measurement misc:pmic:max8997 MAX8997 support for PMIC driver misc:pmic:samsung Convert TRATS target to use MAX8997 instead of MAX8998 arch/arm/cpu/armv7/exynos/Makefile |2 +- arch/arm/cpu/armv7/exynos/clock.c| 184 arch/arm/cpu/armv7/exynos/power.c| 54 +++ arch/arm/cpu/armv7/exynos/system.c | 48 ++ arch/arm/include/asm/arch-exynos/clk.h |3 + arch/arm/include/asm/arch-exynos/cpu.h |5 + arch/arm/include/asm/arch-exynos/dsim.h | 181 +++ arch/arm/include/asm/arch-exynos/fb.h| 446 ++ arch/arm/include/asm/arch-exynos/mipi_dsim.h | 380 +++ arch/arm/include/asm/arch-exynos/power.h |6 + arch/arm/include/asm/arch-exynos/system.h| 53 ++ arch/arm/include/asm/arch-exynos/tzpc.h |2 +- board/samsung/smdk5250/tzpc_init.c |4 +- board/samsung/trats/trats.c | 173 ++- board/samsung/universal_c210/universal.c | 25 +- drivers/misc/Makefile|1 + drivers/misc/pmic_max8997.c | 43 ++ drivers/video/Makefile |4 + drivers/video/exynos_fb.c| 128 + drivers/video/exynos_fb.h| 61 +++ drivers/video/exynos_fimd.c | 354 ++ drivers/video/exynos_mipi_dsi.c | 253 ++ drivers/video/exynos_mipi_dsi_common.c | 637 + drivers/video/exynos_mipi_dsi_common.h | 48 ++ drivers/video/exynos_mipi_dsi_lowlevel.c | 652 ++ drivers/video/exynos_mipi_dsi_lowlevel.h | 111 + drivers/video/s6e8ax0.c | 256 ++ include/configs/trats.h | 15 +- include/lcd.h| 64 +++ include/max8997_pmic.h | 190 include/max8998_pmic.h |1 + 31 files changed, 4356 insertions(+), 28 deletions(-) create mode 100644 arch/arm/cpu/armv7/exynos/power.c create mode 100644 arch/arm/cpu/armv7/exynos/system.c create mode 100644 arch/arm/include/asm/arch-exynos/dsim.h create mode 100644 arch/arm/include/asm/arch-exynos/fb.h create mode 100644 arch/arm/include/asm/arch-exynos/mipi_dsim.h create mode 100644 arch/arm/include/asm/arch-exynos/system.h create mode 100644 drivers/misc/pmic_max8997.c create mode 100644 drivers/video/exynos_fb.c create mode 100644 drivers/video/exynos_fb.h create mode 100644 drivers/video/exynos_fimd.c create mode 100644 drivers/video/exynos_mipi_dsi.c create mode 100644 drivers/video/exynos_mipi_dsi_common.c create mode 100644 drivers/video/exynos_mipi_dsi_common.h create mode 100644 drivers/video/exynos_mipi_dsi_lowlevel.c create mode 100644 drivers/video/exynos_mipi_dsi_lowlevel.h create mode 100644 drivers/video/s6e8ax0.c create mode 100644 include/max8997_pmic.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] LCD: change s6e8ax0 panel gamma value
s6e8ax0 panel init gamma value is changed because existing it was not
proper value for this panel.
Signed-off-by: Donghwa Lee
Signed-off-by: Kyungmin Park
Signed-off-by: Inki Dae
---
drivers/video/s6e8ax0.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/video/s6e8ax0.c b/drivers/video/s6e8ax0.c
index 1ec7fd6..02c5ccf 100644
--- a/drivers/video/s6e8ax0.c
+++ b/drivers/video/s6e8ax0.c
@@ -55,11 +55,11 @@ static void s6e8ax0_display_cond(struct mipi_dsim_device
*dsim_dev)
static void s6e8ax0_gamma_cond(struct mipi_dsim_device *dsim_dev)
{
struct mipi_dsim_master_ops *ops = dsim_dev->master_ops;
- /* 7500K 2.2 Set (M3, 300cd) */
+ /* 7500K 2.2 Set : 30cd */
const unsigned char data_to_send[] = {
- 0xfa, 0x01, 0x0f, 0x00, 0x0f, 0xda, 0xc0, 0xe4, 0xc8,
- 0xc8, 0xc6, 0xd3, 0xd6, 0xd0, 0xab, 0xb2, 0xa6, 0xbf,
- 0xc2, 0xb9, 0x00, 0x93, 0x00, 0x86, 0x00, 0xd1
+ 0xfa, 0x01, 0x60, 0x10, 0x60, 0xf5, 0x00, 0xff, 0xad,
+ 0xaf, 0xba, 0xc3, 0xd8, 0xc5, 0x9f, 0xc6, 0x9e, 0xc1,
+ 0xdc, 0xc0, 0x00, 0x61, 0x00, 0x5a, 0x00, 0x74,
};
ops->cmd_write(dsim_dev, MIPI_DSI_DCS_LONG_WRITE,
--
1.7.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 4/4] lin_gadget: use common linux/compat.h
From: Mike Frysinger
Merge our duplicate definitions with the common header.
Also fix drivers/usb/gadget/s3c_udc_otg_xfer_dma.c to
use min() instead of min_t() since we remove the latter
from compat.h.
Signed-off-by: Mike Frysinger
Signed-off-by: Anatolij Gustschin
---
v2:
- fix build breakage:
In file included from s3c_udc_otg.c:212:0:
s3c_udc_otg_xfer_dma.c: In function 'setdma_tx':
s3c_udc_otg_xfer_dma.c:171:47: error: macro "min_t" requires 3 arguments,
but only 2 given
s3c_udc_otg_xfer_dma.c:171:12: error: 'min_t' undeclared (first use in this
function)
drivers/usb/gadget/s3c_udc_otg_xfer_dma.c |2 +-
include/linux/compat.h|3 +++
include/usb/lin_gadget_compat.h | 15 ++-
3 files changed, 6 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/gadget/s3c_udc_otg_xfer_dma.c
b/drivers/usb/gadget/s3c_udc_otg_xfer_dma.c
index afd4931..56e6e53 100644
--- a/drivers/usb/gadget/s3c_udc_otg_xfer_dma.c
+++ b/drivers/usb/gadget/s3c_udc_otg_xfer_dma.c
@@ -168,7 +168,7 @@ int setdma_tx(struct s3c_ep *ep, struct s3c_request *req)
length = req->req.length - req->req.actual;
if (ep_num == EP0_CON)
- length = min_t(length, (u32)ep_maxpacket(ep));
+ length = min(length, (u32)ep_maxpacket(ep));
ep->len = length;
ep->dma_buf = buf;
diff --git a/include/linux/compat.h b/include/linux/compat.h
index 39c693f..593b07f 100644
--- a/include/linux/compat.h
+++ b/include/linux/compat.h
@@ -48,5 +48,8 @@
#define BUG_ON(condition) do { if (condition) BUG(); } while(0)
#endif /* BUG */
+#define WARN_ON(x) if (x) {printf("WARNING in %s line %d\n" \
+ , __FILE__, __LINE__); }
+
#define PAGE_SIZE 4096
#endif
diff --git a/include/usb/lin_gadget_compat.h b/include/usb/lin_gadget_compat.h
index 1b937e4..8287b9d 100644
--- a/include/usb/lin_gadget_compat.h
+++ b/include/usb/lin_gadget_compat.h
@@ -23,6 +23,8 @@
#ifndef __LIN_COMPAT_H__
#define __LIN_COMPAT_H__
+#include
+
/* common */
#define spin_lock_init(...)
#define spin_lock(...)
@@ -36,25 +38,12 @@
#define mutex_lock(...)
#define mutex_unlock(...)
-#define WARN_ON(x) if (x) {printf("WARNING in %s line %d\n" \
- , __FILE__, __LINE__); }
-
-#define KERN_WARNING
-#define KERN_ERR
-#define KERN_NOTICE
-#define KERN_DEBUG
-
#define GFP_KERNEL 0
#define IRQ_HANDLED1
#define ENOTSUPP 524 /* Operation is not supported */
-#define kmalloc(size, type) memalign(CONFIG_SYS_CACHELINE_SIZE, size)
-#define kfree(addr) free(addr)
-
-#define __iomem
-#define min_t min
#define dma_cache_maint(addr, size, mode) cache_flush()
void cache_flush(void);
--
1.7.7.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] kwboot: Boot Marvell Kirkwood SoCs over a serial link.
> -Original Message- > From: u-boot-boun...@lists.denx.de [mailto:u-boot- > boun...@lists.denx.de] On Behalf Of Daniel Stodden > Sent: 24 April 2012 11:37 > To: U-Boot > Subject: [U-Boot] [PATCH] kwboot: Boot Marvell Kirkwood SoCs over a > serial link. Hi Daniel Pls maintain change log, each version information in the patch as per guidelines. Regards.. Prafulla . . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] LCD: change s6e8ax0 panel gamma value
Hi, On Wed, 25 Apr 2012 17:04:39 +0900 Donghwa Lee wrote: > s6e8ax0 panel init gamma value is changed because existing it was not > proper value for this panel. > > Signed-off-by: Donghwa Lee > Signed-off-by: Kyungmin Park > Signed-off-by: Inki Dae > --- > drivers/video/s6e8ax0.c |8 > 1 files changed, 4 insertions(+), 4 deletions(-) Looks good. I'll apply this patch after the u-boot-samsung tree merge. Thanks! Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] Allow for parallel builds and saved output
Hi Andy,
Le 25/04/2012 07:33, Andy Fleming a écrit :
The MAKEALL script cleverly runs make with the appropriate options
to use all of the cores on the system, but your average U-Boot build
can't make much use of more than a few cores. If you happen to have
a many-core server, your builds will leave most of the system idle.
In order to make full use of such a system, we need to build multiple
targets in parallel, and this requires directing make output into
multiple directories. We add a BUILD_NBUILDS variable, which allows
users to specify how many builds to run in parallel.
When BUILD_NBUILDS is set greater than 1, we redefine BUILD_DIR for
each build to be ${BUILD_DIR}/${target}. Also, we make "./build" the
default BUILD_DIR when BUILD_NBUILDS is greater than 1.
MAKEALL now tracks which builds are still running, and when one
finishes, it starts a new build.
Once each build finishes, we run "make tidy" on its directory, to reduce
the footprint.
As a result, we are left with a build directory with all of the built
targets still there for use, which means anyone who wanted to use
MAKEALL as part of a test harness can now do so.
Signed-off-by: Andy Fleming
---
v2: - Update to keep BUILD_NBUILDS builds in flight, rather than batching
- Clean up style things
- Defer error output until build completion to make output *slightly*
more readable
v3: - Add BUILD_MANY variable to clarify logic
- Added comment for done/skip prefixes, and renamed for clarity
- Changed CURRENT_COUNT to CURRENT_CNT to match TOTAL_CNT
- Put build wait logic into its own manage_build function
- Used wildcards to delete build management files
- Fixed a bug where error-less builds printed an error
For ./MAKEALL arm, using cs2011-09, 7 builds 1 cpu on a 8 thread machine:
real29m20.272s
user95m59.708s
sys 10m17.383s
without the patch, and
real20m26.480s
user100m1.155s
sys 8m34.988s
with it, so there is definitely a benefit.
*However*, two boards build without and do not build clean with: scpu
and pndb3.
Also, the final report is not displayed as the same with and without the
patch -- with it, unclean boards are listed one per line, without it,
they are listed in a single line.
Last: breaking during a parallel build then trying a git clean -xfd
causes errors such as files missing.
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4][v4] doc:Add documentation for e500 external debugger support
This describes requirement of e500 and e500v2 processor to support external debugger. It also provide an insight of the configuration switch required and their description. Signed-off-by: Radu Lazarescu Signed-off-by: Marius Grigoras Signed-off-by: Prabhakar Kushwaha --- Based upon git://git.denx.de/u-boot.git branch master Changes for v2: - Recreated README.mpc85xx - Added #define in README Changes for v3: Incorporated Scott's comments - Moved config switch to "85xx CPU options" - Added TLB entry information Changes for v4: - rebased for top of the tree - updated missing secure boot temporary TLB info Tested on - SoC having E500 Family processor (P1010RDB, BSC9131RDB) - SoC having E500MC Family processor (P4080DS, P3041DS) README |9 +++ doc/README.mpc85xx | 166 2 files changed, 175 insertions(+), 0 deletions(-) create mode 100644 doc/README.mpc85xx diff --git a/README b/README index 43074cf..2e11c88 100644 --- a/README +++ b/README @@ -374,6 +374,15 @@ The following options need to be configured: Defines the string to utilize when trying to match PCIe device tree nodes for the given platform. + CONFIG_SYS_PPC_E500_DEBUG_TLB + + Enables a temporary TLB entry to be used during boot to work + around limitations in e500v1 and e500v2 external debugger + support. This reduces the portions of the boot code where + breakpoints and single stepping do not work. The value of this + symbol should be set to the TLB1 entry to be used for this + purpose. + - Generic CPU options: CONFIG_SYS_BIG_ENDIAN, CONFIG_SYS_LITTLE_ENDIAN diff --git a/doc/README.mpc85xx b/doc/README.mpc85xx new file mode 100644 index 000..2753b45 --- /dev/null +++ b/doc/README.mpc85xx @@ -0,0 +1,166 @@ +External Debug Support +-- + +Freescale's e500v1 and e500v2 cores (used in mpc85xx chips) have some +restrictions on external debugging (JTAG). In particular, for the debugger to +be able to receive control after a single step or breakpoint: + - MSR[DE] must be set + - A valid opcode must be fetchable, through the MMU, from the debug + exception vector (IVPR + IVOR15). + +To maximize the time during which this requirement is met, U-Boot sets MSR[DE] +immediately on entry and keeps it set. It also uses a temporary TLB to keep a +mapping to a valid opcode at the debug exception vector, even if we normally +don't support exception vectors being used that early, and that's not the area +where U-Boot currently executes from. + +Note that there may still be some small windows where debugging will not work, +such as in between updating IVPR and IVOR15. + +Config Switches: + + +Please refer README section "MPC85xx External Debug Support" + +Major Config Switches during various boot Modes +-- + +NOR boot +!defined(CONFIG_SYS_RAMBOOT) +NOR boot Secure +!defined(CONFIG_SYS_RAMBOOT) && defined(CONFIG_SECURE_BOOT) +RAMBOOT(SD, SPI & NAND boot) + defined(CONFIG_SYS_RAMBOOT) +RAMBOOT Secure (SD, SPI & NAND) + defined(CONFIG_SYS_RAMBOOT) && defined(CONFIG_SECURE_BOOT) +NAND SPL BOOT + defined(CONFIG_SYS_RAMBOOT) && defined(CONFIG_NAND_SPL) + + +TLB Entries during u-boot execution +--- + +Note: Sequence number is in order of execution + +A) defined(CONFIG_SYS_RAMBOOT) i.e. SD, SPI, NAND RAMBOOT & NAND_SPL boot + + 1) TLB entry to overcome e500 v1/v2 debug restriction + Location : Label "_start_e500" + TLB Entry : CONFIG_SYS_PPC_E500_DEBUG_TLB + EPN -->RPN : CONFIG_SYS_MONITOR_BASE --> CONFIG_SYS_MONITOR_BASE + Properties : 256K, AS0, I, IPROT + + 2) TLB entry for working in AS1 + Location : Label "create_init_ram_area" + TLB Entry : 15 + EPN -->RPN : CONFIG_SYS_MONITOR_BASE --> CONFIG_SYS_MONITOR_BASE + Properties : 1M, AS1, I, G, IPROT + + 3) TLB entry for the stack during AS1 + Location : Lable "create_init_ram_area" + TLB Entry : 14 + EPN -->RPN : CONFIG_SYS_INIT_RAM_ADDR --> CONFIG_SYS_INIT_RAM_ADDR + Properties : 16K, AS1, IPROT + + 4) TLB entry for CCSRBAR during AS1 execution + Location : cpu_init_early_f + TLB Entry : 13 + EPN -->RPN : CONFIG_SYS_CCSRBAR --> CONFIG_SYS_CCSRBAR + Properties : 1M, AS1, I, G + + 5) Invalidate unproctected TLB Entries + Location : cpu_init_early_f + Invalidated: 13 + + 6) Create TLB entries as per boards/freescale//tlb.c + Location : cpu_init_early_f --> init_tlbs() + Properties : ..., AS0, ... + Please note It can overwrites previous TLB Entries. + + 7) Disable TLB Entries
[U-Boot] [PATCH 2/4][v2] powerpc/85xx:Fix MSR[DE] bit in MSR to support debugger
Debugging of e500 and e500v1 processer requires MSR[DE] bit to be set always. Where MSR = Machine State register Make sure of MSR[DE] bit is set uniformaly across the different execution address space i.e. AS0 and AS1. Signed-off-by: Radu Lazarescu Signed-off-by: Catalin Udma Signed-off-by: Marius Grigoras Signed-off-by: Prabhakar Kushwaha --- Based upon git://git.denx.de/u-boot.git branch master Changes for v2: - Avoid MSR_DE negation in arch_preboot - Made MSR_DE set code independent of any #define No change, Resending again Tested on - SoC having E500 Family processor (P1010RDB, BSC9131RDB) - SoC having E500MC Family processor (P4080DS, P3041DS) arch/powerpc/cpu/mpc85xx/cpu_init.c |2 +- arch/powerpc/cpu/mpc85xx/start.S|7 +-- 2 files changed, 6 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c b/arch/powerpc/cpu/mpc85xx/cpu_init.c index 2e4a06c..3bcbffa 100644 --- a/arch/powerpc/cpu/mpc85xx/cpu_init.c +++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c @@ -532,7 +532,7 @@ void arch_preboot_os(void) * disabled by the time we get called. */ msr = mfmsr(); - msr &= ~(MSR_ME|MSR_CE|MSR_DE); + msr &= ~(MSR_ME|MSR_CE); mtmsr(msr); setup_ivors(); diff --git a/arch/powerpc/cpu/mpc85xx/start.S b/arch/powerpc/cpu/mpc85xx/start.S index 7bfa2d5..597151b 100644 --- a/arch/powerpc/cpu/mpc85xx/start.S +++ b/arch/powerpc/cpu/mpc85xx/start.S @@ -82,6 +82,9 @@ .globl _start_e500 _start_e500: +/* Enable debug exception */ + li r1,MSR_DE + mtmsr r1 #if defined(CONFIG_SECURE_BOOT) && defined(CONFIG_E500MC) /* ISBC uses L2 as stack. @@ -729,8 +732,8 @@ create_init_ram_area: msync tlbwe - lis r6,MSR_IS|MSR_DS@h - ori r6,r6,MSR_IS|MSR_DS@l + lis r6,MSR_IS|MSR_DS|MSR_DE@h + ori r6,r6,MSR_IS|MSR_DS|MSR_DE@l lis r7,switch_as@h ori r7,r7,switch_as@l -- 1.7.5.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4][v4] powerpc/85xx:Make debug exception vector accessible
Debugging of e500 and e500v1 processer requires debug exception vecter (IVPR +
IVOR15) to have valid and fetchable OP code.
While executing in translated space (AS=1), whenever a debug exception is
generated, the MSR[DS/IS] gets cleared i.e. AS=0 and the processor tries to
fetch an instruction from the debug exception vector (IVPR + IVOR15); since now
we are in AS=0, the application needs to ensure the proper TLB configuration to
have (IVOR + IVOR15) accessible from AS=0 also.
Create a temporary TLB in AS0 to make sure debug exception verctor is
accessible on debug exception.
Signed-off-by: Radu Lazarescu
Signed-off-by: Marius Grigoras
Signed-off-by: Prabhakar Kushwaha
---
Based upon git://git.denx.de/u-boot.git branch master
Changes for v2:
- Put Temporary TLB creation under #define
Changes for v3:
- Removed unnecessary CONFIG_E500
- Updated CONFG_SYS_RAMBOOT mas2 properties
- Added secure boot Debug TLB.
- Avoid temp TLB creation for NAND SPL
- removed unnecessary mas7 updation
Changes for v4: Incorporated Andy Fleming's comments
- Removed temporary TLB #define for P1010.
Please note a separte patch will be send for the same
Tested on
- SoC having E500 Family processor (P1010RDB, BSC9131RDB)
- SoC having E500MC Family processor (P4080DS, P3041DS)
arch/powerpc/cpu/mpc85xx/cpu_init_early.c | 32 +-
arch/powerpc/cpu/mpc85xx/start.S | 66 +
2 files changed, 97 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
b/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
index 091af7c..dacfdd1 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
@@ -1,5 +1,5 @@
/*
- * Copyright 2009-2011 Freescale Semiconductor, Inc
+ * Copyright 2009-2012 Freescale Semiconductor, Inc
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
@@ -53,6 +53,36 @@ void setup_ifc(void)
asm volatile("isync;msync;tlbwe;isync");
+#if defined(CONFIG_SYS_PPC_E500_DEBUG_TLB)
+/*
+ * TLB entry for debuggging in AS1
+ * Create temporary TLB entry in AS0 to handle debug exception
+ * As on debug exception MSR is cleared i.e. Address space is changed
+ * to 0. A TLB entry (in AS0) is required to handle debug exception generated
+ * in AS1.
+ *
+ * TLB entry is created for IVPR + IVOR15 to map on valid OP code address
+ * bacause flash's physical address is going to change as
+ * CONFIG_SYS_FLASH_BASE_PHYS.
+ */
+ _mas0 = MAS0_TLBSEL(1) |
+ MAS0_ESEL(CONFIG_SYS_PPC_E500_DEBUG_TLB);
+ _mas1 = MAS1_VALID | MAS1_TID(0) | MAS1_IPROT |
+ MAS1_TSIZE(BOOKE_PAGESZ_4M);
+ _mas2 = FSL_BOOKE_MAS2(CONFIG_SYS_TEXT_BASE, MAS2_I|MAS2_G);
+ _mas3 = FSL_BOOKE_MAS3(flash_phys, 0, MAS3_SW|MAS3_SR|MAS3_SX);
+ _mas7 = FSL_BOOKE_MAS7(flash_phys);
+
+ mtspr(MAS0, _mas0);
+ mtspr(MAS1, _mas1);
+ mtspr(MAS2, _mas2);
+ mtspr(MAS3, _mas3);
+ mtspr(MAS7, _mas7);
+
+ asm volatile("isync;msync;tlbwe;isync");
+#endif
+
+ /* Change flash's physical address */
out_be32(&(ifc_regs->cspr_cs[0].cspr), CONFIG_SYS_CSPR0);
out_be32(&(ifc_regs->csor_cs[0].csor), CONFIG_SYS_CSOR0);
out_be32(&(ifc_regs->amask_cs[0].amask), CONFIG_SYS_AMASK0);
diff --git a/arch/powerpc/cpu/mpc85xx/start.S b/arch/powerpc/cpu/mpc85xx/start.S
index 597151b..1cfd08a 100644
--- a/arch/powerpc/cpu/mpc85xx/start.S
+++ b/arch/powerpc/cpu/mpc85xx/start.S
@@ -182,6 +182,72 @@ l2_disabled:
andi. r1,r3,L1CSR0_DCE@l
beq 2b
+#if defined(CONFIG_SYS_PPC_E500_DEBUG_TLB)
+/*
+ * TLB entry for debuggging in AS1
+ * Create temporary TLB entry in AS0 to handle debug exception
+ * As on debug exception MSR is cleared i.e. Address space is changed
+ * to 0. A TLB entry (in AS0) is required to handle debug exception generated
+ * in AS1.
+ */
+
+ lis r6,FSL_BOOKE_MAS0(1,
+ CONFIG_SYS_PPC_E500_DEBUG_TLB, 0)@h
+ ori r6,r6,FSL_BOOKE_MAS0(1,
+ CONFIG_SYS_PPC_E500_DEBUG_TLB, 0)@l
+
+#if !defined(CONFIG_SYS_RAMBOOT) && !defined(CONFIG_SECURE_BOOT)
+/*
+ * TLB entry is created for IVPR + IVOR15 to map on valid OP code address
+ * bacause flash's virtual address maps to 0xff80 - 0x.
+ * and this window is outside of 4K boot window.
+ */
+ lis r7,FSL_BOOKE_MAS1(1, 1, 0, 0, BOOKE_PAGESZ_4M)@h
+ ori r7,r7,FSL_BOOKE_MAS1(1, 1, 0, 0, BOOKE_PAGESZ_4M)@l
+
+ lis r8,FSL_BOOKE_MAS2(CONFIG_SYS_MONITOR_BASE & 0xffc0,
+ (MAS2_I|MAS2_G))@h
+ ori r8,r8,FSL_BOOKE_MAS2(CONFIG_SYS_MONITOR_BASE & 0xffc0,
+ (MAS2_I|MAS2_G))@l
+
+ /* The 85xx has the
[U-Boot] [PATCH 4/4][v2] powerpc/85xx:Fix NAND code base to support debugger
Update NAND code base to ovecome e500 and e500v2's second limitation i.e. IVPR + IVOR15 should be valid fetchable OP code address. As NAND SPL does not compile vector table so making sure IVOR + IVOR15 points to any fetchable valid data Signed-off-by: Radu Lazarescu Signed-off-by: Marius Grigoras Signed-off-by: Prabhakar Kushwaha --- Based upon git://git.denx.de/u-boot.git branch master Changes for v2: - Removed unnecessary CONFIG_E500 - Avoid TLB creation for NAND_SPL Tested on - SoC having E500 Family processor (P1010RDB, BSC9131RDB) - SoC having E500MC Family processor (P4080DS, P3041DS) No change, Resending again arch/powerpc/cpu/mpc85xx/start.S | 20 ++-- 1 files changed, 14 insertions(+), 6 deletions(-) diff --git a/arch/powerpc/cpu/mpc85xx/start.S b/arch/powerpc/cpu/mpc85xx/start.S index 1cfd08a..92d65af 100644 --- a/arch/powerpc/cpu/mpc85xx/start.S +++ b/arch/powerpc/cpu/mpc85xx/start.S @@ -182,7 +182,7 @@ l2_disabled: andi. r1,r3,L1CSR0_DCE@l beq 2b -#if defined(CONFIG_SYS_PPC_E500_DEBUG_TLB) +#if defined(CONFIG_SYS_PPC_E500_DEBUG_TLB) && !defined(CONFIG_NAND_SPL) /* * TLB entry for debuggging in AS1 * Create temporary TLB entry in AS0 to handle debug exception @@ -1437,17 +1437,25 @@ relocate_code: 7: sync/* Wait for all icbi to complete on bus */ isync - /* -* Re-point the IVPR at RAM -*/ - mtspr IVPR,r10 - /* * We are done. Do not return, instead branch to second part of board * initialization, now running from RAM. */ addir0,r10,in_ram - _start + _START_OFFSET + +#if defined(CONFIG_NAND_SPL) +/* + * As IVPR is going to point RAM address, + * Make sure IVOR15 has valid opcode to support debugger + */ + mtspr IVOR15,r0 +#endif + /* +* Re-point the IVPR at RAM +*/ + mtspr IVPR,r10 + mtlrr0 blr /* NEVER RETURNS! */ .globl in_ram -- 1.7.5.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/mpc85xx:Add debugger support for P1010 and P1014
P1010 and P1014 SoC has e500v2 processor. And Freescale's e500v1 and e500v2 cores (used in mpc85xx chips) have some restrictions on external debugging (JTAG). So define CONFIG_SYS_PPC_E500_DEBUG_TLB to enable a temporary TLB entry to be used during boot to work around the limitations. Please refer doc/README.mpc85xx for more information Signed-off-by: Radu Lazarescu Signed-off-by: Prabhakar Kushwaha --- arch/powerpc/include/asm/config_mpc85xx.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/include/asm/config_mpc85xx.h b/arch/powerpc/include/asm/config_mpc85xx.h index 8654625..5a70be7 100644 --- a/arch/powerpc/include/asm/config_mpc85xx.h +++ b/arch/powerpc/include/asm/config_mpc85xx.h @@ -107,6 +107,7 @@ #define CONFIG_MAX_CPUS1 #define CONFIG_FSL_SDHC_V2_3 #define CONFIG_SYS_FSL_NUM_LAWS12 +#define CONFIG_SYS_PPC_E500_DEBUG_TLB 3 #define CONFIG_TSECV2 #define CONFIG_SYS_FSL_SEC_COMPAT 4 #define CONFIG_FSL_SATA_V2 @@ -160,6 +161,7 @@ #define CONFIG_MAX_CPUS1 #define CONFIG_FSL_SDHC_V2_3 #define CONFIG_SYS_FSL_NUM_LAWS12 +#define CONFIG_SYS_PPC_E500_DEBUG_TLB 3 #define CONFIG_TSECV2 #define CONFIG_SYS_FSL_SEC_COMPAT 4 #define CONFIG_FSL_SATA_V2 -- 1.7.5.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Remove remaining mdelay() macros
Drop mdelay() macros since we already have a common mdelay() func.
Signed-off-by: Anatolij Gustschin
---
drivers/block/sata_sil.c |1 -
drivers/video/da8xx-fb.c |1 -
2 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/block/sata_sil.c b/drivers/block/sata_sil.c
index 5e7ef5e..fb7cd2a 100644
--- a/drivers/block/sata_sil.c
+++ b/drivers/block/sata_sil.c
@@ -30,7 +30,6 @@
/* Convert sectorsize to wordsize */
#define ATA_SECTOR_WORDS (ATA_SECT_SIZE/2)
-#define mdelay(n) udelay((n)*1000)
#define virt_to_bus(devno, v) pci_virt_to_mem(devno, (void *) (v))
static struct sata_info sata_info;
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index a2981b1..30c19b3 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -121,7 +121,6 @@ struct da8xx_lcd_regs {
#define LOWER_MARGIN 32
#define calc_fbsize() (panel.plnSizeX * panel.plnSizeY * panel.gdfBytesPP)
-#define mdelay(n) ({unsigned long msec = (n); while (msec--) udelay(1000); })
static struct da8xx_lcd_regs *da8xx_fb_reg_base;
--
1.7.7.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] P4080/PBL: add tool to support pbl image build.
Hi, On Wed, 16 Mar 2011 10:11:03 +0800 Shaohui Xie wrote: > The tool can build u-boot image which can be used by PBL, > run "make P4080DS_RAMBOOT_PBL" can make all works done, > the default output image is u-boot.pbl, for more details > please refer to doc/README.pblimage. > > Signed-off-by: Shaohui Xie > --- > Makefile|5 + > board/freescale/corenet_ds/config.mk| 26 +++ > board/freescale/corenet_ds/pblimage.cfg | 59 ++ > common/image.c |1 + > doc/README.pblimage | 83 > include/image.h |1 + > tools/Makefile |2 + > tools/mkimage.c |5 + > tools/mkimage.h |2 + > tools/pblimage.c| 329 > +++ > tools/pblimage.h| 36 > 11 files changed, 549 insertions(+), 0 deletions(-) > create mode 100644 board/freescale/corenet_ds/config.mk > create mode 100644 board/freescale/corenet_ds/pblimage.cfg > create mode 100644 doc/README.pblimage > create mode 100644 tools/pblimage.c > create mode 100644 tools/pblimage.h This patch doesn't apply on top of current u-boot.git master. Please rebase and resubmit. Thanks. Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] TRATS: initialize panel_info data structure in board file
panel_info data structure is global variable, so, I have initialized it
in board file. If it is initialized in init_panel_info() like existing,
it can't be used in drv_lcd_init() in common/lcd.c because
init_panel_info() is called after drv_lcd_init().
Signed-off-by: Donghwa Lee
Signed-off-by: Kyungmin Park
---
board/samsung/trats/trats.c | 72 ++
drivers/video/exynos_fb.c |3 --
2 files changed, 38 insertions(+), 37 deletions(-)
diff --git a/board/samsung/trats/trats.c b/board/samsung/trats/trats.c
index 3085de1..a569c83 100644
--- a/board/samsung/trats/trats.c
+++ b/board/samsung/trats/trats.c
@@ -455,43 +455,47 @@ static int mipi_power(void)
return 0;
}
-void init_panel_info(vidinfo_t *vid)
-{
- vid->vl_freq= 60;
- vid->vl_col = 720;
- vid->vl_row = 1280;
- vid->vl_width = 720;
- vid->vl_height = 1280;
- vid->vl_clkp= CONFIG_SYS_HIGH;
- vid->vl_hsp = CONFIG_SYS_LOW;
- vid->vl_vsp = CONFIG_SYS_LOW;
- vid->vl_dp = CONFIG_SYS_LOW;
-
- vid->vl_bpix= 5;
- vid->dual_lcd_enabled = 0;
+vidinfo_t panel_info = {
+ .vl_freq = 60,
+ .vl_col = 720,
+ .vl_row = 1280,
+ .vl_width = 720,
+ .vl_height = 1280,
+ .vl_clkp= CONFIG_SYS_HIGH,
+ .vl_hsp = CONFIG_SYS_LOW,
+ .vl_vsp = CONFIG_SYS_LOW,
+ .vl_dp = CONFIG_SYS_LOW,
+
+ .vl_bpix= 5,/* Bits per pixel, 2^5 = 32 */
/* s6e8ax0 Panel */
- vid->vl_hspw= 5;
- vid->vl_hbpd= 10;
- vid->vl_hfpd= 10;
-
- vid->vl_vspw= 2;
- vid->vl_vbpd= 1;
- vid->vl_vfpd= 13;
- vid->vl_cmd_allow_len = 0xf;
-
- vid->win_id = 3;
- vid->cfg_gpio = NULL;
- vid->backlight_on = NULL;
- vid->lcd_power_on = NULL; /* lcd_power_on in mipi dsi driver */
- vid->reset_lcd = lcd_reset;
-
- vid->init_delay = 0;
- vid->power_on_delay = 0;
- vid->reset_delay = 0;
- vid->interface_mode = FIMD_RGB_INTERFACE;
- vid->mipi_enabled = 1;
+ .vl_hspw= 5,
+ .vl_hbpd= 10,
+ .vl_hfpd= 10,
+
+ .vl_vspw= 2,
+ .vl_vbpd= 1,
+ .vl_vfpd= 13,
+ .vl_cmd_allow_len = 0xf,
+
+ .win_id = 3,
+ .cfg_gpio = NULL,
+ .backlight_on = NULL,
+ .lcd_power_on = NULL, /* lcd_power_on in mipi dsi driver */
+ .reset_lcd = lcd_reset,
+
+ .init_delay = 0,
+ .power_on_delay = 0,
+ .reset_delay = 0,
+ .interface_mode = FIMD_RGB_INTERFACE,
+ .mipi_enabled = 1,
+ .boot_logo_on = 1,
+ .logo_height = TIZEN_LOGO_HEIGHT,
+ .logo_width = TIZEN_LOGO_WIDTH,
+};
+void init_panel_info(vidinfo_t *vid)
+{
strcpy(s6e8ax0_platform_data.lcd_panel_name, mipi_lcd_device.name);
s6e8ax0_platform_data.lcd_power = lcd_power;
s6e8ax0_platform_data.mipi_power = mipi_power;
diff --git a/drivers/video/exynos_fb.c b/drivers/video/exynos_fb.c
index a1cf449..96a8ec1 100644
--- a/drivers/video/exynos_fb.c
+++ b/drivers/video/exynos_fb.c
@@ -44,9 +44,6 @@ short console_row;
static unsigned int panel_width, panel_height;
-/* LCD Panel data */
-vidinfo_t panel_info;
-
static void exynos_lcd_init_mem(void *lcdbase, vidinfo_t *vid)
{
unsigned long palette_size;
--
1.7.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4][v2] powerpc/85xx:Fix MSR[DE] bit in MSR to support debugger
> > Debugging of e500 and e500v1 processer requires MSR[DE] bit to be set always. > Where MSR = Machine State register > > Make sure of MSR[DE] bit is set uniformaly across the different execution > address space i.e. AS0 and AS1. Hi We are trying to bring up our custom P2010 RDB based board. boot is NOR based and we cannot get past the rfi below. lis r6,MSR_IS|MSR_DS@h ori r6,r6,MSR_IS|MSR_DS@l lis r7,switch_as@h ori r7,r7,switch_as@l mtspr SPRN_SRR0,r7 mtspr SPRN_SRR1,r6 rfi switch_as: We end up with a TLB exception no matter what we do, even after applying this patch. Using a Abatron BDI3000 emluator Any pointers as what to look for would be greatly appreciated. Have anyone on the list managed to get past this rfi instruction using BDI3000? What emulator config did you use? Jocke > > Signed-off-by: Radu Lazarescu > Signed-off-by: Catalin Udma > Signed-off-by: Marius Grigoras > Signed-off-by: Prabhakar Kushwaha > --- > Based upon git://git.denx.de/u-boot.git branch master > > Changes for v2: >- Avoid MSR_DE negation in arch_preboot >- Made MSR_DE set code independent of any #define > > No change, Resending again > > Tested on > - SoC having E500 Family processor (P1010RDB, BSC9131RDB) > - SoC having E500MC Family processor (P4080DS, P3041DS) > > arch/powerpc/cpu/mpc85xx/cpu_init.c |2 +- > arch/powerpc/cpu/mpc85xx/start.S|7 +-- > 2 files changed, 6 insertions(+), 3 deletions(-) > > diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c > b/arch/powerpc/cpu/mpc85xx/cpu_init.c > index 2e4a06c..3bcbffa 100644 > --- a/arch/powerpc/cpu/mpc85xx/cpu_init.c > +++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c > @@ -532,7 +532,7 @@ void arch_preboot_os(void) > * disabled by the time we get called. > */ > msr = mfmsr(); > - msr &= ~(MSR_ME|MSR_CE|MSR_DE); > + msr &= ~(MSR_ME|MSR_CE); > mtmsr(msr); > > setup_ivors(); > diff --git a/arch/powerpc/cpu/mpc85xx/start.S > b/arch/powerpc/cpu/mpc85xx/start.S > index 7bfa2d5..597151b 100644 > --- a/arch/powerpc/cpu/mpc85xx/start.S > +++ b/arch/powerpc/cpu/mpc85xx/start.S > @@ -82,6 +82,9 @@ > .globl _start_e500 > > _start_e500: > +/* Enable debug exception */ > + li r1,MSR_DE > + mtmsrr1 > > #if defined(CONFIG_SECURE_BOOT) && defined(CONFIG_E500MC) > /* ISBC uses L2 as stack. > @@ -729,8 +732,8 @@ create_init_ram_area: > msync > tlbwe > > - lis r6,MSR_IS|MSR_DS@h > - ori r6,r6,MSR_IS|MSR_DS@l > + lis r6,MSR_IS|MSR_DS|MSR_DE@h > + ori r6,r6,MSR_IS|MSR_DS|MSR_DE@l > lis r7,switch_as@h > ori r7,r7,switch_as@l > > -- > 1.7.5.4 > > > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] igep00x0: enable the use of a plain text file
From: Enric Balletbo i Serra
Based on commit cf073e49bc3502be1b48a0e3faf0cde9edbb89db for beagleboard
Using the new env import command it is possible to use plain text files instead
of script-images. Plain text files are much easier to handle.
E.g. If your boot.scr contains the following:
---
setenv dvimode 1024x768-16@60
run loaduimage
run mmcboot
---
you could create a file named uEnv.txt and use that instead of boot.scr:
---
dvimode=1024x768-16@60
uenvcmd=run loaduimage; run mmcboot
---
The variable uenvcmd (if existent) will be executed (using run) after uEnv.txt
was loaded. If uenvcmd doesn't exist the default boot sequence will be started,
therefore you could just use
---
dvimode=1024x768-16@60
---
as uEnv.txt because loaduimage and mmcboot is part of the default boot sequence
Signed-off-by: Enric Balletbo i Serra
Signed-off-by: Anatolij Gustschin
---
v2:
- rebased on u-boot-ti/master
include/configs/igep00x0.h | 28
1 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/include/configs/igep00x0.h b/include/configs/igep00x0.h
index d2b4b84..31ddabc 100644
--- a/include/configs/igep00x0.h
+++ b/include/configs/igep00x0.h
@@ -161,9 +161,9 @@
"omapdss.def_disp=${defaultdisplay} " \
"root=${nandroot} " \
"rootfstype=${nandrootfstype}\0" \
- "loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr\0" \
- "bootscript=echo Running bootscript from mmc ...; " \
- "source ${loadaddr}\0" \
+ "loadbootenv=fatload mmc ${mmcdev} ${loadaddr} uEnv.txt\0" \
+ "importbootenv=echo Importing environment from mmc ...; " \
+ "env import -t $loadaddr $filesize\0" \
"loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0" \
"mmcboot=echo Booting from mmc ...; " \
"run mmcargs; " \
@@ -175,15 +175,19 @@
#define CONFIG_BOOTCOMMAND \
"if mmc rescan ${mmcdev}; then " \
- "if run loadbootscript; then " \
- "run bootscript; " \
- "else " \
- "if run loaduimage; then " \
- "run mmcboot; " \
- "else run nandboot; " \
- "fi; " \
- "fi; " \
- "else run nandboot; fi"
+ "echo SD/MMC found on device ${mmcdev};" \
+ "if run loadbootenv; then " \
+ "run importbootenv;" \
+ "fi;" \
+ "if test -n $uenvcmd; then " \
+ "echo Running uenvcmd ...;" \
+ "run uenvcmd;" \
+ "fi;" \
+ "if run loaduimage; then " \
+ "run mmcboot;" \
+ "fi;" \
+ "fi;" \
+ "run nandboot;" \
#define CONFIG_AUTO_COMPLETE 1
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] kwboot: Boot Marvell Kirkwood SoCs over a serial link.
Dear Daniel Stodden, In message <1335325799.8304.15.camel@ramone> you wrote: > > > Why not use something like: > > > > BIN_FILES-$(CONFIG_KIRKWOOD) += kwboot$(SFX) > > Huh? > > I don't know u-boot's build system very well, but normally CONFIG items > are employed to keep the target lean. Where the best you could ask from > down-config'd host toolset build would be to not accidentally miss sth? > This is all host code. > > Is building that conditionally really best current practice? If so, > yeah, we sure can change that. > > But would appreciate a clarification. It makes no sense to build this tool on systems that will have no use for it - say, on Power architecture. It only costs build time. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] igep00x0: change mpurate from 500 to auto
From: Enric Balletbo i Serra This patch changes the default mpurate variable from 500 to auto on all IGEP boards, with this the default rate is autoselected. Signed-off-by: Enric Balletbo i Serra Signed-off-by: Anatolij Gustschin --- v2: - rebased on u-boot-ti/master. include/configs/igep00x0.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/configs/igep00x0.h b/include/configs/igep00x0.h index 31ddabc..a99f332 100644 --- a/include/configs/igep00x0.h +++ b/include/configs/igep00x0.h @@ -136,7 +136,7 @@ "loadaddr=0x8200\0" \ "usbtty=cdc_acm\0" \ "console=ttyS2,115200n8\0" \ - "mpurate=500\0" \ + "mpurate=auto\0" \ "vram=12M\0" \ "dvimode=1024x768MR-16@60\0" \ "defaultdisplay=dvi\0" \ -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [u-boot][PATCH 0/2] igep00x0: updates for IGEP boards
Hello, On Wed, 25 May 2011 16:19:17 +0200 Enric Balletbo i Serra wrote: > Hello, > > This is a couple of patches to update the support for IGEP boards, please > consider to adding. Sorry for very long delay. These patches needed rebasing, I've included Tom in Cc for v2, so these patches hopefully will be merged while current merge window. Thanks! Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Porting u-boot for MPC8280 based board.
Dear Thirumalesha N, In message you wrote: > > Yes These frequency and flash base address are correct to my board. > SMC2 pins PA9-TX and PA8-Rx, > I Checked BRG and clock routing is matching to board. Then you need a debugger. > I have BDI 2000 tool, but its not connecting to board. This is a problem that should be fixable. Keep in mind that the MPC82xx can come up in different modes, depending on if there is a valid HRCW in flash or not. This can change the start address, too. Try both high and low boot configurations. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Remember thee Ay, thou poor ghost while memory holds a seat In this distracted globe. Remember thee! Yea, from the table of my memory I'll wipe away all trivial fond records, All saws of books, all forms, all pressures past, That youth and observation copied there. Hamlet, I : v : 95 William Shakespeare ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [STATUS] v2012.04.01 released
Hello, U-Boot v2012.04.01 has been released and is available from the git repository and the FTP server. Please update and use this bug fix release instead of v2012.04. It fixes a nasty bug in the command line processing, which can cause incorrect execution of commands and scripts. Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "Out of register space (ugh)" - vi ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4][v3] powerpc/85xx:Make debug exception vector accessible
On 04/24/2012 11:05 PM, Andy Fleming wrote: On Tue, Apr 24, 2012 at 10:48 PM, Prabhakar Kushwaha wrote: Hi, On Wednesday 25 April 2012 02:50 AM, Andy Fleming wrote: On Tue, Apr 24, 2012 at 4:10 PM, Scott Wood wrote: On 04/24/2012 03:45 PM, Andy Fleming wrote: On Mon, Mar 26, 2012 at 4:00 AM, Prabhakar Kushwaha @@ -107,6 +107,7 @@ #define CONFIG_MAX_CPUS1 #define CONFIG_FSL_SDHC_V2_3 #define CONFIG_SYS_FSL_NUM_LAWS12 +#define CONFIG_SYS_PPC_E500_DEBUG_TLB 3 You've only enabled this for one processor. Maybe the P1010. Nowhere in the patch description does it mention that this is only being enabled for one chip. As it is, I think you meant to enable it for more chips, and I'm wondering why it's not enabled for the other chips mentioned in the comments above as being test platforms for this patch... Probably, for this feature, we should make a default definition, which can be overridden by other parts if necessary. In other words, add something like this near the end: #ifndef CONFIG_SYS_PPC_E500_DEBUG_TLB #define CONFIG_SYS_PPC_E500_DEBUG_TLB 3 #endif We don't want to enable this on e500mc (testing in that context just means that we didn't break the code path where this isn't enabled). I'm not sure whether it will break anything if we do enable it on e500mc, but we don't need it. Ok, but we still either need this to be enabled for all e500/e500v2. OR split off this config option into a separate patch where it's mentioned that this is only being enabled on the P1010. Actually, it should probably be added to this area that deals in core-specific config options: I agree. I will split the debugger patch and P1010 debug enable. A separate patch will be send for P1010 SoC. For other e500v2 processor based SoC,as i am not sure about their verification. It will be send as and when verified. That should be fine. Enabling it on individual SoCs based on verification conflicts with putting this in the core-specific config area. Just test with a reasonable sample of SoCs, grep for TLB assignments to look for any conflicts, and then enable it in the generic e500v2 area that Andy pointed out. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/4] lin_gadget: use common linux/compat.h
On Wednesday 25 April 2012 04:11:41 Anatolij Gustschin wrote: > From: Mike Frysinger > > Merge our duplicate definitions with the common header. > Also fix drivers/usb/gadget/s3c_udc_otg_xfer_dma.c to > use min() instead of min_t() since we remove the latter > from compat.h. > > Signed-off-by: Mike Frysinger > Signed-off-by: Anatolij Gustschin > --- > v2: > - fix build breakage: >In file included from s3c_udc_otg.c:212:0: >s3c_udc_otg_xfer_dma.c: In function 'setdma_tx': >s3c_udc_otg_xfer_dma.c:171:47: error: macro "min_t" requires 3 > arguments, but only 2 given s3c_udc_otg_xfer_dma.c:171:12: error: 'min_t' > undeclared (first use in this function) we'll prob want to merge the mtd/compat.h stuff in to linux/compat.h, like the min_t() macro -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/4] Cleanups/fixes in patman tool
Vikram Narayanan (4): patman: Fix a typo error patman: Add meaningful statements instead of blah blah patman: Change the location of patman path in README patman: Handle searching of patman config tools/patman/README | 17 - tools/patman/settings.py | 26 -- 2 files changed, 32 insertions(+), 11 deletions(-) -- 1.7.4.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] patman: Fix a typo error
Signed-off-by: Vikram Narayanan Cc: Simon Glass --- tools/patman/README |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/tools/patman/README b/tools/patman/README index 587c97f..d9820ab 100644 --- a/tools/patman/README +++ b/tools/patman/README @@ -197,7 +197,7 @@ patch series and see how the patches turn out. Where Patches Are Sent == -Once the patches are created, patman sends them using gti send-email. The +Once the patches are created, patman sends them using git send-email. The whole series is sent to the recipients in Series-to: and Series-cc. You can Cc individual patches to other people with the Cc: tag. Tags in the subject are also picked up to Cc patches. For example, a commit like this: -- 1.7.4.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] patman: Add meaningful statements instead of blah blah
Signed-off-by: Vikram Narayanan Cc: Simon Glass --- tools/patman/README |9 - 1 files changed, 4 insertions(+), 5 deletions(-) diff --git a/tools/patman/README b/tools/patman/README index d9820ab..d98f081 100644 --- a/tools/patman/README +++ b/tools/patman/README @@ -132,16 +132,15 @@ Series-prefix: prefix Cover-letter: This is the patch set title -blah blah -more blah blah +This patch set fixes the errors when CONFIG_xxx is enabled. +Tested on xyz board. END Sets the cover letter contents for the series. The first line will become the subject of the cover letter Series-notes: -blah blah -blah blah -more blah blah +Sorry that I couldn't find time to reply for the comments posted on the v1 of my +patch. This patch superseeds v1. Please comment. END Sets some notes for the patch series, which you don't want in the commit messages, but do want to send, The notes are joined -- 1.7.4.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] patman: Change the location of patman path in README
Signed-off-by: Vikram Narayanan Cc: Simon Glass --- tools/patman/README |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/tools/patman/README b/tools/patman/README index d98f081..4913510 100644 --- a/tools/patman/README +++ b/tools/patman/README @@ -93,17 +93,17 @@ How to run it First do a dry run: -$ ./tools/scripts/patman/patman -n +$ ./tools/patman/patman -n If it can't detect the upstream branch, try telling it how many patches there are in your series: -$ ./tools/scripts/patman/patman -n -c5 +$ ./tools/patman/patman -n -c5 This will create patch files in your current directory and tell you who it is thinking of sending them to. Take a look at the patch files. -$ ./tools/scripts/patman/patman -n -c5 -s1 +$ ./tools/patman/patman -n -c5 -s1 Similar to the above, but skip the first commit and take the next 5. This is useful if your top commit is for setting up testing. -- 1.7.4.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] PATCH 4/4] patman: Handle searching of patman config
patman shouts when it couldn't find a $(HOME)/.config/patman file.
Also, it couldn't create patch files without the above config file.
Handle it in a sane way by creating a new one for the user.
Signed-off-by: Vikram Narayanan
Cc: Simon Glass
---
tools/patman/settings.py | 26 --
1 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/tools/patman/settings.py b/tools/patman/settings.py
index 049c709..ea8661b 100644
--- a/tools/patman/settings.py
+++ b/tools/patman/settings.py
@@ -61,6 +61,22 @@ def ReadGitAliases(fname):
fd.close()
+def CreatePatmanConfigFile(config_fname):
+name = raw_input("Enter name: ")
+email = raw_input("Enter email: ")
+
+try:
+FILE = open(config_fname,"w")
+except IOError:
+print "Couldn't create patman config file\n"
+
+FILE.write("[alias]\nme: ")
+FILE.write(name);
+FILE.write(" <");
+FILE.write(email);
+FILE.write(">")
+FILE.close();
+
def Setup(config_fname=''):
"""Set up the settings module by reading config files.
@@ -70,8 +86,14 @@ def Setup(config_fname=''):
settings = ConfigParser.SafeConfigParser()
if config_fname == '':
config_fname = '%s/.config/patman' % os.getenv('HOME')
-if config_fname:
-settings.read(config_fname)
+
+exists = os.path.exists(config_fname)
+
+if exists == False:
+print "No config file found under ~/.config/\nCreating one...\n"
+CreatePatmanConfigFile(config_fname)
+
+settings.read(config_fname)
for name, value in settings.items('alias'):
alias[name] = value.split(',')
--
1.7.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/3] usb:gadget:composite: Support for composite gadget framework
Hi Marek,
> This patch set provides support for composite gadget framework.
> Files from Linux kernel (2.6.36) - namely composite.{c|h} have been
> ported to u-boot.
>
> Code supporting this framework has been added to gadget.h and
> Samsung's UDC driver as well.
>
> ---
> Changes for v2:
> - Squash the kernel files with u-boot compatibility layer.
> - Removal of dead/kernel specific code.
> - Comments corrected according to u-boot coding style.
> - Two separate patches regarding gadget.h file squashed together.
> Changes for v3:
> - Remove unlikely function call
> - Code indentation fixup
> Changes for v4:
> - Move variables definition to function beginning
> - CaMeL case declaration fixed
>
> Lukasz Majewski (3):
> usb:gadget:composite USB composite gadget support
> usb:gadget:composite: Support for composite at gadget.h
> usb:udc:samsung Add functions for storing private gadget data in UDC
> driver
Can you look into this code? Since the 2012.04.01 is out (stable
u-boot), I would like to improve the USB subsystem.
Moreover one commit:
http://patchwork.ozlabs.org/patch/151983/
has been acked-by you, but it hasn't been added to u-boot-usb/next.
Would it be possible to pull this code?
--
Best regards,
Lukasz Majewski
Samsung Poland R&D Center | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/4] lin_gadget: use common linux/compat.h
Hi Anatolij, > From: Mike Frysinger > > Merge our duplicate definitions with the common header. > Also fix drivers/usb/gadget/s3c_udc_otg_xfer_dma.c to > use min() instead of min_t() since we remove the latter > from compat.h. Yes. the include/usb/lin_gadget_compat.h layer. Good idea to provide one compat file (as fair as I remember similar problem is with mtd/compat.h). I'll look into the include/linux.h file. -- Best regards, Lukasz Majewski Samsung Poland R&D Center | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/3] usb:gadget:composite: Support for composite gadget framework
Dear Lukasz Majewski,
> Hi Marek,
>
> > This patch set provides support for composite gadget framework.
> > Files from Linux kernel (2.6.36) - namely composite.{c|h} have been
> > ported to u-boot.
> >
> > Code supporting this framework has been added to gadget.h and
> > Samsung's UDC driver as well.
> >
> > ---
> >
> > Changes for v2:
> > - Squash the kernel files with u-boot compatibility layer.
> > - Removal of dead/kernel specific code.
> > - Comments corrected according to u-boot coding style.
> > - Two separate patches regarding gadget.h file squashed together.
> >
> > Changes for v3:
> > - Remove unlikely function call
> > - Code indentation fixup
> >
> > Changes for v4:
> > - Move variables definition to function beginning
> > - CaMeL case declaration fixed
> >
> > Lukasz Majewski (3):
> > usb:gadget:composite USB composite gadget support
> > usb:gadget:composite: Support for composite at gadget.h
> > usb:udc:samsung Add functions for storing private gadget data in UDC
> >
> > driver
>
> Can you look into this code? Since the 2012.04.01 is out (stable
> u-boot), I would like to improve the USB subsystem.
>
> Moreover one commit:
> http://patchwork.ozlabs.org/patch/151983/
>
> has been acked-by you, but it hasn't been added to u-boot-usb/next.
> Would it be possible to pull this code?
Yes, it's on my slate ... I'm slightly congested now, I appologize for not
reviewing these quickly, would you mind giving me a few more days please?
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] kwboot: Boot Marvell Kirkwood SoCs over a serial link.
Hi Daniel, On Wed, Apr 25, 2012 at 02:34:07PM +0200, Wolfgang Denk wrote: > In message <1335325799.8304.15.camel@ramone> you wrote: > > > > > Why not use something like: > > > > > > BIN_FILES-$(CONFIG_KIRKWOOD) += kwboot$(SFX) > > > > Huh? > > > > I don't know u-boot's build system very well, but normally CONFIG items > > are employed to keep the target lean. Where the best you could ask from > > down-config'd host toolset build would be to not accidentally miss sth? > > This is all host code. > > > > Is building that conditionally really best current practice? If so, > > yeah, we sure can change that. > > > > But would appreciate a clarification. > > It makes no sense to build this tool on systems that will have no use > for it - say, on Power architecture. It only costs build time. This is what I was talking about: diff --git a/tools/Makefile b/tools/Makefile index 8993fdd..8097d95 100644 --- a/tools/Makefile +++ b/tools/Makefile @@ -72,6 +72,7 @@ BIN_FILES-$(CONFIG_SMDK5250) += mksmdk5250spl$(SFX) BIN_FILES-$(CONFIG_MX28) += mxsboot$(SFX) BIN_FILES-$(CONFIG_NETCONSOLE) += ncb$(SFX) BIN_FILES-$(CONFIG_SHA1_CHECK_UB_IMG) += ubsha1$(SFX) +BIN_FILES-$(CONFIG_KIRKWOOD) += kwboot$(SFX) # Source files which exist outside the tools directory EXT_OBJ_FILES-$(CONFIG_BUILD_ENVCRC) += common/env_embedded.o @@ -101,6 +102,7 @@ OBJ_FILES-$(CONFIG_NETCONSOLE) += ncb.o NOPED_OBJ_FILES-y += os_support.o OBJ_FILES-$(CONFIG_SHA1_CHECK_UB_IMG) += ubsha1.o NOPED_OBJ_FILES-y += ublimage.o +OBJ_FILES-$(CONFIG_KIRKWOOD) += kwboot.o # Don't build by default #ifeq ($(ARCH),ppc) @@ -234,6 +236,10 @@ $(obj)ncb$(SFX): $(obj)ncb.o $(obj)ubsha1$(SFX):$(obj)os_support.o $(obj)sha1.o $(obj)ubsha1.o $(HOSTCC) $(HOSTCFLAGS) $(HOSTLDFLAGS) -o $@ $^ +$(obj)kwboot$(SFX): $(obj)kwboot.o + $(HOSTCC) $(HOSTCFLAGS) $(HOSTLDFLAGS) -o $@ $^ + $(HOSTSTRIP) $@ + # Some of the tool objects need to be accessed from outside the tools directory $(obj)%.o: $(SRCTREE)/common/%.c $(HOSTCC) -g $(HOSTCFLAGS_NOPED) -c -o $@ $< That worked for me. Please test this, merge it and resend patch v2. When sending patch v2 please put me in CC because I don't look at the mailing list regularly... Regards, Luka ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] beagle: fix 'timed out in wait_for_bb' message in SPL
From: Peter Meerwald SPL boot outputs a 'timed out in wait_for_bb: IC2_STAT' message on beagle U-Boot SPL 2012.04-00020-gb8310b9-dirty (Apr 25 2012 - 18:49:57) Texas Instruments Revision detection unimplemented OMAP SD/MMC: 0 timed out in wait_for_bb: I2C_STAT=1000 reading u-boot.img the reason for above message is that when booting from MMC, I2C needs (?) to be initialized as well when SPL initializes MMC (which is done in omap_hsmmc.c, mmc_board_init()) the following is called: twl4030_power_mmc_init(); in order to communicate with the twl4030, I2C is necessary, but I2C has not been initialized yet in SPL the problem can be easily fixed by #defining CONFIG_SPL_BOARD_INIT in include/configs/omap3_beagle.h tested on beagle-xm (rev. C) Signed-off-by: Peter Meerwald --- include/configs/omap3_beagle.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h index ddeb414..27e51cd 100644 --- a/include/configs/omap3_beagle.h +++ b/include/configs/omap3_beagle.h @@ -410,6 +410,7 @@ #define CONFIG_SYS_MMC_SD_FAT_BOOT_PARTITION 1 #define CONFIG_SPL_FAT_LOAD_PAYLOAD_NAME "u-boot.img" +#define CONFIG_SPL_BOARD_INIT #define CONFIG_SPL_LIBCOMMON_SUPPORT #define CONFIG_SPL_LIBDISK_SUPPORT #define CONFIG_SPL_I2C_SUPPORT -- 1.7.5.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Using sata on mx6qsabrelite
Hi, On Stefano´s tree I see this sata patch for mx5/mx6: http://git.denx.de/?p=u-boot/u-boot-imx.git;a=commit;h=6931bd30d03de827c52bf2c8ddc6ed0c8f21dc9d Has anyone tried sata support on mx6qsabrelite yet? Any patches missing that were not applied? I don't have a way to test it at the moment, but I have a colleague that wants to use sata on mx6qsabrelite. Thanks, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4][v2] powerpc/85xx:Fix MSR[DE] bit in MSR to support debugger
On 04/25/2012 05:57 AM, Joakim Tjernlund wrote: >> >> Debugging of e500 and e500v1 processer requires MSR[DE] bit to be set always. >> Where MSR = Machine State register >> >> Make sure of MSR[DE] bit is set uniformaly across the different execution >> address space i.e. AS0 and AS1. > > Hi > > We are trying to bring up our custom P2010 RDB based board. boot is NOR > based and we cannot get past the rfi below. > lis r6,MSR_IS|MSR_DS@h > ori r6,r6,MSR_IS|MSR_DS@l > lis r7,switch_as@h > ori r7,r7,switch_as@l > > mtspr SPRN_SRR0,r7 > mtspr SPRN_SRR1,r6 > rfi > > switch_as: > > We end up with a TLB exception no matter what we do, even after applying this > patch. Did you apply the entire patchset, and define CONFIG_SYS_PPC_E500_DEBUG_TLB? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4][v2] powerpc/85xx:Fix MSR[DE] bit in MSR to support debugger
Scott Wood wrote on 2012/04/25 20:43:22: > > On 04/25/2012 05:57 AM, Joakim Tjernlund wrote: > >> > >> Debugging of e500 and e500v1 processer requires MSR[DE] bit to be set > >> always. > >> Where MSR = Machine State register > >> > >> Make sure of MSR[DE] bit is set uniformaly across the different execution > >> address space i.e. AS0 and AS1. > > > > Hi > > > > We are trying to bring up our custom P2010 RDB based board. boot is NOR > > based and we cannot get past the rfi below. > >lis r6,MSR_IS|MSR_DS@h > >ori r6,r6,MSR_IS|MSR_DS@l > >lis r7,switch_as@h > >ori r7,r7,switch_as@l > > > >mtspr SPRN_SRR0,r7 > >mtspr SPRN_SRR1,r6 > >rfi > > > > switch_as: > > > > We end up with a TLB exception no matter what we do, even after applying > > this patch. > > Did you apply the entire patchset, and define CONFIG_SYS_PPC_E500_DEBUG_TLB? No, but this code is executed before any of the other parts of the patch. Anyhow, I just found the problem(really obvious once I found it). During bring up we had to load uboot in the middle of the flash instead of the end because we have a flash burn problem in the end of the flash that we do not understand yet. We think it may be related to DDR3 being misconfigured by the emulator(BDI3000). I do not understand why this emulator can not use the L2SRAM instead? Is there something magic behind the L2SRAM so it is impossible to use it as a work area for flash burning? Jocke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4][v2] powerpc/85xx:Fix MSR[DE] bit in MSR to support debugger
On 04/25/2012 01:55 PM, Joakim Tjernlund wrote: > > Scott Wood wrote on 2012/04/25 20:43:22: >> >> On 04/25/2012 05:57 AM, Joakim Tjernlund wrote: Debugging of e500 and e500v1 processer requires MSR[DE] bit to be set always. Where MSR = Machine State register Make sure of MSR[DE] bit is set uniformaly across the different execution address space i.e. AS0 and AS1. >>> >>> Hi >>> >>> We are trying to bring up our custom P2010 RDB based board. boot is NOR >>> based and we cannot get past the rfi below. >>>lis r6,MSR_IS|MSR_DS@h >>>ori r6,r6,MSR_IS|MSR_DS@l >>>lis r7,switch_as@h >>>ori r7,r7,switch_as@l >>> >>>mtspr SPRN_SRR0,r7 >>>mtspr SPRN_SRR1,r6 >>>rfi >>> >>> switch_as: >>> >>> We end up with a TLB exception no matter what we do, even after applying >>> this patch. >> >> Did you apply the entire patchset, and define CONFIG_SYS_PPC_E500_DEBUG_TLB? > > No, but this code is executed before any of the other parts of the patch. > Anyhow, I just > found the problem(really obvious once I found it). > During bring up we had to load uboot in the middle of the flash instead of > the end because we have a flash burn problem in the end of the flash that we > do not > understand yet. We think it may be related to DDR3 being misconfigured by the > emulator(BDI3000). > I do not understand why this emulator can not use the L2SRAM instead? Is > there something > magic behind the L2SRAM so it is impossible to use it as a work area for > flash burning? I don't know of any reason L2SRAM couldn't be used for this. My guess is they just don't want to have to support more than one way of creating RAM. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] PowerPC: Change -fpic flag to -fPIC flag in the config.mk
On 04/18/2012 05:07 AM, Joakim Tjernlund wrote:
> Your linker file is buggy I think. I found u-boot-nand_spl.lds, is that the
> one?
That's the one for the SPL part.
> Check out that files reloc part:
> .reloc : {
> _GOT2_TABLE_ = .;
> KEEP(*(.got2))
> _FIXUP_TABLE_ = .;
> KEEP(*(.fixup))
> }
> __got2_entries = (_FIXUP_TABLE_ - _GOT2_TABLE_) >> 2;
> __fixup_entries = (. - _FIXUP_TABLE_) >> 2;
>
> Compare that with(from u-boot.lds):
> .reloc :
> {
> _GOT2_TABLE_ = .;
> KEEP(*(.got2))
> KEEP(*(.got))
> PROVIDE(_GLOBAL_OFFSET_TABLE_ = . + 4);
> _FIXUP_TABLE_ = .;
> KEEP(*(.fixup))
> }
> __got2_entries = ((_GLOBAL_OFFSET_TABLE_ - _GOT2_TABLE_) >> 2) - 1;
> __fixup_entries = (. - _FIXUP_TABLE_) >> 2;
I notice a difference between u-boot.lds and u-boot-nand.lds -- the
latter (used for the main part of U-Boot when loaded from SPL) has:
> .reloc :
> {
> KEEP(*(.got))
> _GOT2_TABLE_ = .;
> KEEP(*(.got2))
> _FIXUP_TABLE_ = .;
> KEEP(*(.fixup))
> }
> __got2_entries = (_FIXUP_TABLE_ - _GOT2_TABLE_) >> 2;
> __fixup_entries = (. - _FIXUP_TABLE_) >> 2;
Is this wrong as well?
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Using sata on mx6qsabrelite
On 04/25/2012 11:40 AM, Fabio Estevam wrote: Hi, On Stefano´s tree I see this sata patch for mx5/mx6: http://git.denx.de/?p=u-boot/u-boot-imx.git;a=commit;h=6931bd30d03de827c52bf2c8ddc6ed0c8f21dc9d Has anyone tried sata support on mx6qsabrelite yet? Any patches missing that were not applied? I don't have a way to test it at the moment, but I have a colleague that wants to use sata on mx6qsabrelite. Hi Fabio, I've tried it and it just worked for me, but it's been a month or so. I'll dig out my SATA drive and test again this afternoon. Regards, Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Remove extra boards from LIST_ixp
pdnb3 and scpu are explicitly on LIST_ixp, even though they are also specified in boards.cfg as having cpu ixp. This means that they will be built twice when doing ./MAKEALL ixp, or ./MAKEALL arm. This was pointless before, but actually breaks things if you launch both builds at the same time, as they overwrite each other. Signed-off-by: Andy Fleming --- MAKEALL |5 + 1 files changed, 1 insertions(+), 4 deletions(-) diff --git a/MAKEALL b/MAKEALL index e6c801c..5b610bf 100755 --- a/MAKEALL +++ b/MAKEALL @@ -365,10 +365,7 @@ LIST_at91="$(boards_by_soc at91)" LIST_pxa="$(boards_by_cpu pxa)" -LIST_ixp="$(boards_by_cpu ixp) - pdnb3 \ - scpu\ -" +LIST_ixp="$(boards_by_cpu ixp)" # ## ARM groups -- 1.7.3.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Yaffs] yaffs2 u-boot patching support
On Tuesday 24 April 2012 03:33:35 Stefano Babic wrote: > On 22/04/2012 22:23, Charles Manning wrote: > > On Friday 20 April 2012 09:40:50 Tom Rini wrote: > >> On Mon, Apr 16, 2012 at 04:32:07PM +1200, Charles Manning wrote: > >>> Hello ubooters and yaffsers > > Hi Charles, > > >>> I was commissioned to refresh yaffs2 in u-boot and add a mechanism to > >>> support dynamic yaffs partition set up (way simpler than screwing > >>> around with mtd part) and manual configuration. > >>> > >>> Rather than do this as a once off, I set this scripting up so that > >>> this can be done at any time (painlessly I hope) to bring in the fresh > >>> code (as per Linux patching). > >> > >> Just to put this out there, if you're not submitting patches to get the > >> code into git, should the current support in-tree be removed? > > > > I think it is worth having yaffs in the main code base, but not the old > > stuff. > > > > The primary reason to have a "patch-in" script is to allow people to > > refresh the yaffs they are using in a pretty painless way. > > Well, why do not push your patches directly to ML ? This increases > surely the number of testers, and after ypur patches will be merged > thare is not need for external scripts. I have sent a pull request to the list. https://github.com/cdhmanning/u-boot-yaffs2 -- CHarles ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: Integrate latest yaffs2
On Tuesday 24 April 2012 08:58:09 you wrote: > Dear Charles Manning, > > In message <201204231346.32195.mannin...@actrix.gen.nz> you wrote: > > I recently sent a message to the list announcing a method for patching in > > the latest yaffs2. > > > > u-boot updated with the latest yaffs2 can be pulled from > > g...@github.com:cdhmanning/u-boot-yaffs2.git > > Please read http://www.denx.de/wiki/U-Boot/Patches and post proper > patch(es) for review. At least one of the files exceeds the 100k patch limit. I know you'd like patches, but there are two really easy options for someone on the inside to do this: 1) Run the script off the yaffs git -or- 2) Merge from the https://github.com/cdhmanning/u-boot-yaffs2 Regards -- Charles ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] omap4: panda: disable uart2 pads during boot
If uart2 is enabled during boot, spurious wifi chip transmission will
hang the module and it is impossible to recover from this situation
without hard reset. This will prevent any l4_per domain idle
transitions.
Signed-off-by: Tero Kristo
---
board/ti/panda/panda_mux_data.h |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/board/ti/panda/panda_mux_data.h b/board/ti/panda/panda_mux_data.h
index 3efc22a..dc8b388 100644
--- a/board/ti/panda/panda_mux_data.h
+++ b/board/ti/panda/panda_mux_data.h
@@ -168,10 +168,10 @@ const struct pad_conf_entry
core_padconf_array_non_essential[] = {
{ABE_DMIC_DIN1, (IEN | M0)},/*
abe_dmic_din1 */
{ABE_DMIC_DIN2, (PTU | IEN | M3)}, /*
gpio_121 */
{ABE_DMIC_DIN3, (IEN | M0)},/*
abe_dmic_din3 */
- {UART2_CTS, (PTU | IEN | M0)}, /*
uart2_cts */
- {UART2_RTS, (M0)}, /*
uart2_rts */
- {UART2_RX, (PTU | IEN | M0)}, /*
uart2_rx */
- {UART2_TX, (M0)}, /*
uart2_tx */
+ {UART2_CTS, (PTU | IEN | M7)}, /*
uart2_cts */
+ {UART2_RTS, (M7)}, /*
uart2_rts */
+ {UART2_RX, (PTU | IEN | M7)}, /*
uart2_rx */
+ {UART2_TX, (M7)}, /*
uart2_tx */
{HDQ_SIO, (M3)},/*
gpio_127 */
{MCSPI1_CLK, (IEN | OFF_EN | OFF_PD | OFF_IN | M0)},/*
mcspi1_clk */
{MCSPI1_SOMI, (IEN | OFF_EN | OFF_PD | OFF_IN | M0)}, /*
mcspi1_somi */
--
1.7.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] omap4: do not enable fs-usb module
If this is done in the bootloader, the FS-USB will later be stuck into intransition state, which will prevent the device from entering idle. Signed-off-by: Tero Kristo --- arch/arm/cpu/armv7/omap4/clocks.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/arch/arm/cpu/armv7/omap4/clocks.c b/arch/arm/cpu/armv7/omap4/clocks.c index dd694c4..c29531b 100644 --- a/arch/arm/cpu/armv7/omap4/clocks.c +++ b/arch/arm/cpu/armv7/omap4/clocks.c @@ -378,7 +378,6 @@ void enable_basic_clocks(void) &prcm->cm_l4per_gptimer2_clkctrl, &prcm->cm_wkup_wdtimer2_clkctrl, &prcm->cm_l4per_uart3_clkctrl, - &prcm->cm_l3init_fsusb_clkctrl, &prcm->cm_l3init_hsusbhost_clkctrl, 0 }; @@ -505,7 +504,6 @@ void enable_non_essential_clocks(void) &prcm->cm_dss_dss_clkctrl, &prcm->cm_sgx_sgx_clkctrl, &prcm->cm_l3init_hsusbhost_clkctrl, - &prcm->cm_l3init_fsusb_clkctrl, 0 }; -- 1.7.4.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/3] omap4: panda: fixes for core retention
[sorry, failed with the header sending, trying it again] Hi, The following patches are needed before kernel can enter core retention. Namely, u-boot is enabling some functionality too early in the init phase which seems not to be needed, and it is causing trouble later on. I haven't found any other workaround for any of the following issues than to patch the bootloader. I even tried resetting each IP module to no avail. UART2 is used to communicate with the wifi chip, and muxing the pads too early for UART2 usage hangs the UART module, preventing idle. DSP/IVAHD/cortex-m3 cores don't have any firmware to execute, so taking them out of reset is generally a bad idea. Also, all cores will prevent any idle later on if taken out of reset. FSUSB module has similar issue as UART2, if it is enabled during boot, it will never go to idle anymore. Tested with omap4 panda es board. If someone is interested in testing the kernel I have used, it can be found here: git://gitorious.org/~kristo/omap-pm/omap-pm-work.git branch: mainline-3.4-omap4-dev-off Use omap2plus_defconfig, boot it up to shell and do "echo mem > /sys/power/state". -Tero ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] omap4: do not enable auxiliary cores
Booting up these cores (dsp / ivahd / cortex-m3) is bad without
firmware running on them, and they will hang preventing any kind
of sleep transitions later on with the kernel.
Signed-off-by: Tero Kristo
---
arch/arm/cpu/armv7/omap4/clocks.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap4/clocks.c
b/arch/arm/cpu/armv7/omap4/clocks.c
index c29531b..316fdf9 100644
--- a/arch/arm/cpu/armv7/omap4/clocks.c
+++ b/arch/arm/cpu/armv7/omap4/clocks.c
@@ -454,10 +454,6 @@ void enable_non_essential_clocks(void)
};
u32 *const clk_modules_hw_auto_non_essential[] = {
- &prcm->cm_mpu_m3_mpu_m3_clkctrl,
- &prcm->cm_ivahd_ivahd_clkctrl,
- &prcm->cm_ivahd_sl2_clkctrl,
- &prcm->cm_dsp_dsp_clkctrl,
&prcm->cm_l3_2_gpmc_clkctrl,
&prcm->cm_l3instr_l3_3_clkctrl,
&prcm->cm_l3instr_l3_instr_clkctrl,
--
1.7.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] "make menuconfig" does not work
List, "make menuconfig" does not work for u-boot under panadaboard. Old mailing list said because of no Kconfig in u-boot tree. Any plan to add Kconfig or any other way to configure u-boot? Thanks for any help! ---henry ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Can anyone help me to solve the stack problem of U-boot? Urgent~
Dear all: I had a ARM platform which call DVTEST. While booting, the platform (ROM code) will copy image from SD card to SDRAM base address (0x0). So my TEXT_BASE address should be start from 0x. But I found all the ARM platforms in U-boot didn’t start from their SDRAM base address. They also set up the stack pointer by growing up direction /* Set up the stack */ stack_setup: ldrr0, _TEXT_BASE /* upper 128 KiB: relocated uboot */ sub r0, r0, #CONFIG_SYS_MALLOC_LEN /* malloc area */ sub r0, r0, #CONFIG_SYS_GBL_DATA_SIZE /* bdinfo */ My question is can I start U-boot from SDRAM base address (0x)? If so, how to change the stack direction? (GCC option or some else) Please help me because this problem had confused me a lot of days. Thanks. Best Regards. Richard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add support s3c2440 NAND controller
On 04/19/2012 08:53 AM, Ilya Averyanov wrote:
> arch/arm/include/asm/arch-s3c24x0/s3c2410.h |4 +-
> arch/arm/include/asm/arch-s3c24x0/s3c2440.h |4 +-
> arch/arm/include/asm/arch-s3c24x0/s3c24x0.h | 13 +-
> drivers/mtd/nand/Makefile |3 +-
> drivers/mtd/nand/s3c2410_nand.c | 189 ---
> drivers/mtd/nand/s3c24x0_nand.c | 268
> +++
> 6 files changed, 283 insertions(+), 198 deletions(-)
> delete mode 100644 drivers/mtd/nand/s3c2410_nand.c
> create mode 100644 drivers/mtd/nand/s3c24x0_nand.c
>
> diff --git a/arch/arm/include/asm/arch-s3c24x0/s3c2410.h
> b/arch/arm/include/asm/arch-s3c24x0/s3c2410.h
> index 4fbdf20..71eb33e 100644
> --- a/arch/arm/include/asm/arch-s3c24x0/s3c2410.h
> +++ b/arch/arm/include/asm/arch-s3c24x0/s3c2410.h
> @@ -99,9 +99,9 @@ static inline struct s3c24x0_lcd
> *s3c24x0_get_base_lcd(void)
> return (struct s3c24x0_lcd *)S3C24X0_LCD_BASE;
> }
>
> -static inline struct s3c2410_nand *s3c2410_get_base_nand(void)
> +static inline struct s3c24x0_nand *s3c24x0_get_base_nand(void)
> {
> -return (struct s3c2410_nand *)S3C2410_NAND_BASE;
> +return (struct s3c24x0_nand *)S3C2410_NAND_BASE;
> }
Patch is whitespace damaged.
> diff --git a/drivers/mtd/nand/s3c2410_nand.c
> b/drivers/mtd/nand/s3c2410_nand.c
> deleted file mode 100644
> index e1a459b..000
> --- a/drivers/mtd/nand/s3c2410_nand.c
> +++ /dev/null
> @@ -1,189 +0,0 @@
> -/*
> - * (C) Copyright 2006 OpenMoko, Inc.
> - * Author: Harald Welte
> - *
> - * This program is free software; you can redistribute it and/or
> - * modify it under the terms of the GNU General Public License as
> - * published by the Free Software Foundation; either version 2 of
> - * the License, or (at your option) any later version.
Please pass -M -C to git format-patch so it detects renames and copies.
> +#ifdef CONFIG_NAND_SPL
Please try to make the new SPL subsystem work. How tight is your space
restriction?
> +#ifdefCONFIG_S3C2440
One space after #ifdef.
> +static void s3c2440_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int
> ctrl)
> +{
> +struct nand_chip *chip = mtd->priv;
> +struct s3c24x0_nand *nand = s3c24x0_get_base_nand();
> +
> +
> +debug("hwcontrol(): 0x%02x 0x%02x\n", cmd, ctrl);
> +
> +if (ctrl & NAND_CTRL_CHANGE) {
> +ulong IO_ADDR_W = (ulong)nand;
> +
> +if (!(ctrl & NAND_CLE))
> +IO_ADDR_W |= S3C2440_ADDR_NCLE;
> +if (!(ctrl & NAND_ALE))
> +IO_ADDR_W |= S3C2440_ADDR_NALE;
> +
> +chip->IO_ADDR_W = (void *)IO_ADDR_W;
> +
> +if (ctrl & NAND_NCE)
> +writel(readl(&nand->nfcont) & ~S3C2440_NFCONF_nFCE,
> + &nand->nfcont);
> +else
> +writel(readl(&nand->nfcont) | S3C2440_NFCONF_nFCE,
> + &nand->nfcont);
> +}
> +
> +if (cmd != NAND_CMD_NONE)
> +writeb(cmd, chip->IO_ADDR_W);
> +}
> +
> +static int s3c2440_dev_ready(struct mtd_info *mtd)
> +{
> +struct s3c24x0_nand *nand = s3c24x0_get_base_nand();
> +debug("dev_ready\n");
> +return readl(&nand->nfstat) & 0x01;
> +}
> +#else
> +static void s3c2410_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int
> ctrl)
> +{
> +struct nand_chip *chip = mtd->priv;
> +struct s3c24x0_nand *nand = s3c24x0_get_base_nand();
> +
> +
> +debug("hwcontrol(): 0x%02x 0x%02x\n", cmd, ctrl);
> +
> +if (ctrl & NAND_CTRL_CHANGE) {
> +ulong IO_ADDR_W = (ulong)nand;
> +
> +if (!(ctrl & NAND_CLE))
> +IO_ADDR_W |= S3C2410_ADDR_NCLE;
> +if (!(ctrl & NAND_ALE))
> +IO_ADDR_W |= S3C2410_ADDR_NALE;
> +
> +chip->IO_ADDR_W = (void *)IO_ADDR_W;
> +
> +if (ctrl & NAND_NCE)
> +writel(readl(&nand->nfconf) & ~S3C2410_NFCONF_nFCE,
> + &nand->nfconf);
> +else
> +writel(readl(&nand->nfconf) | S3C2410_NFCONF_nFCE,
> + &nand->nfconf);
> +}
> +
> +if (cmd != NAND_CMD_NONE)
> +writeb(cmd, chip->IO_ADDR_W);
> +}
> +
> +static int s3c2410_dev_ready(struct mtd_info *mtd)
> +{
> +struct s3c24x0_nand *nand = s3c24x0_get_base_nand();
> +debug("dev_ready\n");
> +return readl(&nand->nfstat) & 0x01;
> +}
> +#endif
Do you really need to duplicate the code? Can't you just put the
relevant hardware constants in an ifdef, that redefines them with a
non-hardware-specific name?
> +#ifdef CONFIG_SYS_S3C2440_NAND_HWECC
> +void s3c2440_nand_enable_hwecc(struct mtd_info *mtd, int mode)
> +{
> +struct s3c24x0_nand *nand = s3c24x0_get_base_nand();
> +debug("s3c2410_nand_enable_hwecc(%p, %d)\n", mtd, mode);
> +writel((readl(&nand->nfcont) & ~(1 << 5)) | S3C2440_NFCONT_INITECC,
> &nand->nfcont);
> +}
Move that readl out of the writel for readability.
Symbolically define what 1 << 5 means (likewise for other magic numbers).
> +{
> +struct s3c24x0_nand *nand = s3c24x0_get_base_
Re: [U-Boot] [PATCH v3] Allow for parallel builds and saved output
On Wed, Apr 25, 2012 at 3:22 AM, Albert ARIBAUD wrote: > Hi Andy, > > Le 25/04/2012 07:33, Andy Fleming a écrit : > *However*, two boards build without and do not build clean with: scpu and > pndb3. Ok, I figured that one out, and sent out a patch. > > Also, the final report is not displayed as the same with and without the > patch -- with it, unclean boards are listed one per line, without it, they > are listed in a single line. I can probably fix that, no problem. > > Last: breaking during a parallel build then trying a git clean -xfd causes > errors such as files missing. I believe what you're seeing is that there are still builds running after you've hit ctrl-C, and they continue until they're done. I think I've got it figured out, so I'll fix that in my followup. Andy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Can anyone help me to solve the stack problem of U-boot? Urgent~
Dear =?big5?B?p2Sn065w?=, In message <001e01cd2301$609c2e00$21d48a00$@x...@msa.hinet.net> you wrote: ... Urgent~ ... > Please help me because this problem had confused me a lot of days. Please see the README (section "U-Boot Porting Guide", but also section "System Initialization"), and read doc/README.SPL and http://catb.org/esr/faqs/smart-questions.html If this is urgent, and you spent many days on this, then the best advice for you is to hire an expert. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "Unix is simple, but it takes a genius to understand the simplicity." - Dennis Ritchie ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 6/7] tegra: nand: Add Tegra NAND driver
On 04/17/2012 01:50 PM, Simon Glass wrote:
> +#define DEBUG
Did you mean to leave this in?
> +/**
> + * [DEFAULT] Read one byte from the chip
> + *
> + * @param mtdMTD device structure
> + * @return data byte
> + *
> + * Default read function for 8bit bus-width
> + */
This isn't the default read function, it's the tegra read function.
> +static uint8_t read_byte(struct mtd_info *mtd)
> +{
> + struct nand_chip *chip = mtd->priv;
> + u32 dword_read;
> + struct nand_drv *info;
> +
> + info = (struct nand_drv *)chip->priv;
> + if (info->pio_byte_index > 3)
> + return 0;
> +
> + /* We can read this data multiple times and get the same word */
> + dword_read = readl(&info->reg->resp);
> + dword_read = dword_read >> (8 * info->pio_byte_index);
> + info->pio_byte_index++;
> + return (uint8_t)dword_read;
> +}
So you only read up to 4 bytes via this method? If this is really all
that's ever needed, please add a comment to that effect.
> +/**
> + * [DEFAULT] Write buffer to chip
> + *
> + * @param mtdMTD device structure
> + * @param bufdata buffer
> + * @param lennumber of bytes to write
> + *
> + * Default write function for 8bit bus-width
> + */
> +static void write_buf(struct mtd_info *mtd, const uint8_t *buf, int len)
> +{
> + int i, j, l;
> + struct nand_chip *chip = mtd->priv;
> + struct nand_drv *info;
> +
> + info = (struct nand_drv *)chip->priv;
> +
> + for (i = 0; i < len / 4; i++) {
> + l = ((int *)buf)[i];
If you're assuming the buffer is 32-bit aligned, comment it. Ideally
these assumptions should be stated in the interface itself...
Should also comment that there's an endian dependency here.
> + writel(l, &info->reg->resp);
> + writel(CMD_GO | CMD_PIO | CMD_TX |
> + ((4 - 1) << CMD_TRANS_SIZE_SHIFT)
> + | CMD_A_VALID | CMD_CE0,
> + &info->reg->command);
> +
> + if (!nand_waitfor_cmd_completion(info->reg))
> + printf("Command timeout during write_buf\n");
You need to wait for completion every 4 bytes? Where is the DMA?
> + case NAND_CMD_RNDOUT:
> + printf("%s: Unsupported RNDOUT command\n", __func__);
> + return;
[snip]
> + default:
> + printf("%s: Unsupported command %d\n", __func__, command);
> + return;
> + }
Doesn't the print in the default case already handle RNDOUT?
> + if ((reg_val & DEC_STATUS_A_ECC_FAIL) && databuf) {
> + reg_val = readl(®->bch_dec_status_buf);
> + /*
> + * If uncorrectable error occurs on data area, then see whether
> + * they are all FF. If all are FF, it's a blank page.
> + * Not error.
> + */
> + if ((reg_val & BCH_DEC_STATUS_FAIL_SEC_FLAG_MASK) &&
> + !blank_check(databuf, a_len))
> + return_val |= ECC_DATA_ERROR;
> + }
> +
> + if ((reg_val & DEC_STATUS_B_ECC_FAIL) && oobbuf) {
> + reg_val = readl(®->bch_dec_status_buf);
> + /*
> + * If uncorrectable error occurs on tag area, then see whether
> + * they are all FF. If all are FF, it's a blank page.
> + * Not error.
> + */
> + if ((reg_val & BCH_DEC_STATUS_FAIL_TAG_MASK) &&
> + !blank_check(oobbuf, b_len))
> + return_val |= ECC_TAG_ERROR;
Please don't line up the continuation line with the if-body.
What is the difference between an "A" fail and a "B" fail? Do you
really want to do the blank_check twice?
> + /* Need to be 4-byte aligned */
> + tag_ptr = (char *)&tag_buf;
>
> +
> + stop_command(info->reg);
> +
> + writel((1 << chip->page_shift) - 1, &info->reg->dma_cfg_a);
> + writel((u32)buf, &info->reg->data_block_ptr);
> +
> + if (with_ecc) {
> + writel((u32)tag_ptr, &info->reg->tag_ptr);
> + if (is_writing)
> + memcpy(tag_ptr, chip->oob_poi + free->offset,
> + config->tag_bytes +
> + config->tag_ecc_bytes);
> + } else
> + writel((u32)chip->oob_poi, &info->reg->tag_ptr);
Should use virt_to_phys(), even if it currently makes no difference on
this platform.
> +int fdt_decode_nand(const void *blob, int node, struct fdt_nand *config)
Make this static.
> +/**
> + * Board-specific NAND initialization
> + *
> + * @param nand nand chip info structure
> + * @return 0, after initialized, -1 on error
> + */
> +int board_nand_init(struct nand_chip *nand)
Please consider using CONFIG_SYS_NAND_SELF_INIT.
> diff --git a/drivers/mtd/nand/tegra2_nand.h b/drivers/mtd/nand/tegra2_nand.h
> new file mode 100644
> index 000..7e74be7
> --- /dev/null
> +++ b/drivers/mtd/nand/tegra2_nand.h
> @@ -0,0 +1,257 @@
> +/*
> + * (C
Re: [U-Boot] Using sata on mx6qsabrelite
On 04/25/2012 12:10 PM, Eric Nelson wrote: On 04/25/2012 11:40 AM, Fabio Estevam wrote: Hi, On Stefano´s tree I see this sata patch for mx5/mx6: http://git.denx.de/?p=u-boot/u-boot-imx.git;a=commit;h=6931bd30d03de827c52bf2c8ddc6ed0c8f21dc9d Has anyone tried sata support on mx6qsabrelite yet? Any patches missing that were not applied? I don't have a way to test it at the moment, but I have a colleague that wants to use sata on mx6qsabrelite. Hi Fabio, I've tried it and it just worked for me, but it's been a month or so. It looks like I'm a bit forgetful. It didn't __just work__. It required a couple of patches that seem to be lingering: http://patchwork.ozlabs.org/patch/148600/ http://patchwork.ozlabs.org/patch/148599/ I'll dig out my SATA drive and test again this afternoon. I'll rebase and test. Stefano, I'm not sure if the second patch above is on my plate or yours. I'll review the history and see. I think you had asked for a meaningful error code instead of returning -1, but that would require an update to the first patch (clock enabling) to maybe return -ETIMEDOUT or something. Regards, Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: Integrate latest yaffs2
On Thu, Apr 26, 2012 at 09:08:42AM +1200, Charles Manning wrote: > On Tuesday 24 April 2012 08:58:09 you wrote: > > Dear Charles Manning, > > > > In message <201204231346.32195.mannin...@actrix.gen.nz> you wrote: > > > I recently sent a message to the list announcing a method for patching in > > > the latest yaffs2. > > > > > > u-boot updated with the latest yaffs2 can be pulled from > > > g...@github.com:cdhmanning/u-boot-yaffs2.git > > > > Please read http://www.denx.de/wiki/U-Boot/Patches and post proper > > patch(es) for review. > > At least one of the files exceeds the 100k patch limit. > > I know you'd like patches, but there are two really easy options for someone > on the inside to do this: > > 1) Run the script off the yaffs git > -or- > 2) Merge from the https://github.com/cdhmanning/u-boot-yaffs2 So this means things have gotten really far out of sync. Would you be willing to say that in the future you'll be submitting regular well formatted and broken down patches like I assume you do in the yaffs2 tree itself so we can avoid this in the future? -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] "make menuconfig" does not work
Hi Henry, On Thu, Apr 26, 2012 at 4:21 AM, hong zhang wrote: > List, > > "make menuconfig" does not work for u-boot under panadaboard. > Old mailing list said because of no Kconfig in u-boot tree. Correct - new mailing list says the same thing ;) > Any plan to add Kconfig or any other way to configure u-boot? Not that I am aware of, but I would support anyone who submitted patches to add Kconfig support (it would be great to get U-Boot added to buildroot as well - One build for bootloader + kernel + root filesystem :) Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: Integrate latest yaffs2
On Thursday 26 April 2012 10:21:37 Tom Rini wrote: > On Thu, Apr 26, 2012 at 09:08:42AM +1200, Charles Manning wrote: > > On Tuesday 24 April 2012 08:58:09 you wrote: > > > Dear Charles Manning, > > > > > > In message <201204231346.32195.mannin...@actrix.gen.nz> you wrote: > > > > I recently sent a message to the list announcing a method for > > > > patching in the latest yaffs2. > > > > > > > > u-boot updated with the latest yaffs2 can be pulled from > > > > g...@github.com:cdhmanning/u-boot-yaffs2.git > > > > > > Please read http://www.denx.de/wiki/U-Boot/Patches and post proper > > > patch(es) for review. > > > > At least one of the files exceeds the 100k patch limit. > > > > I know you'd like patches, but there are two really easy options for > > someone on the inside to do this: > > > > 1) Run the script off the yaffs git > > -or- > > 2) Merge from the https://github.com/cdhmanning/u-boot-yaffs2 > > So this means things have gotten really far out of sync. Would you be > willing to say that in the future you'll be submitting regular well > formatted and broken down patches like I assume you do in the yaffs2 > tree itself so we can avoid this in the future? yaffs went through a large reformat a while ago meaning that the current code does not diff well against the old code. Future changes shuld be a lot easier to handle with direct patching. yaffs changes typically don't go through the yaffs list since people with direct git checkin access do 95-99% of the changes. -- CHarles ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: Integrate latest yaffs2
On 04/25/2012 03:28 PM, Charles Manning wrote: On Thursday 26 April 2012 10:21:37 Tom Rini wrote: On Thu, Apr 26, 2012 at 09:08:42AM +1200, Charles Manning wrote: On Tuesday 24 April 2012 08:58:09 you wrote: Dear Charles Manning, In message<201204231346.32195.mannin...@actrix.gen.nz> you wrote: I recently sent a message to the list announcing a method for patching in the latest yaffs2. u-boot updated with the latest yaffs2 can be pulled from g...@github.com:cdhmanning/u-boot-yaffs2.git Please read http://www.denx.de/wiki/U-Boot/Patches and post proper patch(es) for review. At least one of the files exceeds the 100k patch limit. I know you'd like patches, but there are two really easy options for someone on the inside to do this: 1) Run the script off the yaffs git -or- 2) Merge from the https://github.com/cdhmanning/u-boot-yaffs2 So this means things have gotten really far out of sync. Would you be willing to say that in the future you'll be submitting regular well formatted and broken down patches like I assume you do in the yaffs2 tree itself so we can avoid this in the future? yaffs went through a large reformat a while ago meaning that the current code does not diff well against the old code. Future changes shuld be a lot easier to handle with direct patching. yaffs changes typically don't go through the yaffs list since people with direct git checkin access do 95-99% of the changes. Right, but a proper set of individual patches could be posted and reviewed in the future, yes? -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: Integrate latest yaffs2
On Thursday 26 April 2012 10:40:51 Tom Rini wrote: > On 04/25/2012 03:28 PM, Charles Manning wrote: > > On Thursday 26 April 2012 10:21:37 Tom Rini wrote: > >> On Thu, Apr 26, 2012 at 09:08:42AM +1200, Charles Manning wrote: > >>> On Tuesday 24 April 2012 08:58:09 you wrote: > Dear Charles Manning, > > In message<201204231346.32195.mannin...@actrix.gen.nz> you wrote: > > I recently sent a message to the list announcing a method for > > patching in the latest yaffs2. > > > > u-boot updated with the latest yaffs2 can be pulled from > > g...@github.com:cdhmanning/u-boot-yaffs2.git > > Please read http://www.denx.de/wiki/U-Boot/Patches and post proper > patch(es) for review. > >>> > >>> At least one of the files exceeds the 100k patch limit. > >>> > >>> I know you'd like patches, but there are two really easy options for > >>> someone on the inside to do this: > >>> > >>> 1) Run the script off the yaffs git > >>> -or- > >>> 2) Merge from the https://github.com/cdhmanning/u-boot-yaffs2 > >> > >> So this means things have gotten really far out of sync. Would you be > >> willing to say that in the future you'll be submitting regular well > >> formatted and broken down patches like I assume you do in the yaffs2 > >> tree itself so we can avoid this in the future? > > > > yaffs went through a large reformat a while ago meaning that the current > > code does not diff well against the old code. Future changes shuld be a > > lot easier to handle with direct patching. > > > > yaffs changes typically don't go through the yaffs list since people > > with direct git checkin access do 95-99% of the changes. > > Right, but a proper set of individual patches could be posted and > reviewed in the future, yes? That makes sense to me. -- Charles ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Remove remaining mdelay() macros
Acked-by: Mike Frysinger -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] CONFIG_SYS_BAUDRATE_TABLE: Place default into
On Wednesday 25 April 2012 14:46:27 Tom Rini wrote:
> --- a/mkconfig
> +++ b/mkconfig
> @@ -167,6 +167,11 @@ cat << EOF >> config.h
> #include
> #include
> #include
> +
> +/* Default baud rate table */
> +#ifndef CONFIG_SYS_BAUDRATE_TABLE
> +#define CONFIG_SYS_BAUDRATE_TABLE{ 9600, 19200, 38400, 57600, 115200 }
> +#endif
> EOF
seems like we should add a new config_fallbacks.h and include that after
asm/config.h rather than coding C in mkconfig
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] mmc: tegra: invalidate complete cachelines
On Tuesday 24 April 2012 03:53:44 Thierry Reding wrote: > The MMC core sometimes reads buffers that are smaller than a complete > cacheline, for example when reading the SCR. In order to avoid a warning > from the ARM v7 cache handling code, this patch makes sure that complete > cachelines are flushed. this is still wrong. all you've done is bypass the error message without addressing the underlying problem -- you're invalidating too much. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/3] usb:gadget:composite USB composite gadget support
Dear Lukasz Majewski, > USB Composite gadget implementation for u-boot. It builds on top > of USB UDC drivers. > > This commit is based on following files from Linux Kernel v2.6.36: > > ./include/linux/usb/composite.h > ./drivers/usb/gadget/composite.c > > SHA1: d187abb9a83e6c6b6e9f2ca17962bdeafb4bc903 > > Signed-off-by: Lukasz Majewski > Signed-off-by: Kyungmin Park > Cc: Marek Vasut > Quick glance through this looks fine, I'll preempt here and check the rest in a few days ... sorry for the delays, I'm overloaded, please understand :-( 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 2/2] i.MX6: mx6q_sabrelite: add SATA bindings
On 03/26/2012 09:59 AM, Eric Nelson wrote:
On 03/26/2012 06:42 AM, Stefano Babic wrote:
On 26/03/2012 15:35, Eric Nelson wrote:
On 03/26/2012 01:35 AM, Stefano Babic wrote:
On 26/03/2012 01:00, Eric Nelson wrote:
V2 has been stripped of the board-independent changes and
+#ifdef CONFIG_CMD_SATA
+
+int setup_sata(void)
+{
+ int rval = enable_sata_clock();
What about to return at this point if there is an error ?
I'm not sure I understand. Do you mean re-structure the code with
two returns like this?
No, much easier - I find the code is easy to understand if it looks like
if the function returns immediately in case of error.
if (do_something())
return ERROR;
< code when no error happens>
Your enable_sata_clock() return only -1 in case of error. You could
easy write:
if (enable_sata_clock())
return -1 (or better a value in errno.h)
>
The choice of error code is better made inside enable_sata_clock(),
although I'm not really sure what error code to choose.
The error occurs if the PLL fails to lock and would indicate that
something's horribly wrong.
I'm guessing -EIO is probably the right choice.
If you agree, I'll send V2 of "i.MX6: add enable_sata_clock()" and
V3 of "i.MX6: mx6q_sabrelite: add SATA bindings".
Hi Stefano,
It looks like I was waiting for you and never did send V3 of this patch.
I'll forward one shortly.
Regards,
Eric
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] TRATS: initialize panel_info data structure in board file
panel_info data structure is gloable variable, so, I have initialized it
in board file. If it is initialized in init_panel_info() like existing,
it can't be used in drv_lcd_init() in common/lcd.c because
init_panel_info() is called after drv_lcd_init().
change of v1:
- I had made a mistake that must do not included variables of vidinfo_t
data structure was included in the file. So, I removed it.
Signed-off-by: Donghwa Lee
Signed-off-by: Kyungmin Park
---
board/samsung/trats/trats.c | 71 ++-
drivers/video/exynos_fb.c |3 --
2 files changed, 36 insertions(+), 38 deletions(-)
diff --git a/board/samsung/trats/trats.c b/board/samsung/trats/trats.c
index 3085de1..084b67a 100644
--- a/board/samsung/trats/trats.c
+++ b/board/samsung/trats/trats.c
@@ -455,43 +455,44 @@ static int mipi_power(void)
return 0;
}
+vidinfo_t panel_info = {
+ .vl_freq= 60,
+ .vl_col = 720,
+ .vl_row = 1280,
+ .vl_width = 720,
+ .vl_height = 1280,
+ .vl_clkp= CONFIG_SYS_HIGH,
+ .vl_hsp = CONFIG_SYS_LOW,
+ .vl_vsp = CONFIG_SYS_LOW,
+ .vl_dp = CONFIG_SYS_LOW,
+ .vl_bpix= 5,/* Bits per pixel, 2^5 = 32 */
+
+ /* s6e8ax0 Panel infomation */
+ .vl_hspw= 5,
+ .vl_hbpd= 10,
+ .vl_hfpd= 10,
+
+ .vl_vspw= 2,
+ .vl_vbpd= 1,
+ .vl_vfpd= 13,
+ .vl_cmd_allow_len = 0xf,
+
+ .win_id = 3,
+ .cfg_gpio = NULL,
+ .backlight_on = NULL,
+ .lcd_power_on = NULL, /* lcd_power_on in mipi dsi driver */
+ .reset_lcd = lcd_reset,
+ .dual_lcd_enabled = 0,
+
+ .init_delay = 0,
+ .power_on_delay = 0,
+ .reset_delay= 0,
+ .interface_mode = FIMD_RGB_INTERFACE,
+ .mipi_enabled = 1,
+};
+
void init_panel_info(vidinfo_t *vid)
{
- vid->vl_freq= 60;
- vid->vl_col = 720;
- vid->vl_row = 1280;
- vid->vl_width = 720;
- vid->vl_height = 1280;
- vid->vl_clkp= CONFIG_SYS_HIGH;
- vid->vl_hsp = CONFIG_SYS_LOW;
- vid->vl_vsp = CONFIG_SYS_LOW;
- vid->vl_dp = CONFIG_SYS_LOW;
-
- vid->vl_bpix= 5;
- vid->dual_lcd_enabled = 0;
-
- /* s6e8ax0 Panel */
- vid->vl_hspw= 5;
- vid->vl_hbpd= 10;
- vid->vl_hfpd= 10;
-
- vid->vl_vspw= 2;
- vid->vl_vbpd= 1;
- vid->vl_vfpd= 13;
- vid->vl_cmd_allow_len = 0xf;
-
- vid->win_id = 3;
- vid->cfg_gpio = NULL;
- vid->backlight_on = NULL;
- vid->lcd_power_on = NULL; /* lcd_power_on in mipi dsi driver */
- vid->reset_lcd = lcd_reset;
-
- vid->init_delay = 0;
- vid->power_on_delay = 0;
- vid->reset_delay = 0;
- vid->interface_mode = FIMD_RGB_INTERFACE;
- vid->mipi_enabled = 1;
-
strcpy(s6e8ax0_platform_data.lcd_panel_name, mipi_lcd_device.name);
s6e8ax0_platform_data.lcd_power = lcd_power;
s6e8ax0_platform_data.mipi_power = mipi_power;
diff --git a/drivers/video/exynos_fb.c b/drivers/video/exynos_fb.c
index a1cf449..96a8ec1 100644
--- a/drivers/video/exynos_fb.c
+++ b/drivers/video/exynos_fb.c
@@ -44,9 +44,6 @@ short console_row;
static unsigned int panel_width, panel_height;
-/* LCD Panel data */
-vidinfo_t panel_info;
-
static void exynos_lcd_init_mem(void *lcdbase, vidinfo_t *vid)
{
unsigned long palette_size;
--
1.7.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add support s3c2440 NAND controller
Dear Scott Wood,
> On 04/19/2012 08:53 AM, Ilya Averyanov wrote:
> > arch/arm/include/asm/arch-s3c24x0/s3c2410.h |4 +-
> > arch/arm/include/asm/arch-s3c24x0/s3c2440.h |4 +-
> > arch/arm/include/asm/arch-s3c24x0/s3c24x0.h | 13 +-
> > drivers/mtd/nand/Makefile |3 +-
> > drivers/mtd/nand/s3c2410_nand.c | 189 ---
> > drivers/mtd/nand/s3c24x0_nand.c | 268
> >
> > +++
> >
> > 6 files changed, 283 insertions(+), 198 deletions(-)
> > delete mode 100644 drivers/mtd/nand/s3c2410_nand.c
> > create mode 100644 drivers/mtd/nand/s3c24x0_nand.c
> >
> > diff --git a/arch/arm/include/asm/arch-s3c24x0/s3c2410.h
> > b/arch/arm/include/asm/arch-s3c24x0/s3c2410.h
> > index 4fbdf20..71eb33e 100644
> > --- a/arch/arm/include/asm/arch-s3c24x0/s3c2410.h
> > +++ b/arch/arm/include/asm/arch-s3c24x0/s3c2410.h
> > @@ -99,9 +99,9 @@ static inline struct s3c24x0_lcd
> > *s3c24x0_get_base_lcd(void)
> >
> > return (struct s3c24x0_lcd *)S3C24X0_LCD_BASE;
> >
> > }
> >
> > -static inline struct s3c2410_nand *s3c2410_get_base_nand(void)
> > +static inline struct s3c24x0_nand *s3c24x0_get_base_nand(void)
> >
> > {
> >
> > -return (struct s3c2410_nand *)S3C2410_NAND_BASE;
> > +return (struct s3c24x0_nand *)S3C2410_NAND_BASE;
> >
> > }
>
> Patch is whitespace damaged.
>
> > diff --git a/drivers/mtd/nand/s3c2410_nand.c
> > b/drivers/mtd/nand/s3c2410_nand.c
> > deleted file mode 100644
> > index e1a459b..000
> > --- a/drivers/mtd/nand/s3c2410_nand.c
> > +++ /dev/null
> > @@ -1,189 +0,0 @@
> > -/*
> > - * (C) Copyright 2006 OpenMoko, Inc.
> > - * Author: Harald Welte
> > - *
> > - * This program is free software; you can redistribute it and/or
> > - * modify it under the terms of the GNU General Public License as
> > - * published by the Free Software Foundation; either version 2 of
> > - * the License, or (at your option) any later version.
>
> Please pass -M -C to git format-patch so it detects renames and copies.
>
> > +#ifdef CONFIG_NAND_SPL
>
> Please try to make the new SPL subsystem work. How tight is your space
> restriction?
Blasting 4k!!! He has so much space he can swim in it!
>
> > +#ifdefCONFIG_S3C2440
>
> One space after #ifdef.
>
> > +static void s3c2440_hwcontrol(struct mtd_info *mtd, int cmd, unsigned
> > int ctrl)
> > +{
> > +struct nand_chip *chip = mtd->priv;
> > +struct s3c24x0_nand *nand = s3c24x0_get_base_nand();
> > +
> > +
> > +debug("hwcontrol(): 0x%02x 0x%02x\n", cmd, ctrl);
> > +
> > +if (ctrl & NAND_CTRL_CHANGE) {
> > +ulong IO_ADDR_W = (ulong)nand;
> > +
> > +if (!(ctrl & NAND_CLE))
> > +IO_ADDR_W |= S3C2440_ADDR_NCLE;
> > +if (!(ctrl & NAND_ALE))
> > +IO_ADDR_W |= S3C2440_ADDR_NALE;
> > +
> > +chip->IO_ADDR_W = (void *)IO_ADDR_W;
> > +
> > +if (ctrl & NAND_NCE)
> > +writel(readl(&nand->nfcont) & ~S3C2440_NFCONF_nFCE,
> > + &nand->nfcont);
> > +else
> > +writel(readl(&nand->nfcont) | S3C2440_NFCONF_nFCE,
> > + &nand->nfcont);
> > +}
> > +
> > +if (cmd != NAND_CMD_NONE)
> > +writeb(cmd, chip->IO_ADDR_W);
> > +}
> > +
> > +static int s3c2440_dev_ready(struct mtd_info *mtd)
> > +{
> > +struct s3c24x0_nand *nand = s3c24x0_get_base_nand();
> > +debug("dev_ready\n");
> > +return readl(&nand->nfstat) & 0x01;
> > +}
> > +#else
> > +static void s3c2410_hwcontrol(struct mtd_info *mtd, int cmd, unsigned
> > int ctrl)
> > +{
> > +struct nand_chip *chip = mtd->priv;
> > +struct s3c24x0_nand *nand = s3c24x0_get_base_nand();
> > +
> > +
> > +debug("hwcontrol(): 0x%02x 0x%02x\n", cmd, ctrl);
> > +
> > +if (ctrl & NAND_CTRL_CHANGE) {
> > +ulong IO_ADDR_W = (ulong)nand;
> > +
> > +if (!(ctrl & NAND_CLE))
> > +IO_ADDR_W |= S3C2410_ADDR_NCLE;
> > +if (!(ctrl & NAND_ALE))
> > +IO_ADDR_W |= S3C2410_ADDR_NALE;
> > +
> > +chip->IO_ADDR_W = (void *)IO_ADDR_W;
> > +
> > +if (ctrl & NAND_NCE)
> > +writel(readl(&nand->nfconf) & ~S3C2410_NFCONF_nFCE,
> > + &nand->nfconf);
> > +else
> > +writel(readl(&nand->nfconf) | S3C2410_NFCONF_nFCE,
> > + &nand->nfconf);
> > +}
> > +
> > +if (cmd != NAND_CMD_NONE)
> > +writeb(cmd, chip->IO_ADDR_W);
> > +}
> > +
> > +static int s3c2410_dev_ready(struct mtd_info *mtd)
> > +{
> > +struct s3c24x0_nand *nand = s3c24x0_get_base_nand();
> > +debug("dev_ready\n");
> > +return readl(&nand->nfstat) & 0x01;
> > +}
> > +#endif
>
> Do you really need to duplicate the code? Can't you just put the
> relevant hardware constants in an ifdef, that redefines them with a
> non-hardware-specific name?
>
> > +#ifdef CONFIG_SYS_S3C2440_NAND_HWECC
> > +void s3c2440_nand_enable_hwecc(struct mtd_info *mtd, int mode)
> > +{
> > +str
[U-Boot] [PATCH, V2] Resend: i.MX6: add enable_sata_clock()
This patch requires Stefano's driver for MX5/MX6 to be useful.
http://lists.denx.de/pipermail/u-boot/2012-February/118530.html
This is the first and board-independent part of what's needed to enable
SATA on an i.MX6 board as discussed in this thread:
http://lists.denx.de/pipermail/u-boot/2012-March/120919.html
Signed-off-by: Eric Nelson
---
V2 updated to return -EIO instead of -1.
arch/arm/cpu/armv7/mx6/clock.c | 31
arch/arm/include/asm/arch-mx6/clock.h|1 +
arch/arm/include/asm/arch-mx6/imx-regs.h |9 +++
arch/arm/include/asm/arch-mx6/iomux-v3.h | 111 ++
4 files changed, 152 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c
index ef98563..de91cac 100644
--- a/arch/arm/cpu/armv7/mx6/clock.c
+++ b/arch/arm/cpu/armv7/mx6/clock.c
@@ -303,6 +303,37 @@ u32 imx_get_fecclk(void)
return decode_pll(PLL_ENET, CONFIG_SYS_MX6_HCLK);
}
+int enable_sata_clock(void)
+{
+ u32 reg = 0;
+ s32 timeout = 10;
+ struct imx_ccm_reg *const imx_ccm
+ = (struct imx_ccm_reg *) CCM_BASE_ADDR;
+
+ /* Enable sata clock */
+ reg = readl(&imx_ccm->CCGR5); /* CCGR5 */
+ reg |= MXC_CCM_CCGR5_CG2_MASK;
+ writel(reg, &imx_ccm->CCGR5);
+
+ /* Enable PLLs */
+ reg = readl(&imx_ccm->analog_pll_enet);
+ reg &= ~BM_ANADIG_PLL_SYS_POWERDOWN;
+ writel(reg, &imx_ccm->analog_pll_enet);
+ reg |= BM_ANADIG_PLL_SYS_ENABLE;
+ while (timeout--) {
+ if (readl(&imx_ccm->analog_pll_enet) & BM_ANADIG_PLL_SYS_LOCK)
+ break;
+ }
+ if (timeout <= 0)
+ return -EIO;
+ reg &= ~BM_ANADIG_PLL_SYS_BYPASS;
+ writel(reg, &imx_ccm->analog_pll_enet);
+ reg |= BM_ANADIG_PLL_ENET_ENABLE_SATA;
+ writel(reg, &imx_ccm->analog_pll_enet);
+
+ return 0 ;
+}
+
unsigned int mxc_get_clock(enum mxc_clock clk)
{
switch (clk) {
diff --git a/arch/arm/include/asm/arch-mx6/clock.h
b/arch/arm/include/asm/arch-mx6/clock.h
index 613809b..b91d8bf 100644
--- a/arch/arm/include/asm/arch-mx6/clock.h
+++ b/arch/arm/include/asm/arch-mx6/clock.h
@@ -47,5 +47,6 @@ u32 imx_get_uartclk(void);
u32 imx_get_fecclk(void);
unsigned int mxc_get_clock(enum mxc_clock clk);
void enable_usboh3_clk(unsigned char enable);
+int enable_sata_clock(void);
#endif /* __ASM_ARCH_CLOCK_H */
diff --git a/arch/arm/include/asm/arch-mx6/imx-regs.h
b/arch/arm/include/asm/arch-mx6/imx-regs.h
index 6d25c8d..e165810 100644
--- a/arch/arm/include/asm/arch-mx6/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx6/imx-regs.h
@@ -436,5 +436,14 @@ struct anatop_regs {
u32 digprog;/* 0x260 */
};
+struct iomuxc_base_regs {
+ u32 gpr[14];/* 0x000 */
+ u32 obsrv[5]; /* 0x038 */
+ u32 swmux_ctl[197]; /* 0x04c */
+ u32 swpad_ctl[250]; /* 0x360 */
+ u32 swgrp[26]; /* 0x748 */
+ u32 daisy[104]; /* 0x7b0..94c */
+};
+
#endif /* __ASSEMBLER__*/
#endif /* __ASM_ARCH_MX6_IMX_REGS_H__ */
diff --git a/arch/arm/include/asm/arch-mx6/iomux-v3.h
b/arch/arm/include/asm/arch-mx6/iomux-v3.h
index 4558f4f..788b413 100644
--- a/arch/arm/include/asm/arch-mx6/iomux-v3.h
+++ b/arch/arm/include/asm/arch-mx6/iomux-v3.h
@@ -100,4 +100,115 @@ typedef u64 iomux_v3_cfg_t;
int imx_iomux_v3_setup_pad(iomux_v3_cfg_t pad);
int imx_iomux_v3_setup_multiple_pads(iomux_v3_cfg_t *pad_list, unsigned count);
+/*
+ * IOMUXC_GPR13 bit fields
+ */
+#define IOMUXC_GPR13_SDMA_STOP_REQ (1<<30)
+#define IOMUXC_GPR13_CAN2_STOP_REQ (1<<29)
+#define IOMUXC_GPR13_CAN1_STOP_REQ (1<<28)
+#define IOMUXC_GPR13_ENET_STOP_REQ (1<<27)
+#define IOMUXC_GPR13_SATA_PHY_8_MASK (7<<24)
+#define IOMUXC_GPR13_SATA_PHY_7_MASK (0x1f<<19)
+#define IOMUXC_GPR13_SATA_PHY_6_SHIFT 16
+#define IOMUXC_GPR13_SATA_PHY_6_MASK (7
[U-Boot] [PATCH V3] i.MX6: mx6q_sabrelite: add SATA bindings
Signed-off-by: Eric Nelson
---
V2 has been stripped of the board-independent changes and
uses clrsetbits_le32() instead of twiddling bits by hand.
V3 returns immediately from setup_sata() if enable_sata_clock()
returns an error.
board/freescale/mx6qsabrelite/mx6qsabrelite.c | 32 +
include/configs/mx6qsabrelite.h | 13 ++
2 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/board/freescale/mx6qsabrelite/mx6qsabrelite.c
b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
index 1d09a72..c9a108f 100644
--- a/board/freescale/mx6qsabrelite/mx6qsabrelite.c
+++ b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
@@ -25,6 +25,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -267,6 +269,32 @@ int board_eth_init(bd_t *bis)
return 0;
}
+#ifdef CONFIG_CMD_SATA
+
+int setup_sata(void)
+{
+ struct iomuxc_base_regs *const iomuxc_regs
+ = (struct iomuxc_base_regs *) IOMUXC_BASE_ADDR;
+ int rval = enable_sata_clock();
+ if (rval)
+ return rval ;
+
+ 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
+ |(3
Re: [U-Boot] Using sata on mx6qsabrelite
On 04/25/2012 03:11 PM, Eric Nelson wrote: On 04/25/2012 12:10 PM, Eric Nelson wrote: On 04/25/2012 11:40 AM, Fabio Estevam wrote: Hi, On Stefano´s tree I see this sata patch for mx5/mx6: http://git.denx.de/?p=u-boot/u-boot-imx.git;a=commit;h=6931bd30d03de827c52bf2c8ddc6ed0c8f21dc9d Has anyone tried sata support on mx6qsabrelite yet? Any patches missing that were not applied? I don't have a way to test it at the moment, but I have a colleague that wants to use sata on mx6qsabrelite. Hi Fabio, I've tried it and it just worked for me, but it's been a month or so. It looks like I'm a bit forgetful. It didn't __just work__. It required a couple of patches that seem to be lingering: http://patchwork.ozlabs.org/patch/148600/ http://patchwork.ozlabs.org/patch/148599/ I'll dig out my SATA drive and test again this afternoon. I'll rebase and test. Hi Fabio, I just re-based and re-sent two of the three patches needed to get SATA up and running against mainline/master. MX6QSABRELITE U-Boot > sata init AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl SATA mode flags: ncq stag pm led clo only pmp pio slum part SATA Device Info: S/N:26EK5486T Product model number: TOSHIBA MK4032GSX Firmware version: AS212D Capacity: 75200265 sectors MX6QSABRELITE U-Boot > ext2ls sata 0:1 / 4096 . 4096 .. 16384 lost+found 4096 bin 4096 mnt 4096 lib 4096 var 4096 root The third commit is Stefano's SATA driver for i.MX5/6: http://git.denx.de/u-boot-imx.git/?p=u-boot/u-boot-imx.git;a=commit;h=6931bd30d03de827c52bf2c8ddc6ed0c8f21dc9d The two new patches are here: http://lists.denx.de/pipermail/u-boot/2012-April/123168.html and here: http://lists.denx.de/pipermail/u-boot/2012-April/123169.html Regards, Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] i.MX6Q: mx6qsabrelite: Add keypress support to alter boot flow
Uses the 'magic_keys' idiom as described in doc/README.kbd:
http://lists.denx.de/pipermail/u-boot/2012-April/122502.html
Signed-off-by: Eric Nelson
Acked-by: Marek Vasut
---
board/freescale/mx6qsabrelite/mx6qsabrelite.c | 122 -
include/configs/mx6qsabrelite.h |3 +
2 files changed, 123 insertions(+), 2 deletions(-)
diff --git a/board/freescale/mx6qsabrelite/mx6qsabrelite.c
b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
index db5e775..f63cef7 100644
--- a/board/freescale/mx6qsabrelite/mx6qsabrelite.c
+++ b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
@@ -52,6 +52,10 @@ DECLARE_GLOBAL_DATA_PTR;
PAD_CTL_PUS_100K_DOWN | PAD_CTL_SPEED_MED | \
PAD_CTL_DSE_40ohm | PAD_CTL_SRE_FAST)
+#define BUTTON_PAD_CTRL (PAD_CTL_PKE | PAD_CTL_PUE | \
+ PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED | \
+ PAD_CTL_DSE_40ohm | PAD_CTL_HYS)
+
int dram_init(void)
{
gd->ram_size = get_ram_size((void *)PHYS_SDRAM, PHYS_SDRAM_SIZE);
@@ -124,6 +128,22 @@ iomux_v3_cfg_t enet_pads2[] = {
MX6Q_PAD_RGMII_RX_CTL__RGMII_RX_CTL | MUX_PAD_CTRL(ENET_PAD_CTRL),
};
+/* Button assignments for J14 */
+static iomux_v3_cfg_t button_pads[] = {
+ /* Menu */
+ MX6Q_PAD_NANDF_D1__GPIO_2_1 | MUX_PAD_CTRL(BUTTON_PAD_CTRL),
+ /* Back */
+ MX6Q_PAD_NANDF_D2__GPIO_2_2 | MUX_PAD_CTRL(BUTTON_PAD_CTRL),
+ /* Labelled Search (mapped to Power under Android) */
+ MX6Q_PAD_NANDF_D3__GPIO_2_3 | MUX_PAD_CTRL(BUTTON_PAD_CTRL),
+ /* Home */
+ MX6Q_PAD_NANDF_D4__GPIO_2_4 | MUX_PAD_CTRL(BUTTON_PAD_CTRL),
+ /* Volume Down */
+ MX6Q_PAD_GPIO_19__GPIO_4_5 | MUX_PAD_CTRL(BUTTON_PAD_CTRL),
+ /* Volume Up */
+ MX6Q_PAD_GPIO_18__GPIO_7_13 | MUX_PAD_CTRL(BUTTON_PAD_CTRL),
+};
+
static void setup_iomux_enet(void)
{
gpio_direction_output(87, 0); /* GPIO 3-23 */
@@ -295,11 +315,18 @@ int setup_sata(void)
}
#endif
+static void setup_buttons(void)
+{
+ imx_iomux_v3_setup_multiple_pads(button_pads,
+ARRAY_SIZE(button_pads));
+}
+
int board_early_init_f(void)
{
- setup_iomux_uart();
+ setup_iomux_uart();
+ setup_buttons();
- return 0;
+ return 0;
}
int board_init(void)
@@ -324,3 +351,94 @@ int checkboard(void)
return 0;
}
+
+struct button_key {
+ char const *name;
+ unsignedgpnum;
+ charident;
+};
+
+static struct button_key const buttons[] = {
+ {"back",GPIO_NUMBER(2, 2), 'B'},
+ {"home",GPIO_NUMBER(2, 4), 'H'},
+ {"menu",GPIO_NUMBER(2, 1), 'M'},
+ {"search", GPIO_NUMBER(2, 3), 'S'},
+ {"volup", GPIO_NUMBER(7, 13), 'V'},
+ {"voldown", GPIO_NUMBER(4, 5), 'v'},
+};
+
+/*
+ * generate a null-terminated string containing the buttons pressed
+ * returns number of keys pressed
+ */
+static int read_keys(char *buf)
+{
+ int i, numpressed = 0;
+ for (i = 0; i < ARRAY_SIZE(buttons); i++) {
+ if (!gpio_get_value(buttons[i].gpnum))
+ buf[numpressed++] = buttons[i].ident;
+ }
+ buf[numpressed] = '\0';
+ return numpressed;
+}
+
+static int do_kbd(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+ char envvalue[ARRAY_SIZE(buttons)+1];
+ int numpressed = read_keys(envvalue);
+ setenv("keybd", envvalue);
+ return numpressed == 0;
+}
+
+U_BOOT_CMD(
+ kbd, 1, 1, do_kbd,
+ "Tests for keypresses, sets 'keybd' environment variable",
+ "Returns 0 (true) to shell if key is pressed."
+);
+
+#ifdef CONFIG_PREBOOT
+static char const kbd_magic_prefix[] = "key_magic";
+static char const kbd_command_prefix[] = "key_cmd";
+
+static void preboot_keys(void)
+{
+ int numpressed;
+ char keypress[ARRAY_SIZE(buttons)+1];
+ numpressed = read_keys(keypress);
+ if (numpressed) {
+ char *kbd_magic_keys = getenv("magic_keys");
+ char *suffix;
+ /*
+* loop over all magic keys
+*/
+ for (suffix = kbd_magic_keys; *suffix; ++suffix) {
+ char *keys;
+ char magic[sizeof(kbd_magic_prefix) + 1];
+ sprintf(magic, "%s%c", kbd_magic_prefix, *suffix);
+ keys = getenv(magic);
+ if (keys) {
+ if (!strcmp(keys, keypress))
+ break;
+ }
+ }
+ if (*suffix) {
+ char cmd_name[sizeof(kbd_command_prefix) + 1];
+ char *cmd;
+ sprintf(cmd_name, "%s%c", kbd_command_prefix, *suffix);
+ cmd = getenv(cmd_name);
+
Re: [U-Boot] Using sata on mx6qsabrelite
Hi Eric, On Wed, Apr 25, 2012 at 8:55 PM, Eric Nelson wrote: > I just re-based and re-sent two of the three patches needed to get > SATA up and running against mainline/master. That's good news! Thanks a lot! I think Pete can give a try on SATA with mainline U-boot now. Thanks, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] i.MX6Q: mx6qsabrelite: Add keypress support to alter boot flow
Dear Eric Nelson,
> Uses the 'magic_keys' idiom as described in doc/README.kbd:
> http://lists.denx.de/pipermail/u-boot/2012-April/122502.html
If this is a V2 of a patch, please send is as "in-reply-to" and descibe the
changes below (at spot marked V2 (and V3 etc))... Also, change the keywork
"PATCH" in teh subject to teh "PATCH V2" etc ;-)
>
> Signed-off-by: Eric Nelson
> Acked-by: Marek Vasut
> ---
V2:
This is just a nitpick though (and I got about similar scolding in the LAKML
today, so don't let it bother you ;-) ), thanks for your work ;-)
> board/freescale/mx6qsabrelite/mx6qsabrelite.c | 122
> - include/configs/mx6qsabrelite.h |
> 3 +
> 2 files changed, 123 insertions(+), 2 deletions(-)
>
> diff --git a/board/freescale/mx6qsabrelite/mx6qsabrelite.c
> b/board/freescale/mx6qsabrelite/mx6qsabrelite.c index db5e775..f63cef7
> 100644
> --- a/board/freescale/mx6qsabrelite/mx6qsabrelite.c
> +++ b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
> @@ -52,6 +52,10 @@ DECLARE_GLOBAL_DATA_PTR;
> PAD_CTL_PUS_100K_DOWN | PAD_CTL_SPEED_MED | \
> PAD_CTL_DSE_40ohm | PAD_CTL_SRE_FAST)
>
> +#define BUTTON_PAD_CTRL (PAD_CTL_PKE | PAD_CTL_PUE | \
> + PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED | \
> + PAD_CTL_DSE_40ohm | PAD_CTL_HYS)
> +
> int dram_init(void)
> {
> gd->ram_size = get_ram_size((void *)PHYS_SDRAM, PHYS_SDRAM_SIZE);
> @@ -124,6 +128,22 @@ iomux_v3_cfg_t enet_pads2[] = {
> MX6Q_PAD_RGMII_RX_CTL__RGMII_RX_CTL | MUX_PAD_CTRL(ENET_PAD_CTRL),
> };
>
> +/* Button assignments for J14 */
> +static iomux_v3_cfg_t button_pads[] = {
> + /* Menu */
> + MX6Q_PAD_NANDF_D1__GPIO_2_1 | MUX_PAD_CTRL(BUTTON_PAD_CTRL),
> + /* Back */
> + MX6Q_PAD_NANDF_D2__GPIO_2_2 | MUX_PAD_CTRL(BUTTON_PAD_CTRL),
> + /* Labelled Search (mapped to Power under Android) */
> + MX6Q_PAD_NANDF_D3__GPIO_2_3 | MUX_PAD_CTRL(BUTTON_PAD_CTRL),
> + /* Home */
> + MX6Q_PAD_NANDF_D4__GPIO_2_4 | MUX_PAD_CTRL(BUTTON_PAD_CTRL),
> + /* Volume Down */
> + MX6Q_PAD_GPIO_19__GPIO_4_5 | MUX_PAD_CTRL(BUTTON_PAD_CTRL),
> + /* Volume Up */
> + MX6Q_PAD_GPIO_18__GPIO_7_13 | MUX_PAD_CTRL(BUTTON_PAD_CTRL),
> +};
> +
> static void setup_iomux_enet(void)
> {
> gpio_direction_output(87, 0); /* GPIO 3-23 */
> @@ -295,11 +315,18 @@ int setup_sata(void)
> }
> #endif
>
> +static void setup_buttons(void)
> +{
> + imx_iomux_v3_setup_multiple_pads(button_pads,
> + ARRAY_SIZE(button_pads));
> +}
> +
> int board_early_init_f(void)
> {
> - setup_iomux_uart();
> + setup_iomux_uart();
> + setup_buttons();
>
> - return 0;
> + return 0;
> }
>
> int board_init(void)
> @@ -324,3 +351,94 @@ int checkboard(void)
>
> return 0;
> }
> +
> +struct button_key {
> + char const *name;
> + unsignedgpnum;
> + charident;
> +};
> +
> +static struct button_key const buttons[] = {
> + {"back",GPIO_NUMBER(2, 2), 'B'},
> + {"home",GPIO_NUMBER(2, 4), 'H'},
> + {"menu",GPIO_NUMBER(2, 1), 'M'},
> + {"search", GPIO_NUMBER(2, 3), 'S'},
> + {"volup", GPIO_NUMBER(7, 13), 'V'},
> + {"voldown", GPIO_NUMBER(4, 5), 'v'},
> +};
> +
> +/*
> + * generate a null-terminated string containing the buttons pressed
> + * returns number of keys pressed
> + */
> +static int read_keys(char *buf)
> +{
> + int i, numpressed = 0;
> + for (i = 0; i < ARRAY_SIZE(buttons); i++) {
> + if (!gpio_get_value(buttons[i].gpnum))
> + buf[numpressed++] = buttons[i].ident;
> + }
> + buf[numpressed] = '\0';
> + return numpressed;
> +}
> +
> +static int do_kbd(cmd_tbl_t *cmdtp, int flag, int argc, char * const
> argv[]) +{
> + char envvalue[ARRAY_SIZE(buttons)+1];
> + int numpressed = read_keys(envvalue);
> + setenv("keybd", envvalue);
> + return numpressed == 0;
> +}
> +
> +U_BOOT_CMD(
> + kbd, 1, 1, do_kbd,
> + "Tests for keypresses, sets 'keybd' environment variable",
> + "Returns 0 (true) to shell if key is pressed."
> +);
> +
> +#ifdef CONFIG_PREBOOT
> +static char const kbd_magic_prefix[] = "key_magic";
> +static char const kbd_command_prefix[] = "key_cmd";
> +
> +static void preboot_keys(void)
> +{
> + int numpressed;
> + char keypress[ARRAY_SIZE(buttons)+1];
> + numpressed = read_keys(keypress);
> + if (numpressed) {
> + char *kbd_magic_keys = getenv("magic_keys");
> + char *suffix;
> + /*
> + * loop over all magic keys
> + */
> + for (suffix = kbd_magic_keys; *suffix; ++suffix) {
> + char *keys;
> + char magic[sizeof(kbd_magic_prefix) + 1];
> + sprintf(magic, "%s%c", kbd_magic_pr
[U-Boot] [PATCH V2] i.MX: fsl_esdhc: allow use with cache enabled.
Signed-off-by: Eric Nelson
---
V2 fixes checkpatch errors and typecasts as pointed out on the ML.
drivers/mmc/fsl_esdhc.c | 17 -
1 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index a2f35e3..539d848 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -190,6 +190,10 @@ static int esdhc_setup_data(struct mmc *mmc, struct
mmc_data *data)
esdhc_clrsetbits32(®s->wml, WML_RD_WML_MASK, wml_value);
esdhc_write32(®s->dsaddr, (u32)data->dest);
} else {
+ flush_dcache_range((ulong)data->src,
+ (ulong)data->src+data->blocks
+*data->blocksize);
+
if (wml_value > WML_WR_WML_MAX)
wml_value = WML_WR_WML_MAX_VAL;
if ((esdhc_read32(®s->prsstat) & PRSSTAT_WPSPL) == 0) {
@@ -249,7 +253,15 @@ static int esdhc_setup_data(struct mmc *mmc, struct
mmc_data *data)
return 0;
}
-
+static void check_and_invalidate_dcache_range
+ (struct mmc_cmd *cmd,
+struct mmc_data *data) {
+ unsigned start = (unsigned)data->dest ;
+ unsigned size = roundup(ARCH_DMA_MINALIGN,
+ data->blocks*data->blocksize);
+ unsigned end = start+size ;
+ invalidate_dcache_range(start, end);
+}
/*
* Sends a command out on the bus. Takes the mmc pointer,
* a command pointer, and an optional data pointer.
@@ -311,6 +323,9 @@ esdhc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd, struct
mmc_data *data)
while (!(esdhc_read32(®s->irqstat) & IRQSTAT_CC))
;
+ if (data && (data->flags & MMC_DATA_READ))
+ check_and_invalidate_dcache_range(cmd, data);
+
irqstat = esdhc_read32(®s->irqstat);
esdhc_write32(®s->irqstat, irqstat);
--
1.7.9
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] i.MX6Q: mx6qsabrelite: Add keypress support to alter boot flow
On 04/25/2012 05:17 PM, Marek Vasut wrote: Dear Eric Nelson, Uses the 'magic_keys' idiom as described in doc/README.kbd: http://lists.denx.de/pipermail/u-boot/2012-April/122502.html If this is a V2 of a patch, please send is as "in-reply-to" and descibe the changes below (at spot marked V2 (and V3 etc))... Also, change the keywork "PATCH" in teh subject to teh "PATCH V2" etc ;-) Signed-off-by: Eric Nelson Acked-by: Marek Vasut --- V2: This is just a nitpick though (and I got about similar scolding in the LAKML today, so don't let it bother you ;-) ), thanks for your work ;-) Thanks Marek. I coulda sworn I did that, but apparently not... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ext2load: increase read speed
On 03/28/2012 07:37 AM, Jason Cooper wrote: This patch dramatically drops the amount of time u-boot needs to read a file from an ext2 partition. On a typical 2 to 5 MB file (kernels and initrds) it goes from tens of seconds to a couple seconds. All we are doing here is grouping contiguous blocks into one read. Boot tested on Globalscale Technologies Dreamplug (Kirkwood ARM SoC) with three different files. sha1sums were calculated in Linux userspace, and then confirmed after ext2load. Signed-off-by: Jason Cooper Tested-by: Eric Nelson Tested on i.MX6 Sabre Lite board loading a file of ~900k: Without patch: MX6QSABRELITE U-Boot > time ext2load sata 0:1 1200 /usr/lib/libperl.so.5.12.4 && crc32 1200 $filesize Loading file "/usr/lib/libperl.so.5.12.4" from sata device 0:1 (hda1) 958032 bytes read time: 0.414 seconds, 414 ticks CRC32 for 1200 ... 120e9e4f ==> 550deec9 With patch: MX6QSABRELITE U-Boot > time ext2load sata 0:1 1200 /usr/lib/libperl.so.5.12.4 && crc32 1200 $filesize Loading file "/usr/lib/libperl.so.5.12.4" from sata device 0:1 (hda1) 958032 bytes read time: 0.205 seconds, 205 ticks CRC32 for 1200 ... 120e9e4f ==> 550deec9 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] A problem about using the nand command
Hello, everyone! I find a strange problem when I use the u-boot command. I list the command I used in the u-boot command line as follows. nand erase nand read 0x200 0x0 0x800 md 0x200 I should see 2K bytes of "0xFF" because I have erase the whole nand flash device. Actually, I find a "0xFD" in one address. Then I try display some other contend of the nand flash. I can also find one "0xFD" in every 2K address space. It is so strange. By the way, I find that the offsets of the addresses of the one "0xFD" from the start of the page are the same. The size of one flash page is 2K bytes. Are the driver of the nand flash in the u-boot wrong? Or are there some other problems? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4][v3] powerpc/85xx:Make debug exception vector accessible
Hi Scott, On Wednesday 25 April 2012 08:20 PM, Scott Wood wrote: On 04/24/2012 11:05 PM, Andy Fleming wrote: On Tue, Apr 24, 2012 at 10:48 PM, Prabhakar Kushwaha wrote: Hi, On Wednesday 25 April 2012 02:50 AM, Andy Fleming wrote: On Tue, Apr 24, 2012 at 4:10 PM, Scott Wood wrote: On 04/24/2012 03:45 PM, Andy Fleming wrote: On Mon, Mar 26, 2012 at 4:00 AM, Prabhakar Kushwaha @@ -107,6 +107,7 @@ #define CONFIG_MAX_CPUS1 #define CONFIG_FSL_SDHC_V2_3 #define CONFIG_SYS_FSL_NUM_LAWS12 +#define CONFIG_SYS_PPC_E500_DEBUG_TLB 3 You've only enabled this for one processor. Maybe the P1010. Nowhere in the patch description does it mention that this is only being enabled for one chip. As it is, I think you meant to enable it for more chips, and I'm wondering why it's not enabled for the other chips mentioned in the comments above as being test platforms for this patch... Probably, for this feature, we should make a default definition, which can be overridden by other parts if necessary. In other words, add something like this near the end: #ifndef CONFIG_SYS_PPC_E500_DEBUG_TLB #define CONFIG_SYS_PPC_E500_DEBUG_TLB 3 #endif We don't want to enable this on e500mc (testing in that context just means that we didn't break the code path where this isn't enabled). I'm not sure whether it will break anything if we do enable it on e500mc, but we don't need it. Ok, but we still either need this to be enabled for all e500/e500v2. OR split off this config option into a separate patch where it's mentioned that this is only being enabled on the P1010. Actually, it should probably be added to this area that deals in core-specific config options: I agree. I will split the debugger patch and P1010 debug enable. A separate patch will be send for P1010 SoC. For other e500v2 processor based SoC,as i am not sure about their verification. It will be send as and when verified. That should be fine. Enabling it on individual SoCs based on verification conflicts with putting this in the core-specific config area. Just test with a reasonable sample of SoCs, grep for TLB assignments to look for any conflicts, and then enable it in the generic e500v2 area that Andy pointed out. I believe , let this patch-set be applied in upstream. then during enabling debugging support of BSC9131 , i will enable for other SoC like P1020, P2020 etc. Regards, Prabhakar ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [SOT] linker scripts
All,
I know this is a little off topic, but u-boot is the only project I've
found implementing a feature I'd like to add to a project.
Specifically, the macro U_BOOT_CMD() and it's use of
section(".u_boot_cmd").
I'd like to implement something similar in a userspace C program, but I
can't get it to work. A lot of my searches on the net for my various
errors leads me to believe I should let gcc do the linking and not mess
with ld.
I've gotten to the point where it compiles cleanly, but then I get 'No
such file or directory" from bash when trying to run the resulting
executable. (Using ld)
Is there a succinct way to use the modified output of 'ld -v' from gcc
so that I can place the array of structs between _blah_start and
_blah_end?
I've tried 'gcc -Wl,-T,mylink.lds -Wl,-u_blah_thisone ...' and that
compiles fine, and runs, but there is no struct found when I iterate
from _blah_start to _blah_end. The output of 'strings a.out | grep
_blah' gives only _blah_end. I'm a bit out of my depth here. Any help
appreciated.
thx,
Jason.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Can anyone help me to solve the stack problem of U-boot? Urgent~
Hi Civic Wu, > Please see the README (section "U-Boot Porting Guide", but also > section "System Initialization"), and read doc/README.SPL and > http://catb.org/esr/faqs/smart-questions.html > > If this is urgent, and you spent many days on this, then the best > advice for you is to hire an expert. > > Best regards, > > Wolfgang Denk http://www.youtube.com/watch?v=XaetQBZB_E4 Hope this introduction "U-boot Porting Guide for NDS32 based SoC" may help you. The stack setup of NDS32 is similar as ARM. Please also read the document at first. :) -- Best regards, Macpaul Lin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] imx-common: Factor out get_ahb_clk()
Hi Fabio,
On 20.03.2012 22:40, Fabio Estevam wrote:
get_ahb_clk() is a common function between mx5 and mx6.
Place it into imx-common directory.
Signed-off-by: Fabio Estevam
---
arch/arm/cpu/armv7/imx-common/cpu.c| 23
arch/arm/cpu/armv7/mx5/clock.c | 17 +-
arch/arm/cpu/armv7/mx6/clock.c | 17 ++
arch/arm/include/asm/arch-mx5/sys_proto.h |1 +
.../asm/arch-mx6/{ccm_regs.h => crm_regs.h}|2 +-
arch/arm/include/asm/arch-mx6/sys_proto.h |1 +
6 files changed, 30 insertions(+), 31 deletions(-)
rename arch/arm/include/asm/arch-mx6/{ccm_regs.h => crm_regs.h} (99%)
We had this patch on a v2012.04.1 based test branch and it showed some
strange issues with SD cards on i.MX6.
Depending on the SD card used (different ones) and the board (SabreLite
and a custom one)
- the SD card just works fine as we are used to
- booting fails with "MMC init failed"
- booting fails with "Card did not respond to voltage select!"
Reverting this patch on the test branch makes all tested boards and
tested SD cards work fine again.
I haven't looked into the details to debug the root cause, though.
So for the moment: NACK
Best regards
Dirk
diff --git a/arch/arm/cpu/armv7/imx-common/cpu.c
b/arch/arm/cpu/armv7/imx-common/cpu.c
index 6d7486b..62b01e7 100644
--- a/arch/arm/cpu/armv7/imx-common/cpu.c
+++ b/arch/arm/cpu/armv7/imx-common/cpu.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_FSL_ESDHC
#include
@@ -107,3 +108,25 @@ void reset_cpu(ulong addr)
{
__raw_writew(4, WDOG1_BASE_ADDR);
}
+
+static u32 __get_periph_clk(void)
+{
+ return 0; /* clock.c will override it */
+}
+
+u32 get_periph_clk(void)
+ __attribute__((weak, alias("__get_periph_clk")));
+
+u32 get_ahb_clk(void)
+{
+ struct mxc_ccm_reg *imx_ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
+ u32 reg, ahb_podf;
+
+ reg = __raw_readl(&imx_ccm->cbcdr);
+ reg &= MXC_CCM_CBCDR_AHB_PODF_MASK;
+ ahb_podf = reg >> MXC_CCM_CBCDR_AHB_PODF_OFFSET;
+
+ return get_periph_clk() / (ahb_podf + 1);
+
+ return 0;
+}
diff --git a/arch/arm/cpu/armv7/mx5/clock.c b/arch/arm/cpu/armv7/mx5/clock.c
index e92f106..a1c8411 100644
--- a/arch/arm/cpu/armv7/mx5/clock.c
+++ b/arch/arm/cpu/armv7/mx5/clock.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
enum pll_clocks {
PLL1_CLOCK = 0,
@@ -213,22 +214,6 @@ static u32 get_periph_clk(void)
}
/*
- * Get the rate of ahb clock.
- */
-static u32 get_ahb_clk(void)
-{
- uint32_t freq, div, reg;
-
- freq = get_periph_clk();
-
- reg = __raw_readl(&mxc_ccm->cbcdr);
- div = ((reg & MXC_CCM_CBCDR_AHB_PODF_MASK) >>
- MXC_CCM_CBCDR_AHB_PODF_OFFSET) + 1;
-
- return freq / div;
-}
-
-/*
* Get the rate of ipg clock.
*/
static u32 get_ipg_clk(void)
diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c
index ef98563..5d42051 100644
--- a/arch/arm/cpu/armv7/mx6/clock.c
+++ b/arch/arm/cpu/armv7/mx6/clock.c
@@ -24,8 +24,9 @@
#include
#include
#include
-#include
+#include
#include
+#include
enum pll_clocks {
PLL_SYS,/* System PLL */
@@ -34,7 +35,7 @@ enum pll_clocks {
PLL_ENET, /* ENET PLL */
};
-struct imx_ccm_reg *imx_ccm = (struct imx_ccm_reg *)CCM_BASE_ADDR;
+struct mxc_ccm_reg *imx_ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
void enable_usboh3_clk(unsigned char enable)
{
@@ -139,18 +140,6 @@ static u32 get_periph_clk(void)
return freq;
}
-
-static u32 get_ahb_clk(void)
-{
- u32 reg, ahb_podf;
-
- reg = __raw_readl(&imx_ccm->cbcdr);
- reg &= MXC_CCM_CBCDR_AHB_PODF_MASK;
- ahb_podf = reg >> MXC_CCM_CBCDR_AHB_PODF_OFFSET;
-
- return get_periph_clk() / (ahb_podf + 1);
-}
-
static u32 get_ipg_clk(void)
{
u32 reg, ipg_podf;
diff --git a/arch/arm/include/asm/arch-mx5/sys_proto.h
b/arch/arm/include/asm/arch-mx5/sys_proto.h
index 13d12ee..7250059 100644
--- a/arch/arm/include/asm/arch-mx5/sys_proto.h
+++ b/arch/arm/include/asm/arch-mx5/sys_proto.h
@@ -35,5 +35,6 @@ void set_chipselect_size(int const);
*/
int fecmxc_initialize(bd_t *bis);
+u32 get_ahb_clk(void);
#endif
diff --git a/arch/arm/include/asm/arch-mx6/ccm_regs.h
b/arch/arm/include/asm/arch-mx6/crm_regs.h
similarity index 99%
rename from arch/arm/include/asm/arch-mx6/ccm_regs.h
rename to arch/arm/include/asm/arch-mx6/crm_regs.h
index 4af0b90..0e605c2 100644
--- a/arch/arm/include/asm/arch-mx6/ccm_regs.h
+++ b/arch/arm/include/asm/arch-mx6/crm_regs.h
@@ -20,7 +20,7 @@
#ifndef __ARCH_ARM_MACH_MX6_CCM_REGS_H__
#define __ARCH_ARM_MACH_MX6_CCM_REGS_H__
-struct imx_ccm_reg {
+struct mxc_ccm_reg {
u32 ccr;/* 0x */
u32 ccdr;
u32 csr;
diff --git a/arch/arm/include/asm/arch-mx6/sys_proto.h
b/arch/arm/include
Re: [U-Boot] [PATCH 2/2] mmc: tegra: invalidate complete cachelines
* Mike Frysinger wrote: > On Tuesday 24 April 2012 03:53:44 Thierry Reding wrote: > > The MMC core sometimes reads buffers that are smaller than a complete > > cacheline, for example when reading the SCR. In order to avoid a warning > > from the ARM v7 cache handling code, this patch makes sure that complete > > cachelines are flushed. > > this is still wrong. all you've done is bypass the error message without > addressing the underlying problem -- you're invalidating too much. Reading 8 bytes is always less than a cacheline, so we don't have much choice, do we? We could of course always read a whole cacheline even if only 8 bytes are requested, but does that have any advantage over reading 8 bytes and then invalidating the cacheline? Or maybe I'm missing the point. Thierry pgpv2cWITeleM.pgp Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] PowerPC: Change -fpic flag to -fPIC flag in the config.mk
Scott Wood wrote on 2012/04/25 21:01:00:
>
> On 04/18/2012 05:07 AM, Joakim Tjernlund wrote:
> > Your linker file is buggy I think. I found u-boot-nand_spl.lds, is that the
> > one?
>
> That's the one for the SPL part.
OK, good.
>
> > Check out that files reloc part:
> > .reloc : {
> > _GOT2_TABLE_ = .;
> > KEEP(*(.got2))
> > _FIXUP_TABLE_ = .;
> > KEEP(*(.fixup))
> >}
> >__got2_entries = (_FIXUP_TABLE_ - _GOT2_TABLE_) >> 2;
> >__fixup_entries = (. - _FIXUP_TABLE_) >> 2;
> >
> > Compare that with(from u-boot.lds):
> > .reloc :
> > {
> > _GOT2_TABLE_ = .;
> > KEEP(*(.got2))
> > KEEP(*(.got))
> > PROVIDE(_GLOBAL_OFFSET_TABLE_ = . + 4);
> > _FIXUP_TABLE_ = .;
> > KEEP(*(.fixup))
> > }
> > __got2_entries = ((_GLOBAL_OFFSET_TABLE_ - _GOT2_TABLE_) >> 2) - 1;
> > __fixup_entries = (. - _FIXUP_TABLE_) >> 2;
>
> I notice a difference between u-boot.lds and u-boot-nand.lds -- the
> latter (used for the main part of U-Boot when loaded from SPL) has:
>
> > .reloc :
> > {
> > KEEP(*(.got))
> > _GOT2_TABLE_ = .;
> > KEEP(*(.got2))
> > _FIXUP_TABLE_ = .;
> > KEEP(*(.fixup))
> > }
> > __got2_entries = (_FIXUP_TABLE_ - _GOT2_TABLE_) >> 2;
> > __fixup_entries = (. - _FIXUP_TABLE_) >> 2;
>
> Is this wrong as well?
Yes, I think so. This one does not care about the .got entries at all so I
suspect
never gcc's wont work.
Jocke
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
