On Thu, Jan 24, 2013 at 13:10:56, Maxim Podbereznyy wrote:
> Hi!
>
> I want to add a new board support to u-boot. So I did the following:
>
> 1) git clone git://git.denx.de/u-boot.git u-boot-dev
> 2) modified existing files, added new
Use "git commit" to commit your changes to tree
> 3) built t
Hello,
On Thu, 24 Jan 2013 02:33:31 +
Xie Shaohui-B21989 wrote:
...
> > currently I do not have access to the p2041rdb board, but here is the
> > previously captured boot log where I've seen this:
> >
> >
> > U-Boot 2011.09-0-g2c02d1d (Oct 22 2011 - 18:31:36)
> >
> [S.H] Did you try th
Hi,
Is there any active raspberry pi development going on, i am planning
to do a support package for raspberry pi, any suggestions would be
welcome.
thanks,
Haneef.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boo
Scott, I reverted this patch, and it fixed some build errors:
20001122-1.c:1:0: error: E500 and FPRs not supported
20010114-2.c:1:0: error: E500 and FPRs not supported
make[2]: ***
[/local/afleming/u-boot/build/P2020DS/post/lib_powerpc/fpu/20001122-1.o]
Error 1
make[2]: *** Waiting for unfinished
I'm seeing these errors, when these patches are enabled:
/local/afleming/u-boot/build/B4420QDS_SPIFLASH/include2/asm/config_mpc85xx.h:575:2:
error: #error Processor type not defined for this platform
/local/afleming/u-boot/build/B4420QDS_SPIFLASH/include2/asm/config_mpc85xx.h:579:2:
error: #error
On Thu, Jan 24, 2013 at 13:51:30, Maxim Podbereznyy wrote:
> Hi Gururaja!
1st don’t top-most. It breaks the flow.
>
>
> Your instructions are exceptional! However I have a few questions:
>
> 1) why should I generate patches for 1st 3 patch, because I have only
> one?
That was just an example.
Hi Gururaja!
Your instructions are exceptional! However I have a few questions:
1) why should I generate patches for 1st 3 patch, because I have only one?
2) if there are 3 patches (only 1 is mine) + a cover which exactly
should I send?
thanks!
2013/1/24 Hebbar, Gururaja
> On Thu, Jan 24, 20
On 01/24/13 00:13, Jeroen Hofstee wrote:
> Hello Nikita,
>
> On 01/23/2013 09:31 AM, Nikita Kiryanov wrote:
>> On 01/21/2013 09:14 PM, Jeroen Hofstee wrote:
>>> Hello Nikita,
>>>
>>> On 01/21/2013 08:51 AM, Nikita Kiryanov wrote:
Hi Jeroen,
On 01/20/2013 10:34 PM, Jeroen Hofstee wro
Hi Maxim,
Le Thu, 24 Jan 2013 12:21:30 +0400,
Maxim Podbereznyy a écrit :
> Your instructions are exceptional! However I have a few questions:
> 1) why should I generate patches for 1st 3 patch, because I have only one?
> 2) if there are 3 patches (only 1 is mine) + a cover which exactly
> shoul
Mats Kärrman wrote on 2013/01/23 22:58:56:
>
> Dear Wolfgang Denk,
>
> >> Found that it was looping endlessly in
arch/powerpc/lib/ticks.S::wait_ticks
> (). Reverting commit "ppc: Create a stack frame for wait_ticks()" made
> everything work again.
> >
> > This makes no sense to me - especial
Joakim Tjernlund/Transmode wrote on 2013/01/24 09:40:45:
> From: Joakim Tjernlund/Transmode
> To: Mats Kärrman ,
> Cc: "u-boot@lists.denx.de" , Wolfgang Denk
> Date: 2013/01/24 09:40
> Subject: RE: [U-Boot] mpc512x: Trouble migrating from 2012.07 to 2013.01
>
> Mats Kärrman wrote on 2013/01/2
On 01/23/13 23:39, Jeroen Hofstee wrote:
> On 01/21/2013 09:12 AM, Nikita Kiryanov wrote:
>>
+else if (!strncmp(displaytype, "dvi800x600", 10))
+return set_dvi_preset(preset_dvi_800X600, 800, 600);
+else if (!strncmp(displaytype, "dvi1024x768", 11))
+retu
On 23/01/2013 20:06, Troy Kisky wrote:
>>
>> Hi Troy,
>>
>> you're right, this patchset stalls - but on the other side, I have not
>> found any comment that should avoid that it can be merged.
>>
>> If nobody complains, I propose I go on and I try to merge it into
>> u-boot-imx. Here my first atte
If property 'fsl,sec-era' is already present, it is updated.
This property is required so that applications can ascertain which
descriptor commands are supported on a particular CAAM version.
Signed-off-by: Vakul Garg
Cc: Andy Fleming
---
Changelog:
v1: Added '__iomem' as per Timur's com
On 01/24/13 00:36, Jeroen Hofstee wrote:
> Hi Nikita,
>
> On 01/21/2013 09:25 AM, Nikita Kiryanov wrote:
>> Hi Jeroen,
>>
>> On 01/20/2013 11:08 PM, Jeroen Hofstee wrote:
>>> On 12/23/2012 08:03 AM, Nikita Kiryanov wrote:
>> [...]
+ * Returns -1 on failure, 0 on success.
+ */
+stati
Joakim Tjernlund/Transmode wrote on 2013/01/24 09:58:35:
>
> Joakim Tjernlund/Transmode wrote on 2013/01/24 09:40:45:
>
> > From: Joakim Tjernlund/Transmode
> > To: Mats Kärrman ,
> > Cc: "u-boot@lists.denx.de" , Wolfgang Denk
> > Date: 2013/01/24 09:40
> > Subject: RE: [U-Boot] mpc512x: Troub
This patch set creats a new configuration file and DTS file for Snow.
Driver for MAX98095 is added and support for same is incorporated in
sound driver and Snow Board.
Changes in V2:
- Corrected multi-line comment style
Rajeshwari Shinde (7):
EXYNOS5: Add function to enable XXTI clock s
This patchs adds support for MAX98095 codec in
sound driver.
Signed-off-by: Rajeshwari Shinde
---
Changes in V2:
- None
arch/arm/include/asm/arch-exynos/sound.h | 10 +-
drivers/sound/sound.c| 13 +++--
include/sound.h |
This patch adds funtion to enable XXTI clock source
required by MAX98095 codec.
Signed-off-by: Rajeshwari Shinde
---
Changes in V2:
- Corrected multi-line comment style
arch/arm/cpu/armv7/exynos/power.c| 11 +++
arch/arm/include/asm/arch-exynos/power.h | 11 +
This patch sets high a GPIO to enable the codec MAX98095
Signed-off-by: Rajeshwari Shinde
---
Changes in V2:
- None
board/samsung/smdk5250/smdk5250.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/board/samsung/smdk5250/smdk5250.c
b/board/samsung
This patch adds the driver for codec MAX98095 required by Snow
Board
Signed-off-by: Rajeshwari Shinde
---
Changes in V2:
- None
drivers/sound/Makefile |1 +
drivers/sound/max98095.c | 550 ++
drivers/sound/max98095.h | 311 +
Add required compatible information for MAX98095 codec
Signed-off-by: Rajeshwari Shinde
---
Changes in V2:
- None
include/fdtdec.h |1 +
lib/fdtdec.c |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/fdtdec.h b/include/fdtdec.h
index f77d195..e76cdc
This patch adds the DTS file for Snow Board.
Signed-off-by: Rajeshwari Shinde
---
Changes in V2:
- None
board/samsung/dts/exynos5250-snow.dts | 69 +
1 files changed, 69 insertions(+), 0 deletions(-)
create mode 100644 board/samsung/dts/exynos5250-snow.
This patch adds the configuration file for Snow Board and
defines the same in boards.cfg.
The Audio codec required for SMDK5250 and Snow are different
hence they are defined in the corresponding configuration files.
Signed-off-by: Rajeshwari Shinde
---
Changes in V2:
- None
boards.cfg
> Hi Vipin,
> On Wed, 23 Jan 2013 15:46:31 +0530, Vipin Kumar
> wrote:
> >> My first feeling is that the descriptors are allocated as Normal
> >> Cachabale memory and it would not help to access them using readl/writel
> >> ...
> > And no, we don't need to allocate them non-cacheable, although i
Hi, List
Is there a book or web document to help start to understand how U-Boot
works?
Thanks!
--
woody
I can't go back to yesterday - because I was a different person then.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/li
On Thu, 2013-01-24 at 03:33 +0800, Wolfgang Denk wrote:
> Dear Jim Lin,
>
> In message <1358937511-32664-1-git-send-email-ji...@nvidia.com> you wrote:
> > Autoboot timeout defined by CONFIG_BOOTDELAY will not be accurate if
> > CONFIG_USB_KEYBOARD and CONFIG_SYS_USB_EVENT_POLL are defined in
> > c
Autoboot timeout defined by CONFIG_BOOTDELAY will not be accurate if
CONFIG_USB_KEYBOARD and CONFIG_SYS_USB_EVENT_POLL are defined in
configuration file and when tstc() function for checking key pressed
takes longer time than 10 ms (e.g., 50 ms) to finish.
Signed-off-by: Jim Lin
---
Changes in v2
Joakim Tjernlund/Transmode wrote on 2013/01/24 09:58:35:
> > >
> > > Me neither, there is not a lot details. I do recall having other
> problems with
> > > wait_ticks from time to time, sometimes the TB counter(mtfbu, mftb in
> get_ticks)
> > > would not increment so one would just loop forever in
Dear Piotr Wilczek,
> From: Lukasz Majewski
>
> The storage_common.c source file from v2.6.36 Linux kernel.
Is it not possibly to port anything more recent? If not, so be it.
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http
Dear Piotr Wilczek,
> The f_mass_storage.c source file from v2.6.36 Linux kernel.
>
> commit 8876f5e7d3b2a320777dd4f6f5301d474c97a06c
> Author: Michal Nazarewicz
> Date: Mon Jun 21 13:57:09 2010 +0200
>
> USB: gadget: f_mass_storage: added eject callback
>
> Signed-off-by: Lukasz Majewski
>
Dear Piotr Wilczek,
> From: Lukasz Majewski
>
> This patch adds the USB Mass Storage Gadget to u-boot
> New command called "ums" is implemented to provide access
> to on-device embedded persistent memory.
>
> USB Mass Storage is supposed to work on top of the USB
> Gadget framework
>
> Signed-
From: Maxim Podberezny
This patch add support for a SOM SomIQ-AM37 based on TI AM37/DM37
precessors. SomIQ-AM37 design is based on Beagleboard-xM schematic
Maxim Podberezny (1):
Add support for new SomIQ-AM37 system on module from MENTOREL Ltd
SomIQ-AM37 is based on TI AM37/DM37 proces
From: Maxim Podberezny
Signed-off-by: Maxim Podberezny
---
:100644 100644 a676b6d... 817e0e6... M arch/arm/include/asm/mach-types.h
:00 100644 000... 018142a... A board/mentorel/somiq_am37/Makefile
:00 100644 000... 3a974bd... A board/mentorel/somiq_am37/somiq_am37.c
:00
Hi Allen,
On Wed, 23 Jan 2013 13:05:27 -0800, Allen Martin
wrote:
> > Shouldn't the function be given '__attribute__((noreturn))' rather than
> > adding a non-executed 'return 0' to it?
> >
>
> The function in question is sandbox main(), and it can return if there
> was an error prior to calli
Joakim Tjernlund/Transmode wrote on 2013/01/24 09:21:
> Looking at the watchdog impl. I see it can be normal C code. This makes
> wait_ticks unsafe
> (even before my patch) as wait_ticks relies on r6 and r7 (and with my
> patch r0 too)
> to be unmodified.
Yes!
I can see in the assembly from my wat
Mats Kärrman wrote on 2013/01/24 14:31:02:
>
> Joakim Tjernlund/Transmode wrote on 2013/01/24 09:21:
> > Looking at the watchdog impl. I see it can be normal C code. This
makes
> > wait_ticks unsafe
> > (even before my patch) as wait_ticks relies on r6 and r7 (and with my
> > patch r0 too)
> > t
Dear Angelo Dureghello,
In message <20130123145107.GA5565@sion.sysam> you wrote:
> Add support for Sysam AMCORE mcf5307 (coldfire) based board.
>
> Signed-off-by: Angelo Dureghello
> Cc: Jason Jin
...
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 28c052d..1d27cb7 100644
> --- a/MAINTAINERS
Hi,
If watchdog is enabled, the arch/powerpc/lib/ticks.S::wait_ticks() function
calls the function specified by the WATCHDOG_RESET macro.
The wait_ticks function depends on the registers r0, r6 and r7 being
preserved however that is not guaranteed if the reset function is a
C function.
The follow
Dear Wolfgang,
thanks for the review, will fix all points.
>
> > +/* reserve 128-4KB */
> > +#define CONFIG_SYS_MONITOR_BASE(CONFIG_SYS_FLASH_BASE + 0x400)
> > +#define CONFIG_SYS_MONITOR_LEN ((128-4)*1024)
>
> Are you sure this is sufficient?
For my board/case actually se
Save the reused parameters at the beginning
of the 'relocate_code' function. This makes
the function a bit more readable.
Signed-off-by: Gabor Juhos
Cc: Daniel Schwierzeck
---
arch/mips/cpu/mips32/start.S |5 +++--
arch/mips/cpu/mips64/start.S |5 +++--
2 files changed, 6 insertions(+),
This series contain various patches for the relocate_code function.
The first patch fixes a minor issue in the relocation code, and the
subsequent patches are doing some optimalization and cleanup.
Gabor Juhos (5):
MIPS: start.S: fix boundary check in relocate_code
MIPS: start.S: set sp regist
The current code uses two instructions to load
the stack pointer into the 'sp' register.
This results in the following assembly code:
468: 3c088040lui t0,0x8040
46c: 251daddiu sp,t0,0
The first instuction loads the stack pointer into
the 't0' register then t
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
The loop code copies more data with one than
necessary due to the 'ble' instuction. Use the
'blt' instruction instead to fix that.
Due to the lack of suitable hardware the Xburst
specific code is compile tested only. However the
change is quite obvious.
Signed-off-by: Gabor Juhos
Cc: Daniel Schw
Saving the parameters in advance unnecessarily complicates
the code. The destination address is already saved in the
's2' register, and that register is not clobbered by the
copy loop. The size of the copied data can be computed
after the copy loop is done.
Change the code to compute the size para
This series introduces tablebased pinmux to all Tegra20 boards and
removes the old way of doing pinmux to avoid any possible conflicts
in pin setup.
Patch 1 introduces a temporary CONFIG option for the new pinmux style
to avoid breaking bisectability in the middle of the series. This
option gets r
This disables all pinmux entry points and instead calls pinmux_init() in
early board init, allowing boards to set up the pinmux in one shot, like
it's done with Tegra30.
This option is temporary and can go away once we switched over all
boards to the new pinmux style.
Signed-off-by: Lucas Stach
Signed-off-by: Lucas Stach
---
arch/arm/include/asm/arch-tegra20/pinmux.h | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/include/asm/arch-tegra20/pinmux.h
b/arch/arm/include/asm/arch-tegra20/pinmux.h
index a9b4eda..a167e48 100644
--- a/arch/arm/include/asm/arch-tegra2
Init pinmux in one shot, in order to avoid any conflicts.
Signed-off-by: Lucas Stach
---
board/avionic-design/common/tamonten.c | 133 -
include/configs/medcom-wide.h | 3 +
include/configs/plutux.h | 3 +
include/configs/tec.h
Init Colibri T20 pinmux in one shot, in order to avoid any conflicts.
Signed-off-by: Lucas Stach
---
.../colibri_t20-common/colibri_t20-common.c| 132 +
board/toradex/colibri_t20_iris/colibri_t20_iris.c | 16 +--
include/configs/colibri_t20_iris.h |
Init pinmux in one shot, in order to avoid any conflicts.
Signed-off-by: Lucas Stach
---
board/nvidia/harmony/harmony.c | 143 -
include/configs/harmony.h | 3 +
2 files changed, 116 insertions(+), 30 deletions(-)
diff --git a/board/nvidia/harmony/
Init pinmux in one shot, in order to avoid any conflicts.
Signed-off-by: Lucas Stach
---
board/nvidia/whistler/whistler.c | 131 ++-
include/configs/whistler.h | 3 +
2 files changed, 119 insertions(+), 15 deletions(-)
diff --git a/board/nvidia/whistl
Init pinmux in one shot, in order to avoid any conflicts.
Signed-off-by: Lucas Stach
---
board/nvidia/seaboard/seaboard.c | 133 +--
include/configs/seaboard.h | 3 +
include/configs/ventana.h| 3 +
3 files changed, 121 insertions(+), 18 dele
Init pinmux in one shot, in order to avoid any conflicts.
Signed-off-by: Lucas Stach
---
board/compal/paz00/paz00.c | 149 ++---
include/configs/paz00.h| 3 +
2 files changed, 115 insertions(+), 37 deletions(-)
diff --git a/board/compal/paz00/paz00.
Init pinmux in one shot, in order to avoid any conflicts.
Signed-off-by: Lucas Stach
---
board/compulab/trimslice/trimslice.c | 146 +++
include/configs/trimslice.h | 3 +
2 files changed, 118 insertions(+), 31 deletions(-)
diff --git a/board/compulab/
All boards are converted to the new tablebased pinmux setup. Get rid of
the old method.
Signed-off-by: Lucas Stach
---
arch/arm/cpu/tegra-common/board.c | 25
arch/arm/include/asm/arch-tegra/board.h | 12 --
board/nvidia/common/board.c | 41 +---
It's not used by anything anymore, now that all boards are using
tablebased pinmux.
Signed-off-by: Lucas Stach
---
arch/arm/cpu/tegra-common/board.c | 1 -
arch/arm/cpu/tegra20-common/Makefile| 2 +-
arch/arm/cpu/tegra20-common/funcmux.c | 310
Hi,
I need some help on mmc driver development on u-boot.
Few questions:
1. is mmc framework in u-boot supports all type of card interfaces like SD,
MMC, and eMMC
2. If I write a driver do I need to develop the common driver for all or a
separate drivers for individual cards.
3. Is there any dr
On Wed, Jan 23, 2013 at 02:05:26PM -0800, York Sun wrote:
> On 01/23/2013 02:02 PM, Scott Wood wrote:
> > On 01/23/2013 04:01:49 PM, York Sun wrote:
> >> On 01/23/2013 01:52 PM, Scott Wood wrote:
> >> > On 01/23/2013 03:46:04 PM, York Sun wrote:
> >> >> On 01/23/2013 01:41 PM, York Sun wrote:
> >>
The mxsboot now receives the SoC type as parameter to generate binary
compatible with the SoC. Currently the NAND support has not been add
for i.MX23 as it is not yet supported in U-Boot.
Signed-off-by: Otavio Salvador
---
doc/README.mx28_common | 4 +--
tools/mxsboot.c| 92
Hi Lucas,
On Fri, Jan 25, 2013 at 5:48 AM, Lucas Stach wrote:
> Init pinmux in one shot, in order to avoid any conflicts.
>
> Signed-off-by: Lucas Stach
> ---
> board/nvidia/seaboard/seaboard.c | 133
> +--
> include/configs/seaboard.h | 3 +
> inclu
On 01/24/2013 09:34 AM, Allen Martin wrote:
> On Wed, Jan 23, 2013 at 02:05:26PM -0800, York Sun wrote:
>> On 01/23/2013 02:02 PM, Scott Wood wrote:
>>> On 01/23/2013 04:01:49 PM, York Sun wrote:
On 01/23/2013 01:52 PM, Scott Wood wrote:
> On 01/23/2013 03:46:04 PM, York Sun wrote:
>>
Dear Otavio Salvador,
> The mxsboot now receives the SoC type as parameter to generate binary
> compatible with the SoC. Currently the NAND support has not been add
> for i.MX23 as it is not yet supported in U-Boot.
Please fix the NAND support as well, then resubmit.
The patch basically does dd
On Thu, Jan 24, 2013 at 11:33 AM, Tom Warren wrote:
> This 'commonizes' much of the clock/pll code. SoC-dependent code
> and tables are left in arch/cpu/tegraXXX-common/clock.c
>
> Some T30 tables needed whitespace fixes due to checkpatch complaints.
>
> Signed-off-by: Tom Warren
Acked-by: Simon
On Thu, Jan 24, 2013 at 3:56 PM, Marek Vasut wrote:
> Dear Otavio Salvador,
>
>> The mxsboot now receives the SoC type as parameter to generate binary
>> compatible with the SoC. Currently the NAND support has not been add
>> for i.MX23 as it is not yet supported in U-Boot.
>
> Please fix the NAND
On 01/24/2013 09:54 AM, York Sun wrote:
> On 01/24/2013 09:34 AM, Allen Martin wrote:
>> On Wed, Jan 23, 2013 at 02:05:26PM -0800, York Sun wrote:
>>> On 01/23/2013 02:02 PM, Scott Wood wrote:
On 01/23/2013 04:01:49 PM, York Sun wrote:
> On 01/23/2013 01:52 PM, Scott Wood wrote:
>> On
Dear Otavio Salvador,
> On Thu, Jan 24, 2013 at 3:56 PM, Marek Vasut wrote:
> > Dear Otavio Salvador,
> >
> >> The mxsboot now receives the SoC type as parameter to generate binary
> >> compatible with the SoC. Currently the NAND support has not been add
> >> for i.MX23 as it is not yet supporte
Dear Otavio Salvador,
NAK, this won't work. SSP0 DMA has this +1 offset in it's channel placement (so
SSP0 DMA channel is actually channel 1), check the MMC patch.
> Signed-off-by: Otavio Salvador
> ---
> drivers/spi/mxs_spi.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/driv
On 01/24/2013 12:03:49 PM, York Sun wrote:
On 01/24/2013 09:54 AM, York Sun wrote:
> On 01/24/2013 09:34 AM, Allen Martin wrote:
>> On Wed, Jan 23, 2013 at 02:05:26PM -0800, York Sun wrote:
>>> On 01/23/2013 02:02 PM, Scott Wood wrote:
On 01/23/2013 04:01:49 PM, York Sun wrote:
> On 01/2
On 23/01/2013 02:01, Marek Vasut wrote:
> The MX23 has less channels for the APBH DMA, sligtly different register
> layout and some bits in those registers are placed differently. Reflect
> this in the driver. This patch fixes MMC/DMA issue on MX23.
>
> Signed-off-by: Marek Vasut
> Cc: Otavio Sal
Am Freitag, den 25.01.2013, 06:54 +1300 schrieb Simon Glass:
> Hi Lucas,
>
> On Fri, Jan 25, 2013 at 5:48 AM, Lucas Stach wrote:
> > Init pinmux in one shot, in order to avoid any conflicts.
> >
> > Signed-off-by: Lucas Stach
> > ---
> > board/nvidia/seaboard/seaboard.c | 133
> > +
On 01/24/2013 10:14 AM, Scott Wood wrote:
>> >
>>
>> I thought I have replaced all #define, enum, typedef. I have left alone
>> those FALSE, False, false but add define like this
>>
>> +#include
>> +#define TRUE true
>> +#define FALSE false
>> +#define True true
>> +#define False false
>>
>> Isn't
Dear Angelo Dureghello,
In message <20130124161349.GA11311@sion.sysam> you wrote:
>
> > > +/* reserve 128-4KB */
> > > +#define CONFIG_SYS_MONITOR_BASE (CONFIG_SYS_FLASH_BASE + 0x400)
> > > +#define CONFIG_SYS_MONITOR_LEN ((128-4)*1024)
> >
> > Are you sure this is sufficient?
On Thu, Jan 24, 2013 at 10:14:37AM -0800, Scott Wood wrote:
> On 01/24/2013 12:03:49 PM, York Sun wrote:
> > On 01/24/2013 09:54 AM, York Sun wrote:
> > > On 01/24/2013 09:34 AM, Allen Martin wrote:
> > >> On Wed, Jan 23, 2013 at 02:05:26PM -0800, York Sun wrote:
> > >>> On 01/23/2013 02:02 PM, Sco
Dear York Sun,
In message <51017785.9060...@freescale.com> you wrote:
>
> I thought I have replaced all #define, enum, typedef. I have left alone
> those FALSE, False, false but add define like this
>
> +#include
> +#define TRUE true
> +#define FALSE false
> +#define True true
> +#define False f
On 23/01/2013 02:01, Marek Vasut wrote:
> Some MXS based boards do not implement the card-detect signal. Allow
> user to specify alternate card-detect implementation.
>
> Signed-off-by: Marek Vasut
> Cc: Otavio Salvador
> Cc: Fabio Estevam
> Cc: Stefano Babic
> ---
> arch/arm/include/asm/arch
Dear Stefano Babic,
> On 23/01/2013 02:01, Marek Vasut wrote:
> > The MX23 has less channels for the APBH DMA, sligtly different register
> > layout and some bits in those registers are placed differently. Reflect
> > this in the driver. This patch fixes MMC/DMA issue on MX23.
> >
> > Signed-off-
On Thu, Jan 24, 2013 at 10:23:21AM -0800, York Sun wrote:
> On 01/24/2013 10:14 AM, Scott Wood wrote:
> >> >
> >>
> >> I thought I have replaced all #define, enum, typedef. I have left alone
> >> those FALSE, False, false but add define like this
> >>
> >> +#include
> >> +#define TRUE true
> >> +#
Dear Stefano Babic,
> On 23/01/2013 02:01, Marek Vasut wrote:
> > Some MXS based boards do not implement the card-detect signal. Allow
> > user to specify alternate card-detect implementation.
> >
> > Signed-off-by: Marek Vasut
> > Cc: Otavio Salvador
> > Cc: Fabio Estevam
> > Cc: Stefano Babi
On Thu, Jan 24, 2013 at 4:08 PM, Marek Vasut wrote:
> Dear Otavio Salvador,
>
>> On Thu, Jan 24, 2013 at 3:56 PM, Marek Vasut wrote:
>> > Dear Otavio Salvador,
>> >
>> >> The mxsboot now receives the SoC type as parameter to generate binary
>> >> compatible with the SoC. Currently the NAND suppor
On 24/01/2013 19:29, Marek Vasut wrote:
>
> That's also an option ... do you want subsequent patch or respin of the
> series?
If I can choose, I prefer a respin of series, but I will surely not
block the patchset if you send subsequent patches...
Best regards,
Stefano Babic
--
=
Dear Stefano Babic,
[...]
> > > diff --git a/board/bluegiga/apx4devkit/apx4devkit.c
> > > b/board/bluegiga/apx4devkit/apx4devkit.c index 029b973..5927693 100644
> > > --- a/board/bluegiga/apx4devkit/apx4devkit.c
> > > +++ b/board/bluegiga/apx4devkit/apx4devkit.c
> > > @@ -69,7 +69,7 @@ int board_i
Dear Otavio Salvador,
> On Thu, Jan 24, 2013 at 4:08 PM, Marek Vasut wrote:
> > Dear Otavio Salvador,
> >
> >> On Thu, Jan 24, 2013 at 3:56 PM, Marek Vasut wrote:
> >> > Dear Otavio Salvador,
> >> >
> >> >> The mxsboot now receives the SoC type as parameter to generate binary
> >> >> compatibl
Dear Stefano Babic,
> On 24/01/2013 19:29, Marek Vasut wrote:
> > That's also an option ... do you want subsequent patch or respin of the
> > series?
>
> If I can choose, I prefer a respin of series, but I will surely not
> block the patchset if you send subsequent patches...
No, scrap this. See
>
> Hi,
Hi Mats
I would appreciate if you CC me directly on stuff I have been involved in.
I don't read every mail on u-boot list(to many of them). It was just
plain luck I saw this one.
>
> If watchdog is enabled, the arch/powerpc/lib/ticks.S::wait_ticks()
function
> calls the function spec
Add support for per architecture CROSS_COMPILE toolchain definitions
via CROSS_COMPILE_ARCH where "ARCH" is any of the supported u-boot
architectures. This allows building every supported u-boot board in a
single pass of MAKEALL.
Signed-off-by: Allen Martin
---
MAKEALL | 32 ++
On 01/24/2013 10:28 AM, Allen Martin wrote:
> On Thu, Jan 24, 2013 at 10:23:21AM -0800, York Sun wrote:
>> On 01/24/2013 10:14 AM, Scott Wood wrote:
>
I thought I have replaced all #define, enum, typedef. I have left alone
those FALSE, False, false but add define like this
>
Hi Jagannadha,
> Hi,
>
> I need some help on mmc driver development on u-boot.
>
> Few questions:
> 1. is mmc framework in u-boot supports all type of card interfaces
> like SD, MMC, and eMMC
Yes there is a generic framework for MMC. -> ./drivers/mmc/ {mmc.c}
> 2. If I write a driver do I nee
On 01/24/2013 12:47:10 PM, York Sun wrote:
diff --git a/tools/patman/checkpatch.py b/tools/patman/checkpatch.py
index d831087..28b3240 100644
--- a/tools/patman/checkpatch.py
+++ b/tools/patman/checkpatch.py
@@ -48,12 +48,12 @@ def FindCheckPatch():
print 'Could not find checkpatch.pl'
On 01/24/2013 11:09 AM, Scott Wood wrote:
> On 01/24/2013 12:47:10 PM, York Sun wrote:
>> diff --git a/tools/patman/checkpatch.py b/tools/patman/checkpatch.py
>> index d831087..28b3240 100644
>> --- a/tools/patman/checkpatch.py
>> +++ b/tools/patman/checkpatch.py
>> @@ -48,12 +48,12 @@ def FindChec
Dear Joakim Tjernlund,
In message
you
wrote:
>
> This adds some extra churn to the code that my patch didn't do.
> On the other hand your patch makes the function look more
> like how gcc would have done so I am fine with that.
> However, I am not sure r14 is a good fit, I cannot remember if t
On Thu, Jan 24, 2013 at 11:13:27AM -0800, York Sun wrote:
> On 01/24/2013 11:09 AM, Scott Wood wrote:
> > On 01/24/2013 12:47:10 PM, York Sun wrote:
> >> diff --git a/tools/patman/checkpatch.py b/tools/patman/checkpatch.py
> >> index d831087..28b3240 100644
> >> --- a/tools/patman/checkpatch.py
> >
Dear York Sun,
In message <1359053230-18920-1-git-send-email-york...@freescale.com> you wrote:
> 'bool' is defined in random places. This patch consolidates them into a
> single header file include/linux/types.h, using stdbool.h introduced in C99.
>
> All other #define, typedef and enum are remov
Dear Wolfgang,
On Thu, Jan 24, 2013 at 07:24:11PM +0100, Wolfgang Denk wrote:
> Dear Angelo Dureghello,
>
> In message <20130124161349.GA11311@sion.sysam> you wrote:
> >
> > > > +/* reserve 128-4KB */
> > > > +#define CONFIG_SYS_MONITOR_BASE(CONFIG_SYS_FLASH_BASE
> > > > + 0x40
Dear Angelo Dureghello,
In message <20130124200736.GA19171@sion.sysam> you wrote:
>
> > How big is your U-Boot image, then? I think it's a pretty long time
> > since I haven't seen any image smaller than 128 kB...
>
> -rwxr-xr-x 1 angelo angelo 88556 gen 22 22:31 u-boot.bin
Wow, that's jus
Sort nodes in dts files according the the following rules:
1) Any nodes that already exist in any /include/d file, in the order
they appear in the /include/d file.
2) Any nodes with a reg property, in order of their address.
3) Any nodes without a reg property, alphabetically by node name.
Sign
Hello Igor,
On 01/24/2013 09:35 AM, Igor Grinberg wrote:
On 01/24/13 00:13, Jeroen Hofstee wrote:
Hello Nikita,
On 01/23/2013 09:31 AM, Nikita Kiryanov wrote:
On 01/21/2013 09:14 PM, Jeroen Hofstee wrote:
mmm, I am not so sure I agree that loading a bitmap in lcd_enable is
a _problem_, whil
Dear Woody Wu,
> Hi, List
>
> Is there a book or web document to help start to understand how U-Boot
> works?
There's a doc/ directory in the u-boot sourcecode.
> Thanks!
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://l
On 01/24/2013 02:07:29 AM, Andy Fleming wrote:
Scott, I reverted this patch, and it fixed some build errors:
20001122-1.c:1:0: error: E500 and FPRs not supported
20010114-2.c:1:0: error: E500 and FPRs not supported
make[2]: ***
[/local/afleming/u-boot/build/P2020DS/post/lib_powerpc/fpu/20001122-
1 - 100 of 121 matches
Mail list logo
