Am 14/05/2011 15:27, schrieb Fabio Estevam:
Hi Fabio,
> ---
> Stefano, this patch applies on your u-boot-imx tree with my previous MX53SMD
> patch applied.
Ok
> +
> +void weim_smc911x_iomux()
> +{
> + unsigned int reg;
> +
> + /* ETHERNET_INT_B as GPIO2_31 */
> + mxc_request_iomux(
Dear Stefano,
In message <4dcf9e79.9020...@denx.de> you wrote:
>
> > + /* ETHERNET_INT_B as GPIO2_31 */
> > + mxc_request_iomux(MX53_PIN_EIM_EB3,
> > + IOMUX_CONFIG_ALT1);
> > + reg = readl(GPIO2_BASE_ADDR + 0x4);
> > + reg &= ~(0x8000);
> > + writel(reg, GPIO2_BASE_ADDR +
Dear Simon Guinot,
In message <1305382159-5483-1-git-send-email-simon.gui...@sequanux.org> you
wrote:
> --===2147409246==
>
> This patch add support for the Network Space v2 board and parents, based
> on the Marvell Kirkwood 6281 SoC. This include Network Space (Max) v2
> and Interne
On 15/05/11 03:32, Simon Glass wrote:
> On Sat, May 14, 2011 at 4:34 AM, Mike Frysinger wrote:
>
>> On Friday, May 13, 2011 16:51:59 Simon Glass wrote:
>>> This defines the basics of a new boot time measurement feature. This
>> allows
>>> logging of very accurate time measurements as the boot pro
Hi Wolfgang,
On Sun, May 15, 2011 at 11:55:25AM +0200, Wolfgang Denk wrote:
> Dear Simon Guinot,
>
> In message <1305382159-5483-1-git-send-email-simon.gui...@sequanux.org> you
> wrote:
> > --===2147409246==
> >
> > This patch add support for the Network Space v2 board and parents,
On Sat, May 14, 2011 at 04:09:19PM +0200, Simon Guinot wrote:
> This patch add support for the Network Space v2 board and parents, based
> on the Marvell Kirkwood 6281 SoC. This include Network Space (Max) v2
> and Internet Space v2.
>
> Additional information is available at:
> http://lacie-nas.o
Dear Simon Glass,
In message <1305319923-9477-1-git-send-email-...@chromium.org> you wrote:
> This defines the basics of a new boot time measurement feature. This allows
> logging of very accurate time measurements as the boot proceeds, by using
> an available microsecond counter.
Well, as long a
On 15/05/11 19:55, Wolfgang Denk wrote:
> Dear Simon Guinot,
>
> In message <1305382159-5483-1-git-send-email-simon.gui...@sequanux.org> you
> wrote:
>> --===2147409246==
>>
>> This patch add support for the Network Space v2 board and parents, based
>> on the Marvell Kirkwood 6281 SoC
This patch add support for the Network Space v2 board and parents, based
on the Marvell Kirkwood 6281 SoC. This include Network Space (Max) v2
and Internet Space v2.
Additional information is available at:
http://lacie-nas.org/doku.php?id=network_space_v2
Signed-off-by: Simon Guinot
---
Changes
Dear Simon Guinot,
In message <1305462738-2583-1-git-send-email-simon.gui...@sequanux.org> you
wrote:
> --===0038591950==
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> This patch add support for the Network Space v2 board and parents, based
> on the
Hi Wolfgang,
On Sun, May 15, 2011 at 02:45:19PM +0200, Wolfgang Denk wrote:
> Dear Simon Guinot,
>
> In message <1305462738-2583-1-git-send-email-simon.gui...@sequanux.org> you
> wrote:
> > --===0038591950==
> > Content-Type: text/plain; charset=UTF-8
> > Content-Transfer-Encoding: 8
On 05/04/2011 08:13 AM, Shawn Guo wrote:
> With the following commit, CONFIG_OF_LIBFDT is redefined.
>
> 2fa8ca98c37d5b1bb0328b19ddb7e9d162cd9683
> Add CONFIG_OF_LIBFDT to more boards.
>
> Remove the duplicated definition to fix CONFIG_OF_LIBFDT redefined
> warning.
>
> Signed-off-by: Shawn
On 05/04/2011 08:13 AM, Shawn Guo wrote:
> Since the following commit, definition CONFIG_SYS_BOOTMAPSZ is not
> needed any more.
>
> ed59e58786cae9f8afcb575649afc65985beed4d
> Remove device tree booting dependency on CONFIG_SYS_BOOTMAPSZ
>
> Signed-off-by: Shawn Guo
> ---
Applied to -u-boot
On 05/13/2011 01:58 PM, Jason Liu wrote:
> This patch add initial support for freescale MX53LOCO board.
> Network(FEC),SD/MMC,UART have been supported by this patch
>
> Signed-off-by: Jason Liu
Applied to u-boot-imx, thanks.
Best regards,
Stefano Babic
--
=
On 05/13/2011 03:15 PM, Fabio Estevam wrote:
> Signed-off-by: Fabio Estevam
> ---
> Changes since v1:
> - Fix Copyright typo
> - Drop board_late_init
>
> MAINTAINERS |1 +
> board/freescale/mx53smd/Makefile | 48
> board/freescale/mx53smd/imximage.cfg
On 05/10/2011 07:50 PM, Fabio Estevam wrote:
> Currently the fb_videomode struct is only declared if CONFIG_HW_WATCHDOG is
> defined.
>
> Remove this dependancy and let the video struct always be declared.
>
> Signed-off-by: Fabio Estevam
> ---
Applied to u-boot-imx, thanks.
Best regards,
Ste
On 05/10/2011 08:13 PM, Fabio Estevam wrote:
> config.mk should not be used in board directory and should be removed.
> Use the same approach for building the image as other MX51/MX53 boards.
>
> After this change vision2 board can be built again.
>
> Signed-off-by: Fabio Estevam
Applied to u-b
Provide a means by which u-boot/SPL can save parameters passed
to it by ROM code or the pre-loader.
A new function 'save_boot_params' has been defined and a default
implentation provided. Please note that we do not have a stack yet.
So, any implementation of this function should not use stack.
Si
Signed-off-by: Aneesh V
---
V2:
* Added a revision string in addition to the revision number
Helps in printing out the OMAP revision at bootup
---
arch/arm/cpu/armv7/omap4/board.c| 58 +++
arch/arm/include/asm/arch-omap4/omap4.h | 17 ++---
arch/arm/i
The basic hardware init of OMAP4(s_init()) can happen in 4
different contexts:
1. SPL running from SRAM
2. U-Boot running from FLASH
3. Non-XIP U-Boot loaded to SDRAM by SPL
4. Non-XIP U-Boot loaded to SDRAM by ROM code using the
Configuration Header feature
What level of hw initialization
Define a new type of SPL that is not tied to any particular media.
- Create a top level directory 'spl' that has a structure similar
to the existing 'nand_spl'
- Make necessary changes to top-level Makefile to build such an spl
Rationale for this approach:
- There may be SPLs(like the OMAP x-loa
This series adds mmc SPL support for OMAP4. This is essentially
an up-streaming effort for TI's x-loader for OMAP4 using the SPL
framework
This work partly draws upon previous work done for x-loader by:
Santosh Shilimkar
Rajendra Nayak
and many others
This series is depedent on
Add the basic spl framework and linker script common for OMAP3/4
platforms.
Signed-off-by: Aneesh V
---
spl/board/ti/spl-omap.c | 47 ++
spl/board/ti/spl-omap.lds | 62 +
2 files changed, 109 insertions(+), 0 delet
Changes for supporting SPL
Signed-off-by: Aneesh V
---
arch/arm/cpu/armv7/start.S | 36 +---
1 files changed, 25 insertions(+), 11 deletions(-)
diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index 13178cd..f92c6d9 100644
--- a/arch/arm/cpu
sync up mux settings with the latest in x-loader
Signed-off-by: Aneesh V
---
Several checkpatch warnings of lines over 80 characters in this
patch. These are due to formatting of mux data array, which only makes
it more readable.
---
board/ti/panda/panda_mux_data.h | 89 ++-
Signed-off-by: Aneesh V
---
V2:
* Changes for make file changes
---
include/configs/omap4_sdp4430.h |1 +
spl/board/ti/omap4.mk |7 +++
spl/board/ti/spl-omap.c | 22 ++
3 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/include/con
Do the essential part from SPL and non-essential part from U-Boot
- Essential part is what is essential for u-boot to function
- Essential part is also largely board independent(at least
as of now)
- So essential part is moved out to SoC directory instead of
keeping in board directory. This hel
_bss_start_ofs is used in start.S to indicate end of copied
image. This may not be correct when we have a discontiguous
memory map. For instance, .bss may be placed in SDRAM for
some SPLS while rest of the image is placed in SRAM.
Define a new label in linker script to indicate the end of the
imag
Signed-off-by: Aneesh V
---
V2:
* Changes for make file changes
---
arch/arm/cpu/armv7/start.S |1 +
arch/arm/include/asm/omap_common.h |4 +
include/configs/omap4_sdp4430.h|7 ++-
spl/board/ti/omap4.mk | 35 +++
spl/board/ti/spl-omap.c|
Save boot device information passed by OMAP4 rom code
ROM code in OMAP4 passes information such as the media from
which it picked up the first boot image(SPL in our case),
the mode(raw mode/FAT mode) etc.
Save this information in SPL so that we can use the same media
and mode to bootload u-boot.
Signed-off-by: Aneesh V
---
arch/arm/cpu/armv7/omap4/board.c|3 ++
arch/arm/cpu/armv7/omap4/clocks.c | 27 ++
arch/arm/include/asm/arch-omap4/sys_proto.h |2 +
arch/arm/include/asm/omap_common.h |1 +
spl/board/ti/omap4.mk
Embed the u-boot flash image size at a known offset from the
start of u-boot so that SPL can use it while loading u-boot
from a non-XIP media.
Signed-off-by: Aneesh V
V2:
* Removed the linker script label '__flash_image_end' and its usage.
Instead '_end' is used now
---
arch/arm/cpu/armv7/star
Adapted from: nand_spl/board/samsung/smdk6400/Makefile
- Add the SPL makefile for OMAP4430 SDP
- Add the necessary CONFIG flags in the board config file
Signed-off-by: Aneesh V
---
V2:
* Changed CONFIG_SYS_SPL_TEXT_BASE to 0x40304350 from
0x40304360. This exact address is needed for EMU
d
From: John Rigby
Signed-off-by: John Rigby
---
common/image.c|1 +
include/image.h |1 +
tools/Makefile|2 +
tools/mkimage.c |2 +
tools/mkimage.h |1 +
tools/omapimage.c | 229 +
tools/omapimage.h | 50 +++
Identify SDRAM devices connected to EMIF automatically:
LPDDR2 devices have some Mode Registers that provide details
about the device such as the type, density, bus width
etc. EMIF has the capability to read these registers. If there
are not devices connected to a given chip-select reading mode
reg
Add support for the SDRAM controller (EMIF).
Signed-off-by: Aneesh V
V2:
* Changes for makefile changes
* Minor corrections in do_lpddr2_init()
* Minor corrections to read_idle interval calculation
* Sanity test of memory after doing the initialization
* Fixed warnings reported with with latest G
Add support for:
1. DPLL locking
2. Initialization of clock domains and clock modules
This work draws upon previous work done for x-loader mainly by:
Santosh Shilimkar
Rajendra Nayak
Signed-off-by: Aneesh V
---
V2:
* Use pre-calculated M & N values instead of calculated ones
*
In SPL console is enabled very early where as in U-Boot
it's not. So, SPL can have traces in early init code
while U-Boot can not have it in the same shared code.
Adding a debug print macro that will be defined in SPL
but compiled out in U-Boot.
Also add some useful debug traces throughout SPL
S
Signed-off-by: Aneesh V
---
V2:
* Changed CONFIG_SYS_SPL_TEXT_BASE to 0x40304350 for Panda
This is required for EMU devices
* Changes due to make file changes
---
arch/arm/cpu/armv7/omap4/emif.c|5 +++--
arch/arm/include/asm/arch-omap4/emif.h | 10 +-
include/configs/om
Calculate EMIF register values based on AC timing parameters
from the SDRAM datasheet and the DDR frequency rather than
using the hard-coded values.
For a new board the user doen't have to go through the tedious
process of calculating the register values. Instead, just
provide the AC timings from
From: Dirk Behme
Fix typo resulting in the compilation error
s5p_mmc.c: In function 's5p_mmc_initialize':
s5p_mmc.c:469: error: 'struct mmc' has no member named 'm_bmax'
introduced by commit "MMC: make b_max unconditional"
(8feafcc49c0b7a9c541904f95a43dbef2fecc38b)
Signed-off-by: Dirk Behme
From: Rick Bronson
Signed-off-by: Rick Bronson
---
arch/arm/cpu/armv7/omap-common/timer.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/timer.c
b/arch/arm/cpu/armv7/omap-common/timer.c
index 9beebb1..3c9d488 100644
--- a/arch/arm/cpu/a
Dear Aneesh V,
In message <1305472900-4004-10-git-send-email-ane...@ti.com> you wrote:
> Adapted from: nand_spl/board/samsung/smdk6400/Makefile
>
> - Add the SPL makefile for OMAP4430 SDP
> - Add the necessary CONFIG flags in the board config file
>
> Signed-off-by: Aneesh V
> ---
> V2:
> * Ch
Dear Aneesh V,
In message <1305202276-27784-3-git-send-email-ane...@ti.com> you wrote:
> add utility macros for:
> * bit field operations
> * log2n functions
...
> +/* extract a bit field from a bit vector */
> +#define get_bit_field(nr, start, mask)\
> + (((nr) & (mask)) >> (start))
> +
>
Dear Aneesh V,
In message <1305202276-27784-4-git-send-email-ane...@ti.com> you wrote:
> - Add a framework for layered cache maintenance
> - separate out SOC specific outer cache maintenance from
> maintenance of caches known to CPU
>
> - Add generic ARMv7 cache maintenance operatio
Dear Aneesh V,
In message <1305202276-27784-5-git-send-email-ane...@ti.com> you wrote:
> replace all occurences of CONFIG_L2_OFF with a more appropriate
> CONFIG_SYS_NO_L2CACHE
>
> CONFIG_SYS_NO_L2CACHE has been chosen to be in line with
> CONFIG_SYS_NO_ICACHE and CONFIG_SYS_NO_DCACHE
sorry, but
Dear Aneesh V,
In message <1305202276-27784-6-git-send-email-ane...@ti.com> you wrote:
> - Enable I-cache on bootup
> - Enable MMU and D-cache immediately after relocation
> - Do necessary initialization before enabling d-cache and MMU
Would it be possible to do this even _before_ relocatio
Dear Aneesh V,
In message <1305202276-27784-9-git-send-email-ane...@ti.com> you wrote:
> adapt omap4 to the new layered cache maintenance framework
NAK because of the CONFIG_SYS_NO_*CACHE names.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zund
Dear Aneesh V,
In message <1305202276-27784-10-git-send-email-ane...@ti.com> you wrote:
> adapt omap3 to the new layered cache maintenance framework
>
> Signed-off-by: Aneesh V
> ---
> V2:
> * Changes for the function pointer to weakly linked change
> ---
> arch/arm/cpu/armv7/omap3/Makefile
Dear Aneesh V,
In message <1305202276-27784-11-git-send-email-ane...@ti.com> you wrote:
> adapt s5pc1xx to the new layered cache maintenance framework
>
> Signed-off-by: Aneesh V
> ---
> V2:
> * Changes for the function pointer to weakly linked change
> ---
> arch/arm/cpu/armv7/s5pc1xx/cache.S
Dear Aneesh V,
In message <1305472900-4004-14-git-send-email-ane...@ti.com> you wrote:
> Add support for:
> 1. DPLL locking
> 2. Initialization of clock domains and clock modules
>
> This work draws upon previous work done for x-loader mainly by:
> Santosh Shilimkar
> Rajendra Nayak
From: Dirk Behme
Add missing header file to fix compilation warning
omap_hsmmc.c: In function 'omap_mmc_init':
omap_hsmmc.c:474: warning: implicit declaration of function 'get_cpu_family'
omap_hsmmc.c:474: warning: implicit declaration of function 'get_cpu_rev'
introduced by commit "MMC: omap_h
Dear Aneesh V,
In message <1305472900-4004-2-git-send-email-ane...@ti.com> you wrote:
> From: John Rigby
>
> Signed-off-by: John Rigby
> ---
> common/image.c|1 +
> include/image.h |1 +
> tools/Makefile|2 +
> tools/mkimage.c |2 +
> tools/mkimage.h |1 +
> t
Dear Aneesh V,
In message <1305472900-4004-3-git-send-email-ane...@ti.com> you wrote:
> Signed-off-by: Aneesh V
> ---
> V2:
> * Added a revision string in addition to the revision number
> Helps in printing out the OMAP revision at bootup
...
> +const char *omap4_rev_string(void)
> +{
> + c
Dear Aneesh V,
In message <1305472900-4004-4-git-send-email-ane...@ti.com> you wrote:
> Provide a means by which u-boot/SPL can save parameters passed
> to it by ROM code or the pre-loader.
>
> A new function 'save_boot_params' has been defined and a default
> implentation provided. Please note t
Dear Aneesh V,
In message <1305472900-4004-5-git-send-email-ane...@ti.com> you wrote:
> Save boot device information passed by OMAP4 rom code
>
> ROM code in OMAP4 passes information such as the media from
> which it picked up the first boot image(SPL in our case),
> the mode(raw mode/FAT mode) e
From: Dirk Behme
Add a header file with the missing function prototype to fix
ca9x4_ct_vxp.c: In function 'cpu_mmc_init':
ca9x4_ct_vxp.c:93: warning: implicit declaration of function
'arm_pl180_mmci_init'
introduced by commit "ARMV7: Vexpress: Add MMC support"
(f0c64526b7e51ba997a0f1baf9e74e6d
Hi all,
Sorry for the delay. I'm adding some of mine ideas for the discussion. What I
like on u-boot is interactive command line ;) this is why I started to tickle
this.
The coreboot + u-boot is a win for u-boot because it can run on then on any
coreboot supported board (including QEMU).
Fro
Dear Aneesh V,
In message <1305472900-4004-7-git-send-email-ane...@ti.com> you wrote:
> Define a new type of SPL that is not tied to any particular media.
> - Create a top level directory 'spl' that has a structure similar
> to the existing 'nand_spl'
> - Make necessary changes to top-level Make
Dear Aneesh V,
In message <1305472900-4004-8-git-send-email-ane...@ti.com> you wrote:
> Changes for supporting SPL
As is, this is dead code. I think this patch should be much later in
this patch series.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & De
Dear Aneesh V,
In message <1305472900-4004-9-git-send-email-ane...@ti.com> you wrote:
> Add the basic spl framework and linker script common for OMAP3/4
> platforms.
>
> Signed-off-by: Aneesh V
> ---
> spl/board/ti/spl-omap.c | 47 ++
> spl/board/ti/spl-omap.
Dear Aneesh V,
In message <1305472900-4004-9-git-send-email-ane...@ti.com> you wrote:
> Add the basic spl framework and linker script common for OMAP3/4
> platforms.
>
> Signed-off-by: Aneesh V
...
> +void board_init_r(gd_t *id, ulong dummy)
> +{
> + for (;;)
> + ;
> +}
Also, th
Dear Aneesh V,
In message <1305472900-4004-10-git-send-email-ane...@ti.com> you wrote:
> Adapted from: nand_spl/board/samsung/smdk6400/Makefile
>
> - Add the SPL makefile for OMAP4430 SDP
> - Add the necessary CONFIG flags in the board config file
>
> Signed-off-by: Aneesh V
> ---
> V2:
> * Ch
Dear Aneesh V,
In message <1305472900-4004-11-git-send-email-ane...@ti.com> you wrote:
> The basic hardware init of OMAP4(s_init()) can happen in 4
> different contexts:
> 1. SPL running from SRAM
> 2. U-Boot running from FLASH
> 3. Non-XIP U-Boot loaded to SDRAM by SPL
> 4. Non-XIP U-Boot loa
Dear Aneesh V,
In message <1305472900-4004-16-git-send-email-ane...@ti.com> you wrote:
> Add support for the SDRAM controller (EMIF).
>
> Signed-off-by: Aneesh V
> V2:
> * Changes for makefile changes
> * Minor corrections in do_lpddr2_init()
> * Minor corrections to read_idle interval calculati
Dear Aneesh V,
In message <1305472900-4004-16-git-send-email-ane...@ti.com> you wrote:
> Add support for the SDRAM controller (EMIF).
>
> Signed-off-by: Aneesh V
> V2:
> * Changes for makefile changes
> * Minor corrections in do_lpddr2_init()
> * Minor corrections to read_idle interval calculati
Dear Aneesh V,
In message <1305472900-4004-17-git-send-email-ane...@ti.com> you wrote:
> Calculate EMIF register values based on AC timing parameters
> from the SDRAM datasheet and the DDR frequency rather than
> using the hard-coded values.
>
> For a new board the user doen't have to go through
Dear Aneesh V,
In message <1305472900-4004-18-git-send-email-ane...@ti.com> you wrote:
> Identify SDRAM devices connected to EMIF automatically:
> LPDDR2 devices have some Mode Registers that provide details
> about the device such as the type, density, bus width
> etc. EMIF has the capability to
Dear Aneesh V,
In message <1305472900-4004-19-git-send-email-ane...@ti.com> you wrote:
> Embed the u-boot flash image size at a known offset from the
> start of u-boot so that SPL can use it while loading u-boot
> from a non-XIP media.
I don't think this is a good idea.
What you are doing here i
Dear Aneesh V,
In message <1305472900-4004-21-git-send-email-ane...@ti.com> you wrote:
> Signed-off-by: Aneesh V
> ---
> V2:
> * Changes for make file changes
> ---
> include/configs/omap4_sdp4430.h |1 +
> spl/board/ti/omap4.mk |7 +++
> spl/board/ti/spl-omap.c |
Dear Aneesh V,
In message <1305472900-4004-22-git-send-email-ane...@ti.com> you wrote:
> Signed-off-by: Aneesh V
> ---
> V2:
> * Changed CONFIG_SYS_SPL_TEXT_BASE to 0x40304350 for Panda
>This is required for EMU devices
> * Changes due to make file changes
> ---
> arch/arm/cpu/armv7/omap4/
Dear Aneesh V,
In message <1305472900-4004-23-git-send-email-ane...@ti.com> you wrote:
> In SPL console is enabled very early where as in U-Boot
> it's not. So, SPL can have traces in early init code
Console should _always_ be enabled as early as possible,
> while U-Boot can not have it in the s
Wolfgang Denk writes:
> Dear Aneesh V,
>
> In message <1305472900-4004-17-git-send-email-ane...@ti.com> you wrote:
>> Calculate EMIF register values based on AC timing parameters
>> from the SDRAM datasheet and the DDR frequency rather than
>> using the hard-coded values.
>>
>> For a new board t
Dear Kumar Gala,
In message you
wrote:
> The following changes since commit 3500e9aed6e13a988f4a5ef6503112fda1c4a7fc:
> Nobuhiro Iwamatsu (1):
> kwbimage: Fix check variable of checksum
>
> are available in the git repository at:
>
> git://git.denx.de/u-boot-mpc85xx master
>
> Tim
Dear Scott Wood,
In message <20110513161643.ga5...@schlenkerla.am.freescale.net> you wrote:
> The following changes since commit 91081e01b10d64e99dc485e477e6ae3b1171e8ce:
>
> Revert "Fix building tools alone with host compiler" (2011-05-13 13:37:20
> +0200)
>
> are available in the git reposi
On Sun, May 15, 2011 at 3:03 AM, Graeme Russ wrote:
> Couple of thoughts:
> - Macro the definition of show_boot_progress() so it accepts a (const
>char *) argument if CONFIG_BOOTSTAGE is defined
> - Change BOOTSTAGE_COUNT to CONFIG_MAX_BOOTSTAGE_RECORDS
> - Any call to show_boot_progress()
On Sun, May 15, 2011 at 4:53 AM, Wolfgang Denk wrote:
> Dear Simon Glass,
>
> In message <1305319923-9477-1-git-send-email-...@chromium.org> you wrote:
> > This defines the basics of a new boot time measurement feature. This
> allows
> > logging of very accurate time measurements as the boot proc
On Sun, May 15, 2011 at 11:44 AM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message <1305202276-27784-3-git-send-email-ane...@ti.com> you wrote:
> > add utility macros for:
> > * bit field operations
> > * log2n functions
> ...
>
> > +/* extract a bit field from a bit vector */
> > +#define
On Mon, May 16, 2011 at 7:58 AM, Simon Glass wrote:
> On Sun, May 15, 2011 at 4:53 AM, Wolfgang Denk wrote:
>
>> Dear Simon Glass,
>>
>> In message <1305319923-9477-1-git-send-email-...@chromium.org> you wrote:
>> > This defines the basics of a new boot time measurement feature. This
>> allows
>>
On Mon, May 16, 2011 at 7:34 AM, Simon Glass wrote:
> On Sun, May 15, 2011 at 3:03 AM, Graeme Russ wrote:
>>
>> Couple of thoughts:
>> - Macro the definition of show_boot_progress() so it accepts a (const
>> char *) argument if CONFIG_BOOTSTAGE is defined
>> - Change BOOTSTAGE_COUNT to CONFI
commit ed59e58 (Remove device tree booting dependency on CONFIG_SYS_BOOTMAPSZ)
made the
definition of CONFIG_SYS_BOOTMAPSZ unnecessary.
Signed-off-by: Fabio Estevam
---
include/configs/mx53loco.h |1 -
include/configs/mx53smd.h |1 -
2 files changed, 0 insertions(+), 2 deletions(-)
d
On Sunday, May 15, 2011 11:21:19 Aneesh V wrote:
> +static void omapimage_print_header(const void *ptr)
> +{
> + struct ch_toc *toc = (struct ch_toc *)ptr;
you're casting away the void. something is fundamentally broken here.
-mike
signature.asc
Description: This is a digitally signed messa
On Sun, May 15, 2011 at 03:15:46PM -0700, Simon Glass wrote:
> I believe that this problem is getting worse - e.g. USB on Tegra2 writes
> various fields of about 20 registers to get things up and running. I find
> translating SOC datasheet register definitions into C code with shifts and
> masks to
From: Luuk Paulussen
Signed-off-by: Luuk Paulussen
Acked-by: Chris Packham
Cc: Ben Warren
---
Changes since v1:
- fixed compile error in BootpVendorProcess when CONFIG_CMD_SNTP is not
defined
net/bootp.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git
On Sunday, May 15, 2011 21:52:53 Mike Frysinger wrote:
> On Sunday, May 15, 2011 11:21:19 Aneesh V wrote:
> > +static void omapimage_print_header(const void *ptr)
> > +{
> > + struct ch_toc *toc = (struct ch_toc *)ptr;
>
> you're casting away the void. something is fundamentally broken here.
e
serial debug statements might work as a "poor mans" timing implementation, but
i think it makes sense to have a binary framework for this.
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.de
Hi, Fabio,
[...]
> +static void setup_iomux_uart(void)
> +{
> + /* UART1 RXD */
> + mxc_request_iomux(MX53_PIN_ATA_DMACK, IOMUX_CONFIG_ALT3);
> + mxc_iomux_set_pad(MX53_PIN_ATA_DMACK,
> + PAD_CTL_HYS_ENABLE | PAD_CTL_DRV_HIGH |
> +
Hi,
I found memory leak in sh_eth.c.
sh_eth_desc_init call for many times in network problem.
And it every time allocate new descriptor. So leak old descriptor.
I will fix this patch.
diff --git a/drivers/net/sh_eth.c b/drivers/net/sh_eth.c
index 17dd0d2..f805785 100644
--- a/drivers/net/sh_eth.
Dear Simon Glass,
In message you wrote:
>
> This is 100us which is pretty good although you are assuming that there is
> no FIFO holding things. Also on modern ARM CPUs the 'processing' part of
I don't see that we use any FIFOs in the output direction.
> U-Boot (where it is not just waiting on
Hi,Stefano,
2011/5/11 Jason Liu :
> Hi, Stefano,
>
> 2011/4/22 Jason Liu :
>> The boot cause code has been factor out to soc common
>> code,we need drop the part from the board support code
>>
>> This patch also remove the redundant cpu version print
>>
>> Signed-off-by: Jason Liu
>> ---
>> chang
Dear Simon Glass,
In message you wrote:
>
> Being a boot loader, charged with basic hardware initialisation, I believe
> bitfield access primitives should be well-supported by U-Boot.
I agree, and they are.
> Would you consider an RFC patch to add pan-U-Boot bitfield operations?
> Failing that,
Dear Graeme Russ,
In message you wrote:
>
> But at 9600 baud it is over 1ms - 9600 is still considered the lowest
> common denominator for serial comms for diagnostic output for a lot of
> devices such as industrial PLCs etc.
I think in the last 5 years I have seen but 2 devices using 9600 bps.
Dear Graeme Russ,
In message you wrote:
>
> I've thought of a 'better' approach:
> - Do no modify the parameters of show_boot_progress()
> - Create a new struct:
> struct boot_progress_msg {
> int boot_progress_id;
> const char *message;
> {
Where do you store this data _
Hi, Stefano,
2011/4/13 Jason Liu :
> Add clock config interface support, so that we
> can configure CPU or DDR clock in the later init
>
> Signed-off-by: Jason Liu
> ---
> arch/arm/cpu/armv7/mx5/clock.c | 551
> +-
> arch/arm/include/asm/arch-mx5/clock.h
On Mon, May 16, 2011 at 3:56 PM, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message you wrote:
>>
>> I've thought of a 'better' approach:
>> - Do no modify the parameters of show_boot_progress()
>> - Create a new struct:
>> struct boot_progress_msg {
>> int boot_progress_id;
>>
On Mon, May 16, 2011 at 3:55 PM, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message you wrote:
>>
>> But at 9600 baud it is over 1ms - 9600 is still considered the lowest
>> common denominator for serial comms for diagnostic output for a lot of
>> devices such as industrial PLCs etc.
>
> I t
On 05/16/2011 07:48 AM, Jason Liu wrote:
> Hi,Stefano,
>
> Any comments, if not, please pull it, thanks.
No, I have not. I will pull it.
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk &
On 04/22/2011 02:55 PM, Jason Liu wrote:
> The boot cause code has been factor out to soc common
> code,we need drop the part from the board support code
>
> This patch also remove the redundant cpu version print
>
Applied to u-boot-imx, thanks.
Best regards,
Stefano Babic
--
On Mon, May 16, 2011 at 3:48 PM, Wolfgang Denk wrote:
> Dear Simon Glass,
>
> In message you wrote:
>>
>> This is 100us which is pretty good although you are assuming that there is
>> no FIFO holding things. Also on modern ARM CPUs the 'processing' part of
>
> I don't see that we use any FIFOs in
On 05/16/2011 08:04 AM, Jason Liu wrote:
> Hi, Stefano,
>
Hi Jason,
> The clock code has been submitted to mail-list for more than one
> month, any comments for it?
> Since you are the imx custodian, you need quick review the patch
> related to imx, right?
Because the clock patch was part of a
100 matches
Mail list logo
