-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/07/13 16:43, Tom Rini wrote:
> On 12/30/2012 01:13 AM, Nikita Kiryanov wrote:
>> Gentle ping.
>
>> On 12/03/2012 02:19 PM, Nikita Kiryanov wrote:
>>> This patchset implements card detection and write protection
>>> check for omap mmc. The write
Add support for user defined lcd parameters for cm-t35 splash screen.
Cc: Jeroen Hofstee
Cc: Anatolij Gustschin
Signed-off-by: Nikita Kiryanov
Signed-off-by: Igor Grinberg
---
Changes in V2:
- Set gfx_format to GFXFORMAT_RGB16 after parsing custom lcd settings.
board/cm_t35/display.c
When the bmp file is loaded to an address specified by the environment
variable "splashimage", its header members might be unaligned.
This happens because the bmp header starts with two byte size fields followd by
mostly 32 bit fields. When the address in splashimage is not equal to aligned
address
Currently there is no logical place to put the code that prepares the
splash image data. The splash image data should be ready in memory
before bmp_display() is called, and after the environment is ready
(since lcd.c looks for the splash image in an address specified by
the environment variable "sp
Add support for dvi displays with user selectable dvi presets.
Cc: Wolfgang Denk
Cc: Jeroen Hofstee
Cc: Anatolij Gustschin
Signed-off-by: Nikita Kiryanov
Signed-off-by: Igor Grinberg
---
Changes in V3:
- Added a #define for CMAP [Wolfgang Denk]
Changes in V2:
- Used LCD_BPP f
Currently, omap3_dss_panel_config() sets gfx_format to a value that is hardcoded
in the code. This forces anyone who wants to use a different gfx_format to make
adjustments after calling omap3_dss_panel_config(). This could be avoided if the
value of gfx_format were parameterized as input for omap3
Add support for loading splash image from NAND
Cc: Anatolij Gustschin
Cc: Jeroen Hofstee
Signed-off-by: Nikita Kiryanov
Signed-off-by: Igor Grinberg
---
Changes in V2:
- Added fix to bmp_load_addr to comply with what happens in lcd.c
following patch number 3.
board/cm_t35/cm_
Add useful omap3 dss defines for: polarity, TFT data lines, lcd
display type, gfx burst size, and gfx format
Cc: Anatolij Gustschin
Cc: Jeroen Hofstee
Cc: Tom Rini
Cc: Wolfgang Denk
Signed-off-by: Nikita Kiryanov
Signed-off-by: Igor Grinberg
---
Changes in V3:
- Removed unused #defin
This patchset adds splash screen support for CM-T35.
It includes the ability to initialize the display subsystem either using
predefines (selected via env variable "displaytype"), or user supplied
configuration options, also stored in an environment variables and pointed to by
displaytype. The spla
On Fri, Jan 18, 2013 at 7:42 PM, Scott Wood wrote:
> This saved 640 bytes on MPC8536DS (a board with two of the six
> ports defined).
>
> Signed-off-by: Scott Wood
I noticed the same issue on SPL builds.
Ack.
-M
> ---
> drivers/serial/serial_ns16550.c | 12
> 1 file changed, 1
Dear Lubomir Rintel,
In message <1359589584-19846-1-git-send-email-lkund...@v3.sk> you wrote:
> In certain cases, memory device is present as flat file or block device (via
> mmc or mtdblock layer). Do not attempt MTD operations against it.
What exactly would be such cases?
> diff --git a/tools/
Set the device tree property associated with the mpic source
frequency. The frequency is used for mpic timer.
Signed-off-by: Wang Dongsheng
---
arch/powerpc/cpu/mpc85xx/fdt.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/fdt.c b/arch/powerp
ES2.0 is the latest silicon revision for OMAP543X socs. The SOC
supports enhanced opps for MPU (up to 1.5GHz). This series essentially
adds the support for both 5430 and 5432 versions.
This is on top of the below U-Boot cleanup series.
http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/15256
From: Lokesh Vutla
After power-up SRCOMP cells are by-passed by default in OMAP5.
Software has to enable these SRCOMP sells.
For ES2: All 5 SRCOMP cells needs to be enabled.
For ES1: Only 4 SRCOMP cells in core power domain are enabled.
The 1 in wkup domain is not enabled because smart i
From: Lokesh Vutla
Add pre calculated timing settings of LPDDR2 and DDR3 memories
present in OMAP5430 and OMAP5432 ES2.0 versions.
Also adding the DDR pad io settings required for
OMAP543X SOCs here.
Signed-off-by: Lokesh Vutla
Signed-off-by: R Sricharan
---
arch/arm/cpu/armv7/omap5/hw_data.
PRCM register addresses are changed from ES1.0 to ES2.0 due to
PER power domain getting moved to CORE power domain.
So adding the nessecary register changes for the same.
Signed-off-by: R Sricharan
---
arch/arm/cpu/armv7/omap5/hw_data.c |4 +
arch/arm/cpu/armv7/omap5/prcm-regs.c | 283 ++
Change OPP settings as per the latest 0.4 version of
addendum for OMAP5430 ES2.0
Signed-off-by: Lokesh Vutla
Signed-off-by: R Sricharan
---
arch/arm/cpu/armv7/omap-common/clocks-common.c |4 +
arch/arm/cpu/armv7/omap4/hw_data.c | 140 +++---
arch/arm/cpu/armv7/omap5/hw_
Adding the CPU detection suport for OMAP5430 and
OMAP5432 ES2.0 SOCs.
Signed-off-by: R Sricharan
---
arch/arm/cpu/armv7/omap5/hwinit.c | 13 +++--
arch/arm/include/asm/arch-omap5/omap.h |2 ++
arch/arm/include/asm/armv7.h |1 +
arch/arm/include/asm/omap_common.h
The pmic code is duplicated for OMAP 4 and 5.
Instead move the data to Soc specific place and
share the code.
Signed-off-by: R Sricharan
---
arch/arm/cpu/armv7/omap-common/clocks-common.c | 79 +--
arch/arm/cpu/armv7/omap4/Makefile |1 -
arch/arm/cpu/armv7/omap4/cl
From: Lokesh Vutla
A seperate omap_sys_ctrl_regs structure is defined for
omap4 & 5. If there is any change in control module for
any of the ES versions, a new structure needs to be created.
In order to remove this dependency, making the register
structure generic for all the omap4+ boards.
Sign
From: Lokesh Vutla
There is some code duplication in the ddr io settings code.
This is avoided by moving the data to a Soc specific place and
letting the code generic.
This avoids unnessecary code addition for future socs.
Signed-off-by: Lokesh Vutla
---
arch/arm/cpu/armv7/omap5/hw_data.c
From: Lokesh Vutla
Removing the duplicated code in ddr3 initialization.
Also creating structure for lpddr2 mode registers to
avoid unnessecary revision checks.
These change reduces code addition for future Socs.
Signed-off-by: R Sricharan
Signed-off-by: Lokesh Vutla
---
arch/arm/cpu/armv7/om
From: Lokesh Vutla
Now SDRAM initialization is done on the basis of omap revision.
Instead this should be done on basis of SDRAM type read from
EMIF_SDRAM_CONFIG register. This will be helpful to avoid
unnessecary cpu checks for new boards
Signed-off-by: R Sricharan
Signed-off-by: Lokesh Vutla
This series is intended to cleanup code which is duplicated
across soc specific files. This is accomplished by moving soc
specifc data to one place and having the code common. This
helps in avoiding un necessary cpu checks and minimal
code addition for future socs.
Tested this on OMAP5 ES1.0, OMAP
In certain cases, memory device is present as flat file or block device (via
mmc or mtdblock layer). Do not attempt MTD operations against it.
---
tools/env/fw_env.c | 21 -
tools/env/fw_env.config |3 +++
2 files changed, 19 insertions(+), 5 deletions(-)
diff --git
Dear Jaehoon,
>Jaehoon Chung samsung.com> writes:
>
> Support to check whether the SD3.0 or not.
>
> Signed-off-by: Jaehoon Chung samsung.com>
> Signed-off-by: Kyungmin Park samsung.com>
> ---
> drivers/mmc/mmc.c |2 ++
> include/mmc.h |1 +
> 2 files changed, 3 insertions(+), 0
Dear Jagannadha,
>Jagannadha Sutradharudu Teki xilinx.com>
writes:
>
> Hi Andy,
>
> The latest patch "mmc: Properly determine maximum supported bus width"
> (sha1: 7798f6dbd5e1a3030ed81a81da5dfb57c3307cac) is causing some error status
issue on
> zynq platform with MMC Plus cards.
>
> Here t
From: Daniel Schwierzeck
Signed-off-by: Daniel Schwierzeck
---
arch/mips/cpu/mips32/start.S | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/arch/mips/cpu/mips32/start.S b/arch/mips/cpu/mips32/start.S
index 51ce914..65acf7d 100644
--- a/arch/mips/cpu/mips32/start.S
On Wed, Jan 30, 2013 at 04:31:42PM -0800, Tom Rini wrote:
> * PGP Signed by an unknown key
>
> On Wed, Jan 30, 2013 at 03:04:53PM -0800, Allen Martin wrote:
> > On Tue, Jan 22, 2013 at 06:12:47AM -0800, Simon Glass wrote:
> > > On Tue, Jan 22, 2013 at 2:15 AM, Lucas Stach wrote:
> > > > No one ex
On Tue, Jan 22, 2013 at 12:15:49AM -, Lucas Stach wrote:
> No one expects to end up in a delayed environment if
> CONFIG_DELAY_ENVIRONMENT isn't defined.
>
> Signed-off-by: Lucas Stach
> Acked-by: Simon Glass
> Acked-by: Allen Martin
Applied to u-boot/master, thanks!
--
Tom
From: Daniel Schwierzeck
Adopt reset vector handling from Yamon.
Signed-off-by: Daniel Schwierzeck
---
arch/mips/cpu/mips32/start.S | 185 +--
arch/mips/cpu/mips64/start.S | 55 +++--
2 files changed, 64 insertions(+), 176 deletions(-)
diff --g
On Wed, Jan 30, 2013 at 03:04:53PM -0800, Allen Martin wrote:
> On Tue, Jan 22, 2013 at 06:12:47AM -0800, Simon Glass wrote:
> > On Tue, Jan 22, 2013 at 2:15 AM, Lucas Stach wrote:
> > > No one expects to end up in a delayed environment if
> > > CONFIG_DELAY_ENVIRONMENT isn't defined.
> > >
> > >
On Thu, Jan 31, 2013 at 01:21:39AM +0100, Daniel Schwierzeck wrote:
> The following changes since commit 54b08efcf2f4ff532ce99c53f341a59c193331a5:
>
> README.mips: update known issues and TODOs (2013-01-16 10:52:08 +0100)
>
> are available in the git repository at:
>
> git://git.denx.de/u-b
2013/1/30 Gabor Juhos :
> This patch-set adds an unfied u-boot.lds file for the MIPS
> architecture, and removes the linker scripts of the individual
> boards.
>
> The series depends on the following patch:
> MIPS: remove OUTPUT_FORMAT from linker scripts
> http://patchwork.ozlabs.org/patch/216
2013/1/30 Gabor Juhos :
> The OUTPUT_FORMAT command in linker scripts
> was always misused due to some endianess and
> toolchain problems.
>
> Use GCC flags to ensure proper output format,
> and get rid of the OUTPUT_FORMAT commands in
> the board specific u-boot.lds files.
>
> Signed-off-by: Gabor
2013/1/30 Gabor Juhos :
> The current code uses four instructions and a
> temporary register to calculate the relocation
> offset and to adjust the gp register.
>
> The relocation offset can be calculated directly
> from the CONFIG_SYS_MONITOR_BASE constant and from
> the destination address. The r
2013/1/30 Gabor Juhos :
> The difference between the address of the original
> and the relocated _GLOBAL_OFFSET_TABLE_ is always
> the same as the relocation offset.
>
> The relocation offset is already computed and it is
> available in the 's1/t6' register. Use that to adjust
> the relocated _G_O_
On Wed, Jan 30, 2013 at 03:09:56PM -0800, York Sun wrote:
> On 01/30/2013 02:53 PM, Allen Martin wrote:
> > On Wed, Jan 30, 2013 at 11:47:57AM -0800, York Sun wrote:
> >> On 01/30/2013 11:40 AM, Allen Martin wrote:
> >>> On Wed, Jan 30, 2013 at 10:37:30AM -0800, York Sun wrote:
> On 01/24/2013
Yes. I have some internal review stuff to finish, but I will get to MMC
next.
On Wed, Jan 30, 2013 at 5:17 PM, Tom Rini wrote:
> On Wed, Jan 30, 2013 at 11:34:47AM -0600, Andy Fleming wrote:
>
> > Merge branch 'master' of git://git.denx.de/u-boot-i2c (2013-01-29
> 15:36:27 -0500)
> >
> > are
On Wed, Jan 30, 2013 at 11:34:47AM -0600, Andy Fleming wrote:
> Merge branch 'master' of git://git.denx.de/u-boot-i2c (2013-01-29 15:36:27
> -0500)
>
> are available in the git repository at:
>
>
> git://www.denx.de/git/u-boot-mpc85xx.git master
>
> for you to fetch changes up to d4ed6542
On 01/30/2013 02:53 PM, Allen Martin wrote:
> On Wed, Jan 30, 2013 at 11:47:57AM -0800, York Sun wrote:
>> On 01/30/2013 11:40 AM, Allen Martin wrote:
>>> On Wed, Jan 30, 2013 at 10:37:30AM -0800, York Sun wrote:
On 01/24/2013 05:00 PM, Allen Martin wrote:
> I think you can drop the RFC fr
On Tue, Jan 22, 2013 at 06:12:47AM -0800, Simon Glass wrote:
> On Tue, Jan 22, 2013 at 2:15 AM, Lucas Stach wrote:
> > No one expects to end up in a delayed environment if
> > CONFIG_DELAY_ENVIRONMENT isn't defined.
> >
> > Signed-off-by: Lucas Stach
>
> Good with me, and solves the immediate pr
On Wed, Jan 30, 2013 at 11:47:57AM -0800, York Sun wrote:
> On 01/30/2013 11:40 AM, Allen Martin wrote:
> > On Wed, Jan 30, 2013 at 10:37:30AM -0800, York Sun wrote:
> >> On 01/24/2013 05:00 PM, Allen Martin wrote:
> >>> I think you can drop the RFC from your patch at this point.
> >>>
> >>> Built
All the users of mx6q_4x_mt41j128.cfg (DDR3-1333H Micron MT41J128M16HA-15E or SK
hynix H5TQ2G63BFR-H9C for i.MX6Q SABRE Lite, and DDR3-1600K Micron
MT41K128M16JT-125:K for i.MX6 SABRE SD) support the optional down binning to
DDR3-1066F (CL = 7, CWL = 6), which is possible at 532 MHz, so use it.
In
MMDC1_MDOR.SDE_to_RST should be set to 200 µs according to the JEDEC
specification for DDR3. With a cycle of 15.258 µs, this gives 14 cycles encoded
as 0x10 for the bit-field MMDC1_MDOR[13:8].
Signed-off-by: Benoît Thébaudeau
---
board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg |2 +-
1 file cha
MR0.PPD should be set as in MMDCx_MDPDC.SLOW_PD, i.e. to fast-exit mode, which
is encoded as 1 in MRS.LMR.MR0.A12 and MMDCx_MDSCR[28].
Signed-off-by: Benoît Thébaudeau
---
board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/boar
MMDC1_MDOR.RST_to_CKE should be set to 500 µs according to the JEDEC
specification for DDR3. With a cycle of 15.258 µs, this gives 33 cycles encoded
as 0x23 for the bit-field MMDC1_MDOR[5:0].
Signed-off-by: Benoît Thébaudeau
---
board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg |2 +-
1 file chan
MMDC1_MDCFG1.tMRD should be set to max(tMRD, tMOD) for DDR3.
For all DDR3 speed bins:
tMRD(min) = 4 nCK
tMOD(min) = max(12 nCK, 15 ns)
Hence, MMDC1_MDCFG1.tMRD should be set to max(12 nCK, 15 ns), which is 12 nCK
at 532 MHz, encoded as 0xB in the bit-field MMDC1_MDCFG1[8:5].
Signed-off-by: B
MMDC1_MDOR.tXPR should be set as specified for the JEDEC DDR3 timing tXPR.
For all DDR3 speed bins:
tXPR(min) = max(5 nCK, tRFC(min) + 10 ns)
tRFC(2 Gb) = 160 ns
All the users of mx6q_4x_mt41j128.cfg have a 2-Gb density (Micron
MT41J128M16HA-15E or SK hynix H5TQ2G63BFR-H9C for i.MX6Q SABRE Li
On 01/30/2013 11:40 AM, Allen Martin wrote:
> On Wed, Jan 30, 2013 at 10:37:30AM -0800, York Sun wrote:
>> On 01/24/2013 05:00 PM, Allen Martin wrote:
>>> I think you can drop the RFC from your patch at this point.
>>>
>>> Built on all tegra20 and tegra30 devices with USE_PRIVATE_LIBGCC.
>>> Tested
On Wed, Jan 30, 2013 at 10:37:30AM -0800, York Sun wrote:
> On 01/24/2013 05:00 PM, Allen Martin wrote:
> > I think you can drop the RFC from your patch at this point.
> >
> > Built on all tegra20 and tegra30 devices with USE_PRIVATE_LIBGCC.
> > Tested on seaboard (tegra20).
> >
> > I've also sub
Dear Stijn,
In message <405242335239dd41a819b4b5f37e07d618334...@xmb-rcd-x04.cisco.com> you
wrote:
>
> I want to read files from an ext2 filesystem stored in a flash that is mapp
> ed to a physical address range. To be able to use the ext2 commands I think
> what I need is a block device (block_
On 01/24/2013 05:00 PM, Allen Martin wrote:
> I think you can drop the RFC from your patch at this point.
>
> Built on all tegra20 and tegra30 devices with USE_PRIVATE_LIBGCC.
> Tested on seaboard (tegra20).
>
> I've also submitted your patch to my build regression script which
> will build all 1
On Tue, Jan 22, 2013 at 02:15:49AM -0800, Lucas Stach wrote:
> No one expects to end up in a delayed environment if
> CONFIG_DELAY_ENVIRONMENT isn't defined.
>
> Signed-off-by: Lucas Stach
> ---
> v2: keep preference of CONFIG_OF_CONTROL and just change default value
> ---
> arch/arm/lib/board.c
I'd like to get some feedback on this patch set which adds support
for our Nitrogen6X series of boards because this patch introduces
some additional feature for i.MX6x processors specifically, but
possibly other i.MX processors as well.
To give a little background, we're supporting a variety of
i
Dear Otavio Salvador,
> On Wed, Jan 30, 2013 at 2:15 PM, Marek Vasut wrote:
> > Dear Otavio Salvador,
> >
> >> On Wed, Jan 30, 2013 at 2:05 PM, Marek Vasut wrote:
> >> > Dear Otavio Salvador,
> >> >
> >> >> On Wed, Jan 30, 2013 at 1:39 PM, Marek Vasut wrote:
> >> >> > Dear Otavio Salvador,
>
Hi all,
I want to read files from an ext2 filesystem stored in a flash that is mapped
to a physical address range. To be able to use the ext2 commands I think what I
need is a block device (block_dev_desc_t) that treats an address range as a
block device.
Does something like this already exist
Hi all,
I'm trying to figure out how to boot my Linux kernel and fs image from two
files stored on a jffs2 parition. I'm using uClinux and have been just
booting a combined kernel+romfs image stored directly in flash. I need to
split the kernel and rootfs apart (in this product, the kernel almos
On Tue, Jan 29, 2013 at 10:08:39PM -0800, Lucas Stach wrote:
> Hi Allen,
>
> Am Dienstag, den 29.01.2013, 19:05 -0800 schrieb Allen Martin:
>
> > The problem I'm seeing is that this regressed environment loading on
> > all boards that use fdt, because none of them have
> > /config/load-environmen
Merge branch 'master' of git://git.denx.de/u-boot-i2c (2013-01-29 15:36:27
-0500)
are available in the git repository at:
git://www.denx.de/git/u-boot-mpc85xx.git master
for you to fetch changes up to d4ed6542788169b789c7eed142efc0a6fa5ca698:
corenet: Disable video on P2020DS (2013-01-3
On Wed, Jan 30, 2013 at 2:15 PM, Marek Vasut wrote:
> Dear Otavio Salvador,
>
>> On Wed, Jan 30, 2013 at 2:05 PM, Marek Vasut wrote:
>> > Dear Otavio Salvador,
>> >
>> >> On Wed, Jan 30, 2013 at 1:39 PM, Marek Vasut wrote:
>> >> > Dear Otavio Salvador,
>> >> >
>> >> >> On Wed, Jan 30, 2013 at 12
Dear Otavio Salvador,
> On Wed, Jan 30, 2013 at 2:06 PM, Marek Vasut wrote:
> > Dear Otavio Salvador,
> >
> > [...]
> >
> >> >> In this case I'd prefer to add support for the hub only in the
> >> >> previous patch and left the ethernet support on this with the env.
> >> >>
> >> >> Makes sense?
Dear Otavio Salvador,
> On Wed, Jan 30, 2013 at 2:05 PM, Marek Vasut wrote:
> > Dear Otavio Salvador,
> >
> >> On Wed, Jan 30, 2013 at 1:39 PM, Marek Vasut wrote:
> >> > Dear Otavio Salvador,
> >> >
> >> >> On Wed, Jan 30, 2013 at 12:13 PM, Marek Vasut wrote:
> >> >> > Dear Otavio Salvador,
>
On Wed, Jan 30, 2013 at 2:06 PM, Marek Vasut wrote:
> Dear Otavio Salvador,
>
> [...]
>
>> >> In this case I'd prefer to add support for the hub only in the
>> >> previous patch and left the ethernet support on this with the env.
>> >>
>> >> Makes sense?
>> >
>> > The hub and the ethernet are the
On Wed, Jan 30, 2013 at 2:05 PM, Marek Vasut wrote:
> Dear Otavio Salvador,
>
>> On Wed, Jan 30, 2013 at 1:39 PM, Marek Vasut wrote:
>> > Dear Otavio Salvador,
>> >
>> >> On Wed, Jan 30, 2013 at 12:13 PM, Marek Vasut wrote:
>> >> > Dear Otavio Salvador,
>> >> >
>> >> >> This allow user to know i
Dear Otavio Salvador,
[...]
> >> In this case I'd prefer to add support for the hub only in the
> >> previous patch and left the ethernet support on this with the env.
> >>
> >> Makes sense?
> >
> > The hub and the ethernet are the same chip, thus it makes no sense to
> > have two patches for t
Dear Otavio Salvador,
> On Wed, Jan 30, 2013 at 1:39 PM, Marek Vasut wrote:
> > Dear Otavio Salvador,
> >
> >> On Wed, Jan 30, 2013 at 12:13 PM, Marek Vasut wrote:
> >> > Dear Otavio Salvador,
> >> >
> >> >> This allow user to know if the bootloader is running, even without a
> >> >> serial co
On Wed, Jan 30, 2013 at 1:55 PM, Marek Vasut wrote:
> Dear Otavio Salvador,
>
>> On Wed, Jan 30, 2013 at 1:38 PM, Marek Vasut wrote:
>> > Dear Otavio Salvador,
>> >
>> >> On Wed, Jan 30, 2013 at 12:12 PM, Marek Vasut wrote:
>> >> > Dear Otavio Salvador,
>> >> >
>> >> >> Adjust HW_DRAM_CTL14 to e
Dear Otavio Salvador,
> On Wed, Jan 30, 2013 at 1:38 PM, Marek Vasut wrote:
> > Dear Otavio Salvador,
> >
> >> On Wed, Jan 30, 2013 at 12:12 PM, Marek Vasut wrote:
> >> > Dear Otavio Salvador,
> >> >
> >> >> Adjust HW_DRAM_CTL14 to enable the chip selects to allow usage of
> >> >> full 128MB o
On Wed, Jan 30, 2013 at 1:40 PM, Marek Vasut wrote:
> Dear Otavio Salvador,
>
>> On Wed, Jan 30, 2013 at 12:18 PM, Marek Vasut wrote:
>> > Dear Otavio Salvador,
>> >
>> >> This adds support to the LAN9512 chip included in the board and extend
>> >> the environment to easy netboot use.
>> >>
>> >>
On Wed, Jan 30, 2013 at 1:39 PM, Marek Vasut wrote:
> Dear Otavio Salvador,
>
>> On Wed, Jan 30, 2013 at 12:13 PM, Marek Vasut wrote:
>> > Dear Otavio Salvador,
>> >
>> >> This allow user to know if the bootloader is running, even without a
>> >> serial console.
>> >>
>> >> Signed-off-by: Otavio
On Wed, Jan 30, 2013 at 1:38 PM, Marek Vasut wrote:
> Dear Otavio Salvador,
>
>> On Wed, Jan 30, 2013 at 12:12 PM, Marek Vasut wrote:
>> > Dear Otavio Salvador,
>> >
>> >> Adjust HW_DRAM_CTL14 to enable the chip selects to allow usage of full
>> >> 128MB of RAM.
>> >>
>> >> Signed-off-by: Otavio
Dear Otavio Salvador,
> On Wed, Jan 30, 2013 at 12:18 PM, Marek Vasut wrote:
> > Dear Otavio Salvador,
> >
> >> This adds support to the LAN9512 chip included in the board and extend
> >> the environment to easy netboot use.
> >>
> >> Signed-off-by: Otavio Salvador
> >> ---
> >>
> >> board/o
Dear Otavio Salvador,
> On Wed, Jan 30, 2013 at 12:13 PM, Marek Vasut wrote:
> > Dear Otavio Salvador,
> >
> >> This allow user to know if the bootloader is running, even without a
> >> serial console.
> >>
> >> Signed-off-by: Otavio Salvador
> >
> > Uh oh, how does this know which GPIO to to
Dear Otavio Salvador,
> On Wed, Jan 30, 2013 at 12:12 PM, Marek Vasut wrote:
> > Dear Otavio Salvador,
> >
> >> Adjust HW_DRAM_CTL14 to enable the chip selects to allow usage of full
> >> 128MB of RAM.
> >>
> >> Signed-off-by: Otavio Salvador
> >
> > Just enable the full set for all in the ge
On Wed, Jan 30, 2013 at 12:18 PM, Marek Vasut wrote:
> Dear Otavio Salvador,
>
>> This adds support to the LAN9512 chip included in the board and extend
>> the environment to easy netboot use.
>>
>> Signed-off-by: Otavio Salvador
>> ---
>> board/olimex/mx23_olinuxino/mx23_olinuxino.c | 6 +
On Wed, Jan 30, 2013 at 12:17 PM, Marek Vasut wrote:
> Dear Otavio Salvador,
>
>> The i.MX23 just one USB port so disable the second controller probe
>> when building for i.MX23.
>>
>> Signed-off-by: Otavio Salvador
>> ---
>> drivers/usb/host/ehci-mxs.c | 2 ++
>> 1 file changed, 2 insertions(+)
On Wed, Jan 30, 2013 at 12:13 PM, Marek Vasut wrote:
> Dear Otavio Salvador,
>
>> This allow user to know if the bootloader is running, even without a
>> serial console.
>>
>> Signed-off-by: Otavio Salvador
>
> Uh oh, how does this know which GPIO to toggle to drive the led this time ?
The probl
On Wed, Jan 30, 2013 at 12:12 PM, Marek Vasut wrote:
> Dear Otavio Salvador,
>
>> Adjust HW_DRAM_CTL14 to enable the chip selects to allow usage of full
>> 128MB of RAM.
>>
>> Signed-off-by: Otavio Salvador
>
> Just enable the full set for all in the generic memory register set
> (dram_vals)?
P
On Wed, Jan 30, 2013 at 12:11 PM, Marek Vasut wrote:
> Dear Otavio Salvador,
>
>> The power switch option is compatible with i.MX23 and i.MX28 so the
>> configration option needs to reflect it. We choose
>> 'CONFIG_SPL_MXS_PSWITCH_WAIT' for the option name.
>
> Acked-by: Marek Vasut
>
> I'm missi
On Wed, Jan 30, 2013 at 12:10 PM, Marek Vasut wrote:
> Dear Otavio Salvador,
>
>> Add a comment about the tRAS lockout setting of HW_DRAM_CTL08 to
>> enable the 'Fast Auto Pre-Charge' found in the memory chip. The
>> setting is applied after memory initialization and it is worth
>> document it.
>>
Laxman,
On Wed, Jan 30, 2013 at 12:01 AM, Laxman Dewangan wrote:
>
> Tegra30 i2c driver will not work as straight. There is los of change which
> need to be taken care.
>
> I posted the change for kernel driver.
> Changes are:
> - Enable/disable control for per packet transfer complete interrupt.
Dear "Altunbas Sabri (DC-IA/EAH2)",
In message
you wrote:
>
> i had a look at the u-boot cmd's. I can read/write a file from/to a dos par
> tition but I didn't find a command for partitioning and formatting a device.
No, you cannot (at least not unless you are willing to manually build
the boo
2013.01.30. 15:34 keltezéssel, Stefan Roese írta:
> On 01/30/2013 03:31 PM, Gabor Juhos wrote:
>> The patch adds an unified linker script file which
>> can be used for all currently supported MIPS targets.
>>
>> Signed-off-by: Gabor Juhos
>> Cc: Daniel Schwierzeck
>> Cc: Stefan Roese
>> Cc: Wolf
The difference between the address of the original
and the relocated _GLOBAL_OFFSET_TABLE_ is always
the same as the relocation offset.
The relocation offset is already computed and it is
available in the 's1/t6' register. Use that to adjust
the relocated _G_O_T_ address, instead of calculating
th
The current code uses four instructions and a
temporary register to calculate the relocation
offset and to adjust the gp register.
The relocation offset can be calculated directly
from the CONFIG_SYS_MONITOR_BASE constant and from
the destination address. The resulting offset can
be used to adjust
On 01/30/2013 03:31 PM, Gabor Juhos wrote:
> The patch adds an unified linker script file which
> can be used for all currently supported MIPS targets.
>
> Signed-off-by: Gabor Juhos
> Cc: Daniel Schwierzeck
> Cc: Stefan Roese
> Cc: Wolfgang Denk
> Cc: Xiangfu Liu
Again, can't test but looks
Remove the board specific linker script. It is not
needed anymore, the unified MIPS linker script can
be used instead.
The qi_lb60 target produces a slightly different
image after the change than before. The value of
'num_got_entries' symbol is different:
@@ -49,7 +49,7 @@
801000b4:
Remove the board specific linker script. It is not
needed anymore, the unified MIPS linker script can
be used instead.
All dbau1x00 targets are producing identical binary
images after the change than before.
Signed-off-by: Gabor Juhos
Cc: Daniel Schwierzeck
---
Changes since v1: ---
---
board/
The patch adds an unified linker script file which
can be used for all currently supported MIPS targets.
Signed-off-by: Gabor Juhos
Cc: Daniel Schwierzeck
Cc: Stefan Roese
Cc: Wolfgang Denk
Cc: Xiangfu Liu
---
Changes since v1:
- use consistent coding style for all sections
- remove the O
Remove the board specific linker script. It is not
needed anymore, the unified MIPS linker script can
be used instead.
All qemu_mips targets are producing identical binary
images after the change than before.
Signed-off-by: Gabor Juhos
Cc: Daniel Schwierzeck
---
Changes since v1: ---
---
board
Remove the board specific linker script. It is not
needed anymore, the unified MIPS linker script can
be used instead.
All pb1x00 targets are producing identical binary
images after the change than before.
Signed-off-by: Gabor Juhos
Cc: Daniel Schwierzeck
---
Changes since v1: ---
---
board/pb
Remove the board specific linker script. It is not
needed anymore, the unified MIPS linker script can
be used instead.
All vct targets are producing identical binary
images after the change than before.
Signed-off-by: Gabor Juhos
Acked-by: Stefan Roese
Cc: Daniel Schwierzeck
---
Changes since
Remove the board specific linker script. It is not
needed anymore, the unified MIPS linker script can
be used instead.
All incaip targets are producing identical binary
images after the change than before.
Signed-off-by: Gabor Juhos
Cc: Daniel Schwierzeck
Cc: Wolfgang Denk
---
Changes since v1
This patch-set adds an unfied u-boot.lds file for the MIPS
architecture, and removes the linker scripts of the individual
boards.
The series depends on the following patch:
MIPS: remove OUTPUT_FORMAT from linker scripts
http://patchwork.ozlabs.org/patch/216892/
Gabor Juhos (7):
MIPS: add
This patch-set adds an unfied u-boot.lds file for the MIPS
architecture, and removes the linker scripts of the individual
boards.
The series depends on the following patch:
MIPS: remove OUTPUT_FORMAT from linker scripts
http://patchwork.ozlabs.org/patch/216892/
Gabor Juhos (7):
MIPS: add
Dear Otavio Salvador,
> This adds support to the LAN9512 chip included in the board and extend
> the environment to easy netboot use.
>
> Signed-off-by: Otavio Salvador
> ---
> board/olimex/mx23_olinuxino/mx23_olinuxino.c | 6 +
> board/olimex/mx23_olinuxino/spl_boot.c | 4 +++
> in
Dear Otavio Salvador,
> The i.MX23 just one USB port so disable the second controller probe
> when building for i.MX23.
>
> Signed-off-by: Otavio Salvador
> ---
> drivers/usb/host/ehci-mxs.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/usb/host/ehci-mxs.c b/drivers/usb/ho
Dear Otavio Salvador,
> This allow user to know if the bootloader is running, even without a
> serial console.
>
> Signed-off-by: Otavio Salvador
Uh oh, how does this know which GPIO to toggle to drive the led this time ?
> ---
> board/olimex/mx23_olinuxino/mx23_olinuxino.c | 7 +++
> bo
Dear Otavio Salvador,
> Adjust HW_DRAM_CTL14 to enable the chip selects to allow usage of full
> 128MB of RAM.
>
> Signed-off-by: Otavio Salvador
Just enable the full set for all in the generic memory register set (dram_vals)?
> ---
> board/freescale/mx23evk/spl_boot.c | 10 ++
> 1 fi
1 - 100 of 128 matches
Mail list logo
