Hello York,
On Wed, 15 Jul 2015 13:32:30 -0700, York Sun
wrote:
>
>
> On 07/15/2015 01:29 PM, Simon Glass wrote:
> > Hi York,
> >
> > On 15 July 2015 at 14:25, York Sun wrote:
> >>
> >>
> >> On 07/15/2015 01:23 PM, Albert ARIBAUD wrote:
> >>> Hello York,
> >>>
> >>> On Wed, 15 Jul 2015 13:02:
Hi Vikas,
On 15.07.2015 23:14, Vikas MANOCHA wrote:
In addition can you please check the patch causing this instability on
socfpga. I don't like to bug you but to close this patchset, this info
& tests mentioned above seems to be required.
Okay. I'll try to find some time this week to do s
Update t4160/t4080 serdes according to latest reference manual rev2.
Signed-off-by: Shengzhou Liu
---
arch/powerpc/cpu/mpc85xx/t4240_serdes.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/t4240_serdes.c
b/arch/powerpc/cpu
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 fro
Fifo width could be different on different socs, e.g. stv0991 & altera soc
have different fifo width.
Signed-off-by: Vikas Manocha
---
Changes in v2: Rebased to master
arch/arm/dts/socfpga.dtsi |1 +
arch/arm/dts/stv0991.dts |1 +
drivers/spi/cadence_qspi.c |1 +
dri
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, particularly
if we are wo
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
---
Changes in v2: Rebased to master
drivers/spi/cadence_qspi_apb.c |6 --
1 file changed, 4 ins
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
---
Changes in v2: Rebased to master
drivers/spi/cadence_qspi_apb.c | 61 ++--
1 file ch
Signed-off-by: Vikas Manocha
---
Changes in v2: Rebased to master
drivers/spi/cadence_qspi_apb.c |9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
index d053407..1ae7edf 100644
--- a/drivers/spi/cadenc
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
Ch
> -Original Message-
> From: Sun York-R58495
> Sent: Thursday, July 16, 2015 2:06 AM
> To: Wang Dongsheng-B40534
> Cc: Jin Zhengxiong-R64188; Wang Huan-B18965; Zhao Chenhui-B35336; Zhang
> Zhuoyu-
> B46552; u-boot@lists.denx.de
> Subject: Re: [PATCH] arm/layerscape: Fix non-boot cpus can
On 07/15/2015 05:49 PM, Adrian Alonso wrote:
> * Add pmic pfuze300 support for imx7 and iMX6 DL/SL/SX SoC's
> * Implement power_pfuze300_init to be used in power_init_board
> callback function.
>
> Signed-off-by: Adrian Alonso
> Signed-off-by: Peng Fan
> ---
> drivers/power/pmic/Makefile
On 12 July 2015 at 22:17, Masahiro Yamada wrote:
>
> As you see in driver/Makefile, Kbuild descends into the driver/core/
> directory only when CONFIG_DM is enabled.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> Changes in v2:
> - Newly added
>
> drivers/core/Makefile | 2 +-
> 1 file changed,
* Extend imximage DCD version 2 to support DCD commands
CMD_WRITE_CLR_BIT 4 [address] [mask bit] means:
while ((*address & ~mask) != 0);
CMD_CHECK_BITS_SET 4 [address] [mask bit] means:
while ((*address & mask) != mask);
CMD_CHECK_BITS_CLR 4 [address] [mask bit] means:
*address =
Hi Rob,
On Fri, 10 Jul 2015, Rob Herring wrote:
> On Wed, Jul 8, 2015 at 10:57 AM, Peter Griffin
> wrote:
> > HiKey is the first 96boards consumer edition compliant board. It features a
> > hi6220
> > SoC which has eight ARM A53 cpu's.
> >
> > This initial port adds support for: -
> > 1) Seria
* Add pmic pfuze300 support for imx7 and iMX6 DL/SL/SX SoC's
* Implement power_pfuze300_init to be used in power_init_board
callback function.
Signed-off-by: Adrian Alonso
Signed-off-by: Peng Fan
---
drivers/power/pmic/Makefile| 1 +
drivers/power/pmic/pmic_pfuze300.c | 32 ++
* Add imx7d support for iomux controller
* Since mx7d introduces LPSR IOMUX pins, add new base to IOMUX v3
driver for these LPSR pins.
Signed-off-by: Adrian Alonso
Signed-off-by: Fugang Duan
Signed-off-by: Ye.Li
---
arch/arm/imx-common/iomux-v3.c | 20 ++-
arch/ar
* Add i.MX7D SABRESD board BSP codes, with enabled modules:
UART, PMIC, USB/OTG, SD, eMMC, ENET, I2C, 74LV IOX.
Build target: mx7dsabresd_config
Signed-off-by: Peng Fan
Signed-off-by: Fugang Duan
Signed-off-by: Ye.Li
Signed-off-by: Adrian Alonso
---
board/freescale/mx7dsabresd/Kconfig
* The system counter driver for imx7d abd mx6ul, move
this timer driver to imx-common and rename it as syscounter.c
For mx6ul and mx7, configurations are used for choose the GPT timer
or system counter timer (default).
GPT timer: CONFIG_GPT_TIMER
System counter timer: CON
* Ocotp of i.MX7D has different operation rule.
This patch is to add support for i.MX7D ocotp.
Signed-off-by: Adrian Alonso
Signed-off-by: Peng Fan
Signed-off-by: Ye.Li
---
drivers/misc/mxc_ocotp.c | 74 +++-
1 file changed, 73 insertions(+), 1 del
* Add mxc_gpio support for imx7d SoC
* Use CONFIG_MX7 to extend mxc gpio driver support for imx7d
Signed-off-by: Peng Fan
Signed-off-by: Adrian Alonso
---
drivers/gpio/mxc_gpio.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpio/mxc_gpio.c b/drivers/gpio/m
* Add support for usb driver for i.MX7D SoC
Signed-off-by: Adrian Alonso
Signed-off-by: Ye.Li
Signed-off-by: Peng Fan
---
drivers/usb/host/Makefile | 1 +
drivers/usb/host/ehci-mx7.c | 103
2 files changed, 104 insertions(+)
create mode 100644
* Add thermal driver support for imx7 SoC
read_cpu_temperature is SoC dependent
* Redefine config macro to support imx7 and imx6 SoC
Signed-off-by: Adrian Alonso
Signed-off-by: Peng Fan
---
arch/arm/imx-common/cpu.c | 10 ++--
drivers/thermal/Makefile | 2 +-
drivers/therm
Hi Sylvain,
On 15.07.2015 22:23, LEMIEUX, SYLVAIN wrote:
> Hi Vladimir and Albert,
>
> During this merge window (once our issues with our exchange server are
> resolve), we were planning on submitting a few patches for the LPC32xx.
great, feel free to add me to Cc.
> Some of the patches are th
On Wed, Jul 15, 2015 at 9:12 AM, Chris Packham wrote:
> On Wed, Jul 15, 2015 at 7:01 AM, Daniel Schwierzeck
> wrote:
>> Hi Chris,
>>
>> sorry for the delay.
>
> No problem. It only just occurred to me that it's probably peak
> holiday season for people in the northern hemisphere.
>
>> Am 14.07.20
The change adds support of LPC32xx SLC NAND controller.
LPC32xx SoC has two different mutually exclusive NAND controllers to
communicate with single and multiple layer chips.
This simple driver allows to specify NAND chip timings and defines
custom read_buf()/write_buf() operations, because acces
This changeset improves support of Timll DevKit3250 board:
* added LPC32xx MAC and SMSC RMII phy support, this dependends on
- http://patchwork.ozlabs.org/patch/489100/
- http://patchwork.ozlabs.org/patch/489190/
- http://patchwork.ozlabs.org/patch/491419/
- http://patchwork.ozlabs.org/patc
The change adds SPL build support to Timll DevKit3250 board, the
generated SPL image can be uploaded over UART5, JTAG or stored on
NAND. SPL is designed to load U-boot image from NAND.
All new NAND chip defines in board configuration are needed by
SPL NAND "simple" framework, the framework is used
This change adds more peripherals to Timll DevKit3250 board, namely
MAC and SMSC phy, SLC NAND, GPIO, SPI and I2C.
Also the default serial console is changed to UART5, added an option
to pass device tree blob by means of bootm, predefined environment
variables are slightly extended and reserved sp
Some NAND controllers define custom functions to read data out,
respect this in order to correctly support bad block handling in
simple SPL NAND framework.
NAND controller specific read_buf() is used even to read 1 byte in
case of connected 8-bit NAND device, it turns out that read_byte()
may beco
From: Jiandong Zheng
Enable BCM SF2 ethernet and PHY for BCM Cygnus SoC
Signed-off-by: Jiandong Zheng
Signed-off-by: Steve Rae
---
arch/arm/include/asm/arch-bcmcygnus/configs.h | 11 +++
board/broadcom/bcm_ep/board.c | 11 +++
2 files changed, 22 insertions(+)
Jiandong Zheng (2):
net: phy: broadcom: Add BCM Cygnus PHY
arm: bcmcygnus: Enable Ethernet support
arch/arm/include/asm/arch-bcmcygnus/configs.h | 11 ++
board/broadcom/bcm_ep/board.c | 11 ++
drivers/net/phy/broadcom.c| 29 ++
From: Jiandong Zheng
Add Ethernet PHY for BCM Cygnus SoC
Signed-off-by: Jiandong Zheng
Signed-off-by: Steve Rae
---
drivers/net/phy/broadcom.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
index 4512
Hi,
On 15 July 2015 at 02:42, Wang Haikun wrote:
> Hi Simon,
>
> It seems that we don't update the source image name to u-boot-dtb.bin in
> case of enabling CONFIG_OF_SEPARATE when generate u-boot-with-spl.bin file.
>
>
> ifdef CONFIG_TPL
> SPL_PAYLOAD := tpl/u-boot-with-tpl.bin
> else
> SPL_PAYL
Hi Stefan,
> -Original Message-
> From: Stefan Roese [mailto:s...@denx.de]
> Sent: Monday, July 13, 2015 2:01 AM
> To: Vikas MANOCHA
> Cc: u-boot@lists.denx.de; grmo...@opensource.altera.com;
> dingu...@opensource.altera.com; jt...@openedev.com
> Subject: Re: [PATCH RESEND 0/7] spi: cadenc
On Wed, Jul 15, 2015 at 02:12:15PM -0600, Stephen Warren wrote:
> On 07/15/2015 10:14 AM, Tom Rini wrote:
> >On Wed, Jul 15, 2015 at 09:54:41AM -0600, Simon Glass wrote:
> >>Hi Stephen,
> >>
> >>On 15 July 2015 at 09:50, Stephen Warren wrote:
> >>>On 07/14/2015 05:33 PM, Tom Rini wrote:
>
> >
On 07/15/2015 01:29 PM, Simon Glass wrote:
> Hi York,
>
> On 15 July 2015 at 14:25, York Sun wrote:
>>
>>
>> On 07/15/2015 01:23 PM, Albert ARIBAUD wrote:
>>> Hello York,
>>>
>>> On Wed, 15 Jul 2015 13:02:07 -0700, York Sun
>>> wrote:
Simon,
Did it happen to you with this warnin
On Wed, Jul 15, 2015 at 7:06 AM, Chris Packham wrote:
> To make it easier to use patman on other projects add a distutils style
> installer. Now patman can be installed with
>
> cd u-boot/tools/patman && python setup.py install
>
> There are also the usual distutils options for creating source/b
Hi York,
On 15 July 2015 at 14:25, York Sun wrote:
>
>
> On 07/15/2015 01:23 PM, Albert ARIBAUD wrote:
>> Hello York,
>>
>> On Wed, 15 Jul 2015 13:02:07 -0700, York Sun
>> wrote:
>>> Simon,
>>>
>>> Did it happen to you with this warning?
>>>
>>> lib/fdtdec.c:108:4: warning: format ‘%x’ expects a
fdt_addr_t and fdt_size_t can be either 64-bit or 32-bit, depending
on the architecture. Change the type to phys_addr_t and phys_size_t.
Signed-off-by: York Sun
---
include/fdtdec.h |7 +++
lib/fdtdec.c |4 ++--
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/inclu
On 07/15/2015 01:23 PM, Albert ARIBAUD wrote:
> Hello York,
>
> On Wed, 15 Jul 2015 13:02:07 -0700, York Sun
> wrote:
>> Simon,
>>
>> Did it happen to you with this warning?
>>
>> lib/fdtdec.c:108:4: warning: format ‘%x’ expects argument of type ‘unsigned
>> int’, but argument 3 has type ‘fdt_s
Hello York,
On Wed, 15 Jul 2015 13:02:07 -0700, York Sun
wrote:
> Simon,
>
> Did it happen to you with this warning?
>
> lib/fdtdec.c:108:4: warning: format ‘%x’ expects argument of type ‘unsigned
> int’, but argument 3 has type ‘fdt_size_t’ [-Wformat=]
> debug("addr=%08lx, size=%08x\n",
>
Hello SYLVAIN,
On Wed, 15 Jul 2015 19:23:33 +, LEMIEUX, SYLVAIN
wrote:
> Hi Vladimir and Albert,
>
> During this merge window (once our issues with our exchange server
> are resolve), we were planning on submitting a few patches for the
> LPC32xx.
>
> Some of the patches are the porting of
On 07/15/2015 10:14 AM, Tom Rini wrote:
On Wed, Jul 15, 2015 at 09:54:41AM -0600, Simon Glass wrote:
Hi Stephen,
On 15 July 2015 at 09:50, Stephen Warren wrote:
On 07/14/2015 05:33 PM, Tom Rini wrote:
On Tue, Jul 14, 2015 at 04:39:01PM -0600, Stephen Warren wrote:
On 07/14/2015 04:09 PM,
Simon,
Did it happen to you with this warning?
lib/fdtdec.c:108:4: warning: format ‘%x’ expects argument of type ‘unsigned
int’, but argument 3 has type ‘fdt_size_t’ [-Wformat=]
debug("addr=%08lx, size=%08x\n",
^
I think when we have 64-bit physical address, as defined in fdtdec.h, this
Hi Vladimir and Albert,
During this merge window (once our issues with our exchange server are
resolve), we were planning on submitting a few patches for the LPC32xx.
Some of the patches are the porting of the legacy NXP BSP (u-boot) drivers into
the latest version; the drivers are the DMA, the
hi joe,
maybe my email got lost ...
best regards,
Hannes
On 2015-06-22 14:23, Hannes Schmelzer wrote:
Hi joe,
you did introduce callbacks on setting up ip,dns, ... in net.c
Why it did become necessary to do following ?
if (flags & H_PROGRAMMATIC)
return 0;
I have act
Hi Vladimir & Albert,
As stated before, I tested this patch and the 3 patches listed below using a
Micrel KSZ8031RNL phy connected over RMII. Everything is working properly.
1) http://patchwork.ozlabs.org/patch/489100/
2) http://patchwork.ozlabs.org/patch/489190/
3) http://patchwork.ozlabs.org/pa
Hi Vitaly,
On Wed, Jul 8, 2015 at 10:56 AM, Vitaly Andrianov wrote:
> The MCAST_TFTP support requires that network drivers has mcast functon
> implemented. This commit adds dummy keystone2_eth_bcast_addr() to meet
> the requirement. As far as the driver doesn't use ALE and doesn't filter
> any in
Hi Lukasz,
On Sun, Jul 12, 2015 at 10:30 AM, Lukasz Majewski wrote:
> The new 'dfutftp' command has syntax similar to 'dfu' command.
> This new command however, requires some extra env variables to allow
> update_tftp() code to work properly. For more explanation, please consult
> ./doc/README.df
Hi Lukasz,
On Sun, Jul 12, 2015 at 10:30 AM, Lukasz Majewski wrote:
> This code allows using DFU defined mediums for storing data received via
> TFTP protocol.
>
> It reuses legacy code at common/update.c.
>
> To run update_tftp() during boot one needs to define
> "update_tftp_exec_at_boot=true".
Hi Lukasz,
On Sun, Jul 12, 2015 at 10:30 AM, Lukasz Majewski wrote:
> This function allows writing via DFU data stored from fixed buffer address
> (like e.g. loadaddr env variable).
>
> Such predefined buffers are used in the update_tftp() code. In fact this
> function is a wrapper on the dfu_wri
Hi Lukasz,
On Sun, Jul 12, 2015 at 10:30 AM, Lukasz Majewski wrote:
> This commit adds initial support for using tftp for downloading and
> upgrading firmware on the device.
>
> Signed-off-by: Lukasz Majewski
> ---
> drivers/dfu/Makefile | 1 +
> drivers/dfu/dfu_tftp.c | 76
> ++
Hi Lukasz,
On Sun, Jul 12, 2015 at 10:30 AM, Lukasz Majewski wrote:
> Up till now it was impossible to use code from update.c when system
> was not equipped with raw FLASH memory.
> Such behavior prevented DFU from reusing this code.
>
> Signed-off-by: Lukasz Majewski
> ---
Acked-by: Joe Hershb
Hi Lukasz,
On Sun, Jul 12, 2015 at 10:30 AM, Lukasz Majewski wrote:
> This change gives the ability to reuse the header file by other
> subsystems (like e.g. dfu).
>
> Without this change compilation error emerges for the legacy update.c file.
>
> Signed-off-by: Lukasz Majewski
> ---
> common/
Hi Lukasz,
On Sun, Jul 12, 2015 at 10:30 AM, Lukasz Majewski wrote:
> Documentation file for DFU extension. With this functionality it is now
> possible to transfer FIT images with firmware updates via TFTP and use
> DFU backend for storing them.
>
> Signed-off-by: Lukasz Majewski
> ---
> doc/R
On 07/14/2015 12:09 AM, Wang Dongsheng-B40534 wrote:
> Hi Alison & Jason,
>
> Could you ACK this patch?
>
> Regards,
> -Dongsheng
>
>> -Original Message-
>> From: Dongsheng Wang [mailto:dongsheng.w...@freescale.com]
>> Sent: Thursday, June 18, 2015 6:33 PM
>> To: Sun York-R58495
>> Cc: J
Hi Stephen,
On 15 July 2015 at 10:28, Stephen Warren wrote:
> On 07/15/2015 09:54 AM, Simon Glass wrote:
>>
>> Hi Stephen,
>>
>> On 15 July 2015 at 09:50, Stephen Warren wrote:
>>>
>>> On 07/14/2015 05:33 PM, Tom Rini wrote:
On Tue, Jul 14, 2015 at 04:39:01PM -0600, Stephen Warren
Hi Simon,
On Thu, Jul 9, 2015 at 9:15 AM, Simon Glass wrote:
> With driver model drivers can have things stored in several places. There is
> driver-private data, then the uclass can attach things to a device. If the
> device is on a bus then its bus may attach parent data to the device too.
>
>
On 07/15/2015 09:54 AM, Simon Glass wrote:
Hi Stephen,
On 15 July 2015 at 09:50, Stephen Warren wrote:
On 07/14/2015 05:33 PM, Tom Rini wrote:
On Tue, Jul 14, 2015 at 04:39:01PM -0600, Stephen Warren wrote:
On 07/14/2015 04:09 PM, Tom Rini wrote:
On Tue, Jul 14, 2015 at 02:11:25PM -0600,
On Wed, Jul 15, 2015 at 09:54:41AM -0600, Simon Glass wrote:
> Hi Stephen,
>
> On 15 July 2015 at 09:50, Stephen Warren wrote:
> > On 07/14/2015 05:33 PM, Tom Rini wrote:
> >>
> >> On Tue, Jul 14, 2015 at 04:39:01PM -0600, Stephen Warren wrote:
> >>>
> >>> On 07/14/2015 04:09 PM, Tom Rini wrote:
Hi Stephen,
On 15 July 2015 at 09:50, Stephen Warren wrote:
> On 07/14/2015 05:33 PM, Tom Rini wrote:
>>
>> On Tue, Jul 14, 2015 at 04:39:01PM -0600, Stephen Warren wrote:
>>>
>>> On 07/14/2015 04:09 PM, Tom Rini wrote:
On Tue, Jul 14, 2015 at 02:11:25PM -0600, Stephen Warren wrote:
>>>
On 07/14/2015 05:33 PM, Tom Rini wrote:
On Tue, Jul 14, 2015 at 04:39:01PM -0600, Stephen Warren wrote:
On 07/14/2015 04:09 PM, Tom Rini wrote:
On Tue, Jul 14, 2015 at 02:11:25PM -0600, Stephen Warren wrote:
On 07/14/2015 11:56 AM, Tom Rini wrote:
Hey all,
I've pushed v2015.07 out to the rep
On 07/14/2015 05:37 PM, Simon Glass wrote:
Hi Stephen,
On 14 July 2015 at 17:27, Stephen Warren wrote:
On 07/14/2015 05:07 PM, Simon Glass wrote:
Hi Stephen,
On 14 July 2015 at 16:39, Stephen Warren wrote:
On 07/14/2015 04:09 PM, Tom Rini wrote:
On Tue, Jul 14, 2015 at 02:11:25PM -06
Hi Tom,
On 14 July 2015 at 17:33, Tom Rini wrote:
>
> On Tue, Jul 14, 2015 at 04:39:01PM -0600, Stephen Warren wrote:
> > On 07/14/2015 04:09 PM, Tom Rini wrote:
> > >On Tue, Jul 14, 2015 at 02:11:25PM -0600, Stephen Warren wrote:
> > >>On 07/14/2015 11:56 AM, Tom Rini wrote:
> > >>>Hey all,
> >
Hi Anton,
On Wed, Jul 15, 2015 at 05:00:21PM +0200, Anton Schubert wrote:
> My Patch isn't necessary anymore and as Stefan said potentially breaking on
> other chip versions.
I think everything is merged correctly as was intended. Please check.
Luka
__
Hi Luka
2015-07-15 17:04 GMT+02:00 Luka Perkov :
> I think everything is merged correctly as was intended. Please check.
>
Is correct.
Thanks, Anton
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Hi Anton, hi Stefan,
On Wed, Jul 15, 2015 at 04:47:55PM +0200, Anton Schubert wrote:
> Hi Stefan,
>
> Your timer patch fixes the booting problems for me so this delay isn't
> necessary anymore.
I've pushed the two patches from you guys to marvell/master:
http://git.denx.de/?p=u-boot/u-boot-marv
Tested-by: Anton Schubert
Tested on custom mv78260 board.
Anton
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Hi Luka,
My Patch isn't necessary anymore and as Stefan said potentially breaking on
other chip versions.
Anton
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Hi Luka,
On 15.07.2015 16:56, Luka Perkov wrote:
On Wed, Jul 15, 2015 at 04:47:55PM +0200, Anton Schubert wrote:
Hi Stefan,
Your timer patch fixes the booting problems for me so this delay isn't
necessary anymore.
I've pushed the two patches from you guys to marvell/master:
http://git.denx.
Hi Stefan,
Your timer patch fixes the booting problems for me so this delay isn't
necessary anymore.
Thanks,
Anton
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Hi Tom,
Here's the first pull request for x86. It includes fixes and improvements
with PCI, multi-core init, Intel FSP init and adds graphics support for
crownbay.
The following changes since commit f4815763b410d8657f6f617067a1d53024b05220:
RFC: Deprecate MAKEALL (2015-07-14 13:50:16 -0400)
a
OMAP devices might boot from peripheral devices, such as UART or USB.
When that happens, the U-Boot SPL tries to boot the next stage (complete U-Boot)
from that peripheral device, but in most cases, this is not a valid boot device.
This introduces a fallback option that reads the SYS_BOOT pins, th
With commit e3a77218a256edbe201112a39beeed8adcabae3f the MII bus is only
reset if a reset handler is registered. If there is no reset handler there
is no need to wait for a device to come out of the reset.
Signed-off-by: Jörg Krause
---
drivers/net/phy/phy.c | 8 +---
1 file changed, 5 inser
The config file for the siemens-am33x-common was using OMAP_I2C_STANDARD, which
is defined in a header that is not included in the config header. In most cases,
it was being included by the code using CONFIG_SYS_OMAP24_I2C_SPEED, but it
might not always be the case.
In particular, when introducing
This introduces code to read the value of the SYS_BOOT pins on the OMAP5, as
well as the memory-preferred scheme for the interpretation of each value.
Signed-off-by: Paul Kocialkowski
---
arch/arm/cpu/armv7/omap5/Makefile | 1 +
arch/arm/cpu/armv7/omap5/boot.c | 46 +++
This introduces code to read the value of the SYS_BOOT pins on the OMAP3, as
well as the memory-preferred scheme for the interpretation of each value.
Signed-off-by: Paul Kocialkowski
---
arch/arm/cpu/armv7/omap3/Makefile | 1 +
arch/arm/cpu/armv7/omap3/boot.c | 58 +++
This introduces code to read the value of the SYS_BOOT pins on the OMAP4, as
well as the memory-preferred scheme for the interpretation of each value.
Signed-off-by: Paul Kocialkowski
---
arch/arm/cpu/armv7/omap4/Makefile| 1 +
arch/arm/cpu/armv7/omap4/boot.c | 60 +
This cleans up the SPL boot devices for omap platforms and introduces support
for missing boot devices.
Signed-off-by: Paul Kocialkowski
---
arch/arm/include/asm/arch-am33xx/spl.h | 94 +++---
arch/arm/include/asm/arch-omap3/spl.h | 18 ---
arch/arm/include/asm/a
Now that SPL boot devices are clearly defined, we can use BOOT_DEVICE_QSPI_4
instead of a hardcoded value.
Signed-off-by: Paul Kocialkowski
---
arch/arm/cpu/armv7/omap-common/boot-common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/boot
phy_id is declared as u32 in create_phy_by_mask and in struct phy_device.
Signed-off-by: Jörg Krause
---
drivers/net/phy/phy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index c8d08e8..865abab 100644
--- a/drivers/net/phy/phy
This introduces OMAP3 support for the common omap boot code, as well as a
major cleanup of the common omap boot code.
First, the omap_boot_parameters structure becomes platform-specific, since its
definition differs a bit across omap platforms. The offsets are removed as well
since it is U-Boot's
Changes since v4:
* Take care of BOOT_DEVICE_USBETH and don't use the fallback when it's defined
and active. This way, we can have both BOOT_DEVICE_USBETH and BOOT_DEVICE_USB
defined to the same value and use USB eth or not based on
CONFIG_SPL_USBETH_SUPPORT.
* boot_params casting clarificati
Le mardi 14 juillet 2015 à 13:32 +0200, Lukasz Majewski a écrit :
> Hi Paul,
>
> > Le mardi 14 juillet 2015 à 12:22 +0200, Lukasz Majewski a écrit :
> > > Hi Paul,
> > >
> > > > This avoids handling requests that have an error status or no
> > > > data. In particular, this avoids showing unnecess
Without calling timer_init(), the xdelay() functions return immediately.
We need to call timer_init() early, so that these functions work and
the PHY and DDR init code works correctly.
Signed-off-by: Stefan Roese
Cc: Anton Schubert
Cc: Luka Perkov
---
arch/arm/mach-mvebu/spl.c | 2 ++
arch/a
Hi Anton,
On 15.07.2015 11:12, Anton Schubert wrote:
The mv78260 needs atleast 10ms after setting the ddr3 training patterns
s/atleast/at least
or else the cpu will hang.
Is this documented somewhere? Or just a value from your experiments / tests?
This patch increases said delay to 20ms
Hi Wolfgang,
On Wed, Jul 15, 2015 at 8:35 PM, Wolfgang Denk wrote:
> Dear Bin,
>
> In message
> you
> wrote:
>>
>> Is the U-Boot mailing list hosted on the same machine as git? Will
>> this move also fix the mailing list occasional hiccup issue?
>
> Yes, at the moment this is on the same, old
Hi!
I'm with Freescale and we are currently working on bringing up a ARM64
SOC platform.
The PCIe module is similar with the one used by the iMX family, being
a Synopsys IP.
However there are many differences in terms of the SOC integration
(clocking, pin muxing, control registers) plus an additio
Hello Stefan,
On Wed, 15 Jul 2015 14:36:16 +0200, Stefan Agner
wrote:
> >> As far as I see we have these two patches which fix Vybrid booting:
> >>
> >> - one which changes the boot_data_t /size/ which keeps the offset
> >> of dcd_v2_t and the image aligned.
> >>
> >> - one which changes the d
Le mardi 07 juillet 2015 à 14:24 +0200, Paul Kocialkowski a écrit :
> FASTBOOT is defined both by CONFIG_USB_FUNCTION_FASTBOOT AND
> CONFIG_CMD_FASTBOOT, so it doesn't
> make much sense to have a CONFIG_USB_FASTBOOT prefix for fastboot-specific
> options, especially
> given that other config opti
Hi Anton,
On Wed, Jul 15, 2015 at 02:25:52PM +0200, Stefan Roese wrote:
> The first minor comment is, to better move the patch history (Changes in
> v2:...) below this line "---". The revision comments will then not be added
> to the git repository. This is common practice.
I would also like to a
Le jeudi 02 juillet 2015 à 00:20 +0200, Paul Kocialkowski a écrit :
> Palmas power support is required for OMAP5 devices such as the OMAP5 uEVM,
> that
> need to e.g. enable MMC power at SPL stage.
>
> This is especially important when booting from a peripheral (such as USB,
> UART),
> where the
Dear Thomas,
In message <593aef6c47f46446852b067021a273d6fbc78...@mucse037.lantiq.com> you
wrote:
>
> I tried to find a way to download a file with wget or a similar tool, which
> would be used by a distribution builder (like Yocto, Buildroot, OpenWrt, ...).
Why would any build environment us
This patch initializes the SATA address windows on Armada XP and
allows it to work with the existing mvsata_ide driver.
It also adds the necessary configuration for the db-mv784mp-gp board.
Signed-off-by: Anton Schubert
Tested-by: Stefan Roese
Cc: Luka Perkov
---
Changes v3:
- fix config forma
On 2015-07-15 13:44, Albert ARIBAUD wrote:
> Hello Stefan (and sorry for the duplicate),
>
> On Wed, 15 Jul 2015 12:41:59 +0200, Stefan Agner
> wrote:
>> Hi Albert,
>>
>> On 2015-07-15 09:54, Albert ARIBAUD wrote:
>> > Hello Stefano,
>> >
>> > On Wed, 15 Jul 2015 09:19:55 +0200, Stefano Babic
>>
Dear Bin,
In message
you wrote:
>
> Is the U-Boot mailing list hosted on the same machine as git? Will
> this move also fix the mailing list occasional hiccup issue?
Yes, at the moment this is on the same, old and slow machine.
We will move services one by one, the mailing lists are next after
Hi Anton,
On 15.07.2015 14:03, Anton Schubert wrote:
This patch initializes the SATA address windows on Armada XP and
allows it to work with the existing mvsata_ide driver.
It also adds the necessary configuration for the db-mv784mp-gp board.
Changes v2:
- add second bus offset
- only allow
This patch initializes the SATA address windows on Armada XP and
allows it to work with the existing mvsata_ide driver.
It also adds the necessary configuration for the db-mv784mp-gp board.
Changes v2:
- add second bus offset
- only allow one device per bus
- enable CONFIG_CMD_IDE per default
1/2: refactors a little because NDS32 actually need not the symbolic link
2/2: introduce a new config to avoid broken symbolic links.
Masahiro Yamada (2):
nds32: include instead of
kbuild: create symbolic link only for ARM, AVR32, SPARC, PowerPC, x86
arch/Kconfig | 7 +
1 - 100 of 157 matches
Mail list logo
