Re: [U-Boot] [PATCH] build: create time and date independent binary

2015-06-13 Thread Chris Kuethe
On Fri, Jun 12, 2015 at 8:31 AM, Heiko Schocher  wrote:
> With this option enabled each compilation creates the exact
> same binary. There are no timestamps, with which a U-Boot
> binary can be identified.

Works on usbarmory.

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


Re: [U-Boot] [Reproducible-builds] [PATCH] build: create time and date independent binary

2015-06-13 Thread Paul Kocialkowski
Le samedi 13 juin 2015 à 11:10 +0200, Holger Levsen a écrit :
> Hi Paul,
> 
> thanks for contacting us!
> 
> On Freitag, 12. Juni 2015, Paul Kocialkowski wrote:
> > I think a bit more is needed to get truly reproducible builds in U-Boot,
> > but this is a first good step!
> 
> you've seen https://reproducible.debian.net/u-boot ?

This seems very minimalistic, but it's good to see U-Boot was given some
attention already!

> > It would certainly be relevant to get in touch with the people working
> > on reproducing builds for Debian (I know Lunar is involved with this),
> > since Debian packages U-Boot for many devices and they're apparently
> > willing to help upstream with automated tests, as they're doing with
> > coreboot and OpenWRT!
> 
> we're definitly happy to help! 
> 
> that said, I'm not sure I want to treat uboot like openwrt or coreboot, 
> simply 
> because uboot is packaged for several distributions, so (in my maybe naive 
> assumptions) it should be tested within those distros.
> 
> coreboot is really exceptional here, as it doesn't make much sense to package 
> it as part of a distro. (though this could also change, at least sources 
> could 
> be shipped...)
> 
> but maybe you can explain why u-boot needs more reproducibility testing than 
> what there currently is. i'm definitly interested and not opposed, even 
> though 
> I think there shoukd be good reasons to treat some software specially.

The point is to make U-Boot reproducible for all possible targets, not
only the few ones that are supported by U-Boot. I think this requires
some extra infrastructure. In that sense, it is very similar to
Coreboot.

> (also please note that we currently only have amd64 hw to run our tests on.)

The problem is the same as Coreboot, which uses its own toolchain to
build images. We don't need to have native armhf builds for U-Boot,
testing with the armhf toolchain that is in Debian should be enough.

> In a similar way I have for now decided that I'm not interested in adding 
> tests of libreboot, as it's basically just a fork of coreboot, so the 
> reproducibility issues should be the same. OTOH libreboot releases images 
> (which coreboot doesnt do) so that might become interesting to validate. But 
> there I think that the validation should be done as part of that project 
> (=libreboot), and not as part of reproducible.debian.net, which I mostly see 
> as a.) effort to test and push Debians reproducibility effort and b.) show 
> that this is possible for other distros too - but I think in long term that 
> should move to a setup located+maintained at those other distros. (because we 
> lack the *human*power to look after too/so many things...)

I understand, this works out nicely because all the work on Coreboot
will be inherited by Libreboot. However, on U-Boot, the work to bring
reproducible builds has to take place initially. I know for a fact that
parts of the code use things like __FILE__ or timestamps.

Also, if those were fixed in Debian, it would be nice to get those
changes back in upstream.

> (And really, testing on reproducible.debian.net is not enough, it's just the 
> first step: now we know that coreboot is 100% reproducible, now what? This 
> "what" needs to happen on the coreboot side...)
> 
> So it's not (so much or maybe at all) a question of hardware ressources, 
> which 
> we can scale up rather easily, but mostly human ressources maintaining the 
> hw+sw *and* translating this into meaningful action for the project tested.

That makes sense. For U-Boot, it will certainly make sense for the
distributions packaging it. I'm the main developer of Replicant, the
fully free version of Android, and it would definitely be useful to have
a smartphone on which we can trust that the bootloader can be built in a
reproducible manner (and checked after being installed).

> All this said, if you send me patches, I will probably deploy them as I'm 
> very 
> curious and more reproducibility efforts are good :-) We can can always 
> decide 
> to remove or move them later.

I wish to make all contributions upstream. What would really help at
first would be to have all targets built regularly to see where work is
needed. This is where I think the Debian infrastructure could help, in a
similar way as what was started for Coreboot.

Thanks for your help!

-- 
Paul Kocialkowski, Replicant developer

Replicant is a fully free Android distribution running on several
devices, a free software mobile operating system putting the emphasis on
freedom and privacy/security.

Website: http://www.replicant.us/
Blog: http://blog.replicant.us/
Wiki/tracker/forums: http://redmine.replicant.us/


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


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

2015-06-13 Thread Andre Przywara
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(-)

diff --git a/common/fdt_support.c b/common/fdt_support.c
index 9e50148..6ad532c 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -429,13 +429,15 @@ int fdt_fixup_memory_banks(void *blob, u64 start[], u64 
size[], int banks)
return err;
}
 
-   len = fdt_pack_reg(blob, tmp, start, size, banks);
+   if (banks) {
+   len = fdt_pack_reg(blob, tmp, start, size, banks);
 
-   err = fdt_setprop(blob, nodeoffset, "reg", tmp, len);
-   if (err < 0) {
-   printf("WARNING: could not set %s %s.\n",
-   "reg", fdt_strerror(err));
-   return err;
+   err = fdt_setprop(blob, nodeoffset, "reg", tmp, len);
+   if (err < 0) {
+   printf("WARNING: could not set %s %s.\n",
+   "reg", fdt_strerror(err));
+   return err;
+   }
}
return 0;
 }
diff --git a/include/fdt_support.h b/include/fdt_support.h
index 5d4f28d..0296ed3 100644
--- a/include/fdt_support.h
+++ b/include/fdt_support.h
@@ -40,8 +40,34 @@ void do_fixup_by_compat(void *fdt, const char *compat,
const char *prop, const void *val, int len, int create);
 void do_fixup_by_compat_u32(void *fdt, const char *compat,
const char *prop, u32 val, int create);
+/**
+ * Setup the memory node in the DT. Creates one if none was existing before.
+ * Calls fdt_fixup_memory_banks() to populate a single reg pair covering the
+ * whole memory.
+ *
+ * @param blob FDT blob to update
+ * @param startBegin of DRAM mapping in physical memory
+ * @param size Size of the single memory bank
+ * @return 0 if ok, or -1 or -FDT_ERR_... on error
+ */
 int fdt_fixup_memory(void *blob, u64 start, u64 size);
+
+/**
+ * Fill the DT memory node with multiple memory banks.
+ * Creates the node if none was existing before.
+ * If banks is 0, it will not touch the existing reg property. This allows
+ * boards to not mess with the existing DT setup, which may have been
+ * filled in properly before.
+ *
+ * @param blob FDT blob to update
+ * @param startArray of size  to hold the start 
addresses.
+ * @param size Array of size  to hold the size of each region.
+ * @param banksNumber of memory banks to create. If 0, the reg
+ * property will be left untouched.
+ * @return 0 if ok, or -1 or -FDT_ERR_... on error
+ */
 int fdt_fixup_memory_banks(void *blob, u64 start[], u64 size[], int banks);
+
 void fdt_fixup_ethernet(void *fdt);
 int fdt_find_and_setprop(void *fdt, const char *node, const char *prop,
 const void *val, int len, int create);
-- 
1.8.4

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


Re: [U-Boot] [PATCH] kconfiglib: update to the latest version

2015-06-13 Thread Ulf Magnusson
On Fri, Jun 12, 2015 at 6:56 PM, Ulf Magnusson  wrote:
> Corresponds to 2f319b8 in https://github.com/ulfalizer/Kconfiglib.
>
> Fixes:
>
>   - Unset user values when loading a zero-byte .config. (5e54e2c)
>   - Ignore indented .config assignments. (f8a7510)
>   - Do not require $srctree to be set for non-kernel projects. (d56e9c1)
>
> Also adds Python 3 support and has a lot of internal cleanup and
> optimization. Makes tools/genboardscfg.py run slightly faster.
>
> Signed-off-by: Ulf Magnusson 
> ---
>  tools/buildman/kconfiglib.py | 2898 
> +++---
>  1 file changed, 1329 insertions(+), 1569 deletions(-)
>
> diff --git a/tools/buildman/kconfiglib.py b/tools/buildman/kconfiglib.py
> index 655cf44..e71f43e 100644
> --- a/tools/buildman/kconfiglib.py
> +++ b/tools/buildman/kconfiglib.py
> @@ -36,57 +36,61 @@ Kconfig-based configuration systems. Features include the 
> following:
>
> [SNIP]

Adding __slots__ (https://docs.python.org/2/reference/datamodel.html#slots) to
the Kconfiglib classes reduces the runtime of genboardscfg.py further from 1.6
to 1.4 seconds on my system, also saving a lot of memory. It'd remove some
flexibility though (and breaks the kconfig-diff.py example), so it
should probably
be optional if I add it. Maybe genboardscfg.py is fast enough already.

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


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

2015-06-13 Thread 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 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 v3 4/6] x86: Move lapic_setup() call into init_bsp()

2015-06-13 Thread 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 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 6387229..0df8eb0 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 v3 5/6] x86: Clean up lapic codes

2015-06-13 Thread 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 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
+ * just a number repres

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

2015-06-13 Thread Bin Meng
Ivybridge is not ready for U-Boot MP initialization yet.

Signed-off-by: Bin Meng 

---

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 v3 3/6] x86: Move MP initialization codes into a common place

2015-06-13 Thread 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 

---

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 | 99 ++---
 arch/x86/cpu/cpu.c  | 40 ++
 arch/x86/cpu/cpu_x86.c  | 30 ++
 arch/x86/cpu/mp_init.c  | 18 +++--
 arch/x86/include/asm/mp.h   |  1 -
 drivers/cpu/cpu-uclass.c|  2 +
 6 files changed, 117 insertions(+), 73 deletions(-)

diff --git a/arch/x86/cpu/baytrail/cpu.c b/arch/x86/cpu/baytrail/cpu.c
index 05156a5..afcc4a9 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,39 @@ static int baytrail_get_info(struct udevice *dev, struct 
cpu_info *info)
return 0;
 }
 
+static int baytrail_get_count(struct udevice *dev, int *count)
+{
+   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) {
+   *count = leaf_b.ebx & 0x;
+   break;
+   }
+   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),
+};
+
+s

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

2015-06-13 Thread 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 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)
+{
+   struct cpu_ops *ops = cpu_get_ops(dev);
+
+   if (!ops->get_count)
+   return -ENOSYS;
+
+   return ops->get_count(dev, count);
+}
+
 U_BOOT_DRIVER(cpu_bus) = {
.name   = "cpu_bus",
.id = UCLASS_SIMPLE_BUS,
diff --git a/include/cpu.h b/include/cpu.h
index 34c60bc..6fd735d 100644
--- a/include/cpu.h
+++ b/include/cpu.h
@@ -58,6 +58,15 @@ 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)
+* @count:  Returns CPU count
+* @return 0 if OK, -ve on error
+*/
+   int (*get_count)(struct udevice *dev, int *count);
 };
 
 #define cpu_get_ops(dev)((struct cpu_ops *)(dev)->driver->ops)
@@ -81,4 +90,13 @@ 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)
+ * @count: Returns CPU count
+ * @return 0 if OK, -ve on error
+ */
+int cpu_get_count(struct udevice *dev, int *count);
+
 #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 v2 2/3] common: cmd_part: start and size sub-commands introduction

2015-06-13 Thread Paul Kocialkowski
This introduces the part start and part size sub-commands. The purpose of these
is to store the start block and size of a partition in a variable, given the
device and partition number.

This allows reading raw data that fits a single partition more easily.
For instance, this could be used to figure out the start block and size of a
kernel partition when a partition table is present, given the partition number.

Signed-off-by: Paul Kocialkowski 
---
 common/cmd_part.c | 66 ++-
 1 file changed, 65 insertions(+), 1 deletion(-)

diff --git a/common/cmd_part.c b/common/cmd_part.c
index 4bdbf90..7212ba6 100644
--- a/common/cmd_part.c
+++ b/common/cmd_part.c
@@ -112,6 +112,62 @@ static int do_part_list(int argc, char * const argv[])
return 0;
 }
 
+static int do_part_start(int argc, char * const argv[])
+{
+   block_dev_desc_t *desc;
+   disk_partition_t info;
+   char buf[512] = { 0 };
+   int part;
+   int err;
+   int ret;
+
+   if (argc < 4)
+   return CMD_RET_USAGE;
+
+   part = simple_strtoul(argv[2], NULL, 0);
+
+   ret = get_device(argv[0], argv[1], &desc);
+   if (ret < 0)
+   return 1;
+
+   err = get_partition_info(desc, part, &info);
+   if (err)
+   return 1;
+
+   snprintf(buf, sizeof(buf), "0x%lx", info.start);
+   setenv(argv[3], buf);
+
+   return 0;
+}
+
+static int do_part_size(int argc, char * const argv[])
+{
+   block_dev_desc_t *desc;
+   disk_partition_t info;
+   char buf[512] = { 0 };
+   int part;
+   int err;
+   int ret;
+
+   if (argc < 4)
+   return CMD_RET_USAGE;
+
+   part = simple_strtoul(argv[2], NULL, 0);
+
+   ret = get_device(argv[0], argv[1], &desc);
+   if (ret < 0)
+   return 1;
+
+   err = get_partition_info(desc, part, &info);
+   if (err)
+   return 1;
+
+   snprintf(buf, sizeof(buf), "0x%lx", info.size);
+   setenv(argv[3], buf);
+
+   return 0;
+}
+
 static int do_part(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
 {
if (argc < 2)
@@ -121,6 +177,10 @@ static int do_part(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
return do_part_uuid(argc - 2, argv + 2);
else if (!strcmp(argv[1], "list"))
return do_part_list(argc - 2, argv + 2);
+   else if (!strcmp(argv[1], "start"))
+   return do_part_start(argc - 2, argv + 2);
+   else if (!strcmp(argv[1], "size"))
+   return do_part_size(argc - 2, argv + 2);
 
return CMD_RET_USAGE;
 }
@@ -136,5 +196,9 @@ U_BOOT_CMD(
"- print a device's partition table\n"
"part list   [flags] \n"
"- set environment variable to the list of partitions\n"
-   "  flags can be -bootable (list only bootable partitions)"
+   "  flags can be -bootable (list only bootable partitions)\n"
+   "part start\n"
+   "- set environment variable to the start of the partition (in 
blocks)\n"
+   "part size\n"
+   "- set environment variable to the size of the partition (in 
blocks)"
 );
-- 
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] common: cmd_part: Error prints on failures

2015-06-13 Thread Paul Kocialkowski
When a failure occurs when selecting the device or partition, the user should be
notified through an error print.

Signed-off-by: Paul Kocialkowski 
---
 common/cmd_part.c | 24 ++--
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/common/cmd_part.c b/common/cmd_part.c
index 7212ba6..ff9bc07 100644
--- a/common/cmd_part.c
+++ b/common/cmd_part.c
@@ -38,8 +38,10 @@ static int do_part_uuid(int argc, char * const argv[])
return CMD_RET_USAGE;
 
part = get_device_and_partition(argv[0], argv[1], &dev_desc, &info, 0);
-   if (part < 0)
+   if (part < 0) {
+   error("Invalid device and/or partition\n");
return 1;
+   }
 
if (argc > 2)
setenv(argv[2], info.uuid);
@@ -82,8 +84,10 @@ static int do_part_list(int argc, char * const argv[])
}
 
ret = get_device(argv[0], argv[1], &desc);
-   if (ret < 0)
+   if (ret < 0) {
+   error("Invalid device\n");
return 1;
+   }
 
if (var != NULL) {
int p;
@@ -127,12 +131,16 @@ static int do_part_start(int argc, char * const argv[])
part = simple_strtoul(argv[2], NULL, 0);
 
ret = get_device(argv[0], argv[1], &desc);
-   if (ret < 0)
+   if (ret < 0) {
+   error("Invalid device\n");
return 1;
+   }
 
err = get_partition_info(desc, part, &info);
-   if (err)
+   if (err) {
+   error("Invalid partition number\n");
return 1;
+   }
 
snprintf(buf, sizeof(buf), "0x%lx", info.start);
setenv(argv[3], buf);
@@ -155,12 +163,16 @@ static int do_part_size(int argc, char * const argv[])
part = simple_strtoul(argv[2], NULL, 0);
 
ret = get_device(argv[0], argv[1], &desc);
-   if (ret < 0)
+   if (ret < 0) {
+   error("Invalid device\n");
return 1;
+   }
 
err = get_partition_info(desc, part, &info);
-   if (err)
+   if (err) {
+   error("Invalid partition number\n");
return 1;
+   }
 
snprintf(buf, sizeof(buf), "0x%lx", info.size);
setenv(argv[3], buf);
-- 
1.9.1

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


[U-Boot] [PATCH v2 1/3] common: cmd_part: Proper alignment

2015-06-13 Thread Paul Kocialkowski
This fixes a misaligned declaration.

Signed-off-by: Paul Kocialkowski 
---
 common/cmd_part.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/cmd_part.c b/common/cmd_part.c
index 8483c12..4bdbf90 100644
--- a/common/cmd_part.c
+++ b/common/cmd_part.c
@@ -88,7 +88,7 @@ static int do_part_list(int argc, char * const argv[])
if (var != NULL) {
int p;
char str[512] = { '\0', };
- disk_partition_t info;
+   disk_partition_t info;
 
for (p = 1; p < 128; p++) {
char t[5];
-- 
1.9.1

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


[U-Boot] [PATCH v2 0/3] common: cmd_part: start and size sub-commands introduction

2015-06-13 Thread Paul Kocialkowski
Changes since v1:
* Fixed build errors related to snprintf

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


Re: [U-Boot] [PATCH 4/9] x86: Move MP initialization codes into a common place

2015-06-13 Thread Bin Meng
Hi Simon,

On Sat, Jun 13, 2015 at 3:10 AM, Simon Glass  wrote:
> Hi Bin,
>
> On 11 June 2015 at 20:07, Bin Meng  wrote:
>> Hi Simon,
>>
>> On Fri, Jun 12, 2015 at 7:39 AM, Simon Glass  wrote:
>>> Hi Bin,
>>>
>>> On 9 June 2015 at 01:45, Bin Meng  wrote:
 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 declare a weak
 detect_num_cpus() which just returns 2 which is minimally required.

 Signed-off-by: Bin Meng 
 ---

  arch/x86/cpu/baytrail/cpu.c | 44 
 +-
  arch/x86/cpu/cpu.c  | 47 
 +
  2 files changed, 48 insertions(+), 43 deletions(-)

 diff --git a/arch/x86/cpu/baytrail/cpu.c b/arch/x86/cpu/baytrail/cpu.c
 index 05156a5..7805056 100644
 --- a/arch/x86/cpu/baytrail/cpu.c
 +++ b/arch/x86/cpu/baytrail/cpu.c
 @@ -12,23 +12,11 @@
  #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 detect_num_cpus(void)
  {
 int ecx = 0;

 @@ -52,38 +40,8 @@ static int detect_num_cpus(void)
 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;
 diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c
 index ffb6e43..ddc7dc3 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 
 @@ -601,8 +604,52 @@ 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),
 +};
 +
 +__weak int detect_num_cpus(void)
>>>
>>> Does this need to be weak? We could perhaps require that the function 
>>> exists?
>>>
>>
>> Yes, since I don't see there is a common way to detect number of cpu
>> cores. Or maybe I am not aware of one. If we want to remove the weak,
>> maybe we can just switch to count the number of cpu nodes in /cpus
>> from device tree, which should be generic for all cases. I believe we
>> discussed this during the review when you added MP stuff.
>
> I worry what might happen if the device tree says 4 but there are only
> 2 CPUs. There should be a way to detect the number of CPUs gracefully
> in each arch.

I don't think there will be any problem for device tree says 4 but
actually 2. U-Boot will just enable 2 CPUs and report 2 to the OS. The
case that might have a problem is that the device tree says 2 but
there are actually 4 CPUs. There is a check_cpu_devices() call in
mp_init() which will put a debug message "Warning: Device tree does
not describe all CPUs. Extra ones will not be started correctly".
There are some places (like SFI) in U-Boot that look up the cpus node
in device tree , and we will end up CPU#2~3 not reported to OS. But
why should we create a device tree which does not describe the
hardware in the first place?

> Can you add get_cpu_count() as a method to the UCLASS_CPU ops perhaps?
> Then baytrail can use it.
>
> mp_init() can make the get_cpu_count() call after finding the first
> CPU, and we c

Re: [U-Boot] [PATCH] fastboot: Dynamic controller index for usb_gadget_handle_interrupts

2015-06-13 Thread Paul Kocialkowski
[snip]

> >> Reviewed-by: Lukasz Majewski 
> >
> > This is in my queue and looks like a fix, so I'm picking it up.
> >
> > Applied to u-boot-x86, thanks!
> 
> Unfortunately in my final build test this breaks a number of boards, 
> including:
> 
> am335x_boneblack_vboot
> 
> common/cmd_fastboot.c:36:32: error: ‘controller_index’ undeclared
> (first use in this function)
>usb_gadget_handle_interrupts(controller_index);
> 
> Can you please take a look and respin it?

Of course, this makes perfect sense. I didn't think about it until now,
but this patch goes on top of the four fastboot-related dfu patches that
I sent out (again) yesterday.

I think this should be picked up along with those patches.
Lukasz, could you do that?

Thanks

> For now I've dropped it from u-boot-x86.

Makes sense.

-- 
Paul Kocialkowski, Replicant developer

Replicant is a fully free Android distribution running on several
devices, a free software mobile operating system putting the emphasis on
freedom and privacy/security.

Website: http://www.replicant.us/
Blog: http://blog.replicant.us/
Wiki/tracker/forums: http://redmine.replicant.us/


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] board/BuR/common: support timer5 for pwm-backlight

2015-06-13 Thread Hannes Schmelzer

Hi Simon,

board_type doesn't apply here.

The board can be used in

Device-Type A
Device-Type B
Device-Type C

all of them may have different backlights.
So it comes, that device-type A has different variants where one has 
backlight using PMIC, the other one has backlight using PWM.


For this we have an entry within the device-tree (brightdrv) on linux 
devices, and on vxworks-devices (where we don't have a device-tree) we 
have same as variable in environment.


The board_type variable is used to separate "Device-Type A, Device-Type 
B, ..."


At this time only one of my boards (brxre2, not committed yet) has this 
variable in use.


best regards,
Hannes

On 2015-06-11 22:07, Simon Glass wrote:

Hi,

On 11 June 2015 at 04:25, Hannes Schmelzer  wrote:

in future we support yet another b&r am335x based board, where Timer 5 is
wired to backlight-driver.

So we introduce a new driver-type '2' to setup timer5 instead timer6.

Signed-off-by: Hannes Schmelzer 


Reviewed-by: Simon Glass 

You might consider using an enum for the board type.


---

  board/BuR/common/common.c | 14 +++---
  1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/board/BuR/common/common.c b/board/BuR/common/common.c
index 7830d1a..441465c 100644
--- a/board/BuR/common/common.c
+++ b/board/BuR/common/common.c
@@ -64,8 +64,7 @@ void lcdbacklight(int on)
 unsigned int pwmfrq = getenv_ulong("ds1_pwmfreq", 10, ~0UL);
  #endif
 unsigned int tmp;
-
-   struct gptimer *const timerhw = (struct gptimer *)DM_TIMER6_BASE;
+   struct gptimer *timerhw;

 if (on)
 bright = bright != ~0UL ? bright : 50;
@@ -73,6 +72,14 @@ void lcdbacklight(int on)
 bright = 0;

 switch (driver) {
+   case 2:
+   timerhw = (struct gptimer *)DM_TIMER5_BASE;
+   break;
+   default:
+   timerhw = (struct gptimer *)DM_TIMER6_BASE;
+   }
+
+   switch (driver) {
 case 0: /* PMIC LED-Driver */
 /* brightness level */
 tps65217_reg_write(TPS65217_PROT_LEVEL_NONE,
@@ -83,7 +90,8 @@ void lcdbacklight(int on)
bright != 0 ? 0x0A : 0x02,
0xFF);
 break;
-   case 1: /* PWM using timer6 */
+   case 1:
+   case 2: /* PWM using timer */
 if (pwmfrq != ~0UL) {
 timerhw->tiocp_cfg = TCFG_RESET;
 udelay(10);
--
2.1.4


Regards,
Simon




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