[U-Boot] [PATCH] driver/mtd/ifc: Read Status while programming NAND flash
as per controller description,
While programming a NAND flash, status read should never skipped.
Because it may happen that a new command is issued to the NAND Flash,
even when the device has not yet finished processing the previous request.
This may result in unpredictable behaviour.
IFC controller never polls for R/B signal after command send. It just return
control to software. This behaviour may not occur with NAND flash access.
because new commands are sent after polling R/B signal. But it may happen
in scenario where GPCM-ASIC and NAND flash device are working simultaneously.
Update the controller driver to take care of this requirement
Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
---
drivers/mtd/nand/fsl_ifc_nand.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/nand/fsl_ifc_nand.c b/drivers/mtd/nand/fsl_ifc_nand.c
index cfed549..49b63af 100644
--- a/drivers/mtd/nand/fsl_ifc_nand.c
+++ b/drivers/mtd/nand/fsl_ifc_nand.c
@@ -491,20 +491,27 @@ static void fsl_ifc_cmdfunc(struct mtd_info *mtd,
unsigned int command,
if (mtd-writesize 512) {
nand_fcr0 =
(NAND_CMD_SEQIN IFC_NAND_FCR0_CMD0_SHIFT) |
- (NAND_CMD_PAGEPROG IFC_NAND_FCR0_CMD1_SHIFT);
+ (NAND_CMD_STATUS IFC_NAND_FCR0_CMD1_SHIFT) |
+ (NAND_CMD_PAGEPROG IFC_NAND_FCR0_CMD2_SHIFT);
out_be32(ifc-ifc_nand.nand_fir0,
(IFC_FIR_OP_CW0 IFC_NAND_FIR0_OP0_SHIFT) |
(IFC_FIR_OP_CA0 IFC_NAND_FIR0_OP1_SHIFT) |
(IFC_FIR_OP_RA0 IFC_NAND_FIR0_OP2_SHIFT) |
(IFC_FIR_OP_WBCD IFC_NAND_FIR0_OP3_SHIFT) |
-(IFC_FIR_OP_CW1 IFC_NAND_FIR0_OP4_SHIFT));
- out_be32(ifc-ifc_nand.nand_fir1, 0);
+(IFC_FIR_OP_CMD2 IFC_NAND_FIR0_OP4_SHIFT));
+ out_be32(ifc-ifc_nand.nand_fir1,
+(IFC_FIR_OP_CW1 IFC_NAND_FIR1_OP5_SHIFT) |
+(IFC_FIR_OP_RDSTAT
+ IFC_NAND_FIR1_OP6_SHIFT) |
+(IFC_FIR_OP_NOP IFC_NAND_FIR1_OP7_SHIFT));
} else {
nand_fcr0 = ((NAND_CMD_PAGEPROG
IFC_NAND_FCR0_CMD1_SHIFT) |
(NAND_CMD_SEQIN
- IFC_NAND_FCR0_CMD2_SHIFT));
+ IFC_NAND_FCR0_CMD2_SHIFT) |
+ (NAND_CMD_STATUS
+ IFC_NAND_FCR0_CMD3_SHIFT));
out_be32(ifc-ifc_nand.nand_fir0,
(IFC_FIR_OP_CW0 IFC_NAND_FIR0_OP0_SHIFT) |
@@ -513,7 +520,11 @@ static void fsl_ifc_cmdfunc(struct mtd_info *mtd, unsigned
int command,
(IFC_FIR_OP_RA0 IFC_NAND_FIR0_OP3_SHIFT) |
(IFC_FIR_OP_WBCD IFC_NAND_FIR0_OP4_SHIFT));
out_be32(ifc-ifc_nand.nand_fir1,
-(IFC_FIR_OP_CW1 IFC_NAND_FIR1_OP5_SHIFT));
+(IFC_FIR_OP_CMD1 IFC_NAND_FIR1_OP5_SHIFT) |
+(IFC_FIR_OP_CW3 IFC_NAND_FIR1_OP6_SHIFT) |
+(IFC_FIR_OP_RDSTAT
+ IFC_NAND_FIR1_OP7_SHIFT) |
+(IFC_FIR_OP_NOP IFC_NAND_FIR1_OP8_SHIFT));
if (column = mtd-writesize)
nand_fcr0 |=
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 7/8] ARM: extend non-secure switch to also go into HYP mode
Hi Andre, On Thu, 19 Sep 2013 18:06:45 +0200, Andre Przywara andre.przyw...@linaro.org wrote: For the KVM and XEN hypervisors to be usable, we need to enter the kernel in HYP mode. Now that we already are in non-secure state, HYP mode switching is within short reach. While doing the non-secure switch, we have to enable the HVC instruction and setup the HYP mode HVBAR (while still secure). The actual switch is done by dropping back from a HYP mode handler without actually leaving HYP mode, so we introduce a new handler routine in our new secure exception vector table. In the assembly switching routine we save and restore the banked LR and SP registers around the hypercall to do the actual HYP mode switch. The C routine first checks whether we are in HYP mode already and also whether the virtualization extensions are available. It also checks whether the HYP mode switch was finally successful. The bootm command part only calls the new function after the non-secure switch. Signed-off-by: Andre Przywara andre.przyw...@linaro.org --- arch/arm/cpu/armv7/Makefile | 2 +- arch/arm/cpu/armv7/nonsec_virt.S | 43 +++- arch/arm/cpu/armv7/virt-v7.c | 37 ++ arch/arm/include/asm/armv7.h | 6 -- arch/arm/lib/bootm.c | 7 ++- 5 files changed, 86 insertions(+), 9 deletions(-) Changes: v3..v4: w/s fixes, embed error output v4..v5: none Seems like Christoffer's comment was not addressed here but IIUC, it was in other files (Christoffer, feel free to comment). Any reason why the older asm comments form was not replaced in here? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 2/8] ARM: add secure monitor handler to switch to non-secure state
Hi Andre, On Thu, 19 Sep 2013 18:06:40 +0200, Andre Przywara andre.przyw...@linaro.org wrote: A prerequisite for using virtualization is to be in HYP mode, which requires the CPU to be in non-secure state first. Add a new file in arch/arm/cpu/armv7 to hold a monitor handler routine which switches the CPU to non-secure state by setting the NS and associated bits. According to the ARM architecture reference manual this should not be done in SVC mode, so we have to setup a SMC handler for this. We create a new vector table to avoid interference with other boards. The MVBAR register will be programmed later just before the smc call. Signed-off-by: Andre Przywara andre.przyw...@linaro.org --- arch/arm/cpu/armv7/Makefile | 4 +++ arch/arm/cpu/armv7/nonsec_virt.S | 54 2 files changed, 58 insertions(+) create mode 100644 arch/arm/cpu/armv7/nonsec_virt.S BTW, this has an empty line at EOF warning when applying. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] zynq: Use arch_cpu_init() instead of lowlevel_init()
On 10/02/2013 09:43 PM, Albert ARIBAUD wrote:
Hi Michal,
On Tue, 24 Sep 2013 12:38:38 +0200, Michal Simek mon...@monstr.eu
wrote:
Hi Albert,
On 09/23/2013 04:37 PM, Albert ARIBAUD wrote:
Hi Michal,
On Mon, 23 Sep 2013 16:19:52 +0200, Michal Simek mon...@monstr.eu
wrote:
On 09/23/2013 02:31 PM, Albert ARIBAUD wrote:
Hi Michal,
On Thu, 22 Aug 2013 14:52:02 +0200, Michal Simek
michal.si...@xilinx.com wrote:
Zynq lowlevel_init() was implemented in C but stack
pointer is setup after function call in _main().
Move architecture setup to arch_cpu_init() which is call
as the first function in board_init_f() which
already have correct stack pointer.
Reported-by: Sven Schwermer sven.schwer...@tuhh.de
Signed-off-by: Michal Simek michal.si...@xilinx.com
---
I can't see any problem to call zynq setup a little
bit later. There is already expectation that u-boot
runs from DDR.
Moving lowlevel_init from C to ASM is possible but
I will have to introduce new macros with hardcoded
values. Using structures is much nicer.
---
arch/arm/cpu/armv7/zynq/cpu.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/cpu/armv7/zynq/cpu.c
b/arch/arm/cpu/armv7/zynq/cpu.c
index 4367d1a..8846f30 100644
--- a/arch/arm/cpu/armv7/zynq/cpu.c
+++ b/arch/arm/cpu/armv7/zynq/cpu.c
@@ -11,6 +11,10 @@
void lowlevel_init(void)
{
+}
I'd rather you deleted lowlevel_init() as a C function with this
name should not exist.
Ok. Do you want me to create almost empty low_level.S or just use
arch/arm/cpu/arvm7/lowlevel_init.S and define empty s_init()?
Urgh. I realize removing the C function would give you more work than
simply keeping it empty until the whole s_init() mess is cleaned up. :(
I'll take your change as-is, sorry for the noise.
In connection to this topic we have recently found one issue
regarding to neon instruction which u-boot uses.
We have this code to enable them in asm and adding this to lowlevel_init.S
is straight way how to do so.
mov r0, r0
mrc p15, 0, r1, c1, c0, 2
orr r1, r1, #(0xf 20)
mcr p15, 0, r1, c1, c0, 2
fmrxr1, FPEXC
orr r1,r1, #(130)
fmxrFPEXC, r1
Is it ok to create zynq asm specific lowlevel function
or doing this through s_init() or you have nice a clean way how
this should be solved when you are saying that s_init() is mess.
Sorry for responding slowly.
I suspect when you say neon instruction that U-Boot uses, you mean neon
instructions that GCC is allowed to emit while building U-Boot, right?
yes.
So we're talking about neon insns in C code only, not asm, correct?
yes. gcc emits neon instruction in timer code. Not in asm.
If this is correct, then does something prevent you from enabling
neon instructions as early as possible, in e.g. the lowlevel_init
routine?
ok let me clear this. I think location of this code is clear.
It is asm code and it will be called ASAP even
we know exactly which code emits neon instructions.
My point was if we should create specific lowlevel_init asm function
and add this code there.
Or use arch/arm/cpu/armv7/lowlevel_init.S and create just s_init function.
You mentioned above that s_init() is a mess and needs to be clean up
but you didn't mentioned how.
It means my point is if you tell us how should be clean up we can
just submit code which is compatible with this cleanup activity.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP - KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
signature.asc
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Dual boot Images in Flash
Hi Wolfgang Denk, Thanks for the feedback, for the customization of u-boot_stub, the main file start.S needs to be changed i guess, the u-boot_stub has to perform only CRC check. after performing it should goto u_boot1/u_boot2 address and then it should start booting. How can i customize the u-boot_stub or generate the start.S file which perform only CRC calculation and switching address of u_boot1/u_boot2 , which performs booting. Thanks Regards Pradeep S -- View this message in context: http://u-boot.10912.n7.nabble.com/Dual-boot-Images-in-Flash-tp164381p164588.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/6] power: Explicitly select pmic device's bus
Hello Lukasz,
Thanks for reviewing the patch.
On Wed, Oct 2, 2013 at 8:41 PM, Lukasz Majewski l.majew...@samsung.com wrote:
Hi Leela,
The current pmic i2c code assumes the current i2c bus is
the same as the pmic device's bus. There is nothing ensuring
that to be true. Therefore, select the proper bus before performing
a transaction.
Signed-off-by: Aaron Durbin adur...@chromium.org
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
Reviewed-by: Doug Anderson diand...@google.com
---
drivers/power/power_i2c.c | 62
+ 1 file changed, 57
insertions(+), 5 deletions(-)
diff --git a/drivers/power/power_i2c.c b/drivers/power/power_i2c.c
index 47c606f..c22e01f 100644
--- a/drivers/power/power_i2c.c
+++ b/drivers/power/power_i2c.c
@@ -16,9 +16,45 @@
#include i2c.h
#include compiler.h
+static int pmic_select(struct pmic *p)
+{
+ int ret, old_bus;
+
+ old_bus = i2c_get_bus_num();
+ if (old_bus != p-bus) {
+ debug(%s: Select bus %d\n, __func__, p-bus);
+ ret = i2c_set_bus_num(p-bus);
+ if (ret) {
+ debug(%s: Cannot select pmic %s, err %d\n,
+ __func__, p-name, ret);
+ return -1;
+ }
+ }
+
+ return old_bus;
+}
+
+static int pmic_deselect(int old_bus)
+{
+ int ret;
+
+ if (old_bus != i2c_get_bus_num()) {
+ ret = i2c_set_bus_num(old_bus);
+ debug(%s: Select bus %d\n, __func__, old_bus);
+ if (ret) {
+ debug(%s: Cannot restore i2c bus, err %d\n,
+ __func__, ret);
+ return -1;
+ }
+ }
+
+ return 0;
+}
+
int pmic_reg_write(struct pmic *p, u32 reg, u32 val)
{
unsigned char buf[4] = { 0 };
+ int ret, old_bus;
if (check_reg(p, reg))
return -1;
@@ -52,23 +88,33 @@ int pmic_reg_write(struct pmic *p, u32 reg, u32
val) return -1;
}
- if (i2c_write(pmic_i2c_addr, reg, 1, buf, pmic_i2c_tx_num))
+ old_bus = pmic_select(p);
+ if (old_bus 0)
return -1;
- return 0;
+ ret = i2c_write(pmic_i2c_addr, reg, 1, buf, pmic_i2c_tx_num);
I'm wondering if setting the bus before each, single i2c write (when we
usually perform several writes to one device) will not be an overkill
(we search the ll_entry_count linker list each time to find max i2c
adapter names) ?
Here we are not setting the bus before each i2c write, If you look at the
pmic_select() function code it shows like
static int pmic_select(struct pmic *p)
{
/.../
old_bus = i2c_get_bus_num();
if (old_bus != p-bus) {
/./
}
return old_bus;
}
Here we are trying to get the bus number and if it is equal to the bus
on which we are going to write we are returning immediately which is minimal.
The i2c_set_bus_num() is now done at pmic_probe(), but this also
introduces overkill for probing each device when we want to read from
it.
As a side note - I would appreciate if you would add Stefano Babic and
me on the Cc (as we are listed at e.g. power_core.c).
Okay, will do it.
Best Wishes,
Leela Krishna
+ pmic_deselect(old_bus);
+ return ret;
}
int pmic_reg_read(struct pmic *p, u32 reg, u32 *val)
{
unsigned char buf[4] = { 0 };
u32 ret_val = 0;
+ int ret, old_bus;
if (check_reg(p, reg))
return -1;
- if (i2c_read(pmic_i2c_addr, reg, 1, buf, pmic_i2c_tx_num))
+ old_bus = pmic_select(p);
+ if (old_bus 0)
return -1;
+ ret = i2c_read(pmic_i2c_addr, reg, 1, buf, pmic_i2c_tx_num);
+ pmic_deselect(old_bus);
+ if (ret)
+ return ret;
+
switch (pmic_i2c_tx_num) {
case 3:
if (p-sensor_byte_order ==
PMIC_SENSOR_BYTE_ORDER_BIG) @@ -117,9 +163,15 @@ int
pmic_reg_update(struct pmic *p, int reg, uint regval)
int pmic_probe(struct pmic *p)
{
- i2c_set_bus_num(p-bus);
+ int ret, old_bus;
+
+ old_bus = pmic_select(p);
+ if (old_bus 0)
+ return -1;
debug(Bus: %d PMIC:%s probed!\n, p-bus, p-name);
- if (i2c_probe(pmic_i2c_addr)) {
+ ret = i2c_probe(pmic_i2c_addr);
+ pmic_deselect(old_bus);
+ if (ret) {
printf(Can't find PMIC:%s\n, p-name);
return -1;
}
--
Best regards,
Lukasz Majewski
Samsung RD Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] zynq: Use arch_cpu_init() instead of lowlevel_init()
Hi Michal,
On Thu, 03 Oct 2013 08:58:38 +0200, Michal Simek mon...@monstr.eu
wrote:
On 10/02/2013 09:43 PM, Albert ARIBAUD wrote:
Hi Michal,
On Tue, 24 Sep 2013 12:38:38 +0200, Michal Simek mon...@monstr.eu
wrote:
Hi Albert,
On 09/23/2013 04:37 PM, Albert ARIBAUD wrote:
Hi Michal,
On Mon, 23 Sep 2013 16:19:52 +0200, Michal Simek mon...@monstr.eu
wrote:
On 09/23/2013 02:31 PM, Albert ARIBAUD wrote:
Hi Michal,
On Thu, 22 Aug 2013 14:52:02 +0200, Michal Simek
michal.si...@xilinx.com wrote:
Zynq lowlevel_init() was implemented in C but stack
pointer is setup after function call in _main().
Move architecture setup to arch_cpu_init() which is call
as the first function in board_init_f() which
already have correct stack pointer.
Reported-by: Sven Schwermer sven.schwer...@tuhh.de
Signed-off-by: Michal Simek michal.si...@xilinx.com
---
I can't see any problem to call zynq setup a little
bit later. There is already expectation that u-boot
runs from DDR.
Moving lowlevel_init from C to ASM is possible but
I will have to introduce new macros with hardcoded
values. Using structures is much nicer.
---
arch/arm/cpu/armv7/zynq/cpu.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/cpu/armv7/zynq/cpu.c
b/arch/arm/cpu/armv7/zynq/cpu.c
index 4367d1a..8846f30 100644
--- a/arch/arm/cpu/armv7/zynq/cpu.c
+++ b/arch/arm/cpu/armv7/zynq/cpu.c
@@ -11,6 +11,10 @@
void lowlevel_init(void)
{
+}
I'd rather you deleted lowlevel_init() as a C function with this
name should not exist.
Ok. Do you want me to create almost empty low_level.S or just use
arch/arm/cpu/arvm7/lowlevel_init.S and define empty s_init()?
Urgh. I realize removing the C function would give you more work than
simply keeping it empty until the whole s_init() mess is cleaned up. :(
I'll take your change as-is, sorry for the noise.
In connection to this topic we have recently found one issue
regarding to neon instruction which u-boot uses.
We have this code to enable them in asm and adding this to lowlevel_init.S
is straight way how to do so.
mov r0, r0
mrc p15, 0, r1, c1, c0, 2
orr r1, r1, #(0xf 20)
mcr p15, 0, r1, c1, c0, 2
fmrxr1, FPEXC
orr r1,r1, #(130)
fmxrFPEXC, r1
Is it ok to create zynq asm specific lowlevel function
or doing this through s_init() or you have nice a clean way how
this should be solved when you are saying that s_init() is mess.
Sorry for responding slowly.
I suspect when you say neon instruction that U-Boot uses, you mean neon
instructions that GCC is allowed to emit while building U-Boot, right?
yes.
So we're talking about neon insns in C code only, not asm, correct?
yes. gcc emits neon instruction in timer code. Not in asm.
If this is correct, then does something prevent you from enabling
neon instructions as early as possible, in e.g. the lowlevel_init
routine?
ok let me clear this. I think location of this code is clear.
It is asm code and it will be called ASAP even
we know exactly which code emits neon instructions.
My point was if we should create specific lowlevel_init asm function
and add this code there.
Or use arch/arm/cpu/armv7/lowlevel_init.S and create just s_init function.
You mentioned above that s_init() is a mess and needs to be clean up
but you didn't mentioned how.
It means my point is if you tell us how should be clean up we can
just submit code which is compatible with this cleanup activity.
If I knew how to clean s_init() up, I'd have sent out patches
already. :)
Anyway, I'm not sure that I see how s_init() and your need for a NEON
enable sequence would be related: this sequence does not *need* to be in
s_init().
Indeed, enabling NEON is, IMO, similar to enabling alignment checks
or setting the CPU mode, so I guess it could find its way in start.S,
inside a preprocessor conditional (since e.g. not all Cortex-A9 will
support NEON).
BTW, where in U-Boot does GCC get instructed to emit NEON instructions
at the moment? There is no -mfpu or -mfloat-abi option in the code base
right now, so I suspect you're going to introduce it along with the
enable sequence, correct?
Thanks,
Michal
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] RFC: exynos: Disable the display controller when starting Linux
If the exynos display controller is still active when Linux starts,
then it will result in a kernel panic while FIMD sysmmu driver is
getting probed.
Calling exynos_fimd_lcd_disable() before jumping into kernel
disables the display controller by switching off the windows,
hence resolving the kernel panic which arises from sysmmu driver.
Create an Exynos specific definition for the weak function
arch_cleanup_before_linux(), and then place the call to
exynos_fimd_lcd_disable() inside the overrided definition of
arch_cleanup_before_linux().
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
Signed-off-by: Simon Glass s...@chromium.org
---
arch/arm/cpu/armv7/exynos/system.c| 9 +
arch/arm/include/asm/arch-exynos/system.h | 9 +
drivers/video/exynos_fimd.c | 8
3 files changed, 26 insertions(+)
diff --git a/arch/arm/cpu/armv7/exynos/system.c
b/arch/arm/cpu/armv7/exynos/system.c
index ad12445..977169b 100644
--- a/arch/arm/cpu/armv7/exynos/system.c
+++ b/arch/arm/cpu/armv7/exynos/system.c
@@ -69,3 +69,12 @@ void set_system_display_ctrl(void)
else
exynos5_set_system_display();
}
+
+/*
+ * Cleanup any Exynos specific setting here,
+ * if they can cause problem during kernel boot.
+ */
+void arch_cleanup_before_linux(void)
+{
+ exynos_fimd_lcd_disable();
+}
diff --git a/arch/arm/include/asm/arch-exynos/system.h
b/arch/arm/include/asm/arch-exynos/system.h
index 7e2057c..ed0c984 100644
--- a/arch/arm/include/asm/arch-exynos/system.h
+++ b/arch/arm/include/asm/arch-exynos/system.h
@@ -40,4 +40,13 @@ struct exynos5_sysreg {
void set_usbhost_mode(unsigned int mode);
void set_system_display_ctrl(void);
+#ifdef CONFIG_EXYNOS_FB
+/* Disable the display */
+void exynos_fimd_lcd_disable(void);
+#else
+static inline void exynos_fimd_lcd_disable(void)
+{
+}
+#endif
+
#endif /* _EXYNOS4_SYSTEM_H */
diff --git a/drivers/video/exynos_fimd.c b/drivers/video/exynos_fimd.c
index 8c2de4e..6a13d03 100644
--- a/drivers/video/exynos_fimd.c
+++ b/drivers/video/exynos_fimd.c
@@ -363,3 +363,11 @@ unsigned long exynos_fimd_calc_fbsize(void)
{
return pvid-vl_col * pvid-vl_row * (NBITS(pvid-vl_bpix) / 8);
}
+
+void exynos_fimd_lcd_disable(void)
+{
+ int i;
+
+ for (i = 0; i 4; i++)
+ exynos_fimd_window_off(i);
+}
--
1.7.12.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] RFC: arm: add call to cleanup things before jumping into kernel
Add infrasturcture to cleanup any of those architecture related settings
done for u-boot, if they can cause problem during kernel boot.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
arch/arm/cpu/armv7/cpu.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/cpu/armv7/cpu.c b/arch/arm/cpu/armv7/cpu.c
index 01cdb7e..edf4604 100644
--- a/arch/arm/cpu/armv7/cpu.c
+++ b/arch/arm/cpu/armv7/cpu.c
@@ -23,6 +23,7 @@
#include linux/compiler.h
void __weak cpu_cache_initialization(void){}
+void __weak arch_cleanup_before_linux(void){}
int cleanup_before_linux(void)
{
@@ -35,6 +36,11 @@ int cleanup_before_linux(void)
#ifndef CONFIG_SPL_BUILD
disable_interrupts();
#endif
+ /*
+* Cleanup any of those architecture related settings done for u-boot,
+* if they can cause problem during kernel boot.
+*/
+ arch_cleanup_before_linux();
/*
* Turn off I-cache and invalidate it
--
1.7.12.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] RFC: exynos: Disable the display controller when starting Linux
Hi Ajay, On Thu, 03 Oct 2013 14:34:20 +0530, Ajay Kumar ajaykumar...@samsung.com wrote: If the exynos display controller is still active when Linux starts, then it will result in a kernel panic while FIMD sysmmu driver is getting probed. Calling exynos_fimd_lcd_disable() before jumping into kernel disables the display controller by switching off the windows, hence resolving the kernel panic which arises from sysmmu driver. Create an Exynos specific definition for the weak function arch_cleanup_before_linux(), and then place the call to exynos_fimd_lcd_disable() inside the overrided definition of arch_cleanup_before_linux(). Signed-off-by: Ajay Kumar ajaykumar...@samsung.com Signed-off-by: Simon Glass s...@chromium.org --- Why should the fix to this situation be making U-Boot disable the display controller rather than making Linux able to cope with an already active display controller? Besides, fixing Linux would allow seamless booting displays, without an ugly off-on glitch. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] RFC: arm: add call to cleanup things before jumping into kernel
Hi Ajay, On Thu, 03 Oct 2013 14:34:19 +0530, Ajay Kumar ajaykumar...@samsung.com wrote: Add infrasturcture to cleanup any of those architecture related settings done for u-boot, if they can cause problem during kernel boot. Signed-off-by: Ajay Kumar ajaykumar...@samsung.com --- Regardless to ma question re fixing the issue in U-Boot or Linux: does something prevent using the already existing cleanup_before_linux() function, and if not, what made you choose to create another one instead? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] RFC: exynos: Disable the display controller when starting Linux
+Simon Glass On Thu, Oct 3, 2013 at 2:25 PM, Albert ARIBAUD albert.u.b...@aribaud.netwrote: Hi Ajay, On Thu, 03 Oct 2013 14:34:20 +0530, Ajay Kumar ajaykumar...@samsung.com wrote: If the exynos display controller is still active when Linux starts, then it will result in a kernel panic while FIMD sysmmu driver is getting probed. Calling exynos_fimd_lcd_disable() before jumping into kernel disables the display controller by switching off the windows, hence resolving the kernel panic which arises from sysmmu driver. Create an Exynos specific definition for the weak function arch_cleanup_before_linux(), and then place the call to exynos_fimd_lcd_disable() inside the overrided definition of arch_cleanup_before_linux(). Signed-off-by: Ajay Kumar ajaykumar...@samsung.com Signed-off-by: Simon Glass s...@chromium.org --- Why should the fix to this situation be making U-Boot disable the display controller rather than making Linux able to cope with an already active display controller? Besides, fixing Linux would allow seamless booting displays, without an ugly off-on glitch. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/6] power: Explicitly select pmic device's bus
Hi Leela,
Hello Lukasz,
Thanks for reviewing the patch.
On Wed, Oct 2, 2013 at 8:41 PM, Lukasz Majewski
l.majew...@samsung.com wrote:
Hi Leela,
The current pmic i2c code assumes the current i2c bus is
the same as the pmic device's bus. There is nothing ensuring
that to be true. Therefore, select the proper bus before performing
a transaction.
Signed-off-by: Aaron Durbin adur...@chromium.org
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
Reviewed-by: Doug Anderson diand...@google.com
---
drivers/power/power_i2c.c | 62
+ 1 file changed, 57
insertions(+), 5 deletions(-)
diff --git a/drivers/power/power_i2c.c b/drivers/power/power_i2c.c
index 47c606f..c22e01f 100644
--- a/drivers/power/power_i2c.c
+++ b/drivers/power/power_i2c.c
@@ -16,9 +16,45 @@
#include i2c.h
#include compiler.h
+static int pmic_select(struct pmic *p)
+{
+ int ret, old_bus;
+
+ old_bus = i2c_get_bus_num();
+ if (old_bus != p-bus) {
+ debug(%s: Select bus %d\n, __func__, p-bus);
+ ret = i2c_set_bus_num(p-bus);
+ if (ret) {
+ debug(%s: Cannot select pmic %s, err %d\n,
+ __func__, p-name, ret);
+ return -1;
+ }
+ }
+
+ return old_bus;
+}
+
+static int pmic_deselect(int old_bus)
+{
+ int ret;
+
+ if (old_bus != i2c_get_bus_num()) {
+ ret = i2c_set_bus_num(old_bus);
+ debug(%s: Select bus %d\n, __func__, old_bus);
+ if (ret) {
+ debug(%s: Cannot restore i2c bus, err %d\n,
+ __func__, ret);
+ return -1;
+ }
+ }
+
+ return 0;
+}
+
int pmic_reg_write(struct pmic *p, u32 reg, u32 val)
{
unsigned char buf[4] = { 0 };
+ int ret, old_bus;
if (check_reg(p, reg))
return -1;
@@ -52,23 +88,33 @@ int pmic_reg_write(struct pmic *p, u32 reg, u32
val) return -1;
}
- if (i2c_write(pmic_i2c_addr, reg, 1, buf, pmic_i2c_tx_num))
+ old_bus = pmic_select(p);
+ if (old_bus 0)
return -1;
- return 0;
+ ret = i2c_write(pmic_i2c_addr, reg, 1, buf, pmic_i2c_tx_num);
I'm wondering if setting the bus before each, single i2c write
(when we usually perform several writes to one device) will not be
an overkill (we search the ll_entry_count linker list each time to
find max i2c adapter names) ?
Here we are not setting the bus before each i2c write, If you look at
the pmic_select() function code it shows like
static int pmic_select(struct pmic *p)
{
/.../
old_bus = i2c_get_bus_num();
if (old_bus != p-bus) {
/./
}
return old_bus;
}
Here we are trying to get the bus number and if it is equal to the bus
on which we are going to write we are returning immediately which is
minimal.
Thanks for explanation.
The i2c_set_bus_num() is now done at pmic_probe(), but this also
introduces overkill for probing each device when we want to read
from it.
As a side note - I would appreciate if you would add Stefano Babic
and me on the Cc (as we are listed at e.g. power_core.c).
Okay, will do it.
Best Wishes,
Leela Krishna
+ pmic_deselect(old_bus);
+ return ret;
}
int pmic_reg_read(struct pmic *p, u32 reg, u32 *val)
{
unsigned char buf[4] = { 0 };
u32 ret_val = 0;
+ int ret, old_bus;
if (check_reg(p, reg))
return -1;
- if (i2c_read(pmic_i2c_addr, reg, 1, buf, pmic_i2c_tx_num))
+ old_bus = pmic_select(p);
+ if (old_bus 0)
return -1;
+ ret = i2c_read(pmic_i2c_addr, reg, 1, buf, pmic_i2c_tx_num);
+ pmic_deselect(old_bus);
+ if (ret)
+ return ret;
+
switch (pmic_i2c_tx_num) {
case 3:
if (p-sensor_byte_order ==
PMIC_SENSOR_BYTE_ORDER_BIG) @@ -117,9 +163,15 @@ int
pmic_reg_update(struct pmic *p, int reg, uint regval)
int pmic_probe(struct pmic *p)
{
- i2c_set_bus_num(p-bus);
+ int ret, old_bus;
+
+ old_bus = pmic_select(p);
+ if (old_bus 0)
+ return -1;
debug(Bus: %d PMIC:%s probed!\n, p-bus, p-name);
- if (i2c_probe(pmic_i2c_addr)) {
+ ret = i2c_probe(pmic_i2c_addr);
+ pmic_deselect(old_bus);
+ if (ret) {
printf(Can't find PMIC:%s\n, p-name);
return -1;
}
--
Best regards,
Lukasz Majewski
Samsung RD Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
--
Best regards,
Re: [U-Boot] [PATCH 1/2] RFC: arm: add call to cleanup things before jumping into kernel
Hi Albert, On Thu, Oct 3, 2013 at 2:28 PM, Albert ARIBAUD albert.u.b...@aribaud.netwrote: Hi Ajay, On Thu, 03 Oct 2013 14:34:19 +0530, Ajay Kumar ajaykumar...@samsung.com wrote: Add infrasturcture to cleanup any of those architecture related settings done for u-boot, if they can cause problem during kernel boot. Signed-off-by: Ajay Kumar ajaykumar...@samsung.com --- Regardless to ma question re fixing the issue in U-Boot or Linux: does something prevent using the already existing cleanup_before_linux() function, and if not, what made you choose to create another one instead? cleanup_before_linux() generally cleans up things specific to the processor. I thought of introducing a cleanup function which would allow us to cleanup things which are SOC specific(all SOC under armv7 as per the patch). And, used the same function to cleanup some exynos specific stuff before booting linux. May be, I should have used a different name instead of arch_cleanup_before_linux? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] zynq: Use arch_cpu_init() instead of lowlevel_init()
Hi Albert,
On 10/03/2013 10:41 AM, Albert ARIBAUD wrote:
Hi Michal,
On Thu, 03 Oct 2013 08:58:38 +0200, Michal Simek mon...@monstr.eu
wrote:
On 10/02/2013 09:43 PM, Albert ARIBAUD wrote:
Hi Michal,
On Tue, 24 Sep 2013 12:38:38 +0200, Michal Simek mon...@monstr.eu
wrote:
Hi Albert,
On 09/23/2013 04:37 PM, Albert ARIBAUD wrote:
Hi Michal,
On Mon, 23 Sep 2013 16:19:52 +0200, Michal Simek mon...@monstr.eu
wrote:
On 09/23/2013 02:31 PM, Albert ARIBAUD wrote:
Hi Michal,
On Thu, 22 Aug 2013 14:52:02 +0200, Michal Simek
michal.si...@xilinx.com wrote:
Zynq lowlevel_init() was implemented in C but stack
pointer is setup after function call in _main().
Move architecture setup to arch_cpu_init() which is call
as the first function in board_init_f() which
already have correct stack pointer.
Reported-by: Sven Schwermer sven.schwer...@tuhh.de
Signed-off-by: Michal Simek michal.si...@xilinx.com
---
I can't see any problem to call zynq setup a little
bit later. There is already expectation that u-boot
runs from DDR.
Moving lowlevel_init from C to ASM is possible but
I will have to introduce new macros with hardcoded
values. Using structures is much nicer.
---
arch/arm/cpu/armv7/zynq/cpu.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/cpu/armv7/zynq/cpu.c
b/arch/arm/cpu/armv7/zynq/cpu.c
index 4367d1a..8846f30 100644
--- a/arch/arm/cpu/armv7/zynq/cpu.c
+++ b/arch/arm/cpu/armv7/zynq/cpu.c
@@ -11,6 +11,10 @@
void lowlevel_init(void)
{
+}
I'd rather you deleted lowlevel_init() as a C function with this
name should not exist.
Ok. Do you want me to create almost empty low_level.S or just use
arch/arm/cpu/arvm7/lowlevel_init.S and define empty s_init()?
Urgh. I realize removing the C function would give you more work than
simply keeping it empty until the whole s_init() mess is cleaned up. :(
I'll take your change as-is, sorry for the noise.
In connection to this topic we have recently found one issue
regarding to neon instruction which u-boot uses.
We have this code to enable them in asm and adding this to lowlevel_init.S
is straight way how to do so.
mov r0, r0
mrc p15, 0, r1, c1, c0, 2
orr r1, r1, #(0xf 20)
mcr p15, 0, r1, c1, c0, 2
fmrxr1, FPEXC
orr r1,r1, #(130)
fmxrFPEXC, r1
Is it ok to create zynq asm specific lowlevel function
or doing this through s_init() or you have nice a clean way how
this should be solved when you are saying that s_init() is mess.
Sorry for responding slowly.
I suspect when you say neon instruction that U-Boot uses, you mean neon
instructions that GCC is allowed to emit while building U-Boot, right?
yes.
So we're talking about neon insns in C code only, not asm, correct?
yes. gcc emits neon instruction in timer code. Not in asm.
If this is correct, then does something prevent you from enabling
neon instructions as early as possible, in e.g. the lowlevel_init
routine?
ok let me clear this. I think location of this code is clear.
It is asm code and it will be called ASAP even
we know exactly which code emits neon instructions.
My point was if we should create specific lowlevel_init asm function
and add this code there.
Or use arch/arm/cpu/armv7/lowlevel_init.S and create just s_init function.
You mentioned above that s_init() is a mess and needs to be clean up
but you didn't mentioned how.
It means my point is if you tell us how should be clean up we can
just submit code which is compatible with this cleanup activity.
If I knew how to clean s_init() up, I'd have sent out patches
already. :)
Fair enough. :-)
Anyway, I'm not sure that I see how s_init() and your need for a NEON
enable sequence would be related: this sequence does not *need* to be in
s_init().
ok. s_init is not asm function - but C function.
Indeed, enabling NEON is, IMO, similar to enabling alignment checks
or setting the CPU mode, so I guess it could find its way in start.S,
inside a preprocessor conditional (since e.g. not all Cortex-A9 will
support NEON).
ok. That sound good to me.
BTW, where in U-Boot does GCC get instructed to emit NEON instructions
at the moment? There is no -mfpu or -mfloat-abi option in the code base
right now, so I suspect you're going to introduce it along with the
enable sequence, correct?
file: arch/arm/cpu/armv7/zynq/timer.c
fce: void __udelay(unsigned long usec)
line: countticks = (u32) (((unsigned long long) TIMER_TICK_HZ * usec) /
100);
This is what I have got from Edgar.
A significant difference between the u-boot builds is that the failing
one is using NEON instructions for some of the div/mod helpers.
AFAIK, NEON instructions are disabled after reset and will cause undef
exceptions if issued while disabled.
That difference in builds which is mentioned above is when this patch is
applied.
[U-Boot] [PATCH v3 1/3] mtd: Fix function description in part_validate comment
The part_validate comment had a wrong description of the actions it does and referenced to non-existent functions while in fact it calls 'part_validate_eraseblock()'. Signed-off-by: Otavio Salvador ota...@ossystems.com.br --- Changes in v3: - Fix code comment (dropped 'either') Changes in v2: - rework commit log (Eric Benard) common/cmd_mtdparts.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/common/cmd_mtdparts.c b/common/cmd_mtdparts.c index 38a6e6d..f791372 100644 --- a/common/cmd_mtdparts.c +++ b/common/cmd_mtdparts.c @@ -381,10 +381,9 @@ static int part_validate_eraseblock(struct mtdids *id, struct part_info *part) /** - * Performs sanity check for supplied partition. Offset and size are verified - * to be within valid range. Partition type is checked and either - * parts_validate_nor() or parts_validate_nand() is called with the argument - * of part. + * Performs sanity check for supplied partition. Offset and size are + * verified to be within valid range. Partition type is checked and + * part_validate_eraseblock() is called with the argument of part. * * @param id of the parent device * @param part partition to validate -- 1.8.4.rc3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 3/3] doc: Fix a typo in the description in doc/README.JFFS2_NAND
Signed-off-by: Otavio Salvador ota...@ossystems.com.br --- Changes in v3: None Changes in v2: None doc/README.JFFS2_NAND | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/README.JFFS2_NAND b/doc/README.JFFS2_NAND index 5018ae8..09788d5 100644 --- a/doc/README.JFFS2_NAND +++ b/doc/README.JFFS2_NAND @@ -1,6 +1,6 @@ JFFS2 NAND support: -To ebable, use the following #define in the board configuration file: +To enable, use the following #define in the board configuration file: #define CONFIG_JFFS2_NAND 1 -- 1.8.4.rc3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 2/3] include/linux/fb.h: Add a missing include for 'list.h'
The modelist data uses the list definition but the 'list.h' header were not being included. The build failure is bellow: , | In file included from .c:16:0: | .../u-boot/include/linux/fb.h:503:19: error: field 'modelist' has incomplete type | struct list_head modelist; /* mode list */ |^ | make[1]: *** [.o] Error 1 | make[1]: Leaving directory `.../u-boot/board/xxx/' | make: *** [board/xxx//lib.o] Error 2 ` Signed-off-by: Otavio Salvador ota...@ossystems.com.br --- Changes in v3: None Changes in v2: - rework commitlog (Fabio) include/linux/fb.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/fb.h b/include/linux/fb.h index 3858f8f..111372c 100644 --- a/include/linux/fb.h +++ b/include/linux/fb.h @@ -2,6 +2,7 @@ #define _LINUX_FB_H #include linux/types.h +#include linux/list.h /* Definitions of frame buffers */ -- 1.8.4.rc3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 0/3] Trivial patches ready for merging
Hello, I am resending the patches I think are ready to be applied and are trivial. Please also add: http://patchwork.ozlabs.org/patch/279105/ as it fixes a watchdog to work. Changes in v3: - Fix code comment (dropped 'either') Changes in v2: - rework commit log (Eric Benard) - rework commitlog (Fabio) Otavio Salvador (3): mtd: Fix function description in part_validate comment include/linux/fb.h: Add a missing include for 'list.h' doc: Fix a typo in the description in doc/README.JFFS2_NAND common/cmd_mtdparts.c | 7 +++ doc/README.JFFS2_NAND | 2 +- include/linux/fb.h| 1 + 3 files changed, 5 insertions(+), 5 deletions(-) -- 1.8.4.rc3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] imx: Easy enabling of SION per-pin using MUX_MODE_SION helper macro
The macro allows easy setting in per-pin, as for example: , | imx_iomux_v3_setup_pad(MX6_PAD_NANDF_D1__GPIO_2_1 | MUX_MODE_SION); ` The IOMUX_CONFIG_SION allows for reading PAD value from PSR register. The following quote from the datasheet: , | ... | 28.4.2.2 GPIO Write Mode | The programming sequence for driving output signals should be as follows: | 1. Configure IOMUX to select GPIO mode (Via IOMUXC), also enable SION if need | to read loopback pad value through PSR | 2. Configure GPIO direction register to output (GPIO_GDIR[GDIR] set to 1b). | 3. Write value to data register (GPIO_DR). | ... ` This fixes the gpio_get_value to properly work when a GPIO is set for output and has no conflicts. Thanks for Benoît Thébaudeau benoit.thebaud...@advansee.com, Fabio Estevam fabio.este...@freescale.com and Eric Bénard e...@eukrea.com for helping to properly trace this down. Signed-off-by: Otavio Salvador ota...@ossystems.com.br --- arch/arm/include/asm/imx-common/iomux-v3.h | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/include/asm/imx-common/iomux-v3.h b/arch/arm/include/asm/imx-common/iomux-v3.h index dc2b3ef..b7bdaa5 100644 --- a/arch/arm/include/asm/imx-common/iomux-v3.h +++ b/arch/arm/include/asm/imx-common/iomux-v3.h @@ -57,6 +57,7 @@ typedef u64 iomux_v3_cfg_t; MUX_SEL_INPUT_OFS_SHIFT) #define MUX_MODE_SHIFT 36 +#define MUX_MODE_SION ((iomux_v3_cfg_t)IOMUX_CONFIG_SION MUX_MODE_SHIFT) #define MUX_MODE_MASK ((iomux_v3_cfg_t)0x1f MUX_MODE_SHIFT) #define MUX_PAD_CTRL_SHIFT 41 #define MUX_PAD_CTRL_MASK ((iomux_v3_cfg_t)0x3 MUX_PAD_CTRL_SHIFT) -- 1.8.4.rc3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 00/10] usb: Support for TIZEN's THOR download protocol
This patch series provide support for TIZEN's THOR download protocol.
Dedicated program for flashing TIZEN developer devices (TRATS, TRATS2)
is called lthor (or thor for Windows) and can be found at:
git clone git://review.tizen.org/tools/lthor
or for git web:
https://review.tizen.org/git/?p=tools/lthor.git;a=summary
Presented composite USB function acts as a front end to perform
correct USB communication with HOST PC.
To store the received data on the target, the DFU (Device Firmware
Update) code for flashing has been reused.
This means, that the dfu_alt_info environment variable is used
to provide information where a received file is stored.
This also means that dfu and thor can co-exists together.
Thor protocol and its implementation has one advantage - it is much
faster than DFU for large files transfers (especially rootfs images).
It applies on: u-boot-denx-usb/master
SHA1: 5077f96f10fe88f1f7cbe09743ac7c765f9e98c3
Test HW: Exynos4210 (TRATS)
Lukasz Majewski (10):
usb:udc:s3c: Reduce dcache invalidate range for UDC receive buffer
dfu:core: Find DFU alt setting number by passing its name
dfu:core: Export dfu_{get|free}_buf functions
usb:g_dnl: Replace static usb_configuration structure with
dynamically allocated one
usb:g_dnl: Add name parameter to g_dnl_bind_fixup function
usb:g_dnl:f_thor: USB download function to support TIZEN's THOR
protocol
usb:g_dnl: Support for TIZEN's THOR function at generic download code
cmd:thor: Support for TIZEN's download (thordown) command
samsung:common:thor: Define common Samsung code to handle THOR usb
descriptor setup
trats: Update TRATS config to support TIZEN download
board/samsung/common/Makefile |1 +
board/samsung/common/thor.c | 21 +
board/siemens/common/factoryset.c |2 +-
common/Makefile |1 +
common/cmd_thordown.c | 58 ++
drivers/dfu/dfu.c | 16 +-
drivers/usb/gadget/Makefile |1 +
drivers/usb/gadget/f_thor.c | 1006 +
drivers/usb/gadget/f_thor.h | 123
drivers/usb/gadget/g_dnl.c| 38 +-
drivers/usb/gadget/s3c_udc_otg_xfer_dma.c |2 +-
include/configs/trats.h | 13 +-
include/dfu.h |3 +
include/g_dnl.h |2 +-
include/thor.h| 27 +
15 files changed, 1295 insertions(+), 19 deletions(-)
create mode 100644 board/samsung/common/thor.c
create mode 100644 common/cmd_thordown.c
create mode 100644 drivers/usb/gadget/f_thor.c
create mode 100644 drivers/usb/gadget/f_thor.h
create mode 100644 include/thor.h
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 08/10] cmd:thor: Support for TIZEN's download (thordown) command
New command - thordown - has been added to support downloading data
via lthor TIZEN program.
It is similar to dfu command syntax and reuses its code for flashing data.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
common/Makefile |1 +
common/cmd_thordown.c | 58 +
2 files changed, 59 insertions(+)
create mode 100644 common/cmd_thordown.c
diff --git a/common/Makefile b/common/Makefile
index 288690b..8daca5b 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -168,6 +168,7 @@ COBJS-y += usb.o usb_hub.o
COBJS-$(CONFIG_USB_STORAGE) += usb_storage.o
endif
COBJS-$(CONFIG_CMD_USB_MASS_STORAGE) += cmd_usb_mass_storage.o
+COBJS-$(CONFIG_CMD_THOR_DOWNLOAD) += cmd_thordown.o
COBJS-$(CONFIG_CMD_XIMG) += cmd_ximg.o
COBJS-$(CONFIG_YAFFS2) += cmd_yaffs2.o
COBJS-$(CONFIG_CMD_SPL) += cmd_spl.o
diff --git a/common/cmd_thordown.c b/common/cmd_thordown.c
new file mode 100644
index 000..fc5635b
--- /dev/null
+++ b/common/cmd_thordown.c
@@ -0,0 +1,58 @@
+/*
+ * cmd_thordown.c -- USB TIZEN THOR Downloader gadget
+ *
+ * Copyright (C) 2013 Lukasz Majewski l.majew...@samsung.com
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include thor.h
+#include dfu.h
+#include g_dnl.h
+
+int do_thor_down(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+ const char *s = thor;
+ int ret;
+
+ if (argc 3)
+ return CMD_RET_USAGE;
+
+ puts(TIZEN \THOR\ Downloader\n);
+
+ ret = dfu_init_env_entities(argv[1], simple_strtoul(argv[2], NULL, 10));
+ if (ret)
+ return ret;
+
+ board_usb_init();
+ g_dnl_register(s);
+
+ ret = thor_init();
+ if (ret) {
+ error(THOR DOWNLOAD failed: %d, ret);
+ ret = CMD_RET_FAILURE;
+ goto exit;
+ }
+
+ ret = thor_handle();
+ if (ret) {
+ error(THOR failed: %d, ret);
+ ret = CMD_RET_FAILURE;
+ goto exit;
+ }
+
+exit:
+ g_dnl_unregister();
+ dfu_free_entities();
+
+ return ret;
+}
+
+U_BOOT_CMD(thordown, CONFIG_SYS_MAXARGS, 1, do_thor_down,
+ TIZEN \THOR\ downloader,
+ interface dev\n
+- device software upgrade via LTHOR TIZEN dowload\n
+ program at dev attached to interface interface\n
+);
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 09/10] samsung:common:thor: Define common Samsung code to handle THOR usb descriptor setup
Special, common to Samsung, function for altering usb descriptor's
idVendor and idProduct has been added.
For compatibility reasons (Win vs Linux) the THOR idProduct must be
different than the one for DFU/UMS.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com
---
board/samsung/common/Makefile |1 +
board/samsung/common/thor.c | 21 +
2 files changed, 22 insertions(+)
create mode 100644 board/samsung/common/thor.c
diff --git a/board/samsung/common/Makefile b/board/samsung/common/Makefile
index 9e48a7b..ad7564c 100644
--- a/board/samsung/common/Makefile
+++ b/board/samsung/common/Makefile
@@ -10,6 +10,7 @@ include $(TOPDIR)/config.mk
LIB= $(obj)libsamsung.o
COBJS-$(CONFIG_SOFT_I2C_MULTI_BUS) += multi_i2c.o
+COBJS-$(CONFIG_THOR_FUNCTION) += thor.o
SRCS:= $(COBJS-y:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS-y))
diff --git a/board/samsung/common/thor.c b/board/samsung/common/thor.c
new file mode 100644
index 000..1c7630d
--- /dev/null
+++ b/board/samsung/common/thor.c
@@ -0,0 +1,21 @@
+/*
+ * Copyright (C) 2013 Samsung Electronics
+ * Lukasz Majewski l.majew...@samsung.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include linux/usb/ch9.h
+
+int g_dnl_bind_fixup(struct usb_device_descriptor *dev, const char *name)
+{
+ if (!strcmp(name, usb_dnl_thor)) {
+ put_unaligned(CONFIG_G_DNL_THOR_VENDOR_NUM, dev-idVendor);
+ put_unaligned(CONFIG_G_DNL_THOR_PRODUCT_NUM, dev-idProduct);
+ } else {
+ put_unaligned(CONFIG_G_DNL_VENDOR_NUM, dev-idVendor);
+ put_unaligned(CONFIG_G_DNL_PRODUCT_NUM, dev-idProduct);
+ }
+ return 0;
+}
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 03/10] dfu:core: Export dfu_{get|free}_buf functions
Define the dfu_get_buf() and dfu_free_buf() as global functions.
They are necessary for zero copy buffer management, when DFU backend is
used for storing data.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
Marek Vasut ma...@denx.de
---
drivers/dfu/dfu.c |4 ++--
include/dfu.h |2 ++
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index cbeea3c..d656f0e 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -67,14 +67,14 @@ int dfu_init_env_entities(char *interface, int dev)
static unsigned char *dfu_buf;
static unsigned long dfu_buf_size = CONFIG_SYS_DFU_DATA_BUF_SIZE;
-static unsigned char *dfu_free_buf(void)
+unsigned char *dfu_free_buf(void)
{
free(dfu_buf);
dfu_buf = NULL;
return dfu_buf;
}
-static unsigned char *dfu_get_buf(void)
+unsigned char *dfu_get_buf(void)
{
char *s;
diff --git a/include/dfu.h b/include/dfu.h
index b144255..cc14044 100644
--- a/include/dfu.h
+++ b/include/dfu.h
@@ -129,6 +129,8 @@ void dfu_trigger_reset(void);
int dfu_get_alt(char *name);
bool dfu_reset(void);
int dfu_init_env_entities(char *interface, int dev);
+unsigned char *dfu_get_buf(void);
+unsigned char *dfu_free_buf(void);
int dfu_read(struct dfu_entity *de, void *buf, int size, int blk_seq_num);
int dfu_write(struct dfu_entity *de, void *buf, int size, int blk_seq_num);
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 01/10] usb:udc:s3c: Reduce dcache invalidate range for UDC receive buffer
The s3c udc driver sends data in a max packet size. Therefore the dcache invalidate range shall be equal to max packet, not the entire DMA_BUFFER_SIZE. Signed-off-by: Lukasz Majewski l.majew...@samsung.com Cc: Marek Vasut ma...@denx.de --- drivers/usb/gadget/s3c_udc_otg_xfer_dma.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/gadget/s3c_udc_otg_xfer_dma.c b/drivers/usb/gadget/s3c_udc_otg_xfer_dma.c index d7af5e9..5e3ba76 100644 --- a/drivers/usb/gadget/s3c_udc_otg_xfer_dma.c +++ b/drivers/usb/gadget/s3c_udc_otg_xfer_dma.c @@ -117,7 +117,7 @@ static int setdma_rx(struct s3c_ep *ep, struct s3c_request *req) invalidate_dcache_range((unsigned long) ep-dev-dma_buf[ep_num], (unsigned long) ep-dev-dma_buf[ep_num] - + DMA_BUFFER_SIZE); + + ep-ep.maxpacket); if (length == 0) pktcnt = 1; -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 02/10] dfu:core: Find DFU alt setting number by passing its name
New function - dfu_get_alt() - has been added to dfu core. If present, it
returns alt setting's number corresponding to passed name.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
Cc: Marek Vasut ma...@denx.de
---
drivers/dfu/dfu.c | 12
include/dfu.h |1 +
2 files changed, 13 insertions(+)
diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index 56b21c7..cbeea3c 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -440,3 +440,15 @@ struct dfu_entity *dfu_get_entity(int alt)
return NULL;
}
+
+int dfu_get_alt(char *name)
+{
+ struct dfu_entity *dfu;
+
+ list_for_each_entry(dfu, dfu_list, list) {
+ if (!strncmp(dfu-name, name, strlen(dfu-name)))
+ return dfu-alt;
+ }
+
+ return -ENODEV;
+}
diff --git a/include/dfu.h b/include/dfu.h
index b2ecf1b..b144255 100644
--- a/include/dfu.h
+++ b/include/dfu.h
@@ -126,6 +126,7 @@ const char *dfu_get_layout(enum dfu_layout l);
struct dfu_entity *dfu_get_entity(int alt);
char *dfu_extract_token(char** e, int *n);
void dfu_trigger_reset(void);
+int dfu_get_alt(char *name);
bool dfu_reset(void);
int dfu_init_env_entities(char *interface, int dev);
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 05/10] usb:g_dnl: Add name parameter to g_dnl_bind_fixup function
New parameter, namely *name has been added to g_dnl_bind_fixup().
It is necessary (for compatibility reasons) to assign new USB idProduct
and idVendor for different usb functions.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
Cc: Marek Vasut ma...@denx.de
---
board/siemens/common/factoryset.c |2 +-
drivers/usb/gadget/g_dnl.c|4 ++--
include/g_dnl.h |2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/board/siemens/common/factoryset.c
b/board/siemens/common/factoryset.c
index eda9141..fbe7997 100644
--- a/board/siemens/common/factoryset.c
+++ b/board/siemens/common/factoryset.c
@@ -275,7 +275,7 @@ int factoryset_setenv(void)
return ret;
}
-int g_dnl_bind_fixup(struct usb_device_descriptor *dev)
+int g_dnl_bind_fixup(struct usb_device_descriptor *dev, const char *name)
{
put_unaligned(factory_dat.usb_vendor_id, dev-idVendor);
put_unaligned(factory_dat.usb_product_id, dev-idProduct);
diff --git a/drivers/usb/gadget/g_dnl.c b/drivers/usb/gadget/g_dnl.c
index 1aaf78f..98560b8 100644
--- a/drivers/usb/gadget/g_dnl.c
+++ b/drivers/usb/gadget/g_dnl.c
@@ -126,7 +126,7 @@ static int g_dnl_config_register(struct usb_composite_dev
*cdev)
}
__weak
-int g_dnl_bind_fixup(struct usb_device_descriptor *dev)
+int g_dnl_bind_fixup(struct usb_device_descriptor *dev, const char *name)
{
return 0;
}
@@ -153,7 +153,7 @@ static int g_dnl_bind(struct usb_composite_dev *cdev)
g_dnl_string_defs[1].id = id;
device_desc.iProduct = id;
- g_dnl_bind_fixup(device_desc);
+ g_dnl_bind_fixup(device_desc, cdev-driver-name);
ret = g_dnl_config_register(cdev);
if (ret)
goto error;
diff --git a/include/g_dnl.h b/include/g_dnl.h
index 2b2f11a..f16f451 100644
--- a/include/g_dnl.h
+++ b/include/g_dnl.h
@@ -10,7 +10,7 @@
#include linux/usb/ch9.h
#include linux/usb/gadget.h
-int g_dnl_bind_fixup(struct usb_device_descriptor *);
+int g_dnl_bind_fixup(struct usb_device_descriptor *, const char *);
int g_dnl_register(const char *s);
void g_dnl_unregister(void);
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 10/10] trats: Update TRATS config to support TIZEN download
A set of environment variables needs to be updated to provide support for TIZEN download command (tizendown). Since DFU is used as a flashing backend, it is also necessary to extent malloc pool size for DFU buffer allocation. Moreover, for compatibility reasons (Win vs. Lin) new USB idProduct number for download gadget had to be added. Signed-off-by: Lukasz Majewski l.majew...@samsung.com Cc: Marek Vasut ma...@denx.de --- include/configs/trats.h | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/include/configs/trats.h b/include/configs/trats.h index 24ea06b..955bd20 100644 --- a/include/configs/trats.h +++ b/include/configs/trats.h @@ -50,7 +50,7 @@ #define CONFIG_MACH_TYPE MACH_TYPE_TRATS /* Size of malloc() pool */ -#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + (16 20)) +#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + (80 20)) /* select serial console configuration */ #define CONFIG_SERIAL2 /* use SERIAL 2 */ @@ -91,12 +91,20 @@ /* USB Composite download gadget - g_dnl */ #define CONFIG_USBDOWNLOAD_GADGET + +/* TIZEN THOR downloader support */ +#define CONFIG_CMD_THOR_DOWNLOAD +#define CONFIG_THOR_FUNCTION + +#define CONFIG_SYS_DFU_DATA_BUF_SIZE (32 20) #define CONFIG_DFU_FUNCTION #define CONFIG_DFU_MMC /* USB Samsung's IDs */ #define CONFIG_G_DNL_VENDOR_NUM 0x04E8 #define CONFIG_G_DNL_PRODUCT_NUM 0x6601 +#define CONFIG_G_DNL_THOR_VENDOR_NUM CONFIG_G_DNL_VENDOR_NUM +#define CONFIG_G_DNL_THOR_PRODUCT_NUM 0x685D #define CONFIG_G_DNL_MANUFACTURER Samsung #define CONFIG_BOOTDELAY 1 @@ -131,7 +139,8 @@ #define CONFIG_DFU_ALT \ u-boot mmc 80 400; \ uImage ext4 0 2; \ - exynos4210-trats.dtb ext4 0 2\0 + exynos4210-trats.dtb ext4 0 2; \ + PARTS_ROOT part 0 5\0 #define CONFIG_ENV_OVERWRITE #define CONFIG_SYS_CONSOLE_INFO_QUIET -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 04/10] usb:g_dnl: Replace static usb_configuration structure with dynamically allocated one
When the usb_configuration structure is declared as static, it is very
hard to assure, that relevant fields (as e.g. config-interfaces[]) are
cleared out before new call to g_dnl related functions.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
Marek Vasut ma...@denx.de
---
drivers/usb/gadget/g_dnl.c | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/gadget/g_dnl.c b/drivers/usb/gadget/g_dnl.c
index 40868c0..1aaf78f 100644
--- a/drivers/usb/gadget/g_dnl.c
+++ b/drivers/usb/gadget/g_dnl.c
@@ -79,6 +79,8 @@ static int g_dnl_unbind(struct usb_composite_dev *cdev)
{
struct usb_gadget *gadget = cdev-gadget;
+ free(cdev-config);
+ cdev-config = NULL;
debug(%s: calling usb_gadget_disconnect for
controller '%s'\n, shortname, gadget-name);
usb_gadget_disconnect(gadget);
@@ -105,16 +107,22 @@ static int g_dnl_do_config(struct usb_configuration *c)
static int g_dnl_config_register(struct usb_composite_dev *cdev)
{
- static struct usb_configuration config = {
- .label = usb_dnload,
- .bmAttributes = USB_CONFIG_ATT_ONE | USB_CONFIG_ATT_SELFPOWER,
- .bConfigurationValue = CONFIGURATION_NUMBER,
- .iConfiguration = STRING_USBDOWN,
+ struct usb_configuration *config;
+ const char *name = usb_dnload;
- .bind = g_dnl_do_config,
- };
+ config = memalign(CONFIG_SYS_CACHELINE_SIZE, sizeof(*config));
+ if (!config)
+ return -ENOMEM;
- return usb_add_config(cdev, config);
+ memset(config, 0, sizeof(*config));
+
+ config-label = name;
+ config-bmAttributes = USB_CONFIG_ATT_ONE | USB_CONFIG_ATT_SELFPOWER;
+ config-bConfigurationValue = CONFIGURATION_NUMBER;
+ config-iConfiguration = STRING_USBDOWN;
+ config-bind = g_dnl_do_config;
+
+ return usb_add_config(cdev, config);
}
__weak
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 06/10] usb:g_dnl:f_thor: USB download function to support TIZEN's THOR protocol
Implementation of USB download function which supports THOR protocol.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
Cc: Marek Vasut ma...@denx.de
---
drivers/usb/gadget/Makefile |1 +
drivers/usb/gadget/f_thor.c | 1010 +++
drivers/usb/gadget/f_thor.h | 123 ++
include/thor.h | 27 ++
4 files changed, 1161 insertions(+)
create mode 100644 drivers/usb/gadget/f_thor.c
create mode 100644 drivers/usb/gadget/f_thor.h
create mode 100644 include/thor.h
diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile
index 1590c4a..afaf5ce 100644
--- a/drivers/usb/gadget/Makefile
+++ b/drivers/usb/gadget/Makefile
@@ -21,6 +21,7 @@ ifdef CONFIG_USB_GADGET
COBJS-$(CONFIG_USB_GADGET_ATMEL_USBA) += atmel_usba_udc.o
COBJS-$(CONFIG_USB_GADGET_S3C_UDC_OTG) += s3c_udc_otg.o
COBJS-$(CONFIG_USB_GADGET_FOTG210) += fotg210.o
+COBJS-$(CONFIG_THOR_FUNCTION) += f_thor.o
COBJS-$(CONFIG_USBDOWNLOAD_GADGET) += g_dnl.o
COBJS-$(CONFIG_DFU_FUNCTION) += f_dfu.o
COBJS-$(CONFIG_USB_GADGET_MASS_STORAGE) += f_mass_storage.o
diff --git a/drivers/usb/gadget/f_thor.c b/drivers/usb/gadget/f_thor.c
new file mode 100644
index 000..366194d
--- /dev/null
+++ b/drivers/usb/gadget/f_thor.c
@@ -0,0 +1,1010 @@
+/*
+ * f_thor.c -- USB TIZEN THOR Downloader gadget function
+ *
+ * Copyright (C) 2013 Samsung Electronics
+ * Lukasz Majewski l.majew...@samsung.com
+ *
+ * Based on code from:
+ * git://review.tizen.org/kernel/u-boot
+ *
+ * Developed by:
+ * Copyright (C) 2009 Samsung Electronics
+ * Minkyu Kang mk7.k...@samsung.com
+ * Sanghee Kim sh0130@samsung.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include errno.h
+#include common.h
+#include malloc.h
+#include version.h
+#include linux/usb/ch9.h
+#include linux/usb/gadget.h
+#include linux/usb/composite.h
+#include linux/usb/cdc.h
+#include g_dnl.h
+#include dfu.h
+
+#include f_thor.h
+
+static void thor_tx_data(char *data, int len);
+static void thor_set_dma(void *addr, int len);
+static int thor_rx_data(void);
+
+static struct f_thor *thor_func;
+static inline struct f_thor *func_to_thor(struct usb_function *f)
+{
+ return container_of(f, struct f_thor, usb_function);
+}
+
+DEFINE_CACHE_ALIGN_BUFFER(char, thor_tx_data_buf, sizeof(struct rsp_box));
+DEFINE_CACHE_ALIGN_BUFFER(char, thor_rx_data_buf, sizeof(struct rqt_box));
+
+/* ** */
+/* THOR protocol - transmission handling */
+/* ** */
+DEFINE_CACHE_ALIGN_BUFFER(char, f_name, F_NAME_BUF_SIZE);
+static unsigned long long int thor_file_size;
+static int alt_setting_num;
+
+static void send_rsp(const struct rsp_box *rsp)
+{
+ /* should be copy on dma duffer */
+ memcpy(thor_tx_data_buf, rsp, sizeof(struct rsp_box));
+ thor_tx_data(thor_tx_data_buf, sizeof(struct rsp_box));
+
+ debug(-RSP: %d, %d\n, rsp-rsp, rsp-rsp_data);
+}
+
+static void send_data_rsp(s32 ack, s32 count)
+{
+ ALLOC_CACHE_ALIGN_BUFFER(struct data_rsp_box, rsp,
+sizeof(struct data_rsp_box));
+
+ rsp-ack = ack;
+ rsp-count = count;
+
+ /* should be copy on dma duffer */
+ memcpy(thor_tx_data_buf, rsp, sizeof(struct data_rsp_box));
+ thor_tx_data(thor_tx_data_buf, sizeof(struct data_rsp_box));
+
+ debug(-DATA RSP: %d, %d\n, ack, count);
+}
+
+static int process_rqt_info(const struct rqt_box *rqt)
+{
+ ALLOC_CACHE_ALIGN_BUFFER(struct rsp_box, rsp, sizeof(struct rsp_box));
+ memset(rsp, '\0', sizeof(struct rsp_box));
+
+ rsp-rsp = rqt-rqt;
+ rsp-rsp_data = rqt-rqt_data;
+
+ switch (rqt-rqt_data) {
+ case RQT_INFO_VER_PROTOCOL:
+ rsp-int_data[0] = VER_PROTOCOL_MAJOR;
+ rsp-int_data[1] = VER_PROTOCOL_MINOR;
+ break;
+ case RQT_INIT_VER_HW:
+ snprintf(rsp-str_data[0], sizeof(rsp-str_data[0]),
+%x, checkboard());
+ break;
+ case RQT_INIT_VER_BOOT:
+ sprintf(rsp-str_data[0], %s, U_BOOT_VERSION);
+ break;
+ case RQT_INIT_VER_KERNEL:
+ sprintf(rsp-str_data[0], %s, k unknown);
+ break;
+ case RQT_INIT_VER_PLATFORM:
+ sprintf(rsp-str_data[0], %s, p unknown);
+ break;
+ case RQT_INIT_VER_CSC:
+ sprintf(rsp-str_data[0], %s, c unknown);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ send_rsp(rsp);
+ return true;
+}
+
+static int process_rqt_cmd(const struct rqt_box *rqt)
+{
+ ALLOC_CACHE_ALIGN_BUFFER(struct rsp_box, rsp, sizeof(struct rsp_box));
+ memset(rsp, '\0', sizeof(struct rsp_box));
+
+ rsp-rsp = rqt-rqt;
+ rsp-rsp_data = rqt-rqt_data;
+
+ switch (rqt-rqt_data) {
+ case RQT_CMD_REBOOT:
+
[U-Boot] [PATCH 07/10] usb:g_dnl: Support for TIZEN's THOR function at generic download code
Support of thor function at generic download code (g_dnl.c).
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
Cc: Marek Vasut ma...@denx.de
---
drivers/usb/gadget/g_dnl.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/g_dnl.c b/drivers/usb/gadget/g_dnl.c
index 98560b8..43f413a 100644
--- a/drivers/usb/gadget/g_dnl.c
+++ b/drivers/usb/gadget/g_dnl.c
@@ -16,6 +16,7 @@
#include g_dnl.h
#include usb_mass_storage.h
#include dfu.h
+#include thor.h
#include gadget_chips.h
#include composite.c
@@ -101,6 +102,8 @@ static int g_dnl_do_config(struct usb_configuration *c)
ret = dfu_add(c);
else if (!strcmp(s, usb_dnl_ums))
ret = fsg_add(c);
+ else if (!strcmp(s, usb_dnl_thor))
+ ret = thor_add(c);
return ret;
}
@@ -191,8 +194,8 @@ static struct usb_composite_driver g_dnl_driver = {
int g_dnl_register(const char *type)
{
- /* We only allow dfu atm, so 3 should be enough */
- static char name[sizeof(shortname) + 3];
+ /* The largest function name is 4 */
+ static char name[sizeof(shortname) + 4];
int ret;
if (!strcmp(type, dfu)) {
@@ -201,6 +204,9 @@ int g_dnl_register(const char *type)
} else if (!strcmp(type, ums)) {
strcpy(name, shortname);
strcat(name, type);
+ } else if (!strcmp(type, thor)) {
+ strcpy(name, shortname);
+ strcat(name, type);
} else {
printf(%s: unknown command: %s\n, __func__, type);
return -EINVAL;
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] mx28evk: Use 512k for fdt partition to align it
Using 512k for fdt partition allow it to be aligned with the other small partitions and 512k erase block size. Signed-off-by: Otavio Salvador ota...@ossystems.com.br --- include/configs/mx28evk.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h index 07f88ca..27b1a41 100644 --- a/include/configs/mx28evk.h +++ b/include/configs/mx28evk.h @@ -97,7 +97,7 @@ 512k(environment),\ 512k(redundant-environment), \ 4m(kernel), \ - 128k(fdt),\ + 512k(fdt),\ 8m(ramdisk), \ -(filesystem) #endif -- 1.8.4.rc3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] mtd: Fix size overflow
When using a NAND IC with 4GiB of size, mtdparts go crazy as the 32bit
size variables overview resulting in:
,
| MX28EVK U-Boot mtdparts default
| gpmi-nand: partitioning exceeds flash size
`
Using a 64bit variable fixes the problem.
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
common/cmd_mtdparts.c | 24
include/jffs2/load_kernel.h | 6 +++---
2 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/common/cmd_mtdparts.c b/common/cmd_mtdparts.c
index f791372..9acf41d 100644
--- a/common/cmd_mtdparts.c
+++ b/common/cmd_mtdparts.c
@@ -395,7 +395,7 @@ static int part_validate(struct mtdids *id, struct
part_info *part)
part-size = id-size - part-offset;
if (part-offset id-size) {
- printf(%s: offset %08x beyond flash size %08x\n,
+ printf(%s: offset %08llx beyond flash size %08llx\n,
id-mtd_id, part-offset, id-size);
return 1;
}
@@ -578,8 +578,8 @@ static int part_add(struct mtd_device *dev, struct
part_info *part)
static int part_parse(const char *const partdef, const char **ret, struct
part_info **retpart)
{
struct part_info *part;
- unsigned long size;
- unsigned long offset;
+ u64 size;
+ u64 offset;
const char *name;
int name_len;
unsigned int mask_flags;
@@ -598,7 +598,7 @@ static int part_parse(const char *const partdef, const char
**ret, struct part_i
} else {
size = memsize_parse(p, p);
if (size MIN_PART_SIZE) {
- printf(partition size too small (%lx)\n, size);
+ printf(partition size too small (%llx)\n, size);
return 1;
}
}
@@ -670,14 +670,14 @@ static int part_parse(const char *const partdef, const
char **ret, struct part_i
part-auto_name = 0;
} else {
/* auto generated name in form of size@offset */
- sprintf(part-name, 0x%08lx@0x%08lx, size, offset);
+ sprintf(part-name, 0x%08llx@0x%08llx, size, offset);
part-auto_name = 1;
}
part-name[name_len - 1] = '\0';
INIT_LIST_HEAD(part-link);
- debug(+ partition: name %-22s size 0x%08x offset 0x%08x mask flags
%d\n,
+ debug(+ partition: name %-22s size 0x%08llx offset 0x%08llx mask flags
%d\n,
part-name, part-size,
part-offset, part-mask_flags);
@@ -693,7 +693,7 @@ static int part_parse(const char *const partdef, const char
**ret, struct part_i
* @param size a pointer to the size of the mtd device (output)
* @return 0 if device is valid, 1 otherwise
*/
-static int mtd_device_validate(u8 type, u8 num, u32 *size)
+static int mtd_device_validate(u8 type, u8 num, u64 *size)
{
struct mtd_info *mtd = NULL;
@@ -1270,7 +1270,7 @@ static void print_partition_table(void)
list_for_each(pentry, dev-parts) {
part = list_entry(pentry, struct part_info, link);
- printf(%2d: %-20s0x%08x\t0x%08x\t%d\n,
+ printf(%2d: %-20s0x%08llx\t0x%08llx\t%d\n,
part_num, part-name, part-size,
part-offset, part-mask_flags);
#endif /* defined(CONFIG_CMD_MTDPARTS_SHOW_NET_SIZES) */
@@ -1297,7 +1297,7 @@ static void list_partitions(void)
if (current_mtd_dev) {
part = mtd_part_info(current_mtd_dev, current_mtd_partnum);
if (part) {
- printf(\nactive partition: %s%d,%d - (%s) 0x%08x @
0x%08x\n,
+ printf(\nactive partition: %s%d,%d - (%s) 0x%08llx @
0x%08llx\n,
MTD_DEV_TYPE(current_mtd_dev-id-type),
current_mtd_dev-id-num,
current_mtd_partnum,
part-name, part-size, part-offset);
@@ -1397,7 +1397,7 @@ static int delete_partition(const char *id)
if (find_dev_and_part(id, dev, pnum, part) == 0) {
- debug(delete_partition: device = %s%d, partition %d = (%s)
0x%08x@0x%08x\n,
+ debug(delete_partition: device = %s%d, partition %d = (%s)
0x%08llx@0x%08llx\n,
MTD_DEV_TYPE(dev-id-type), dev-id-num, pnum,
part-name, part-size, part-offset);
@@ -1589,7 +1589,7 @@ static int parse_mtdids(const char *const ids)
struct list_head *entry, *n;
struct mtdids *id_tmp;
u8 type, num;
- u32 size;
+ u64 size;
int ret = 1;
debug(\n---parse_mtdids---\nmtdids = %s\n\n, ids);
@@ -1663,7 +1663,7 @@ static int parse_mtdids(const char *const ids)
id-mtd_id[mtd_id_len - 1] = '\0';
INIT_LIST_HEAD(id-link);
-
[U-Boot] [PATCH 7/9][v2] net: tsec: Use portable types and accessors for BDs
Currently, the buffer descriptor (BD) fields cannot be
correctly accessed by a little endian processor. This
patch fixes the issue by making the access of BDs to be
portable among different cpu architectures.
Use portable data types for the Rx/Tx buffer descriptor
fields. Use portable I/O accessors to insure that the
big endian BDs are correctly accessed by little endian
cpus too, and to insure proper sync with the H/W.
Removed the redundant RTXBD volatile type, as proper
synchronization around BD data accesses is provided by
the I/O accessors now.
The sparse tool was also used to verify the correctness
of these changes.
Cc: Scott Wood scottw...@freescale.com
Signed-off-by: Claudiu Manoil claudiu.man...@freescale.com
---
v2:
* used portable I/O accessors (in_be/out_be)
* replaced macro usage
* retested on p1020 (ping, tftp)
drivers/net/tsec.c | 108 -
include/tsec.h | 22 +--
2 files changed, 76 insertions(+), 54 deletions(-)
diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c
index 289229a..b48e595 100644
--- a/drivers/net/tsec.c
+++ b/drivers/net/tsec.c
@@ -28,13 +28,30 @@ DECLARE_GLOBAL_DATA_PTR;
static uint rx_idx;/* index of the current RX buffer */
static uint tx_idx;/* index of the current TX buffer */
-typedef volatile struct rtxbd {
- txbd8_t txbd[TX_BUF_CNT];
- rxbd8_t rxbd[PKTBUFSRX];
-} RTXBD;
-
#ifdef __GNUC__
-static RTXBD rtx __attribute__ ((aligned(8)));
+static struct txbd8 txbd[TX_BUF_CNT] __aligned(8);
+static struct rxbd8 rxbd[PKTBUFSRX] __aligned(8);
+
+static inline u16 read_txbd_stat(uint idx)
+{
+ return in_be16((u16 __iomem *)txbd[idx].status);
+}
+
+static inline void write_txbd_stat(uint idx, u16 status)
+{
+ out_be16((u16 __iomem *)txbd[idx].status, status);
+}
+
+static inline u16 read_rxbd_stat(uint idx)
+{
+ return in_be16((u16 __iomem *)rxbd[idx].status);
+}
+
+static inline void write_rxbd_stat(uint idx, u16 status)
+{
+ out_be16((u16 __iomem *)rxbd[idx].status, status);
+}
+
#else
#error rtx must be 64-bit aligned
#endif
@@ -275,10 +292,11 @@ void redundant_init(struct eth_device *dev)
clrbits_be32(regs-dmactrl, DMACTRL_GRS | DMACTRL_GTS);
do {
+ uint16_t status;
tsec_send(dev, (void *)pkt, sizeof(pkt));
/* Wait for buffer to be received */
- for (t = 0; rtx.rxbd[rx_idx].status RXBD_EMPTY; t++) {
+ for (t = 0; read_rxbd_stat(rx_idx) RXBD_EMPTY; t++) {
if (t = 10 * TOUT_LOOP) {
printf(%s: tsec: rx error\n, dev-name);
break;
@@ -288,9 +306,11 @@ void redundant_init(struct eth_device *dev)
if (!memcmp(pkt, (void *)NetRxPackets[rx_idx], sizeof(pkt)))
fail = 0;
- rtx.rxbd[rx_idx].length = 0;
- rtx.rxbd[rx_idx].status =
- RXBD_EMPTY | (((rx_idx + 1) == PKTBUFSRX) ? RXBD_WRAP : 0);
+ out_be16((u16 __iomem *)rxbd[rx_idx].length, 0);
+ status = RXBD_EMPTY;
+ if ((rx_idx + 1) == PKTBUFSRX)
+ status |= RXBD_WRAP;
+ write_rxbd_stat(rx_idx, status);
rx_idx = (rx_idx + 1) % PKTBUFSRX;
if (in_be32(regs-ievent) IEVENT_BSY) {
@@ -319,9 +339,10 @@ void redundant_init(struct eth_device *dev)
*/
static void startup_tsec(struct eth_device *dev)
{
- int i;
struct tsec_private *priv = (struct tsec_private *)dev-priv;
struct tsec __iomem *regs = priv-regs;
+ uint16_t status;
+ int i;
/* reset the indices to zero */
rx_idx = 0;
@@ -331,24 +352,26 @@ static void startup_tsec(struct eth_device *dev)
#endif
/* Point to the buffer descriptors */
- out_be32(regs-tbase, (unsigned int)(rtx.txbd[tx_idx]));
- out_be32(regs-rbase, (unsigned int)(rtx.rxbd[rx_idx]));
+ out_be32(regs-tbase, (u32)txbd[0]);
+ out_be32(regs-rbase, (u32)rxbd[0]);
/* Initialize the Rx Buffer descriptors */
for (i = 0; i PKTBUFSRX; i++) {
- rtx.rxbd[i].status = RXBD_EMPTY;
- rtx.rxbd[i].length = 0;
- rtx.rxbd[i].bufptr = (uint) NetRxPackets[i];
+ write_rxbd_stat(i, RXBD_EMPTY);
+ out_be16((u16 __iomem *)rxbd[i].length, 0);
+ out_be32((u32 __iomem *)rxbd[i].bufptr, (u32)NetRxPackets[i]);
}
- rtx.rxbd[PKTBUFSRX - 1].status |= RXBD_WRAP;
+ status = read_rxbd_stat(PKTBUFSRX - 1);
+ write_rxbd_stat(PKTBUFSRX - 1, status | RXBD_WRAP);
/* Initialize the TX Buffer Descriptors */
for (i = 0; i TX_BUF_CNT; i++) {
- rtx.txbd[i].status = 0;
- rtx.txbd[i].length = 0;
- rtx.txbd[i].bufptr = 0;
+ write_txbd_stat(i, 0);
+
[U-Boot] [PATCH 1/3 v2] exynos: i2c: Fix i2c driver to handle NACKs properly
The Exynos5 i2c driver does not handle NACKs properly. This change:
- fixes the NACK processing problem (do not continue transaction if
address cycle was NACKed)
- eliminates a fair amount of duplicate code
Signed-off-by: Vadim Bendebury vben...@chromium.org
Reviewed-by: Simon Glass s...@google.com
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
---
Changes since v1:
1. Removed the compilation error mentioned by Heiko for VCMA9 board...
drivers/i2c/s3c24x0_i2c.c | 214 +++--
1 file changed, 90 insertions(+), 124 deletions(-)
diff --git a/drivers/i2c/s3c24x0_i2c.c b/drivers/i2c/s3c24x0_i2c.c
index cd09c78..c65360d 100644
--- a/drivers/i2c/s3c24x0_i2c.c
+++ b/drivers/i2c/s3c24x0_i2c.c
@@ -43,7 +43,7 @@
#define I2C_START_STOP 0x20/* START / STOP */
#define I2C_TXRX_ENA 0x10/* I2C Tx/Rx enable */
-#define I2C_TIMEOUT 1 /* 1 second */
+#define I2C_TIMEOUT_MS 1000/* 1 second */
/*
@@ -84,22 +84,26 @@ static void SetI2CSCL(int x)
}
#endif
+/*
+ * Wait til the byte transfer is completed.
+ *
+ * @param i2c- pointer to the appropriate i2c register bank.
+ * @return I2C_OK, if transmission was ACKED
+ * I2C_NACK, if transmission was NACKED
+ * I2C_NOK_TIMEOUT, if transaction did not complete in I2C_TIMEOUT_MS
+ */
+
static int WaitForXfer(struct s3c24x0_i2c *i2c)
{
- int i;
+ ulong start_time = get_timer(0);
- i = I2C_TIMEOUT * 1;
- while (!(readl(i2c-iiccon) I2CCON_IRPND) (i 0)) {
- udelay(100);
- i--;
- }
+ do {
+ if (readl(i2c-iiccon) I2CCON_IRPND)
+ return (readl(i2c-iicstat) I2CSTAT_NACK) ?
+ I2C_NACK : I2C_OK;
+ } while (get_timer(start_time) I2C_TIMEOUT_MS);
- return (readl(i2c-iiccon) I2CCON_IRPND) ? I2C_OK : I2C_NOK_TOUT;
-}
-
-static int IsACK(struct s3c24x0_i2c *i2c)
-{
- return !(readl(i2c-iicstat) I2CSTAT_NACK);
+ return I2C_NOK_TOUT;
}
static void ReadWriteByte(struct s3c24x0_i2c *i2c)
@@ -180,21 +184,27 @@ unsigned int i2c_get_bus_num(void)
void i2c_init(int speed, int slaveadd)
{
+ int i;
struct s3c24x0_i2c *i2c;
#if !(defined CONFIG_EXYNOS4 || defined CONFIG_EXYNOS5)
struct s3c24x0_gpio *gpio = s3c24x0_get_base_gpio();
#endif
- int i;
+ ulong start_time = get_timer(0);
/* By default i2c channel 0 is the current bus */
g_current_bus = 0;
i2c = get_base_i2c();
- /* wait for some time to give previous transfer a chance to finish */
- i = I2C_TIMEOUT * 1000;
- while ((readl(i2c-iicstat) I2CSTAT_BSY) (i 0)) {
- udelay(1000);
- i--;
+ /*
+* In case the previous transfer is still going, wait to give it a
+* chance to finish.
+*/
+ while (readl(i2c-iicstat) I2CSTAT_BSY) {
+ if (get_timer(start_time) I2C_TIMEOUT_MS) {
+ printf(%s: I2C bus busy for %p\n, __func__,
+ i2c-iicstat);
+ return;
+ }
}
#if !(defined CONFIG_EXYNOS4 || defined CONFIG_EXYNOS5)
@@ -260,7 +270,8 @@ static int i2c_transfer(struct s3c24x0_i2c *i2c,
unsigned char data[],
unsigned short data_len)
{
- int i, result;
+ int i = 0, result;
+ ulong start_time = get_timer(0);
if (data == 0 || data_len == 0) {
/*Don't support data transfer of no length or to address 0 */
@@ -268,128 +279,78 @@ static int i2c_transfer(struct s3c24x0_i2c *i2c,
return I2C_NOK;
}
- /* Check I2C bus idle */
- i = I2C_TIMEOUT * 1000;
- while ((readl(i2c-iicstat) I2CSTAT_BSY) (i 0)) {
- udelay(1000);
- i--;
+ while (readl(i2c-iicstat) I2CSTAT_BSY) {
+ if (get_timer(start_time) I2C_TIMEOUT_MS)
+ return I2C_NOK_TOUT;
}
- if (readl(i2c-iicstat) I2CSTAT_BSY)
- return I2C_NOK_TOUT;
-
writel(readl(i2c-iiccon) | I2CCON_ACKGEN, i2c-iiccon);
- result = I2C_OK;
- switch (cmd_type) {
- case I2C_WRITE:
- if (addr addr_len) {
- writel(chip, i2c-iicds);
- /* send START */
- writel(I2C_MODE_MT | I2C_TXRX_ENA | I2C_START_STOP,
- i2c-iicstat);
- i = 0;
- while ((i addr_len) (result == I2C_OK)) {
- result = WaitForXfer(i2c);
- writel(addr[i], i2c-iicds);
- ReadWriteByte(i2c);
- i++;
- }
- i = 0;
- while ((i data_len) (result ==
[U-Boot] [PATCH 2/3 v2] exynos: i2c: Change FDT bus setup code to enumerate ports correctly
From: Simon Glass s...@chromium.org
At present the i2c ports are enumerated in a strange way - the
fdtdec_find_aliases_for_id() function is used, but then the ID returned
is ignored and the ports are renumbered. The effect is the same provided
that the device tree has the ports in the same order, or uses aliases,
and has no gaps, but it is not correct.
Adjust the code to use the function as intended. This will allows device
tree aliases to change the device order if required.
As a result, the i2c_busses variable is dropped. We can't be sure that
there are no 'holes' in the list of buses, so must check the whole
array.
Note: it seems that non-FDT operation is now broken in this drive and
will need to be reinstated for upstream.
Signed-off-by: Simon Glass s...@chromium.org
Reviewed-on: https://gerrit.chromium.org/gerrit/59369
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
---
drivers/i2c/s3c24x0_i2c.c | 25 ++---
drivers/i2c/s3c24x0_i2c.h |1 +
2 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/s3c24x0_i2c.c b/drivers/i2c/s3c24x0_i2c.c
index c65360d..0e6f241 100644
--- a/drivers/i2c/s3c24x0_i2c.c
+++ b/drivers/i2c/s3c24x0_i2c.c
@@ -52,7 +52,6 @@
*/
static unsigned int g_current_bus __attribute__((section(.data)));
#ifdef CONFIG_OF_CONTROL
-static int i2c_busses __attribute__((section(.data)));
static struct s3c24x0_i2c_bus i2c_bus[CONFIG_MAX_I2C_NUM]
__attribute__((section(.data)));
#endif
@@ -164,8 +163,8 @@ int i2c_set_bus_num(unsigned int bus)
{
struct s3c24x0_i2c *i2c;
- if ((bus 0) || (bus = CONFIG_MAX_I2C_NUM)) {
- debug(Bad bus: %d\n, bus);
+ i2c_bus = get_bus(bus);
+ if (!i2c_bus)
return -1;
}
@@ -483,19 +482,31 @@ void board_i2c_init(const void *blob)
if (node = 0)
continue;
bus = i2c_bus[i];
+ bus-active = true;
bus-regs = (struct s3c24x0_i2c *)
fdtdec_get_addr(blob, node, reg);
bus-id = pinmux_decode_periph_id(blob, node);
bus-node = node;
- bus-bus_num = i2c_busses++;
+ bus-bus_num = i;
exynos_pinmux_config(bus-id, 0);
}
}
+/**
+ * Get a pointer to the given bus index
+ *
+ * @bus_idx: Bus index to look up
+ * @return pointer to bus, or NULL if invalid or not available
+ */
static struct s3c24x0_i2c_bus *get_bus(unsigned int bus_idx)
{
- if (bus_idx i2c_busses)
- return i2c_bus[bus_idx];
+ if (bus_idx ARRAY_SIZE(i2c_bus)) {
+ struct s3c24x0_i2c_bus *bus;
+
+ bus = i2c_bus[bus_idx];
+ if (bus-active)
+ return bus;
+ }
debug(Undefined bus: %d\n, bus_idx);
return NULL;
@@ -505,7 +516,7 @@ int i2c_get_bus_num_fdt(int node)
{
int i;
- for (i = 0; i i2c_busses; i++) {
+ for (i = 0; i ARRAY_SIZE(i2c_bus); i++) {
if (node == i2c_bus[i].node)
return i;
}
diff --git a/drivers/i2c/s3c24x0_i2c.h b/drivers/i2c/s3c24x0_i2c.h
index b4a337a..882af62 100644
--- a/drivers/i2c/s3c24x0_i2c.h
+++ b/drivers/i2c/s3c24x0_i2c.h
@@ -16,6 +16,7 @@ struct s3c24x0_i2c {
};
struct s3c24x0_i2c_bus {
+ bool active;/* port is active and available */
int node; /* device tree node */
int bus_num;/* i2c bus number */
struct s3c24x0_i2c *regs;
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3 v2]: i2c: s3c24xx: add hsi2c controller support
Add support for hsi2c controller available on exynos5420.
Note: driver currently supports only fast speed mode 100kbps
Change-Id: I02555b1dc8f4ac21c50aa5158179768563c92f43
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Signed-off-by: R. Chandrasekar rc.se...@samsung.com
---
drivers/i2c/s3c24x0_i2c.c | 617 +
drivers/i2c/s3c24x0_i2c.h | 37 +++
2 files changed, 604 insertions(+), 50 deletions(-)
diff --git a/drivers/i2c/s3c24x0_i2c.c b/drivers/i2c/s3c24x0_i2c.c
index 0e6f241..b2b0eef 100644
--- a/drivers/i2c/s3c24x0_i2c.c
+++ b/drivers/i2c/s3c24x0_i2c.c
@@ -34,6 +34,76 @@
#define I2C_NOK_LA 3 /* Lost arbitration */
#define I2C_NOK_TOUT 4 /* time out */
+/* HSI2C specific register description */
+
+/* I2C_CTL Register bits */
+#define HSI2C_FUNC_MODE_I2C(1u 0)
+#define HSI2C_MASTER (1u 3)
+#define HSI2C_RXCHON (1u 6) /* Write/Send */
+#define HSI2C_TXCHON (1u 7) /* Read/Receive */
+#define HSI2C_SW_RST (1u 31)
+
+/* I2C_FIFO_CTL Register bits */
+#define HSI2C_RXFIFO_EN(1u 0)
+#define HSI2C_TXFIFO_EN(1u 1)
+#define HSI2C_TXFIFO_TRIGGER_LEVEL (0x20 16)
+#define HSI2C_RXFIFO_TRIGGER_LEVEL (0x20 4)
+
+/* I2C_TRAILING_CTL Register bits */
+#define HSI2C_TRAILING_COUNT (0xff)
+
+/* I2C_INT_EN Register bits */
+#define HSI2C_TX_UNDERRUN_EN (1u 2)
+#define HSI2C_TX_OVERRUN_EN(1u 3)
+#define HSI2C_RX_UNDERRUN_EN (1u 4)
+#define HSI2C_RX_OVERRUN_EN(1u 5)
+#define HSI2C_INT_TRAILING_EN (1u 6)
+#define HSI2C_INT_I2C_EN (1u 9)
+
+#define HSI2C_INT_ERROR_MASK (HSI2C_TX_UNDERRUN_EN |\
+HSI2C_TX_OVERRUN_EN |\
+HSI2C_RX_UNDERRUN_EN |\
+HSI2C_RX_OVERRUN_EN |\
+HSI2C_INT_TRAILING_EN)
+
+/* I2C_CONF Register bits */
+#define HSI2C_AUTO_MODE(1u 31)
+#define HSI2C_10BIT_ADDR_MODE (1u 30)
+#define HSI2C_HS_MODE (1u 29)
+
+/* I2C_AUTO_CONF Register bits */
+#define HSI2C_READ_WRITE (1u 16)
+#define HSI2C_STOP_AFTER_TRANS (1u 17)
+#define HSI2C_MASTER_RUN (1u 31)
+
+/* I2C_TIMEOUT Register bits */
+#define HSI2C_TIMEOUT_EN (1u 31)
+
+/* I2C_TRANS_STATUS register bits */
+#define HSI2C_MASTER_BUSY (1u 17)
+#define HSI2C_SLAVE_BUSY (1u 16)
+#define HSI2C_TIMEOUT_AUTO (1u 4)
+#define HSI2C_NO_DEV (1u 3)
+#define HSI2C_NO_DEV_ACK (1u 2)
+#define HSI2C_TRANS_ABORT (1u 1)
+#define HSI2C_TRANS_SUCCESS(1u 0)
+#define HSI2C_TRANS_ERROR_MASK (HSI2C_TIMEOUT_AUTO |\
+HSI2C_NO_DEV | HSI2C_NO_DEV_ACK |\
+HSI2C_TRANS_ABORT)
+#define HSI2C_TRANS_FINISHED_MASK (HSI2C_TRANS_ERROR_MASK |
HSI2C_TRANS_SUCCESS)
+
+
+/* I2C_FIFO_STAT Register bits */
+#define HSI2C_RX_FIFO_EMPTY(1u 24)
+#define HSI2C_RX_FIFO_FULL (1u 23)
+#define HSI2C_TX_FIFO_EMPTY(1u 8)
+#define HSI2C_TX_FIFO_FULL (1u 7)
+#define HSI2C_RX_FIFO_LEVEL(x) (((x) 16) 0x7f)
+#define HSI2C_TX_FIFO_LEVEL(x) ((x) 0x7f)
+
+#define HSI2C_SLV_ADDR_MAS(x) ((x 0x3ff) 10)
+
+/* S3C I2C Controller bits */
#define I2CSTAT_BSY0x20/* Busy bit */
#define I2CSTAT_NACK 0x01/* Nack bit */
#define I2CCON_ACKGEN 0x80/* Acknowledge generation */
@@ -45,16 +115,35 @@
#define I2C_TIMEOUT_MS 1000/* 1 second */
+#defineHSI2C_TIMEOUT_US 10 /* 100 ms, finer granularity */
/*
* For SPL boot some boards need i2c before SDRAM is initialised so force
* variables to live in SRAM
*/
static unsigned int g_current_bus __attribute__((section(.data)));
-#ifdef CONFIG_OF_CONTROL
static struct s3c24x0_i2c_bus i2c_bus[CONFIG_MAX_I2C_NUM]
__attribute__((section(.data)));
-#endif
+
+/**
+ * Get a pointer to the given bus index
+ *
+ * @bus_idx: Bus index to look up
+ * @return pointer to bus, or NULL if invalid or not available
+ */
+static struct s3c24x0_i2c_bus *get_bus(unsigned int bus_idx)
+{
+ if (bus_idx ARRAY_SIZE(i2c_bus)) {
+ struct s3c24x0_i2c_bus *bus;
+
+ bus = i2c_bus[bus_idx];
+ if (bus-active)
+ return bus;
+ }
+
+ debug(Undefined bus: %d\n, bus_idx);
+ return NULL;
+}
#if !(defined CONFIG_EXYNOS4 || defined CONFIG_EXYNOS5)
static int GetI2CSDA(void)
@@ -105,6 +194,55 @@ static int WaitForXfer(struct s3c24x0_i2c *i2c)
return I2C_NOK_TOUT;
}
+/*
+ * Wait for transfer completion.
+ *
+ * This function reads the interrupt
Re: [U-Boot] [PATCH 1/2] Armada100: Adds SD/MMC Register definitions
- Pantelis Antoniou pa...@antoniou-consulting.com wrote: Hi Ajay, On Sep 24, 2013, at 11:02 AM, Ajay Bhargav wrote: This patch add SD/MMC interface register difinitions for Armada100 series. Signed-off-by: Ajay Bhargav ajay.bhar...@einfochips.com --- arch/arm/include/asm/arch-armada100/armada100.h | 10 ++ 1 file changed, 10 insertions(+) diff --git a/arch/arm/include/asm/arch-armada100/armada100.h b/arch/arm/include/asm/arch-armada100/armada100.h index d9feb16..81e4b8a 100644 --- a/arch/arm/include/asm/arch-armada100/armada100.h +++ b/arch/arm/include/asm/arch-armada100/armada100.h @@ -27,6 +27,14 @@ #define SSP2_APBCLK 0x01 #define SSP2_FNCLK 0x02 +/* SD Clock/Reset Control Register Bit definition */ +#define SD1_SD2_AXI_RESET 0x01 +#define SD1_RESET 0x02 +#define SD1_SD2_AXICLK_EN 0x08 +#define SD1_CLK_EN 0x10 +#define SD2_RESET 0x02 +#define SD2_CLK_EN 0x10 + /* USB Clock/reset control bits */ #define USB_SPH_AXICLK_EN 0x10 #define USB_SPH_AXI_RST 0x02 @@ -53,6 +61,8 @@ #define ARMD1_UART3_BASE0xD4026000 #define ARMD1_MPMU_BASE 0xD405 #define ARMD1_USB_HOST_BASE 0xD4209000 +#define ARMD1_SD1_BASE 0xD428 +#define ARMD1_SD2_BASE 0xD4281000 #define ARMD1_APMU_BASE 0xD4282800 #define ARMD1_CPU_BASE 0xD4282C00 -- 1.8.3.rc3 Looks fine. Acked-by: Pantelis Antoniou pa...@antoniou-consulting.com Hi Pantelis, May I know, when are you going to update u-boot-mmc custodian? Regards, Ajay Bhargav - Notice: This message has been scanned by Trend Micro Mail Security scanner and is believed to be clean - ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] imx: Easy enabling of SION per-pin using MUX_MODE_SION helper macro
Hi Otavio, On Thursday, October 3, 2013 1:46:00 PM, Otavio Salvador wrote: The macro allows easy setting in per-pin, as for example: , | imx_iomux_v3_setup_pad(MX6_PAD_NANDF_D1__GPIO_2_1 | MUX_MODE_SION); ` The IOMUX_CONFIG_SION allows for reading PAD value from PSR register. The following quote from the datasheet: , | ... | 28.4.2.2 GPIO Write Mode | The programming sequence for driving output signals should be as follows: | 1. Configure IOMUX to select GPIO mode (Via IOMUXC), also enable SION if | need | to read loopback pad value through PSR | 2. Configure GPIO direction register to output (GPIO_GDIR[GDIR] set to 1b). | 3. Write value to data register (GPIO_DR). | ... ` This fixes the gpio_get_value to properly work when a GPIO is set for output and has no conflicts. Thanks for Benoît Thébaudeau benoit.thebaud...@advansee.com, Fabio Estevam fabio.este...@freescale.com and Eric Bénard e...@eukrea.com for helping to properly trace this down. Signed-off-by: Otavio Salvador ota...@ossystems.com.br --- arch/arm/include/asm/imx-common/iomux-v3.h | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/include/asm/imx-common/iomux-v3.h b/arch/arm/include/asm/imx-common/iomux-v3.h index dc2b3ef..b7bdaa5 100644 --- a/arch/arm/include/asm/imx-common/iomux-v3.h +++ b/arch/arm/include/asm/imx-common/iomux-v3.h @@ -57,6 +57,7 @@ typedef u64 iomux_v3_cfg_t; MUX_SEL_INPUT_OFS_SHIFT) #define MUX_MODE_SHIFT 36 +#define MUX_MODE_SION((iomux_v3_cfg_t)IOMUX_CONFIG_SION MUX_MODE_SHIFT) #define MUX_MODE_MASK((iomux_v3_cfg_t)0x1f MUX_MODE_SHIFT) #define MUX_PAD_CTRL_SHIFT 41 #define MUX_PAD_CTRL_MASK((iomux_v3_cfg_t)0x3 MUX_PAD_CTRL_SHIFT) Looks good. Just some nit picking: - The line seems to be longer that the max allowed 80 chars. - You could perhaps move this definition to the line right above #define MUX_PAD_CTRL(x) so that macros for configuration options are grouped together. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] imx: Easy enabling of SION per-pin using MUX_MODE_SION helper macro
On Thu, Oct 3, 2013 at 9:43 AM, Benoît Thébaudeau benoit.thebaud...@advansee.com wrote: Hi Otavio, On Thursday, October 3, 2013 1:46:00 PM, Otavio Salvador wrote: The macro allows easy setting in per-pin, as for example: , | imx_iomux_v3_setup_pad(MX6_PAD_NANDF_D1__GPIO_2_1 | MUX_MODE_SION); ` The IOMUX_CONFIG_SION allows for reading PAD value from PSR register. The following quote from the datasheet: , | ... | 28.4.2.2 GPIO Write Mode | The programming sequence for driving output signals should be as follows: | 1. Configure IOMUX to select GPIO mode (Via IOMUXC), also enable SION if | need | to read loopback pad value through PSR | 2. Configure GPIO direction register to output (GPIO_GDIR[GDIR] set to 1b). | 3. Write value to data register (GPIO_DR). | ... ` This fixes the gpio_get_value to properly work when a GPIO is set for output and has no conflicts. Thanks for Benoît Thébaudeau benoit.thebaud...@advansee.com, Fabio Estevam fabio.este...@freescale.com and Eric Bénard e...@eukrea.com for helping to properly trace this down. Signed-off-by: Otavio Salvador ota...@ossystems.com.br --- arch/arm/include/asm/imx-common/iomux-v3.h | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/include/asm/imx-common/iomux-v3.h b/arch/arm/include/asm/imx-common/iomux-v3.h index dc2b3ef..b7bdaa5 100644 --- a/arch/arm/include/asm/imx-common/iomux-v3.h +++ b/arch/arm/include/asm/imx-common/iomux-v3.h @@ -57,6 +57,7 @@ typedef u64 iomux_v3_cfg_t; MUX_SEL_INPUT_OFS_SHIFT) #define MUX_MODE_SHIFT 36 +#define MUX_MODE_SION((iomux_v3_cfg_t)IOMUX_CONFIG_SION MUX_MODE_SHIFT) #define MUX_MODE_MASK((iomux_v3_cfg_t)0x1f MUX_MODE_SHIFT) #define MUX_PAD_CTRL_SHIFT 41 #define MUX_PAD_CTRL_MASK((iomux_v3_cfg_t)0x3 MUX_PAD_CTRL_SHIFT) Looks good. Just some nit picking: - The line seems to be longer that the max allowed 80 chars. Splitting it looks so ugly! - You could perhaps move this definition to the line right above #define MUX_PAD_CTRL(x) so that macros for configuration options are grouped together. Ok. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/9] net: tsec: Use portable types and accessors for BDs
On 10/3/2013 1:15 AM, Scott Wood wrote: [snip] Yeah, it doesn't help when both types of accesses show up when searching for the ring, and accessors exist with both possible argument orderings. Especially when a driver has custom accessors. It's OK to use explicit synchronization rather than I/O accessors, if you're careful to ensure that it's correct. It looks like drivers/net/fec_mxc.c in U-Boot is an example that uses I/O accessors on ring data, e.g.: writew(length, fec-tbd_base[fec-tbd_index].data_length); Hi Scott, I sent a v2 for this patch (the next 2 patches in the series are not affected by this one): http://patchwork.ozlabs.org/patch/280285/ In this version I dropped the macro usage and used I/O accessors for the ring data, as discussed. This approach does not require the explicit __beNN type for the BD fields, it also removes the need to declare the BD structures as volatile and it's safer because in_be()/ out_be() enforce HW sync. Thanks, Claudiu ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] RFC: exynos: Disable the display controller when starting Linux
Hi, On Thu, Oct 3, 2013 at 3:24 AM, Ajay kumar ajayn...@gmail.com wrote: +Simon Glass On Thu, Oct 3, 2013 at 2:25 PM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Ajay, On Thu, 03 Oct 2013 14:34:20 +0530, Ajay Kumar ajaykumar...@samsung.com wrote: If the exynos display controller is still active when Linux starts, then it will result in a kernel panic while FIMD sysmmu driver is getting probed. Calling exynos_fimd_lcd_disable() before jumping into kernel disables the display controller by switching off the windows, hence resolving the kernel panic which arises from sysmmu driver. Create an Exynos specific definition for the weak function arch_cleanup_before_linux(), and then place the call to exynos_fimd_lcd_disable() inside the overrided definition of arch_cleanup_before_linux(). Signed-off-by: Ajay Kumar ajaykumar...@samsung.com Signed-off-by: Simon Glass s...@chromium.org --- Why should the fix to this situation be making U-Boot disable the display controller rather than making Linux able to cope with an already active display controller? Besides, fixing Linux would allow seamless booting displays, without an ugly off-on glitch. Yes, I believe this bug was fixed in Linux - Ajay do you know? Perhaps the fix has not been upstreamed yet? Regards, Simon Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] RFC: arm: add call to cleanup things before jumping into kernel
Hi Albert, On Thu, Oct 3, 2013 at 2:58 AM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Ajay, On Thu, 03 Oct 2013 14:34:19 +0530, Ajay Kumar ajaykumar...@samsung.com wrote: Add infrasturcture to cleanup any of those architecture related settings done for u-boot, if they can cause problem during kernel boot. Signed-off-by: Ajay Kumar ajaykumar...@samsung.com --- Regardless to ma question re fixing the issue in U-Boot or Linux: does something prevent using the already existing cleanup_before_linux() function, and if not, what made you choose to create another one instead? That function is in generic ARM code - I think the intent here is to add something SoC-specific. Perhaps it should be board-specific? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] sf: probe: Add support for EN25S64
From: Priyanka Jain priyanka.j...@freescale.com
Add support for EON EN25S64 SPI flash.
Signed-off-by: Priyanka Jain priyanka.j...@freescale.com
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
Changes for v2:
- Updated as per new probe code
drivers/mtd/spi/sf_probe.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c
index 8f56c63..1525636 100644
--- a/drivers/mtd/spi/sf_probe.c
+++ b/drivers/mtd/spi/sf_probe.c
@@ -51,6 +51,7 @@ static const struct spi_flash_params spi_flash_params_table[]
= {
{EN25Q32B, 0x1c3016, 0x0, 64 * 1024,64,
0},
{EN25Q64,0x1c3017, 0x0, 64 * 1024, 128,
SECT_4K},
{EN25Q128B, 0x1c3018, 0x0, 64 * 1024, 256,
0},
+ {EN25S64,0x1c3817, 0x0, 64 * 1024, 128,
0},
#endif
#ifdef CONFIG_SPI_FLASH_GIGADEVICE /* GIGADEVICE */
{GD25Q64B, 0xc84017, 0x0, 64 * 1024, 128,
SECT_4K},
--
1.8.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] sf: probe: Add support for EN25S64
Hi,
Can you test this patch on u-boot-spi.git with master-probe branch.
On Thu, Oct 3, 2013 at 9:11 PM, Jagannadha Sutradharudu Teki
jagannadha.sutradharudu-t...@xilinx.com wrote:
From: Priyanka Jain priyanka.j...@freescale.com
Add support for EON EN25S64 SPI flash.
Signed-off-by: Priyanka Jain priyanka.j...@freescale.com
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
Changes for v2:
- Updated as per new probe code
drivers/mtd/spi/sf_probe.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c
index 8f56c63..1525636 100644
--- a/drivers/mtd/spi/sf_probe.c
+++ b/drivers/mtd/spi/sf_probe.c
@@ -51,6 +51,7 @@ static const struct spi_flash_params
spi_flash_params_table[] = {
{EN25Q32B, 0x1c3016, 0x0, 64 * 1024,64,
0},
{EN25Q64,0x1c3017, 0x0, 64 * 1024, 128,
SECT_4K},
{EN25Q128B, 0x1c3018, 0x0, 64 * 1024, 256,
0},
+ {EN25S64,0x1c3817, 0x0, 64 * 1024, 128,
0},
#endif
#ifdef CONFIG_SPI_FLASH_GIGADEVICE /* GIGADEVICE */
{GD25Q64B, 0xc84017, 0x0, 64 * 1024, 128,
SECT_4K},
--
1.8.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
--
Thanks,
Jagan.
Jagannadha Sutradharudu Teki,
E: jagannadh.t...@gmail.com, P: +91-9676773388
Engineer - System Software Hacker
U-boot - SPI Custodian and Zynq APSOC
Ln: http://www.linkedin.com/in/jaganteki
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] RFC: arm: add call to cleanup things before jumping into kernel
Hi Ajay, On Thu, 3 Oct 2013 14:49:49 +0530, Ajay kumar ajayn...@gmail.com wrote: Hi Albert, On Thu, Oct 3, 2013 at 2:28 PM, Albert ARIBAUD albert.u.b...@aribaud.netwrote: Hi Ajay, On Thu, 03 Oct 2013 14:34:19 +0530, Ajay Kumar ajaykumar...@samsung.com wrote: Add infrasturcture to cleanup any of those architecture related settings done for u-boot, if they can cause problem during kernel boot. Signed-off-by: Ajay Kumar ajaykumar...@samsung.com --- Regardless to ma question re fixing the issue in U-Boot or Linux: does something prevent using the already existing cleanup_before_linux() function, and if not, what made you choose to create another one instead? (fixed quote glitch here that put the start of your reply inside mine.) cleanup_before_linux() generally cleans up things specific to the processor. I thought of introducing a cleanup function which would allow us to cleanup things which are SOC specific(all SOC under armv7 as per the patch). And, used the same function to cleanup some exynos specific stuff before booting linux. May be, I should have used a different name instead of arch_cleanup_before_linux? Well, if it is *SoC* specific, then it is not *arch* specific, so yes, the name should be changed. Now, we don't really have a concept of 'SoC-specific' in U-Boot, so board-specific, as suggested by Simon, is the 'next not-too-worst thing'. Still, don't rush to provide a new patch. According to Simon, the Linux panic was solved and might just not have hit mainline yet; if that is confirmed, then renaming arch_cleanup_before_linux() becomes moot. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Uboot][PATCH] drivers: spi: macronix: Add MX66L51235L data
Hi Sourav,
Can you test this macronix part w.r.t latest code base on
u-boot-spi.git with master-probe branch.
Please let me know about any issues/concerns.
On Tue, Aug 27, 2013 at 2:48 PM, Jagan Teki jagannadh.t...@gmail.com wrote:
Hi
On Tue, Aug 27, 2013 at 11:15 AM, Sourav Poddar sourav.pod...@ti.com wrote:
Add support for macronix MX66L51235L flash device.
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
drivers/mtd/spi/macronix.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/spi/macronix.c b/drivers/mtd/spi/macronix.c
index 70435eb..5a528c3 100644
--- a/drivers/mtd/spi/macronix.c
+++ b/drivers/mtd/spi/macronix.c
@@ -61,6 +61,11 @@ static const struct macronix_spi_flash_params
macronix_spi_flash_table[] = {
.nr_blocks = 256,
.name = MX25L12855E,
},
+ {
+ .idcode = 0x201a,
+ .nr_blocks = 512,
+ .name = MX66L51235L,
+ },
};
Can you check the similar patch
http://patchwork.ozlabs.org/patch/262928/
Please confirm about nr_blocks?
Also have u tested with latest spi_flash code, since ur part is 64MB
must require a BAR to access entire memory.?
http://patchwork.ozlabs.org/patch/262929/
Let me know for any concerns.
--
Thanks,
Jagan.
--
Thanks,
Jagan.
Jagannadha Sutradharudu Teki,
E: jagannadh.t...@gmail.com, P: +91-9676773388
Engineer - System Software Hacker
U-boot - SPI Custodian and Zynq APSOC
Ln: http://www.linkedin.com/in/jaganteki
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sf: spansion: Add support for S25FL512S_256K
Please try to test your part in u-boot-spi.git with master-probe branch.
We have a new probe setup code.
Let me know for any issues or concerns.
On Thu, Aug 1, 2013 at 5:46 AM, Nobuhiro Iwamatsu
nobuhiro.iwamatsu...@renesas.com wrote:
Hi,
Thank you for your review.
2013/7/31 Michal Simek mon...@monstr.eu:
On 07/31/2013 09:43 AM, Nobuhiro Iwamatsu wrote:
Add support for Spansion S25FL512S_256K SPI flash.
Signed-off-by: Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com
---
drivers/mtd/spi/spansion.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/mtd/spi/spansion.c b/drivers/mtd/spi/spansion.c
index 47a4897..a7dc096 100644
--- a/drivers/mtd/spi/spansion.c
+++ b/drivers/mtd/spi/spansion.c
@@ -1,4 +1,5 @@
/*
+ * Copyright (C) 2013 Renesas Electronics Corporation
I don't think that this is huge contribution that you should also update
header.
Hm, OK. I remove this line.
* Copyright (C) 2009 Freescale Semiconductor, Inc.
*
* Author: Mingkai Hu (mingkai...@freescale.com)
@@ -101,6 +102,13 @@ static const struct spansion_spi_flash_params
spansion_spi_flash_table[] = {
.nr_sectors = 1024,
.name = S25FL512S_64K,
},
+ {
+ .idcode1 = 0x0220,
+ .idcode2 = 0x4d00,
+ .pages_per_sector = 1024,
+ .nr_sectors = 256,
+ .name = S25FL512S_256K,
+ },
Jagan sent very similar patch
http://lists.denx.de/pipermail/u-boot/2013-May/155501.html
but nr_sectors and pages_per_sector are swapped.
I did not notice this patch, thanks.
I wait patch of Jagan to be merged.
Best regards,
Nobuhiro
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP - KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
--
Nobuhiro Iwamatsu
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
--
Thanks,
Jagan.
Jagannadha Sutradharudu Teki,
E: jagannadh.t...@gmail.com, P: +91-9676773388
Engineer - System Software Hacker
U-boot - SPI Custodian and Zynq APSOC
Ln: http://www.linkedin.com/in/jaganteki
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 10/10] trats: Update TRATS config to support TIZEN download
Dear Lukasz Majewski, A set of environment variables needs to be updated to provide support for TIZEN download command (tizendown). Since DFU is used as a flashing backend, it is also necessary to extent malloc pool size for DFU buffer allocation. Moreover, for compatibility reasons (Win vs. Lin) new USB idProduct number for download gadget had to be added. Signed-off-by: Lukasz Majewski l.majew...@samsung.com Cc: Marek Vasut ma...@denx.de --- include/configs/trats.h | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/include/configs/trats.h b/include/configs/trats.h index 24ea06b..955bd20 100644 --- a/include/configs/trats.h +++ b/include/configs/trats.h @@ -50,7 +50,7 @@ #define CONFIG_MACH_TYPE MACH_TYPE_TRATS /* Size of malloc() pool */ -#define CONFIG_SYS_MALLOC_LEN(CONFIG_ENV_SIZE + (16 20)) +#define CONFIG_SYS_MALLOC_LEN(CONFIG_ENV_SIZE + (80 20)) Use SZ_1M instead of that l-shift by 20. /* select serial console configuration */ #define CONFIG_SERIAL2 /* use SERIAL 2 */ @@ -91,12 +91,20 @@ /* USB Composite download gadget - g_dnl */ #define CONFIG_USBDOWNLOAD_GADGET + +/* TIZEN THOR downloader support */ +#define CONFIG_CMD_THOR_DOWNLOAD +#define CONFIG_THOR_FUNCTION + +#define CONFIG_SYS_DFU_DATA_BUF_SIZE (32 20) DTTO #define CONFIG_DFU_FUNCTION #define CONFIG_DFU_MMC /* USB Samsung's IDs */ #define CONFIG_G_DNL_VENDOR_NUM 0x04E8 #define CONFIG_G_DNL_PRODUCT_NUM 0x6601 +#define CONFIG_G_DNL_THOR_VENDOR_NUM CONFIG_G_DNL_VENDOR_NUM +#define CONFIG_G_DNL_THOR_PRODUCT_NUM 0x685D #define CONFIG_G_DNL_MANUFACTURER Samsung #define CONFIG_BOOTDELAY 1 @@ -131,7 +139,8 @@ #define CONFIG_DFU_ALT \ u-boot mmc 80 400; \ uImage ext4 0 2; \ - exynos4210-trats.dtb ext4 0 2\0 + exynos4210-trats.dtb ext4 0 2; \ + PARTS_ROOT part 0 5\0 #define CONFIG_ENV_OVERWRITE #define CONFIG_SYS_CONSOLE_INFO_QUIET btw. I'm picking this patch before this set: [PATCH v5] usb: new board-specific USB init interface So you might want to wait until it's applied onto usb/next and then rebase and repost. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5] usb: new board-specific USB init interface
Dear Mateusz Zalega, This commit unifies board-specific USB initialization implementations under one symbol (usb_board_init), declaration of which is available in usb.h. New API allows selective initialization of USB controllers whenever needed. Signed-off-by: Mateusz Zalega m.zal...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Reviewed-by: Lukasz Majewski l.majew...@samsung.com Cc: Marek Vasut ma...@denx.de Cc: Lukasz Majewski l.majew...@samsung.com --- Changes since RFC (v1): - NVIDIA Tegra doesn't postpone its USB init anymore - board_usb_init()'s sole argument name was shortened - networking code comment style (/* blurb...) dropped - squashed RFC changes so that patch won't break bisect v2 changes: - commit message fixup v3 changes: - added 'index' argument to perform selective port initialization v4 changes: - board_usb_init_fail() renamed to board_usb_cleanup() - board_usb_cleanup() accepts controller index and init type - DFU and UMS commands don't init all USB controllers anymore - minor related fixes refactorization v5 changes: - fixed an issue with boards based on canyonlands.c - patch passes MAKEALL -a powerpc (vide: ^) Hey, can you please rebase on top of usb/next ? I'd like to run build tests and apply. 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] usb: Fix error handling in musb_hcd.c
Dear Andrew Murray, The wait_until_[rx|tx]ep_ready functions return a u8 to indicate success containing the value 0, 1 or -1. This patch changes the return type to an int to accommodate the negative return values. These functions are used in the file using calls such as if (!wait_until... Where a -1 is returned it is mishandled and treated as success instead of a CRC error. This patch addresses this. Cc: Marek Vasut ma...@denx.de Cc: Tom Rini tr...@ti.com Signed-off-by: Andrew Murray amur...@embedded-bits.co.uk Acked-by: Marek Vasut ma...@denx.de Tom, feel free to pick this up if it's ok on this omap hardware. 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 06/10] usb:g_dnl:f_thor: USB download function to support TIZEN's THOR protocol
Dear Lukasz Majewski,
[...]
+static struct f_thor *thor_func;
+static inline struct f_thor *func_to_thor(struct usb_function *f)
+{
+ return container_of(f, struct f_thor, usb_function);
+}
+
+DEFINE_CACHE_ALIGN_BUFFER(char, thor_tx_data_buf, sizeof(struct rsp_box));
+DEFINE_CACHE_ALIGN_BUFFER(char, thor_rx_data_buf, sizeof(struct rqt_box));
This should either be uint8_t or unsigned char. A buffer shall not be (signed)
char.
Also, I suspect you want to use DEFINE_CACHE_ALIGN_BUFFER here, no ?
+/* ** */
+/* THOR protocol - transmission handling */
+/* ** */
+DEFINE_CACHE_ALIGN_BUFFER(char, f_name, F_NAME_BUF_SIZE);
Ditto
+static unsigned long long int thor_file_size;
+static int alt_setting_num;
+
+static void send_rsp(const struct rsp_box *rsp)
+{
+ /* should be copy on dma duffer */
+ memcpy(thor_tx_data_buf, rsp, sizeof(struct rsp_box));
+ thor_tx_data(thor_tx_data_buf, sizeof(struct rsp_box));
+
+ debug(-RSP: %d, %d\n, rsp-rsp, rsp-rsp_data);
+}
+
+static void send_data_rsp(s32 ack, s32 count)
+{
+ ALLOC_CACHE_ALIGN_BUFFER(struct data_rsp_box, rsp,
+ sizeof(struct data_rsp_box));
+
+ rsp-ack = ack;
+ rsp-count = count;
+
+ /* should be copy on dma duffer */
This comment really makes no sense to me.
+ memcpy(thor_tx_data_buf, rsp, sizeof(struct data_rsp_box));
+ thor_tx_data(thor_tx_data_buf, sizeof(struct data_rsp_box));
+
+ debug(-DATA RSP: %d, %d\n, ack, count);
+}
+
+static int process_rqt_info(const struct rqt_box *rqt)
+{
+ ALLOC_CACHE_ALIGN_BUFFER(struct rsp_box, rsp, sizeof(struct rsp_box));
+ memset(rsp, '\0', sizeof(struct rsp_box));
+
+ rsp-rsp = rqt-rqt;
+ rsp-rsp_data = rqt-rqt_data;
+
+ switch (rqt-rqt_data) {
+ case RQT_INFO_VER_PROTOCOL:
+ rsp-int_data[0] = VER_PROTOCOL_MAJOR;
+ rsp-int_data[1] = VER_PROTOCOL_MINOR;
+ break;
+ case RQT_INIT_VER_HW:
+ snprintf(rsp-str_data[0], sizeof(rsp-str_data[0]),
+ %x, checkboard());
+ break;
+ case RQT_INIT_VER_BOOT:
+ sprintf(rsp-str_data[0], %s, U_BOOT_VERSION);
+ break;
+ case RQT_INIT_VER_KERNEL:
+ sprintf(rsp-str_data[0], %s, k unknown);
+ break;
+ case RQT_INIT_VER_PLATFORM:
+ sprintf(rsp-str_data[0], %s, p unknown);
+ break;
+ case RQT_INIT_VER_CSC:
+ sprintf(rsp-str_data[0], %s, c unknown);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ send_rsp(rsp);
+ return true;
+}
+
+static int process_rqt_cmd(const struct rqt_box *rqt)
+{
+ ALLOC_CACHE_ALIGN_BUFFER(struct rsp_box, rsp, sizeof(struct rsp_box));
+ memset(rsp, '\0', sizeof(struct rsp_box));
memset(rsp, 0, sizeof() ... this '\0' is unneeded, fix globally.
+
+ rsp-rsp = rqt-rqt;
+ rsp-rsp_data = rqt-rqt_data;
+
+ switch (rqt-rqt_data) {
+ case RQT_CMD_REBOOT:
+ debug(TARGET RESET\n);
+ send_rsp(rsp);
+ g_dnl_unregister();
+ dfu_free_entities();
+ run_command(reset, 0);
+ break;
+ case RQT_CMD_POWEROFF:
+ case RQT_CMD_EFSCLEAR:
+ send_rsp(rsp);
This case fallthrough is intentional here ?
+ default:
+ printf(Command not supported - cmd: %d\n, rqt-rqt_data);
+ return -EINVAL;
+ }
+
+ return true;
+}
[...]
[...]
+static struct usb_cdc_call_mgmt_descriptor thor_downloader_cdc_call = {
+ .bLength =sizeof(thor_downloader_cdc_call),
+ .bDescriptorType =0x24, /* CS_INTERFACE */
+ .bDescriptorSubType = 0x01,
+ .bmCapabilities = 0x00,
+ .bDataInterface = 0x01,
+};
+
+struct usb_cdc_acm_descriptor thor_downloader_cdc_abstract = {
Why is this and the rest not static ?
+ .bLength =sizeof(thor_downloader_cdc_abstract),
+ .bDescriptorType =0x24, /* CS_INTERFACE */
+ .bDescriptorSubType = 0x02,
+ .bmCapabilities = 0x00,
+};
+
+struct usb_cdc_union_desc thor_downloader_cdc_union = {
+ .bLength = sizeof(thor_downloader_cdc_union),
+ .bDescriptorType = 0x24, /* CS_INTERFACE */
+ .bDescriptorSubType = USB_CDC_UNION_TYPE,
+};
+
+static struct usb_endpoint_descriptor fs_int_desc = {
+ .bLength = USB_DT_ENDPOINT_SIZE,
+ .bDescriptorType = USB_DT_ENDPOINT,
+
+ .bEndpointAddress = 3 | USB_DIR_IN,
+ .bmAttributes = USB_ENDPOINT_XFER_INT,
+ .wMaxPacketSize = __constant_cpu_to_le16(16),
+
+ .bInterval = 0x9,
+};
[...]
+/*
-*/ +static struct usb_request
Re: [U-Boot] [PATCH 01/10] usb:udc:s3c: Reduce dcache invalidate range for UDC receive buffer
Dear Lukasz Majewski, The s3c udc driver sends data in a max packet size. Therefore the dcache invalidate range shall be equal to max packet, not the entire DMA_BUFFER_SIZE. Signed-off-by: Lukasz Majewski l.majew...@samsung.com Cc: Marek Vasut ma...@denx.de --- drivers/usb/gadget/s3c_udc_otg_xfer_dma.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/gadget/s3c_udc_otg_xfer_dma.c b/drivers/usb/gadget/s3c_udc_otg_xfer_dma.c index d7af5e9..5e3ba76 100644 --- a/drivers/usb/gadget/s3c_udc_otg_xfer_dma.c +++ b/drivers/usb/gadget/s3c_udc_otg_xfer_dma.c @@ -117,7 +117,7 @@ static int setdma_rx(struct s3c_ep *ep, struct s3c_request *req) invalidate_dcache_range((unsigned long) ep-dev-dma_buf[ep_num], (unsigned long) ep-dev-dma_buf[ep_num] - + DMA_BUFFER_SIZE); + + ep-ep.maxpacket); Is this maxpacket _always_ multiple of cacheline big or will you need some ROUND_UP() call here ? 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] zynq: Use arch_cpu_init() instead of lowlevel_init()
Hi Michal,
On Thu, 3 Oct 2013 11:56:20 +0200, Michal Simek
michal.si...@xilinx.com wrote:
Hi Albert,
On 10/03/2013 10:41 AM, Albert ARIBAUD wrote:
Hi Michal,
On Thu, 03 Oct 2013 08:58:38 +0200, Michal Simek mon...@monstr.eu
wrote:
On 10/02/2013 09:43 PM, Albert ARIBAUD wrote:
Hi Michal,
On Tue, 24 Sep 2013 12:38:38 +0200, Michal Simek mon...@monstr.eu
wrote:
Hi Albert,
On 09/23/2013 04:37 PM, Albert ARIBAUD wrote:
Hi Michal,
On Mon, 23 Sep 2013 16:19:52 +0200, Michal Simek mon...@monstr.eu
wrote:
On 09/23/2013 02:31 PM, Albert ARIBAUD wrote:
Hi Michal,
On Thu, 22 Aug 2013 14:52:02 +0200, Michal Simek
michal.si...@xilinx.com wrote:
Zynq lowlevel_init() was implemented in C but stack
pointer is setup after function call in _main().
Move architecture setup to arch_cpu_init() which is call
as the first function in board_init_f() which
already have correct stack pointer.
Reported-by: Sven Schwermer sven.schwer...@tuhh.de
Signed-off-by: Michal Simek michal.si...@xilinx.com
---
I can't see any problem to call zynq setup a little
bit later. There is already expectation that u-boot
runs from DDR.
Moving lowlevel_init from C to ASM is possible but
I will have to introduce new macros with hardcoded
values. Using structures is much nicer.
---
arch/arm/cpu/armv7/zynq/cpu.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/cpu/armv7/zynq/cpu.c
b/arch/arm/cpu/armv7/zynq/cpu.c
index 4367d1a..8846f30 100644
--- a/arch/arm/cpu/armv7/zynq/cpu.c
+++ b/arch/arm/cpu/armv7/zynq/cpu.c
@@ -11,6 +11,10 @@
void lowlevel_init(void)
{
+}
I'd rather you deleted lowlevel_init() as a C function with this
name should not exist.
Ok. Do you want me to create almost empty low_level.S or just use
arch/arm/cpu/arvm7/lowlevel_init.S and define empty s_init()?
Urgh. I realize removing the C function would give you more work than
simply keeping it empty until the whole s_init() mess is cleaned up. :(
I'll take your change as-is, sorry for the noise.
In connection to this topic we have recently found one issue
regarding to neon instruction which u-boot uses.
We have this code to enable them in asm and adding this to
lowlevel_init.S
is straight way how to do so.
mov r0, r0
mrc p15, 0, r1, c1, c0, 2
orr r1, r1, #(0xf 20)
mcr p15, 0, r1, c1, c0, 2
fmrxr1, FPEXC
orr r1,r1, #(130)
fmxrFPEXC, r1
Is it ok to create zynq asm specific lowlevel function
or doing this through s_init() or you have nice a clean way how
this should be solved when you are saying that s_init() is mess.
Sorry for responding slowly.
I suspect when you say neon instruction that U-Boot uses, you mean neon
instructions that GCC is allowed to emit while building U-Boot, right?
yes.
So we're talking about neon insns in C code only, not asm, correct?
yes. gcc emits neon instruction in timer code. Not in asm.
If this is correct, then does something prevent you from enabling
neon instructions as early as possible, in e.g. the lowlevel_init
routine?
ok let me clear this. I think location of this code is clear.
It is asm code and it will be called ASAP even
we know exactly which code emits neon instructions.
My point was if we should create specific lowlevel_init asm function
and add this code there.
Or use arch/arm/cpu/armv7/lowlevel_init.S and create just s_init function.
You mentioned above that s_init() is a mess and needs to be clean up
but you didn't mentioned how.
It means my point is if you tell us how should be clean up we can
just submit code which is compatible with this cleanup activity.
If I knew how to clean s_init() up, I'd have sent out patches
already. :)
Fair enough. :-)
Anyway, I'm not sure that I see how s_init() and your need for a NEON
enable sequence would be related: this sequence does not *need* to be in
s_init().
ok. s_init is not asm function - but C function.
Indeed, enabling NEON is, IMO, similar to enabling alignment checks
or setting the CPU mode, so I guess it could find its way in start.S,
inside a preprocessor conditional (since e.g. not all Cortex-A9 will
support NEON).
ok. That sound good to me.
BTW, where in U-Boot does GCC get instructed to emit NEON instructions
at the moment? There is no -mfpu or -mfloat-abi option in the code base
right now, so I suspect you're going to introduce it along with the
enable sequence, correct?
file: arch/arm/cpu/armv7/zynq/timer.c
fce: void __udelay(unsigned long usec)
line: countticks = (u32) (((unsigned long long) TIMER_TICK_HZ * usec) /
100);
This is what I have got from Edgar.
A significant difference between the u-boot builds is that the failing
one is
Re: [U-Boot] [PATCH 2/6] power: Explicitly select pmic device's bus
Hi Heiko,
Sorry for a late reply.
Hello Lukasz,
Am 02.10.2013 17:11, schrieb Lukasz Majewski:
Hi Leela,
The current pmic i2c code assumes the current i2c bus is
the same as the pmic device's bus. There is nothing ensuring
that to be true. Therefore, select the proper bus before performing
a transaction.
Signed-off-by: Aaron Durbinadur...@chromium.org
Signed-off-by: Simon Glasss...@chromium.org
Signed-off-by: Leela Krishna Amudalal.kris...@samsung.com
Reviewed-by: Doug Andersondiand...@google.com
---
drivers/power/power_i2c.c | 62
+ 1 file changed, 57
insertions(+), 5 deletions(-)
diff --git a/drivers/power/power_i2c.c b/drivers/power/power_i2c.c
index 47c606f..c22e01f 100644
--- a/drivers/power/power_i2c.c
+++ b/drivers/power/power_i2c.c
@@ -16,9 +16,45 @@
#includei2c.h
#includecompiler.h
+static int pmic_select(struct pmic *p)
+{
+ int ret, old_bus;
+
+ old_bus = i2c_get_bus_num();
+ if (old_bus != p-bus) {
+ debug(%s: Select bus %d\n, __func__, p-bus);
+ ret = i2c_set_bus_num(p-bus);
+ if (ret) {
+ debug(%s: Cannot select pmic %s, err
%d\n,
+__func__, p-name, ret);
+ return -1;
+ }
+ }
+
+ return old_bus;
+}
+
+static int pmic_deselect(int old_bus)
+{
+ int ret;
+
+ if (old_bus != i2c_get_bus_num()) {
+ ret = i2c_set_bus_num(old_bus);
+ debug(%s: Select bus %d\n, __func__, old_bus);
+ if (ret) {
+ debug(%s: Cannot restore i2c bus, err
%d\n,
+__func__, ret);
+ return -1;
+ }
+ }
+
+ return 0;
+}
+
int pmic_reg_write(struct pmic *p, u32 reg, u32 val)
{
unsigned char buf[4] = { 0 };
+ int ret, old_bus;
if (check_reg(p, reg))
return -1;
@@ -52,23 +88,33 @@ int pmic_reg_write(struct pmic *p, u32 reg, u32
val) return -1;
}
- if (i2c_write(pmic_i2c_addr, reg, 1, buf,
pmic_i2c_tx_num))
+ old_bus = pmic_select(p);
+ if (old_bus 0)
return -1;
- return 0;
+ ret = i2c_write(pmic_i2c_addr, reg, 1, buf,
pmic_i2c_tx_num);
I'm wondering if setting the bus before each, single i2c write
(when we usually perform several writes to one device) will not be
an overkill (we search the ll_entry_count linker list each time to
find max i2c adapter names) ?
Yes, maybe we could optimze this in drivers/i2c/i2c_core.c. It should
be enough to detect the max adapter once ... but it is not a
search... ll_entry_count() calculates the number ...
Yes, you are right. I've overlooked it.
With -Os compiler flag this compiles to a few ASM instructions.
Obviously it is NOT a performance killer :-) (I made unnecessary
fuzzz... sorry).
Looking in i2c_set_bus_num(), I think it can be optimized ...
lets speaking code:
diff --git a/drivers/i2c/i2c_core.c b/drivers/i2c/i2c_core.c
index d1072e8..170423a 100644
--- a/drivers/i2c/i2c_core.c
+++ b/drivers/i2c/i2c_core.c
@@ -278,20 +278,22 @@ unsigned int i2c_get_bus_num(void)
*/
int i2c_set_bus_num(unsigned int bus)
{
- int max = ll_entry_count(struct i2c_adapter, i2c);
+ int max;
+
+ if ((bus == I2C_BUS) (I2C_ADAP-init_done 0))
+ return 0;
This looks nice.
- if (I2C_ADAPTER(bus) = max) {
- printf(Error, wrong i2c adapter %d max %d
possible\n,
- I2C_ADAPTER(bus), max);
- return -2;
- }
#ifndef CONFIG_SYS_I2C_DIRECT_BUS
if (bus = CONFIG_SYS_NUM_I2C_BUSES)
return -1;
#endif
- if ((bus == I2C_BUS) (I2C_ADAP-init_done 0))
- return 0;
+ max = ll_entry_count(struct i2c_adapter, i2c);
+ if (I2C_ADAPTER(bus) = max) {
+ printf(Error, wrong i2c adapter %d max %d
possible\n,
+ I2C_ADAPTER(bus), max);
+ return -2;
+ }
#ifndef CONFIG_SYS_I2C_DIRECT_BUS
i2c_mux_disconnet_all();
So, first check, if we are on the correct bus, and return immediately!
What do you think?
I think that it is acceptable.
Beside of that, pmic_select() does the check, if we are on the correct
bus too, and calls i2c_set_bus_num() only, if not ... so this is here
no problem ...
Yes, I see.
but exactly I want to get rid of this code as it is in
pmic_select() someday, when all i2c drivers converted to the new i2c
framework.
My 2 cents. I understand that pmic_select() preserves old i2c bus
number, when PMIC performs transmission. This is probably done to not
break the legacy code (where one driver assumed, that it is alone).
If this is necessary, then I'm OK with this. However I personally think,
that drivers shall call API functions from i2c core (like i2c_bus_num())
only with bus number
Re: [U-Boot] [UBOOT][PATCHv3 0/7] mtd/spi: add quad/memory mapped read support, add ti qspi controller.
Hi Sourav, Can you rebase your changes w.r.t u-boot-spi.git with master-probe branch. Sorry for the delay, try to send the patches without quad related stuff. I will prepare a thread for this quad after this release as we did lot of work last few months back. Thanks for your help.!!! On Wed, Sep 18, 2013 at 5:51 PM, Sourav Poddar sourav.pod...@ti.com wrote: This patch series add support for TI qspi controller and in the process also add support for quad read and memory mapped read in mtd spi framework. Testing details: Did a boot from qspi mode on DRA7xx. Testing details present in the last patch of the series. Currently, TI qpsi controller supports only 16MB access. Access for higher MB area will be added later. v2-v3: 1. run checkpatch 2. Rearrange the code logically. 3. Remove a page read hack. Matt Porter (3): omap5: add qspi support spi: add TI QSPI driver dra7xx_evm: add SPL API, QSPI, and serial flash support Ravikumar Kattekola (1): drivers: mtd: :spi: Add quad read support Sourav Poddar (3): armv7: hw_data: change clock divider setting. driver: mtd: spi: Add memory mapped read support README: qspi usecase and testing documentation. arch/arm/cpu/armv7/omap5/hw_data.c | 10 +- arch/arm/cpu/armv7/omap5/prcm-regs.c |1 + arch/arm/include/asm/arch-omap5/omap.h |3 + arch/arm/include/asm/arch-omap5/spl.h |1 + arch/arm/include/asm/omap_common.h |1 + board/ti/dra7xx/mux_data.h | 10 + doc/README.ti_qspi_dra_test| 38 doc/README.ti_qspi_flash | 47 + drivers/mtd/spi/spansion.c |1 + drivers/mtd/spi/spi_flash.c| 113 +++- drivers/mtd/spi/spi_flash_internal.h |2 + drivers/spi/Makefile |1 + drivers/spi/ti_qspi.c | 324 include/configs/dra7xx_evm.h | 20 ++ include/spi.h |5 + 15 files changed, 575 insertions(+), 2 deletions(-) create mode 100644 doc/README.ti_qspi_dra_test create mode 100644 doc/README.ti_qspi_flash create mode 100644 drivers/spi/ti_qspi.c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot -- Thanks, Jagan. Jagannadha Sutradharudu Teki, E: jagannadh.t...@gmail.com, P: +91-9676773388 Engineer - System Software Hacker U-boot - SPI Custodian and Zynq APSOC Ln: http://www.linkedin.com/in/jaganteki ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [UBOOT][PATCHv3 5/7] spi: add TI QSPI driver
Hi Sourav, Please try to code the driver as specified in below thread! http://lists.denx.de/pipermail/u-boot/2013-August/160472.html On Fri, Sep 20, 2013 at 8:21 AM, Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com wrote: Hi, 2013/9/18 Sourav Poddar sourav.pod...@ti.com: From: Matt Porter matt.por...@linaro.org Adds a SPI master driver for the TI QSPI peripheral. Signed-off-by: Matt Porter matt.por...@linaro.org Signed-off-by: Sourav Poddar sourav.pod...@ti.com [Added quad read support and memory mapped support). --- drivers/spi/Makefile |1 + drivers/spi/ti_qspi.c | 324 + 2 files changed, 325 insertions(+), 0 deletions(-) create mode 100644 drivers/spi/ti_qspi.c diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile index 91d24ce..e5941b0 100644 --- a/drivers/spi/Makefile +++ b/drivers/spi/Makefile @@ -38,6 +38,7 @@ COBJS-$(CONFIG_FDT_SPI) += fdt_spi.o COBJS-$(CONFIG_TEGRA20_SFLASH) += tegra20_sflash.o COBJS-$(CONFIG_TEGRA20_SLINK) += tegra20_slink.o COBJS-$(CONFIG_TEGRA114_SPI) += tegra114_spi.o +COBJS-$(CONFIG_TI_QSPI) += ti_qspi.o COBJS-$(CONFIG_XILINX_SPI) += xilinx_spi.o COBJS-$(CONFIG_ZYNQ_SPI) += zynq_spi.o diff --git a/drivers/spi/ti_qspi.c b/drivers/spi/ti_qspi.c new file mode 100644 index 000..3e88cf4 --- /dev/null +++ b/drivers/spi/ti_qspi.c @@ -0,0 +1,324 @@ +/* + * TI QSPI driver + * + * Copyright (C) 2013, Texas Instruments, Incorporated + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR /PURPOSE. See the + * GNU General Public License for more details. + */ Could you change to 'SPDX-License-Identifier:GPL-2.0+', please? Best regards, Nobuhiro -- Nobuhiro Iwamatsu ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot -- Thanks, Jagan. Jagannadha Sutradharudu Teki, E: jagannadh.t...@gmail.com, P: +91-9676773388 Engineer - System Software Hacker U-boot - SPI Custodian and Zynq APSOC Ln: http://www.linkedin.com/in/jaganteki ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] spi: Add support SH Quad SPI driver
Have you verified this on hw?
Sorry for the late response.
Can you RESEND the patch again- I couldn't find it on patchwork.
Thanks,
Jagan.
-Original Message-
From: Nobuhiro Iwamatsu [mailto:iwama...@nigauri.org] On Behalf Of
Nobuhiro Iwamatsu
Sent: Thursday, August 22, 2013 7:25 AM
To: Jagannadha Sutradharudu Teki
Cc: tr...@ti.com; u-boot@lists.denx.de; jagannadh.t...@gmail.com;
Nobuhiro Iwamatsu; Kouei Abe
Subject: [PATCH v3] spi: Add support SH Quad SPI driver
This patch adds a driver for Renesas SoC's Quad SPI bus.
This supports with 8 bits per transfer to use with SPI flash.
Signed-off-by: Kouei Abe kouei.abe...@renesas.com
Signed-off-by: Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com
---
v3: Change Queued to Quad.
Remove path of file from file header.
Use read* and write* directly instead of sh_qspi_write* sh_qspi_read*.
Change driver format.
v2: Change SH QSPI to SH QSPI (Queued SPI).
Remove magic number.
drivers/spi/Makefile | 1 +
drivers/spi/sh_qspi.c | 248
++
2 files changed, 249 insertions(+)
create mode 100644 drivers/spi/sh_qspi.c
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile index
91d24ce..c44f851 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -33,6 +33,7 @@ COBJS-$(CONFIG_OC_TINY_SPI) += oc_tiny_spi.o
COBJS-$(CONFIG_OMAP3_SPI) += omap3_spi.o
COBJS-$(CONFIG_SOFT_SPI) += soft_spi.o
COBJS-$(CONFIG_SH_SPI) += sh_spi.o
+COBJS-$(CONFIG_SH_QSPI) += sh_qspi.o
COBJS-$(CONFIG_FSL_ESPI) += fsl_espi.o
COBJS-$(CONFIG_FDT_SPI) += fdt_spi.o
COBJS-$(CONFIG_TEGRA20_SFLASH) += tegra20_sflash.o diff --git
a/drivers/spi/sh_qspi.c b/drivers/spi/sh_qspi.c new file mode 100644 index
000..2efaea8
--- /dev/null
+++ b/drivers/spi/sh_qspi.c
@@ -0,0 +1,248 @@
+/*
+ * SH QSPI (Quad SPI) driver
+ *
+ * Copyright (C) 2013 Renesas Electronics Corporation
+ * Copyright (C) 2013 Nobuhiro Iwamatsu
+nobuhiro.iwamatsu...@renesas.com
+ *
+ * SPDX-License-Identifier: GPL-2.0
+ */
+
+#include common.h
+#include malloc.h
+#include spi.h
+#include asm/io.h
+
+/* SPCR */
+#define SPCR_MSTR 0x08
+#define SPCR_SPE 0x40
+
+/* SPSR */
+#define SPSR_SPRFF 0x80
+#define SPSR_SPTEF 0x20
+
+/* SPPCR */
+#define SPPCR_IO3FV 0x04
+#define SPPCR_IO2FV 0x02
+#define SPPCR_IO1FV 0x01
+
+/* SPBDCR */
+#define SPBDCR_RXBC0 (1 0)
+
+/* SPCMD */
+#define SPCMD_SCKDEN (1 15)
+#define SPCMD_SLNDEN (1 14)
+#define SPCMD_SPNDEN (1 13)
+#define SPCMD_SSLKP (1 7)
+#define SPCMD_BRDV0 (1 2)
+#define SPCMD_INIT1 \
+
(SPCMD_SCKDEN|SPCMD_SLNDEN|SPCMD_SPNDEN|SPCMD_SSLKP|
SPCMD_BRDV0)
+#define SPCMD_INIT2 (SPCMD_SPNDEN|SPCMD_SSLKP|SPCMD_BRDV0)
+
+/* SPBFCR */
+#define SPBFCR_TXRST (1 7)
+#define SPBFCR_RXRST (1 6)
+
+/* SH QSPI register set */
+struct sh_qspi_regs {
+ unsigned char spcr;
+ unsigned char sslp;
+ unsigned char sppcr;
+ unsigned char spsr;
+ unsigned long spdr;
+ unsigned char spscr;
+ unsigned char spssr;
+ unsigned char spbr;
+ unsigned char spdcr;
+ unsigned char spckd;
+ unsigned char sslnd;
+ unsigned char spnd;
+ unsigned char dummy0;
+ unsigned short spcmd0;
+ unsigned short spcmd1;
+ unsigned short spcmd2;
+ unsigned short spcmd3;
+ unsigned char spbfcr;
+ unsigned char dummy1;
+ unsigned short spbdcr;
+ unsigned long spbmul0;
+ unsigned long spbmul1;
+ unsigned long spbmul2;
+ unsigned long spbmul3;
+};
+
+struct sh_qspi {
+ struct spi_slaveslave;
+ struct sh_qspi_regs *regs;
+};
+
+static inline struct sh_qspi *to_sh_qspi(struct spi_slave *slave) {
+ return container_of(slave, struct sh_qspi, slave); }
+
+static int sh_qspi_xfer(struct sh_qspi *ss, unsigned char *tdata,
+ unsigned char *rdata, unsigned long flags) {
+ while (!(readb(ss-regs-spsr) SPSR_SPTEF)) {
+ if (ctrlc())
+ return 1;
+ udelay(10);
+ }
+
+ writeb(*tdata, (unsigned char *)(ss-regs-spdr));
+
+ while ((readw(ss-regs-spbdcr) != SPBDCR_RXBC0)) {
+ int i = 100;
+
+ if (ctrlc())
+ return 1;
+ while (i--)
+ ;
+ }
+
+ while (!(readb(ss-regs-spsr) SPSR_SPRFF)) {
+ if (ctrlc())
+ return 1;
+ udelay(10);
+ }
+
+ *rdata = readb((unsigned char *)(ss-regs-spdr));
+
+ return 0;
+}
+
+int spi_cs_is_valid(unsigned int bus, unsigned int cs) {
+ return 1;
+}
+
+void spi_cs_activate(struct spi_slave *slave) { }
+
+void spi_cs_deactivate(struct spi_slave *slave) { }
+
+void spi_init(void)
+{
+ /* nothing to do */
+}
+
+struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs,
+ unsigned int max_hz, unsigned int mode)
Re: [U-Boot] [UBOOT][PATCHv3 0/7] mtd/spi: add quad/memory mapped read support, add ti qspi controller.
Thanks, On Thu, Oct 3, 2013 at 11:55 PM, Sourav Poddar sourav.pod...@ti.com wrote: On Thursday 03 October 2013 11:13 PM, Jagan Teki wrote: Hi Sourav, Can you rebase your changes w.r.t u-boot-spi.git with master-probe branch. Sorry for the delay, try to send the patches without quad related stuff. Ok. I will rebase and send only ti qspi and memory mapped part. I will prepare a thread for this quad after this release as we did lot of work last few months back. Thanks for your help.!!! Ok. On Wed, Sep 18, 2013 at 5:51 PM, Sourav Poddarsourav.pod...@ti.com wrote: This patch series add support for TI qspi controller and in the process also add support for quad read and memory mapped read in mtd spi framework. Testing details: Did a boot from qspi mode on DRA7xx. Testing details present in the last patch of the series. Currently, TI qpsi controller supports only 16MB access. Access for higher MB area will be added later. v2-v3: 1. run checkpatch 2. Rearrange the code logically. 3. Remove a page read hack. Matt Porter (3): omap5: add qspi support spi: add TI QSPI driver dra7xx_evm: add SPL API, QSPI, and serial flash support Ravikumar Kattekola (1): drivers: mtd: :spi: Add quad read support Sourav Poddar (3): armv7: hw_data: change clock divider setting. driver: mtd: spi: Add memory mapped read support README: qspi usecase and testing documentation. arch/arm/cpu/armv7/omap5/hw_data.c | 10 +- arch/arm/cpu/armv7/omap5/prcm-regs.c |1 + arch/arm/include/asm/arch-omap5/omap.h |3 + arch/arm/include/asm/arch-omap5/spl.h |1 + arch/arm/include/asm/omap_common.h |1 + board/ti/dra7xx/mux_data.h | 10 + doc/README.ti_qspi_dra_test| 38 doc/README.ti_qspi_flash | 47 + drivers/mtd/spi/spansion.c |1 + drivers/mtd/spi/spi_flash.c| 113 +++- drivers/mtd/spi/spi_flash_internal.h |2 + drivers/spi/Makefile |1 + drivers/spi/ti_qspi.c | 324 include/configs/dra7xx_evm.h | 20 ++ include/spi.h |5 + 15 files changed, 575 insertions(+), 2 deletions(-) create mode 100644 doc/README.ti_qspi_dra_test create mode 100644 doc/README.ti_qspi_flash create mode 100644 drivers/spi/ti_qspi.c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot -- Thanks, Jagan. Jagannadha Sutradharudu Teki, E: jagannadh.t...@gmail.com, P: +91-9676773388 Engineer - System Software Hacker U-boot - SPI Custodian and Zynq APSOC Ln: http://www.linkedin.com/in/jaganteki ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [UBOOT][PATCHv3 5/7] spi: add TI QSPI driver
On Thursday 03 October 2013 11:19 PM, Jagan Teki wrote: Hi Sourav, Please try to code the driver as specified in below thread! http://lists.denx.de/pipermail/u-boot/2013-August/160472.html Ok. On Fri, Sep 20, 2013 at 8:21 AM, Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com wrote: Hi, 2013/9/18 Sourav Poddarsourav.pod...@ti.com: From: Matt Portermatt.por...@linaro.org Adds a SPI master driver for the TI QSPI peripheral. Signed-off-by: Matt Portermatt.por...@linaro.org Signed-off-by: Sourav Poddarsourav.pod...@ti.com [Added quad read support and memory mapped support). --- drivers/spi/Makefile |1 + drivers/spi/ti_qspi.c | 324 + 2 files changed, 325 insertions(+), 0 deletions(-) create mode 100644 drivers/spi/ti_qspi.c diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile index 91d24ce..e5941b0 100644 --- a/drivers/spi/Makefile +++ b/drivers/spi/Makefile @@ -38,6 +38,7 @@ COBJS-$(CONFIG_FDT_SPI) += fdt_spi.o COBJS-$(CONFIG_TEGRA20_SFLASH) += tegra20_sflash.o COBJS-$(CONFIG_TEGRA20_SLINK) += tegra20_slink.o COBJS-$(CONFIG_TEGRA114_SPI) += tegra114_spi.o +COBJS-$(CONFIG_TI_QSPI) += ti_qspi.o COBJS-$(CONFIG_XILINX_SPI) += xilinx_spi.o COBJS-$(CONFIG_ZYNQ_SPI) += zynq_spi.o diff --git a/drivers/spi/ti_qspi.c b/drivers/spi/ti_qspi.c new file mode 100644 index 000..3e88cf4 --- /dev/null +++ b/drivers/spi/ti_qspi.c @@ -0,0 +1,324 @@ +/* + * TI QSPI driver + * + * Copyright (C) 2013, Texas Instruments, Incorporated + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR /PURPOSE. See the + * GNU General Public License for more details. + */ Could you change to 'SPDX-License-Identifier:GPL-2.0+', please? Best regards, Nobuhiro -- Nobuhiro Iwamatsu ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [UBOOT][PATCHv3 0/7] mtd/spi: add quad/memory mapped read support, add ti qspi controller.
On Thursday 03 October 2013 11:13 PM, Jagan Teki wrote: Hi Sourav, Can you rebase your changes w.r.t u-boot-spi.git with master-probe branch. Sorry for the delay, try to send the patches without quad related stuff. Ok. I will rebase and send only ti qspi and memory mapped part. I will prepare a thread for this quad after this release as we did lot of work last few months back. Thanks for your help.!!! Ok. On Wed, Sep 18, 2013 at 5:51 PM, Sourav Poddarsourav.pod...@ti.com wrote: This patch series add support for TI qspi controller and in the process also add support for quad read and memory mapped read in mtd spi framework. Testing details: Did a boot from qspi mode on DRA7xx. Testing details present in the last patch of the series. Currently, TI qpsi controller supports only 16MB access. Access for higher MB area will be added later. v2-v3: 1. run checkpatch 2. Rearrange the code logically. 3. Remove a page read hack. Matt Porter (3): omap5: add qspi support spi: add TI QSPI driver dra7xx_evm: add SPL API, QSPI, and serial flash support Ravikumar Kattekola (1): drivers: mtd: :spi: Add quad read support Sourav Poddar (3): armv7: hw_data: change clock divider setting. driver: mtd: spi: Add memory mapped read support README: qspi usecase and testing documentation. arch/arm/cpu/armv7/omap5/hw_data.c | 10 +- arch/arm/cpu/armv7/omap5/prcm-regs.c |1 + arch/arm/include/asm/arch-omap5/omap.h |3 + arch/arm/include/asm/arch-omap5/spl.h |1 + arch/arm/include/asm/omap_common.h |1 + board/ti/dra7xx/mux_data.h | 10 + doc/README.ti_qspi_dra_test| 38 doc/README.ti_qspi_flash | 47 + drivers/mtd/spi/spansion.c |1 + drivers/mtd/spi/spi_flash.c| 113 +++- drivers/mtd/spi/spi_flash_internal.h |2 + drivers/spi/Makefile |1 + drivers/spi/ti_qspi.c | 324 include/configs/dra7xx_evm.h | 20 ++ include/spi.h |5 + 15 files changed, 575 insertions(+), 2 deletions(-) create mode 100644 doc/README.ti_qspi_dra_test create mode 100644 doc/README.ti_qspi_flash create mode 100644 drivers/spi/ti_qspi.c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/9][v2] net: tsec: Use portable types and accessors for BDs
On Thu, 2013-10-03 at 14:48 +0300, Claudiu Manoil wrote:
+static inline u16 read_txbd_stat(uint idx)
+{
+ return in_be16((u16 __iomem *)txbd[idx].status);
+}
+
+static inline void write_txbd_stat(uint idx, u16 status)
+{
+ out_be16((u16 __iomem *)txbd[idx].status, status);
+}
+
+static inline u16 read_rxbd_stat(uint idx)
+{
+ return in_be16((u16 __iomem *)rxbd[idx].status);
+}
+
+static inline void write_rxbd_stat(uint idx, u16 status)
+{
+ out_be16((u16 __iomem *)rxbd[idx].status, status);
+}
Do you need __force on these to make sparse happy?
I'd rather see these declared as __iomem than use casts (at which point,
you probably don't need per-field accessor functions).
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [UBOOT]: Mcspi/qspi conflicting configs leading to build failure.
Hi Jagan, If you see the mcspi defconfig(CONFIG_OMAP3_SPI), it is moved to common file include/configs/ti_armv7_common.h . But with this, now after adding qspi the build breaks like this.. ti_qspi.o: In function `spi_cs_is_valid': /home/a0131647/clone/u-boot/drivers/spi/ti_qspi.c:108: multiple definition of `spi_cs_is_valid' omap3_spi.o:/home/a0131647/clone/u-boot/drivers/spi/omap3_spi.c:415: first defined here ti_qspi.o: In function `spi_cs_activate': /home/a0131647/clone/u-boot/drivers/spi/ti_qspi.c:114: multiple definition of `spi_cs_activate' omap3_spi.o:/home/a0131647/clone/u-boot/drivers/spi/omap3_spi.c:419: first defined here ti_qspi.o: In function `spi_cs_deactivate': /home/a0131647/clone/u-boot/drivers/spi/ti_qspi.c:120: multiple definition of `spi_cs_deactivate' omap3_spi.o:/home/a0131647/clone/u-boot/drivers/spi/omap3_spi.c:423: first defined here ti_qspi.o: In function `spi_init': /home/a0131647/clone/u-boot/drivers/spi/ti_qspi.c:125: multiple definition of `spi_init' As of now, I am tackling this by doing a undef CONFIG_OMAP3_SPI in my configs. But, we should have a way to use both(spi/qspi) of them simultaneously ? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [UBOOT]: Mcspi/qspi conflicting configs leading to build failure.
On Fri, Oct 4, 2013 at 12:07 AM, Sourav Poddar sourav.pod...@ti.com wrote: Hi Jagan, If you see the mcspi defconfig(CONFIG_OMAP3_SPI), it is moved to common file include/configs/ti_armv7_common.h . But with this, now after adding qspi the build breaks like this.. ti_qspi.o: In function `spi_cs_is_valid': /home/a0131647/clone/u-boot/drivers/spi/ti_qspi.c:108: multiple definition of `spi_cs_is_valid' omap3_spi.o:/home/a0131647/clone/u-boot/drivers/spi/omap3_spi.c:415: first defined here ti_qspi.o: In function `spi_cs_activate': /home/a0131647/clone/u-boot/drivers/spi/ti_qspi.c:114: multiple definition of `spi_cs_activate' omap3_spi.o:/home/a0131647/clone/u-boot/drivers/spi/omap3_spi.c:419: first defined here ti_qspi.o: In function `spi_cs_deactivate': /home/a0131647/clone/u-boot/drivers/spi/ti_qspi.c:120: multiple definition of `spi_cs_deactivate' omap3_spi.o:/home/a0131647/clone/u-boot/drivers/spi/omap3_spi.c:423: first defined here ti_qspi.o: In function `spi_init': /home/a0131647/clone/u-boot/drivers/spi/ti_qspi.c:125: multiple definition of `spi_init' As of now, I am tackling this by doing a undef CONFIG_OMAP3_SPI in my configs. But, we should have a way to use both(spi/qspi) of them simultaneously ? As of now there is no way to use both, will do it.. I will add it on TODO. -- Thanks, Jagan. Jagannadha Sutradharudu Teki, E: jagannadh.t...@gmail.com, P: +91-9676773388 Engineer - System Software Hacker U-boot - SPI Custodian and Zynq APSOC Ln: http://www.linkedin.com/in/jaganteki ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] : Discussion on Serial Flash Discoverable Parameters (SFDP): JESD216A
Hi All, As all we know that the spi_flash is a day-by-day developing hardware where each vendor has followed their own standard to get the best to come out. I see SFDP looks like a common standard where most of the vendors were following to get the flash parameter information at runtime. I have couple of questions, added few flash vendors on cc - request for all try to give some inputs 1. Does all vendors follow this standard at-least from the latest parts? 2. Any idea who are not following SFDP 3. Does the format of getting data from SFDP is varies from vendor to vendor or same? 4. Command to get the SFDP is same for all vendors? 5. What type of information we can get any list? Request for your comments, this will really help to shape the spi_flash code more dynamic. -- Thanks, Jagan. Jagannadha Sutradharudu Teki, E: jagannadh.t...@gmail.com, P: +91-9676773388 Engineer - System Software Hacker U-boot - SPI Custodian and Zynq APSOC Ln: http://www.linkedin.com/in/jaganteki ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 7/8] ARM: extend non-secure switch to also go into HYP mode
On Thu, Oct 03, 2013 at 08:24:57AM +0200, Albert ARIBAUD wrote: Hi Andre, On Thu, 19 Sep 2013 18:06:45 +0200, Andre Przywara andre.przyw...@linaro.org wrote: For the KVM and XEN hypervisors to be usable, we need to enter the kernel in HYP mode. Now that we already are in non-secure state, HYP mode switching is within short reach. While doing the non-secure switch, we have to enable the HVC instruction and setup the HYP mode HVBAR (while still secure). The actual switch is done by dropping back from a HYP mode handler without actually leaving HYP mode, so we introduce a new handler routine in our new secure exception vector table. In the assembly switching routine we save and restore the banked LR and SP registers around the hypercall to do the actual HYP mode switch. The C routine first checks whether we are in HYP mode already and also whether the virtualization extensions are available. It also checks whether the HYP mode switch was finally successful. The bootm command part only calls the new function after the non-secure switch. Signed-off-by: Andre Przywara andre.przyw...@linaro.org --- arch/arm/cpu/armv7/Makefile | 2 +- arch/arm/cpu/armv7/nonsec_virt.S | 43 +++- arch/arm/cpu/armv7/virt-v7.c | 37 ++ arch/arm/include/asm/armv7.h | 6 -- arch/arm/lib/bootm.c | 7 ++- 5 files changed, 86 insertions(+), 9 deletions(-) Changes: v3..v4: w/s fixes, embed error output v4..v5: none Seems like Christoffer's comment was not addressed here but IIUC, it was in other files (Christoffer, feel free to comment). Any reason why the older asm comments form was not replaced in here? I think these comments are a bit superflous, but not exactly harmful, so I didn't raise the flag when they were not corrected. My thought was that if you're building for a board that has support for the virtualization extensions you should be using a toolchain that knows about them too, but Andre pointed out that his (I think Debian) still used an old enough cross toolchain not to have this support. In any case, I don't think this warrants holding back the patches but can be fixed as a follow-up if the community agrees that we need to support older toolchains by some define that encodes the hvc and eret instructions properly. Thanks, -Christoffer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 7/8] ARM: extend non-secure switch to also go into HYP mode
Hi Christoffer, On Thu, 3 Oct 2013 19:55:15 +0100, Christoffer Dall christoffer.d...@linaro.org wrote: On Thu, Oct 03, 2013 at 08:24:57AM +0200, Albert ARIBAUD wrote: Hi Andre, On Thu, 19 Sep 2013 18:06:45 +0200, Andre Przywara andre.przyw...@linaro.org wrote: For the KVM and XEN hypervisors to be usable, we need to enter the kernel in HYP mode. Now that we already are in non-secure state, HYP mode switching is within short reach. While doing the non-secure switch, we have to enable the HVC instruction and setup the HYP mode HVBAR (while still secure). The actual switch is done by dropping back from a HYP mode handler without actually leaving HYP mode, so we introduce a new handler routine in our new secure exception vector table. In the assembly switching routine we save and restore the banked LR and SP registers around the hypercall to do the actual HYP mode switch. The C routine first checks whether we are in HYP mode already and also whether the virtualization extensions are available. It also checks whether the HYP mode switch was finally successful. The bootm command part only calls the new function after the non-secure switch. Signed-off-by: Andre Przywara andre.przyw...@linaro.org --- arch/arm/cpu/armv7/Makefile | 2 +- arch/arm/cpu/armv7/nonsec_virt.S | 43 +++- arch/arm/cpu/armv7/virt-v7.c | 37 ++ arch/arm/include/asm/armv7.h | 6 -- arch/arm/lib/bootm.c | 7 ++- 5 files changed, 86 insertions(+), 9 deletions(-) Changes: v3..v4: w/s fixes, embed error output v4..v5: none Seems like Christoffer's comment was not addressed here but IIUC, it was in other files (Christoffer, feel free to comment). Any reason why the older asm comments form was not replaced in here? I think these comments are a bit superflous, but not exactly harmful, so I didn't raise the flag when they were not corrected. My thought was that if you're building for a board that has support for the virtualization extensions you should be using a toolchain that knows about them too, but Andre pointed out that his (I think Debian) still used an old enough cross toolchain not to have this support. In any case, I don't think this warrants holding back the patches but can be fixed as a follow-up if the community agrees that we need to support older toolchains by some define that encodes the hvc and eret instructions properly. Thanks for the answer. Works for me, although I don't believe much in followup fixes once the code is in. Thanks, -Christoffer Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 0/8] ARMv7: Add HYP mode switching support
Hi Andre, On Thu, 19 Sep 2013 18:06:38 +0200, Andre Przywara andre.przyw...@linaro.org wrote: (for GIT URL and Changelog see below) ARM CPUs with the virtualization extension have a new mode called HYP mode, which allows hypervisors to safely control and monitor guests. The current hypervisor implementations (KVM and Xen) require the kernel to be entered in that HYP mode. This patch series introduces a configuration variable CONFIG_ARMV7_VIRT which enables code to switch all cores into HYP mode. This is done automatically during execution of the bootm command. The process of switching into HYP mode requires the CPU to be in secure state initially when entering u-boot, it will then setup some register and switch to non-secure state. This requires the GIC to be programmed properly first. Explanations about the details are in the commit messages of the respective patches. The patches are structured like this: 1/8: prepare header file 2/8: add monitor handler (assembly) 3/8: add per CPU non-secure switch routine (assembly) 4/8: add system wide non-secure setup (C) 5/8: trigger non-secure switch during bootm command 6/8: add generic SMP functionality 7/8: add HYP mode switching 8/8: board specific code for ARM Versatile Express TC2 Since up to patch 6/8 this code works on non-virtualization capable CPUs also and as there has been a request, there is now a second configuration variable CONFIG_ARMV7_NONSEC, which omits the final HYP mode switch and just goes into non-secure SVC state. You can specify either (or none) of them, the code cares about the dependency. The code aims to be as generic as possible, though currently it has only been tested on the Versatile Express TC-2 board. The last patch thus enables the feature for that board and should serve as an example for supporting other boards. I have had reports from different parties of successful adaptions to other boards as well (Arndale, Cubieboard, Chromebook), so I will create a hypmode-ports branch in the below repository to collect those patches and prepare them for upstreaming. For convenience there is a GIT tree which you can pull these patches from (hypmode_v5 branch): git://git.linaro.org/people/aprzywara/u-boot.git Changes RFC..v1 * not a dedicated command anymore, code run by bootm friends * protecting code with #ifdefs to avoid unnecessary inclusion and accidental crashing (when accessing restricted registers) * moving prototypes to header file to meet checkpatch recommendation * adding comment as proposed by Christoffer Changes v1..v2 mostly style and code layout changes * restructure assembly code to live in a new file and not start.S * split smp, nonsec_init and hyp_init to be separate functions * used named constants from common header files * split C function to be more readable * extend comments to be more precise and elaborate * add provision to override GIC base address (needed for Arndale?) * add configuration variable to enable VExpress specific SMP code * use writel/readl for MMIO GIC accesses * remove superfluous isb instructions * more minor fixes Changes v2..v3 * fix clobbering of GICC address actually spoiling the stack * do CNTFRQ setup in assembly per core (and not only once per SoC) * moving the new code files into arch/arm/cpu/armv7 * add config variable for doing non-secure switch only * use actual HYP and secure instructions mnemonics instead of the encoded byte sequence. This requires more recent compilers. * make the identification of the CPU core more robust and saner * use enum for error codes and rename them * lots of smaller layout and style fixes Changes v3..v4 * mask reserved bits in CBAR register * move the VExpress board specific SMP code into the board directory * embed error reporting in the respective functions and getting rid of the error code enum at all (by popular demand ;-) * minor style fixes Changes v4..v5: * remove unneeded padding in exception table * only clear unbanked interrupts in GIC distributor for non-secure * add a default weak implementation for the smp_waitloop() function, there only needs to be provided the address of the SMP pen now * fix compilation error with non-A15 VExpress boards * adding patch specific changelogs for v3..v4 and v4..v5 Please review, comment ... and commit ;-) Contributions and comments to support other boards are welcome. Andre Przywara (8): ARM: prepare armv7.h to be included from assembly source ARM: add secure monitor handler to switch to non-secure state ARM: add assembly routine to switch to non-secure state ARM: add C function to switch to non-secure state ARM: trigger non-secure state switch during bootm execution ARM: add SMP support for non-secure switch ARM: extend non-secure switch to also go into HYP mode ARM: VExpress: enable ARMv7 virt support for VExpress A15 arch/arm/cpu/armv7/Makefile | 5
[U-Boot] [PATCH v4] spi: Add support SH Quad SPI driver
From: Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com
This patch adds a driver for Renesas SoC's Quad SPI bus.
This supports with 8 bits per transfer to use with SPI flash.
Signed-off-by: Kouei Abe kouei.abe...@renesas.com
Signed-off-by: Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
Changes for v4:
- Added tabs
- Added comments
- Added sh_qspi_init()
Changes for v3:
- Change Queued to Quad.
- Remove path of file from file header.
- Use read* and write* directly instead of sh_qspi_write*
sh_qspi_read*.
- Change driver format.
Changes for v2:
- SH QSPI to SH QSPI (Queued SPI).
- Remove magic number.
drivers/spi/Makefile | 1 +
drivers/spi/sh_qspi.c | 248 ++
2 files changed, 249 insertions(+)
create mode 100644 drivers/spi/sh_qspi.c
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 91d24ce..c44f851 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -33,6 +33,7 @@ COBJS-$(CONFIG_OC_TINY_SPI) += oc_tiny_spi.o
COBJS-$(CONFIG_OMAP3_SPI) += omap3_spi.o
COBJS-$(CONFIG_SOFT_SPI) += soft_spi.o
COBJS-$(CONFIG_SH_SPI) += sh_spi.o
+COBJS-$(CONFIG_SH_QSPI) += sh_qspi.o
COBJS-$(CONFIG_FSL_ESPI) += fsl_espi.o
COBJS-$(CONFIG_FDT_SPI) += fdt_spi.o
COBJS-$(CONFIG_TEGRA20_SFLASH) += tegra20_sflash.o
diff --git a/drivers/spi/sh_qspi.c b/drivers/spi/sh_qspi.c
new file mode 100644
index 000..6872142
--- /dev/null
+++ b/drivers/spi/sh_qspi.c
@@ -0,0 +1,248 @@
+/*
+ * SH QSPI (Quad SPI) driver
+ *
+ * Copyright (C) 2013 Renesas Electronics Corporation
+ * Copyright (C) 2013 Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com
+ *
+ * SPDX-License-Identifier:GPL-2.0
+ */
+
+#include common.h
+#include malloc.h
+#include spi.h
+#include asm/io.h
+
+/* SH QSPI register bit masks REG_BIT */
+#define SPCR_MSTR 0x08
+#define SPCR_SPE 0x40
+#define SPSR_SPRFF 0x80
+#define SPSR_SPTEF 0x20
+#define SPPCR_IO3FV0x04
+#define SPPCR_IO2FV0x02
+#define SPPCR_IO1FV0x01
+#define SPBDCR_RXBC0 (1 0)
+#define SPCMD_SCKDEN (1 15)
+#define SPCMD_SLNDEN (1 14)
+#define SPCMD_SPNDEN (1 13)
+#define SPCMD_SSLKP(1 7)
+#define SPCMD_BRDV0(1 2)
+#define SPCMD_INIT1SPCMD_SCKDEN | SPCMD_SLNDEN | \
+ SPCMD_SPNDEN | SPCMD_SSLKP | \
+ SPCMD_BRDV0
+#define SPCMD_INIT2SPCMD_SPNDEN | SPCMD_SSLKP | \
+ SPCMD_BRDV0
+#define SPBFCR_TXRST (1 7)
+#define SPBFCR_RXRST (1 6)
+
+/* SH QSPI register set */
+struct sh_qspi_regs {
+ unsigned char spcr;
+ unsigned char sslp;
+ unsigned char sppcr;
+ unsigned char spsr;
+ unsigned long spdr;
+ unsigned char spscr;
+ unsigned char spssr;
+ unsigned char spbr;
+ unsigned char spdcr;
+ unsigned char spckd;
+ unsigned char sslnd;
+ unsigned char spnd;
+ unsigned char dummy0;
+ unsigned short spcmd0;
+ unsigned short spcmd1;
+ unsigned short spcmd2;
+ unsigned short spcmd3;
+ unsigned char spbfcr;
+ unsigned char dummy1;
+ unsigned short spbdcr;
+ unsigned long spbmul0;
+ unsigned long spbmul1;
+ unsigned long spbmul2;
+ unsigned long spbmul3;
+};
+
+struct sh_qspi_slave {
+ struct spi_slaveslave;
+ struct sh_qspi_regs *regs;
+};
+
+static inline struct sh_qspi_slave *to_sh_qspi(struct spi_slave *slave)
+{
+ return container_of(slave, struct sh_qspi_slave, slave);
+}
+
+static void sh_qspi_init(struct sh_qspi_slave *ss)
+{
+ /* QSPI initialize */
+ writeb(SPCR_MSTR, ss-regs-spcr);
+ writeb(0x00, ss-regs-sslp);
+ writeb(SPPCR_IO3FV|SPPCR_IO2FV, ss-regs-sppcr);
+
+ /* Set bit rate. See 58.3.8 Quad Serial Peripheral Interface */
+ writeb(0x01, ss-regs-spbr);
+
+ writeb(0x00, ss-regs-spdcr);
+ writeb(0x00, ss-regs-spckd);
+ writeb(0x00, ss-regs-sslnd);
+ writeb(0x00, ss-regs-spnd);
+ writew(SPCMD_INIT1, ss-regs-spcmd0);
+ writew(SPCMD_INIT2, ss-regs-spcmd0);
+ writeb(SPBFCR_TXRST|SPBFCR_RXRST, ss-regs-spbfcr);
+ writeb(0x00, ss-regs-spbfcr);
+ writeb(0x00, ss-regs-spscr);
+ writeb(SPCR_SPE|SPCR_MSTR, ss-regs-spcr);
+}
+
+static int sh_qspi_xfer(struct sh_qspi_slave *ss, unsigned char *tdata,
+ unsigned char *rdata, unsigned long flags)
+{
+ while (!(readb(ss-regs-spsr) SPSR_SPTEF)) {
+ if (ctrlc())
+ return 1;
+ udelay(10);
+ }
+
+ writeb(*tdata, (unsigned char *)(ss-regs-spdr));
+
+ while ((readw(ss-regs-spbdcr) != SPBDCR_RXBC0)) {
+ int i = 100;
+
+ if (ctrlc())
+ return 1;
+ while (i--)
+ ;
+ }
+
+ while
Re: [U-Boot] [PATCH v3] spi: Add support SH Quad SPI driver
Ignore this I found.
On Thu, Oct 3, 2013 at 11:28 PM, Jagannadha Sutradharudu Teki
jagannadha.sutradharudu-t...@xilinx.com wrote:
Have you verified this on hw?
Sorry for the late response.
Can you RESEND the patch again- I couldn't find it on patchwork.
Thanks,
Jagan.
-Original Message-
From: Nobuhiro Iwamatsu [mailto:iwama...@nigauri.org] On Behalf Of
Nobuhiro Iwamatsu
Sent: Thursday, August 22, 2013 7:25 AM
To: Jagannadha Sutradharudu Teki
Cc: tr...@ti.com; u-boot@lists.denx.de; jagannadh.t...@gmail.com;
Nobuhiro Iwamatsu; Kouei Abe
Subject: [PATCH v3] spi: Add support SH Quad SPI driver
This patch adds a driver for Renesas SoC's Quad SPI bus.
This supports with 8 bits per transfer to use with SPI flash.
Signed-off-by: Kouei Abe kouei.abe...@renesas.com
Signed-off-by: Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com
---
v3: Change Queued to Quad.
Remove path of file from file header.
Use read* and write* directly instead of sh_qspi_write* sh_qspi_read*.
Change driver format.
v2: Change SH QSPI to SH QSPI (Queued SPI).
Remove magic number.
drivers/spi/Makefile | 1 +
drivers/spi/sh_qspi.c | 248
++
2 files changed, 249 insertions(+)
create mode 100644 drivers/spi/sh_qspi.c
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile index
91d24ce..c44f851 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -33,6 +33,7 @@ COBJS-$(CONFIG_OC_TINY_SPI) += oc_tiny_spi.o
COBJS-$(CONFIG_OMAP3_SPI) += omap3_spi.o
COBJS-$(CONFIG_SOFT_SPI) += soft_spi.o
COBJS-$(CONFIG_SH_SPI) += sh_spi.o
+COBJS-$(CONFIG_SH_QSPI) += sh_qspi.o
COBJS-$(CONFIG_FSL_ESPI) += fsl_espi.o
COBJS-$(CONFIG_FDT_SPI) += fdt_spi.o
COBJS-$(CONFIG_TEGRA20_SFLASH) += tegra20_sflash.o diff --git
a/drivers/spi/sh_qspi.c b/drivers/spi/sh_qspi.c new file mode 100644 index
000..2efaea8
--- /dev/null
+++ b/drivers/spi/sh_qspi.c
@@ -0,0 +1,248 @@
+/*
+ * SH QSPI (Quad SPI) driver
+ *
+ * Copyright (C) 2013 Renesas Electronics Corporation
+ * Copyright (C) 2013 Nobuhiro Iwamatsu
+nobuhiro.iwamatsu...@renesas.com
+ *
+ * SPDX-License-Identifier: GPL-2.0
+ */
+
+#include common.h
+#include malloc.h
+#include spi.h
+#include asm/io.h
+
+/* SPCR */
+#define SPCR_MSTR 0x08
+#define SPCR_SPE 0x40
+
+/* SPSR */
+#define SPSR_SPRFF 0x80
+#define SPSR_SPTEF 0x20
+
+/* SPPCR */
+#define SPPCR_IO3FV 0x04
+#define SPPCR_IO2FV 0x02
+#define SPPCR_IO1FV 0x01
+
+/* SPBDCR */
+#define SPBDCR_RXBC0 (1 0)
+
+/* SPCMD */
+#define SPCMD_SCKDEN (1 15)
+#define SPCMD_SLNDEN (1 14)
+#define SPCMD_SPNDEN (1 13)
+#define SPCMD_SSLKP (1 7)
+#define SPCMD_BRDV0 (1 2)
+#define SPCMD_INIT1 \
+
(SPCMD_SCKDEN|SPCMD_SLNDEN|SPCMD_SPNDEN|SPCMD_SSLKP|
SPCMD_BRDV0)
+#define SPCMD_INIT2 (SPCMD_SPNDEN|SPCMD_SSLKP|SPCMD_BRDV0)
+
+/* SPBFCR */
+#define SPBFCR_TXRST (1 7)
+#define SPBFCR_RXRST (1 6)
+
+/* SH QSPI register set */
+struct sh_qspi_regs {
+ unsigned char spcr;
+ unsigned char sslp;
+ unsigned char sppcr;
+ unsigned char spsr;
+ unsigned long spdr;
+ unsigned char spscr;
+ unsigned char spssr;
+ unsigned char spbr;
+ unsigned char spdcr;
+ unsigned char spckd;
+ unsigned char sslnd;
+ unsigned char spnd;
+ unsigned char dummy0;
+ unsigned short spcmd0;
+ unsigned short spcmd1;
+ unsigned short spcmd2;
+ unsigned short spcmd3;
+ unsigned char spbfcr;
+ unsigned char dummy1;
+ unsigned short spbdcr;
+ unsigned long spbmul0;
+ unsigned long spbmul1;
+ unsigned long spbmul2;
+ unsigned long spbmul3;
+};
+
+struct sh_qspi {
+ struct spi_slaveslave;
+ struct sh_qspi_regs *regs;
+};
+
+static inline struct sh_qspi *to_sh_qspi(struct spi_slave *slave) {
+ return container_of(slave, struct sh_qspi, slave); }
+
+static int sh_qspi_xfer(struct sh_qspi *ss, unsigned char *tdata,
+ unsigned char *rdata, unsigned long flags) {
+ while (!(readb(ss-regs-spsr) SPSR_SPTEF)) {
+ if (ctrlc())
+ return 1;
+ udelay(10);
+ }
+
+ writeb(*tdata, (unsigned char *)(ss-regs-spdr));
+
+ while ((readw(ss-regs-spbdcr) != SPBDCR_RXBC0)) {
+ int i = 100;
+
+ if (ctrlc())
+ return 1;
+ while (i--)
+ ;
+ }
+
+ while (!(readb(ss-regs-spsr) SPSR_SPRFF)) {
+ if (ctrlc())
+ return 1;
+ udelay(10);
+ }
+
+ *rdata = readb((unsigned char *)(ss-regs-spdr));
+
+ return 0;
+}
+
+int spi_cs_is_valid(unsigned int bus, unsigned int cs) {
+ return 1;
+}
+
+void spi_cs_activate(struct spi_slave *slave) { }
+
+void spi_cs_deactivate(struct spi_slave *slave) { }
+
+void spi_init(void)
+{
+ /* nothing to do
Re: [U-Boot] [PATCH v4] spi: Add support SH Quad SPI driver
Hi Nobuhiro Iwamatsu,
I have send your patch for v4.
Eliminated few checks see on change log:
Please fix below comments and try to apply the same on u-boot-spi.git
repo with master-probe branch.
On Fri, Oct 4, 2013 at 1:04 AM, Jagannadha Sutradharudu Teki
jagannadha.sutradharudu-t...@xilinx.com wrote:
From: Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com
This patch adds a driver for Renesas SoC's Quad SPI bus.
This supports with 8 bits per transfer to use with SPI flash.
Signed-off-by: Kouei Abe kouei.abe...@renesas.com
Signed-off-by: Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
Changes for v4:
- Added tabs
- Added comments
- Added sh_qspi_init()
Changes for v3:
- Change Queued to Quad.
- Remove path of file from file header.
- Use read* and write* directly instead of sh_qspi_write*
sh_qspi_read*.
- Change driver format.
Changes for v2:
- SH QSPI to SH QSPI (Queued SPI).
- Remove magic number.
drivers/spi/Makefile | 1 +
drivers/spi/sh_qspi.c | 248
++
2 files changed, 249 insertions(+)
create mode 100644 drivers/spi/sh_qspi.c
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 91d24ce..c44f851 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -33,6 +33,7 @@ COBJS-$(CONFIG_OC_TINY_SPI) += oc_tiny_spi.o
COBJS-$(CONFIG_OMAP3_SPI) += omap3_spi.o
COBJS-$(CONFIG_SOFT_SPI) += soft_spi.o
COBJS-$(CONFIG_SH_SPI) += sh_spi.o
+COBJS-$(CONFIG_SH_QSPI) += sh_qspi.o
COBJS-$(CONFIG_FSL_ESPI) += fsl_espi.o
COBJS-$(CONFIG_FDT_SPI) += fdt_spi.o
COBJS-$(CONFIG_TEGRA20_SFLASH) += tegra20_sflash.o
diff --git a/drivers/spi/sh_qspi.c b/drivers/spi/sh_qspi.c
new file mode 100644
index 000..6872142
--- /dev/null
+++ b/drivers/spi/sh_qspi.c
@@ -0,0 +1,248 @@
+/*
+ * SH QSPI (Quad SPI) driver
+ *
+ * Copyright (C) 2013 Renesas Electronics Corporation
+ * Copyright (C) 2013 Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com
+ *
+ * SPDX-License-Identifier:GPL-2.0
+ */
+
+#include common.h
+#include malloc.h
+#include spi.h
+#include asm/io.h
+
+/* SH QSPI register bit masks REG_BIT */
+#define SPCR_MSTR 0x08
+#define SPCR_SPE 0x40
+#define SPSR_SPRFF 0x80
+#define SPSR_SPTEF 0x20
+#define SPPCR_IO3FV0x04
+#define SPPCR_IO2FV0x02
+#define SPPCR_IO1FV0x01
+#define SPBDCR_RXBC0 (1 0)
+#define SPCMD_SCKDEN (1 15)
+#define SPCMD_SLNDEN (1 14)
+#define SPCMD_SPNDEN (1 13)
+#define SPCMD_SSLKP(1 7)
+#define SPCMD_BRDV0(1 2)
+#define SPCMD_INIT1SPCMD_SCKDEN | SPCMD_SLNDEN | \
+ SPCMD_SPNDEN | SPCMD_SSLKP | \
+ SPCMD_BRDV0
+#define SPCMD_INIT2SPCMD_SPNDEN | SPCMD_SSLKP | \
+ SPCMD_BRDV0
+#define SPBFCR_TXRST (1 7)
+#define SPBFCR_RXRST (1 6)
+
+/* SH QSPI register set */
+struct sh_qspi_regs {
+ unsigned char spcr;
+ unsigned char sslp;
+ unsigned char sppcr;
+ unsigned char spsr;
+ unsigned long spdr;
+ unsigned char spscr;
+ unsigned char spssr;
+ unsigned char spbr;
+ unsigned char spdcr;
+ unsigned char spckd;
+ unsigned char sslnd;
+ unsigned char spnd;
+ unsigned char dummy0;
+ unsigned short spcmd0;
+ unsigned short spcmd1;
+ unsigned short spcmd2;
+ unsigned short spcmd3;
+ unsigned char spbfcr;
+ unsigned char dummy1;
+ unsigned short spbdcr;
+ unsigned long spbmul0;
+ unsigned long spbmul1;
+ unsigned long spbmul2;
+ unsigned long spbmul3;
+};
+
+struct sh_qspi_slave {
+ struct spi_slaveslave;
+ struct sh_qspi_regs *regs;
+};
+
+static inline struct sh_qspi_slave *to_sh_qspi(struct spi_slave *slave)
+{
+ return container_of(slave, struct sh_qspi_slave, slave);
+}
+
+static void sh_qspi_init(struct sh_qspi_slave *ss)
+{
+ /* QSPI initialize */
+ writeb(SPCR_MSTR, ss-regs-spcr);
+ writeb(0x00, ss-regs-sslp);
+ writeb(SPPCR_IO3FV|SPPCR_IO2FV, ss-regs-sppcr);
+
+ /* Set bit rate. See 58.3.8 Quad Serial Peripheral Interface */
+ writeb(0x01, ss-regs-spbr);
+
+ writeb(0x00, ss-regs-spdcr);
+ writeb(0x00, ss-regs-spckd);
+ writeb(0x00, ss-regs-sslnd);
+ writeb(0x00, ss-regs-spnd);
+ writew(SPCMD_INIT1, ss-regs-spcmd0);
+ writew(SPCMD_INIT2, ss-regs-spcmd0);
+ writeb(SPBFCR_TXRST|SPBFCR_RXRST, ss-regs-spbfcr);
+ writeb(0x00, ss-regs-spbfcr);
+ writeb(0x00, ss-regs-spscr);
+ writeb(SPCR_SPE|SPCR_MSTR, ss-regs-spcr);
+}
+
+static int sh_qspi_xfer(struct sh_qspi_slave *ss, unsigned char *tdata,
+ unsigned char *rdata, unsigned long flags)
+{
Re: [U-Boot] [PATCH v6] spi: pl022_spi: Add support for ARM PL022 spi controller
Any update on this. On Wed, Jun 12, 2013 at 9:25 PM, Armando Visconti armando.visco...@st.com wrote: On 06/12/2013 05:29 PM, Jagan Teki wrote: On Wed, Jun 12, 2013 at 8:49 PM, Armando Visconti armando.visco...@st.com wrote: But if you prefer to be on safer side I think we need to re-do some checks on a spare 1340 board... OK, maybe it is better to re-check again. I need to find some time and a spare board... I'll let you know, Arm Do we have an config file available in master, i need to build at-least. Mmmh... currently in mainline there is only spear3xx config file, but there is no PL022 support there. In fact, to compile locally here I had to change it in this way, even if they cannot be used for testing (only compiling): diff --git a/include/configs/spear3xx_evb.h b/include/configs/spear3xx_evb.h index 3cd56dc..03a046e 100644 --- a/include/configs/spear3xx_evb.h +++ b/include/configs/spear3xx_evb.h @@ -54,6 +54,11 @@ /* Ethernet driver configuration */ #define CONFIG_DW_ALTDESCRIPTOR +#define CONFIG_PL022_SPI1 +#define CONFIG_SYS_SPI_BASE 0xE010 +#define CONFIG_SYS_SPI_CLK 8300 +#define CONFIG_CMD_SPI 1 + #if defined(CONFIG_SPEAR310) #define CONFIG_MACB #define CONFIG_MACB0_PHY 0x01 I know that Vipin was going to add support of spear1340 in mainline. His patches are currently already submitted and partially acked but I'm not sure what is the status now... Vipin, can you update us? Rgds, Arm -- Thanks, Jagan. Jagannadha Sutradharudu Teki, E: jagannadh.t...@gmail.com, P: +91-9676773388 Engineer - System Software Hacker U-boot - SPI Custodian and Zynq APSOC Ln: http://www.linkedin.com/in/jaganteki ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 05/12] spi: add Faraday FTSPI010 SPI controller support
Any update on this. On Mon, Aug 12, 2013 at 6:07 AM, Kuo-Jung Su dant...@gmail.com wrote: Please see the comments on below patch http://patchwork.ozlabs.org/patch/265683/ -- Got it, thanks -- Best wishes, Kuo-Jung Su -- Thanks, Jagan. Jagannadha Sutradharudu Teki, E: jagannadh.t...@gmail.com, P: +91-9676773388 Engineer - System Software Hacker U-boot - SPI Custodian and Zynq APSOC Ln: http://www.linkedin.com/in/jaganteki ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2 V3] spi: exynos: Support a delay after deactivate
Any update on this! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] : SPI patches
Hi Rajeswari, Below is a list of pending patches on my queue: http://patchwork.ozlabs.org/patch/247461/ http://patchwork.ozlabs.org/patch/247457/ http://patchwork.ozlabs.org/patch/247452/ http://patchwork.ozlabs.org/patch/247451/ http://patchwork.ozlabs.org/patch/247450/ Request you to fix my comments and re-base the same on to u-boot-spi.git repo with master-probe branch. Please test this new branch with your changes and let me know for any issues/concerns. -- Thanks, Jagan. Jagannadha Sutradharudu Teki, E: jagannadh.t...@gmail.com, P: +91-9676773388 Engineer - System Software Hacker U-boot - SPI Custodian and Zynq APSOC Ln: http://www.linkedin.com/in/jaganteki ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-arm/master
Hello Tom, The following changes since commit f04c53762962280365005c9db12ab561a18f2692: Merge branch 'u-boot-imx/master' into 'u-boot-arm/master' (2013-10-02 14:53:27 +0200) are available in the git repository at: git://git.denx.De/u-boot-arm master for you to fetch changes up to e261c83aa04ce0396d57aaecf8dfe0970ffac03e: ARM: VExpress: enable ARMv7 virt support for VExpress A15 (2013-10-03 21:28:57 +0200) Andre Przywara (8): ARM: prepare armv7.h to be included from assembly source ARM: add secure monitor handler to switch to non-secure state ARM: add assembly routine to switch to non-secure state ARM: add C function to switch to non-secure state ARM: trigger non-secure state switch during bootm execution ARM: add SMP support for non-secure switch ARM: extend non-secure switch to also go into HYP mode ARM: VExpress: enable ARMv7 virt support for VExpress A15 arch/arm/cpu/armv7/Makefile | 5 + arch/arm/cpu/armv7/nonsec_virt.S| 208 arch/arm/cpu/armv7/virt-v7.c| 173 ++ arch/arm/include/asm/armv7.h| 33 - arch/arm/include/asm/gic.h | 19 +++ arch/arm/lib/bootm.c| 18 +++ board/armltd/vexpress/vexpress_common.c | 15 +++ include/common.h| 2 + include/configs/vexpress_ca15_tc2.h | 5 +- 9 files changed, 476 insertions(+), 2 deletions(-) create mode 100644 arch/arm/cpu/armv7/nonsec_virt.S create mode 100644 arch/arm/cpu/armv7/virt-v7.c create mode 100644 arch/arm/include/asm/gic.h Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, u-boot, RFC, v1] sdp4430: Initialize board id using CONFIG_MACH_TYPE
Hi Tom, On Wed, 28 Aug 2013 14:25:25 -0400, Tom Rini tr...@ti.com wrote: On Tue, Aug 06, 2013 at 02:03:27PM +0300, Oleksandr Tyshchenko wrote: Use CONFIG_MACH_TYPE generic macro to set the machine type number in the common arm code instead of setting it in the board code. Signed-off-by: Oleksandr Tyshchenko oleksandr.tyshche...@ti.com Applied to u-boot-ti/master, thanks! So it was not an RFC, then? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC] ARM: U-boot and 2 GiB of ram with get_ram_size only being long
Hey all, I just yesterday received my CubieTruck (cubieboard3) with 2 GiB of Ram and added support for it to the sunxi-u-boot branch. While I know this isn't merged into the main u-boot tree (yet), I ran into the following problem. At the end of the dram init code, it is customary to call get_ram_size() and return its value. This is then used to print the DRAM size and also is passed to the Linux kernel. However the return size of get_ram_size() is a long. While I don't understand why not unsigned long or even u64 was chosen, this causes get_dram_size to overflow when having a ramsize of 2 GiB. While only printing of the value isn't hugely important, this does indicate u-boot seems to be somewhat artificially limited to 2 GiB of Ram? This only seems to affect the SPL as, if I understood correctly, there it stores the ram_size into the gd struct which I think is unsigned long. I've started working on a patch to convert common/memsize.c's get_ram_size(), to be completely unsigned long, however there seems to be quite a lot of code that calls this. So my question is now before going over all drivers and change that and submit a big patch-set, did I overlook anything and are my conclusions correct, get_ram_size should return unsigned long. Finally, a long is 32 bits on x86 and armv7, but how will that relate to 64bits armv8? As I understood, Windows treats long's as 4 bytes no matter if it's 32 bit or 64 bit. Linux is better and a long is 4 bytes on 32 bits, and 8 bytes on 64 bits versions. So how will u-boot work on armv8? Will the long datatype work well, or should I consider changing things more future proof? (u32 and u64 come to mind). Thank you for any input regarding that issue. Oliver ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Merge and reformat boards.cfg and MAINTAINERS
Hi Masahiro, On Fri, 27 Sep 2013 20:05:35 +0900, Masahiro Yamada yamad...@jp.panasonic.com wrote: Hello Albert I set the board state in the new board.cfg to Orphan if and only if the board was listed in such an unknown / orphan section, and to Active in any other case. This implies that: - some boards were present in the old boards.cfg but not listed in MAINTAINERS (e.g. sh7785lcr), which means there are Active boards which do not have a maintainer; - some unknown / orphan boards had a last known maintainer address specified (e.g. EVB64260_750CX), which means there are Orphan boards which have a maintainer listed. To sum up things, boards have actually 3 states: (1) Active: had a maintainer in the original MAINTAINERS file (2) Orphan: listed under unknown/orphan in the original MAINTAINERS file (3) maybe Active, maybe Orphan: not mentioned in the original MAINTAINERS file You pushed both (1) and (3) into Active state in the new boards.cfg although many boards in (3) might not have a maintainer. In such a case, what is the meaning to categorize into Active or Orphan? IOW, a board's state (Active or Orphan) has no formal relationship with this board having maintainers or not; the state only determines whether this board should be built (Active) or not (Orphan). I think unknown/orphan stands for no maintainers in the original MAINTAINERS file. Now you recongnize this as Should not be built. Is this the same meaning? As far as I can tell, it is the same meaning -- by that I mean I compared the build counts before and after the change and found no difference. Note that if a board was found orphan, it means that there was an attempt to contact the maintainer and it failed. And if there was an attempt to contact the maintainer, chances are it was because the board had issues. In my opinion, 'Orphan' might be a misleading term for the latter. Active / Dead ? How abount reconsidering a bit more about this categorization? If you feel that there should be a renaming, feel free to submit patches. The only risk I see is that the name Active is used by the makefiles to find out which boards it should build, so if you change that in boards.cfg, you'll have to change it in the makefile(s) too. Best Regards Masahiro Yamada Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Dual boot Images in Flash
Dear pshambhu, In message 1380783611628-164588.p...@n7.nabble.com you wrote: Thanks for the feedback, for the customization of u-boot_stub, the main file start.S needs to be changed i guess, the u-boot_stub has to perform only CRC check. after performing it should goto u_boot1/u_boot2 address and then it should start booting. I think you still fail to see the real issues with any such approach. What makes you think the fact that the CRC checksum is correct could actually mean that the image is really working? It only means that there is a pretty good chance that it has not been corrupted - it does NOT give you any additional reason to trust it would be good. How can i customize the u-boot_stub or generate the start.S file which perform only CRC calculation and switching address of u_boot1/u_boot2 , which performs booting. Well, just implement what you think needs to be done... Note that I don't think that you could get what you want this way. 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 A list is only as strong as its weakest link.-- Don Knuth ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] mx28evk: Use 512k for fdt partition to align it
Dear Otavio Salvador, In message 1380801056-11923-1-git-send-email-ota...@ossystems.com.br you wrote: Using 512k for fdt partition allow it to be aligned with the other small partitions and 512k erase block size. Signed-off-by: Otavio Salvador ota...@ossystems.com.br --- include/configs/mx28evk.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h index 07f88ca..27b1a41 100644 --- a/include/configs/mx28evk.h +++ b/include/configs/mx28evk.h @@ -97,7 +97,7 @@ 512k(environment),\ 512k(redundant-environment), \ 4m(kernel), \ - 128k(fdt),\ + 512k(fdt),\ 8m(ramdisk), \ -(filesystem) Are you positively sure there is a 0.5 MiB erase block size? Which exact NAND device is this? Sorry for asking, there is no NAND at all on the mx28evk in our lab, so I really have no clue... 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 If you're out of tree, you don't exist. - David Woodhouse in 1304620350.2398.29.ca...@i7.infradead.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] mx28evk: Use 512k for fdt partition to align it
On Thu, Oct 3, 2013 at 6:48 PM, Wolfgang Denk w...@denx.de wrote: Dear Otavio Salvador, In message 1380801056-11923-1-git-send-email-ota...@ossystems.com.br you wrote: Using 512k for fdt partition allow it to be aligned with the other small partitions and 512k erase block size. Signed-off-by: Otavio Salvador ota...@ossystems.com.br --- include/configs/mx28evk.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h index 07f88ca..27b1a41 100644 --- a/include/configs/mx28evk.h +++ b/include/configs/mx28evk.h @@ -97,7 +97,7 @@ 512k(environment),\ 512k(redundant-environment), \ 4m(kernel), \ - 128k(fdt),\ + 512k(fdt),\ 8m(ramdisk), \ -(filesystem) Are you positively sure there is a 0.5 MiB erase block size? Which exact NAND device is this? Sorry for asking, there is no NAND at all on the mx28evk in our lab, so I really have no clue... Sure; it does. It is a 4G NAND. The part# is K9LBG08U0D-PCB0 -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v13 1/6] core support of arm64
On 10/03/2013 02:51 PM, Rob Herring wrote:
On 10/03/2013 04:35 PM, Rob Herring wrote:
On 09/26/2013 08:35 AM, feng...@phytium.com.cn wrote:
From: David Feng feng...@phytium.com.cn
Signed-off-by: David Feng feng...@phytium.com.cn
---
arch/arm/config.mk |4 +
FYI, some recent mainline changes to config.mk break the build for me.
arch/arm/cpu/armv8/Makefile | 38 +
arch/arm/cpu/armv8/cache.S | 130 +
arch/arm/cpu/armv8/cache_v8.c | 218
arch/arm/cpu/armv8/config.mk| 16 +++
arch/arm/cpu/armv8/cpu.c| 67 +
arch/arm/cpu/armv8/exceptions.S | 115 +++
arch/arm/cpu/armv8/start.S | 234
+++
arch/arm/cpu/armv8/timer.c | 80 +++
arch/arm/cpu/armv8/tlb.S| 30
arch/arm/cpu/armv8/u-boot.lds | 71 ++
arch/arm/include/asm/arch-armv8/gpio.h | 11 ++
arch/arm/include/asm/arch-armv8/mmu.h | 110 +++
Also, this directory is mutually exclusive with arch-${soc}. I think
this should be moved up a level. gpio.h is probably fine as a default
version.
I am also concerned about gpio.h. I am forced to create a gpio.h file
even I don't use it when I add soc for armv8.
York
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v13 1/6] core support of arm64
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/03/2013 05:54 PM, York Sun wrote:
On 10/03/2013 02:51 PM, Rob Herring wrote:
On 10/03/2013 04:35 PM, Rob Herring wrote:
On 09/26/2013 08:35 AM, feng...@phytium.com.cn wrote:
From: David Feng feng...@phytium.com.cn
Signed-off-by: David Feng feng...@phytium.com.cn
---
arch/arm/config.mk |4 +
FYI, some recent mainline changes to config.mk break the build for me.
arch/arm/cpu/armv8/Makefile | 38 +
arch/arm/cpu/armv8/cache.S | 130 +
arch/arm/cpu/armv8/cache_v8.c | 218
arch/arm/cpu/armv8/config.mk| 16 +++
arch/arm/cpu/armv8/cpu.c| 67 +
arch/arm/cpu/armv8/exceptions.S | 115 +++
arch/arm/cpu/armv8/start.S | 234
+++
arch/arm/cpu/armv8/timer.c | 80 +++
arch/arm/cpu/armv8/tlb.S| 30
arch/arm/cpu/armv8/u-boot.lds | 71 ++
arch/arm/include/asm/arch-armv8/gpio.h | 11 ++
arch/arm/include/asm/arch-armv8/mmu.h | 110 +++
Also, this directory is mutually exclusive with arch-${soc}. I think
this should be moved up a level. gpio.h is probably fine as a default
version.
I am also concerned about gpio.h. I am forced to create a gpio.h file
even I don't use it when I add soc for armv8.
Yes, gpio.h belongs elsewhere, and we should not be making symlinks for
arch-armv8, we should just have asm/armv8/ and asm/armv7/ and reference
them directly,
- --
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJSTefxAAoJENk4IS6UOR1WzkgQAK61cVCUk2ouSKChMs0bZkIf
xjiNzN+YSAjE49P5APl6Ai6XbIWUVNWlZnRwbZC3rAl7QsTM0c8tcx8G3e54QDQT
pvbH4nvpj79Zjkc48Td7C5ZP+pw+vXshkXnUJrGKQe5AUPnP6DFGbILHn1gcSDj9
IusRDO1+sr0zuyU9XTKopmWQvPddFoUUwsA3KaFAoqDQeuBWW/lbYiETbDRnPGdz
e9hmq7sX9j6iE2Q5Vut8OuiZdvF677AL2eoFhk4NZ25KDaTP0cAltvpFcrZheGrt
vBKkpAFiKeuZG6CDEhJu22OHGLrQb266WpqqzHyGnAoqYpUahfxOfP+Z/31SaNBz
T1TnPfgNTCmy5LxG/msXeYXR6CJg0uIXvQnBJk/oRAA+xyxEwIeEXpmMyTtC2ZPy
cHeBgeLUo2QetMtMEOyrnt/xauOjRU5s252qniRPfaSLOSbyF4ElxDMNcU0amOYH
ay+bp7cgmsIuMJV/Oza9k/SH+wkMlERud5gY85U3MUmNUSCt3UfOdwTZSOMnAucM
//Dli/bsD+MegfO+aXG/nDWDPkpIqfFwHYlbrLORD5LhUFPqTliZepj9U5ACFBc6
b6H0crU134XBfsWtlDs3ZvPFberP9THU0tmreAwPtDtAKkl2SG0VqV+P4obxXH/G
o4V7jZg+eLHSm1mMYgmz
=WywE
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, u-boot, RFC, v1] sdp4430: Initialize board id using CONFIG_MACH_TYPE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/03/2013 05:15 PM, Albert ARIBAUD wrote: Hi Tom, On Wed, 28 Aug 2013 14:25:25 -0400, Tom Rini tr...@ti.com wrote: On Tue, Aug 06, 2013 at 02:03:27PM +0300, Oleksandr Tyshchenko wrote: Use CONFIG_MACH_TYPE generic macro to set the machine type number in the common arm code instead of setting it in the board code. Signed-off-by: Oleksandr Tyshchenko oleksandr.tyshche...@ti.com Applied to u-boot-ti/master, thanks! So it was not an RFC, then? Yes, there was nothing really RFC-worthy here, it was a small change. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSTegtAAoJENk4IS6UOR1WAqYP/0khzMI3hCrC4T9C8Abyuw9o XB3kH1pJ3mQCtoLP0jsPGeZP6dlDNQ9h50DXO46V1Juam/cPc7o2C3r/bYO7uwMx /a9r4Z5TCQ7oPDsirMVvf5flTgPrY76Q8IK9diiv2N/OJzmIVjGfo2rMWjRRUBWP 48S/HlF+5jQNSUrqa5P8hx0NYuxv+3i0eoTM82zAF/kN4xPgVT+ThktGn8kmJZHz EcHizUjXKSZwrqYC0735/PhIBjRefNgpcX0k6cnP0XcjT6N35f++Yvik8i1lLdBW PMk2MO2Y1LGjK9OKh58oZQ6QicZmpkwii0fCE0rihXE1eJEw3glljVlityn4pVj0 1evZpqqXzsEg8XI0neAQwD2n98knzv64mR5Tp27m/sgkr5n38EK0YPVydcQAMyle b2VIgO19h05GalTXC3itmcQmBq3ZL2PwW2UC/ZHTOyHLR8YuWwAax4SrvyTCfA8n 3hrPJ88bWEMaYgyeJFsfzjM80tTtW0347ZH9Zph1ymoVxMw9uQomn31C5hI7V95h 9bggRCH8XItynokq+qmOYVdFTAfuFYJUpUc6niHn+CzbM9o0EbwLBf5/U+2ij6PG r4VJLCBgR2ow4p2ATfEae/1zZIm39ZeooI6FMXFOafKt3x9FZlBaUpJj14uO/tSc lVoZngsvsXVGk5LkKb7I =kq6T -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v13 1/6] core support of arm64
On 10/03/2013 04:35 PM, Rob Herring wrote:
On 09/26/2013 08:35 AM, feng...@phytium.com.cn wrote:
From: David Feng feng...@phytium.com.cn
Signed-off-by: David Feng feng...@phytium.com.cn
---
arch/arm/config.mk |4 +
FYI, some recent mainline changes to config.mk break the build for me.
arch/arm/cpu/armv8/Makefile | 38 +
arch/arm/cpu/armv8/cache.S | 130 +
arch/arm/cpu/armv8/cache_v8.c | 218
arch/arm/cpu/armv8/config.mk| 16 +++
arch/arm/cpu/armv8/cpu.c| 67 +
arch/arm/cpu/armv8/exceptions.S | 115 +++
arch/arm/cpu/armv8/start.S | 234
+++
arch/arm/cpu/armv8/timer.c | 80 +++
arch/arm/cpu/armv8/tlb.S| 30
arch/arm/cpu/armv8/u-boot.lds | 71 ++
arch/arm/include/asm/arch-armv8/gpio.h | 11 ++
arch/arm/include/asm/arch-armv8/mmu.h | 110 +++
Also, this directory is mutually exclusive with arch-${soc}. I think
this should be moved up a level. gpio.h is probably fine as a default
version.
Rob
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v13 6/6] add weak entry definition
On 09/26/2013 08:35 AM, feng...@phytium.com.cn wrote: From: David Feng feng...@phytium.com.cn Signed-off-by: David Feng feng...@phytium.com.cn --- include/linux/linkage.h |4 1 file changed, 4 insertions(+) This patch should come before adding core v8 support. Rob diff --git a/include/linux/linkage.h b/include/linux/linkage.h index 9ddf830..2a2848a 100644 --- a/include/linux/linkage.h +++ b/include/linux/linkage.h @@ -49,6 +49,10 @@ .globl SYMBOL_NAME(name); \ LENTRY(name) +#define WEAK(name) \ + .weak SYMBOL_NAME(name); \ + LENTRY(name) + #ifndef END #define END(name) \ .size name, .-name ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] arm64: Add tool to statically apply RELA relocations
ARM64 uses the newer RELA-style relocations rather than the older REL.
RELA relocations have an addend in the relocation struct, rather than
expecting the loader to read a value from the location to be updated.
While this is beneficial for ordinary program loading, it's problematic
for U-Boot because the location to be updated starts out with zero,
rather than a pre-relocation value. Since we need to be able to run C
code before relocation, we need a tool to apply the relocations at
build time.
In theory this tool is applicable to other newer architectures (mainly
64-bit), but currently the only relocations it supports are for arm64,
and it assumes a 64-bit little-endian target. If the latter limitation
is ever to be changed, we'll need a way to tell the tool what format
the image is in. Eventually this may be replaced by a tool that uses
libelf or similar and operates directly on the ELF file. I've written
some code for such an approach but libelf does not make it easy to poke
addresses by memory address (rather than by section), and I was
hesitant to write code to manually parse the program headers and do the
update outside of libelf (or to iterate over sections) -- especially
since it wouldn't get test coverage on things like binaries with
multiple PT_LOAD segments. This should be good enough for now to let
the manual relocation stuff be removed from the arm64 patches.
Signed-off-by: Scott Wood scottw...@freescale.com
---
Makefile | 12
tools/Makefile| 6 ++
tools/relocate-rela.c | 185 ++
3 files changed, 203 insertions(+)
create mode 100644 tools/relocate-rela.c
diff --git a/Makefile b/Makefile
index 07abef4..5024dd8 100644
--- a/Makefile
+++ b/Makefile
@@ -392,6 +392,17 @@ else
BOARD_SIZE_CHECK =
endif
+# Statically apply RELA-style relocations (currently arm64 only)
+ifneq ($(CONFIG_STATIC_RELA),)
+# $(1) is u-boot ELF, $(2) is u-boot bin, $(3) is text base
+DO_STATIC_RELA = \
+ start=$$($(NM) $(1) | grep __rel_dyn_start | cut -f 1 -d ' '); \
+ end=$$($(NM) $(1) | grep __rel_dyn_end | cut -f 1 -d ' '); \
+ $(obj)tools/relocate-rela $(2) $(3) $$start $$end
+else
+DO_STATIC_RELA =
+endif
+
# Always append ALL so that arch config.mk's can add custom ones
ALL-y += $(obj)u-boot.srec $(obj)u-boot.bin $(obj)System.map
@@ -431,6 +442,7 @@ $(obj)u-boot.srec: $(obj)u-boot
$(obj)u-boot.bin: $(obj)u-boot
$(OBJCOPY) ${OBJCFLAGS} -O binary $ $@
+ $(call DO_STATIC_RELA,$,$@,$(CONFIG_SYS_TEXT_BASE))
$(BOARD_SIZE_CHECK)
$(obj)u-boot.ldr: $(obj)u-boot
diff --git a/tools/Makefile b/tools/Makefile
index c36cde2..a5eb85e 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -59,6 +59,7 @@ BIN_FILES-$(CONFIG_NETCONSOLE) += ncb$(SFX)
BIN_FILES-$(CONFIG_SHA1_CHECK_UB_IMG) += ubsha1$(SFX)
BIN_FILES-$(CONFIG_KIRKWOOD) += kwboot$(SFX)
BIN_FILES-y += proftool(SFX)
+BIN_FILES-$(CONFIG_STATIC_RELA) += relocate-rela$(SFX)
# Source files which exist outside the tools directory
EXT_OBJ_FILES-$(CONFIG_BUILD_ENVCRC) += common/env_embedded.o
@@ -84,6 +85,7 @@ NOPED_OBJ_FILES-y += os_support.o
NOPED_OBJ_FILES-y += pblimage.o
NOPED_OBJ_FILES-y += proftool.o
NOPED_OBJ_FILES-y += ublimage.o
+NOPED_OBJ_FILES-y += relocate-rela.o
OBJ_FILES-$(CONFIG_BUILD_ENVCRC) += envcrc.o
OBJ_FILES-$(CONFIG_CMD_LOADS) += img2srec.o
OBJ_FILES-$(CONFIG_CMD_NET) += gen_eth_addr.o
@@ -250,6 +252,10 @@ $(obj)kwboot$(SFX): $(obj)kwboot.o
$(HOSTCC) $(HOSTCFLAGS) $(HOSTLDFLAGS) -o $@ $^
$(HOSTSTRIP) $@
+$(obj)relocate-rela$(SFX): $(obj)relocate-rela.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 $@ $
diff --git a/tools/relocate-rela.c b/tools/relocate-rela.c
new file mode 100644
index 000..47afe0b
--- /dev/null
+++ b/tools/relocate-rela.c
@@ -0,0 +1,185 @@
+/*
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+ BSD-2-Clause
+ *
+ * 64-bit and little-endian target only until we need to support a different
+ * arch that needs this.
+ */
+
+#include elf.h
+#include errno.h
+#include inttypes.h
+#include stdarg.h
+#include stdbool.h
+#include stdio.h
+#include stdlib.h
+#include string.h
+
+static const bool debug_en;
+
+static void debug(const char *fmt, ...)
+{
+ va_list args;
+
+ va_start(args, fmt);
+ if (debug_en)
+ vprintf(fmt, args);
+}
+
+static bool supported_rela(Elf64_Rela *rela)
+{
+ uint64_t mask = 0xULL; /* would be different on 32-bit */
+ uint32_t type = rela-r_info mask;
+
+ switch (type) {
+#ifdef R_AARCH64_RELATIVE
+ case R_AARCH64_RELATIVE:
+ return true;
+#endif
+ default:
+ fprintf(stderr, warning:
[U-Boot] [PATCH 4/4] arm64: Make checkarmreloc accept arm64 relocations
Signed-off-by: Scott Wood scottw...@freescale.com --- Makefile | 14 +- arch/arm/config.mk | 2 -- 2 files changed, 9 insertions(+), 7 deletions(-) diff --git a/Makefile b/Makefile index 1938f60..20d48e9 100644 --- a/Makefile +++ b/Makefile @@ -805,12 +805,16 @@ tools: $(VERSION_FILE) $(TIMESTAMP_FILE) $(MAKE) -C $@ all endif # config.mk -# ARM relocations should all be R_ARM_RELATIVE. +# ARM relocations should all be R_ARM_RELATIVE (32-bit) or +# R_AARCH64_RELATIVE (64-bit). checkarmreloc: $(obj)u-boot - @if test R_ARM_RELATIVE != \ - `$(CROSS_COMPILE)readelf -r $ | cut -d ' ' -f 4 | grep R_ARM | sort -u`; \ - then echo $ contains relocations other than \ - R_ARM_RELATIVE; false; fi + @RELOC=`$(CROSS_COMPILE)readelf -r -W $ | cut -d ' ' -f 4 | \ + grep R_A | sort -u`; \ + if test $$RELOC != R_ARM_RELATIVE -a \ +$$RELOC != R_AARCH64_RELATIVE; then \ + echo $ contains unexpected relocations: $$RELOC; \ + false; \ + fi $(VERSION_FILE): @mkdir -p $(dir $(VERSION_FILE)) diff --git a/arch/arm/config.mk b/arch/arm/config.mk index 96d2d88..ce3903b 100644 --- a/arch/arm/config.mk +++ b/arch/arm/config.mk @@ -95,8 +95,6 @@ endif endif # check that only R_ARM_RELATIVE relocations are generated -ifndef CONFIG_ARM64 ifneq ($(CONFIG_SPL_BUILD),y) ALL-y += checkarmreloc endif -endif -- 1.8.1.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] arm64: Turn u-boot.bin back into an ELF file after relocate-rela
While performing relocations on u-boot.bin should be good enough for booting on real hardware, some simulators insist on booting an ELF file (and yet don't perform ELF relocations), so convert the relocated binary back into an ELF file. This can go away in the future if we change relocate-rela to operate directly on the ELF file, or if and when we stop caring about a simulator with this restriction. Signed-off-by: Scott Wood scottw...@freescale.com --- Makefile | 13 + 1 file changed, 13 insertions(+) diff --git a/Makefile b/Makefile index 5024dd8..1938f60 100644 --- a/Makefile +++ b/Makefile @@ -415,6 +415,7 @@ ALL-$(CONFIG_OF_SEPARATE) += $(obj)u-boot.dtb $(obj)u-boot-dtb.bin ifneq ($(CONFIG_SPL_TARGET),) ALL-$(CONFIG_SPL) += $(obj)$(subst ,,$(CONFIG_SPL_TARGET)) endif +ALL-$(CONFIG_REMAKE_ELF) += $(obj)u-boot.elf # enable combined SPL/u-boot/dtb rules for tegra ifneq ($(CONFIG_TEGRA),) @@ -581,6 +582,18 @@ $(obj)u-boot-img-spl-at-end.bin: $(obj)spl/u-boot-spl.bin $(obj)u-boot.img conv=notrunc 2/dev/null cat $(obj)u-boot-pad.img $(obj)spl/u-boot-spl.bin $@ +# Create a new ELF from a raw binary file. This is useful for arm64 +# where static relocation needs to be performed on the raw binary, +# but certain simulators only accept an ELF file (but don't do the +# relocation). +# FIXME refactor dts/Makefile to share target/arch detection +$(obj)u-boot.elf: $(obj)u-boot.bin + @$(OBJCOPY) -B aarch64 -I binary -O elf64-littleaarch64 \ + $ $(obj)u-boot-elf.o + @$(LD) $(obj)u-boot-elf.o -o $@ \ + --defsym=_start=$(CONFIG_SYS_TEXT_BASE) \ + -Ttext=$(CONFIG_SYS_TEXT_BASE) + ifeq ($(CONFIG_SANDBOX),y) GEN_UBOOT = \ cd $(LNDIR) $(CC) $(SYMS) -T $(obj)u-boot.lds \ -- 1.8.1.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/4] arm64: rela relocation
This lets us remove the manual relocation stuff from the arm64 patchset (the symbol itself is removed by this patchset, but not all the new manual relocations added by the arm64 patchset). I'm not terribly happy with the way relocate-rela is now, versus something cleaner that operates on the ELF file, but it's good enough for now and waiting longer to get rid of the manual relocations would be worse. This patchset is based on David's arm64 patchset v13. David, the first two patches should be applied before your arm64 patches. Maybe the fourth as well (except for the removal of the arm64 ifdef you added, which would then need to be squashed with your patch). The third patch should be squashed with your patches (plus you should remove the manual relocs). Scott Wood (4): arm64: Add tool to statically apply RELA relocations arm64: Turn u-boot.bin back into an ELF file after relocate-rela arm64: Non-manual relocation arm64: Make checkarmreloc accept arm64 relocations Makefile | 39 ++-- arch/arm/config.mk| 4 - arch/arm/cpu/armv8/config.mk | 1 - arch/arm/cpu/armv8/u-boot.lds | 32 +-- arch/arm/include/asm/config.h | 5 -- arch/arm/lib/crt0_64.S| 7 +- arch/arm/lib/relocate_64.S| 41 - include/configs/vexpress_aemv8a.h | 3 + tools/Makefile| 6 ++ tools/relocate-rela.c | 185 ++ 10 files changed, 276 insertions(+), 47 deletions(-) create mode 100644 tools/relocate-rela.c -- 1.8.1.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] arm64: Non-manual relocation
This turns off CONFIG_NEEDS_MANUAL_RELOC and turns on -pie.
The bss part of the linker script is changed to be more like arm32,
as the previous arm64 approach was generating bad relocations (even
readelf didn't like them).
relocate_64.S is made to look more like relocate.S, and then changed to
support RELA style relocations rather than REL.
Signed-off-by: Scott Wood scottw...@freescale.com
---
arch/arm/config.mk| 2 --
arch/arm/cpu/armv8/config.mk | 1 -
arch/arm/cpu/armv8/u-boot.lds | 32 +++---
arch/arm/include/asm/config.h | 5 -
arch/arm/lib/crt0_64.S| 7 ++-
arch/arm/lib/relocate_64.S| 41 ---
include/configs/vexpress_aemv8a.h | 3 +++
7 files changed, 51 insertions(+), 40 deletions(-)
diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index 95c07ad..96d2d88 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -74,9 +74,7 @@ endif
endif
# needed for relocation
-ifndef CONFIG_ARM64
LDFLAGS_u-boot += -pie
-endif
#
# FIXME: binutils versions 2.22 have a bug in the assembler where
diff --git a/arch/arm/cpu/armv8/config.mk b/arch/arm/cpu/armv8/config.mk
index 9f36d59..027a68c 100644
--- a/arch/arm/cpu/armv8/config.mk
+++ b/arch/arm/cpu/armv8/config.mk
@@ -13,4 +13,3 @@ PLATFORM_NO_UNALIGNED := $(PF_NO_UNALIGNED)
PF_CPPFLAGS_ARMV8 := $(call cc-option, -march=armv8-a)
PLATFORM_CPPFLAGS += $(PF_CPPFLAGS_ARMV8)
PLATFORM_CPPFLAGS += $(PF_NO_UNALIGNED)
-PLATFORM_CPPFLAGS += -fpic
diff --git a/arch/arm/cpu/armv8/u-boot.lds b/arch/arm/cpu/armv8/u-boot.lds
index 328d477..4c1 100644
--- a/arch/arm/cpu/armv8/u-boot.lds
+++ b/arch/arm/cpu/armv8/u-boot.lds
@@ -41,25 +41,43 @@ SECTIONS
}
. = ALIGN(8);
- .reloc : {
- __rel_got_start = .;
- *(.got)
- __rel_got_end = .;
- }
.image_copy_end :
{
*(.__image_copy_end)
}
+ . = ALIGN(8);
+
+ .rel_dyn_start :
+ {
+ *(.__rel_dyn_start)
+ }
+
+ .rela.dyn : {
+ *(.rela*)
+ }
+
+ .rel_dyn_end :
+ {
+ *(.__rel_dyn_end)
+ }
+
_end = .;
. = ALIGN(8);
+
+ .bss_start : {
+ KEEP(*(.__bss_start));
+ }
+
.bss : {
- __bss_start = .;
*(.bss*)
. = ALIGN(8);
- __bss_end = .;
+ }
+
+ .bss_end : {
+ KEEP(*(.__bss_end));
}
/DISCARD/ : { *(.dynsym) }
diff --git a/arch/arm/include/asm/config.h b/arch/arm/include/asm/config.h
index 0ee131d..de4d01e 100644
--- a/arch/arm/include/asm/config.h
+++ b/arch/arm/include/asm/config.h
@@ -11,11 +11,6 @@
#define CONFIG_SYS_BOOT_RAMDISK_HIGH
#ifdef CONFIG_ARM64
-/*
- * Currently, GOT is used to relocate u-boot and
- * configuration CONFIG_NEEDS_MANUAL_RELOC is needed.
- */
-#define CONFIG_NEEDS_MANUAL_RELOC
#define CONFIG_PHYS_64BIT
#endif
diff --git a/arch/arm/lib/crt0_64.S b/arch/arm/lib/crt0_64.S
index ddd46eb..7756396 100644
--- a/arch/arm/lib/crt0_64.S
+++ b/arch/arm/lib/crt0_64.S
@@ -94,11 +94,8 @@ relocation_return:
/*
* Clear BSS section
*/
- ldr x9, [x18, #GD_RELOC_OFF]/* x9 - gd-reloc_off */
- ldr x0, =__bss_start
- add x0, x0, x9 /* x0 - __bss_start in RAM */
- ldr x1, =__bss_end
- add x1, x1, x9 /* x1 - __bss_end in RAM */
+ ldr x0, =__bss_start/* this is auto-relocated! */
+ ldr x1, =__bss_end /* this is auto-relocated! */
mov x2, #0
clear_loop:
str x2, [x0]
diff --git a/arch/arm/lib/relocate_64.S b/arch/arm/lib/relocate_64.S
index 29c3239..7fba9e2 100644
--- a/arch/arm/lib/relocate_64.S
+++ b/arch/arm/lib/relocate_64.S
@@ -16,40 +16,41 @@
* void relocate_code (addr_moni)
*
* This function relocates the monitor code.
- *
- * NOTE:
- * GOT is used and configuration CONFIG_NEEDS_MANUAL_RELOC is needed.
+ * x0 holds the destination address.
*/
ENTRY(relocate_code)
/*
* Copy u-boot from flash to RAM
*/
- ldr x1, =__image_copy_start /* x1 - copy source */
- cmp x1, x0
+ ldr x1, =__image_copy_start /* x1 - SRC __image_copy_start */
+ subsx9, x0, x1 /* x9 - relocation offset */
b.eqrelocate_done /* skip relocation */
- mov x2, x0 /* x2 - copy destination */
- ldr x3, =__image_copy_end /* x3 - source end address */
+ ldr x2, =__image_copy_end /* x2 - SRC __image_copy_end */
copy_loop:
ldp x10, x11, [x1], #16 /* copy from source address [x1] */
- stp x10, x11, [x2], #16 /* copy to target address [x2] */
- cmp x1, x3 /* until source end
Re: [U-Boot] [PATCH v2 01/19] Makefile: prepare for using Kbuild-style Makefile
Hi, On Thu, Sep 26, 2013 at 5:51 AM, Masahiro Yamada yamad...@jp.panasonic.comwrote: In every sub directory, Makefile is like follows: include $(TOPDIR)/config.mk LIB = $(obj)libfoo.o COBJS := ... COBJS += ... SOBJS := ... SRCS:= $(SOBJS:.o=.S) $(COBJS:.o=.c) OBJS:= $(addprefix $(obj),$(COBJS) $(SOBJS)) all: $(obj).depend $(LIB) $(LIB): $(OBJS) $(call cmd_link_o_target, $(OBJS)) # include $(SRCTREE)/rules.mk sinclude $(obj).depend # Top and bottom parts are common in almost all sub-makefiles. This is a big waste. This commit pushes common parts of makefiles into script/Makefile.build. Going forward sub-makefiles only need to describe this part: COBJS := ... COBJS += ... SOBJS := ... But, script/Makefile.build includes the glue code to support obj-y, the following style (the same as Kbuild) is preferable: obj-y := ... obj-$(CONFIG_FOO) += ... obj-$(CONFIG_BAR) += ... The conventional (non-Kbuild) Makefile style is still supported. This is achieved by greping the Makefile before entering into it. U-Boot conventional sub makefiles always include some other makefiles. So the build system searches a line beginning with include keyword in the makefile in order to distinguish which style it is. If the Makefile include a include line, we assume it is a conventional U-Boot style. Otherwise, it is treated as a Kbuild-style makefile. (At first, I tried to grep rules.mk keyword instead, but I found it does not work. Almost all sub makefiles include rules.mk, but there exist three exception: - board/avnet/fx12mm/Makefile - board/avnet/v5fx30teval/Makefile - board/xilinx/ml507/Makefile These three makefiles include rules.mk indirectly. Anyway, they look weird, so they should be fixed lator.) With this tweak, we can switch sub-makefiles from U-Boot style to Kbuild style little by little. This refactoring of sub makefiles is the first step towards Kbuild, and makes it easy to import a real Kbuild from Linux Kernel. Note that this refactoring breaks nothing because it just moves the common parts into scripts/Makefile.build. Note one more thing: obj-y := foo/ # descending into foo sub directory syntax is not supported yet. (This feature will be implemented in the upcoming commit.) Of course, scripts/Makefile.build added by this commit is temporary. It shall be replaced with the one of Linux Kernel in future. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Simon Glass s...@chromium.org Cc: Tom Rini tr...@ti.com --- Changes for v2: - fix commit log (purely cosmetic) Makefile | 34 ++ scripts/Makefile.build | 48 spl/Makefile | 20 ++-- 3 files changed, 96 insertions(+), 6 deletions(-) create mode 100644 scripts/Makefile.build diff --git a/Makefile b/Makefile index 07abef4..36bbd09 100644 --- a/Makefile +++ b/Makefile @@ -593,14 +593,35 @@ ifeq ($(CONFIG_KALLSYMS),y) $(GEN_UBOOT) $(obj)common/system_map.o endif +# Tentative step for Kbuild-style makefiles coexist with conventional U-Boot style makefiles +# U-Boot conventional sub makefiles always include some other makefiles. +# So, the build system searches a line beginning with include before entering into the sub makefile +# in order to distinguish which style it is. Would looking for obj- be better or worse? +# If the Makefile include a include line, we assume it is an U-Boot style makefile. +# Otherwise, it is treated as a Kbuild-style makefile. + +# We do not need to build $(OBJS) explicitly. +# It is built while we are at $(CPUDIR)/lib$(CPU).o build. $(OBJS): depend - $(MAKE) -C $(CPUDIR) $(if $(REMOTE_BUILD),$@,$(notdir $@)) + if grep -q ^include $(CPUDIR)/Makefile; then \ + $(MAKE) -C $(CPUDIR) $(if $(REMOTE_BUILD),$@,$(notdir $@)); \ an indent might help here, and below. + fi $(LIBS): depend $(SUBDIR_TOOLS) - $(MAKE) -C $(dir $(subst $(obj),,$@)) + if grep -q ^include $(dir $(subst $(obj),,$@))Makefile; then \ This check seems to appear a lot - could it become a $(call ...) perhaps? + $(MAKE) -C $(dir $(subst $(obj),,$@)); \ + else \ + $(MAKE) -C $(dir $(subst $(obj),,$@)) -f $(TOPDIR)/scripts/Makefile.build; \ + mv $(dir $@)built-in.o $@; \ + fi $(LIBBOARD): depend $(LIBS) - $(MAKE) -C $(dir $(subst $(obj),,$@)) + if grep -q ^include $(dir $(subst $(obj),,$@))/Makefile; then \ + $(MAKE) -C $(dir
Re: [U-Boot] [PATCH v2 17/19] sandbox: convert makefiles to Kbuild style
On Thu, Sep 26, 2013 at 5:51 AM, Masahiro Yamada yamad...@jp.panasonic.comwrote: Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Simon Glass s...@chromium.org --- Changes for v2 - No change arch/sandbox/cpu/Makefile | 23 +-- arch/sandbox/lib/Makefile | 25 + 2 files changed, 2 insertions(+), 46 deletions(-) Acked-by: Simon Glass s...@chromium.org Seems to work for me. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] config.mk: Add -Wundef to CFLAGS
Hi, On Wed, Oct 2, 2013 at 1:27 PM, Albert ARIBAUD albert.u.b...@aribaud.netwrote: Hi Masahiro, On Wed, 21 Aug 2013 13:33:19 +0900, Masahiro Yamada yamad...@jp.panasonic.com wrote: Hello, Albert and U-Boot developers. The current status of this patch is Changes Requested. I love -Wundef option to be in, but it looks like difficult for me to post the version 2. The first choice to meet Albert's requirement is Therefore I ask: - that this patch be submitted along fixes to build failures it causes, as a proper patch series, by a single individual, Sorry, I cannot do this because: I am not familiar with architectures other than ARM. I understand only a few devices. To fix warnings in a correct way, a close look is often needed, but I cannot cover the whole code in the U-Boot tree. If possible, could anyone take over this task? The other option is collected by someone in an officially created git repo or branch; OK, I can do this. But I am not sure this will go well. Even if I create a new repo u-boot-wundef, how many people will pay attention to this repository? Most of users/developers track upstream repos where -Wundef warnings are never displayed. This means no one will have the motivation to fix the warnings. If this patch is desired, in which way should we continue? Comments are welcome. Sorry not to have followed up earlier. As I said, I want fixes for trivial cases -- cases where, for instance, a macro is used in an #if which has absolutely *no* definition in the whole codebase. I do not want fixes for all cases. OTOH, to find out which failures would be trivial to fix and which ones would not, you'd have to go through all of them, which could be time-consuming, depending on the number of targets. I thus suggest we use the typical U-Boot strategy: right at the beginning of the merge period, we apply the -Wundef patch onto all repos (or on the main repo and then pulled into others) and then wait for screams. Screams should come fst from custodians, who routinely build for all targets of their assigned architecture. They will see which boards fail due to undefined macros and will report those failures on the list, copying the board maintainers (or subsystem owners if the issue is not board-specific. All boards not fixed before merge window closure release will be declared dying; all those not fixed before 2014.01 will be declared dead, and orphaned and put in the scrapyard (and then, people who want them back can always resurrect *and fix* them). Subsystems... will have to be fixed some way or other. Of course, anyone with an interest can spontaneously provide fixes for boards or subsystems affected. Adding Tom and Wolfgang for advice, but of course comments are welcome from everyone. Breaking a board by introducing a warning is bad, I don't think we can do that. But fixing common.h would be easy enough at least. Can you run buildman on all boards and see how many files generate warnings? Regards, Simon Best Regards, Masahiro Yamada Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/6] Second step towards Kbuild: Descend down like Kbuild
Hi Masahiro, On Mon, Sep 30, 2013 at 2:23 AM, Masahiro Yamada yamad...@jp.panasonic.comwrote: Note: Update for v3 is the only patch subjects. The patch body is the same as v2. I have been just wondering why the U-Boot top Makefile is so dirty. It is sprinkled with SoC-specific code as follows: ifneq ($(CONFIG_OMAP_COMMON),) LIBS-y += $(CPUDIR)/omap-common/libomap-common.o endif ifneq (,$(filter $(SOC), mx25 mx27 mx5 mx6 mx31 mx35 mxs vf610)) LIBS-y += arch/$(ARCH)/imx-common/libimx-common.o endif ifeq ($(SOC),s5pc1xx) LIBS-y += $(CPUDIR)/s5p-common/libs5p-common.o endif ifeq ($(SOC),exynos) LIBS-y += $(CPUDIR)/s5p-common/libs5p-common.o endif ifneq ($(CONFIG_TEGRA),) LIBS-y += arch/$(ARCH)/cpu/$(SOC)-common/lib$(SOC)-common.o LIBS-y += arch/$(ARCH)/cpu/tegra-common/libcputegra-common.o LIBS-y += $(CPUDIR)/tegra-common/libtegra-common.o endif And it describes drivers not right under the top directory, which should be essentially cared by drivers/Makefile. LIBS-y += drivers/bios_emulator/libatibiosemu.o LIBS-y += drivers/block/libblock.o LIBS-$(CONFIG_BOOTCOUNT_LIMIT) += drivers/bootcount/libbootcount.o LIBS-y += drivers/crypto/libcrypto.o LIBS-y += drivers/dma/libdma.o ... This series adds the directory descending feature like Kbuild. 1/6 tweaks scripts/Makefile.build to support 'obj-y += foo/' syntax. If the build system finds 'foo/' (trailed by a slash), it visits foo directory. 2/6-6/6 demonstarate how we can refactor makefiles with this syntax. 2/6: Move some drivers LIBS from top Makefile to drivers/Makefile 3/6: Move some fs LIBS from top Makefile to fs/Makefile 4/6: Move Tegra specific lines from top Makefile under arch/arm/ 5/6: Move OMAP specific lines from top Makefile under arch/arm/ 6/6: Move Samsung SoC specific lines from top Makefile under arch/arm/ Note: This series uses [PATCH v2]First step towards Kbuild: Use Kbuild-style makefiles (19 patch files). as a prerequisite. Please apply those patches first. I believe no boards are broken by this refactoring. In order to confirm my claim, I compiled all boards except nds32 and nios2 architrecutures. (I could not get an appropriate prebuilt cross compilers for those two arch.) For arm, avr32, sandbox, x86, I could perfectly compile all boards without any warnings. For the other architectures, I could compile some boards and I could not the others. But the SUMMARY result is still the same after applying this series. In addition I compared all the error and warning messages for all boards and they are the same. This means these patches do not introduce any additional errors, warnings. Cc: Simon Glass s...@chromium.org Cc: Tom Rini tr...@ti.com Changes for v3: 1/6 - 3/6: No change 4/6 - 6/6: Fix mesleading patch subject (No change in body) Changes for v2: 1/6: No change 2/6: additionally refactor drivers/pcmcia drivers/rtc too 3/6, 4/6: No change 5/6: rebase on the master 6/6: No change Masahiro Yamada (6): Makefile: support descending down to subdirectories drivers: move some drivers to drivers/Makefile fs: move some file system to fs/Makefile ARM: tegra: delete Tegra specific code from toplevel Makefile ARM: omap: delete OMAP specific code from toplevel Makefile ARM: s5pc, exynos: delete Samsung ARM SoC specific code from toplevel Makefile Makefile | 44 +++ arch/arm/cpu/Makefile | 2 ++ arch/arm/cpu/arm720t/Makefile | 2 ++ arch/arm/cpu/armv7/Makefile | 9 + board/LEOX/elpt860/u-boot.lds | 1 - board/tqc/tqm8xx/u-boot.lds | 4 ++-- drivers/Makefile | 15 +++ fs/Makefile | 11 +++ scripts/Makefile.build| 15 +++ spl/Makefile | 14 +- 10 files changed, 60 insertions(+), 57 deletions(-) create mode 100644 arch/arm/cpu/Makefile create mode 100644 drivers/Makefile Can you please explain why you need to change the .lds files - sorry it is not obvious to me. Regards, Simon -- 1.8.1.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/9] net: tsec: Use portable types and accessors for BDs
On Mon, Sep 30, 2013 at 4:44 AM, Claudiu Manoil claudiu.man...@freescale.com wrote: +#define GET_BD_STAT(T, i) be16_to_cpu((__force __be16)T##BD(i).status) +#define SET_BD_STAT(T, i, v) T##BD(i).status = (__force __u16)cpu_to_be16(v) +#define GET_BD_BLEN(T, i) be16_to_cpu((__force __be16)T##BD(i).length) +#define SET_BD_BLEN(T, i, v) T##BD(i).length = (__force __u16)cpu_to_be16(v) +#define GET_BD_BPTR(T, i) be32_to_cpu((__force __be32)T##BD(i).bufptr) +#define SET_BD_BPTR(T, i, v) T##BD(i).bufptr = (__force __u32)cpu_to_be32(v) This is pretty ugly. There's got to be a better way to handle this. Are you going to be doing stuff like this for every driver for bi-endian hardware? Some time ago I suggest that we re-purpose iowrite() and ioread() to be native-endian, and not just little endian. I think something like that would make more sense than hacky macros like this. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6] spi: pl022_spi: Add support for ARM PL022 spi controller
On 10/4/2013 1:22 AM, Jagan Teki wrote: Any update on this. This should already be in u-boot mainline Regards Vipin On Wed, Jun 12, 2013 at 9:25 PM, Armando Visconti armando.visco...@st.com wrote: On 06/12/2013 05:29 PM, Jagan Teki wrote: On Wed, Jun 12, 2013 at 8:49 PM, Armando Visconti armando.visco...@st.com wrote: But if you prefer to be on safer side I think we need to re-do some checks on a spare 1340 board... OK, maybe it is better to re-check again. I need to find some time and a spare board... I'll let you know, Arm Do we have an config file available in master, i need to build at-least. Mmmh... currently in mainline there is only spear3xx config file, but there is no PL022 support there. In fact, to compile locally here I had to change it in this way, even if they cannot be used for testing (only compiling): diff --git a/include/configs/spear3xx_evb.h b/include/configs/spear3xx_evb.h index 3cd56dc..03a046e 100644 --- a/include/configs/spear3xx_evb.h +++ b/include/configs/spear3xx_evb.h @@ -54,6 +54,11 @@ /* Ethernet driver configuration */ #define CONFIG_DW_ALTDESCRIPTOR +#define CONFIG_PL022_SPI1 +#define CONFIG_SYS_SPI_BASE 0xE010 +#define CONFIG_SYS_SPI_CLK 8300 +#define CONFIG_CMD_SPI 1 + #if defined(CONFIG_SPEAR310) #define CONFIG_MACB #define CONFIG_MACB0_PHY 0x01 I know that Vipin was going to add support of spear1340 in mainline. His patches are currently already submitted and partially acked but I'm not sure what is the status now... Vipin, can you update us? Rgds, Arm ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3][v5] board/c29xpcie: Add support of 8K page size NAND flash
Defines constants required to support 8K page size NAND flash. Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com --- Changes for v2:Sending as it is Changes for v3:Sending as it is Changes for v4:Sending as it is Changes for v5:Sending as it is include/configs/C29XPCIE.h | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/include/configs/C29XPCIE.h b/include/configs/C29XPCIE.h index 83779ef..6a1e145 100644 --- a/include/configs/C29XPCIE.h +++ b/include/configs/C29XPCIE.h @@ -189,13 +189,14 @@ | CSPR_MSEL_NAND \ | CSPR_V) #define CONFIG_SYS_NAND_AMASK IFC_AMASK(64*1024) +#define CONFIG_SYS_NAND_OOBSIZE0x0280 /* 640b */ #define CONFIG_SYS_NAND_CSOR (CSOR_NAND_ECC_ENC_EN /* ECC on encode */ \ | CSOR_NAND_ECC_DEC_EN /* ECC on decode */ \ | CSOR_NAND_ECC_MODE_4 /* 4-bit ECC */ \ - | CSOR_NAND_RAL_2 /* RAL = 2 Bytes */ \ - | CSOR_NAND_PGS_2K /* Page Size = 2k */ \ - | CSOR_NAND_SPRZ_64 /* Spare size = 64 */ \ - | CSOR_NAND_PB(64)) /* 64 Pages Per Block */ + | CSOR_NAND_RAL_3 /* RAL = 3 Bytes */ \ + | CSOR_NAND_PGS_8K /* Page Size = 8K */ \ + | CSOR_NAND_SPRZ_CSOR_EXT /*oob in csor_ext*/\ + | CSOR_NAND_PB(128))/*128 Pages Per Block*/ #define CONFIG_SYS_NAND_FTIM0 (FTIM0_NAND_TCCST(0x01) | \ FTIM0_NAND_TWP(0x0c) | \ FTIM0_NAND_TWCHT(0x08) | \ @@ -222,6 +223,7 @@ #define CONFIG_SYS_CSPR1 CONFIG_SYS_NAND_CSPR #define CONFIG_SYS_AMASK1 CONFIG_SYS_NAND_AMASK #define CONFIG_SYS_CSOR1 CONFIG_SYS_NAND_CSOR +#define CONFIG_SYS_CSOR1_EXT CONFIG_SYS_NAND_OOBSIZE #define CONFIG_SYS_CS1_FTIM0 CONFIG_SYS_NAND_FTIM0 #define CONFIG_SYS_CS1_FTIM1 CONFIG_SYS_NAND_FTIM1 #define CONFIG_SYS_CS1_FTIM2 CONFIG_SYS_NAND_FTIM2 -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3][v5] mtd/ifc: Add support of 8K page size NAND flash
Current IFC driver supports till 4K page size NAND flash. Add support of 8K NAND flash - Program Spare region size in csor_ext - Add nand_ecclayout for 4 bit 8 bit ecc - Defines constants - Add support of 8K NAND boot. Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com CC: Liu Po po@freescale.com --- Changes for v2: sending as it is Changes for v3: Incorporated Liu Po's commetns - Updated fsl_ifc_spl 8K if conditional check Changes for v4: fix SPL 8K condition check Changes for v5: - Fixed compile warning - Used CSOR_NAND_PGS_MASK arch/powerpc/cpu/mpc8xxx/fsl_ifc.c | 24 +++ arch/powerpc/include/asm/fsl_ifc.h |2 + drivers/mtd/nand/fsl_ifc_nand.c| 78 drivers/mtd/nand/fsl_ifc_spl.c |7 +++- 4 files changed, 109 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/cpu/mpc8xxx/fsl_ifc.c b/arch/powerpc/cpu/mpc8xxx/fsl_ifc.c index 2d0fb43..64a5225 100644 --- a/arch/powerpc/cpu/mpc8xxx/fsl_ifc.c +++ b/arch/powerpc/cpu/mpc8xxx/fsl_ifc.c @@ -34,6 +34,9 @@ void init_early_memctl_regs(void) #ifdef CONFIG_SYS_CSPR0_EXT set_ifc_cspr_ext(IFC_CS0, CONFIG_SYS_CSPR0_EXT); #endif +#ifdef CONFIG_SYS_CSOR0_EXT + set_ifc_csor_ext(IFC_CS0, CONFIG_SYS_CSOR0_EXT); +#endif set_ifc_cspr(IFC_CS0, CONFIG_SYS_CSPR0); set_ifc_amask(IFC_CS0, CONFIG_SYS_AMASK0); set_ifc_csor(IFC_CS0, CONFIG_SYS_CSOR0); @@ -43,6 +46,9 @@ void init_early_memctl_regs(void) #ifdef CONFIG_SYS_CSPR1_EXT set_ifc_cspr_ext(IFC_CS1, CONFIG_SYS_CSPR1_EXT); #endif +#ifdef CONFIG_SYS_CSOR1_EXT + set_ifc_csor_ext(IFC_CS1, CONFIG_SYS_CSOR1_EXT); +#endif #if defined(CONFIG_SYS_CSPR1) defined(CONFIG_SYS_CSOR1) set_ifc_ftim(IFC_CS1, IFC_FTIM0, CONFIG_SYS_CS1_FTIM0); set_ifc_ftim(IFC_CS1, IFC_FTIM1, CONFIG_SYS_CS1_FTIM1); @@ -57,6 +63,9 @@ void init_early_memctl_regs(void) #ifdef CONFIG_SYS_CSPR2_EXT set_ifc_cspr_ext(IFC_CS2, CONFIG_SYS_CSPR2_EXT); #endif +#ifdef CONFIG_SYS_CSOR2_EXT + set_ifc_csor_ext(IFC_CS2, CONFIG_SYS_CSOR2_EXT); +#endif #if defined(CONFIG_SYS_CSPR2) defined(CONFIG_SYS_CSOR2) set_ifc_ftim(IFC_CS2, IFC_FTIM0, CONFIG_SYS_CS2_FTIM0); set_ifc_ftim(IFC_CS2, IFC_FTIM1, CONFIG_SYS_CS2_FTIM1); @@ -71,6 +80,9 @@ void init_early_memctl_regs(void) #ifdef CONFIG_SYS_CSPR3_EXT set_ifc_cspr_ext(IFC_CS3, CONFIG_SYS_CSPR3_EXT); #endif +#ifdef CONFIG_SYS_CSOR3_EXT + set_ifc_csor_ext(IFC_CS3, CONFIG_SYS_CSOR3_EXT); +#endif #if defined(CONFIG_SYS_CSPR3) defined(CONFIG_SYS_CSOR3) set_ifc_ftim(IFC_CS3, IFC_FTIM0, CONFIG_SYS_CS3_FTIM0); set_ifc_ftim(IFC_CS3, IFC_FTIM1, CONFIG_SYS_CS3_FTIM1); @@ -85,6 +97,9 @@ void init_early_memctl_regs(void) #ifdef CONFIG_SYS_CSPR4_EXT set_ifc_cspr_ext(IFC_CS4, CONFIG_SYS_CSPR4_EXT); #endif +#ifdef CONFIG_SYS_CSOR4_EXT + set_ifc_csor_ext(IFC_CS4, CONFIG_SYS_CSOR4_EXT); +#endif #if defined(CONFIG_SYS_CSPR4) defined(CONFIG_SYS_CSOR4) set_ifc_ftim(IFC_CS4, IFC_FTIM0, CONFIG_SYS_CS4_FTIM0); set_ifc_ftim(IFC_CS4, IFC_FTIM1, CONFIG_SYS_CS4_FTIM1); @@ -99,6 +114,9 @@ void init_early_memctl_regs(void) #ifdef CONFIG_SYS_CSPR5_EXT set_ifc_cspr_ext(IFC_CS5, CONFIG_SYS_CSPR5_EXT); #endif +#ifdef CONFIG_SYS_CSOR5_EXT + set_ifc_csor_ext(IFC_CS5, CONFIG_SYS_CSOR5_EXT); +#endif #if defined(CONFIG_SYS_CSPR5) defined(CONFIG_SYS_CSOR5) set_ifc_ftim(IFC_CS5, IFC_FTIM0, CONFIG_SYS_CS5_FTIM0); set_ifc_ftim(IFC_CS5, IFC_FTIM1, CONFIG_SYS_CS5_FTIM1); @@ -113,6 +131,9 @@ void init_early_memctl_regs(void) #ifdef CONFIG_SYS_CSPR6_EXT set_ifc_cspr_ext(IFC_CS6, CONFIG_SYS_CSPR6_EXT); #endif +#ifdef CONFIG_SYS_CSOR6_EXT + set_ifc_csor_ext(IFC_CS6, CONFIG_SYS_CSOR6_EXT); +#endif #if defined(CONFIG_SYS_CSPR6) defined(CONFIG_SYS_CSOR6) set_ifc_ftim(IFC_CS6, IFC_FTIM0, CONFIG_SYS_CS6_FTIM0); set_ifc_ftim(IFC_CS6, IFC_FTIM1, CONFIG_SYS_CS6_FTIM1); @@ -127,6 +148,9 @@ void init_early_memctl_regs(void) #ifdef CONFIG_SYS_CSPR7_EXT set_ifc_cspr_ext(IFC_CS7, CONFIG_SYS_CSPR7_EXT); #endif +#ifdef CONFIG_SYS_CSOR7_EXT + set_ifc_csor_ext(IFC_CS7, CONFIG_SYS_CSOR7_EXT); +#endif #if defined(CONFIG_SYS_CSPR7) defined(CONFIG_SYS_CSOR7) set_ifc_ftim(IFC_CS7, IFC_FTIM0, CONFIG_SYS_CS7_FTIM0); set_ifc_ftim(IFC_CS7, IFC_FTIM1, CONFIG_SYS_CS7_FTIM1); diff --git a/arch/powerpc/include/asm/fsl_ifc.h b/arch/powerpc/include/asm/fsl_ifc.h index a945e4b..182b1a6 100644 --- a/arch/powerpc/include/asm/fsl_ifc.h +++ b/arch/powerpc/include/asm/fsl_ifc.h @@ -77,6 +77,7 @@ #define CSOR_NAND_PGS_512 0x #define CSOR_NAND_PGS_2K 0x0008 #define CSOR_NAND_PGS_4K 0x0010 +#define CSOR_NAND_PGS_8K 0x0018 /* Spare region Size */ #define CSOR_NAND_SPRZ_MASK0xE000 #define CSOR_NAND_SPRZ_SHIFT 13 @@ -86,6 +87,7 @@
