Hi Simon,
On Mon, Mar 7, 2016 at 10:27 AM, Simon Glass wrote:
> This series adds support for samus, the Chromebook Pixel 2015. Since it is
> only the second board added that does not use an FSP, there is quite a bit
> of refactoring involved to avoid code duplication.
>
> Samus uses roughly the s
On Fri, Mar 11, 2016 at 3:38 PM, Bin Meng wrote:
> On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
>> Add two microcode files for broadwell.
>>
>> Signed-off-by: Simon Glass
>> ---
>>
>> arch/x86/dts/microcode/m7240651_001c.dtsi | 1328
>> +
>> arch/x86/dts/micr
On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
> Add two microcode files for broadwell.
>
> Signed-off-by: Simon Glass
> ---
>
> arch/x86/dts/microcode/m7240651_001c.dtsi | 1328
> +
> arch/x86/dts/microcode/mc0306d4_0018.dtsi | 944 ++
> 2
On Fri, Mar 11, 2016 at 3:18 PM, Bin Meng wrote:
> On Fri, Mar 11, 2016 at 3:17 PM, Bin Meng wrote:
>> On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
>>> Add a driver which sets up the pin configuration on x86 devices with an ICH6
>>> (or later) Platform Controller Hub.
>>>
>>> The driver i
Hi Simon,
On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
> This adds the broadwell architecture, with the CPU driver and some useful
> header files.
>
> Signed-off-by: Simon Glass
> ---
>
> arch/x86/Kconfig| 1 +
> arch/x86/cpu/Makefile |
On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
> Make a few minor updates to make the meaning clearer.
>
> Signed-off-by: Simon Glass
> ---
>
> doc/device-tree-bindings/gpio/intel,x86-pinctrl.txt | 21
> +++--
> 1 file changed, 11 insertions(+), 10 deletions(-)
>
Reviewed-
Hi Simon,
On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
> Intel has invented yet another binary blob which firmware is required to
> run. This is run after SDRAM is ready. It is linked to load at a particular
> address, typically 0, but is a relocatable ELF so can be moved if required.
>
T
On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
> We don't need this anymore - we can use device tree and the new pinconfig
> driver instead.
>
> Signed-off-by: Simon Glass
> ---
>
> arch/x86/include/asm/gpio.h | 141
> --
> board/coreboot/coreboot/
On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
> Rather than setting up the pin configuration in the GPIO driver, use the
> new pinctrl driver to do it.
>
> Signed-off-by: Simon Glass
> ---
>
> configs/bayleybay_defconfig | 2 +
> configs/cougarcanyon2_defconfig | 2 +
> configs/cro
On Fri, Mar 11, 2016 at 3:01 PM, Bin Meng wrote:
> On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
>> The Intel SIPI (start-up inter-processor interrupt) vector is the entry
>> point for each secondary CPU (also called an AP - applications processor).
>> The assembler and C code are linked, s
On Fri, Mar 11, 2016 at 3:17 PM, Bin Meng wrote:
> On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
>> Add a driver which sets up the pin configuration on x86 devices with an ICH6
>> (or later) Platform Controller Hub.
>>
>> The driver is not in the pinctrl uclass due to some oddities of the w
On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
> Add a driver which sets up the pin configuration on x86 devices with an ICH6
> (or later) Platform Controller Hub.
>
> The driver is not in the pinctrl uclass due to some oddities of the way x86
> devices work:
>
> - The GPIO controller is not
Hi Simon,
On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
> At present pin configuration on link does not use the standard mechanism,
> but some rather ugly custom code. As a first step to resolving this, add the
> pin configuration to the device tree.
>
> Four of the GPIOs must be available
Hi Simon,
On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
> Each CPU needs to have its microcode loaded. Add support for this so that
> all CPUs will have the same version.
>
> Signed-off-by: Simon Glass
> ---
>
> arch/x86/cpu/cpu.c | 1 +
> arch/x86/cpu/intel_common/car.S |
On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
> The Intel SIPI (start-up inter-processor interrupt) vector is the entry
> point for each secondary CPU (also called an AP - applications processor).
> The assembler and C code are linked, so add comments to indicate this.
>
> Signed-off-by: Sim
On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
> Enable the microcode feature so that the microcode version is shown with the
> 'cpu detail' command.
>
> Signed-off-by: Simon Glass
> ---
>
> arch/x86/cpu/ivybridge/model_206ax.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> d
Hi Simon,
On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
> As each core starts up, record its microcode version and CPU ID so these can
> be presented with the 'cpu detail' command.
>
> Signed-off-by: Simon Glass
> ---
>
> arch/x86/cpu/intel_common/microcode_intel.c | 2 +-
> arch/x86/cpu/
On Fri, Mar 11, 2016 at 2:43 PM, Bin Meng wrote:
> On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
>> The timeout step is always 50us. By updating apic_wait_timeout() to print
>> the debug messages we can simplify the code. Also tidy up a few messages and
>> comments while we are here.
>>
>>
Enables usb device-tree fixup code to incorporate xhci controller
Signed-off-by: Ramneek Mehresh
Signed-off-by: Sriram Dash
---
Changes in v4:
- Use a terminating entry in the array for getting node type for controller
Changes in v3:
- Modify the Makefile to remove comparison
- Put the sup
Move usb device-tree fixup framework from ehci-fsl.c to common place so
that it can be used by other drivers as well (xhci-fsl.c).
Signed-off-by: Ramneek Mehresh
Signed-off-by: Sriram Dash
---
Changes in v4:
- Retain copywrite info
- Remove #include from fsl-dt-fixup.c which are not used cur
fdt_usb_get_node_type() to return error code instead of pointer.
Signed-off-by: Sriram Dash
Signed-off-by: Rajesh Bhagat
---
drivers/usb/common/fsl-dt-fixup.c | 25 ++---
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/common/fsl-dt-fixup.c
b/dri
Call fdt_usb_get_node_type() from fdt_fixup_usb_mode_phy_type() to
avoid code duplication.
Signed-off-by: Sriram Dash
Signed-off-by: Rajesh Bhagat
---
Changes in v4:
- Make minimal modification to code
Changes in v3:
- Move the duplication of code to new patch
drivers/usb/common/fsl-dt-fix
Makes usb device-tree fixup independent of Controller type. This enables the
usage of device-tree fixup as a common framework for EHCI and XHCI controllers
Sriram Dash (4):
drivers:usb:common:fsl-dt-fixup: Move device-tree fixup framework to
common file
drivers:usb:common:fsl-dt-fixup: Rem
Hi everyone
I am having a problem with a Freescale imx28 to get HAB (High Assurance Boot)
working with U-Boot. I understand that this is a question regarding one specific
processor model but since I have seen several patches from Marek Vasut which
deal with this specific processor I am taking a ch
On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
> The timeout step is always 50us. By updating apic_wait_timeout() to print
> the debug messages we can simplify the code. Also tidy up a few messages and
> comments while we are here.
>
> Signed-off-by: Simon Glass
> ---
>
> arch/x86/cpu/mp_in
On 10.03.2016 20:13, Hans de Goede wrote:
Hi,
On 10-03-16 16:50, Stefan Roese wrote:
Debugging has shown, that all USB hubs are being resetted twice while
USB scanning. This introduces additional delays and makes USB scanning
even more slow. Testing has shown that this 2nd USB hub reset doesn't
Hi Simon,
On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
> At present the MRC options are private to ivybridge. Other Intel CPUs also
> use these settings. Move them to a common place.
>
> Signed-off-by: Simon Glass
> ---
>
> arch/x86/Kconfig | 39
On 11 March 2016 at 07:50, Marek Vasut wrote:
> The stm_is_locked_sr() function is picked from Linux kernel. For reason
> unknown, the 64bit data types used by the function and present in Linux
> were replaced with 32bit unsigned ones, which causes trouble.
>
> The testcase performed was done usin
On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
> It is common with memory-mapped I/O to use the address of a structure member
> to access memory, as in:
>
>struct some_regs {
> u32 ctrl;
> u32 data;
>}
>
>struct some_regs *regs = (struct some_regs *)BASE_ADDRESS;
>
>
On 10.03.2016 19:51, Hans de Goede wrote:
Hi,
On 10-03-16 16:50, Stefan Roese wrote:
Start with a short USB hub reset delay of 10ms. This can be enough for
some configurations.
The 2nd delay at the of the loop is completely removed. Since the delay
hasn't been long enough, a longer delay time
On 10.03.2016 19:55, Hans de Goede wrote:
Hi,
On 10-03-16 16:50, Stefan Roese wrote:
This patch removes 2 mdelay(200) calls from
usb_hub_port_connect_change().
These delays don't seem to be necessary. At least not in my tests. Here
the number for a custom x86 Bay Trail board (not in mainline ye
On 10.03.2016 19:55, Hans de Goede wrote:
Hi,
On 10-03-16 16:50, Stefan Roese wrote:
This patch removes 2 mdelay(200) calls from
usb_hub_port_connect_change().
These delays don't seem to be necessary. At least not in my tests. Here
the number for a custom x86 Bay Trail board (not in mainline ye
Hi Simon,
On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
> The clrsetbits_...() macros are useful for working with memory mapped I/O.
> But they do not work with I/O space, as used on x86 machines.
>
> Add some macros to provide similar features for I/O.
>
> Signed-off-by: Simon Glass
> ---
On Fri, Mar 11, 2016 at 2:12 PM, Bin Meng wrote:
> On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
>> Two power-on-self-test values are the same. Fix this.
>>
>> Signed-off-by: Simon Glass
>> ---
>>
>> arch/x86/include/asm/post.h | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
On Fri, Mar 11, 2016 at 2:11 PM, Bin Meng wrote:
> Hi Simon,
>
> On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
>> It is useful to automate the process of converting code from coreboot a
>> little. Add a sed script which performs some common transformations.
>>
>> Signed-off-by: Simon Glass
On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
> Two power-on-self-test values are the same. Fix this.
>
> Signed-off-by: Simon Glass
> ---
>
> arch/x86/include/asm/post.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
Reviewed-by: Bin Meng
_
Hi Simon,
On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
> It is useful to automate the process of converting code from coreboot a
> little. Add a sed script which performs some common transformations.
>
> Signed-off-by: Simon Glass
> ---
>
> doc/README.x86 | 9 +
> scripts/
On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
> This is not needed now that the memory controller driver has the SPD data
> in its own node.
>
> Signed-off-by: Simon Glass
> ---
>
> arch/x86/dts/chromebook_link.dts | 1 -
> include/fdtdec.h | 1 -
> lib/fdtdec.c
On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
> Adjust the existing implementation to use the new common SDRAM init code.
>
> Signed-off-by: Simon Glass
> ---
>
> arch/x86/cpu/ivybridge/sdram.c | 394
> +
> 1 file changed, 83 insertions(+), 311 dele
Hi Simon,
On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
> The code to call the memory reference code is common to several Intel CPUs.
> Add common code for performing this init. Intel calls this 'Pre-EFI-Init'
> (PEI), where EFI stands for Extensible Firmware Interface.
>
I doubt SDRAM ini
On Fri, Mar 11, 2016 at 1:52 PM, Bin Meng wrote:
> On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
>> At present the board ID GPIOs are hard-coded. Move them to the device tree
>> so that we can use general SDRAM init code.
>>
>> Signed-off-by: Simon Glass
>> ---
>>
>> arch/x86/dts/chromebo
On Fri, Mar 11, 2016 at 1:55 PM, Bin Meng wrote:
> On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
>> The Intel GPIO driver can set up the GPIO pin mapping when the first GPIO
>> is probed. However, it assumes that the first GPIO to be probed is in the
>> first GPIO bank. If this is not the c
On Fri, Mar 11, 2016 at 1:51 PM, Bin Meng wrote:
> On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
>> The SDRAM SPD (Serial Presence Detect) information should be contained
>> with the SDRAM controller. This makes it easier for the controller to access
>> it and removes the need for a separat
On Fri, Mar 11, 2016 at 1:50 PM, Bin Meng wrote:
> On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
>> In order to use GPIO phandles we need to add some GPIO properties as
>> specified by the GPIO bindings. Add these for link.
>>
>> Signed-off-by: Simon Glass
>> ---
>>
>> arch/x86/dts/chrome
On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
> The Intel GPIO driver can set up the GPIO pin mapping when the first GPIO
> is probed. However, it assumes that the first GPIO to be probed is in the
> first GPIO bank. If this is not the case then the init will write to the
> wrong registers.
On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
> At present the board ID GPIOs are hard-coded. Move them to the device tree
> so that we can use general SDRAM init code.
>
> Signed-off-by: Simon Glass
> ---
>
> arch/x86/dts/chromebook_link.dts | 2 ++
> 1 file changed, 2 insertions(+)
>
Re
On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
> The SDRAM SPD (Serial Presence Detect) information should be contained
> with the SDRAM controller. This makes it easier for the controller to access
> it and removes the need for a separate compatible string.
>
> As a first step, move the info
On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
> In order to use GPIO phandles we need to add some GPIO properties as
> specified by the GPIO bindings. Add these for link.
>
> Signed-off-by: Simon Glass
> ---
>
> arch/x86/dts/chromebook_link.dts | 12 +---
> 1 file changed, 9 insert
Hi Simon,
On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
> The SATA indexed register write functions are common to several Intel PCHs.
> Move this into a common location.
>
> Signed-off-by: Simon Glass
> ---
>
> arch/x86/cpu/intel_common/Makefile| 1 +
> arch/x86/cpu/intel_common/
On Fri, Mar 11, 2016 at 1:15 PM, Bin Meng wrote:
> On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
>> Many of the model-specific indexes are common to several Intel CPUs. Add
>> some more common ones, and remove them from the ivybridge-specific header
>> file.
>>
>> Signed-off-by: Simon Glass
On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
> This function was removed in the previous clean-up. Drop it from the header
> file also.
>
> Signed-off-by: Simon Glass
> ---
>
> arch/x86/include/asm/arch-ivybridge/sandybridge.h | 2 --
> 1 file changed, 2 deletions(-)
>
Reviewed-by: Bin M
Hi Simon,
On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
> Some of the Intel ME code is common to several Intel CPUs. Move it into a
> common location. Add a header file for report_platform.c also.
>
> Signed-off-by: Simon Glass
> ---
>
> arch/x86/cpu/intel_common/Makefile
On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
> This same name is used in USB. Add a prefix to distinguish it.
>
> Signed-off-by: Simon Glass
> ---
>
> arch/x86/cpu/cpu.c | 4 ++--
> arch/x86/cpu/intel_common/cpu_common.c | 4 ++--
> arch/x86/include/asm/processor.h
Hi Simon,
On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
> Some of the Intel CPU code is common to several Intel CPUs. Move it into a
> common location along with required declarations.
>
> Signed-off-by: Simon Glass
> ---
>
> arch/x86/cpu/intel_common/Makefile| 1 +
> arch/x86/c
On Fri, Mar 11, 2016 at 1:05 PM, Bin Meng wrote:
> Hi Simon,
>
> On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
>> Some of the LPC code is common to several Intel LPC devices. Move it into a
>> common location.
>>
>> Signed-off-by: Simon Glass
>> ---
>>
>> arch/x86/cpu/intel_common/Makefil
On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
> Many of the model-specific indexes are common to several Intel CPUs. Add
> some more common ones, and remove them from the ivybridge-specific header
> file.
>
> Signed-off-by: Simon Glass
> ---
>
> arch/x86/cpu/ivybridge/model_206ax.c
On Fri, Mar 11, 2016 at 12:32 PM, Bin Meng wrote:
> On Mon, Mar 7, 2016 at 10:27 AM, Simon Glass wrote:
>> This does not need to be modified at run-time, so make it const.
>>
>> Signed-off-by: Simon Glass
>> ---
>>
>> arch/x86/cpu/cpu.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>
On Fri, Mar 11, 2016 at 12:18 PM, Bin Meng wrote:
> On Mon, Mar 7, 2016 at 10:27 AM, Simon Glass wrote:
>> Output the pointer returned by each call to malloc(). This can be useful
>> when debugging memory problems.
>>
>> Signed-off-by: Simon Glass
>> ---
>>
>> common/malloc_simple.c | 7 +--
Hi Simon,
On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
> This code is used on several Intel CPUs. Move it into a common location.
>
> Signed-off-by: Simon Glass
> ---
>
> arch/x86/cpu/intel_common/Makefile | 3 +++
> arch/x86/cpu/intel_common/car.S
Hi Simon,
On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
> Some of the LPC code is common to several Intel LPC devices. Move it into a
> common location.
>
> Signed-off-by: Simon Glass
> ---
>
> arch/x86/cpu/intel_common/Makefile| 1 +
> arch/x86/cpu/intel_common/lpc_common.c
Hi Simon,
On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
> There are several blocks of registers that are accessed from all over the
> code on Intel CPUs. These don't currently have their own driver and it is
> not clear whether having a driver makes sense.
>
> An example is the Memory Contr
On Mon, Mar 7, 2016 at 10:27 AM, Simon Glass wrote:
> This cache-as-RAM (CAR) code is common to several Intel chips. Create a new
> intel_common directory and move it in there.
>
> Signed-off-by: Simon Glass
> ---
>
> arch/x86/cpu/Makefile | 1 +
> arch/x86/cpu/intel_com
On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
> This is similar to MCH in that it is used in various drivers. Add it to
> the common header.
>
> Signed-off-by: Simon Glass
> ---
>
> arch/x86/cpu/ivybridge/bd82x6x.c | 1 +
> arch/x86/cpu/ivybridge/lpc.c | 6 --
> a
Hi Simon,
On Mon, Mar 7, 2016 at 10:27 AM, Simon Glass wrote:
> These two identifiers can be useful for drivers which need to adjust their
> behaviour depending on the CPU family or stepping (revision).
>
> Signed-off-by: Simon Glass
> ---
>
> arch/x86/cpu/cpu.c | 10 ++
> arch/
On Mon, Mar 7, 2016 at 10:27 AM, Simon Glass wrote:
> This does not need to be modified at run-time, so make it const.
>
> Signed-off-by: Simon Glass
> ---
>
> arch/x86/cpu/cpu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Reviewed-by: Bin Meng
___
Hi Simon,
On Mon, Mar 7, 2016 at 10:27 AM, Simon Glass wrote:
> At present on x86 machines with use cache-as-RAM, the memory goes away just
> before board_init_r() is called. This means that serial drivers are
> no-longer unavailable, until initr_dm() it called, etc.
>
> Any attempt to use printf
On Mon, Mar 7, 2016 at 10:27 AM, Simon Glass wrote:
> Output the pointer returned by each call to malloc(). This can be useful
> when debugging memory problems.
>
> Signed-off-by: Simon Glass
> ---
>
> common/malloc_simple.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
Revie
Hi Simon,
On Mon, Mar 7, 2016 at 10:27 AM, Simon Glass wrote:
> Add one more step into the init sequence. This fixes the keyboard on samus,
> which otherwise does not work.
>
> Signed-off-by: Simon Glass
> ---
>
> drivers/input/i8042.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --gi
On Fri, Mar 11, 2016 at 11:46 AM, Bin Meng wrote:
> On Mon, Mar 7, 2016 at 10:27 AM, Simon Glass wrote:
>> It is common to read a config register value, clear and set some bits, then
>> write back the updated value. Add functions to do this in one step, for
>> convenience.
>>
>> Signed-off-by: Si
On Fri, Mar 11, 2016 at 11:46 AM, Bin Meng wrote:
> On Mon, Mar 7, 2016 at 10:27 AM, Simon Glass wrote:
>> Two comments are missing a parameter and there is an extra blank line. Also
>> two of the region access macros are misnamed. Correct these problems.
>>
>> Signed-off-by: Simon Glass
>> ---
On Fri, Mar 11, 2016 at 11:45 AM, Bin Meng wrote:
> On Mon, Mar 7, 2016 at 10:27 AM, Simon Glass wrote:
>> We can use GPIOs as binary digits for reading 'strapping' values. Each GPIO
>> is assigned a single bit and can be set high or low on the circuit board. We
>> already have a legacy function
On Fri, Mar 11, 2016 at 11:45 AM, Bin Meng wrote:
> On Mon, Mar 7, 2016 at 10:27 AM, Simon Glass wrote:
>> Some CPUs use microcode and each core can have a different version of
>> microcode loaded. Also some CPUs support the concept of an integer ID used
>> for identification purposes. Add suppor
On Mon, Mar 7, 2016 at 3:37 PM, Anatolij Gustschin wrote:
> Hi Simon,
>
> On Sun, 6 Mar 2016 19:27:48 -0700
> Simon Glass s...@chromium.org wrote:
>
>> At present simple-panel requires regulator support and will not build
>> without it. But some panels do not have a power supply, or at least not
On Fri, Mar 11, 2016 at 11:45 AM, Bin Meng wrote:
> On Mon, Mar 7, 2016 at 10:27 AM, Simon Glass wrote:
>> Some functions do not change the struct gpio_desc parameter. Update these to
>> use const so this is clear.
>>
>> Signed-off-by: Simon Glass
>> ---
>>
>> drivers/gpio/gpio-uclass.c | 10 ++
On 05/03/16 18:08, Anand Moon wrote:
> Enable CONFIG_USB_ETHER_RTL8152 support for Odroid XU4 which
> has support for RTL8153-CG gigabit Ethernet adapter,
> connected over USB 3.0.
>
> commit 9dc8ba19c50fc0b1623c654bcfe6caa903a4c36c added support
> for Realtek 8152/8153 driver.
>
> Signed-off-by:
On Mon, Mar 7, 2016 at 10:27 AM, Simon Glass wrote:
> Some CPUs use microcode and each core can have a different version of
> microcode loaded. Also some CPUs support the concept of an integer ID used
> for identification purposes. Add support for these in the CPU uclass.
>
> Signed-off-by: Simon
On Mon, Mar 7, 2016 at 10:27 AM, Simon Glass wrote:
> It is common to read a config register value, clear and set some bits, then
> write back the updated value. Add functions to do this in one step, for
> convenience.
>
> Signed-off-by: Simon Glass
> ---
>
> drivers/pci/pci-uclass.c | 57
> +++
On Mon, Mar 7, 2016 at 10:27 AM, Simon Glass wrote:
> We can use GPIOs as binary digits for reading 'strapping' values. Each GPIO
> is assigned a single bit and can be set high or low on the circuit board. We
> already have a legacy function for reading these values. Add one that
> supports driver
On Mon, Mar 7, 2016 at 10:27 AM, Simon Glass wrote:
> Some functions do not change the struct gpio_desc parameter. Update these to
> use const so this is clear.
>
> Signed-off-by: Simon Glass
> ---
>
> drivers/gpio/gpio-uclass.c | 10 +-
> include/asm-generic/gpio.h | 10 +-
> 2
On Mon, Mar 7, 2016 at 10:27 AM, Simon Glass wrote:
> Two comments are missing a parameter and there is an extra blank line. Also
> two of the region access macros are misnamed. Correct these problems.
>
> Signed-off-by: Simon Glass
> ---
>
> drivers/pci/pci-uclass.c | 1 -
> include/pci.h
Hi Simon,
On Mon, Mar 7, 2016 at 10:27 AM, Simon Glass wrote:
> If the device cannot be probed, syscon_get_by_driver_data() will still
> return a useful value in its devp parameter. Ensure that it returns NULL
> instead.
Shouldn't this be the caller's bug, that caller must check the return value
Hi Simon,
On Mon, Mar 7, 2016 at 10:27 AM, Simon Glass wrote:
> Commit 1057e6c broke use of the timer with driver model. If the timer is used
> before relocation, then it becomes broken after relocation. This prevents
> some x86 boards from booting. Fix it.
Isn't the broken due to gd not initial
On Mon, Feb 29, 2016 at 3:54 PM, Bin Meng wrote:
> Now that ACPI is supported on QEMU, enable it.
>
> Signed-off-by: Bin Meng
> Reviewed-by: Simon Glass
> ---
>
> Changes in v2: None
>
> configs/qemu-x86_defconfig | 1 +
> 1 file changed, 1 insertion(+)
>
applied to u-boot-x86/next, thanks!
__
On Mon, Feb 29, 2016 at 3:54 PM, Bin Meng wrote:
> Boting SeaBIOS is done via U-Boot's bootelf command. Document this.
>
> Signed-off-by: Bin Meng
> Reviewed-by: Simon Glass
>
> ---
>
> Changes in v2:
> - Drop patches which were already applied
> - Add more detailed information for testing QEMU/
On Tue, Mar 1, 2016 at 10:04 AM, Simon Glass wrote:
> On 29 February 2016 at 00:54, Bin Meng wrote:
>> SeaBIOS is an open source implementation of a 16-bit x86 BIOS.
>> It can run in an emulator or natively on x86 hardware with the
>> use of coreboot. With SeaBIOS's help, we can boot some OSes
>>
The stm_is_locked_sr() function is picked from Linux kernel. For reason
unknown, the 64bit data types used by the function and present in Linux
were replaced with 32bit unsigned ones, which causes trouble.
The testcase performed was done using ST M25P80 chip.
The command used was:
=> sf protect u
On Thu, Mar 10, 2016 at 3:46 PM, Steve Rae wrote:
> ... updated the subject line, was:
> Re: [U-Boot][PATCH v3 1/3] fastboot: OUT transaction length must be aligned
> to wMaxPacketSize
>
>
>>> -static unsigned int rx_bytes_expected(void)
>>> +static unsigned int rx_bytes_expected(unsigned int ma
On 03/10/2016 08:50 AM, Stefan Roese wrote:
Debugging has shown, that all USB hubs are being resetted twice while
USB scanning. This introduces additional delays and makes USB scanning
even more slow. Testing has shown that this 2nd USB hub reset doesn't
seem to be necessary.
This patch now remo
On 03/10/2016 08:50 AM, Stefan Roese wrote:
This patch removes 2 mdelay(200) calls from usb_hub_port_connect_change().
These delays don't seem to be necessary. At least not in my tests. Here
the number for a custom x86 Bay Trail board (not in mainline yet) with
a quite large and complex USB hub i
On 03/10/2016 08:50 AM, Stefan Roese wrote:
Start with a short USB hub reset delay of 10ms. This can be enough for
some configurations.
The 2nd delay at the of the loop is completely removed. Since the delay
hasn't been long enough, a longer delay time of 200ms is assigned. And
will be used in t
... updated the subject line, was:
Re: [U-Boot][PATCH v3 1/3] fastboot: OUT transaction length must be
aligned to wMaxPacketSize
On 15-02-24 02:28 AM, Lukasz Majewski wrote:
Hi Dileep,
OUT transactions must be aligned to wMaxPacketSize for each transfer,
or else transfer will not complete s
- add missing declaration
- update debug output format specifiers
Signed-off-by: Steve Rae
---
the checkpatch warning:
warning: cmd/mtdparts.c,1494: quoted string split across lines
is for the existing code; it is not introduced with this change...
cmd/mtdparts.c | 4 ++--
include/li
Enable MTD support on Cygnus and NSP boards.
Signed-off-by: Steve Rae
---
arch/arm/include/asm/arch-bcmcygnus/configs.h | 6 ++
arch/arm/include/asm/arch-bcmnsp/configs.h| 6 ++
2 files changed, 12 insertions(+)
diff --git a/arch/arm/include/asm/arch-bcmcygnus/configs.h
b/arch/arm
From: Jiandong Zheng
Add support for the iproc NAND, and enable on Cygnus and NSP boards.
Signed-off-by: Jiandong Zheng
Signed-off-by: Steve Rae
---
There was a previous attempt to implement this "iproc NAND"
(see: http://patchwork.ozlabs.org/patch/505399), however, due to the
amount of change
Configure the NAND device, define partition sizes, and create
the environment space for Cygnus and NSP boards.
Signed-off-by: Steve Rae
---
arch/arm/include/asm/arch-bcmcygnus/configs.h | 33 +++
arch/arm/include/asm/arch-bcmnsp/configs.h| 33
The Difrnce dit4350 tablet is a tiny tablet with a 4.3" 16:9 480x272 LCD,
A13 SoC, 512M RAM, 4G NAND, solomon systech ssd2532qn6 touchscreen at
i2c1 address 0x48, Memsic MXC622X accelerometer at i2c1 address 0x15 and
rtl8188etv wifi.
The dts file is identical to the one submitted to the upstream k
Hi,
On 10-03-16 16:50, Stefan Roese wrote:
This patch implements an optionally quasi static USB port configuration.
This is done by using an environment variable, that describes the ports
that shall be scanned at the next USB scans (usb start, usb reset).
The "usb_port_use" env variable is used
Hi,
On 10-03-16 16:50, Stefan Roese wrote:
Debugging has shown, that all USB hubs are being resetted twice while
USB scanning. This introduces additional delays and makes USB scanning
even more slow. Testing has shown that this 2nd USB hub reset doesn't
seem to be necessary.
This patch now remo
Hi,
On 10-03-16 16:50, Stefan Roese wrote:
In a system with a complex USB infrastrcture (many USB hubs), the
power-on delay of mininimum 1 second for each USB hub results in a quite
big USB scanning time. Many USB devices can deal with much lower
power-on delays. In my test system, even 10ms see
Hi,
On 10-03-16 16:50, Stefan Roese wrote:
On complex USB infrastructures, with many hubs and therefore many
(perhaps unconnected) ports, current U-Boot has a very long USB scanning
time. On my current custom x86 board, this time is over 20 seconds!!!
One of the biggest problems here is a 1 seco
1 - 100 of 148 matches
Mail list logo
