Hi Otavio, hi Fabio,
On 25/11/2013 17:21, Otavio Salvador wrote:
> On Mon, Nov 25, 2013 at 1:54 PM, Fabio Estevam
> wrote:
>> Currently the booting of a 3.10 kernel fails, as explained by Jason Liu [1]:
>>
>> "Let me explain it:
>> since we defined the fdt_high=0x at
>> include/configs/m
Existing eSDHC SPL framework assumes booting from sd-image
with boot_format header which contains final u-boot Image
offset and size. No such header is present in case of
corenet devices like T1040 as corenet deivces use PBI-RCW
based intialization.
So, for corenet deives, SPL bootloader use value
Existing eSPI SPL framework assumes booting from spi-image
with boot_format header which contains final u-boot Image
offset and size. No such header is present in case of
corenet devices like T1040 as corenet deivces use PBI-RCW
based intialization.
So, for corenet deives, SPL bootloader use value
Before this commit, output files under tpl/ directry
were not ignored.
This commit fixes this problem.
And we have only one source file under spl/ directory:
spl/Makefile
So, we can describe .gitignore more simply.
Signed-off-by: Masahiro Yamada
---
Changes in v2:
- Fix my weird English in
Hello Wolfgang
> > Could you resend
> > http://patchwork.ozlabs.org/patch/292309/
> > in a correct format?
> >
> > (Or Tom can directly pick it from the ML?)
>
> Of course I can. Does this patch solve the problem for you?
Yes. It worked for me. Thanks.
(And applied to u-boot/master)
It's OK
MSTPRI0 (Master Priority 0 Register) sits at 0x01C14110 not at
0x01C14114
Signed-off-by: Viktar Palstsiuk
---
arch/arm/include/asm/arch-davinci/hardware.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/arch-davinci/hardware.h
b/arch/arm/include/asm/ar
This patch fixes allow for the DeviceTree and initrd relocation fixing
the boot of FSL 3.10.9-1.0.0-alpha kernel.
This changes following boards:
- mx6sabreauto
- mx6sabresd
- wandboard
- udoo
- nitrogen6x
- cgtqmx6eval
The reasoning, as explained by Hui Liu, is:
,
| The FDT blob will
This patch adds support for TMU on Exynos5260
Register bit fields are little different from the previous
versions.
Change-Id: Ibe835abe9cb255d2f8375c8e9e32d32cff19c093
Signed-off-by: Naveen Krishna Chatradhi
---
arch/arm/include/asm/arch-exynos/tmu.h | 11 +++
drivers/power/exynos-tmu.
On Tue, Nov 26, 2013 at 10:11 AM, Tom Rini wrote:
> On Tue, Nov 26, 2013 at 09:06:27AM -0200, Otavio Salvador wrote:
>
>> This patch fixes allow for the DeviceTree and initrd relocation fixing
>> the boot of FSL 3.10.9-1.0.0-alpha kernel.
>>
>> This changes following boards:
>>
>> - mx6sabreauto
On Tue, Nov 26, 2013 at 09:06:27AM -0200, Otavio Salvador wrote:
> This patch fixes allow for the DeviceTree and initrd relocation fixing
> the boot of FSL 3.10.9-1.0.0-alpha kernel.
>
> This changes following boards:
>
> - mx6sabreauto
> - mx6sabresd
> - wandboard
> - udoo
> - nitrogen6x
>
Ping!
On 11/07/2013 07:57 AM, Ilya Ledvich wrote:
This patch series adds support for the Compulab CM-T335 board.
The board is based on TI Sitara AM3352/4 SoC and provides folowing features:
- 128MB to 512MB DDR3
- 128MB to 1GB NAND as a main storage
- Micro SD/MMC card as a secondary stora
I currently need support for rsa-sha256 signatures in u-boot and found out that
the code for signatures is not very generic. Thus adding of different
hash-algorithms for rsa-signatures is not easy to do without copy-pasting the
rsa-code. I attached a patch for how I think it could be better and inc
Commit v2013.10-189-gb3a7f22 breaks u-boot on the VExpress TC2, since
the hardcoded value for SP804 timer address is wrong on Versatile
Express boards using the extended memory map.
Replace this value with an existing macro make it work on both sets of
machines.
Signed-off-by: Andre Przywara
---
Hello,
last days I've been trying to isolate the hung cause of a customer
board, and also SabreSD board, when using the Freescale's Linux fork
of 3.10.9 with 2013.10 U-Boot.
The below patch makes it work fine but it does not seem to be possible
to upstream this fix, that way. How you guys thing t
On Tue, Nov 26, 2013 at 12:22:19PM +0530, Lokesh Vutla wrote:
> Hi Chao,
> On Tuesday 26 November 2013 10:32 AM, Chao Xu wrote:
> > Thank you! Please see the inline reply.
> >
> > On Mon, Nov 25, 2013 at 10:40 PM, Lokesh Vutla wrote:
> >> Hi,
> >> On Tuesday 26 November 2013 09:55 AM, Abraham V.
On 11/21/2013 09:59 AM, Marc Zyngier wrote:
Having the switch to non-secure in the "prep" phase is causing
all kind of troubles, as that stage can be called multiple times.
Instead, move the switch to non-secure to the last possible phase,
when there is no turning back anymore.
Tested on Versa
Hi Otavio,
Le Tue, 26 Nov 2013 12:32:45 -0200,
Otavio Salvador a écrit :
> Hello,
>
> last days I've been trying to isolate the hung cause of a customer
> board, and also SabreSD board, when using the Freescale's Linux fork
> of 3.10.9 with 2013.10 U-Boot.
>
> The below patch makes it work fin
On 11/21/2013 09:59 AM, Marc Zyngier wrote:
A CP15 instruction execution can be reordered, requiring an
isb to be sure it is executed in program order.
Makes sense ;-) and works on the VExpress TC2.
Albert, Tom, please apply for v2014.01.
Acked-by: Andre Przywara
Signed-off-by: Marc Zyngie
On 11/21/2013 09:59 AM, Marc Zyngier wrote:
Before switching to non-secure, make sure that CNTVOFF is set
to zero on all CPUs. Otherwise, kernel running in non-secure
without HYP enabled (hence using virtual timers) may observe
timers that are not synchronized, effectively seeing time
going backw
On 26/11/13 14:41, Andre Przywara wrote:
> On 11/21/2013 09:59 AM, Marc Zyngier wrote:
>> Before switching to non-secure, make sure that CNTVOFF is set
>> to zero on all CPUs. Otherwise, kernel running in non-secure
>> without HYP enabled (hence using virtual timers) may observe
>> timers that are
Removed code works properly only once after power-up because on every
"first" invocation of "dwmci_init" existing value of "fifo_size" is used
for calculation of itself. More over other bits in the same register
(namely TX watermark and burst size) get corrupted (lost forever till
the next power-to
Dear Tom,
In message <20131125215854.GW420@bill-the-cat> you wrote:
>
> I've put v2014.01-rc1 out and and we should have a tarball out soon.
The tarball is on the FTP server.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Muni
Dear Otavio,
In message
you wrote:
>
> last days I've been trying to isolate the hung cause of a customer
> board, and also SabreSD board, when using the Freescale's Linux fork
> of 3.10.9 with 2013.10 U-Boot.
Do I understand correctly that this happens only with the FSL kernel,
i. e. not with
On Tue, Nov 26, 2013 at 12:39 PM, Eric Bénard wrote:
> Hi Otavio,
>
> Le Tue, 26 Nov 2013 12:32:45 -0200,
> Otavio Salvador a écrit :
>
>> Hello,
>>
>> last days I've been trying to isolate the hung cause of a customer
>> board, and also SabreSD board, when using the Freescale's Linux fork
>> of
On Tue, Nov 26, 2013 at 1:39 PM, Wolfgang Denk wrote:
> Dear Otavio,
>
> In message
> you
> wrote:
>>
>> last days I've been trying to isolate the hung cause of a customer
>> board, and also SabreSD board, when using the Freescale's Linux fork
>> of 3.10.9 with 2013.10 U-Boot.
>
> Do I understa
Le Tue, 26 Nov 2013 13:59:36 -0200,
Otavio Salvador a écrit :
> > Do you also get the kernel freeze without changing anything in
> > u-boot when you disable cpufreq in the kernel ?
>
> The FSL kernel does not build without cpufreq so I didn't try.
>
check if your regulator settings is not defaul
On Tue, Nov 26, 2013 at 2:09 PM, Eric Bénard wrote:
> Le Tue, 26 Nov 2013 13:59:36 -0200,
> Otavio Salvador a écrit :
>> > Do you also get the kernel freeze without changing anything in
>> > u-boot when you disable cpufreq in the kernel ?
>>
>> The FSL kernel does not build without cpufreq so I d
This series fixes a few issues with the MIPS Malta board. The first 2
patches correct the handling of the UART baudrate and allow Linux to
correctly inherit that used by U-boot. The third patch enables an
interrupt which Linux relies upon but does not enable itself. I will
submit a patch to Linux i
The baudrate passed to Linux in the environment was hardcoded at 38400.
Instead pass the correct baudrate from global data, allowing Linux to
correctly inherit the baudrate used by U-boot when console setup is not
explicitly specified.
Signed-off-by: Paul Burton
---
arch/mips/lib/bootm.c | 6 +++
Whilst U-boot does not require this itself, Linux currently relies upon
it having been muxed and enabled by the bootloader. Thus in order to
preserve compatibility with current kernels before a fix is merged in
Linux we will enable the SERIRQ interrupt and mux it to its pin.
Without doing this cur
Allow a larger kernel binary to be decompressed - the default 8MB can
become limiting on a Malta.
Signed-off-by: Paul Burton
---
include/configs/malta.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/configs/malta.h b/include/configs/malta.h
index 666cca9..cc574ed 100644
--- a/inclu
CONFIG_SYS_NS16550_CLK specifies the rate of the clock 16x the baud
rate. The SMSC FDC37M81x datasheet states that a divider of 1 results in
a UART at 115200 baud, thus the x16 clock rate is 115200 * 16.
Previously the divider was left at 0 which led to a rate of 38400 baud
regardless of CONFIG_BAU
2013/11/26 Paul Burton :
> This series fixes a few issues with the MIPS Malta board. The first 2
> patches correct the handling of the UART baudrate and allow Linux to
> correctly inherit that used by U-boot. The third patch enables an
> interrupt which Linux relies upon but does not enable itself.
On Sun, Nov 24, 2013 at 11:46 PM, Lokesh Vutla wrote:
> On Friday 22 November 2013 01:56 AM, Vaibhav Bedia wrote:
>> On Thu, Nov 21, 2013 at 1:18 AM, Lokesh Vutla wrote:
>> [...]
>>> #define NON_SECURE_SRAM_START 0x402F0400
>>> #define NON_SECURE_SRAM_END0x4034
>>> #define SRAM_SCRATC
On Sun, Nov 24, 2013 at 11:48 PM, Lokesh Vutla wrote:
> On Friday 22 November 2013 01:58 AM, Vaibhav Bedia wrote:
>> On Thu, Nov 21, 2013 at 1:18 AM, Lokesh Vutla wrote:
>> [...]
>>> +#ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
>>> + char safe_string[HDR_NAME_LEN + 1];
>>> + struct am
Hi Tom,
please pull some additional fixes for MIPS malta board, thanks.
The following changes since commit d19ad726bcd5d9106f7ba9c750462fcc369f1020:
Prepare v2014.01-rc1 (2013-11-25 16:49:32 -0500)
are available in the git repository at:
git://git.denx.de/u-boot-mips.git master
for you to
On Sun, Nov 24, 2013 at 11:53 PM, Lokesh Vutla wrote:
> On Friday 22 November 2013 02:01 AM, Vaibhav Bedia wrote:
>> On Thu, Nov 21, 2013 at 1:18 AM, Lokesh Vutla wrote:
>>> Selecting the Master osc clk as Timer2 clock source.
>>>
>>> Signed-off-by: Lokesh Vutla
>>> ---
>>> arch/arm/cpu/armv7/a
On Sun, Nov 24, 2013 at 11:59 PM, Lokesh Vutla wrote:
> On Friday 22 November 2013 02:04 AM, Vaibhav Bedia wrote:
>> On Thu, Nov 21, 2013 at 1:18 AM, Lokesh Vutla wrote:
>>> Updating the mux data for UART, adding data for i2c0 and mmc.
>>> And also updating pad_signals structure.
>>>
>>> Signed-o
On Mon, Nov 25, 2013 at 12:08 AM, Lokesh Vutla wrote:
> On Friday 22 November 2013 02:07 AM, Vaibhav Bedia wrote:
>> On Thu, Nov 21, 2013 at 1:18 AM, Lokesh Vutla wrote:
>>> Updating the Multiplier and Dividers values for all DPLLs for EPOS EVM.
>>> Following are the DPLL locking frequencies at O
On Mon, Nov 25, 2013 at 12:13 AM, Lokesh Vutla wrote:
> On Friday 22 November 2013 02:16 AM, Vaibhav Bedia wrote:
>> On Thu, Nov 21, 2013 at 1:18 AM, Lokesh Vutla wrote:
>>> AM4372 EPOS EVM has 1GB LPDDR2(Part no: MT42L256M32D2LG-25 WT:A)
>>> Adding LPDDR2 init sequence and register details for t
On Mon, Nov 25, 2013 at 12:18 AM, Lokesh Vutla wrote:
> On Friday 22 November 2013 02:22 AM, Vaibhav Bedia wrote:
>> On Thu, Nov 21, 2013 at 1:18 AM, Lokesh Vutla wrote:
>> [...]
>>
>>> -/*
>>> - * Get SDRAM type connected to EMIF.
>>> - * Assuming similar SDRAM parts are connected to both EMIF's
The CPU errata expressed in include/configs/mx6_common.h apply
to all i.MX6DQ and i.MX6DLS parts.
Signed-off-by: Eric Nelson
---
include/configs/nitrogen6x.h | 1 +
include/configs/titanium.h | 1 +
include/configs/udoo.h | 1 +
include/configs/wandboard.h | 1 +
4 files changed, 4 inse
On Tue, Nov 26, 2013 at 10:40 PM, Eric Nelson
wrote:
> The CPU errata expressed in include/configs/mx6_common.h apply
> to all i.MX6DQ and i.MX6DLS parts.
>
> Signed-off-by: Eric Nelson
Thanks, Eric.
Reviewed-by: Fabio Estevam
___
U-Boot mailing list
On 11/26/2013 05:57 PM, Fabio Estevam wrote:
On Tue, Nov 26, 2013 at 10:40 PM, Eric Nelson
wrote:
The CPU errata expressed in include/configs/mx6_common.h apply
to all i.MX6DQ and i.MX6DLS parts.
Signed-off-by: Eric Nelson
Thanks, Eric.
No problem. If this is good enough for Freescale, i
On 26/11/13 13:24, Rajeshwari Birje wrote:
> Hi Minkyu Kang.
>
> Please do let me know if any comments or can we get this merged?
>
> On Fri, Nov 15, 2013 at 10:29 AM, Rajeshwari S Shinde
> wrote:
>> This patch adds basic board support for SMDK5420 board.
>> These patches are tested for booting
On 27.11.2013 01:40, Eric Nelson wrote:
> The CPU errata expressed in include/configs/mx6_common.h apply
> to all i.MX6DQ and i.MX6DLS parts.
>
> Signed-off-by: Eric Nelson
Acked-by: Stefan Roese
Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.d
On Wednesday 27 November 2013 05:42 AM, Vaibhav Bedia wrote:
> On Mon, Nov 25, 2013 at 12:13 AM, Lokesh Vutla wrote:
>> On Friday 22 November 2013 02:16 AM, Vaibhav Bedia wrote:
>>> On Thu, Nov 21, 2013 at 1:18 AM, Lokesh Vutla wrote:
AM4372 EPOS EVM has 1GB LPDDR2(Part no: MT42L256M32D2LG-2
Hi, Alexey,
I think good that use the initial fifoth value at register.
Then we need not to change the value.
But according to my experiment, some SoC needs to change the fifoth value.
On 11/27/2013 12:08 AM, Alexey Brodkin wrote:
> Removed code works properly only once after power-up because on
ping.
Original Message
Subject: Re: [PATCH 3/9 v8] Exynos5420: Add clock initialization for 5420
Date: Thu, 21 Nov 2013 16:03:23 +0900
From: Minkyu Kang
Organization: SAMSUNG ELECTRONICS
To: Rajeshwari S Shinde
CC: u-boot@lists.denx.de, patc...@linaro.org, s...@chromium.org,
ping.
Original Message
Subject: Re: [PATCH 6/9 v8] Exynos5420: Add base patch for SMDK5420
Date: Thu, 21 Nov 2013 16:24:14 +0900
From: Minkyu Kang
Organization: SAMSUNG ELECTRONICS
To: Rajeshwari S Shinde
CC: u-boot@lists.denx.de, patc...@linaro.org, s...@chromium.org,
chande
ping.
Original Message
Subject: Re: [PATCH 8/9 v8] Config: Add initial config for SMDK5420
Date: Thu, 21 Nov 2013 16:32:32 +0900
From: Minkyu Kang
Organization: SAMSUNG ELECTRONICS
To: Rajeshwari S Shinde
CC: u-boot@lists.denx.de, patc...@linaro.org, s...@chromium.org,
chande
ping.
Original Message
Subject: Re: [PATCH 4/9 v8] Exynos5420: Add DDR3 initialization for 5420
Date: Thu, 21 Nov 2013 16:13:24 +0900
From: Minkyu Kang
Organization: SAMSUNG ELECTRONICS
To: Rajeshwari S Shinde
CC: u-boot@lists.denx.de, patc...@linaro.org, s...@chromium.org,
c
Dear Otavio Salvador,
In message
you wrote:
>
> > Do I understand correctly that this happens only with the FSL kernel,
> > i. e. not with mainline Linux?
>
> Exactly.
>
> > What exactly is the effect of calling your set_anatop_bypass()
> > function? Why would that be needed on the FSL kernel
On Wednesday 27 November 2013 05:36 AM, Vaibhav Bedia wrote:
> On Mon, Nov 25, 2013 at 12:08 AM, Lokesh Vutla wrote:
>> On Friday 22 November 2013 02:07 AM, Vaibhav Bedia wrote:
>>> On Thu, Nov 21, 2013 at 1:18 AM, Lokesh Vutla wrote:
Updating the Multiplier and Dividers values for all DPLLs
Hello.
> As always, please speak up if something suddenly broke or you've found a
> problem of some sort. Thanks all!
I noticed at least two boards got broken by v2014.01-rc release:
cam_enc_4xx and linkstation_HGLAN
I bisected and
68ec9c85a9d334c7598b4972af037de05c034f8d is the first bad com
Hi Alexey,
On Nov 27, 2013, at 9:11 AM, Alexey Brodkin wrote:
> Hi Jaehoon,
>
> On Wed, 2013-11-27 at 14:33 +0900, Jaehoon Chung wrote:
>> Hi, Alexey,
>>
>> I think good that use the initial fifoth value at register.
>> Then we need not to change the value.
>> But according to my experiment, so
Hi Otavio,
On 26/11/2013 13:16, Otavio Salvador wrote:
>> I'm going to suggest this is the wrong path. Once you see i.MX systems
>> with > 768MB DDR you're going to have initrd/fdt placed into memory
>> Linux can't access without HIGHMEM on, and you need the FDT before then.
>
> I didn't catch t
57 matches
Mail list logo
