Re: [U-Boot] Compilation of env error u-boot 2015.07-rc2

[Thirumalesha N]

Hi Franklin,

Sorry for late response

On Wednesday, June 10, 2015, Cooper Jr., Franklin  wrote:

>
>
> > -Original Message-
> > From: Maxin B. John [mailto:maxin.j...@enea.com ]
> > Sent: Wednesday, June 10, 2015 4:10 AM
> > To: Thirumalesha N
> > Cc: u-boot@lists.denx.de ; Cooper Jr., Franklin;
> tr...@konsulko.com 
> > Subject: Re: [U-Boot] Compilation of env error u-boot 2015.07-rc2
> >
> > Hi,
> >
> > On Wed, Jun 10, 2015 at 10:29:47AM +0530, Thirumalesha N wrote:
> > > Hi all,
> > >
> > > I have pulled latest code from u-boot main line through git.
> > >
> > > Using linaro tool chain for am335x board
> > >
> > > I'm trying to compile tools/env but its giving an error
> > >
> > > #make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- env
> > >
> > > HOSTCC tools/env/fw_env.o
> > >
> > > arm-linux-gnueabihf/include/search.h:173:1 erro: expected '}' before
> > > 'NETARGS'
> > > make[1]: *** [ tools/env/few.env.o] error 1
> >
> > I have managed to re-create the same problem.
> >
> > Revert this commit: 2320866b978fc12904eeba37236f35d12b4aec30
> > ie:
> > # git revert 2320866b978fc12904eeba37236f35d12b4aec30
> >
> > and then try building again.
> >
> > Apparently network arguments were moved to ti_armv7_common.h.
> > However, it wasn't included in the am335x config.
> [Franklin] I haven't used make env before but from my understanding there
> is no config for it. The other configs for am335x that I saw all had
> CONFIG_CMD_NET enabled. So I'm guessing that when doing make env
> CONFIG_CMD_NET isn't enabled which is why we get that error. I just sent a
> patch that fixed this error.


I agree, CONFIG_CMD_NET Is the issue. I have tried to include the
generated/autoconf.h in include/defaults.h that's solve the issue but I
didnt do thoroug test, if it gets effect for other configurations.



> >
> > >
> > > With same tool chain I'm able compile 2014 u-boot
> > >
> > > Regards,
> > > Thiru N
> >
> > Best Regards,
> > Maxin
>

Regards,
Thiru N
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] gpio: mxc_gpio: enable DM gpio before relocation

[Markus Niebel]

Hello Simon,

Am 16.06.2015 um 23:44 schrieb Simon Glass:
> Hi Markus,
> 
> On 16 June 2015 at 01:08, Markus Niebel  wrote:
>> From: Markus Niebel 
>>
>> gpio often are needed to detect revision and variants.
>> Therefore gpio should be available ASAP.
>>
>> Signed-off-by: Markus Niebel 
>> ---
>>  drivers/gpio/mxc_gpio.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/gpio/mxc_gpio.c b/drivers/gpio/mxc_gpio.c
>> index 2012f99..925758a 100644
>> --- a/drivers/gpio/mxc_gpio.c
>> +++ b/drivers/gpio/mxc_gpio.c
>> @@ -330,6 +330,7 @@ U_BOOT_DRIVER(gpio_mxc) = {
>> .priv_auto_alloc_size = sizeof(struct mxc_bank_info),
>> .of_match = mxc_gpio_ids,
>> .bind   = mxc_gpio_bind,
>> +   .flags  = DM_FLAG_PRE_RELOC,
>>  };
>>
>>  #ifndef CONFIG_OF_CONTROL
>> --
>> 2.3.0
>>
> 
> This should really be done in the device tree with the
> u-boot,dm-pre-reloc property for the particular GPIO banks you need. I
> don't think this should be a global setting.
> 

I totally agree for the longer run - but tegra gpio does it the same way.

Regards,
Markus
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v4 6/6] x86: crownbay: Add MP initialization

[Bin Meng]

Intel Crown Bay board has a TunnelCreek processor which supports
hyper-threading. Add /cpus node in the crownbay.dts and enable
the MP initialization.

Signed-off-by: Bin Meng 
Acked-by: Simon Glass 

---

Changes in v4: None
Changes in v3: None
Changes in v2:
- Move CONFIG_MAX_CPUS after CONFIG_SMP in crownbay_defconfig to
  match the order in Kconfig

 arch/x86/dts/crownbay.dts  | 20 
 configs/crownbay_defconfig |  4 
 2 files changed, 24 insertions(+)

diff --git a/arch/x86/dts/crownbay.dts b/arch/x86/dts/crownbay.dts
index d68efda..1ec90cd 100644
--- a/arch/x86/dts/crownbay.dts
+++ b/arch/x86/dts/crownbay.dts
@@ -23,6 +23,26 @@
silent_console = <0>;
};
 
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu@0 {
+   device_type = "cpu";
+   compatible = "cpu-x86";
+   reg = <0>;
+   intel,apic-id = <0>;
+   };
+
+   cpu@1 {
+   device_type = "cpu";
+   compatible = "cpu-x86";
+   reg = <1>;
+   intel,apic-id = <1>;
+   };
+
+   };
+
gpioa {
compatible = "intel,ich6-gpio";
u-boot,dm-pre-reloc;
diff --git a/configs/crownbay_defconfig b/configs/crownbay_defconfig
index d3a370d..d21177d 100644
--- a/configs/crownbay_defconfig
+++ b/configs/crownbay_defconfig
@@ -2,6 +2,10 @@ CONFIG_X86=y
 CONFIG_VENDOR_INTEL=y
 CONFIG_DEFAULT_DEVICE_TREE="crownbay"
 CONFIG_TARGET_CROWNBAY=y
+CONFIG_SMP=y
+CONFIG_MAX_CPUS=2
 CONFIG_GENERATE_PIRQ_TABLE=y
+CONFIG_CMD_CPU=y
 CONFIG_CMD_NET=y
 CONFIG_OF_CONTROL=y
+CONFIG_CPU=y
-- 
1.8.2.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v4 5/6] x86: Clean up lapic codes

[Bin Meng]

This commit cleans up the lapic codes:
- Delete arch/x86/include/asm/lapic_def.h, and move register and bit
  defines into arch/x86/include/asm/lapic.h
- Use MSR defines from msr-index.h in enable_lapic() and disable_lapic()
- Remove unnecessary stuff like NEED_LAPIC, X86_GOOD_APIC and
  CONFIG_AP_IN_SIPI_WAIT
- Move struct x86_cpu_priv defines to asm/arch-ivybridge/bd82x6x.h, as
  it is not apic related and only used by ivybridge
- Fix coding convention issues

Signed-off-by: Bin Meng 
Acked-by: Simon Glass 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/x86/cpu/ivybridge/model_206ax.c  |   2 +-
 arch/x86/cpu/lapic.c  |  38 
 arch/x86/include/asm/arch-ivybridge/bd82x6x.h |  14 ++-
 arch/x86/include/asm/lapic.h  | 131 ++
 arch/x86/include/asm/lapic_def.h  | 101 
 5 files changed, 103 insertions(+), 183 deletions(-)
 delete mode 100644 arch/x86/include/asm/lapic_def.h

diff --git a/arch/x86/cpu/ivybridge/model_206ax.c 
b/arch/x86/cpu/ivybridge/model_206ax.c
index 8b08c40..fd7db97 100644
--- a/arch/x86/cpu/ivybridge/model_206ax.c
+++ b/arch/x86/cpu/ivybridge/model_206ax.c
@@ -13,12 +13,12 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 
 static void enable_vmx(void)
diff --git a/arch/x86/cpu/lapic.c b/arch/x86/cpu/lapic.c
index 4690603..6769ae5 100644
--- a/arch/x86/cpu/lapic.c
+++ b/arch/x86/cpu/lapic.c
@@ -8,50 +8,46 @@
  */
 
 #include 
-#include 
-#include 
 #include 
 #include 
 
 void lapic_setup(void)
 {
-#if NEED_LAPIC == 1
+#ifdef CONFIG_SMP
/* Only Pentium Pro and later have those MSR stuff */
debug("Setting up local apic: ");
 
/* Enable the local apic */
enable_lapic();
 
-   /*
-* Set Task Priority to 'accept all'.
-*/
+   /* Set Task Priority to 'accept all' */
lapic_write_around(LAPIC_TASKPRI,
   lapic_read_around(LAPIC_TASKPRI) & ~LAPIC_TPRI_MASK);
 
/* Put the local apic in virtual wire mode */
lapic_write_around(LAPIC_SPIV, (lapic_read_around(LAPIC_SPIV) &
-   ~(LAPIC_VECTOR_MASK)) | LAPIC_SPIV_ENABLE);
+  ~(LAPIC_VECTOR_MASK)) | LAPIC_SPIV_ENABLE);
lapic_write_around(LAPIC_LVT0, (lapic_read_around(LAPIC_LVT0) &
-   ~(LAPIC_LVT_MASKED | LAPIC_LVT_LEVEL_TRIGGER |
- LAPIC_LVT_REMOTE_IRR | LAPIC_INPUT_POLARITY |
- LAPIC_SEND_PENDING | LAPIC_LVT_RESERVED_1 |
- LAPIC_DELIVERY_MODE_MASK)) |
-   (LAPIC_LVT_REMOTE_IRR | LAPIC_SEND_PENDING |
-LAPIC_DELIVERY_MODE_EXTINT));
+  ~(LAPIC_LVT_MASKED | LAPIC_LVT_LEVEL_TRIGGER |
+  LAPIC_LVT_REMOTE_IRR | LAPIC_INPUT_POLARITY |
+  LAPIC_SEND_PENDING | LAPIC_LVT_RESERVED_1 |
+  LAPIC_DELIVERY_MODE_MASK)) |
+  (LAPIC_LVT_REMOTE_IRR | LAPIC_SEND_PENDING |
+  LAPIC_DELIVERY_MODE_EXTINT));
lapic_write_around(LAPIC_LVT1, (lapic_read_around(LAPIC_LVT1) &
-   ~(LAPIC_LVT_MASKED | LAPIC_LVT_LEVEL_TRIGGER |
- LAPIC_LVT_REMOTE_IRR | LAPIC_INPUT_POLARITY |
- LAPIC_SEND_PENDING | LAPIC_LVT_RESERVED_1 |
- LAPIC_DELIVERY_MODE_MASK)) |
-   (LAPIC_LVT_REMOTE_IRR | LAPIC_SEND_PENDING |
-   LAPIC_DELIVERY_MODE_NMI));
+  ~(LAPIC_LVT_MASKED | LAPIC_LVT_LEVEL_TRIGGER |
+  LAPIC_LVT_REMOTE_IRR | LAPIC_INPUT_POLARITY |
+  LAPIC_SEND_PENDING | LAPIC_LVT_RESERVED_1 |
+  LAPIC_DELIVERY_MODE_MASK)) |
+  (LAPIC_LVT_REMOTE_IRR | LAPIC_SEND_PENDING |
+  LAPIC_DELIVERY_MODE_NMI));
 
debug("apic_id: 0x%02lx, ", lapicid());
-#else /* !NEED_LLAPIC */
+#else /* !CONFIG_SMP */
/* Only Pentium Pro and later have those MSR stuff */
debug("Disabling local apic: ");
disable_lapic();
-#endif /* !NEED_LAPIC */
+#endif /* CONFIG_SMP */
debug("done.\n");
post_code(POST_LAPIC);
 }
diff --git a/arch/x86/include/asm/arch-ivybridge/bd82x6x.h 
b/arch/x86/include/asm/arch-ivybridge/bd82x6x.h
index 5ae32f7..7786493 100644
--- a/arch/x86/include/asm/arch-ivybridge/bd82x6x.h
+++ b/arch/x86/include/asm/arch-ivybridge/bd82x6x.h
@@ -16,7 +16,19 @@ int gma_func0_init(pci_dev_t dev, struct pci_controller 
*hose,
   const void *blob, int node);
 int bd82x6x_init(void);
 
-struct x86_cpu_priv;
+/**
+ * struct x86_cpu_priv - Information about a single CPU
+ *
+ * @apic_id: Advanced Programmable Interrupt Controller Identifier, which is
+ * 

[U-Boot] [PATCH v4 1/6] dm: cpu: Add a new get_count method to cpu uclass

[Bin Meng]

Introduce a new method 'get_count' in the UCLASS_CPU ops to get
the number of CPUs in the system.

Signed-off-by: Bin Meng 

---

Changes in v4:
- Remove parameter 'count' from cpu_get_count()

Changes in v3:
- Drop patches already applied and rebase on u-boot-x86/master
- New patch to add a new get_count method to cpu uclass

Changes in v2: None

 drivers/cpu/cpu-uclass.c | 10 ++
 include/cpu.h| 16 
 2 files changed, 26 insertions(+)

diff --git a/drivers/cpu/cpu-uclass.c b/drivers/cpu/cpu-uclass.c
index d6be9d4..a2814a8 100644
--- a/drivers/cpu/cpu-uclass.c
+++ b/drivers/cpu/cpu-uclass.c
@@ -32,6 +32,16 @@ int cpu_get_info(struct udevice *dev, struct cpu_info *info)
return ops->get_info(dev, info);
 }
 
+int cpu_get_count(struct udevice *dev)
+{
+   struct cpu_ops *ops = cpu_get_ops(dev);
+
+   if (!ops->get_count)
+   return -ENOSYS;
+
+   return ops->get_count(dev);
+}
+
 U_BOOT_DRIVER(cpu_bus) = {
.name   = "cpu_bus",
.id = UCLASS_SIMPLE_BUS,
diff --git a/include/cpu.h b/include/cpu.h
index 34c60bc..bfb0db2 100644
--- a/include/cpu.h
+++ b/include/cpu.h
@@ -58,6 +58,14 @@ struct cpu_ops {
 * @return 0 if OK, -ve on error
 */
int (*get_info)(struct udevice *dev, struct cpu_info *info);
+
+   /**
+* get_count() - Get number of CPUs
+*
+* @dev:Device to check (UCLASS_CPU)
+* @return CPU count if OK, -ve on error
+*/
+   int (*get_count)(struct udevice *dev);
 };
 
 #define cpu_get_ops(dev)((struct cpu_ops *)(dev)->driver->ops)
@@ -81,4 +89,12 @@ int cpu_get_desc(struct udevice *dev, char *buf, int size);
  */
 int cpu_get_info(struct udevice *dev, struct cpu_info *info);
 
+/**
+ * cpu_get_count() - Get number of CPUs
+ *
+ * @dev:   Device to check (UCLASS_CPU)
+ * @return CPU count if OK, -ve on error
+ */
+int cpu_get_count(struct udevice *dev);
+
 #endif
-- 
1.8.2.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v4 4/6] x86: Move lapic_setup() call into init_bsp()

[Bin Meng]

Currently lapic_setup() is called before calling mp_init(), which
then calls init_bsp() where it calls enable_lapic(), which was
already enabled in lapic_setup(). Hence move lapic_setup() call
into init_bsp() to avoid the duplication.

Signed-off-by: Bin Meng 
Acked-by: Simon Glass 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/x86/cpu/cpu.c | 2 --
 arch/x86/cpu/mp_init.c | 2 +-
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c
index a6e88cf..d108ee5 100644
--- a/arch/x86/cpu/cpu.c
+++ b/arch/x86/cpu/cpu.c
@@ -640,8 +640,6 @@ static int x86_mp_init(void)
 {
struct mp_params mp_params;
 
-   lapic_setup();
-
mp_params.parallel_microcode_load = 0,
mp_params.flight_plan = &mp_steps[0];
mp_params.num_records = ARRAY_SIZE(mp_steps);
diff --git a/arch/x86/cpu/mp_init.c b/arch/x86/cpu/mp_init.c
index 5564d84..e8bc9b6 100644
--- a/arch/x86/cpu/mp_init.c
+++ b/arch/x86/cpu/mp_init.c
@@ -418,7 +418,7 @@ static int init_bsp(struct udevice **devp)
cpu_get_name(processor_name);
debug("CPU: %s.\n", processor_name);
 
-   enable_lapic();
+   lapic_setup();
 
apic_id = lapicid();
ret = find_cpu_by_apid_id(apic_id, devp);
-- 
1.8.2.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v4 2/6] x86: ivybridge: Remove SMP from CPU_SPECIFIC_OPTIONS

[Bin Meng]

Ivybridge is not ready for U-Boot MP initialization yet.

Signed-off-by: Bin Meng 
Acked-by: Simon Glass 

---

Changes in v4: None
Changes in v3:
- New patch to remove SMP from CPU_SPECIFIC_OPTIONS for ivybridge

Changes in v2: None

 arch/x86/cpu/ivybridge/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/x86/cpu/ivybridge/Kconfig b/arch/x86/cpu/ivybridge/Kconfig
index e4595be..0e249a4 100644
--- a/arch/x86/cpu/ivybridge/Kconfig
+++ b/arch/x86/cpu/ivybridge/Kconfig
@@ -95,7 +95,6 @@ config CPU_SPECIFIC_OPTIONS
select ARCH_BOOTBLOCK_X86_32
select ARCH_ROMSTAGE_X86_32
select ARCH_RAMSTAGE_X86_32
-   select SMP
select SSE2
select UDELAY_LAPIC
select CPU_MICROCODE_IN_CBFS
-- 
1.8.2.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v4 3/6] x86: Move MP initialization codes into a common place

[Bin Meng]

Most of the MP initialization codes in arch/x86/cpu/baytrail/cpu.c is
common to all x86 processors, except detect_num_cpus() which varies
from cpu to cpu. Move these to arch/x86/cpu/cpu.c and implement the
new 'get_count' method for baytrail and cpu_x86 drivers. Now we call
cpu_get_count() in mp_init() to get the number of CPUs.

Signed-off-by: Bin Meng 
Acked-by: Simon Glass 

---

Changes in v4:
- Update to match cpu_get_count()

Changes in v3:
- Remove num_cpus from struct mp_params
- Call cpu_get_count() in mp_init() to get the number of CPUs
- Add missing DECLARE_GLOBAL_DATA_PTR in cpu-uclass.c and cpu_x86.c

Changes in v2: None

 arch/x86/cpu/baytrail/cpu.c | 98 ++---
 arch/x86/cpu/cpu.c  | 40 ++
 arch/x86/cpu/cpu_x86.c  | 28 +
 arch/x86/cpu/mp_init.c  | 18 +++--
 arch/x86/include/asm/mp.h   |  1 -
 drivers/cpu/cpu-uclass.c|  2 +
 6 files changed, 114 insertions(+), 73 deletions(-)

diff --git a/arch/x86/cpu/baytrail/cpu.c b/arch/x86/cpu/baytrail/cpu.c
index 05156a5..a011730 100644
--- a/arch/x86/cpu/baytrail/cpu.c
+++ b/arch/x86/cpu/baytrail/cpu.c
@@ -12,78 +12,9 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
-#ifdef CONFIG_SMP
-static int enable_smis(struct udevice *cpu, void *unused)
-{
-   return 0;
-}
-
-static struct mp_flight_record mp_steps[] = {
-   MP_FR_BLOCK_APS(mp_init_cpu, NULL, mp_init_cpu, NULL),
-   /* Wait for APs to finish initialization before proceeding. */
-   MP_FR_BLOCK_APS(NULL, NULL, enable_smis, NULL),
-};
-
-static int detect_num_cpus(void)
-{
-   int ecx = 0;
-
-   /*
-* Use the algorithm described in Intel 64 and IA-32 Architectures
-* Software Developer's Manual Volume 3 (3A, 3B & 3C): System
-* Programming Guide, Jan-2015. Section 8.9.2: Hierarchical Mapping
-* of CPUID Extended Topology Leaf.
-*/
-   while (1) {
-   struct cpuid_result leaf_b;
-
-   leaf_b = cpuid_ext(0xb, ecx);
-
-   /*
-* Bay Trail doesn't have hyperthreading so just determine the
-* number of cores by from level type (ecx[15:8] == * 2)
-*/
-   if ((leaf_b.ecx & 0xff00) == 0x0200)
-   return leaf_b.ebx & 0x;
-   ecx++;
-   }
-}
-
-static int baytrail_init_cpus(void)
-{
-   struct mp_params mp_params;
-
-   lapic_setup();
-
-   mp_params.num_cpus = detect_num_cpus();
-   mp_params.parallel_microcode_load = 0,
-   mp_params.flight_plan = &mp_steps[0];
-   mp_params.num_records = ARRAY_SIZE(mp_steps);
-   mp_params.microcode_pointer = 0;
-
-   if (mp_init(&mp_params)) {
-   printf("Warning: MP init failure\n");
-   return -EIO;
-   }
-
-   return 0;
-}
-#endif
-
-int x86_init_cpus(void)
-{
-#ifdef CONFIG_SMP
-   debug("Init additional CPUs\n");
-   baytrail_init_cpus();
-#endif
-
-   return 0;
-}
-
 static void set_max_freq(void)
 {
msr_t perf_ctl;
@@ -176,9 +107,38 @@ static int baytrail_get_info(struct udevice *dev, struct 
cpu_info *info)
return 0;
 }
 
+static int baytrail_get_count(struct udevice *dev)
+{
+   int ecx = 0;
+
+   /*
+* Use the algorithm described in Intel 64 and IA-32 Architectures
+* Software Developer's Manual Volume 3 (3A, 3B & 3C): System
+* Programming Guide, Jan-2015. Section 8.9.2: Hierarchical Mapping
+* of CPUID Extended Topology Leaf.
+*/
+   while (1) {
+   struct cpuid_result leaf_b;
+
+   leaf_b = cpuid_ext(0xb, ecx);
+
+   /*
+* Bay Trail doesn't have hyperthreading so just determine the
+* number of cores by from level type (ecx[15:8] == * 2)
+*/
+   if ((leaf_b.ecx & 0xff00) == 0x0200)
+   return leaf_b.ebx & 0x;
+
+   ecx++;
+   }
+
+   return 0;
+}
+
 static const struct cpu_ops cpu_x86_baytrail_ops = {
.get_desc   = cpu_x86_get_desc,
.get_info   = baytrail_get_info,
+   .get_count  = baytrail_get_count,
 };
 
 static const struct udevice_id cpu_x86_baytrail_ids[] = {
diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c
index 1dfd9e6..a6e88cf 100644
--- a/arch/x86/cpu/cpu.c
+++ b/arch/x86/cpu/cpu.c
@@ -21,10 +21,13 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -621,8 +624,45 @@ int last_stage_init(void)
 }
 #endif
 
+#ifdef CONFIG_SMP
+static int enable_smis(struct udevice *cpu, void *unused)
+{
+   return 0;
+}
+
+static struct mp_flight_record mp_steps[] = {
+   MP_FR_BLOCK_APS(mp_init_cpu, NULL, mp_init_cpu, NULL),
+   /* Wait for APs to finish initialization before proceeding */
+   MP_FR_BLOCK_APS(NULL, NULL, enable_smis, NULL),

[U-Boot] [PATCH v2] Initial support for ACPI Tables for qemu-x86 target.

[Saket Sinha]

This patchset is an initial attempt to support ACPI Tables for qemu-x86 target.

Changes in v2:
Dynamic generation of AML code for DSDT table.
Reading PCI registers for FADT table.
Incorporated Simon's review comments.

Signed-off-by: Saket Sinha 
---
 Makefile  |   5 +
 arch/x86/Kconfig  |   5 +
 arch/x86/cpu/qemu/Makefile|   2 +-
 arch/x86/cpu/qemu/acpi_table.c| 575 ++
 arch/x86/cpu/qemu/cpu-hotplug.asl |  78 ++
 arch/x86/cpu/qemu/dbug.asl|  26 ++
 arch/x86/cpu/qemu/dsdt.asl| 221 +++
 arch/x86/cpu/qemu/hpet.asl|  36 +++
 arch/x86/cpu/qemu/pci-crs.asl |  94 +++
 arch/x86/include/asm/acpi_table.h | 318 +
 arch/x86/include/asm/acpigen.h|  85 ++
 arch/x86/lib/tables.c |   5 +
 configs/qemu-x86_defconfig|   1 +
 13 files changed, 1450 insertions(+), 1 deletion(-)
 create mode 100755 arch/x86/cpu/qemu/acpi_table.c
 create mode 100644 arch/x86/cpu/qemu/cpu-hotplug.asl
 create mode 100644 arch/x86/cpu/qemu/dbug.asl
 create mode 100644 arch/x86/cpu/qemu/dsdt.asl
 create mode 100644 arch/x86/cpu/qemu/hpet.asl
 create mode 100644 arch/x86/cpu/qemu/pci-crs.asl
 create mode 100755 arch/x86/include/asm/acpi_table.h
 create mode 100755 arch/x86/include/asm/acpigen.h

diff --git a/Makefile b/Makefile
index 0a674bf..94388e6 100644
--- a/Makefile
+++ b/Makefile
@@ -389,6 +389,11 @@ export RCS_TAR_IGNORE := --exclude SCCS --exclude 
BitKeeper --exclude .svn \
 # ===
 # Rules shared between *config targets and build targets
 
+PHONY += acpi 
+acpi:
+   $(Q)iasl -p dsdt -tc arch/x86/cpu/qemu/dsdt.asl 
+   $(Q)mv dsdt.hex arch/x86/cpu/qemu/dsdt.c
+
 # Basic helpers built in scripts/
 PHONY += scripts_basic
 scripts_basic:
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 1aeae9d..c44ac07 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -321,6 +321,11 @@ config GENERATE_SFI_TABLE
 
 endmenu
 
+config GENERATE_ACPI_TABLE 
+   bool "Generate ACPI(Advanced Configuration and Power Interface) table"  
 
+   default y
+
+
 config MAX_PIRQ_LINKS
int
default 8
diff --git a/arch/x86/cpu/qemu/Makefile b/arch/x86/cpu/qemu/Makefile
index be79723..3a570bb 100644
--- a/arch/x86/cpu/qemu/Makefile
+++ b/arch/x86/cpu/qemu/Makefile
@@ -4,5 +4,5 @@
 # SPDX-License-Identifier: GPL-2.0+
 #
 
-obj-y += car.o dram.o qemu.o
+obj-y += car.o dram.o qemu.o dsdt.o acpi_table.o
 obj-$(CONFIG_PCI) += pci.o
diff --git a/arch/x86/cpu/qemu/acpi_table.c b/arch/x86/cpu/qemu/acpi_table.c
new file mode 100755
index 000..cefd5f4
--- /dev/null
+++ b/arch/x86/cpu/qemu/acpi_table.c
@@ -0,0 +1,575 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+ 
+#define LOCAL_APIC_ADDR 0xfee
+
+extern const unsigned char AmlCode[];
+
+u8 acpi_checksum(u8 *table, u32 length)
+{
+   u8 ret = 0;
+   while (length--) {
+   ret += *table;
+   table++;
+   }
+   return -ret;
+}
+/**
+ * Add an ACPI table to the RSDT (and XSDT) structure, recalculate length
+ * and checksum.
+ */
+void acpi_add_table(struct acpi_rsdp *rsdp, void *table)
+{
+   int i, entries_num;
+   struct acpi_rsdt *rsdt;
+   struct acpi_xsdt *xsdt = NULL;
+
+   /* The RSDT is mandatory... */
+   rsdt = (struct acpi_rsdt *)rsdp->rsdt_address;
+
+   /* ...while the XSDT is not. */
+   if (rsdp->xsdt_address)
+   xsdt = (struct acpi_xsdt *)((u32)rsdp->xsdt_address);
+
+   /* This should always be MAX_ACPI_TABLES. */
+   entries_num = ARRAY_SIZE(rsdt->entry);
+
+   for (i = 0; i < entries_num; i++) {
+   if (rsdt->entry[i] == 0)
+   break;
+   }
+
+   if (i >= entries_num) {
+   printf("ACPI: Error: Could not add ACPI table, "
+   "too many tables.\n");
+   return;
+   }
+
+   /* Add table to the RSDT. */
+   rsdt->entry[i] = (u32)table;
+
+   /* Fix RSDT length or the kernel will assume invalid entries. */
+   rsdt->header.length = sizeof(acpi_header_t) + (sizeof(u32) * (i + 1));
+
+   /* Re-calculate checksum. */
+   rsdt->header.checksum = 0; /* Hope this won't get optimized away */
+   rsdt->header.checksum = acpi_checksum((u8 *)rsdt, rsdt->header.length);
+
+   /*
+* And now the same thing for the XSDT. We use the same index as for
+* now we want the XSDT and RSDT to always be in sync in coreboot.
+*/
+   if (xsdt) {
+   /* Add table to the XSDT. */
+   xsdt->entry[i] = (u64)(u32)table;
+
+   /* Fix XSDT length. */
+   xsdt->header.length = sizeof(acpi_header_t) +
+   (sizeof(u64) * (i + 1));
+
+

[U-Boot] [PATCH RESEND 7/7] spi: cadence_qspi: get fifo width from device tree

[Vikas Manocha]

Fifo width could be different on different socs, e.g. stv0991 & altera soc
have different fifo width.

Signed-off-by: Vikas Manocha 
---
 arch/arm/dts/socfpga.dtsi  |1 +
 arch/arm/dts/stv0991.dts   |1 +
 drivers/spi/cadence_qspi.c |1 +
 drivers/spi/cadence_qspi.h |1 +
 drivers/spi/cadence_qspi_apb.c |   13 -
 5 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/arch/arm/dts/socfpga.dtsi b/arch/arm/dts/socfpga.dtsi
index d89c974..a2a2029 100644
--- a/arch/arm/dts/socfpga.dtsi
+++ b/arch/arm/dts/socfpga.dtsi
@@ -640,6 +640,7 @@
ext-decoder = <0>;  /* external decoder */
num-cs = <4>;
fifo-depth = <128>;
+   fifo-width = <4>;
bus-num = <2>;
status = "disabled";
};
diff --git a/arch/arm/dts/stv0991.dts b/arch/arm/dts/stv0991.dts
index 72399ff..433fcd1 100644
--- a/arch/arm/dts/stv0991.dts
+++ b/arch/arm/dts/stv0991.dts
@@ -36,6 +36,7 @@
ext-decoder = <0>; /* external decoder */
num-cs = <4>;
fifo-depth = <256>;
+   fifo-width = <8>;
bus-num = <0>;
status = "okay";
 
diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
index b23461d..dfdd9e3 100644
--- a/drivers/spi/cadence_qspi.c
+++ b/drivers/spi/cadence_qspi.c
@@ -310,6 +310,7 @@ static int cadence_spi_ofdata_to_platdata(struct udevice 
*bus)
plat->tsd2d_ns = fdtdec_get_int(blob, subnode, "tsd2d-ns", 255);
plat->tchsh_ns = fdtdec_get_int(blob, subnode, "tchsh-ns", 20);
plat->tslch_ns = fdtdec_get_int(blob, subnode, "tslch-ns", 20);
+   plat->fifo_width = fdtdec_get_int(blob, node, "fifo-width", 4);
 
debug("%s: regbase=%p flashbase=%p trigger_base=%p max-frequency=%d \
page-size=%d\n", __func__, plat->regbase, plat->flashbase,
diff --git a/drivers/spi/cadence_qspi.h b/drivers/spi/cadence_qspi.h
index 5ea4581..2be1b43 100644
--- a/drivers/spi/cadence_qspi.h
+++ b/drivers/spi/cadence_qspi.h
@@ -26,6 +26,7 @@ struct cadence_spi_platdata {
u32 tsd2d_ns;
u32 tchsh_ns;
u32 tslch_ns;
+   u32 fifo_width;
 };
 
 struct cadence_spi_priv {
diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
index 2994158..61fc95a 100644
--- a/drivers/spi/cadence_qspi_apb.c
+++ b/drivers/spi/cadence_qspi_apb.c
@@ -34,8 +34,6 @@
 #define CQSPI_REG_RETRY(1)
 #define CQSPI_POLL_IDLE_RETRY  (3)
 
-#define CQSPI_FIFO_WIDTH   (4)
-
 /* Controller sram size in word */
 #define CQSPI_REG_SRAM_SIZE_WORD   (128)
 #define CQSPI_REG_SRAM_RESV_WORDS  (2)
@@ -54,9 +52,6 @@
 #define CQSPI_DUMMY_CLKS_PER_BYTE  (8)
 #define CQSPI_DUMMY_BYTES_MAX  (4)
 
-
-#define CQSPI_REG_SRAM_FILL_THRESHOLD  \
-   ((CQSPI_REG_SRAM_SIZE_WORD / 2) * CQSPI_FIFO_WIDTH)
 /
  * Controller's configuration and status register (offset from QSPI_BASE)
  /
@@ -235,11 +230,11 @@ static int qpsi_write_sram_fifo_push(struct 
cadence_spi_platdata *plat,
page_size : remaining;
 
remaining -= wr_bytes;
-   while (wr_bytes >= CQSPI_FIFO_WIDTH) {
-   for (i = 0; i < CQSPI_FIFO_WIDTH/sizeof(dest_addr); i++)
+   while (wr_bytes >= plat->fifo_width) {
+   for (i = 0; i < plat->fifo_width/sizeof(dest_addr); i++)
writel(*(src_ptr+i), dest_addr+i);
-   src_ptr += CQSPI_FIFO_WIDTH/sizeof(dest_addr);
-   wr_bytes -= CQSPI_FIFO_WIDTH;
+   src_ptr += plat->fifo_width/sizeof(dest_addr);
+   wr_bytes -= plat->fifo_width;
}
if (wr_bytes) {
/* dangling bytes */
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH RESEND 3/7] spi: cadence_qspi: remove sram polling from flash write

[Vikas Manocha]

There is no need to poll sram level before writing to flash, data going to SRAM
till sram is full, after that backpressure will take over.

Signed-off-by: Vikas Manocha 
---
 drivers/spi/cadence_qspi_apb.c |   59 ++--
 1 file changed, 15 insertions(+), 44 deletions(-)

diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
index 794d51d..403230a 100644
--- a/drivers/spi/cadence_qspi_apb.c
+++ b/drivers/spi/cadence_qspi_apb.c
@@ -220,63 +220,34 @@ static int cadence_qspi_apb_read_fifo_data(void *dest,
return 0;
 }
 
-static void cadence_qspi_apb_write_fifo_data(const void *dest_ahb_addr,
-   const void *src, unsigned int bytes)
-{
-   unsigned int temp;
-   int remaining = bytes;
-   unsigned int *dest_ptr = (unsigned int *)dest_ahb_addr;
-   unsigned int *src_ptr = (unsigned int *)src;
-
-   while (remaining > 0) {
-   if (remaining >= CQSPI_FIFO_WIDTH) {
-   writel(*src_ptr, dest_ptr);
-   remaining -= sizeof(unsigned int);
-   } else {
-   /* dangling bytes */
-   memcpy(&temp, src_ptr, remaining);
-   writel(temp, dest_ptr);
-   break;
-   }
-   src_ptr++;
-   }
-
-   return;
-}
-
-/* Write to SRAM FIFO with polling SRAM fill level. */
 static int qpsi_write_sram_fifo_push(struct cadence_spi_platdata *plat,
const void *src_addr, unsigned int num_bytes)
 {
-   const void *reg_base = plat->regbase;
-   void *dest_addr = plat->ahbbase;
-   unsigned int retry = CQSPI_REG_RETRY;
-   unsigned int sram_level;
+   int i = 0;
+   unsigned int *dest_addr = plat->trigger_base;
unsigned int wr_bytes;
-   unsigned char *src = (unsigned char *)src_addr;
+   unsigned int *src_ptr = (unsigned int *)src_addr;
int remaining = num_bytes;
unsigned int page_size = plat->page_size;
-   unsigned int sram_threshold_words = CQSPI_REG_SRAM_THRESHOLD_WORDS;
 
while (remaining > 0) {
-   retry = CQSPI_REG_RETRY;
-   while (retry--) {
-   sram_level = CQSPI_GET_WR_SRAM_LEVEL(reg_base);
-   if (sram_level <= sram_threshold_words)
-   break;
-   }
-   if (!retry) {
-   printf("QSPI: SRAM fill level (0x%08x) not hit lower 
expected level (0x%08x)",
-  sram_level, sram_threshold_words);
-   return -1;
-   }
/* Write a page or remaining bytes. */
wr_bytes = (remaining > page_size) ?
page_size : remaining;
 
-   cadence_qspi_apb_write_fifo_data(dest_addr, src, wr_bytes);
-   src += wr_bytes;
remaining -= wr_bytes;
+   while (wr_bytes >= CQSPI_FIFO_WIDTH) {
+   for (i = 0; i < CQSPI_FIFO_WIDTH/sizeof(dest_addr); i++)
+   writel(*(src_ptr+i), dest_addr+i);
+   src_ptr += CQSPI_FIFO_WIDTH/sizeof(dest_addr);
+   wr_bytes -= CQSPI_FIFO_WIDTH;
+   }
+   if (wr_bytes) {
+   /* dangling bytes */
+   i = wr_bytes/sizeof(dest_addr);
+   for (i = wr_bytes/sizeof(dest_addr); i >= 0; i--)
+   writel(*(src_ptr+i), dest_addr+i);
+   }
}
 
return 0;
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH RESEND 5/7] spi: cadence_qspi: fix indirect read/write start address

[Vikas Manocha]

Indirect read/write start addresses are flash start addresses for indirect read
or write transfers. These should be absolute flash addresses instead of
offsets.

Signed-off-by: Vikas Manocha 
---
 drivers/spi/cadence_qspi_apb.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
index e1e1315..7be67a9 100644
--- a/drivers/spi/cadence_qspi_apb.c
+++ b/drivers/spi/cadence_qspi_apb.c
@@ -647,7 +647,8 @@ int cadence_qspi_apb_indirect_read_setup(struct 
cadence_spi_platdata *plat,
 
/* Get address */
addr_value = cadence_qspi_apb_cmd2addr(&cmdbuf[1], addr_bytes);
-   writel(addr_value, plat->regbase + CQSPI_REG_INDIRECTRDSTARTADDR);
+   writel((u32)plat->ahbbase + addr_value,
+   plat->regbase + CQSPI_REG_INDIRECTRDSTARTADDR);
 
/* The remaining lenght is dummy bytes. */
dummy_bytes = cmdlen - addr_bytes - 1;
@@ -741,7 +742,8 @@ int cadence_qspi_apb_indirect_write_setup(struct 
cadence_spi_platdata *plat,
 
/* Setup write address. */
reg = cadence_qspi_apb_cmd2addr(&cmdbuf[1], addr_bytes);
-   writel(reg, plat->regbase + CQSPI_REG_INDIRECTWRSTARTADDR);
+   writel((u32)plat->ahbbase + reg,
+   plat->regbase + CQSPI_REG_INDIRECTWRSTARTADDR);
 
reg = readl(plat->regbase + CQSPI_REG_SIZE);
reg &= ~CQSPI_REG_SIZE_ADDRESS_MASK;
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH RESEND 6/7] spi: cadence_qspi: fix base trigger address & transfer start address

[Vikas Manocha]

This patch is to separate the base trigger from the read/write transfer start
addresses.

Base trigger register address (0x1c register) corresponds to the
address which should be put on AHB bus to handle indirect transfer
triggered before.
To handle indirect transfer we need to issue addresses from (value of 0x1c) to
(value of 0x1c) + 15*4 ("4" corresponds to size of SRAM location).
There are no obstacles in issuing const address just equal to 0x1c. Important
thing to note is that indirect trigger address has nothing in common with your
physical or mapped NOR Flash address.

Transfer read/write start addresses (offset 0x68/0x78)should be programmed with
the absolute flash address to be read/written.

plat->ahbbase has been renamed to plat->flashbase for clarity.
plat->triggerbase is added in device tree for mapped spi flash address.

Signed-off-by: Vikas Manocha 
---
 arch/arm/dts/socfpga.dtsi  |1 +
 arch/arm/dts/stv0991.dts   |3 ++-
 drivers/spi/cadence_qspi.c |   13 +++--
 drivers/spi/cadence_qspi.h |5 +++--
 drivers/spi/cadence_qspi_apb.c |   12 +---
 5 files changed, 18 insertions(+), 16 deletions(-)

diff --git a/arch/arm/dts/socfpga.dtsi b/arch/arm/dts/socfpga.dtsi
index bf791c5..d89c974 100644
--- a/arch/arm/dts/socfpga.dtsi
+++ b/arch/arm/dts/socfpga.dtsi
@@ -634,6 +634,7 @@
#size-cells = <0>;
reg = <0xff705000 0x1000>,
<0xffa0 0x1000>;
+   <0x 0x0010>;
interrupts = <0 151 4>;
clocks = <&qspi_clk>;
ext-decoder = <0>;  /* external decoder */
diff --git a/arch/arm/dts/stv0991.dts b/arch/arm/dts/stv0991.dts
index 3b1efca..72399ff 100644
--- a/arch/arm/dts/stv0991.dts
+++ b/arch/arm/dts/stv0991.dts
@@ -30,7 +30,8 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <0x80203000 0x100>,
-   <0x4000 0x100>;
+   <0x4000 0x100>,
+   <0x4000 0x010>;
clocks = <375>;
ext-decoder = <0>; /* external decoder */
num-cs = <4>;
diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
index a75fc46..b23461d 100644
--- a/drivers/spi/cadence_qspi.c
+++ b/drivers/spi/cadence_qspi.c
@@ -150,7 +150,7 @@ static int cadence_spi_probe(struct udevice *bus)
struct cadence_spi_priv *priv = dev_get_priv(bus);
 
priv->regbase = plat->regbase;
-   priv->ahbbase = plat->ahbbase;
+   priv->flashbase = plat->flashbase;
 
if (!priv->qspi_is_init) {
cadence_qspi_apb_controller_init(plat);
@@ -278,7 +278,7 @@ static int cadence_spi_ofdata_to_platdata(struct udevice 
*bus)
const void *blob = gd->fdt_blob;
int node = bus->of_offset;
int subnode;
-   u32 data[4];
+   u32 data[6];
int ret;
 
/* 2 base addresses are needed, lets get them from the DT */
@@ -289,7 +289,8 @@ static int cadence_spi_ofdata_to_platdata(struct udevice 
*bus)
}
 
plat->regbase = (void *)data[0];
-   plat->ahbbase = (void *)data[2];
+   plat->flashbase = (void *)data[2];
+   plat->trigger_base = (void *)data[4];
 
/* Use 500KHz as a suitable default */
plat->max_hz = fdtdec_get_int(blob, node, "spi-max-frequency",
@@ -310,9 +311,9 @@ static int cadence_spi_ofdata_to_platdata(struct udevice 
*bus)
plat->tchsh_ns = fdtdec_get_int(blob, subnode, "tchsh-ns", 20);
plat->tslch_ns = fdtdec_get_int(blob, subnode, "tslch-ns", 20);
 
-   debug("%s: regbase=%p ahbbase=%p max-frequency=%d page-size=%d\n",
- __func__, plat->regbase, plat->ahbbase, plat->max_hz,
- plat->page_size);
+   debug("%s: regbase=%p flashbase=%p trigger_base=%p max-frequency=%d \
+   page-size=%d\n", __func__, plat->regbase, plat->flashbase,
+   plat->trigger_base, plat->max_hz, plat->page_size);
 
return 0;
 }
diff --git a/drivers/spi/cadence_qspi.h b/drivers/spi/cadence_qspi.h
index c9a6142..5ea4581 100644
--- a/drivers/spi/cadence_qspi.h
+++ b/drivers/spi/cadence_qspi.h
@@ -17,7 +17,8 @@
 struct cadence_spi_platdata {
unsigned intmax_hz;
void*regbase;
-   void*ahbbase;
+   void*flashbase;
+   void*trigger_base;
 
u32 page_size;
u32 block_size;
@@ -29,7 +30,7 @@ struct cadence_spi_platdata {
 
 struct cadence_spi_priv {
void*regbase;
-   void*ahbbase;
+   void*flashbase;
size_t  cmd_len;
u8  cmd_buf[32];
size_t  data_len;
diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/sp

[U-Boot] [PATCH RESEND 4/7] spi: cadence_qspi: move trigger base configuration in init

[Vikas Manocha]

Signed-off-by: Vikas Manocha 
---
 drivers/spi/cadence_qspi_apb.c |   11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
index 403230a..e1e1315 100644
--- a/drivers/spi/cadence_qspi_apb.c
+++ b/drivers/spi/cadence_qspi_apb.c
@@ -471,6 +471,10 @@ void cadence_qspi_apb_controller_init(struct 
cadence_spi_platdata *plat)
/* Configure the remap address register, no remap */
writel(0, plat->regbase + CQSPI_REG_REMAP);
 
+   /* Setup the indirect trigger address */
+   writel(((u32)plat->ahbbase & CQSPI_INDIRECTTRIGGER_ADDR_MASK),
+   plat->regbase + CQSPI_REG_INDIRECTTRIGGER);
+
/* Disable all interrupts */
writel(0, plat->regbase + CQSPI_REG_IRQMASK);
 
@@ -629,10 +633,6 @@ int cadence_qspi_apb_indirect_read_setup(struct 
cadence_spi_platdata *plat,
/* for normal read (only ramtron as of now) */
addr_bytes = cmdlen - 1;
 
-   /* Setup the indirect trigger address */
-   writel(((u32)plat->ahbbase & CQSPI_INDIRECTTRIGGER_ADDR_MASK),
-  plat->regbase + CQSPI_REG_INDIRECTTRIGGER);
-
/* Configure SRAM partition for read. */
writel(CQSPI_REG_SRAM_PARTITION_RD, plat->regbase +
   CQSPI_REG_SRAMPARTITION);
@@ -731,9 +731,6 @@ int cadence_qspi_apb_indirect_write_setup(struct 
cadence_spi_platdata *plat,
   cmdlen, (unsigned int)cmdbuf);
return -EINVAL;
}
-   /* Setup the indirect trigger address */
-   writel(((u32)plat->ahbbase & CQSPI_INDIRECTTRIGGER_ADDR_MASK),
-  plat->regbase + CQSPI_REG_INDIRECTTRIGGER);
 
writel(CQSPI_REG_SRAM_PARTITION_WR,
   plat->regbase + CQSPI_REG_SRAMPARTITION);
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH RESEND 0/7] spi: cadence_qspi: optimize & fix indirect rd-writes

[Vikas Manocha]

This patchset:
- removes sram polling while reading/writing from flash.
- fixes trigger base & transfer start address register programming. This fix
superseeds the previous patch "spi: cadence_qspi: Fix the indirect ahb trigger
address setting"
- adds support to get fifo width from device tree

Vikas Manocha (7):
  spi: cadence_qspi: remove sram polling from flash read
  spi: cadence_qspi: read can be independent of fifo width
  spi: cadence_qspi: remove sram polling from flash write
  spi: cadence_qspi: move trigger base configuration in init
  spi: cadence_qspi: fix indirect read/write start address
  spi: cadence_qspi: fix base trigger address & transfer start address
  spi: cadence_qspi: get fifo width from device tree

 arch/arm/dts/socfpga.dtsi  |2 +
 arch/arm/dts/stv0991.dts   |4 +-
 drivers/spi/cadence_qspi.c |   14 ++--
 drivers/spi/cadence_qspi.h |6 +-
 drivers/spi/cadence_qspi_apb.c |  140 ++--
 5 files changed, 50 insertions(+), 116 deletions(-)

-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH RESEND 2/7] spi: cadence_qspi: read can be independent of fifo width

[Vikas Manocha]

Signed-off-by: Vikas Manocha 
---
 drivers/spi/cadence_qspi_apb.c |   18 --
 1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
index 8eeb423..794d51d 100644
--- a/drivers/spi/cadence_qspi_apb.c
+++ b/drivers/spi/cadence_qspi_apb.c
@@ -206,18 +206,16 @@ static int cadence_qspi_apb_read_fifo_data(void *dest,
unsigned int *dest_ptr = (unsigned int *)dest;
unsigned int *src_ptr = (unsigned int *)src_ahb_addr;
 
-   while (remaining > 0) {
-   if (remaining >= CQSPI_FIFO_WIDTH) {
-   *dest_ptr = readl(src_ptr);
-   remaining -= CQSPI_FIFO_WIDTH;
-   } else {
-   /* dangling bytes */
-   temp = readl(src_ptr);
-   memcpy(dest_ptr, &temp, remaining);
-   break;
-   }
+   while (remaining >= sizeof(dest_ptr)) {
+   *dest_ptr = readl(src_ptr);
+   remaining -= sizeof(dest_ptr);
dest_ptr++;
}
+   if (remaining) {
+   /* dangling bytes */
+   temp = readl(src_ptr);
+   memcpy(dest_ptr, &temp, remaining);
+   }
 
return 0;
 }
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH RESEND 1/7] spi: cadence_qspi: remove sram polling from flash read

[Vikas Manocha]

There is no need to check for sram fill level. If sram is empty, cpu
will go in the wait state till the time data is available from flash.

Also Relying on SRAM fill level only for deciding when the data should be
fetched from the local SRAM is not most efficient approach, particulary
if we are working on high data rates.

It should be noticed that after one SRAM word is collected, the information is
forwarded into system domain and then synchronized into register domain (apb).
If we are using slow APB and AHB clks, SRAM fill level might not be up-to-dated
because of latency cycles needed for synchronization. For example in case we are
getting SRAM fill level equal to 10 locations but in reality there were 2
another words completed and actual level is 12 but information may not be
synchronized yet because of the synchronization latency on APB domain.

Signed-off-by: Vikas Manocha 
---
 drivers/spi/cadence_qspi_apb.c |   45 +---
 1 file changed, 5 insertions(+), 40 deletions(-)

diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
index 00a115f..8eeb423 100644
--- a/drivers/spi/cadence_qspi_apb.c
+++ b/drivers/spi/cadence_qspi_apb.c
@@ -198,7 +198,7 @@ static unsigned int cadence_qspi_apb_cmd2addr(const 
unsigned char *addr_buf,
return addr;
 }
 
-static void cadence_qspi_apb_read_fifo_data(void *dest,
+static int cadence_qspi_apb_read_fifo_data(void *dest,
const void *src_ahb_addr, unsigned int bytes)
 {
unsigned int temp;
@@ -219,7 +219,7 @@ static void cadence_qspi_apb_read_fifo_data(void *dest,
dest_ptr++;
}
 
-   return;
+   return 0;
 }
 
 static void cadence_qspi_apb_write_fifo_data(const void *dest_ahb_addr,
@@ -246,42 +246,6 @@ static void cadence_qspi_apb_write_fifo_data(const void 
*dest_ahb_addr,
return;
 }
 
-/* Read from SRAM FIFO with polling SRAM fill level. */
-static int qspi_read_sram_fifo_poll(const void *reg_base, void *dest_addr,
-   const void *src_addr,  unsigned int num_bytes)
-{
-   unsigned int remaining = num_bytes;
-   unsigned int retry;
-   unsigned int sram_level = 0;
-   unsigned char *dest = (unsigned char *)dest_addr;
-
-   while (remaining > 0) {
-   retry = CQSPI_REG_RETRY;
-   while (retry--) {
-   sram_level = CQSPI_GET_RD_SRAM_LEVEL(reg_base);
-   if (sram_level)
-   break;
-   udelay(1);
-   }
-
-   if (!retry) {
-   printf("QSPI: No receive data after polling for %d 
times\n",
-  CQSPI_REG_RETRY);
-   return -1;
-   }
-
-   sram_level *= CQSPI_FIFO_WIDTH;
-   sram_level = sram_level > remaining ? remaining : sram_level;
-
-   /* Read data from FIFO. */
-   cadence_qspi_apb_read_fifo_data(dest, src_addr, sram_level);
-   dest += sram_level;
-   remaining -= sram_level;
-   udelay(1);
-   }
-   return 0;
-}
-
 /* Write to SRAM FIFO with polling SRAM fill level. */
 static int qpsi_write_sram_fifo_push(struct cadence_spi_platdata *plat,
const void *src_addr, unsigned int num_bytes)
@@ -759,9 +723,10 @@ int cadence_qspi_apb_indirect_read_execute(struct 
cadence_spi_platdata *plat,
/* Start the indirect read transfer */
writel(CQSPI_REG_INDIRECTRD_START_MASK,
   plat->regbase + CQSPI_REG_INDIRECTRD);
+   udelay(1);
 
-   if (qspi_read_sram_fifo_poll(plat->regbase, (void *)rxbuf,
-(const void *)plat->ahbbase, rxlen))
+   if (cadence_qspi_apb_read_fifo_data((void *)rxbuf,
+   (const void *)plat->ahbbase, rxlen))
goto failrd;
 
/* Check flash indirect controller */
-- 
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 v3 1/6] dm: cpu: Add a new get_count method to cpu uclass

[Simon Glass]

Hi Bin,

On 15 June 2015 at 18:19, Bin Meng  wrote:
> Hi Simon,
>
> On Tue, Jun 16, 2015 at 4:45 AM, Simon Glass  wrote:
>> Hi Bin,
>>
>> On 13 June 2015 at 04:11, Bin Meng  wrote:
>>>
>>> Introduce a new method 'get_count' in the UCLASS_CPU ops to get
>>> the number of CPUs in the system.
>>>
>>> Signed-off-by: Bin Meng 
>>>
>>> ---
>>>
>>> Changes in v3:
>>> - Drop patches already applied and rebase on u-boot-x86/master
>>> - New patch to add a new get_count method to cpu uclass
>>>
>>> Changes in v2: None
>>>
>>>  drivers/cpu/cpu-uclass.c | 10 ++
>>>  include/cpu.h| 18 ++
>>>  2 files changed, 28 insertions(+)
>>>
>>> diff --git a/drivers/cpu/cpu-uclass.c b/drivers/cpu/cpu-uclass.c
>>> index d6be9d4..8efb17c 100644
>>> --- a/drivers/cpu/cpu-uclass.c
>>> +++ b/drivers/cpu/cpu-uclass.c
>>> @@ -32,6 +32,16 @@ int cpu_get_info(struct udevice *dev, struct cpu_info 
>>> *info)
>>> return ops->get_info(dev, info);
>>>  }
>>>
>>> +int cpu_get_count(struct udevice *dev, int *count)
>>
>> Can we please return count and avoid the 'count' parameter? We can use
>> -ve for errors.
>>
>
> Yes, but I was wondering that if it looks inconsistent to other two
> cpu ops? (or maybe other dm driver ops?)

I think that if the return value needs to be a postive int, then we
should just use the return value. In other cases perhaps not. It is
slightly more efficient and a little easier to read.

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/4] usb: board_usb_init and board_usb_cleanup calls in the fastboot command

[Paul Kocialkowski]

Le mardi 16 juin 2015 à 14:36 -0700, Steve Rae a écrit :
> 
> On 15-06-16 02:25 PM, Paul Kocialkowski wrote:
> > Le mardi 16 juin 2015 à 13:58 -0700, Steve Rae a écrit :
> >> Hi Paul,
> >>
> >> On 15-06-12 10:57 AM, Paul Kocialkowski wrote:
> >>> Each USB download function command calls board_usb_init before 
> >>> registering the
> >>> USB gadget and board_usb_cleanup after de-registering it. On devices 
> >>> currently
> >>> using fasboot, musb-new is usually initialized earlier, but some other 
> >>> boards
> >>> might need the board_usb_init call to properly initialize musb-new.
> >>>
> >>> This requires adding an argument (the USB controller index) to the 
> >>> fastboot
> >>> command, as it is currently done with other USB download gadget functions.
> >>>
> >>> Signed-off-by: Paul Kocialkowski 
> >>> ---
> >>>common/cmd_fastboot.c | 31 +--
> >>>include/configs/ti_omap5_common.h |  2 +-
> >>>2 files changed, 26 insertions(+), 7 deletions(-)
> >>>
> >>> diff --git a/common/cmd_fastboot.c b/common/cmd_fastboot.c
> >>> index d52ccfb..86fbddf 100644
> >>> --- a/common/cmd_fastboot.c
> >>> +++ b/common/cmd_fastboot.c
> >>> @@ -10,11 +10,26 @@
> >>>#include 
> >>>#include 
> >>>#include 
> >>> +#include 
> >>>
> >>>static int do_fastboot(cmd_tbl_t *cmdtp, int flag, int argc, char 
> >>> *const argv[])
> >>>{
> >>> + int controller_index;
> >>> + char *usb_controller;
> >>>   int ret;
> >>>
> >>> + if (argc < 2)
> >>> + return CMD_RET_USAGE;
> >>> +
> >>> + usb_controller = argv[1];
> >>
> >> Not backwards compatible I would prefer to make it optional:
> >>   if (argc < 2)
> >>   controller_index = 0;
> >>   else {
> >>   usb_controller = argv[1];
> >>   controller_index = simple_strtoul(usb_controller, NULL, 
> >> 0);
> >>   }
> >
> > This is definitely a "bug fix". There is no reason to assume that the
> > USB controller index is 0 and it was incorrect to assume that from the
> > very beginning. Other download USB gadget commands had the controller
> > index as a non-optional parameter already.
> >
> > Since I fixed the configs that use it in U-Boot, I think it's fair
> > enough. This may indeed break some hand-written scripts but those will
> > be straightforward to fix.
> >
> > I am strongly against keeping deprecated legacy fallbacks that make the
> > code inconsistent and harder to maintain just for the sake of keeping
> > backwards compatibility with users' hand-written scripts.
> >
> 
> I understand, but I'm more worried about _all_ the existing 
> documentation that states the the command line is "fastboot" (which now 
> would need to be changed to "fastboot 0")

Well, if I missed someplace in U-Boot where it is stated that only
"fastboot" is sufficient to run the command, I should change that too.

Otherwise, for third party guides, the rationale is the same as
previously stated.

> >>> + controller_index = simple_strtoul(usb_controller, NULL, 0);
> >>> +
> >>> + ret = board_usb_init(controller_index, USB_INIT_DEVICE);
> >>> + if (ret) {
> >>> + error("USB init failed: %d", ret);
> >>> + return CMD_RET_FAILURE;
> >>> + }
> >>> +
> >>>   g_dnl_clear_detach();
> >>>   ret = g_dnl_register("usb_dnl_fastboot");
> >>>   if (ret)
> >>> @@ -23,9 +38,8 @@ static int do_fastboot(cmd_tbl_t *cmdtp, int flag, int 
> >>> argc, char *const argv[])
> >>>   if (!g_dnl_board_usb_cable_connected()) {
> >>>   puts("\rUSB cable not detected.\n" \
> >>>"Command exit.\n");
> >>> - g_dnl_unregister();
> >>> - g_dnl_clear_detach();
> >>> - return CMD_RET_FAILURE;
> >>> + ret = CMD_RET_FAILURE;
> >>> + goto exit;
> >>>   }
> >>>
> >>>   while (1) {
> >>> @@ -36,14 +50,19 @@ static int do_fastboot(cmd_tbl_t *cmdtp, int flag, 
> >>> int argc, char *const argv[])
> >>>   usb_gadget_handle_interrupts(0);
> >>>   }
> >>>
> >>> + ret = CMD_RET_SUCCESS;
> >>> +
> >>> +exit:
> >>>   g_dnl_unregister();
> >>>   g_dnl_clear_detach();
> >>> - return CMD_RET_SUCCESS;
> >>> + board_usb_cleanup(controller_index, USB_INIT_DEVICE);
> >>> +
> >>> + return ret;
> >>>}
> >>>
> >>>U_BOOT_CMD(
> >>> - fastboot,   1,  0,  do_fastboot,
> >>> + fastboot, 2, 1, do_fastboot,
> >>>   "use USB Fastboot protocol",
> >>> - "\n"
> >>> + "\n"
> >>
> >> make it optional:
> >>"[]\n"
> >>
> >>>   "- run as a fastboot usb device"
> >>>);
> >>> diff --git a/include/configs/ti_omap5_common.h 
> >>> b/include/configs/ti_omap5_common.h
> >>> index 4faffef..4fd5669 100644
> >>> --- a/include/configs/ti_omap5_common.h
> >>> +++ b/include/configs/ti_omap5_common.h
> >>> @@ -137,7 +137,7 @@
> >>>   "if test ${dofastboot} -eq 1; then " \
> >>>   "echo Boo

Re: [U-Boot] [PATCH] gpio: mxc_gpio: enable DM gpio before relocation

[Simon Glass]

Hi Markus,

On 16 June 2015 at 01:08, Markus Niebel  wrote:
> From: Markus Niebel 
>
> gpio often are needed to detect revision and variants.
> Therefore gpio should be available ASAP.
>
> Signed-off-by: Markus Niebel 
> ---
>  drivers/gpio/mxc_gpio.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpio/mxc_gpio.c b/drivers/gpio/mxc_gpio.c
> index 2012f99..925758a 100644
> --- a/drivers/gpio/mxc_gpio.c
> +++ b/drivers/gpio/mxc_gpio.c
> @@ -330,6 +330,7 @@ U_BOOT_DRIVER(gpio_mxc) = {
> .priv_auto_alloc_size = sizeof(struct mxc_bank_info),
> .of_match = mxc_gpio_ids,
> .bind   = mxc_gpio_bind,
> +   .flags  = DM_FLAG_PRE_RELOC,
>  };
>
>  #ifndef CONFIG_OF_CONTROL
> --
> 2.3.0
>

This should really be done in the device tree with the
u-boot,dm-pre-reloc property for the particular GPIO banks you need. I
don't think this should be a global setting.

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/4] usb: board_usb_init and board_usb_cleanup calls in the fastboot command

[Steve Rae]

On 15-06-16 02:25 PM, Paul Kocialkowski wrote:

Le mardi 16 juin 2015 à 13:58 -0700, Steve Rae a écrit :

Hi Paul,

On 15-06-12 10:57 AM, Paul Kocialkowski wrote:

Each USB download function command calls board_usb_init before registering the
USB gadget and board_usb_cleanup after de-registering it. On devices currently
using fasboot, musb-new is usually initialized earlier, but some other boards
might need the board_usb_init call to properly initialize musb-new.

This requires adding an argument (the USB controller index) to the fastboot
command, as it is currently done with other USB download gadget functions.

Signed-off-by: Paul Kocialkowski 
---
   common/cmd_fastboot.c | 31 +--
   include/configs/ti_omap5_common.h |  2 +-
   2 files changed, 26 insertions(+), 7 deletions(-)

diff --git a/common/cmd_fastboot.c b/common/cmd_fastboot.c
index d52ccfb..86fbddf 100644
--- a/common/cmd_fastboot.c
+++ b/common/cmd_fastboot.c
@@ -10,11 +10,26 @@
   #include 
   #include 
   #include 
+#include 

   static int do_fastboot(cmd_tbl_t *cmdtp, int flag, int argc, char *const 
argv[])
   {
+   int controller_index;
+   char *usb_controller;
int ret;

+   if (argc < 2)
+   return CMD_RET_USAGE;
+
+   usb_controller = argv[1];


Not backwards compatible I would prefer to make it optional:
  if (argc < 2)
  controller_index = 0;
  else {
  usb_controller = argv[1];
  controller_index = simple_strtoul(usb_controller, NULL, 0);
  }


This is definitely a "bug fix". There is no reason to assume that the
USB controller index is 0 and it was incorrect to assume that from the
very beginning. Other download USB gadget commands had the controller
index as a non-optional parameter already.

Since I fixed the configs that use it in U-Boot, I think it's fair
enough. This may indeed break some hand-written scripts but those will
be straightforward to fix.

I am strongly against keeping deprecated legacy fallbacks that make the
code inconsistent and harder to maintain just for the sake of keeping
backwards compatibility with users' hand-written scripts.



I understand, but I'm more worried about _all_ the existing 
documentation that states the the command line is "fastboot" (which now 
would need to be changed to "fastboot 0")



+   controller_index = simple_strtoul(usb_controller, NULL, 0);
+
+   ret = board_usb_init(controller_index, USB_INIT_DEVICE);
+   if (ret) {
+   error("USB init failed: %d", ret);
+   return CMD_RET_FAILURE;
+   }
+
g_dnl_clear_detach();
ret = g_dnl_register("usb_dnl_fastboot");
if (ret)
@@ -23,9 +38,8 @@ static int do_fastboot(cmd_tbl_t *cmdtp, int flag, int argc, 
char *const argv[])
if (!g_dnl_board_usb_cable_connected()) {
puts("\rUSB cable not detected.\n" \
 "Command exit.\n");
-   g_dnl_unregister();
-   g_dnl_clear_detach();
-   return CMD_RET_FAILURE;
+   ret = CMD_RET_FAILURE;
+   goto exit;
}

while (1) {
@@ -36,14 +50,19 @@ static int do_fastboot(cmd_tbl_t *cmdtp, int flag, int 
argc, char *const argv[])
usb_gadget_handle_interrupts(0);
}

+   ret = CMD_RET_SUCCESS;
+
+exit:
g_dnl_unregister();
g_dnl_clear_detach();
-   return CMD_RET_SUCCESS;
+   board_usb_cleanup(controller_index, USB_INIT_DEVICE);
+
+   return ret;
   }

   U_BOOT_CMD(
-   fastboot,   1,  0,  do_fastboot,
+   fastboot, 2, 1, do_fastboot,
"use USB Fastboot protocol",
-   "\n"
+   "\n"


make it optional:
"[]\n"


"- run as a fastboot usb device"
   );
diff --git a/include/configs/ti_omap5_common.h 
b/include/configs/ti_omap5_common.h
index 4faffef..4fd5669 100644
--- a/include/configs/ti_omap5_common.h
+++ b/include/configs/ti_omap5_common.h
@@ -137,7 +137,7 @@
"if test ${dofastboot} -eq 1; then " \
"echo Boot fastboot requested, resetting dofastboot ...;" \
"setenv dofastboot 0; saveenv;" \
-   "echo Booting into fastboot ...; fastboot;" \
+   "echo Booting into fastboot ...; fastboot 0;" \


then this isn't needed either


"fi;" \
"run findfdt; " \
"run mmcboot;" \



Thanks, Steve



___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/3] stv0991: spi env & configs related board changes

[Vikas MANOCHA]

Thanks Jagan.

> -Original Message-
> From: Jagan Teki [mailto:jt...@openedev.com]
> Sent: Tuesday, June 16, 2015 3:50 AM
> To: Vikas MANOCHA
> Cc: u-boot@lists.denx.de; tr...@konsulko.com
> Subject: Re: [U-Boot] [PATCH 0/3] stv0991: spi env & configs related board
> changes
> 
> As these were new feature additions I will take these into spi-next.
> 
> On 16 June 2015 at 02:23, Vikas MANOCHA  wrote:
> > Hi Tom,
> >
> > Can you please apply these patchset for stv0991.
> >
> > Rgds,
> > Vikas
> >
> >> -Original Message-
> >> From: Vikas MANOCHA
> >> Sent: Monday, June 08, 2015 5:47 PM
> >> To: u-boot@lists.denx.de
> >> Cc: Vikas MANOCHA
> >> Subject: [PATCH 0/3] stv0991: spi env & configs related board changes
> >>
> >> This patchset does changes in stv0991 board file to enable saving
> >> environments in spi flash & moves CONFIG_OF in the defconfig file.
> >>
> >> Vikas Manocha (3):
> >>   stv0991: enable saving enrironment in spi flash
> >>   stv0991: move OF_CONTROL config to defconfig
> >>   stv0991: remove define CONFIG_OF_SEPARATE from board file
> >>
> >>  configs/stv0991_defconfig |1 +
> >>  include/configs/stv0991.h |7 +++
> >>  2 files changed, 4 insertions(+), 4 deletions(-)
> >>
> >> --
> >> 1.7.9.5
> 
> thanks!
> --
> Jagan | openedev.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/4] ARM: Tegra210: Add SoC code/include files for T210

[Tom Warren]

> -Original Message-
> From: Stephen Warren [mailto:swar...@wwwdotorg.org]
> Sent: Tuesday, June 16, 2015 1:29 PM
> To: Tom Warren; Tom Warren
> Cc: u-boot@lists.denx.de; Stephen Warren
> Subject: Re: [U-Boot] [PATCH 1/4] ARM: Tegra210: Add SoC code/include files
> for T210
> 
> On 06/15/2015 04:18 PM, Tom Warren wrote:
> > Update WRT gpio.h and hardware.h, below.
> >
> >Tom Warren wrote at Monday, June 15, 2015 1:05 PM:
> >> Stephen Warren wrote at Monday, June 15, 2015 10:11 AM:
> >>> On 06/03/2015 02:35 PM, Tom Warren wrote:
>  All based off of Tegra124. As a Tegra210 board is brought up, these
>  may change a bit to match the HW more closely, but probably 90% of
>  this is identical to T124.
> ...
>  diff --git a/arch/arm/include/asm/arch-tegra210/hardware.h
>  b/arch/arm/include/asm/arch-tegra210/hardware.h
> >>>
> >>> Can we drop this file? I don't see a hardware.h in any of the other
> >>> arch-tegra*/ directories.
> >> Sure. It's never been used AFAICT.
> > Can't drop hardware.h. It's expected to be in every build, included from
> arch/arm/include/asm/hardware.h, created by Wolfgang way back in 2003.
> 
> But there is no hardware.h in any of arch/arm/include/asm/arch-tegra*.h
> in u-boot.git's master branch as of today.
Sorry, I must have  been looking at my u-boot-tegra/next branch, which hasn't 
been sync'd w/master (u-boot or u-boot-tegra) in a while. I'll remove 
hardware.h in the next patchset.

Thanks

--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/4] usb: board_usb_init and board_usb_cleanup calls in the fastboot command

[Paul Kocialkowski]

Le mardi 16 juin 2015 à 13:58 -0700, Steve Rae a écrit :
> Hi Paul,
> 
> On 15-06-12 10:57 AM, Paul Kocialkowski wrote:
> > Each USB download function command calls board_usb_init before registering 
> > the
> > USB gadget and board_usb_cleanup after de-registering it. On devices 
> > currently
> > using fasboot, musb-new is usually initialized earlier, but some other 
> > boards
> > might need the board_usb_init call to properly initialize musb-new.
> >
> > This requires adding an argument (the USB controller index) to the fastboot
> > command, as it is currently done with other USB download gadget functions.
> >
> > Signed-off-by: Paul Kocialkowski 
> > ---
> >   common/cmd_fastboot.c | 31 +--
> >   include/configs/ti_omap5_common.h |  2 +-
> >   2 files changed, 26 insertions(+), 7 deletions(-)
> >
> > diff --git a/common/cmd_fastboot.c b/common/cmd_fastboot.c
> > index d52ccfb..86fbddf 100644
> > --- a/common/cmd_fastboot.c
> > +++ b/common/cmd_fastboot.c
> > @@ -10,11 +10,26 @@
> >   #include 
> >   #include 
> >   #include 
> > +#include 
> >
> >   static int do_fastboot(cmd_tbl_t *cmdtp, int flag, int argc, char *const 
> > argv[])
> >   {
> > +   int controller_index;
> > +   char *usb_controller;
> > int ret;
> >
> > +   if (argc < 2)
> > +   return CMD_RET_USAGE;
> > +
> > +   usb_controller = argv[1];
> 
> Not backwards compatible I would prefer to make it optional:
>  if (argc < 2)
>  controller_index = 0;
>  else {
>  usb_controller = argv[1];
>  controller_index = simple_strtoul(usb_controller, NULL, 0);
>  }

This is definitely a "bug fix". There is no reason to assume that the
USB controller index is 0 and it was incorrect to assume that from the
very beginning. Other download USB gadget commands had the controller
index as a non-optional parameter already.

Since I fixed the configs that use it in U-Boot, I think it's fair
enough. This may indeed break some hand-written scripts but those will
be straightforward to fix.

I am strongly against keeping deprecated legacy fallbacks that make the
code inconsistent and harder to maintain just for the sake of keeping
backwards compatibility with users' hand-written scripts.

> > +   controller_index = simple_strtoul(usb_controller, NULL, 0);
> > +
> > +   ret = board_usb_init(controller_index, USB_INIT_DEVICE);
> > +   if (ret) {
> > +   error("USB init failed: %d", ret);
> > +   return CMD_RET_FAILURE;
> > +   }
> > +
> > g_dnl_clear_detach();
> > ret = g_dnl_register("usb_dnl_fastboot");
> > if (ret)
> > @@ -23,9 +38,8 @@ static int do_fastboot(cmd_tbl_t *cmdtp, int flag, int 
> > argc, char *const argv[])
> > if (!g_dnl_board_usb_cable_connected()) {
> > puts("\rUSB cable not detected.\n" \
> >  "Command exit.\n");
> > -   g_dnl_unregister();
> > -   g_dnl_clear_detach();
> > -   return CMD_RET_FAILURE;
> > +   ret = CMD_RET_FAILURE;
> > +   goto exit;
> > }
> >
> > while (1) {
> > @@ -36,14 +50,19 @@ static int do_fastboot(cmd_tbl_t *cmdtp, int flag, int 
> > argc, char *const argv[])
> > usb_gadget_handle_interrupts(0);
> > }
> >
> > +   ret = CMD_RET_SUCCESS;
> > +
> > +exit:
> > g_dnl_unregister();
> > g_dnl_clear_detach();
> > -   return CMD_RET_SUCCESS;
> > +   board_usb_cleanup(controller_index, USB_INIT_DEVICE);
> > +
> > +   return ret;
> >   }
> >
> >   U_BOOT_CMD(
> > -   fastboot,   1,  0,  do_fastboot,
> > +   fastboot, 2, 1, do_fastboot,
> > "use USB Fastboot protocol",
> > -   "\n"
> > +   "\n"
> 
> make it optional:
>   "[]\n"
> 
> > "- run as a fastboot usb device"
> >   );
> > diff --git a/include/configs/ti_omap5_common.h 
> > b/include/configs/ti_omap5_common.h
> > index 4faffef..4fd5669 100644
> > --- a/include/configs/ti_omap5_common.h
> > +++ b/include/configs/ti_omap5_common.h
> > @@ -137,7 +137,7 @@
> > "if test ${dofastboot} -eq 1; then " \
> > "echo Boot fastboot requested, resetting dofastboot ...;" \
> > "setenv dofastboot 0; saveenv;" \
> > -   "echo Booting into fastboot ...; fastboot;" \
> > +   "echo Booting into fastboot ...; fastboot 0;" \
> 
> then this isn't needed either
> 
> > "fi;" \
> > "run findfdt; " \
> > "run mmcboot;" \
> >
> 
> Thanks, Steve



signature.asc
Description: This is a digitally signed message part
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/4] usb: board_usb_init and board_usb_cleanup calls in the fastboot command

[Steve Rae]

Hi Paul,

On 15-06-12 10:57 AM, Paul Kocialkowski wrote:

Each USB download function command calls board_usb_init before registering the
USB gadget and board_usb_cleanup after de-registering it. On devices currently
using fasboot, musb-new is usually initialized earlier, but some other boards
might need the board_usb_init call to properly initialize musb-new.

This requires adding an argument (the USB controller index) to the fastboot
command, as it is currently done with other USB download gadget functions.

Signed-off-by: Paul Kocialkowski 
---
  common/cmd_fastboot.c | 31 +--
  include/configs/ti_omap5_common.h |  2 +-
  2 files changed, 26 insertions(+), 7 deletions(-)

diff --git a/common/cmd_fastboot.c b/common/cmd_fastboot.c
index d52ccfb..86fbddf 100644
--- a/common/cmd_fastboot.c
+++ b/common/cmd_fastboot.c
@@ -10,11 +10,26 @@
  #include 
  #include 
  #include 
+#include 

  static int do_fastboot(cmd_tbl_t *cmdtp, int flag, int argc, char *const 
argv[])
  {
+   int controller_index;
+   char *usb_controller;
int ret;

+   if (argc < 2)
+   return CMD_RET_USAGE;
+
+   usb_controller = argv[1];


Not backwards compatible I would prefer to make it optional:
if (argc < 2)
controller_index = 0;
else {
usb_controller = argv[1];
controller_index = simple_strtoul(usb_controller, NULL, 0);
}


+   controller_index = simple_strtoul(usb_controller, NULL, 0);
+
+   ret = board_usb_init(controller_index, USB_INIT_DEVICE);
+   if (ret) {
+   error("USB init failed: %d", ret);
+   return CMD_RET_FAILURE;
+   }
+
g_dnl_clear_detach();
ret = g_dnl_register("usb_dnl_fastboot");
if (ret)
@@ -23,9 +38,8 @@ static int do_fastboot(cmd_tbl_t *cmdtp, int flag, int argc, 
char *const argv[])
if (!g_dnl_board_usb_cable_connected()) {
puts("\rUSB cable not detected.\n" \
 "Command exit.\n");
-   g_dnl_unregister();
-   g_dnl_clear_detach();
-   return CMD_RET_FAILURE;
+   ret = CMD_RET_FAILURE;
+   goto exit;
}

while (1) {
@@ -36,14 +50,19 @@ static int do_fastboot(cmd_tbl_t *cmdtp, int flag, int 
argc, char *const argv[])
usb_gadget_handle_interrupts(0);
}

+   ret = CMD_RET_SUCCESS;
+
+exit:
g_dnl_unregister();
g_dnl_clear_detach();
-   return CMD_RET_SUCCESS;
+   board_usb_cleanup(controller_index, USB_INIT_DEVICE);
+
+   return ret;
  }

  U_BOOT_CMD(
-   fastboot,   1,  0,  do_fastboot,
+   fastboot, 2, 1, do_fastboot,
"use USB Fastboot protocol",
-   "\n"
+   "\n"


make it optional:
"[]\n"


"- run as a fastboot usb device"
  );
diff --git a/include/configs/ti_omap5_common.h 
b/include/configs/ti_omap5_common.h
index 4faffef..4fd5669 100644
--- a/include/configs/ti_omap5_common.h
+++ b/include/configs/ti_omap5_common.h
@@ -137,7 +137,7 @@
"if test ${dofastboot} -eq 1; then " \
"echo Boot fastboot requested, resetting dofastboot ...;" \
"setenv dofastboot 0; saveenv;" \
-   "echo Booting into fastboot ...; fastboot;" \
+   "echo Booting into fastboot ...; fastboot 0;" \


then this isn't needed either


"fi;" \
"run findfdt; " \
"run mmcboot;" \



Thanks, Steve
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] If CONFIG_SANDBOX isn't defined the build fails in fw_env.c

[Simon Glass]

+Masahiro, who might have some clues

Hi Tom,

On 16 June 2015 at 14:04, Tom Rini  wrote:
> On Tue, Jun 16, 2015 at 12:24:01PM -0600, Simon Glass wrote:
>> Hi Peter,
>>
>> On 15 June 2015 at 13:40, Peter Robinson  wrote:
>> > In our Fedora builds we get the below errors if we build the following 
>> > using
>> > a vanilla u-boot 2015.07rc2. I'm not sure if it's the best fix but it fixes
>> > the build for rc2.
>> >
>> > make HOSTCC="gcc $RPM_OPT_FLAGS" CROSS_COMPILE="" defconfig V=1 O=builds/
>> > make HOSTCC="gcc $RPM_OPT_FLAGS" CROSS_COMPILE="" tools-all V=1 O=builds/
>> >
>> > gcc -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
>> > -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 
>> > -grecord-gcc-switches  -m64 -mtune=generic -Wp,-MD,tools/env/.fw_env.o.d 
>> > -Itools/env -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer 
>> > -idirafterinclude -idirafter../include -idirafter../arch/sandbox/include 
>> > -idirafter ../tools/env -DUSE_HOSTCC -DTEXT_BASE= -c -o tools/env/fw_env.o 
>> > ../tools/env/fw_env.c
>> > In file included from ../include/configs/sandbox.h:130:0,
>> >  from include/config.h:5,
>> >  from ../tools/env/fw_env.h:11,
>> >  from ../tools/env/fw_env.c:34:
>> > ../include/env_default.h:104:2: error: expected '}' before 
>> > 'BOOT_TARGET_DEVICES_references_HOST_without_CONFIG_SANDBOX'
>> >   CONFIG_EXTRA_ENV_SETTINGS
>> >   ^
>> > scripts/Makefile.host:108: recipe for target 'tools/env/fw_env.o' failed
>> > make[2]: *** [tools/env/fw_env.o] Error 1
>>
>> Thanks for the report. I can't seem to repeat this. The build
>> completes OK for me.
>
> I see it too.  Make sure you start with an empty objdir.  'defconfig'
> and 'sandbox_defconfig' both do it for me.

OK, I see. The oldsilentconfig seem to do something odd. Without that
it works for me. Why is it needed?

(try-peter=0155f0: -- b/ index.html index.html.1 sandbox/ test/) u> !rm
rm -r b/sandbox
(try-peter=0155f0: -- b/ index.html index.html.1 sandbox/ test/) u>
make O=b/sandbox defconfig
make[1]: Entering directory
`/usr/local/google/c/cosarm/src/third_party/u-boot/files/b/sandbox'
  HOSTCC  scripts/basic/fixdep
  GEN ./Makefile
  HOSTCC  scripts/kconfig/conf.o
  SHIPPED scripts/kconfig/zconf.tab.c
  SHIPPED scripts/kconfig/zconf.lex.c
  SHIPPED scripts/kconfig/zconf.hash.c
  HOSTCC  scripts/kconfig/zconf.tab.o
  HOSTLD  scripts/kconfig/conf
*** Default configuration is based on 'sandbox_defconfig'
#
# configuration written to .config
#
make[1]: Leaving directory
`/usr/local/google/c/cosarm/src/third_party/u-boot/files/b/sandbox'
(try-peter=0155f0: -- b/ index.html index.html.1 sandbox/ test/) u>
make O=b/sandbox tools-all -s
/usr/local/google/c/cosarm/src/third_party/u-boot/files/tools/easylogo/easylogo.c:
In function ‘image_load_tga’:
/usr/local/google/c/cosarm/src/third_party/u-boot/files/tools/easylogo/easylogo.c:160:8:
warning: ignoring return value of ‘fread’, declared with attribute
warn_unused_result [-Wunused-result]
  fread (&header, sizeof (header), 1, file);
^
/usr/local/google/c/cosarm/src/third_party/u-boot/files/tools/easylogo/easylogo.c:196:8:
warning: ignoring return value of ‘fread’, declared with attribute
warn_unused_result [-Wunused-result]
  fread (image->data, image->size, 1, file);
^
(try-peter=0155f0: -- b/ index.html index.html.1 sandbox/ test/) u> !rm
rm -r b/sandbox
(try-peter=0155f0: -- b/ index.html index.html.1 sandbox/ test/) u>
make O=b/sandbox defconfig
make[1]: Entering directory
`/usr/local/google/c/cosarm/src/third_party/u-boot/files/b/sandbox'
  HOSTCC  scripts/basic/fixdep
  GEN ./Makefile
  HOSTCC  scripts/kconfig/conf.o
  SHIPPED scripts/kconfig/zconf.tab.c
  SHIPPED scripts/kconfig/zconf.lex.c
  SHIPPED scripts/kconfig/zconf.hash.c
  HOSTCC  scripts/kconfig/zconf.tab.o
  HOSTLD  scripts/kconfig/conf
*** Default configuration is based on 'sandbox_defconfig'
#
# configuration written to .config
#
make[1]: Leaving directory
`/usr/local/google/c/cosarm/src/third_party/u-boot/files/b/sandbox'
(try-peter=0155f0: -- b/ index.html index.html.1 sandbox/ test/) u>
make O=b/sandbox silentoldconfig
make[1]: Entering directory
`/usr/local/google/c/cosarm/src/third_party/u-boot/files/b/sandbox'
  GEN ./Makefile
scripts/kconfig/conf --silentoldconfig Kconfig
make[1]: Leaving directory
`/usr/local/google/c/cosarm/src/third_party/u-boot/files/b/sandbox'
(try-peter=0155f0: -- b/ index.html index.html.1 sandbox/ test/) u>
make O=b/sandbox tools-all -s
In file included from
/usr/local/google/c/cosarm/src/third_party/u-boot/files/tools/env/fw_env.c:34:0:
/usr/local/google/c/cosarm/src/third_party/u-boot/files/tools/env/fw_env.h:11:20:
fatal error: config.h: No such file or directory
 #include 
^
compilation terminated.
make[2]: *** [tools/env/fw_env.o] Error 1
make[1]: *** [env] Error 2
make: *** [sub-make] Error 2


So it seems to work fine without silentoldconfig. A normal 'defconf

Re: [U-Boot] [PATCH 1/4] ARM: Tegra210: Add SoC code/include files for T210

[Stephen Warren]

On 06/15/2015 04:18 PM, Tom Warren wrote:

Update WRT gpio.h and hardware.h, below.

Tom Warren wrote at Monday, June 15, 2015 1:05 PM:

Stephen Warren wrote at Monday, June 15, 2015 10:11 AM:

On 06/03/2015 02:35 PM, Tom Warren wrote:

All based off of Tegra124. As a Tegra210 board is brought up, these
may change a bit to match the HW more closely, but probably 90% of
this is identical to T124.

...

diff --git a/arch/arm/include/asm/arch-tegra210/hardware.h
b/arch/arm/include/asm/arch-tegra210/hardware.h


Can we drop this file? I don't see a hardware.h in any of the other
arch-tegra*/ directories.

Sure. It's never been used AFAICT.

Can't drop hardware.h. It's expected to be in every build, included from 
arch/arm/include/asm/hardware.h, created by Wolfgang way back in 2003.


But there is no hardware.h in any of arch/arm/include/asm/arch-tegra*.h 
in u-boot.git's master branch as of today.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/4] ARM: Tegra210: Add SoC code/include files for T210

[Stephen Warren]

On 06/15/2015 02:04 PM, Tom Warren wrote:




-Original Message-
From: Stephen Warren [mailto:swar...@wwwdotorg.org]
Sent: Monday, June 15, 2015 10:11 AM
To: Tom Warren
Cc: u-boot@lists.denx.de; Stephen Warren; Tom Warren
Subject: Re: [U-Boot] [PATCH 1/4] ARM: Tegra210: Add SoC code/include files
for T210

On 06/03/2015 02:35 PM, Tom Warren wrote:

All based off of Tegra124. As a Tegra210 board is brought up, these
may change a bit to match the HW more closely, but probably 90% of
this is identical to T124.


Rather than duplicating lots of headers and code, can we share the content
with other chips?

>

Sure, but I wasn't looking at this patchset as a reworking of all Tegra common 
headers, but an inclusion of T210 support. We can then move to common/shared 
content after this is in, or someone (you?) can do it now before I add T210 
support, but that'll delay it.


The problem here is that the same excuse against cleanup is made every 
time a new SoC comes along, and the cleanup never happens.



diff --git a/arch/arm/include/asm/arch-tegra210/funcmux.h
b/arch/arm/include/asm/arch-tegra210/funcmux.h


We should be able to drop funcmux support completely now that we're
programming entire board pinmux tables.

>

I'll look into it, but I believe funcmux is only used to get early UART muxes 
set, which is done before the pinmux table is parsed/written.


There's no guarantee funcmux will work in general for the UARTs. The 
best solution would be to apply the pinmux table before doing anything. 
That way, we wouldn't need anything custom to try and get the UART working.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] If CONFIG_SANDBOX isn't defined the build fails in fw_env.c

[Tom Rini]

On Tue, Jun 16, 2015 at 12:24:01PM -0600, Simon Glass wrote:
> Hi Peter,
> 
> On 15 June 2015 at 13:40, Peter Robinson  wrote:
> > In our Fedora builds we get the below errors if we build the following using
> > a vanilla u-boot 2015.07rc2. I'm not sure if it's the best fix but it fixes
> > the build for rc2.
> >
> > make HOSTCC="gcc $RPM_OPT_FLAGS" CROSS_COMPILE="" defconfig V=1 O=builds/
> > make HOSTCC="gcc $RPM_OPT_FLAGS" CROSS_COMPILE="" tools-all V=1 O=builds/
> >
> > gcc -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
> > -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 
> > -grecord-gcc-switches  -m64 -mtune=generic -Wp,-MD,tools/env/.fw_env.o.d 
> > -Itools/env -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer 
> > -idirafterinclude -idirafter../include -idirafter../arch/sandbox/include 
> > -idirafter ../tools/env -DUSE_HOSTCC -DTEXT_BASE= -c -o tools/env/fw_env.o 
> > ../tools/env/fw_env.c
> > In file included from ../include/configs/sandbox.h:130:0,
> >  from include/config.h:5,
> >  from ../tools/env/fw_env.h:11,
> >  from ../tools/env/fw_env.c:34:
> > ../include/env_default.h:104:2: error: expected '}' before 
> > 'BOOT_TARGET_DEVICES_references_HOST_without_CONFIG_SANDBOX'
> >   CONFIG_EXTRA_ENV_SETTINGS
> >   ^
> > scripts/Makefile.host:108: recipe for target 'tools/env/fw_env.o' failed
> > make[2]: *** [tools/env/fw_env.o] Error 1
> 
> Thanks for the report. I can't seem to repeat this. The build
> completes OK for me.

I see it too.  Make sure you start with an empty objdir.  'defconfig'
and 'sandbox_defconfig' both do it for me.

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] USB ethernet support broken with device-model?

[Simon Glass]

+Joe (Network maintainer)

Hi,

On 14 June 2015 at 08:08, Karsten Merker  wrote:
> Hello,
>
> I am trying to build current u-boot master for the (sunxi-based)
> MSI_Primo81 target with support for an ASIX AX88772B USB ethernet
> adapter. Setting
>
> CONFIG_SYS_EXTRA_OPTIONS="USB_HOST_ETHER,USB_ETHER_ASIX"
>
> via make menuconfig results in the following build error:
>
> [...]
>   CC  common/main.o
>   CC  common/board_f.o
>   CC  common/cmd_version.o
>   LD  common/built-in.o
>   CC  drivers/video/cfb_console.o
>   LD  drivers/video/built-in.o
>   LD  drivers/built-in.o
>   CC  drivers/usb/eth/usb_ether.o
> In file included from drivers/usb/eth/usb_ether.c:12:0:
> include/usb_ether.h:24:20: error: field 'eth_dev' has incomplete type
>   struct eth_device eth_dev;  /* used with eth_register */
> ^
> drivers/usb/eth/usb_ether.c: In function 'is_eth_dev_on_usb_host':
> drivers/usb/eth/usb_ether.c:68:27: warning: initialization from incompatible 
> pointer type
>   struct eth_device *dev = eth_get_dev();
>^
> drivers/usb/eth/usb_ether.c: In function 'probe_valid_drivers':
> drivers/usb/eth/usb_ether.c:106:4: warning: implicit declaration of function 
> 'eth_register' [-Wimplicit-function-declaration]
> eth_register(eth);
> ^
> drivers/usb/eth/usb_ether.c:107:4: warning: implicit declaration of function 
> 'eth_write_hwaddr' [-Wimplicit-function-declaration]
> if (eth_write_hwaddr(eth, "usbeth",
> ^
> drivers/usb/eth/usb_ether.c: In function 'usb_host_eth_scan':
> drivers/usb/eth/usb_ether.c:131:3: warning: implicit declaration of function 
> 'eth_unregister' [-Wimplicit-function-declaration]
>eth_unregister(&usb_eth[i].eth_dev);
>^
> scripts/Makefile.build:276: recipe for target 'drivers/usb/eth/usb_ether.o' 
> failed
> make[1]: *** [drivers/usb/eth/usb_ether.o] Error 1
> Makefile:1158: recipe for target 'drivers/usb/eth' failed
> make: *** [drivers/usb/eth] Error 2
>
> This appears to be a device-model related issue. With the default
> configuration, which includes CONFIG_DM_ETH=y, the above error
> occurs, but with CONFIG_DM_ETH unset, the build succeeds.  The
> problem seems to be with the definition of struct eth_device in
> include/net.h, which is bracketed by an #ifndef CONFIG_DM_ETH /
> #endif (lines 147-214).  I know about nothing about how
> device-model works in u-boot, so I am stuck here.  Simon, could
> you perhaps take a look at the issue?

Yes, USB Ethernet does not support driver model for Ethernet /
CONFIG_DM_ETH yet.

It would be great to add this if you'd like to give it a crack.

Some hints:

- declare a USB_DEVICE() in asix.c with the appropriate vendor/device
IDs using usb_device_id (see usb_storage.c for how the storage driver
does it). You'll want to take the IDs from asix_dongles[] and use the
USB_DEVICE_ID_MATCH_VENDOR and USB_DEVICE_ID_MATCH_PRODUCT flags
- add a U_BOOT_DRIVER() in asix.c which defines the
start/send/recv/stop methods (see sunxi_emac.c for an example)
- don't compile in usb_ether.c if CONFIG_DM_ETH is set (the USB
subsystem should automatically scan and find your driver as it does
with storage)
- skip calling usb_host_eth_scan() from cmd_usb.c if CONFIG_DM_ETH is set
- hack up asix.c to remove asix_eth_probe() and asix_eth_get_info()
when CONFIG_DM_ETH is set

I'm happy to review and test.

[snip]

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] If CONFIG_SANDBOX isn't defined the build fails in fw_env.c

[Simon Glass]

Hi Peter,

On 15 June 2015 at 13:40, Peter Robinson  wrote:
> In our Fedora builds we get the below errors if we build the following using
> a vanilla u-boot 2015.07rc2. I'm not sure if it's the best fix but it fixes
> the build for rc2.
>
> make HOSTCC="gcc $RPM_OPT_FLAGS" CROSS_COMPILE="" defconfig V=1 O=builds/
> make HOSTCC="gcc $RPM_OPT_FLAGS" CROSS_COMPILE="" tools-all V=1 O=builds/
>
> gcc -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
> -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 
> -grecord-gcc-switches  -m64 -mtune=generic -Wp,-MD,tools/env/.fw_env.o.d 
> -Itools/env -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer 
> -idirafterinclude -idirafter../include -idirafter../arch/sandbox/include 
> -idirafter ../tools/env -DUSE_HOSTCC -DTEXT_BASE= -c -o tools/env/fw_env.o 
> ../tools/env/fw_env.c
> In file included from ../include/configs/sandbox.h:130:0,
>  from include/config.h:5,
>  from ../tools/env/fw_env.h:11,
>  from ../tools/env/fw_env.c:34:
> ../include/env_default.h:104:2: error: expected '}' before 
> 'BOOT_TARGET_DEVICES_references_HOST_without_CONFIG_SANDBOX'
>   CONFIG_EXTRA_ENV_SETTINGS
>   ^
> scripts/Makefile.host:108: recipe for target 'tools/env/fw_env.o' failed
> make[2]: *** [tools/env/fw_env.o] Error 1

Thanks for the report. I can't seem to repeat this. The build
completes OK for me.

CONFIG_SANDBOX is defined in arch/Kconfig. It ends up in your build
directory in these files.

b/sandbox/include/config/auto.conf:CONFIG_SANDBOX=y
b/sandbox/include/generated/autoconf.h:#define CONFIG_SANDBOX 1

autoconf.h is the one that matters. I wonder why this is not included
in your case?

I notice that fw_env.h starts like this:

/* Pull in the current config to define the default environment */
#ifndef __ASSEMBLY__
#define __ASSEMBLY__ /* get only #defines from config.h */
#include 
#undef __ASSEMBLY__
#else
#include 
#endif
#include 

Should the inclusion of autoconf.h go above the inclusion of config.h, perhaps?

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] fdt: prevent clearing memory node if there are no banks

[Simon Glass]

Hi,

On 13 June 2015 at 04:43, Andre Przywara  wrote:
>
> Avoid clearing the reg property in the memory DT node if no memory
> banks have been specified for a board (CONFIG_NR_DRAM_BANKS == 0).
> This allows boards to let U-Boot skip the DT memory tinkering in case
> other firmware has already setup the node properly before.
> This should be safe as all callers of fdt_fixup_memory_banks that use
> a computed  value put at least 1 in there.
> Add some documentation comments to the header file.
>
> Signed-off-by: Andre Przywara 
> ---
> Hi,
>
> this replaces my former "6/8: ARM: bootm: allow skipping fdt memory node 
> fixup"
> patch, as Simon had some (justified) concerns. If this is too generic now,
> let me know and I will rework it.
>
> Cheers,
> Andre.
>
>  common/fdt_support.c  | 14 --
>  include/fdt_support.h | 26 ++
>  2 files changed, 34 insertions(+), 6 deletions(-)

Acked-by: Simon Glass 

Tom, you can pick this up if you like?

- Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Ask for help: Compulab CM-510 U-boot version: Load Kernel from SD-Card

[Gandha Naringrekar]

WHAT IS MINIMUM BATCH SIZE USING COMPULAB 48" COATING PAN WITH BD OF TABLETS IS 
0.69


Gandha Naringrekar
Sr. Manager, R&D
Aurobindo Pharma USA
6 Wheeling Road
Dayton, NJ 08810
Phone: 732-230-8229
Cell :732-310-5515
gnaringre...@aurobindousa.com

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PULL] u-boot-usb/master

[Tom Rini]

On Tue, Jun 16, 2015 at 01:14:09AM +0200, Marek Vasut wrote:

> The following changes since commit 5bcec545a6ca977ad74ee9fe0f2b335d348b5000:
> 
>   image-fit: Fix compiler warning in fit_conf_print() (2015-06-06 09:30:20 
> -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-usb.git HEAD
> 
> for you to fetch changes up to 2911bd1858d11308164b0b33de4ea0e8994d3edf:
> 
>   samsung: common: add example boot scripts (2015-06-08 15:26:11 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/3] am43xx_evm: add eth boot support

[Tom Rini]

On Tue, Jun 16, 2015 at 08:23:39PM +0530, Mugunthan V N wrote:

> add cpsw ethernet boot mode support to download spl and
> u-boot.img via tftp protocol. Also adding a seperate config
> for ethernet boot mode as the default build falcon mode and
> environment on MMC is defined for ethernet boot mode
> environment should be set to nowhere.
> 
> Signed-off-by: Mugunthan V N 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: DRA7: Change configuration to prevent DDR reset control from EMIF

[Tom Rini]

On Tue, Jun 16, 2015 at 08:29:01AM -0500, Nishanth Menon wrote:

> DRA7/AM57xx devices can be operated in many different configurations.
> When the SoC is supposed to support a configuration where low power mode
> state may involve the SoC completely powered off and DDR is in self
> refresh, SoC EMIF controller should not be the master of the reset
> signal and an external entity might be in control of things.
> 
> The default configuration of Linux on TI evms involve not powering off
> the voltage rails (due to various reasons including reliability concerns)
> and must not allow DDR reset to be controlled by EMIF. On platforms
> where external entity might control the reset signal, this configuration
> will be a "dont care".
> 
> Fixes: 536d87470869 ("ARM: DRA7: Update DDR IO registers")
> Tested-by: Keerthy 
> Acked-by: Brad Griffis 
> Signed-off-by: Nishanth Menon 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] ti: armv7: enable EXT support in SPL (using ti_armv7_common.h)

[Tom Rini]

On Tue, Jun 16, 2015 at 03:00:09PM +0200, Guillaume GARDET wrote:

> Tested on Pandaboard (rev. A3) and Beagleboard xM (rev. B).
> Compilation tested on TI armv7 boards and OMAP boards from other vendors.
> 
> Signed-off-by: Guillaume GARDET 
> Cc: Tom Rini 
> 

Reviewed-by: Tom Rini 

-- 
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: BeagleBoard-X15: Enable VTT regulator

[Tom Rini]

On Tue, Jun 16, 2015 at 08:36:05PM +0530, Lokesh Vutla wrote:

> BeagleBoard-X15 uses a vtt regulator for DDR3 termination
> and this is controlled by gpio7_11. Configuring gpio7_11.
> 
> Signed-off-by: Lokesh Vutla 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 2/3] am43xx_evm: add usb host boot support

[Tom Rini]

On Tue, Jun 16, 2015 at 08:23:38PM +0530, Mugunthan V N wrote:

> While booting via usb host mode, ROM uses DMA to copy MLO over USB so
> ARM internal RAM cannot be used. Adding USB host boot support by
> introducing new config target which sets SPL_TEXT_BASE to OCMC ram.
> 
> Signed-off-by: Mugunthan V N 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] ti: omap4: remove CONFIG_SPL_EXT_SUPPORT from ti_omap4_common.h since it is now in ti_armv7_common.h

[Tom Rini]

On Tue, Jun 16, 2015 at 03:00:10PM +0200, Guillaume GARDET wrote:

> Signed-off-by: Guillaume GARDET 
> Cc: Tom Rini 
> 

Reviewed-by: Tom Rini 

-- 
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] ARM: BeagleBoard-X15: Enable VTT regulator

[Lokesh Vutla]

BeagleBoard-X15 uses a vtt regulator for DDR3 termination
and this is controlled by gpio7_11. Configuring gpio7_11.

Signed-off-by: Lokesh Vutla 
---
 board/ti/beagle_x15/board.c  | 23 +++
 include/configs/beagle_x15.h |  2 ++
 2 files changed, 25 insertions(+)

diff --git a/board/ti/beagle_x15/board.c b/board/ti/beagle_x15/board.c
index b6c17ec..c7f19c7 100644
--- a/board/ti/beagle_x15/board.c
+++ b/board/ti/beagle_x15/board.c
@@ -14,6 +14,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -30,6 +32,9 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
+/* GPIO 7_11 */
+#define GPIO_DDR_VTT_EN 203
+
 const struct omap_sysinfo sysinfo = {
"Board: BeagleBoard x15\n"
 };
@@ -404,3 +409,21 @@ int board_eth_init(bd_t *bis)
return ret;
 }
 #endif
+
+#ifdef CONFIG_BOARD_EARLY_INIT_F
+/* VTT regulator enable */
+static inline void vtt_regulator_enable(void)
+{
+   if (omap_hw_init_context() == OMAP_INIT_CONTEXT_UBOOT_AFTER_SPL)
+   return;
+
+   gpio_request(GPIO_DDR_VTT_EN, "ddr_vtt_en");
+   gpio_direction_output(GPIO_DDR_VTT_EN, 1);
+}
+
+int board_early_init_f(void)
+{
+   vtt_regulator_enable();
+   return 0;
+}
+#endif
diff --git a/include/configs/beagle_x15.h b/include/configs/beagle_x15.h
index 8d072c6..c5dde99 100644
--- a/include/configs/beagle_x15.h
+++ b/include/configs/beagle_x15.h
@@ -18,6 +18,8 @@
 #define CONFIG_IODELAY_RECALIBRATION
 #endif
 
+#define CONFIG_BOARD_EARLY_INIT_F
+
 #define CONFIG_NR_DRAM_BANKS   2
 
 #define CONFIG_ENV_SIZE(64 << 10)
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 3/3] am43xx_evm: add eth boot support

[Mugunthan V N]

add cpsw ethernet boot mode support to download spl and
u-boot.img via tftp protocol. Also adding a seperate config
for ethernet boot mode as the default build falcon mode and
environment on MMC is defined for ethernet boot mode
environment should be set to nowhere.

Signed-off-by: Mugunthan V N 
---
 configs/am43xx_evm_ethboot_defconfig |  5 +
 include/configs/am43xx_evm.h | 11 +--
 2 files changed, 14 insertions(+), 2 deletions(-)
 create mode 100644 configs/am43xx_evm_ethboot_defconfig

diff --git a/configs/am43xx_evm_ethboot_defconfig 
b/configs/am43xx_evm_ethboot_defconfig
new file mode 100644
index 000..5b07cc1
--- /dev/null
+++ b/configs/am43xx_evm_ethboot_defconfig
@@ -0,0 +1,5 @@
+CONFIG_ARM=y
+CONFIG_TARGET_AM43XX_EVM=y
+CONFIG_SPL=y
+CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,NAND,SPL_ETH_SUPPORT"
+CONFIG_CMD_NET=y
diff --git a/include/configs/am43xx_evm.h b/include/configs/am43xx_evm.h
index e1cd7a8..0526bd4 100644
--- a/include/configs/am43xx_evm.h
+++ b/include/configs/am43xx_evm.h
@@ -317,11 +317,11 @@
 
 #endif
 
+#ifndef CONFIG_SPL_BUILD
 /* CPSW Ethernet */
 #define CONFIG_CMD_DHCP
 #define CONFIG_CMD_PING
 #define CONFIG_CMD_MII
-#define CONFIG_DRIVER_TI_CPSW
 #define CONFIG_MII
 #define CONFIG_BOOTP_DEFAULT
 #define CONFIG_BOOTP_DNS
@@ -331,13 +331,20 @@
 #define CONFIG_BOOTP_SUBNETMASK
 #define CONFIG_NET_RETRY_COUNT 10
 #define CONFIG_PHY_GIGE
+#endif
+
+#define CONFIG_DRIVER_TI_CPSW
 #define CONFIG_PHYLIB
 
 #define CONFIG_SPL_ENV_SUPPORT
 #define CONFIG_SPL_NET_VCI_STRING  "AM43xx U-Boot SPL"
 
-#define CONFIG_SPL_ETH_SUPPORT
+#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_ETH_SUPPORT)
+#undef CONFIG_ENV_IS_IN_FAT
+#define CONFIG_ENV_IS_NOWHERE
 #define CONFIG_SPL_NET_SUPPORT
+#endif
+
 #define CONFIG_SYS_RX_ETH_BUFFER   64
 
 /* NAND support */
-- 
2.4.2.387.gf86f31a

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 0/3] Add usb host and ethernet boot support

[Mugunthan V N]

This patch set adds support for usb host boot and
ethernet boot support

Changes from initial version:
* Used standard defines like CONFIG_SPL_USB_HOST_SUPPORT instead
  of introducing new defines as commented by Tom Rini.

Mugunthan V N (2):
  am43xx_evm: add usb host boot support
  am43xx_evm: add eth boot support

Tom Rini (1):
  am43xx: Update CONFIG_SPL_TEXT_BASE

 configs/am43xx_evm_ethboot_defconfig  |  5 +
 configs/am43xx_evm_usbhost_boot_defconfig |  5 +
 include/configs/am43xx_evm.h  | 23 ---
 3 files changed, 30 insertions(+), 3 deletions(-)
 create mode 100644 configs/am43xx_evm_ethboot_defconfig
 create mode 100644 configs/am43xx_evm_usbhost_boot_defconfig

-- 
2.4.2.387.gf86f31a

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 2/3] am43xx_evm: add usb host boot support

[Mugunthan V N]

While booting via usb host mode, ROM uses DMA to copy MLO over USB so
ARM internal RAM cannot be used. Adding USB host boot support by
introducing new config target which sets SPL_TEXT_BASE to OCMC ram.

Signed-off-by: Mugunthan V N 
---
 configs/am43xx_evm_usbhost_boot_defconfig |  5 +
 include/configs/am43xx_evm.h  | 12 +++-
 2 files changed, 16 insertions(+), 1 deletion(-)
 create mode 100644 configs/am43xx_evm_usbhost_boot_defconfig

diff --git a/configs/am43xx_evm_usbhost_boot_defconfig 
b/configs/am43xx_evm_usbhost_boot_defconfig
new file mode 100644
index 000..071deac
--- /dev/null
+++ b/configs/am43xx_evm_usbhost_boot_defconfig
@@ -0,0 +1,5 @@
+CONFIG_ARM=y
+CONFIG_TARGET_AM43XX_EVM=y
+CONFIG_SPL=y
+CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,NAND,SPL_USB_HOST_SUPPORT"
+CONFIG_CMD_NET=y
diff --git a/include/configs/am43xx_evm.h b/include/configs/am43xx_evm.h
index ade7151..e1cd7a8 100644
--- a/include/configs/am43xx_evm.h
+++ b/include/configs/am43xx_evm.h
@@ -42,7 +42,16 @@
 #define CONFIG_POWER_TPS62362
 
 /* SPL defines. */
+#ifdef CONFIG_SPL_USB_HOST_SUPPORT
+/*
+ * For USB host boot, ROM uses DMA for copying MLO from USB storage
+ * and ARM internal ram is not accessible for DMA, so SPL text base
+ * should be in OCMC ram
+ */
+#define CONFIG_SPL_TEXT_BASE   0x40300350
+#else
 #define CONFIG_SPL_TEXT_BASE   0x402F4000
+#endif
 #define CONFIG_SPL_MAX_SIZE(220 << 10) /* 220KB */
 #define CONFIG_SYS_SPL_ARGS_ADDR   (CONFIG_SYS_SDRAM_BASE + \
 (128 << 20))
@@ -95,8 +104,8 @@
 #define CONFIG_SPL_LDSCRIPT"$(CPUDIR)/omap-common/u-boot-spl.lds"
 
 /* SPL USB Support */
+#ifdef CONFIG_SPL_USB_HOST_SUPPORT
 #define CONFIG_SPL_USB_SUPPORT
-#define CONFIG_SPL_USB_HOST_SUPPORT
 #define CONFIG_SYS_USB_FAT_BOOT_PARTITION  1
 
 #define CONFIG_CMD_USB
@@ -108,6 +117,7 @@
 
 #define CONFIG_OMAP_USB_PHY
 #define CONFIG_AM437X_USB2PHY2_HOST
+#endif
 
 /* USB GADGET */
 #if !defined(CONFIG_SPL_BUILD) || \
-- 
2.4.2.387.gf86f31a

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 1/3] am43xx: Update CONFIG_SPL_TEXT_BASE

[Mugunthan V N]

From: Tom Rini 

With 1.2 silicon this is now the documented starting usable point for
downloading images to (and corrects a problem with peripheral booting
with prior silicon).  Prior silicon is OK using this address as well.

Signed-off-by: Tom Rini 
Signed-off-by: Mugunthan V N 
---
 include/configs/am43xx_evm.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/am43xx_evm.h b/include/configs/am43xx_evm.h
index 9d65111..ade7151 100644
--- a/include/configs/am43xx_evm.h
+++ b/include/configs/am43xx_evm.h
@@ -42,7 +42,7 @@
 #define CONFIG_POWER_TPS62362
 
 /* SPL defines. */
-#define CONFIG_SPL_TEXT_BASE   0x40300350
+#define CONFIG_SPL_TEXT_BASE   0x402F4000
 #define CONFIG_SPL_MAX_SIZE(220 << 10) /* 220KB */
 #define CONFIG_SYS_SPL_ARGS_ADDR   (CONFIG_SYS_SDRAM_BASE + \
 (128 << 20))
-- 
2.4.2.387.gf86f31a

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] mx53loco: Use generic 'load' command instead of 'fatload'

[Liu Jason]

> -Original Message-
> From: Guillaume GARDET [mailto:guillaume.gar...@free.fr]
> Sent: Tuesday, June 16, 2015 5:49 PM
> To: u-boot@lists.denx.de
> Cc: Guillaume GARDET; Liu Hui-R64343; Stefano Babic
> Subject: [U-Boot] [PATCH] mx53loco: Use generic 'load' command instead of
> 'fatload'
> 
> This patch uses generic 'load' command instead of 'fatload' for
> 'loadbootscript', 'loadimage' and 'loadfdt' for mx53loco board.
> 
> This allows to use EXT partition instead of FAT, while keeping FAT
> compatibility.
> 
> Signed-off-by: Guillaume GARDET 
> 
> Cc: Jason Liu 
> Cc: Stefano Babic 

Acked-by: Jason Liu 

> 
> ---
>  include/configs/mx53loco.h | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/include/configs/mx53loco.h b/include/configs/mx53loco.h
> index db551a9..b3ac5e2 100644
> --- a/include/configs/mx53loco.h
> +++ b/include/configs/mx53loco.h
> @@ -43,6 +43,7 @@
>  #define CONFIG_MMC
>  #define CONFIG_CMD_MMC
>  #define CONFIG_GENERIC_MMC
> +#define CONFIG_CMD_FS_GENERIC
>  #define CONFIG_CMD_FAT
>  #define CONFIG_CMD_EXT2
>  #define CONFIG_DOS_PARTITION
> @@ -116,11 +117,11 @@
>   "mmcroot=/dev/mmcblk0p2 rw rootwait\0" \
>   "mmcargs=setenv bootargs console=ttymxc0,${baudrate}
> root=${mmcroot}\0" \
>   "loadbootscript=" \
> - "fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
> + "load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
>   "bootscript=echo Running bootscript from mmc ...; " \
>   "source\0" \
> - "loadimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${image}\0"
> \
> - "loadfdt=fatload mmc ${mmcdev}:${mmcpart} ${fdt_addr}
> ${fdt_file}\0" \
> + "loadimage=load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${image}\0" \
> + "loadfdt=load mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0" \
>   "mmcboot=echo Booting from mmc ...; " \
>   "run mmcargs; " \
>   "if test ${boot_fdt} = yes || test ${boot_fdt} = try; then "
> \
> --
> 1.8.4.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/4] zynqmp: Kconfig: Move zynqmp Kconfig

[Michal Simek]

Hi,

On 06/16/2015 04:45 AM, Simon Glass wrote:
> Hi Michal,
> 
> On 15 June 2015 at 03:24, Michal Simek  wrote:
>> On 06/15/2015 11:03 AM, Masahiro Yamada wrote:
>>> Hi Michal,
>>>
>>>
>>> 2015-06-15 17:53 GMT+09:00 Michal Simek :
 On 06/10/2015 12:20 PM, Siva Durga Prasad Paladugu wrote:
> Move the zynqmp Kconfig from board to arch
> as there may be different boards under same
> architecture.
>
> Signed-off-by: Siva Durga Prasad Paladugu 
> ---
>  arch/arm/Kconfig   |3 ++-
>  .../xilinx => arch/arm/cpu/armv8}/zynqmp/Kconfig   |0
>  2 files changed, 2 insertions(+), 1 deletions(-)
>  rename {board/xilinx => arch/arm/cpu/armv8}/zynqmp/Kconfig (100%)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 2985e6e..ca2c410 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -850,6 +850,8 @@ source "arch/arm/mach-zynq/Kconfig"
>
>  source "arch/arm/cpu/armv7/Kconfig"
>
> +source "arch/arm/cpu/armv8/zynqmp/Kconfig"
> +
>  source "arch/arm/cpu/armv8/Kconfig"
>
>  source "arch/arm/imx-common/Kconfig"
> @@ -967,7 +969,6 @@ source "board/warp/Kconfig"
>  source "board/woodburn/Kconfig"
>  source "board/work-microwave/work_92105/Kconfig"
>  source "board/xaeniax/Kconfig"
> -source "board/xilinx/zynqmp/Kconfig"
>  source "board/zipitz2/Kconfig"
>
>  source "arch/arm/Kconfig.debug"
> diff --git a/board/xilinx/zynqmp/Kconfig 
> b/arch/arm/cpu/armv8/zynqmp/Kconfig
> similarity index 100%
> rename from board/xilinx/zynqmp/Kconfig
> rename to arch/arm/cpu/armv8/zynqmp/Kconfig
>

 Masahiro/Simon: Can you see any problem with these patches?
>>>
>>> I do not see any problem.
>>>
>>>
 I want to make sure that we are align with your other activities.
>>>
>>> I do not currently have any activities that could have conflicts with
>>> this series.
>>
>> Ok great. Will wait for Simon if he has any concern. If not, I will
>> apply this series.
> 
> LGTM.

Good sign that our internal review make sense. :-)
Anyway applied and will be queued for the next version.

Tom: I expect that this should to go to the next version but I am happy
to send pull request for 2015.07 if you accept that.

Cheers,
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] [U-Boot PATCH v2 13/17] dts: zynq: Enable spi1 for zc770_xm010 board

[Michal Simek]

On 06/16/2015 01:28 PM, Jagan Teki wrote:
> Hi Michal,
> 
> On 10 May 2015 at 20:45, Jagan Teki  wrote:
>> This patch enables spi1 for zynq zc770_xm010 board dts.
>>
>> Signed-off-by: Jagan Teki 
>> Acked-by: Simon Glass 
>> Cc: Michal Simek 
>> Cc: Siva Durga Prasad Paladugu 
>> ---
>>  arch/arm/dts/zynq-zc770-xm010.dts | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/arch/arm/dts/zynq-zc770-xm010.dts 
>> b/arch/arm/dts/zynq-zc770-xm010.dts
>> index 5e66174..e793a61 100644
>> --- a/arch/arm/dts/zynq-zc770-xm010.dts
>> +++ b/arch/arm/dts/zynq-zc770-xm010.dts
>> @@ -21,3 +21,7 @@
>> reg = <0 0x4000>;
>> };
>>  };
>> +
>> +&spi1 {
>> +   status = "okay";
>> +};
> 
> Did you find this, its not working with this type enabling in board
> dts instead it works only with
> aliases {
> serial0 = &uart1;
> spi1 = "/spi@e0007000";
> };

Sorry I haven't had any time to test this but if you want to use aliases
please use &spi1 which does better job.

Thanks,
Michal


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] ARM: DRA7: Change configuration to prevent DDR reset control from EMIF

[Nishanth Menon]

DRA7/AM57xx devices can be operated in many different configurations.
When the SoC is supposed to support a configuration where low power mode
state may involve the SoC completely powered off and DDR is in self
refresh, SoC EMIF controller should not be the master of the reset
signal and an external entity might be in control of things.

The default configuration of Linux on TI evms involve not powering off
the voltage rails (due to various reasons including reliability concerns)
and must not allow DDR reset to be controlled by EMIF. On platforms
where external entity might control the reset signal, this configuration
will be a "dont care".

Fixes: 536d87470869 ("ARM: DRA7: Update DDR IO registers")
Tested-by: Keerthy 
Acked-by: Brad Griffis 
Signed-off-by: Nishanth Menon 
---

Based on master b48b69ba10fd Merge git://git.denx.de/u-boot-marvell

 arch/arm/cpu/armv7/omap5/hw_data.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c 
b/arch/arm/cpu/armv7/omap5/hw_data.c
index f1a59a3ca918..3a723cace71a 100644
--- a/arch/arm/cpu/armv7/omap5/hw_data.c
+++ b/arch/arm/cpu/armv7/omap5/hw_data.c
@@ -602,8 +602,8 @@ const struct ctrl_ioregs ioregs_dra7xx_es1 = {
.ctrl_ddrio_0 = 0x00094A40,
.ctrl_ddrio_1 = 0x04A52000,
.ctrl_ddrio_2 = 0x8421,
-   .ctrl_emif_sdram_config_ext = 0x0001C127,
-   .ctrl_emif_sdram_config_ext_final = 0x0001C127,
+   .ctrl_emif_sdram_config_ext = 0x0001C1A7,
+   .ctrl_emif_sdram_config_ext_final = 0x0001C1A7,
.ctrl_ddr_ctrl_ext_0 = 0xA200,
 };
 
@@ -614,8 +614,8 @@ const struct ctrl_ioregs ioregs_dra72x_es1 = {
.ctrl_ddrio_0 = 0x00094A40,
.ctrl_ddrio_1 = 0x04A52000,
.ctrl_ddrio_2 = 0x8421,
-   .ctrl_emif_sdram_config_ext = 0x0001C127,
-   .ctrl_emif_sdram_config_ext_final = 0x0001C127,
+   .ctrl_emif_sdram_config_ext = 0x0001C1A7,
+   .ctrl_emif_sdram_config_ext_final = 0x0001C1A7,
.ctrl_ddr_ctrl_ext_0 = 0xA200,
 };
 
-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 1/2] ti: armv7: enable EXT support in SPL (using ti_armv7_common.h)

[Guillaume GARDET]

Tested on Pandaboard (rev. A3) and Beagleboard xM (rev. B).
Compilation tested on TI armv7 boards and OMAP boards from other vendors.

Signed-off-by: Guillaume GARDET 
Cc: Tom Rini 

---
 include/configs/ti_armv7_common.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/configs/ti_armv7_common.h 
b/include/configs/ti_armv7_common.h
index 2bd1164..8762930 100644
--- a/include/configs/ti_armv7_common.h
+++ b/include/configs/ti_armv7_common.h
@@ -256,6 +256,11 @@
 #define CONFIG_SPL_LIBDISK_SUPPORT
 #define CONFIG_SPL_MMC_SUPPORT
 #define CONFIG_SPL_FAT_SUPPORT
+#define CONFIG_SPL_EXT_SUPPORT
+#endif
+
+#ifdef CONFIG_SPL_BUILD
+#define CONFIG_SYS_THUMB_BUILD /* Thumbs mode to save space in SPL */
 #endif
 
 /* General parts of the framework, required. */
-- 
1.8.4.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 2/2] ti: omap4: remove CONFIG_SPL_EXT_SUPPORT from ti_omap4_common.h since it is now in ti_armv7_common.h

[Guillaume GARDET]

Signed-off-by: Guillaume GARDET 
Cc: Tom Rini 

---
 include/configs/ti_omap4_common.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/include/configs/ti_omap4_common.h 
b/include/configs/ti_omap4_common.h
index 1c93aab..b0f199e 100644
--- a/include/configs/ti_omap4_common.h
+++ b/include/configs/ti_omap4_common.h
@@ -167,9 +167,6 @@
 #define CONFIG_SYS_SPL_ARGS_ADDR   (CONFIG_SYS_SDRAM_BASE + \
 (128 << 20))
 
-/* SPL: Allow to use an EXT partition */
-#define CONFIG_SPL_EXT_SUPPORT
-
 #ifdef CONFIG_NAND
 #define CONFIG_SPL_NAND_AM33XX_BCH /* ELM support */
 #endif
-- 
1.8.4.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 0/2] Enable EXT support in SPL for all TI armv7 boards

[Guillaume GARDET]

First patch enables EXT support in SPL for all boards including 
'ti_armv7_common.h' file, mostly TI armv7 boards and some OMAP boards from 
other vendors.
To reduce size of MLO/SPL, in order to fit in SRAM (especially on OMAP3 
boards), thumb build is used to build MLO/SPL.
Second patch remove CONFIG_SPL_EXT_SUPPORT from ti_omap4_common.h since it is 
now in ti_armv7_common.h.

Tested on Pandaboard (rev. A3) and Beagleboard xM (rev. B).
Compilation tested on TI armv7 boards and OMAP boards from other vendors.

Signed-off-by: Guillaume GARDET 
Cc: Tom Rini 


---

Guillaume GARDET (2):
  ti: armv7: enable EXT support in SPL
  ti: omap4: remove CONFIG_SPL_EXT_SUPPORT from ti_omap4_common.h since
it is now in ti_armv7_common.h

 include/configs/ti_armv7_common.h | 5 +
 include/configs/ti_omap4_common.h | 3 ---
 2 files changed, 5 insertions(+), 3 deletions(-)

-- 
1.8.4.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2] arm, am33xx: update for siemens am335x based boards

[Heiko Schocher]

updates for the siemens am335x based boards:

- draco: add delay for DDR3 configuration
- change MTD partition layout and add a possibility
  to redefine MTD layout in board header.
- move ubi support to common header file
- draco: improve dtb naming
- draco: set CONFIG_SYS_CBSIZE to 1024
- add generic env based led
  Leds can now be defined in Environment
- add generic env based dfu button
  Which gpio is used for the dfu button can be defined
  through the Environment
- set MACH_TYPE only if defined
- draco: increase CPU freq to 300MHz
- Add time command to siemens am33xx boards
- DDR3: increase default tRFC
- draco: enable pullup for DFU and ERST pin
- change print format DDR3

Signed-off-by: Samuel Egli 
Acked-by: Heiko Schocher 
Reviewed-by: Tom Rini 

Signed-off-by: Heiko Schocher 
---

Changes in v2:
- add Reviewed-by from Tom Rini
- add comment from Samuel Egli:
  increase delay in DDR3 init

 board/siemens/common/board.c   | 176 +++--
 board/siemens/draco/board.c|  43 +++--
 board/siemens/draco/board.h|  13 +-
 board/siemens/draco/mux.c  |   4 +-
 include/configs/draco.h|  28 +++-
 include/configs/dxr2.h |  23 ++-
 include/configs/pxm2.h |  23 ++-
 include/configs/rut.h  |  16 +-
 include/configs/siemens-am33x-common.h | 280 +++--
 9 files changed, 428 insertions(+), 178 deletions(-)

diff --git a/board/siemens/common/board.c b/board/siemens/common/board.c
index fb2de48..c127f6c 100644
--- a/board/siemens/common/board.c
+++ b/board/siemens/common/board.c
@@ -75,8 +75,9 @@ int board_init(void)
i2c_set_bus_num(0);
if (read_eeprom() < 0)
puts("Could not get board ID.\n");
-
+#ifdef CONFIG_MACH_TYPE
gd->bd->bi_arch_number = CONFIG_MACH_TYPE;
+#endif
gd->bd->bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100;
 
 #ifdef CONFIG_FACTORYSET
@@ -102,21 +103,29 @@ const struct dpll_params *get_dpll_ddr_params(void)
 }
 
 #ifndef CONFIG_SPL_BUILD
+
+#define MAX_NR_LEDS10
+#define MAX_PIN_NUMBER 128
+#define STARTUP0
+
 #if defined(BOARD_DFU_BUTTON_GPIO)
-/*
- * This command returns the status of the user button on
- * Input - none
- * Returns -   1 if button is held down
- * 0 if button is not held down
- */
-static int
-do_userbutton(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+unsigned char get_button_state(char * const envname, unsigned char def)
 {
int button = 0;
int gpio;
+   char *ptr_env;
 
-   gpio = BOARD_DFU_BUTTON_GPIO;
-   gpio_request(gpio, "DFU");
+   /* If button is not found we take default */
+   ptr_env = getenv(envname);
+   if (NULL == ptr_env) {
+   gpio = def;
+   } else {
+   gpio = (unsigned char)simple_strtoul(ptr_env, NULL, 0);
+   if (gpio > MAX_PIN_NUMBER)
+   gpio = def;
+   }
+
+   gpio_request(gpio, "");
gpio_direction_input(gpio);
if (gpio_get_value(gpio))
button = 1;
@@ -127,53 +136,27 @@ do_userbutton(cmd_tbl_t *cmdtp, int flag, int argc, char 
* const argv[])
 
return button;
 }
-
-U_BOOT_CMD(
-   dfubutton, CONFIG_SYS_MAXARGS, 1, do_userbutton,
-   "Return the status of the DFU button",
-   ""
-);
-#endif
-/*
- * This command sets led
- * Input - name of led
- * value of led
- * Returns -   1 if input does not match
- * 0 if led was set
+/**
+ * This command returns the status of the user button on
+ * Input - none
+ * Returns -   1 if button is held down
+ * 0 if button is not held down
  */
 static int
-do_setled(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+do_userbutton(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
 {
-   int gpio = 0;
-   if (argc != 3)
-   goto exit;
-#if defined(BOARD_STATUS_LED)
-   if (!strcmp(argv[1], "stat"))
-   gpio = BOARD_STATUS_LED;
-#endif
-#if defined(BOARD_DFU_BUTTON_LED)
-   if (!strcmp(argv[1], "dfu"))
-   gpio = BOARD_DFU_BUTTON_LED;
-#endif
-   /* If argument does not mach exit */
-   if (gpio == 0)
-   goto exit;
-   gpio_request(gpio, "");
-   gpio_direction_output(gpio, 1);
-   if (!strcmp(argv[2], "1"))
-   gpio_set_value(gpio, 1);
-   else
-   gpio_set_value(gpio, 0);
-   return 0;
-exit:
-   return 1;
+   int button = 0;
+   button = get_button_state("button_dfu0", BOARD_DFU_BUTTON_GPIO);
+   button |= get_button_state("button_dfu1", BOARD_DFU_BUTTON_GPIO);
+   return button;
 }
 
 U_BOOT_CMD(
-   led, CONFIG_SYS_MAXARGS, 2, do_setled,
-   "Set led on or off",
-   "dfu val - set dfu led\nled stat val - set status led"
+   dfubutton, CONFIG_SYS_MAXARGS, 1, do_userbutton,
+   "Return the status of the DFU button",
+   "

Re: [U-Boot] [PATCH] arm, am33xx: update for siemens am335x based boards

[Heiko Schocher denx]

Hello Samuel,

Am 16.06.2015 um 14:08 schrieb Egli, Samuel:

Hi Heiko,

I noticed a little discrepancy concerning delay for DDR3. During
last rebase to v2015.04 I observed that delay needs to be
increased to boot successfully. Somehow some timing behavior
changed since v2014.04.

I set it to udelay(2000) and it works fine again. Please
update your patch.


Ups... Ok, I send an updated v2 patch.
Thanks!

bye,
Heiko


Sam



-Original Message-
From: Heiko Schocher [mailto:h...@denx.de]
Sent: Montag, 15. Juni 2015 14:55
To: u-boot@lists.denx.de
Cc: Heiko Schocher; Egli, Samuel; Tom Rini
Subject: [PATCH] arm, am33xx: update for siemens am335x based boards
[...]
@@ -193,6 +196,11 @@ struct ctrl_ioregs draco_ddr3_ioregs = {

config_ddr(DDR_PLL_FREQ, &draco_ddr3_ioregs, &draco_ddr3_data,
   &draco_ddr3_cmd_ctrl_data, &draco_ddr3_emif_reg_data, 0);
+
+   /* For Samsung 2Gbit RAM we need this delay otherwise config fails
after
+* soft reset.
+*/
+   udelay(1000);
}
[...]




--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm, am33xx: update for siemens am335x based boards

[Egli, Samuel]

Hi Heiko,

I noticed a little discrepancy concerning delay for DDR3. During 
last rebase to v2015.04 I observed that delay needs to be 
increased to boot successfully. Somehow some timing behavior 
changed since v2014.04.

I set it to udelay(2000) and it works fine again. Please
update your patch. 

Sam


>-Original Message-
>From: Heiko Schocher [mailto:h...@denx.de]
>Sent: Montag, 15. Juni 2015 14:55
>To: u-boot@lists.denx.de
>Cc: Heiko Schocher; Egli, Samuel; Tom Rini
>Subject: [PATCH] arm, am33xx: update for siemens am335x based boards
>[...]
>@@ -193,6 +196,11 @@ struct ctrl_ioregs draco_ddr3_ioregs = {
>
>   config_ddr(DDR_PLL_FREQ, &draco_ddr3_ioregs, &draco_ddr3_data,
>  &draco_ddr3_cmd_ctrl_data, &draco_ddr3_emif_reg_data, 0);
>+
>+  /* For Samsung 2Gbit RAM we need this delay otherwise config fails
>after
>+   * soft reset.
>+   */
>+  udelay(1000);
> }
>[...]
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] imx: imximage: add new CHECK/CLR BIT command

[Stefano Babic]

Hi Peng,

On 16/06/2015 03:48, Peng Fan wrote:

>>> What about just using SPL mechanism instead?
>>
> Hi Fabio,
> I agree that SPL can give many benifits, but we default not support it.
> CHECK_BITS_SET/CLR is supported by i.MX6, but current no user use this 
> feature.
> This patch is actually for i.MX7 which needs these command. Since this feature
> is also supported by i.MX6, I make it a single patch, but not with i.MX7 patch
> set.
> As Otavio said, we should make it complete, since not everyone use SPL.

The point is not to block this feature, but, as you are starting with a
new SOC (i.MX7), to think about how to better support this new
processor. We get a while to have SPL support for i.MX6, and the same
benefits we can have from the beginning with i.MX7.

>>
>> Thanks, Fabio. I can only join to your proposal.
> Hi Stefano,
> I hope you can review this patch.

Of course, this will be done - anyway, what I and Fabio try to point out
is to give i.MX7 a chance to be supported as well as i.MX6 is.

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot PATCH v2 13/17] dts: zynq: Enable spi1 for zc770_xm010 board

[Jagan Teki]

Hi Michal,

On 10 May 2015 at 20:45, Jagan Teki  wrote:
> This patch enables spi1 for zynq zc770_xm010 board dts.
>
> Signed-off-by: Jagan Teki 
> Acked-by: Simon Glass 
> Cc: Michal Simek 
> Cc: Siva Durga Prasad Paladugu 
> ---
>  arch/arm/dts/zynq-zc770-xm010.dts | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/dts/zynq-zc770-xm010.dts 
> b/arch/arm/dts/zynq-zc770-xm010.dts
> index 5e66174..e793a61 100644
> --- a/arch/arm/dts/zynq-zc770-xm010.dts
> +++ b/arch/arm/dts/zynq-zc770-xm010.dts
> @@ -21,3 +21,7 @@
> reg = <0 0x4000>;
> };
>  };
> +
> +&spi1 {
> +   status = "okay";
> +};

Did you find this, its not working with this type enabling in board
dts instead it works only with
aliases {
serial0 = &uart1;
spi1 = "/spi@e0007000";
};

thanks!
-- 
Jagan | openedev.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] spi: fsl_espi.c: fix checkpatch.pl erorrs/warnings

[Jagan Teki]

On 14 June 2015 at 23:03, Chakra Divi  wrote:
> This patch clears the errors found by running checkpatch.pl on file 
> drivers/spi/fsl_espi.c
>
> Signed-off-by: Chakra Divi 
> ---
>  drivers/spi/fsl_espi.c |   14 --
>  1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/spi/fsl_espi.c b/drivers/spi/fsl_espi.c
> index 375dc07..9d9a6e0 100644
> --- a/drivers/spi/fsl_espi.c
> +++ b/drivers/spi/fsl_espi.c
> @@ -92,11 +92,12 @@ struct spi_slave *spi_setup_slave(unsigned int bus, 
> unsigned int cs,
> pm = spibrg / (max_hz * 16 * 2);
> if (pm > 16) {
> pm = 16;
> -   debug("Requested speed is too low: %d Hz, %ld Hz "
> -   "is used.\n", max_hz, spibrg / (32 * 16));
> +   debug("Requested speed is too low: %d Hz, %ld Hz
> +   is used.\n", max_hz, spibrg / (32 * 16));

This is wrong, fires compilation error - check it

> }
> -   } else
> +   } else {
> pm = spibrg / (max_hz * 2);
> +   }
> if (pm)
> pm--;
> fsl->pm = pm;
> @@ -121,7 +122,7 @@ void spi_free_slave(struct spi_slave *slave)
>
>  void spi_init(void)
>  {
> -
> +   ; /* Do nothing */

Adding comment is enough - ; may not require.

>  }
>
>  int spi_claim_bus(struct spi_slave *slave)
> @@ -177,7 +178,7 @@ int spi_claim_bus(struct spi_slave *slave)
>
>  void spi_release_bus(struct spi_slave *slave)
>  {
> -
> +   ; /* Do nothing */

ditto.

>  }
>
>  static void fsl_espi_tx(struct fsl_spi_slave *fsl, const void *dout)
> @@ -264,7 +265,8 @@ int spi_xfer(struct spi_slave *slave, unsigned int 
> bitlen, const void *data_out,
> max_tran_len = fsl->max_transfer_length;
> switch (flags) {
> case SPI_XFER_BEGIN:
> -   cmd_len = fsl->cmd_len = data_len;
> +   fsl->cmd_len = data_len;
> +   cmd_len = fsl->cmd_len;
> memcpy(cmd_buf, data_out, cmd_len);
> return 0;
> case 0:
> --
> 1.7.9.5
>

thanks!
-- 
Jagan | openedev.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/3] stv0991: enable cadence qspi controller & spi flash

[Jagan Teki]

On 16 June 2015 at 02:24, Vikas MANOCHA  wrote:
> Hi Tom,
>
> Can you please apply the stv0991 patchset.

As these were new feature additions I will take these into spi-next.

>
>> -Original Message-
>> From: Vikas MANOCHA
>> Sent: Wednesday, May 27, 2015 6:43 PM
>> To: u-boot@lists.denx.de
>> Cc: Vikas MANOCHA
>> Subject: [PATCH 0/3] stv0991: enable cadence qspi controller & spi flash
>>
>> This patchset enables cadence qspi controller for stv0991 soc.
>>
>> Vikas Manocha (3):
>>   stv0991: configure clock & pad muxing for qspi
>>   stv0991: enable cadence qspi controller & spi flash
>>   stv0991: configure device tree for cadence qspi & flash
>>
>>  arch/arm/cpu/armv7/stv0991/clock.c |4 ++-
>>  arch/arm/cpu/armv7/stv0991/pinmux.c|5 +++
>>  arch/arm/dts/stv0991.dts   |   34 
>> 
>>  arch/arm/include/asm/arch-stv0991/stv0991_cgu.h|   15 +
>>  arch/arm/include/asm/arch-stv0991/stv0991_creg.h   |9 ++
>>  arch/arm/include/asm/arch-stv0991/stv0991_periph.h |2 ++
>>  board/st/stv0991/stv0991.c |8 +
>>  include/configs/stv0991.h  |   18 +++
>>  8 files changed, 94 insertions(+), 1 deletion(-)
>>
>> --

thanks!
-- 
Jagan | openedev.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/3] stv0991: spi env & configs related board changes

[Jagan Teki]

As these were new feature additions I will take these into spi-next.

On 16 June 2015 at 02:23, Vikas MANOCHA  wrote:
> Hi Tom,
>
> Can you please apply these patchset for stv0991.
>
> Rgds,
> Vikas
>
>> -Original Message-
>> From: Vikas MANOCHA
>> Sent: Monday, June 08, 2015 5:47 PM
>> To: u-boot@lists.denx.de
>> Cc: Vikas MANOCHA
>> Subject: [PATCH 0/3] stv0991: spi env & configs related board changes
>>
>> This patchset does changes in stv0991 board file to enable saving
>> environments in spi flash & moves CONFIG_OF in the defconfig file.
>>
>> Vikas Manocha (3):
>>   stv0991: enable saving enrironment in spi flash
>>   stv0991: move OF_CONTROL config to defconfig
>>   stv0991: remove define CONFIG_OF_SEPARATE from board file
>>
>>  configs/stv0991_defconfig |1 +
>>  include/configs/stv0991.h |7 +++
>>  2 files changed, 4 insertions(+), 4 deletions(-)
>>
>> --
>> 1.7.9.5

thanks!
--
Jagan | openedev.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] am43xx_evm: add usb host boot support

[Mugunthan V N]

On Thursday 11 June 2015 12:26 AM, Tom Rini wrote:
> On Wed, Jun 10, 2015 at 03:04:16PM +0530, Mugunthan V N wrote:
> 
>> While booting via usb host mode, ROM uses DMA to copy MLO over USB so
>> ARM internal RAM cannot be used. Adding USB host boot support by
>> introducing new config target which sets SPL_TEXT_BASE to OCMC ram.
>>
>> Signed-off-by: Mugunthan V N 
>> ---
>>  configs/am43xx_evm_usbhost_boot_defconfig | 5 +
>>  include/configs/am43xx_evm.h  | 9 +
>>  2 files changed, 14 insertions(+)
>>  create mode 100644 configs/am43xx_evm_usbhost_boot_defconfig
>>
>> diff --git a/configs/am43xx_evm_usbhost_boot_defconfig 
>> b/configs/am43xx_evm_usbhost_boot_defconfig
>> new file mode 100644
>> index 000..9455707
>> --- /dev/null
>> +++ b/configs/am43xx_evm_usbhost_boot_defconfig
>> @@ -0,0 +1,5 @@
>> +CONFIG_ARM=y
>> +CONFIG_TARGET_AM43XX_EVM=y
>> +CONFIG_SPL=y
>> +CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,NAND,USBHOST_BOOT"
>> +CONFIG_CMD_NET=y
> 
> We need to be adding USBHOST_BOOT in Kconfig and that's a bit too
> generic of a name.  It should perhaps be removed all together and only
> set CONFIG_SPL_USB_HOST_SUPPORT for this build and not include it in the
> rest.
> 

Will fix this in v2

Regards
Mugunthan V N
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] EXYNOS: fix regression for Origen4210

[Thomas Abraham]

The do_lowlevel_init() function includes certian CA15 specific L2 cache
configuration which is only applicable on Exynos5420 and members of its
family. Fix the regression on Origen4210 by skipping the Exynos5420
specific portions of the code.

Cc: Minkyu Kang 
Signed-off-by: Thomas Abraham 
---
 arch/arm/cpu/armv7/exynos/common_setup.h  |2 +-
 arch/arm/cpu/armv7/exynos/lowlevel_init.c |4 +---
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/arm/cpu/armv7/exynos/common_setup.h 
b/arch/arm/cpu/armv7/exynos/common_setup.h
index 5235abb..67aac2d 100644
--- a/arch/arm/cpu/armv7/exynos/common_setup.h
+++ b/arch/arm/cpu/armv7/exynos/common_setup.h
@@ -60,7 +60,7 @@ enum l2_cache_params {
 };
 
 
-#ifndef CONFIG_SYS_L2CACHE_OFF
+#if !defined(CONFIG_SYS_L2CACHE_OFF) && defined(CONFIG_EXYNOS5420)
 /*
  * Configure L2CTLR to get timings that keep us from hanging/crashing.
  *
diff --git a/arch/arm/cpu/armv7/exynos/lowlevel_init.c 
b/arch/arm/cpu/armv7/exynos/lowlevel_init.c
index 120aaf8..1c125f6 100644
--- a/arch/arm/cpu/armv7/exynos/lowlevel_init.c
+++ b/arch/arm/cpu/armv7/exynos/lowlevel_init.c
@@ -174,7 +174,7 @@ int do_lowlevel_init(void)
 
arch_cpu_init();
 
-#ifndef CONFIG_SYS_L2CACHE_OFF
+#if !defined(CONFIG_SYS_L2CACHE_OFF) && defined(CONFIG_EXYNOS5420)
/*
 * Init L2 cache parameters here for use by boot and resume
 *
@@ -187,9 +187,7 @@ int do_lowlevel_init(void)
configure_l2_actlr();
dsb();
isb();
-#endif
 
-#ifdef CONFIG_EXYNOS5420
relocate_wait_code();
 
/* Reconfigure secondary cores */
-- 
1.6.6.rc2

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Very slow fatload on bcm2835

[Michal Marek]

On 2015-06-16 06:01, Stephen Warren wrote:
> On 06/11/2015 12:35 PM, Jakub Kicinski wrote:
>> Hello!
>>
>> I'm using latest git source of U-Boot on Raspberry Pi Compute Module 
>> and performance of fatload is quite bad.  Does anyone have any clue
>> about what can be wrong?  Is it the lack of cache?
>>
>> Sample boot log:
> ...
>> reading zImage
>> 4003816 bytes read in 48930 ms (79.1 KiB/s)
> 
> I see this too. I bisected it to:
> 33fe2fb8df01 ARM: mmc: bcm283x: Remove get_timer_us() from mmc driver
> 
> Marek, this is the second symptom I bisected to this patch. Something
> seems quite wrong with it. Did changing to the other timer function
> change the timer tick rate or something? FWIW, "sleep 10" at the shell
> prompt appears to run for the correct amount of time, so I guess it's
> not that.

I think you meant Marek Vašut. I'm Marek by last name :).

Michal

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v6 1/4] mtd, spi: add MTD layer driver

[Daniel Schwierzeck]

2015-06-16 11:36 GMT+02:00 Jagan Teki :
> On 16 June 2015 at 14:48, Heiko Schocher denx  wrote:
>> Hello Jagan,
>>
>>
>> Am 16.06.2015 um 10:52 schrieb Jagan Teki:
>>>
>>> Hi Heiko,
>>>
>>> On 16 June 2015 at 14:13, Heiko Schocher denx  wrote:

 Hello Jagan,


 Am 16.06.2015 um 10:04 schrieb Jagan Teki:
>
>
> Hi Heiko,
>
> On 20 May 2015 at 12:16, Heiko Schocher  wrote:
>>
>>
>> Hello Jagan,
>>
>> Am 19.05.2015 22:09, schrieb Jagan Teki:
>>>
>>>
>>>
>>> Hi Heiko,
>>>
>>> I have tested this sf-mtd stuff, please see below and enabled prints
>>> in all the func calls.
>>
>>
>>
>>
>> Thanks for testing!
>>
>>
>>> zynq-uboot> mtdparts add nor0 0x1@0x0 env
>>> mtdparts variable not set, see 'help mtdparts'
>>> zynq-uboot> mtdparts
>>>
>>> device nor0 , # parts = 1
>>> #: namesizeoffset  mask_flags
>>> 0: env 0x0001  0x  0
>>>
>>> active partition: nor0,0 - (env) 0x0001 @ 0x
>>>
>>> defaults:
>>> mtdids  : nor0=zynq-sf.0
>>> mtdparts: none
>>> zynq-uboot> sf erase env 0x1
>>> spi_flash_erase
>>> spi_flash_cmd_erase_ops
>>> SF: erase d8  0  0  0 (0)
>>> SF: 65536 bytes @ 0x0 Erased: OK
>>> zynq-uboot> mw.b 0x100 0x44 0x1
>>> zynq-uboot> sf write 0x100 env
>>> device 0 offset 0x0, size 0x1
>>> spi_flash_cmd_write_ops
>>> SF: 65536 bytes @ 0x0 Written: OK
>>> zynq-uboot> sf read 0x4 env
>>> device 0 offset 0x0, size 0x1
>>> spi_flash_cmd_read_ops
>>> off = 0x1, len = 0
>>> SF: 65536 bytes @ 0x0 Read: OK
>>> zynq-uboot> cmp.b 0x100 0x4 0x1
>>> Total of 65536 byte(s) were the same
>>
>>
>>
>>
>> Looks good ...
>>
>>> I wonder none of the sf_mtd_info._* getting called, why?
>>
>>
>>
>>
>> Hmm.. good question .. you use the "sf ..." commands, they do not
>> use the mtd interface, right?
>
>
>
> I'm fine with the testing, but mtd code in sf seems used only for in UBI
> only.



 a fast "grep mtd_read" in the u-boot source shows, that yaffs2
 also uses mtd_read ... I did no yaffs2 test, but I think, yaffs2 can
 be used also with spi flashes now ... if this is wise, I don;t know ...

 I tested with UBI on a spi flash, and that works ... in the same
 fashion it currently does on nand for example ...

> I wouldn't see this is a better approach where mtd code is considered as
> to
> be unknown thing for sf.



 I do not understand you here complete ...

 drivers/mtd/spi/sf_mtd.c

 adds just spi flash specific functions to integrate spi flashes
 into mtd ... and mtd users can then read/write/erase
 with the mtd_* functions ...

 Maybe someone has time to convert common/sf.c to use them?

 So, the final question is, can this patches go into mainline?
>>>
>>>
>>> The only point I'm concerned here is If I need to use sf with mtd support
>>> without using ubifs or any flash filesystem, the code in sf_mtd.c ops
>>> becomes
>>> unused.
>>
>>
>> Why you want to enable mtd support for sf, if you not use it?
>> do not define CONFIG_SPI_FLASH_MTD in this case?
>
> Suppose I need sf-mtd and enabled CONFIG_SPI_FLASH_MTD so
> when I did it from sf_cmd the code in sf-mtd.c is never been used for
> erase/read/write. Is that true right?

you obviously do not understand the intention of sf_mtd. It is only an
adapter for translating mtd_read/mtd_write commands into
spi_flash_read/spi_flash_write commands. It is not intended to use it
within sf_cmd or the SPI flash subsystem. Such an adapter is needed
for subsystems like UBI which can only operate on top of the MTD
layer. Thus if you want to use UBI on SPI flash, you will need sf_mtd.
And using UBI on SPI flash is a legitimate use-case for many users.

BTW: this is the same approach as for CFI NOR flash. The CFI driver
regularly works without MTD support, but you can enable the optional
cfi_mtd driver if you need it.

>
>>
>>> This seems to be a code size increasing factor which is obviously not a
>>> good
>>> point for bootloader atleast for u-boot, what do you think?
>>>
>>> I agreed your concerned for someone may add support to common/cmd_sf.c
>>> in future, but I'm bit worried to go this.
>>
>>
>> Why? Its the same state as it is in the nand subsystem ...
>
> Agreed but until unless if you have filesystem link to cmd_sf to partitioning.

Again sf_mtd is an optional driver for users who need MTD support on
SPI flash. All others do not need to enable sf_mtd. Thus there is no
increasing of code size.

-- 
- Daniel
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] mmc_write.c: Make mmc_berase do 32bit safe 64bit math

[Hans de Goede]

Hi,

On 12-06-15 02:53, Tom Rini wrote:

We want to see if the requested start or total block count are
unaligned.  We discard the whole numbers and only care about the
remainder.  Update the code to use div_u64_rem here and add a comment.

Cc: Hans de Goede 
Cc: Pantelis Antoniou 
Cc: Bernhard Nortmann 
Reported-by: Simon Glass 
Signed-off-by: Tom Rini 
Tested-by: Bernhard Nortmann 


Thanks for this, looks good to me:

Reviewed-by: Hans de Goede 

Regards,

Hans


---
  drivers/mmc/mmc_write.c |   12 +++-
  1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/mmc_write.c b/drivers/mmc/mmc_write.c
index 3db9669..7aea7e9 100644
--- a/drivers/mmc/mmc_write.c
+++ b/drivers/mmc/mmc_write.c
@@ -10,6 +10,8 @@
  #include 
  #include 
  #include 
+#include 
+#include 
  #include "mmc_private.h"

  static ulong mmc_erase_t(struct mmc *mmc, ulong start, lbaint_t blkcnt)
@@ -66,6 +68,7 @@ err_out:
  unsigned long mmc_berase(int dev_num, lbaint_t start, lbaint_t blkcnt)
  {
int err = 0;
+   u32 start_rem, blkcnt_rem;
struct mmc *mmc = find_mmc_device(dev_num);
lbaint_t blk = 0, blk_r = 0;
int timeout = 1000;
@@ -73,7 +76,14 @@ unsigned long mmc_berase(int dev_num, lbaint_t start, 
lbaint_t blkcnt)
if (!mmc)
return -1;

-   if ((start % mmc->erase_grp_size) || (blkcnt % mmc->erase_grp_size))
+   /*
+* We want to see if the requested start or total block count are
+* unaligned.  We discard the whole numbers and only care about the
+* remainder.
+*/
+   err = div_u64_rem(start, mmc->erase_grp_size, &start_rem);
+   err = div_u64_rem(blkcnt, mmc->erase_grp_size, &blkcnt_rem);
+   if (start_rem || blkcnt_rem)
printf("\n\nCaution! Your devices Erase group is 0x%x\n"
   "The erase range would be change to "
   "0x" LBAF "~0x" LBAF "\n\n",


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] mx53loco: Use generic 'load' command instead of 'fatload'

[Guillaume GARDET]

This patch uses generic 'load' command instead of 'fatload' for 
'loadbootscript', 'loadimage' and 'loadfdt' for mx53loco board.

This allows to use EXT partition instead of FAT, while keeping FAT 
compatibility.

Signed-off-by: Guillaume GARDET 

Cc: Jason Liu 
Cc: Stefano Babic 

---
 include/configs/mx53loco.h | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/include/configs/mx53loco.h b/include/configs/mx53loco.h
index db551a9..b3ac5e2 100644
--- a/include/configs/mx53loco.h
+++ b/include/configs/mx53loco.h
@@ -43,6 +43,7 @@
 #define CONFIG_MMC
 #define CONFIG_CMD_MMC
 #define CONFIG_GENERIC_MMC
+#define CONFIG_CMD_FS_GENERIC
 #define CONFIG_CMD_FAT
 #define CONFIG_CMD_EXT2
 #define CONFIG_DOS_PARTITION
@@ -116,11 +117,11 @@
"mmcroot=/dev/mmcblk0p2 rw rootwait\0" \
"mmcargs=setenv bootargs console=ttymxc0,${baudrate} root=${mmcroot}\0" 
\
"loadbootscript=" \
-   "fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
+   "load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
"bootscript=echo Running bootscript from mmc ...; " \
"source\0" \
-   "loadimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${image}\0" \
-   "loadfdt=fatload mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0" \
+   "loadimage=load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${image}\0" \
+   "loadfdt=load mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0" \
"mmcboot=echo Booting from mmc ...; " \
"run mmcargs; " \
"if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \
-- 
1.8.4.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v6 1/4] mtd, spi: add MTD layer driver

[Jagan Teki]

On 16 June 2015 at 14:48, Heiko Schocher denx  wrote:
> Hello Jagan,
>
>
> Am 16.06.2015 um 10:52 schrieb Jagan Teki:
>>
>> Hi Heiko,
>>
>> On 16 June 2015 at 14:13, Heiko Schocher denx  wrote:
>>>
>>> Hello Jagan,
>>>
>>>
>>> Am 16.06.2015 um 10:04 schrieb Jagan Teki:


 Hi Heiko,

 On 20 May 2015 at 12:16, Heiko Schocher  wrote:
>
>
> Hello Jagan,
>
> Am 19.05.2015 22:09, schrieb Jagan Teki:
>>
>>
>>
>> Hi Heiko,
>>
>> I have tested this sf-mtd stuff, please see below and enabled prints
>> in all the func calls.
>
>
>
>
> Thanks for testing!
>
>
>> zynq-uboot> mtdparts add nor0 0x1@0x0 env
>> mtdparts variable not set, see 'help mtdparts'
>> zynq-uboot> mtdparts
>>
>> device nor0 , # parts = 1
>> #: namesizeoffset  mask_flags
>> 0: env 0x0001  0x  0
>>
>> active partition: nor0,0 - (env) 0x0001 @ 0x
>>
>> defaults:
>> mtdids  : nor0=zynq-sf.0
>> mtdparts: none
>> zynq-uboot> sf erase env 0x1
>> spi_flash_erase
>> spi_flash_cmd_erase_ops
>> SF: erase d8  0  0  0 (0)
>> SF: 65536 bytes @ 0x0 Erased: OK
>> zynq-uboot> mw.b 0x100 0x44 0x1
>> zynq-uboot> sf write 0x100 env
>> device 0 offset 0x0, size 0x1
>> spi_flash_cmd_write_ops
>> SF: 65536 bytes @ 0x0 Written: OK
>> zynq-uboot> sf read 0x4 env
>> device 0 offset 0x0, size 0x1
>> spi_flash_cmd_read_ops
>> off = 0x1, len = 0
>> SF: 65536 bytes @ 0x0 Read: OK
>> zynq-uboot> cmp.b 0x100 0x4 0x1
>> Total of 65536 byte(s) were the same
>
>
>
>
> Looks good ...
>
>> I wonder none of the sf_mtd_info._* getting called, why?
>
>
>
>
> Hmm.. good question .. you use the "sf ..." commands, they do not
> use the mtd interface, right?



 I'm fine with the testing, but mtd code in sf seems used only for in UBI
 only.
>>>
>>>
>>>
>>> a fast "grep mtd_read" in the u-boot source shows, that yaffs2
>>> also uses mtd_read ... I did no yaffs2 test, but I think, yaffs2 can
>>> be used also with spi flashes now ... if this is wise, I don;t know ...
>>>
>>> I tested with UBI on a spi flash, and that works ... in the same
>>> fashion it currently does on nand for example ...
>>>
 I wouldn't see this is a better approach where mtd code is considered as
 to
 be unknown thing for sf.
>>>
>>>
>>>
>>> I do not understand you here complete ...
>>>
>>> drivers/mtd/spi/sf_mtd.c
>>>
>>> adds just spi flash specific functions to integrate spi flashes
>>> into mtd ... and mtd users can then read/write/erase
>>> with the mtd_* functions ...
>>>
>>> Maybe someone has time to convert common/sf.c to use them?
>>>
>>> So, the final question is, can this patches go into mainline?
>>
>>
>> The only point I'm concerned here is If I need to use sf with mtd support
>> without using ubifs or any flash filesystem, the code in sf_mtd.c ops
>> becomes
>> unused.
>
>
> Why you want to enable mtd support for sf, if you not use it?
> do not define CONFIG_SPI_FLASH_MTD in this case?

Suppose I need sf-mtd and enabled CONFIG_SPI_FLASH_MTD so
when I did it from sf_cmd the code in sf-mtd.c is never been used for
erase/read/write. Is that true right?

>
>> This seems to be a code size increasing factor which is obviously not a
>> good
>> point for bootloader atleast for u-boot, what do you think?
>>
>> I agreed your concerned for someone may add support to common/cmd_sf.c
>> in future, but I'm bit worried to go this.
>
>
> Why? Its the same state as it is in the nand subsystem ...

Agreed but until unless if you have filesystem link to cmd_sf to partitioning.

>
>>
>>>
> I tested this functions with using UBI on the SPI NOR on the
> aristainetos and aristianetos2 boards... I added for example in
>
> diff --git a/drivers/mtd/spi/sf_mtd.c b/drivers/mtd/spi/sf_mtd.c
> index 0b9cb62..6063ed7 100644
> --- a/drivers/mtd/spi/sf_mtd.c
> +++ b/drivers/mtd/spi/sf_mtd.c
> @@ -39,6 +40,7 @@ static int spi_flash_mtd_read(struct mtd_info *mtd,
> loff_t
> from, size_t len,
>   struct spi_flash *flash = mtd->priv;
>   int err;
>
> +printf("%s \n", __func__);
>   err = spi_flash_read(flash, from, len, buf);
>   if (!err)
>   *retlen = len;
>
> and see:
>
> => sf probe
> SF: Detected N25Q128A with page size 256 Bytes, erase size 64 KiB,
> total
> 16
> MiB
> => mtdparts
>
> device nor0 , # parts = 4
>#: namesizeoffset  mask_flags
>0: u-boot  0x000d  0x  0
>1: env 0x0001  0x000d  0
>2: env-red 0x0001

[U-Boot] [PATCH 1/2] Drop duplicate CONFIG_SYS_NO_FLASH from mx6_common

[Peter Robinson]

It's defind earlier in the file

Signed-off-by: Peter Robinson 
---
 include/configs/mx6_common.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/include/configs/mx6_common.h b/include/configs/mx6_common.h
index 50370e1..b37477a 100644
--- a/include/configs/mx6_common.h
+++ b/include/configs/mx6_common.h
@@ -87,7 +87,6 @@
 #define CONFIG_CMD_FAT
 
 /* Miscellaneous configurable options */
-#define CONFIG_SYS_NO_FLASH
 #undef CONFIG_CMD_IMLS
 #define CONFIG_SYS_LONGHELP
 #define CONFIG_SYS_HUSH_PARSER
-- 
2.4.3

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 2/2] mx6cuboxi: drop options that are duplicated in mx6_common

[Peter Robinson]

These options were merged into mx6_common and were seemingly missed
in mx6cuboxi so drop the duplicates

Signed-off-by: Peter Robinson 
---
 include/configs/mx6cuboxi.h | 8 
 1 file changed, 8 deletions(-)

diff --git a/include/configs/mx6cuboxi.h b/include/configs/mx6cuboxi.h
index 3f99512..3d5bba7 100644
--- a/include/configs/mx6cuboxi.h
+++ b/include/configs/mx6cuboxi.h
@@ -186,14 +186,6 @@
"fi; " \
"else run netboot; fi"
 
-/* Miscellaneous configurable options */
-#define CONFIG_SYS_LONGHELP
-#define CONFIG_SYS_HUSH_PARSER
-#define CONFIG_AUTO_COMPLETE
-#define CONFIG_SYS_BARGSIZE CONFIG_SYS_CBSIZE
-
-#define CONFIG_CMDLINE_EDITING
-
 /* Physical Memory Map */
 #define CONFIG_NR_DRAM_BANKS   1
 #define CONFIG_SYS_SDRAM_BASE  MMDC0_ARB_BASE_ADDR
-- 
2.4.3

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] imx6 minor cleanups

[Peter Robinson]

Just a couple of small cleanups to remove duplicate options that are
already defined in mx6_common.h

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v6 1/4] mtd, spi: add MTD layer driver

[Heiko Schocher denx]

Hello Jagan,

Am 16.06.2015 um 10:52 schrieb Jagan Teki:

Hi Heiko,

On 16 June 2015 at 14:13, Heiko Schocher denx  wrote:

Hello Jagan,


Am 16.06.2015 um 10:04 schrieb Jagan Teki:


Hi Heiko,

On 20 May 2015 at 12:16, Heiko Schocher  wrote:


Hello Jagan,

Am 19.05.2015 22:09, schrieb Jagan Teki:



Hi Heiko,

I have tested this sf-mtd stuff, please see below and enabled prints
in all the func calls.




Thanks for testing!



zynq-uboot> mtdparts add nor0 0x1@0x0 env
mtdparts variable not set, see 'help mtdparts'
zynq-uboot> mtdparts

device nor0 , # parts = 1
#: namesizeoffset  mask_flags
0: env 0x0001  0x  0

active partition: nor0,0 - (env) 0x0001 @ 0x

defaults:
mtdids  : nor0=zynq-sf.0
mtdparts: none
zynq-uboot> sf erase env 0x1
spi_flash_erase
spi_flash_cmd_erase_ops
SF: erase d8  0  0  0 (0)
SF: 65536 bytes @ 0x0 Erased: OK
zynq-uboot> mw.b 0x100 0x44 0x1
zynq-uboot> sf write 0x100 env
device 0 offset 0x0, size 0x1
spi_flash_cmd_write_ops
SF: 65536 bytes @ 0x0 Written: OK
zynq-uboot> sf read 0x4 env
device 0 offset 0x0, size 0x1
spi_flash_cmd_read_ops
off = 0x1, len = 0
SF: 65536 bytes @ 0x0 Read: OK
zynq-uboot> cmp.b 0x100 0x4 0x1
Total of 65536 byte(s) were the same




Looks good ...


I wonder none of the sf_mtd_info._* getting called, why?




Hmm.. good question .. you use the "sf ..." commands, they do not
use the mtd interface, right?



I'm fine with the testing, but mtd code in sf seems used only for in UBI
only.



a fast "grep mtd_read" in the u-boot source shows, that yaffs2
also uses mtd_read ... I did no yaffs2 test, but I think, yaffs2 can
be used also with spi flashes now ... if this is wise, I don;t know ...

I tested with UBI on a spi flash, and that works ... in the same
fashion it currently does on nand for example ...


I wouldn't see this is a better approach where mtd code is considered as
to
be unknown thing for sf.



I do not understand you here complete ...

drivers/mtd/spi/sf_mtd.c

adds just spi flash specific functions to integrate spi flashes
into mtd ... and mtd users can then read/write/erase
with the mtd_* functions ...

Maybe someone has time to convert common/sf.c to use them?

So, the final question is, can this patches go into mainline?


The only point I'm concerned here is If I need to use sf with mtd support
without using ubifs or any flash filesystem, the code in sf_mtd.c ops becomes
unused.


Why you want to enable mtd support for sf, if you not use it?
do not define CONFIG_SPI_FLASH_MTD in this case?


This seems to be a code size increasing factor which is obviously not a good
point for bootloader atleast for u-boot, what do you think?

I agreed your concerned for someone may add support to common/cmd_sf.c
in future, but I'm bit worried to go this.


Why? Its the same state as it is in the nand subsystem ...

bye,
Heiko





I tested this functions with using UBI on the SPI NOR on the
aristainetos and aristianetos2 boards... I added for example in

diff --git a/drivers/mtd/spi/sf_mtd.c b/drivers/mtd/spi/sf_mtd.c
index 0b9cb62..6063ed7 100644
--- a/drivers/mtd/spi/sf_mtd.c
+++ b/drivers/mtd/spi/sf_mtd.c
@@ -39,6 +40,7 @@ static int spi_flash_mtd_read(struct mtd_info *mtd,
loff_t
from, size_t len,
  struct spi_flash *flash = mtd->priv;
  int err;

+printf("%s \n", __func__);
  err = spi_flash_read(flash, from, len, buf);
  if (!err)
  *retlen = len;

and see:

=> sf probe
SF: Detected N25Q128A with page size 256 Bytes, erase size 64 KiB, total
16
MiB
=> mtdparts

device nor0 , # parts = 4
   #: namesizeoffset  mask_flags
   0: u-boot  0x000d  0x  0
   1: env 0x0001  0x000d  0
   2: env-red 0x0001  0x000e  0
   3: rescue-system   0x00f1  0x000f  0

device nand0 , # parts = 1
   #: namesizeoffset  mask_flags
   0: ubi 0x4000  0x  0

active partition: nor0,0 - (u-boot) 0x000d @ 0x

defaults:
mtdids  : none
mtdparts: none
=> ubi part rescue-system
UBI: default fastmap pool size: 10
UBI: default fastmap WL pool size: 25
UBI: attaching mtd2 to ubi0
UBI DBG gen (pid 1): sizeof(struct ubi_ainf_peb) 48
UBI DBG gen (pid 1): sizeof(struct ubi_wl_entry) 20
UBI DBG gen (pid 1): min_io_size  1
UBI DBG gen (pid 1): max_write_size   256
UBI DBG gen (pid 1): hdrs_min_io_size 1
UBI DBG gen (pid 1): ec_hdr_alsize64
UBI DBG gen (pid 1): vid_hdr_alsize   64
UBI DBG gen (pid 1): vid_hdr_offset   64
UBI DBG gen (pid 1): vid_hdr_aloffset 64
UBI DBG gen (pid 1): vid_hdr_shift0
UBI DBG gen (pid 1): leb_start128
UBI DBG gen (pid 1): max_erroneous24
UBI DBG gen (pid 1): process PEB 0
UBI DBG bld (pid 1): scan PEB 0
UBI DBG io (pid 1): read EC header fr

Re: [U-Boot] [PATCH v3 4/4] arm: ls102xa: Enable Driver Model SPI for ls1021atwr

[Jagan Teki]

Pls- resend this series by adding Data Flash driver to it.

On 18 May 2015 at 18:55, Haikun Wang  wrote:
> From: Haikun Wang 
>
> Enable Driver Model SPI for ls1021atwr board.
> DSPI and QSPI only be enabled when boot from QSPI.
> DSPI and QSPI are compatible under Driver Model SPI.
>
> Signed-off-by: Haikun Wang 
> Change-Id: I6342807da7725ae8b678952117c8758c75a61d3d
> Reviewed-on: http://git.am.freescale.net:8181/33447
> Tested-by: Review Code-CDREVIEW 
> Reviewed-by: Prabhakar Kushwaha 
> ---
> Changes in v3:
> - IS_ENABLED(CONFIG_XXX) is only work with configure option in Kconfig,
>   and DM core code use IS_ENABLED(), so configure option in head file
>   can't work, so remove CONFIG_OF_CONTROL CONFIG_OF_SEPARATE CONFIG_DM 
> CONFIG_DM_SPI
>
> Changes in v2:
> - Move all changes inside of CONFIG_QSPI_BOOT
>
> Changes in v1: None
>  include/configs/ls1021atwr.h | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h
> index 729205f..13e3aa4 100644
> --- a/include/configs/ls1021atwr.h
> +++ b/include/configs/ls1021atwr.h
> @@ -229,16 +229,22 @@
>  #define CONFIG_CMD_FAT
>  #define CONFIG_DOS_PARTITION
>
> -/* QSPI */
> +/* SPI */
>  #ifdef CONFIG_QSPI_BOOT
> +/* QSPI */
>  #define CONFIG_FSL_QSPI
>  #define QSPI0_AMBA_BASE0x4000
>  #define FSL_QSPI_FLASH_SIZE(1 << 24)
>  #define FSL_QSPI_FLASH_NUM 2
>
> +#define CONFIG_SPI_FLASH_STMICRO
> +
> +/* DM SPI */
> +#if defined(CONFIG_FSL_DSPI) || defined(CONFIG_FSL_QSPI)
>  #define CONFIG_CMD_SF
> +#define CONFIG_DM_SPI_FLASH
>  #define CONFIG_SPI_FLASH
> -#define CONFIG_SPI_FLASH_STMICRO
> +#endif
>  #endif
>
>  /*
> --
> 2.1.0.27.g96db324
>



-- 
Jagan | openedev.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v6 1/4] mtd, spi: add MTD layer driver

[Jagan Teki]

Hi Heiko,

On 16 June 2015 at 14:13, Heiko Schocher denx  wrote:
> Hello Jagan,
>
>
> Am 16.06.2015 um 10:04 schrieb Jagan Teki:
>>
>> Hi Heiko,
>>
>> On 20 May 2015 at 12:16, Heiko Schocher  wrote:
>>>
>>> Hello Jagan,
>>>
>>> Am 19.05.2015 22:09, schrieb Jagan Teki:


 Hi Heiko,

 I have tested this sf-mtd stuff, please see below and enabled prints
 in all the func calls.
>>>
>>>
>>>
>>> Thanks for testing!
>>>
>>>
 zynq-uboot> mtdparts add nor0 0x1@0x0 env
 mtdparts variable not set, see 'help mtdparts'
 zynq-uboot> mtdparts

 device nor0 , # parts = 1
#: namesizeoffset  mask_flags
0: env 0x0001  0x  0

 active partition: nor0,0 - (env) 0x0001 @ 0x

 defaults:
 mtdids  : nor0=zynq-sf.0
 mtdparts: none
 zynq-uboot> sf erase env 0x1
 spi_flash_erase
 spi_flash_cmd_erase_ops
 SF: erase d8  0  0  0 (0)
 SF: 65536 bytes @ 0x0 Erased: OK
 zynq-uboot> mw.b 0x100 0x44 0x1
 zynq-uboot> sf write 0x100 env
 device 0 offset 0x0, size 0x1
 spi_flash_cmd_write_ops
 SF: 65536 bytes @ 0x0 Written: OK
 zynq-uboot> sf read 0x4 env
 device 0 offset 0x0, size 0x1
 spi_flash_cmd_read_ops
 off = 0x1, len = 0
 SF: 65536 bytes @ 0x0 Read: OK
 zynq-uboot> cmp.b 0x100 0x4 0x1
 Total of 65536 byte(s) were the same
>>>
>>>
>>>
>>> Looks good ...
>>>
 I wonder none of the sf_mtd_info._* getting called, why?
>>>
>>>
>>>
>>> Hmm.. good question .. you use the "sf ..." commands, they do not
>>> use the mtd interface, right?
>>
>>
>> I'm fine with the testing, but mtd code in sf seems used only for in UBI
>> only.
>
>
> a fast "grep mtd_read" in the u-boot source shows, that yaffs2
> also uses mtd_read ... I did no yaffs2 test, but I think, yaffs2 can
> be used also with spi flashes now ... if this is wise, I don;t know ...
>
> I tested with UBI on a spi flash, and that works ... in the same
> fashion it currently does on nand for example ...
>
>> I wouldn't see this is a better approach where mtd code is considered as
>> to
>> be unknown thing for sf.
>
>
> I do not understand you here complete ...
>
> drivers/mtd/spi/sf_mtd.c
>
> adds just spi flash specific functions to integrate spi flashes
> into mtd ... and mtd users can then read/write/erase
> with the mtd_* functions ...
>
> Maybe someone has time to convert common/sf.c to use them?
>
> So, the final question is, can this patches go into mainline?

The only point I'm concerned here is If I need to use sf with mtd support
without using ubifs or any flash filesystem, the code in sf_mtd.c ops becomes
unused.

This seems to be a code size increasing factor which is obviously not a good
point for bootloader atleast for u-boot, what do you think?

I agreed your concerned for someone may add support to common/cmd_sf.c
in future, but I'm bit worried to go this.

>
>>> I tested this functions with using UBI on the SPI NOR on the
>>> aristainetos and aristianetos2 boards... I added for example in
>>>
>>> diff --git a/drivers/mtd/spi/sf_mtd.c b/drivers/mtd/spi/sf_mtd.c
>>> index 0b9cb62..6063ed7 100644
>>> --- a/drivers/mtd/spi/sf_mtd.c
>>> +++ b/drivers/mtd/spi/sf_mtd.c
>>> @@ -39,6 +40,7 @@ static int spi_flash_mtd_read(struct mtd_info *mtd,
>>> loff_t
>>> from, size_t len,
>>>  struct spi_flash *flash = mtd->priv;
>>>  int err;
>>>
>>> +printf("%s \n", __func__);
>>>  err = spi_flash_read(flash, from, len, buf);
>>>  if (!err)
>>>  *retlen = len;
>>>
>>> and see:
>>>
>>> => sf probe
>>> SF: Detected N25Q128A with page size 256 Bytes, erase size 64 KiB, total
>>> 16
>>> MiB
>>> => mtdparts
>>>
>>> device nor0 , # parts = 4
>>>   #: namesizeoffset  mask_flags
>>>   0: u-boot  0x000d  0x  0
>>>   1: env 0x0001  0x000d  0
>>>   2: env-red 0x0001  0x000e  0
>>>   3: rescue-system   0x00f1  0x000f  0
>>>
>>> device nand0 , # parts = 1
>>>   #: namesizeoffset  mask_flags
>>>   0: ubi 0x4000  0x  0
>>>
>>> active partition: nor0,0 - (u-boot) 0x000d @ 0x
>>>
>>> defaults:
>>> mtdids  : none
>>> mtdparts: none
>>> => ubi part rescue-system
>>> UBI: default fastmap pool size: 10
>>> UBI: default fastmap WL pool size: 25
>>> UBI: attaching mtd2 to ubi0
>>> UBI DBG gen (pid 1): sizeof(struct ubi_ainf_peb) 48
>>> UBI DBG gen (pid 1): sizeof(struct ubi_wl_entry) 20
>>> UBI DBG gen (pid 1): min_io_size  1
>>> UBI DBG gen (pid 1): max_write_size   256
>>> UBI DBG gen (pid 1): hdrs_min_io_size 1
>>> UBI DBG gen (pid 1): ec_hdr_alsize64
>>> UBI DBG gen (pid 1): vid_hdr_alsize   64
>>> UBI DBG gen (pid 1): vid_hdr_offset   64
>>> UBI DBG gen (pid 1

Re: [U-Boot] [PATCH v6 1/4] mtd, spi: add MTD layer driver

[Heiko Schocher denx]

Hello Jagan,

Am 16.06.2015 um 10:04 schrieb Jagan Teki:

Hi Heiko,

On 20 May 2015 at 12:16, Heiko Schocher  wrote:

Hello Jagan,

Am 19.05.2015 22:09, schrieb Jagan Teki:


Hi Heiko,

I have tested this sf-mtd stuff, please see below and enabled prints
in all the func calls.



Thanks for testing!



zynq-uboot> mtdparts add nor0 0x1@0x0 env
mtdparts variable not set, see 'help mtdparts'
zynq-uboot> mtdparts

device nor0 , # parts = 1
   #: namesizeoffset  mask_flags
   0: env 0x0001  0x  0

active partition: nor0,0 - (env) 0x0001 @ 0x

defaults:
mtdids  : nor0=zynq-sf.0
mtdparts: none
zynq-uboot> sf erase env 0x1
spi_flash_erase
spi_flash_cmd_erase_ops
SF: erase d8  0  0  0 (0)
SF: 65536 bytes @ 0x0 Erased: OK
zynq-uboot> mw.b 0x100 0x44 0x1
zynq-uboot> sf write 0x100 env
device 0 offset 0x0, size 0x1
spi_flash_cmd_write_ops
SF: 65536 bytes @ 0x0 Written: OK
zynq-uboot> sf read 0x4 env
device 0 offset 0x0, size 0x1
spi_flash_cmd_read_ops
off = 0x1, len = 0
SF: 65536 bytes @ 0x0 Read: OK
zynq-uboot> cmp.b 0x100 0x4 0x1
Total of 65536 byte(s) were the same



Looks good ...


I wonder none of the sf_mtd_info._* getting called, why?



Hmm.. good question .. you use the "sf ..." commands, they do not
use the mtd interface, right?


I'm fine with the testing, but mtd code in sf seems used only for in UBI only.


a fast "grep mtd_read" in the u-boot source shows, that yaffs2
also uses mtd_read ... I did no yaffs2 test, but I think, yaffs2 can
be used also with spi flashes now ... if this is wise, I don;t know ...

I tested with UBI on a spi flash, and that works ... in the same
fashion it currently does on nand for example ...


I wouldn't see this is a better approach where mtd code is considered as to
be unknown thing for sf.


I do not understand you here complete ...

drivers/mtd/spi/sf_mtd.c

adds just spi flash specific functions to integrate spi flashes
into mtd ... and mtd users can then read/write/erase
with the mtd_* functions ...

Maybe someone has time to convert common/sf.c to use them?

So, the final question is, can this patches go into mainline?

thanks!

bye,
Heiko

I tested this functions with using UBI on the SPI NOR on the
aristainetos and aristianetos2 boards... I added for example in

diff --git a/drivers/mtd/spi/sf_mtd.c b/drivers/mtd/spi/sf_mtd.c
index 0b9cb62..6063ed7 100644
--- a/drivers/mtd/spi/sf_mtd.c
+++ b/drivers/mtd/spi/sf_mtd.c
@@ -39,6 +40,7 @@ static int spi_flash_mtd_read(struct mtd_info *mtd, loff_t
from, size_t len,
 struct spi_flash *flash = mtd->priv;
 int err;

+printf("%s \n", __func__);
 err = spi_flash_read(flash, from, len, buf);
 if (!err)
 *retlen = len;

and see:

=> sf probe
SF: Detected N25Q128A with page size 256 Bytes, erase size 64 KiB, total 16
MiB
=> mtdparts

device nor0 , # parts = 4
  #: namesizeoffset  mask_flags
  0: u-boot  0x000d  0x  0
  1: env 0x0001  0x000d  0
  2: env-red 0x0001  0x000e  0
  3: rescue-system   0x00f1  0x000f  0

device nand0 , # parts = 1
  #: namesizeoffset  mask_flags
  0: ubi 0x4000  0x  0

active partition: nor0,0 - (u-boot) 0x000d @ 0x

defaults:
mtdids  : none
mtdparts: none
=> ubi part rescue-system
UBI: default fastmap pool size: 10
UBI: default fastmap WL pool size: 25
UBI: attaching mtd2 to ubi0
UBI DBG gen (pid 1): sizeof(struct ubi_ainf_peb) 48
UBI DBG gen (pid 1): sizeof(struct ubi_wl_entry) 20
UBI DBG gen (pid 1): min_io_size  1
UBI DBG gen (pid 1): max_write_size   256
UBI DBG gen (pid 1): hdrs_min_io_size 1
UBI DBG gen (pid 1): ec_hdr_alsize64
UBI DBG gen (pid 1): vid_hdr_alsize   64
UBI DBG gen (pid 1): vid_hdr_offset   64
UBI DBG gen (pid 1): vid_hdr_aloffset 64
UBI DBG gen (pid 1): vid_hdr_shift0
UBI DBG gen (pid 1): leb_start128
UBI DBG gen (pid 1): max_erroneous24
UBI DBG gen (pid 1): process PEB 0
UBI DBG bld (pid 1): scan PEB 0
UBI DBG io (pid 1): read EC header from PEB 0
UBI DBG io (pid 1): read 64 bytes from PEB 0:0
spi_flash_mtd_read 
UBI DBG io (pid 1): read VID header from PEB 0
UBI DBG io (pid 1): read 64 bytes from PEB 0:64
spi_flash_mtd_read 
[...]

UBI uses the MTD layer ... the sf command not ...
Hope this helps?

bye,
Heiko



On 27 April 2015 at 11:12, Heiko Schocher  wrote:


From: Daniel Schwierzeck 

add MTD layer driver for spi, original patch from:

http://git.denx.de/?p=u-boot/u-boot-mips.git;a=commitdiff;h=bb246819cdc90493dd7089eaa51b9e639765cced

changes from Heiko Schocher against this patch:
- remove compile error if not defining CONFIG_SPI_FLASH_MTD:

LD  drivers/mtd/spi/built-in.o
drivers/mtd/spi/sf_probe.o: In function `spi_flash_mtd_unregist

Re: [U-Boot] [PATCH v6 1/4] mtd, spi: add MTD layer driver

[Jagan Teki]

Hi Heiko,

On 20 May 2015 at 12:16, Heiko Schocher  wrote:
> Hello Jagan,
>
> Am 19.05.2015 22:09, schrieb Jagan Teki:
>>
>> Hi Heiko,
>>
>> I have tested this sf-mtd stuff, please see below and enabled prints
>> in all the func calls.
>
>
> Thanks for testing!
>
>
>> zynq-uboot> mtdparts add nor0 0x1@0x0 env
>> mtdparts variable not set, see 'help mtdparts'
>> zynq-uboot> mtdparts
>>
>> device nor0 , # parts = 1
>>   #: namesizeoffset  mask_flags
>>   0: env 0x0001  0x  0
>>
>> active partition: nor0,0 - (env) 0x0001 @ 0x
>>
>> defaults:
>> mtdids  : nor0=zynq-sf.0
>> mtdparts: none
>> zynq-uboot> sf erase env 0x1
>> spi_flash_erase
>> spi_flash_cmd_erase_ops
>> SF: erase d8  0  0  0 (0)
>> SF: 65536 bytes @ 0x0 Erased: OK
>> zynq-uboot> mw.b 0x100 0x44 0x1
>> zynq-uboot> sf write 0x100 env
>> device 0 offset 0x0, size 0x1
>> spi_flash_cmd_write_ops
>> SF: 65536 bytes @ 0x0 Written: OK
>> zynq-uboot> sf read 0x4 env
>> device 0 offset 0x0, size 0x1
>> spi_flash_cmd_read_ops
>> off = 0x1, len = 0
>> SF: 65536 bytes @ 0x0 Read: OK
>> zynq-uboot> cmp.b 0x100 0x4 0x1
>> Total of 65536 byte(s) were the same
>
>
> Looks good ...
>
>> I wonder none of the sf_mtd_info._* getting called, why?
>
>
> Hmm.. good question .. you use the "sf ..." commands, they do not
> use the mtd interface, right?

I'm fine with the testing, but mtd code in sf seems used only for in UBI only.
I wouldn't see this is a better approach where mtd code is considered as to
be unknown thing for sf.

>
> I tested this functions with using UBI on the SPI NOR on the
> aristainetos and aristianetos2 boards... I added for example in
>
> diff --git a/drivers/mtd/spi/sf_mtd.c b/drivers/mtd/spi/sf_mtd.c
> index 0b9cb62..6063ed7 100644
> --- a/drivers/mtd/spi/sf_mtd.c
> +++ b/drivers/mtd/spi/sf_mtd.c
> @@ -39,6 +40,7 @@ static int spi_flash_mtd_read(struct mtd_info *mtd, loff_t
> from, size_t len,
> struct spi_flash *flash = mtd->priv;
> int err;
>
> +printf("%s \n", __func__);
> err = spi_flash_read(flash, from, len, buf);
> if (!err)
> *retlen = len;
>
> and see:
>
> => sf probe
> SF: Detected N25Q128A with page size 256 Bytes, erase size 64 KiB, total 16
> MiB
> => mtdparts
>
> device nor0 , # parts = 4
>  #: namesizeoffset  mask_flags
>  0: u-boot  0x000d  0x  0
>  1: env 0x0001  0x000d  0
>  2: env-red 0x0001  0x000e  0
>  3: rescue-system   0x00f1  0x000f  0
>
> device nand0 , # parts = 1
>  #: namesizeoffset  mask_flags
>  0: ubi 0x4000  0x  0
>
> active partition: nor0,0 - (u-boot) 0x000d @ 0x
>
> defaults:
> mtdids  : none
> mtdparts: none
> => ubi part rescue-system
> UBI: default fastmap pool size: 10
> UBI: default fastmap WL pool size: 25
> UBI: attaching mtd2 to ubi0
> UBI DBG gen (pid 1): sizeof(struct ubi_ainf_peb) 48
> UBI DBG gen (pid 1): sizeof(struct ubi_wl_entry) 20
> UBI DBG gen (pid 1): min_io_size  1
> UBI DBG gen (pid 1): max_write_size   256
> UBI DBG gen (pid 1): hdrs_min_io_size 1
> UBI DBG gen (pid 1): ec_hdr_alsize64
> UBI DBG gen (pid 1): vid_hdr_alsize   64
> UBI DBG gen (pid 1): vid_hdr_offset   64
> UBI DBG gen (pid 1): vid_hdr_aloffset 64
> UBI DBG gen (pid 1): vid_hdr_shift0
> UBI DBG gen (pid 1): leb_start128
> UBI DBG gen (pid 1): max_erroneous24
> UBI DBG gen (pid 1): process PEB 0
> UBI DBG bld (pid 1): scan PEB 0
> UBI DBG io (pid 1): read EC header from PEB 0
> UBI DBG io (pid 1): read 64 bytes from PEB 0:0
> spi_flash_mtd_read 
> UBI DBG io (pid 1): read VID header from PEB 0
> UBI DBG io (pid 1): read 64 bytes from PEB 0:64
> spi_flash_mtd_read 
> [...]
>
> UBI uses the MTD layer ... the sf command not ...
> Hope this helps?
>
> bye,
> Heiko
>
>
>> On 27 April 2015 at 11:12, Heiko Schocher  wrote:
>>>
>>> From: Daniel Schwierzeck 
>>>
>>> add MTD layer driver for spi, original patch from:
>>>
>>> http://git.denx.de/?p=u-boot/u-boot-mips.git;a=commitdiff;h=bb246819cdc90493dd7089eaa51b9e639765cced
>>>
>>> changes from Heiko Schocher against this patch:
>>> - remove compile error if not defining CONFIG_SPI_FLASH_MTD:
>>>
>>>LD  drivers/mtd/spi/built-in.o
>>> drivers/mtd/spi/sf_probe.o: In function `spi_flash_mtd_unregister':
>>> /home/hs/abb/imx6/u-boot/drivers/mtd/spi/sf_internal.h:168: multiple
>>> definition of `spi_flash_mtd_unregister'
>>>
>>> drivers/mtd/spi/sf_params.o:/home/hs/abb/imx6/u-boot/drivers/mtd/spi/sf_internal.h:168:
>>> first defined here
>>> drivers/mtd/spi/sf_ops.o: In function `spi_flash_mtd_unregister':
>>> /home/hs/abb/imx6/u-boot/drivers/mtd/spi/sf_internal.h:168: multiple
>>> definition of `spi_flash_mtd_unregister'
>>>
>>> drivers/mtd/spi/sf_param

[U-Boot] [PATCH] gpio: mxc_gpio: enable DM gpio before relocation

[Markus Niebel]

From: Markus Niebel 

gpio often are needed to detect revision and variants.
Therefore gpio should be available ASAP.

Signed-off-by: Markus Niebel 
---
 drivers/gpio/mxc_gpio.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpio/mxc_gpio.c b/drivers/gpio/mxc_gpio.c
index 2012f99..925758a 100644
--- a/drivers/gpio/mxc_gpio.c
+++ b/drivers/gpio/mxc_gpio.c
@@ -330,6 +330,7 @@ U_BOOT_DRIVER(gpio_mxc) = {
.priv_auto_alloc_size = sizeof(struct mxc_bank_info),
.of_match = mxc_gpio_ids,
.bind   = mxc_gpio_bind,
+   .flags  = DM_FLAG_PRE_RELOC,
 };
 
 #ifndef CONFIG_OF_CONTROL
-- 
2.3.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot