Hi Michal,
On 3 February 2015 at 02:26, Michal Simek wrote:
> Hi Simon,
>
> On 02/03/2015 12:58 AM, Simon Glass wrote:
>> Hi Michal,
>>
>> On 2 February 2015 at 08:46, Michal Simek wrote:
>>> Compile code with -fPIC to get GOT. Do not build SPL
>>> with fPIC because it increasing SPL size for no
On 2/4/2015 1:10 PM, Bo Shen wrote:
Hi Josh,
On 02/03/2015 06:19 PM, Josh Wu wrote:
HUSH parser will handle the variable easier. That will be helpful for
write a complicated U-Boot commands or varaibles.
You are on the way to Kconfig. :)
Yep. Seems a long way to go ;-)
Thanks.
Signed-of
Some boards have a special way of loading U-Boot that does not fit with
the existing SPL code. For example sunxi uses an 'FEL' mode where U-Boot
is loaded over USB. Add a CONFIG option and boot mode for this.
Signed-off-by: Simon Glass
---
arch/arm/include/asm/spl.h | 4
common/spl/spl.c
(What does FEL stand for?)
This is an attempt to make sunxi's FEL code fit with the normal U-Boot
boot sequence instead of creating its own.
Most of the FEL special-case code is removed, although I may have gone too
far with my changes to generate a u-boot-sunxi-with-spl.bin file even when
FEL is
This patch will display the U-Boot version on LCD.
Signed-off-by: Josh Wu
---
board/atmel/sama5d4_xplained/sama5d4_xplained.c | 2 ++
board/atmel/sama5d4ek/sama5d4ek.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/board/atmel/sama5d4_xplained/sama5d4_xplained.c
b/board/a
Hi Josh,
On 02/03/2015 06:19 PM, Josh Wu wrote:
HUSH parser will handle the variable easier. That will be helpful for
write a complicated U-Boot commands or varaibles.
You are on the way to Kconfig. :)
Thanks.
Signed-off-by: Josh Wu
Acked-by: Bo Shen
---
configs/at91sam9rlek_datafla
Hi Josh,
On 02/04/2015 11:03 AM, Josh Wu wrote:
This patch will display the U-Boot version on LCD.
To be frankly, I have no idea what should be put on LCD to display. No
objection for this patch.
Signed-off-by: Josh Wu
Acked-by: Bo Shen
---
board/atmel/sama5d4_xplained/sama5d4_xpl
If you want to inspect the control device tree using the fdt command,
the "fdt address -c" command previously unhelpfully printed the phys
memory address of the device tree. That address could not then be used
to set the fdt address for inspection. Changed the resulting print to
one that can be cop
Hi Akshay,
On 02/03/2015 05:27 PM, Akshay Saraswat wrote:
> Cleaning up soc_get_periph_rate to make the logic easy to
> comprehend.
>
Could you give more detailed description?
> Signed-off-by: Akshay Saraswat
> ---
> Changes since v4:
> - New patch.
>
> arch/arm/cpu/armv7/exynos/clock.
Hi,
On 02/03/2015 05:26 PM, Akshay Saraswat wrote:
> This patch series does following changes -
> 1. Removing compiler warnings for clock_get_periph_rate.
> 2. Adding and enabling support for Exynos542x in
>clock_get_periph_rate.
> 3. Replacing peripheral specific function calls with
>cloc
Hi, Nikita
On 2/3/2015 7:32 PM, Nikita Kiryanov wrote:
This series is part of my ongoing efforts to cleanup common/lcd code (and at
some point merge it with the CONFIG_VIDEO code).
This series focuses on eliminating platform specific #defines from lcd.c code,
and then adds a few platform indepen
Of course there is the meta question of why RSA sig is still being used
rather than ECDSA.
As a crypto plumber, I occationally wonder why we perpetuate need of
large, slow RSA keys over ECC. Perhaps the patent concerns even with
RFC 6090.
I will shut up and let you to your important work of
Hi Michal,
On Tue, 3 Feb 2015 10:11:39 +0100
Michal Simek wrote:
> Hi Simon,
>
> On 02/03/2015 03:02 AM, Masahiro Yamada wrote:
> > Hi.
> >
> >
> > On Mon, 2 Feb 2015 16:57:15 -0700
> > Simon Glass wrote:
> >
> >> Hi Michal,
> >>
> >> On 2 February 2015 at 08:31, Michal Simek wrote:
> >>>
Hi Simon,
Maybe I asked this before, but when can we remove
CONFIG_NEEDS_MANUAL_RELOC? What platforms need it?
A quick grep yields a global define of CONFIG_NEEDS_MANUAL_RELOC for
avr32, m68k, nds32, and sparc
Next question is - which of these platforms have toolchains which lack
the abili
Some boards want to skip the normal reset init. For example OMAP4 SPL
does not want to touch VBAR and many boards don't want to set up
CP15.
Provide a return value from save_boot_params() which allows the board
to indicate what reset processing should be done.
Signed-off-by: Simon Glass
---
ar
On Tue, 3 Feb 2015 17:55:52 -0700
Simon Glass wrote:
> Hi,
>
> On 2 February 2015 at 22:29, Simon Glass wrote:
> > Hi,
> >
> > On 2 February 2015 at 01:07, Hans de Goede wrote:
> >> Hi Simon, Siarhei,
> >>
> >> On 01-02-15 21:59, Simon Glass wrote:
> >>>
> >>> Hi Siarhei,
> >>>
> >>> On 1 Febr
The link register value can be required on some boards (e.g. FEL mode on
sunxi) so stash it to r4 before jumping to save_boot_params().
Signed-off-by: Simon Glass
---
arch/arm/cpu/armv7/start.S | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/s
Hi Siarhei,
On 3 February 2015 at 18:58, Siarhei Siamashka
wrote:
> On Tue, 3 Feb 2015 17:55:52 -0700
> Simon Glass wrote:
>
>> Hi,
>>
>> On 2 February 2015 at 22:29, Simon Glass wrote:
>> > Hi,
>> >
>> > On 2 February 2015 at 01:07, Hans de Goede wrote:
>> >> Hi Simon, Siarhei,
>> >>
>> >> On
Hi,
On 02/04/2015 03:30 PM, Akshay Saraswat wrote:
> Hi,
>
>> Hi Akshay,
>>
>> On 02/03/2015 05:27 PM, Akshay Saraswat wrote:
>>> Cleaning up soc_get_periph_rate to make the logic easy to
>>> comprehend.
>>>
>>
>> Could you give more detailed description?
>
> We did just a cleanup here by removi
Hi,
>Hi Akshay,
>
>On 02/03/2015 05:27 PM, Akshay Saraswat wrote:
>> Cleaning up soc_get_periph_rate to make the logic easy to
>> comprehend.
>>
>
>Could you give more detailed description?
We did just a cleanup here by removing I2C sepecific calculations
because we can now have a generic div an
If mode is not DDR-mode, then it needs to clear it.
Signed-off-by: Jaehoon Chung
---
drivers/mmc/dw_mmc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index b18c75d..76fa0b0 100644
--- a/drivers/mmc/dw_mmc.c
+++ b/drivers/mmc/dw_
This patchset fixed minor problems.
Included the previous patch("mmc: dw_mmc: fixed the wrong bit control")
Jaehoon Chung (3):
mmc: dw_mmc: fixed the wrong bit control
mmc: exynos_dw_mmc: set to clksel_val into board-init function
mmc: exynos_dw_mmc: use the exynos specific data structure
Clksel value is exynos specific value.
It removed "clksel_val" into dwmci_host and created the
"dwmci_exynos_priv_data" structure for exynos specific data.
Signed-off-by: Jaehoon Chung
---
drivers/mmc/exynos_dw_mmc.c | 60 +++--
include/dwmmc.h
Heiko,
what a great tool :-)
This makes the whole thing much easier and will produce (hopefully) less
noise from me :-)
But i 've a further questions:
1st)
patman prints out some errors, looks like for me that something is wrong
with the first line of my commit message - but no idea what.
"
T
On 02/03/2015 07:32 PM, Nikita Kiryanov wrote:
common/lcd code is full of platform-specific code and definitions, which
ideally should reside with the respective driver code. Take a step towards that
goal by moving platform-specific structs from lcd.h to their own header files.
The structs for t
"clksel_val" is assigned to property of mmc or defined value.
But it doesn't write at initial sequence.
There is a reason that get the wrong source-clock value.
This patch fixed it.
Signed-off-by: Jaehoon Chung
---
drivers/mmc/exynos_dw_mmc.c | 4
1 file changed, 4 insertions(+)
diff --git
Hi Guys,
Since I did the initial 'full relocation' for x86 way back when
(http://git.denx.de/?p=u-boot.git;a=commit;h=1c409bc7101a24ecd47a13a4e851845d66dc23ce),
there has been a lot of chatter about the ongoing need for
CONFIG_NEEDS_MANUAL_RELOC. I think it's about time we looked really hard
On Tue, Feb 3, 2015 at 5:01 PM, Simon Glass wrote:
> We certainly must avoid the build break.
>
> My concern is that CONFIG_DM may introduce a run-time break. For
> example if you don't have pre-relocation malloc() available the board
> may not boot. Driver model is a fundamental core feature, and
Hi Nikita Kiryanov,
On 02/03/2015 07:32 PM, Nikita Kiryanov wrote:
configuration_get_cmap() is multiple platform-specific functions stuffed into
one function. Split it into multiple versions, and move each version to the
appropriate driver to reduce the #ifdef complexity.
Signed-off-by: Nikita
Hello Hannes,
Am 04.02.2015 08:10, schrieb Hannes Petermaier:
Heiko,
what a great tool :-)
Yep, definitely... Thanks to Simon!
This makes the whole thing much easier and will produce (hopefully) less
noise from me :-)
;-)
But i 've a further questions:
1st)
patman prints out some error
Hello Simon,
On Tue, 3 Feb 2015 18:01:49 -0700, Simon Glass wrote:
> Hi Chris,
>
> On 3 February 2015 at 17:57, Chris Kuethe wrote:
> > On Tue, Feb 3, 2015 at 4:38 PM, Simon Glass wrote:
> >> +Masahiro
> >>
> >> Hi Chris,
> >>
> >> On 3 February 2015 at 00:42, Chris Kuethe wrote:
> >>> Discov
On 02/03/2015 07:32 PM, Nikita Kiryanov wrote:
Reduce the amount of platform-specific code in common/lcd.c by moving Atmel
implementation of fb_put_word() to atmel_lcdfb.c. Since we must also have a
default implementation for everybody else, make the remainder of the code
into a weak function.
S
Signed-off-by: Bo Shen
---
Changes in v2: None
arch/arm/cpu/arm926ejs/at91/timer.c | 59
arch/arm/include/asm/arch-at91/at91sam9260.h | 3 ++
arch/arm/include/asm/arch-at91/at91sam9261.h | 3 ++
arch/arm/include/asm/arch-at91/at91sam9263.h | 3 ++
arch/a
Hi Nikita Kiryanov,
On 02/03/2015 07:32 PM, Nikita Kiryanov wrote:
This series is part of my ongoing efforts to cleanup common/lcd code (and at
some point merge it with the CONFIG_VIDEO code).
This series focuses on eliminating platform specific #defines from lcd.c code,
and then adds a few plat
On 2015-02-04 08:33, Heiko Schocher wrote:
Hello Hannes,
1st)
patman prints out some errors, looks like for me that something is wrong
with the first line of my commit message - but no idea what.
"
Traceback (most recent call last):
File "tools/patman/patman", line 149, in
options.add
The commit 8dfafdd (Introduce common timer functions), add common
timer functions, we can use them directly.
Signed-off-by: Bo Shen
---
Changes in v2:
- correct the timer register for sama5d4.
arch/arm/cpu/armv7/at91/timer.c | 61
arch/arm/include/asm
The Quark SoC contains a legacy SPI controller in the legacy bridge
which is ICH7 compatible. Like Tunnel Creek and BayTrail, the BIOS
control register offset in the ICH SPI driver is wrong for the Quark
SoC too, unprotect_spi_flash() is added to enable the flash write.
Signed-off-by: Bin Meng
--
Intel Galileo board has a microSD slot which is routed from Quark SoC
SDIO controller. Enable SD/MMC support so that we can use an SD card.
Signed-off-by: Bin Meng
---
arch/x86/cpu/quark/quark.c | 11 +++
include/configs/galileo.h | 7 +++
2 files changed, 18 insertions(+)
diff -
Add pci ids for Intel Quark SoC.
Signed-off-by: Bin Meng
---
include/pci_ids.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/pci_ids.h b/include/pci_ids.h
index 1012abe..dc2ca21 100644
--- a/include/pci_ids.h
+++ b/include/pci_ids.h
@@ -2592,6 +2592,10 @@
#define PCI_DEVICE_I
Quark SoC has some non-standard BARs (excluding PCI standard BARs)
which need be initialized with suggested values. This includes GPIO,
WDT, RCBA, PCIe ECAM and some ACPI register block base addresses.
Signed-off-by: Bin Meng
---
arch/x86/cpu/quark/quark.c | 46
Add some instructions about building U-Boot for Intel Galileo board.
Signed-off-by: Bin Meng
---
doc/README.x86 | 24
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/doc/README.x86 b/doc/README.x86
index c699b79..fb87682 100644
--- a/doc/README.x86
+++ b
This series adds GPIO, SPI and SD/MMC support to Intel Galileo board.
Intel's chipset controllers are normally compatible so that we can easily
add peripherals support via existing drivers with minor modification.
Note this series depends on previous two series:
series#1: http://patchwork.ozlabs.o
Quark SoC has a legacy GPIO block in the legacy bridge (D0:F31),
which is just the same one found in other x86 chipset. Since we
programmed the GPIO register block base address, we should be
able to enable the GPIO support on Intel Galileo board.
Signed-off-by: Bin Meng
---
arch/x86/dts/galileo
Hi,
On 04-02-15 09:27, Ian Campbell wrote:
On Wed, 2015-02-04 at 00:43 +0100, Hans de Goede wrote:
The recent changes to config_distro_bootcmd.h require CONFIG_CMD_PART to be
defined, as the default bootcmd not uses the "part" command.
^w
Shouldn't config_d
Hello Simon,
On Tue, 3 Feb 2015 21:18:52 -0700, Simon Glass
wrote:
> The link register value can be required on some boards (e.g. FEL mode on
> sunxi) so stash it to r4 before jumping to save_boot_params().
I'd rather not make this there; I would like save_boot_params to start
with as unmodifie
On Wed, 2015-02-04 at 00:43 +0100, Hans de Goede wrote:
> The recent changes to config_distro_bootcmd.h require CONFIG_CMD_PART to be
> defined, as the default bootcmd not uses the "part" command.
^w
Shouldn't config_distro_bootcmd.h (or perhaps config_distro_def
On 2014-08-11 15:52, Anatolij Gustschin wrote:
Hi,
Hi,
sorry for my late response because i've been working on some other
project for a couple of months.
On Thu, 6 Mar 2014 15:26:11 +0100
Hannes Petermaier wrote:
...
+ CONFIG_LCD_NOSTDOUT
+ Normally 'stdout' is
Hi,
On 04-02-15 05:18, Simon Glass wrote:
(What does FEL stand for?)
This is an attempt to make sunxi's FEL code fit with the normal U-Boot
boot sequence instead of creating its own.
Most of the FEL special-case code is removed, although I may have gone too
far with my changes to generate a u-
On Tue, 2015-02-03 at 18:59 +0100, Hans de Goede wrote:
> Then we need to keep track of if that callback succeeded, because without
> the reservation we should not enable simplefb. I would prefer to just
> keep this bit as is.
OK then. With the comment fixed up:
Acked-by: Ian Campbell
Hi Peter,
> Previously NAND writes were not verified and could fail silently. Add
> a verification step after all writes to NAND.
>
> Signed-off-by: Peter Tyser
> ---
> I don't have a board with DFU support, so this change is untested.
>
> drivers/dfu/dfu_nand.c | 2 +-
> 1 file changed, 1 in
Hello Simon,
(sorry for the dupe)
On Tue, 3 Feb 2015 21:18:50 -0700, Simon Glass
wrote:
> Allow r0 to be used for other purposes in this file.
These purposes should be made clear -- possibly even, merged with the
code that actually needs it.
> Signed-off-by: Simon Glass
> ---
Amicaleme
Hello Hans,
On Wed, 04 Feb 2015 09:47:41 +0100, Hans de Goede
wrote:
> Hi,
>
> On 04-02-15 05:18, Simon Glass wrote:
> > (What does FEL stand for?)
> >
> > This is an attempt to make sunxi's FEL code fit with the normal U-Boot
> > boot sequence instead of creating its own.
> >
> > Most of the FE
Allow r0 to be used for other purposes in this file.
Signed-off-by: Simon Glass
---
arch/arm/cpu/armv7/start.S | 88 +++---
1 file changed, 44 insertions(+), 44 deletions(-)
diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index 70048
Hi Siarhei,
On 3 February 2015 at 20:23, Simon Glass wrote:
> Hi Siarhei,
>
> On 3 February 2015 at 18:58, Siarhei Siamashka
> wrote:
>> On Tue, 3 Feb 2015 17:55:52 -0700
>> Simon Glass wrote:
>>
>>> Hi,
>>>
>>> On 2 February 2015 at 22:29, Simon Glass wrote:
>>> > Hi,
>>> >
>>> > On 2 Februar
Hello Simon,
On Tue, 3 Feb 2015 21:18:51 -0700, Simon Glass
wrote:
> Some boards want to skip the normal reset init. For example OMAP4 SPL
> does not want to touch VBAR and many boards don't want to set up
> CP15.
>
> Provide a return value from save_boot_params() which allows the board
> to in
Hello Tom,
On Mon, 2 Feb 2015 13:56:57 -0500, Tom Rini wrote:
> And (and this is being split into
> different email threads, sigh), it would be good, possibly, if we have
> something that means "very early init things, but we can be written in
> C".
"Very early" -- and "early" too, BTW -- is wa
On 02/04/2015 04:11 AM, Masahiro Yamada wrote:
> Hi Michal,
>
>
> On Tue, 3 Feb 2015 10:11:39 +0100
> Michal Simek wrote:
>
>> Hi Simon,
>>
>> On 02/03/2015 03:02 AM, Masahiro Yamada wrote:
>>> Hi.
>>>
>>>
>>> On Mon, 2 Feb 2015 16:57:15 -0700
>>> Simon Glass wrote:
>>>
Hi Michal,
>>
Hi,
On 02/04/2015 06:48 AM, Graeme Russ wrote:
> Hi Simon,
>
>> Maybe I asked this before, but when can we remove
>> CONFIG_NEEDS_MANUAL_RELOC? What platforms need it?
>
> A quick grep yields a global define of CONFIG_NEEDS_MANUAL_RELOC for avr32,
> m68k, nds32, and sparc
+ Microblaze to move
On 1/14/15 5:45 PM, Marek Vasut wrote:
> On Wednesday, January 14, 2015 at 05:40:48 PM, dingu...@opensource.altera.com
> wrote:
>> From: Dinh Nguyen
>>
>> Signed-off-by: Dinh Nguyen
>
> You might want to check common/spl/spl.c , which implements most of the
> standard
> SPL init procedure. I
On 3 February 2015 at 12:57, Stefan Roese wrote:
> Without this change the board support for these SPEAr boards would
> be dropped soon. Generic board support seems to work just fine.
>
> Signed-off-by: Stefan Roese
> Cc: Viresh Kumar
> Cc: Vipin Kumar
> ---
> Unfortunately I missed the merge w
Commit 90bac29a76bc8d649b41a55f2786c0abef9bb2c1 claims to fix this bug
that was introduced in commit a92fd6577ea17751ead9b50243e3c562125cf581
but doesn't actually make the change that the commit message describes.
Actually fix the bug this time.
Signed-off-by: Joe Hershberger
---
Changes in v2
If CONFIG_ARMV7_PSCI is not defined and CONFIG_ARMV7_SECURE_BASE is defined,
smp_kicl_all_cpus may enable secondary cores and runs into secure_ram_addr(
_smp_pen), before code is relocated to secure ram.
So need relocation to secure ram before enable secondary cores.
Signed-off-by: Peng Fan
---
This patch series does following changes -
1. Removing compiler warnings for clock_get_periph_rate.
2. Adding and enabling support for Exynos542x in
clock_get_periph_rate.
3. Replacing peripheral specific function calls with
clock_get_periph_rate.
4. Remove code from clocks file which became
Apparently, members of clk_bit_info array do not map correctly
to the members of enum periph_id. This mapping got broken after
we changed periph_id(s) to reflect interrupt number instead of
their position in a sequence. This patch intends to fix above
mentioned issue.
Signed-off-by: Akshay Saraswa
Moving exynos5420_get_pll_clk function definition up in the
code to keep it together with rest of SoC_get_pll_clk functions.
This makes code more legible and also removes the need of
declaration when called before the position of definition in
code. Also, renaming exynos5420_get_pll_clk to
exynos54
We planned to fetch peripheral rate through one generic API per
peripheral. These generic peripheral functions are in turn
expected to fetch apt values from a function refactored as
per SoC versions. This patch adds support for fetching peripheral
rates for Exynos5420 and Exynos5800.
Signed-off-by
exynos5_get_periph_rate function reads incorrect div for
SDMMC2 & 3. It also reads prediv and does division only for
SDMMC0 & 2 when actually various other peripherals need that.
Adding changes to fix these mistakes in periph rate calculation.
Signed-off-by: Akshay Saraswat
Reviewed-by: Simon Gla
We have assumed and kept mask bits for divider and pre-divider
as 0xf and 0xff, respectively. But these mask bits change from
one peripheral to another, and hence, need to be specified in
accordance with the peripherals.
Signed-off-by: Akshay Saraswat
---
Changes since v5:
- No Change.
C
Replacing SoC and peripheral specific function calls with generic
clock_get_periph_rate calls to get the peripheral clocks.
Also, removing dead code of peripheral and SoC specific function
implementations which was used earlier for fetching peripheral clocks.
This code is not being used anymore bec
Since we have src, div and pre-div mask bits defined corresponding
to peripherals, calculation of clock specific to I2C appears
redundant and confusing. Using clk_bit_info struct we can write
calculations generic to all peripherals which makes code easy to
understand and free from peripheral specif
Hello Graeme,
On Wed, 04 Feb 2015 18:14:22 +1100, Graeme Russ
wrote:
> Hi Guys,
>
> Since I did the initial 'full relocation' for x86 way back when
> (http://git.denx.de/?p=u-boot.git;a=commit;h=1c409bc7101a24ecd47a13a4e851845d66dc23ce),
>
> there has been a lot of chatter about the ongoing n
Hello Michal,
On Wed, 4 Feb 2015 10:56:02 +0100, Michal Simek
wrote:
> On 02/04/2015 04:11 AM, Masahiro Yamada wrote:
> > Hi Michal,
> >
> >
> > On Tue, 3 Feb 2015 10:11:39 +0100
> > Michal Simek wrote:
> >
> >> Hi Simon,
> >>
> >> On 02/03/2015 03:02 AM, Masahiro Yamada wrote:
> >>> Hi.
> >>
Hello Tobias,
You should use git send-email (or better yet, patman) for sending
patches; this one was attached instead of inline.
That being said, it did not seem to worry patchwork, so you don't
need to repost this one.
Amicalement,
--
Albert.
___
U-
Hi Anatolij,
On Tue, 3 Feb 2015 20:17:36 +0100
Anatolij Gustschin wrote:
> Hello Boris,
>
> On Tue, 3 Feb 2015 19:39:16 +0100
> Boris Brezillon wrote:
>
> > Hello,
> >
> > I'm currently porting the SECO iMX6 uQ7 board to mainline, but I'm
> > facing a hang when enabling DCache (CONFIG_SYS_DC
On 04/02/15 10:15, Peng Fan wrote:
> If CONFIG_ARMV7_PSCI is not defined and CONFIG_ARMV7_SECURE_BASE is defined,
> smp_kicl_all_cpus may enable secondary cores and runs into secure_ram_addr(
> _smp_pen), before code is relocated to secure ram.
> So need relocation to secure ram before enable secon
Hi Albert,
On 02/04/2015 11:34 AM, Albert ARIBAUD wrote:
> Hello Michal,
>
> On Wed, 4 Feb 2015 10:56:02 +0100, Michal Simek
> wrote:
>> On 02/04/2015 04:11 AM, Masahiro Yamada wrote:
>>> Hi Michal,
>>>
>>>
>>> On Tue, 3 Feb 2015 10:11:39 +0100
>>> Michal Simek wrote:
>>>
Hi Simon,
>>
Hi All,
Inspired by Simon's work to make the FEL SPL and regular SPL builds more
similar I've been looking into reducing the size of the SPL, resulting in
the following patch series. This all seems quite safe, but we are past rc1,
so may be best to keep this on a branch for now, or not ...
Simon,
All callers of malloc should already do error checking, and may even be able
to continue without the alloc succeeding.
Moreover, common/malloc_simple.c is the only user of .rodata.str1.1 in
common/built-in.o when building the SPL, triggering this gcc bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?
Before this patch malloc_simple would always allocate a chunk of RAM from
the stack. This commit adds a CONFIG_SYS_MALLOC_F_BASE define, which when
set directly specifies the memory address to use for the heap with
malloc_simple.
Signed-off-by: Hans de Goede
---
arch/arm/lib/crt0.S | 2 +-
commo
common/dlmalloc.c is quite big, both in .text and .data usage. E.g. for a
Mele_M9 sun6i board build this reduces .text from 0x4214 to 0x3b94 bytes, and
.data from 0x54c to 0x144 bytes.
Signed-off-by: Hans de Goede
---
include/configs/sunxi-common.h | 5 +++--
1 file changed, 3 insertions(+), 2 d
Move the dram helper functions to a separate C file, rather then having them
as inline helpers in dram.h. This saves 144 bytes in the .text segment for
sun6i builds.
Signed-off-by: Hans de Goede
---
arch/arm/cpu/armv7/sunxi/Makefile | 1 +
arch/arm/cpu/armv7/sunxi/dram_helpers.c | 37
Hi Albert,
If we use SPL, we do not have to relocate code, I think.
SPL doesn't have relocation that's why this code is not used there.
It is not what I meant.
If SPL can directly load the main u-boot image
to the DRAM address where it is linked,
we do not relocate the code in the main
Hi Albert,
On 04/02/15 21:29, Albert ARIBAUD wrote:
Hello Graeme,
On Wed, 04 Feb 2015 18:14:22 +1100, Graeme Russ
wrote:
So the first question that we need to answer is: Do the avr32, m68k,
nds32, and sparc toolchains support the generation of the relevant
sections needed to perform reloca
On Sat 2015-01-17 03:39:46, Marek Vasut wrote:
> On Friday, January 16, 2015 at 08:04:20 PM, Pavel Machek wrote:
> > Hi!
>
> Hi!
>
> > > > +void wait_di_buffer(void)
> > > > +{
> > > > + if (debug_data->di_report.cur_samples == NUM_DI_SAMPLE) {
> > > > + debug_data->di_report.
On Fri 2015-01-30 23:08:46, Marek Vasut wrote:
> Since all boards now have a DT, instead of hard-coding the board
> name into the U-Boot binary, read the board name from DT "model"
> property.
>
> Signed-off-by: Marek Vasut
> Cc: Chin Liang See
> Cc: Dinh Nguyen
Acked-by: Pavel Machek
--
(en
Hi all,
is it possible to start FIT signed kernel from SPL (falcon mode)?
Thanks,
marek
--
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052
Hello!
On 2015-02-04 11:42, Albert ARIBAUD wrote:
Hello Tobias,
You should use git send-email (or better yet, patman) for sending
patches; this one was attached instead of inline.
Sorry, I normally do that, but I didn't have access to my Odroid system
when I sent the patch.
That being said
On Mon 2015-02-02 10:18:23, Stephen Warren wrote:
> On 01/31/2015 08:20 PM, Simon Glass wrote:
> >Hi Albert,
> >
> >On 31 January 2015 at 20:02, Albert ARIBAUD
> >wrote:
> >>Hello Masahiro,
> >>
> >>On Sun, 25 Jan 2015 15:11:02 +0900, Masahiro Yamada
> >> wrote:
> >>>
> >>>This series can be appl
hi Linus,
The following is some advice about the multi entry patch.
> While the Freescale ARMv8 board LS2085A will enter U-Boot both
> on a master and a secondary (slave) CPU, this is not the common
> behaviour on ARMv8 platforms. The norm is that U-Boot is entered
> from the master
On 3 February 2015 at 01:18, Akshay Saraswat wrote:
> This patch adds code to shutdown secondary cores.
> When U-boot comes up, all secondary cores appear powered on,
> which is undesirable and causes side effects while
> initializing these cores in kernel.
>
> Secondary core power down happens in
On 3 February 2015 at 01:19, Akshay Saraswat wrote:
> From: Doug Anderson
>
> It was found that the L2 cache timings that we had before could cause
> freezes and hangs. We should make things more robust with better
> timings. Currently the production ChromeOS kernel applies these
> timings, but
On 3 February 2015 at 01:27, Akshay Saraswat wrote:
> We have assumed and kept mask bits for divider and pre-divider
> as 0xf and 0xff, respectively. But these mask bits change from
> one peripheral to another, and hence, need to be specified in
> accordance with the peripherals.
>
> Signed-off-by
On 2 February 2015 at 07:35, Bin Meng wrote:
> device.h for integrated pci devices' bdf on Quark SoC and quark.h for
> various memory-mapped and i/o-mapped base addresses within SoC.
>
> Signed-off-by: Bin Meng
>
> ---
>
> Changes in v3:
> - Add several macros for message bus port and registers
>
On 2 February 2015 at 07:35, Bin Meng wrote:
> Move PCI_REG_ADDR and PCI_REG_DATA from arch/x86/lib/pci_type1.c to
> arch/x86/include/asm/pci.h, also define PCI_CFG_EN so that these
> macros can be used for pci configuration space access.
>
> Signed-off-by: Bin Meng
>
> ---
>
> Changes in v3:
> -
On 2 February 2015 at 07:35, Bin Meng wrote:
> Quark SoC contains an embedded 512KiB SRAM (eSRAM) that is
> initialized by hardware. eSRAM is the ideal place to be used
> for Cache-As-RAM (CAR) before system memory is available.
>
> Signed-off-by: Bin Meng
>
> ---
>
> Changes in v3:
> - Use macro
On 2 February 2015 at 07:35, Bin Meng wrote:
> Add minimum codes to support Intel Quark SoC. DRAM initialization
> is not ready yet so a hardcoded gd->ram_size is assigned.
>
> Signed-off-by: Bin Meng
>
> ---
>
> Changes in v3:
> - Add simple help for ACPI PM1, PBLK and GEP0
>
> Changes in v2:
>
Dear all,
I have already used u-boot several times on various ARM-based platforms but I
need to go to unknown territories this time.
On an ARM-based platform again, we have a u-boot port (v2010.09) available
loaded by a ROM bootloader into the internal RAM.
For some reasons, the ROM bootloader l
Hello;
I just started working with the ChiliSOM module [1] -- in my particular
case it is part of the Chiliboard [2].
The ChiliSOM is a nice little module based on the TI AM335x ARM SoC. I
already started porting the mainline U-boot for it. The DRAM and serial
console seem to work so far. I hope th
On 3 February 2015 at 04:45, Bin Meng wrote:
> Add COMPAT_INTEL_QRK_MRC and "intel,quark-mrc" so that fdtdec can
> decode Intel Quark MRC node.
>
> Signed-off-by: Bin Meng
> ---
>
> include/fdtdec.h | 1 +
> lib/fdtdec.c | 1 +
> 2 files changed, 2 insertions(+)
Acked-by: Simon Glass
_
Hi Bin,
On 3 February 2015 at 04:45, Bin Meng wrote:
> Turn on the Memory Reference code build in the quark Makefile.
>
> Signed-off-by: Bin Meng
> ---
>
> arch/x86/cpu/quark/Makefile | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/x86/cpu/quark/Makefile b/arch/x86/cpu/quark/Makef
1 - 100 of 166 matches
Mail list logo
