Hi All,
On 02/22/2013 04:11 PM, Lukasz Majewski wrote:
> Hi Tom,
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 02/21/2013 06:33 PM, Jaehoon Chung wrote:
>>> Hi Tom,
>>>
>>> On 02/22/2013 02:45 AM, Tom Rini wrote: On 02/21/2013 12:21 PM,
>>> Lukasz Majewski wrote:
>> Dear All,
Hi Jean,
> Hi,
>
> I use the last uboot from your git and boot with it on AM3517 EVM
> from SD card
> without NAND.
>
> I use this option in uboot config : #define CONFIG_FAT_WRITE 1
>
> I use intensively fatload / fatwrite commands at the boot before
> kernel loading.
>
> Sometimes, in about
Hi Tom,
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 02/21/2013 06:33 PM, Jaehoon Chung wrote:
> > Hi Tom,
> >
> > On 02/22/2013 02:45 AM, Tom Rini wrote: On 02/21/2013 12:21 PM,
> > Lukasz Majewski wrote:
> Dear All,
>
> I'd like to kindly ask for any feedback on thi
Dear Jason,
In message <20130221232821.ga2...@obsidianresearch.com> you wrote:
>
> > > own seems to be rather static and stable, and unlike software there is
> > > no way I can change it (soldering irons don't count).
> >
> > There is other hardware available (for example FPGA based) where this
On Thu, Feb 21, 2013 at 06:19:05PM -0600, Rob Herring wrote:
> The desired FPGA use case is DT updates after booting the kernel. This
> has nothing to do with FIT images. And if the FPGA tools generate the
> DTB, then it is certainly not tied to the kernel.
Completely unrelated, but do you have a
On Thu, Feb 21, 2013 at 05:10:36PM -0700, Stephen Warren wrote:
> On 02/21/2013 02:18 PM, Nicolas Pitre wrote:
> > Where were such guidance given?
>
> IIRC, it's been discussed a number of times on the Linux ARM kernel
> mailing list and at the various ARM workshops at kernel summit and/or
> Linar
On Thu, Feb 21, 2013 at 04:45:37PM -0700, Stephen Warren wrote:
> Well they ship x86 CPU firmware updates according to the boot log on one
> of my systems at least...
Correction: CPU microcode updates. That's updating the microcode in the
CPU which runs the x86 instruction set. It's done to fix
On Thu, Feb 21, 2013 at 04:11:06PM -0700, Jason Gunthorpe wrote:
> On Thu, Feb 21, 2013 at 05:05:54PM -0500, Nicolas Pitre wrote:
> > No it is not. FIT is about bundling a multi-platform kernel with a
> > bunch of DTBs together in a single file. I don't think you need that
> > for your embedded
On Fri, Feb 22, 2013 at 12:18:48AM +0100, Wolfgang Denk wrote:
> > The DT is meant to describe hardware. As far as I know, the hardware I
> > own seems to be rather static and stable, and unlike software there is
> > no way I can change it (soldering irons don't count).
>
> There is other hard
Hi Minkyu Kang,
Can we get these patches merged or do let me know if you have any
review comments.
Regards,
Rajeshwari Shinde.
On Wed, Feb 20, 2013 at 8:31 PM, Tom Rini wrote:
> On Tue, Jan 22, 2013 at 08:30:18PM -, Rajeshwari Shinde wrote:
>
>> This patch adds driver for the gigabyte devic
On 02/21/2013 08:22 PM, Jason Gunthorpe wrote:
> On Thu, Feb 21, 2013 at 06:19:05PM -0600, Rob Herring wrote:
>
>> The desired FPGA use case is DT updates after booting the kernel. This
>> has nothing to do with FIT images. And if the FPGA tools generate the
>> DTB, then it is certainly not tied t
On 02/21/2013 05:11:06 PM, Jason Gunthorpe wrote:
On Thu, Feb 21, 2013 at 05:05:54PM -0500, Nicolas Pitre wrote:
> No it is not. FIT is about bundling a multi-platform kernel with a
> bunch of DTBs together in a single file. I don't think you need
that
> for your embedded system. The "wrong
On 02/21/2013 05:28 PM, Jason Gunthorpe wrote:
> On Fri, Feb 22, 2013 at 12:18:48AM +0100, Wolfgang Denk wrote:
>
>>> The DT is meant to describe hardware. As far as I know, the hardware I
>>> own seems to be rather static and stable, and unlike software there is
>>> no way I can change it (sol
On 02/21/2013 02:18 PM, Nicolas Pitre wrote:
> On Thu, 21 Feb 2013, Stephen Warren wrote:
>
>> On 02/21/2013 12:21 PM, Nicolas Pitre wrote:
>>> DT installation must be outside of the distribution's responsibilities.
>>> It should be the OEM's responsibility, just like BIOS updates for PCs
>>> w
On 02/21/2013 04:11 PM, Jason Gunthorpe wrote:
> On Thu, Feb 21, 2013 at 05:05:54PM -0500, Nicolas Pitre wrote:
...
>> The DT is meant to describe hardware. As far as I know, the hardware I
>> own seems to be rather static and stable, and unlike software there is
>> no way I can change it (solde
On 02/21/2013 03:05 PM, Nicolas Pitre wrote:
> On Thu, 21 Feb 2013, Jason Gunthorpe wrote:
...
>> Distros already ship huge kernels with modules for every hardware out
>> there. Shipping all the DTs as well doesn't seem like a problem.
>
> But it is! Even shipping multiple kernels _is_ a problem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/21/2013 06:33 PM, Jaehoon Chung wrote:
> Hi Tom,
>
> On 02/22/2013 02:45 AM, Tom Rini wrote: On 02/21/2013 12:21 PM,
> Lukasz Majewski wrote:
Dear All,
I'd like to kindly ask for any feedback on this patch.
It is now m
On 02/21/2013 04:33 PM, Tom Warren wrote:
> Minor edits to clock, apbdma and SPI, make I2C match kernel DT, and add gpio
Conceptually looks fine; I didn't do much to verify it than briefly scan
through it since I assume it's all just cut/paste.
Reviewed-by: Stephen Warren
___
On 02/21/2013 03:31 PM, Tom Warren wrote:
> This patchset adds device-tree support to the Tegra MMC driver.
> All device config is done via properties in the DT files instead
> of hard-coded config options/function arguments.
>
> I've tested this on my Seaboard and everything works fine,
> includi
On 02/21/2013 03:40 PM, Tom Warren wrote:
> Not used, and wrong in Cardhu's case
Reviewed-by: Stephen Warren
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Minor edits to clock, apbdma and SPI, make I2C match kernel DT, and add gpio
Signed-off-by: Tom Warren
---
arch/arm/dts/tegra30.dtsi | 90 ++-
board/nvidia/dts/tegra30-cardhu.dts |5 ++
2 files changed, 61 insertions(+), 34 deletions(-)
diff --git
Hi Tom,
On 02/22/2013 02:45 AM, Tom Rini wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 02/21/2013 12:21 PM, Lukasz Majewski wrote:
>> Dear All,
>>
>> I'd like to kindly ask for any feedback on this patch.
>>
>> It is now more than month on the u-boot mailing list...
>
> OK, sor
On Thu, Feb 21, 2013 at 05:05:54PM -0500, Nicolas Pitre wrote:
> On Thu, 21 Feb 2013, Jason Gunthorpe wrote:
>
> > On Thu, Feb 21, 2013 at 02:57:46PM -0500, Nicolas Pitre wrote:
> > > For embedded appliance product you may do as you wish. Nobody will
> > > interfere in the way you develop and su
Dear Nicolas,
In message you wrote:
>
> No it is not. FIT is about bundling a multi-platform kernel with a
> bunch of DTBs together in a single file. I don't think you need that
Actually this is neither the only, nor even the primary purpose of FIT
images; these have a much wider scope of u
Not used, and wrong in Cardhu's case
Signed-off-by: Tom Warren
---
board/nvidia/dts/tegra20-seaboard.dts |1 -
board/nvidia/dts/tegra30-cardhu.dts |1 -
2 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/board/nvidia/dts/tegra20-seaboard.dts
b/board/nvidia/dts/tegra20-seab
Hi Mats and Tom,
(sorry for precedent duplicate email)
I currently test with the correction.
I see that not help me to exit from the case I have described but I think
that avoid or
significantly reduce future problems with a sane card.
I use mainly FAT32 (not FAT12).
I think also that the corr
I need ti816x u-boot too! Maybe I can help too. Need 3.x kernel too but I
guess that is for another list :)
Regards,
Brian
On Feb 18, 2013 7:21 AM, "Peter Korsgaard" wrote:
>
> > "Tom" == Tom Rini writes:
>
> Hi,
>
> >> Quite some of the base addresses are similar, but I wonder if it
>
tegra_mmc_init() now parses the DT info for bus width, WP/CD GPIOs, etc.
Tested on Seaboard, fully functional.
Tamonten boards (medcom-wide, plutux, and tec) use a different/new
dtsi file w/common settings.
Signed-off-by: Tom Warren
Signed-off-by: Thierry Reding
---
v2:
- all boards now call te
Linux dts files were used for those boards that didn't already
have sdhci info populated. Tamonten has their own dtsi file with
common sdhci nodes (sourced from Linux).
Signed-off-by: Tom Warren
Tested-by: Thierry Reding
---
v2:
- cleanup comments in dts files/match w/kernel files
- add sdhci al
Tamonten boards (medcom-wide, plutux, and tec) use a different/new
dtsi file w/common settings.
Signed-off-by: Tom Warren
Acked-by: Thierry Reding
---
v3: new
v4: no change
v5: change /include/ to #include
v6: change AD DT files ARCH_CPU_DTS to "tegra20-tamonten.dtsi"
v7: change ARCH_CPU_DTS to
dts Makefile has the arch & board include paths added to DTS_CPPFLAGS.
This allows the use of '#include "xyz"' in the dts/dtsi file which
helps the C preprocessor find common dtsi include files.
Signed-off-by: Tom Warren
---
---
v4: new
v5: add dts/dtsi paths to DTS_CPPFLAGS instead of DTC comman
This patchset adds device-tree support to the Tegra MMC driver.
All device config is done via properties in the DT files instead
of hard-coded config options/function arguments.
I've tested this on my Seaboard and everything works fine,
including card detect. For the other T20 boards, I've used
th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/21/2013 05:05 PM, Mats K￤rrman wrote:
> Jean Louis wrote:
>> Many thanks for your great help, I change the code as you say by
>> :
>>
>> ~line 659: if ((fat_val == 0xfff && mydata->fatsize == 32)
>> ||
> (fat_val == 0x && mydata->fatsi
Hi Mats,
Many thanks for your great help, I change the code as you say by :
~line 659:
if ((fat_val == 0xfff && mydata->fatsize == 32) ||
(fat_val == 0x && mydata->fatsize == 16))
break;
~line 904:
if ((curclust >= 0xff8 && mydat
On Thu, 21 Feb 2013, Jason Gunthorpe wrote:
> On Thu, Feb 21, 2013 at 02:57:46PM -0500, Nicolas Pitre wrote:
> > For embedded appliance product you may do as you wish. Nobody will
> > interfere in the way you develop and support your own products (as long
> > as you honor the applicable license
Jean Louis wrote:
> Many thanks for your great help, I change the code as you say by :
>
> ~line 659:
> if ((fat_val == 0xfff && mydata->fatsize == 32) ||
> (fat_val == 0x && mydata->fatsize == 16))
> break;
> ~line 904:
> if ((curclu
Hi Tom,
On Tue, 19 Feb 2013 11:14:05 -0500, Tom Rini wrote:
> Hello,
>
> The following changes since commit 9f024f62e4604274a23213dcee30016092e32e7b:
>
> Merge branch 'fixes' of git://git.denx.de/u-boot-mips (2013-02-15 12:23:42
> -0500)
>
> are available in the git repository at:
>
>
>
On Thu, Feb 21, 2013 at 02:57:46PM -0500, Nicolas Pitre wrote:
> On Thu, 21 Feb 2013, Jason Gunthorpe wrote:
>
> > On Thu, Feb 21, 2013 at 12:25:21PM -0500, Nicolas Pitre wrote:
> >
> > > So let's stop kidding ourselves and be coherent please: either we move
> > > device specifics away from the
On Thu, 21 Feb 2013, Stephen Warren wrote:
> On 02/21/2013 12:21 PM, Nicolas Pitre wrote:
> > DT installation must be outside of the distribution's responsibilities.
> > It should be the OEM's responsibility, just like BIOS updates for PCs
> > which don't come from Fedora/Debian/Ubuntu. Obviou
Hi Wolfgang,
On Tue, Feb 19, 2013 at 11:14 AM, Wolfgang Denk wrote:
> Dear Simon Glass,
>
> In message
> you
> wrote:
>>
>> > You are wrong. This includes a number of functions, and macros, too,
>> > for example:
> ...
>> That's a very manageable and small series of patches I think if we
>> w
> "Jason" == Jason Gunthorpe writes:
Hi,
Jason> We've been using DT on production embedded stuff sice about 2.6.20ish
Jason> on PPC and now ARM. We treat the dtb as a kernel version specific
Jason> file, much like an initrd and ensure that the kernel only ever boots
Jason> with its prope
Hi Rajeshwari,
On Mon, Feb 18, 2013 at 4:10 AM, Rajeshwari Birje
wrote:
> Hi Simon,
>
> Thank you for comments.
>
> On Sun, Feb 17, 2013 at 11:51 AM, Simon Glass wrote:
>> Hi Rajeshwari,
>>
>> On Thu, Feb 7, 2013 at 4:00 AM, Rajeshwari Shinde
>> wrote:
>>> This patch adds support for gpio pin n
On Thu, Feb 21, 2013 at 07:08:20PM +, Russell King - ARM Linux wrote:
> > We've been using DT on production embedded stuff sice about 2.6.20ish
> > on PPC and now ARM. We treat the dtb as a kernel version specific
> > file, much like an initrd and ensure that the kernel only ever boots
> > wit
Dear Stephen,
In message <51267e0a.3060...@wwwdotorg.org> you wrote:
>
> > so. Just consider the typical "diskless" system that boots over the
> > network, using DHCP + TFTP, where the server will provide a single
> > file only.
>
> I use TFTP routinely to boot my boards, and load separate zImag
On 02/21/2013 12:57 PM, Wolfgang Denk wrote:
> Dear Stephen,
>
> In message <5126778a.4040...@wwwdotorg.org> you wrote:
>>
>> If U-Boot always searched a disk for e.g. /boot/boot.scr or similar and
>> just executed that, and there was a standard boot.scr that worked on all
>> boards by use of e.g.
Dear Stephen,
In message <5126778a.4040...@wwwdotorg.org> you wrote:
>
> If U-Boot always searched a disk for e.g. /boot/boot.scr or similar and
> just executed that, and there was a standard boot.scr that worked on all
> boards by use of e.g. bootz, ${soc}, ${board}, then that could be
> distro-a
On Thu, 21 Feb 2013, Jason Gunthorpe wrote:
> On Thu, Feb 21, 2013 at 12:25:21PM -0500, Nicolas Pitre wrote:
>
> > So let's stop kidding ourselves and be coherent please: either we move
> > device specifics away from the kernel, or we keep them together. In
> > other words, the DT should ideal
On 02/21/2013 09:45 AM, Tom Warren wrote:
> tegra_mmc_init() now parses the DT info for bus width, WP/CD GPIOs, etc.
> Tested on Seaboard, fully functional.
>
> Tamonten boards (medcom-wide, plutux, and tec) use a different/new
> dtsi file w/common settings.
Aside from the patch split issue I men
On 02/21/2013 09:45 AM, Tom Warren wrote:
> Linux dts files were used for those boards that didn't already
> have sdhci info populated. Tamonten has their own dtsi file with
> common sdhci nodes (sourced from Linux).
> v6:
> - change ARCH_CPU_DTS to "tegra20.dtsi"
Oh. That should be a separate pa
On 02/21/2013 09:45 AM, Tom Warren wrote:
> dts Makefile has the arch & board include paths added to DTS_CPPFLAGS.
> This allows the use of '#include "xyz"' in the dts/dtsi file which
> helps the C preprocessor find common dtsi include files.
> diff --git a/board/avionic-design/dts/tegra20-medcom-
On Thursday 21 February 2013 09:45:44 Tom Warren wrote:
> Linux dts files were used for those boards that didn't already
> have sdhci info populated. Tamonten has their own dtsi file with
> common sdhci nodes (sourced from Linux).
>
> Signed-off-by: Tom Warren
> Tested-by: Thierry Reding
looks
On 02/21/2013 12:21 PM, Nicolas Pitre wrote:
> On Thu, 21 Feb 2013, Tom Rini wrote:
>
>> On 02/21/2013 12:25 PM, Nicolas Pitre wrote:
>>> On Thu, 21 Feb 2013, Tom Rini wrote:
>> [snip]
> uboot dug _itself_ into this hole. It's uboot's problem.
A whole lot of people dug this particu
On Thu, Feb 21, 2013 at 11:27:24AM -0700, Jason Gunthorpe wrote:
> On Thu, Feb 21, 2013 at 12:25:21PM -0500, Nicolas Pitre wrote:
>
> > So let's stop kidding ourselves and be coherent please: either we move
> > device specifics away from the kernel, or we keep them together. In
> > other words,
On Thu, Feb 21, 2013 at 12:25:21PM -0500, Nicolas Pitre wrote:
> So let's stop kidding ourselves and be coherent please: either we move
> device specifics away from the kernel, or we keep them together. In
> other words, the DT should ideally come preinstalled with the bootloader
> on a given
On Thu, 21 Feb 2013, Tom Rini wrote:
> On 02/21/2013 12:25 PM, Nicolas Pitre wrote:
> > On Thu, 21 Feb 2013, Tom Rini wrote:
> [snip]
> >>> uboot dug _itself_ into this hole. It's uboot's problem.
> >>
> >> A whole lot of people dug this particular hole. Joel is trying
> >> to offer up a solut
On 02/21/2013 06:29 AM, Tom Rini wrote:
> On 02/20/2013 11:26 PM, Stephen Warren wrote:
>> On 02/20/2013 06:37 PM, Joel A Fernandes wrote:
>>> Hello, I've been spinning some work-in-progress patches for
>>> FIT build support in the kernel. With the move to
>>> multiplatform support on OMAP, I feel
On 02/21/2013 12:15 AM, Joel A Fernandes wrote:
> On Wed, Feb 20, 2013 at 10:26 PM, Stephen Warren
> wrote:
>> On 02/20/2013 06:37 PM, Joel A Fernandes wrote:
>>> Hello,
>>> I've been spinning some work-in-progress patches for FIT build support
>>> in the kernel.
>>> With the move to multiplatfor
This patch adds fdt nodes for peripherals which require
pin muxing and configuration. Device tree bindings for pinctrl
are kept same as required for Linux. Existing pinmux code
modified to retrieve gpio range and function related info from fdt.
Depends-on: [U-Boot] [PATCH 0/4 V3] EXYNOS5: Add GPIO
On Thu, 21 Feb 2013, Tom Rini wrote:
> FIT isn't required. FIT is just trying to offer a nice usability
> thing to folks.
Usability is often counter-balanced by maintenance costs.
> A point of device trees is a single image works in a
> lot of places. FIT gives you a single file works in a lot
Hi Michal,
On Mon, 4 Feb 2013 15:36:07 +0100, Michal Simek
wrote:
> Do lowlevel initialization directly in C. Zynq do not
> require to do it in asm.
>
> Signed-off-by: Michal Simek
> ---
> arch/arm/cpu/armv7/zynq/cpu.c | 26 +++-
> arch/arm/include/asm/arch-zynq/har
Hi Michal,
On Mon, 4 Feb 2013 15:36:05 +0100, Michal Simek
wrote:
> Enable DCC driver for arm zynq platform to be compiled.
>
> Signed-off-by: Michal Simek
> ---
> boards.cfg |1 +
> include/configs/zynq.h |5 +
> 2 files changed, 6 insertions(+), 0 deletions(-)
>
>
Hi Michal,
On Mon, 4 Feb 2013 15:36:05 +0100, Michal Simek
wrote:
> Enable DCC driver for arm zynq platform to be compiled.
>
> Signed-off-by: Michal Simek
> ---
> boards.cfg |1 +
> include/configs/zynq.h |5 +
> 2 files changed, 6 insertions(+), 0 deletions(-)
>
>
On Thursday 21 February 2013 11:27 PM, Tom Rini wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/21/2013 12:52 PM, R Sricharan wrote:
Hi Tom,
On Tuesday 19 February 2013 09:44 PM, Tom Rini wrote:
Hello,
The following changes since commit
9f024f62e4604274a23213dcee30016092e32e7b:
M
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/21/2013 12:52 PM, R Sricharan wrote:
> Hi Tom,
>
> On Tuesday 19 February 2013 09:44 PM, Tom Rini wrote:
>> Hello,
>>
>> The following changes since commit
>> 9f024f62e4604274a23213dcee30016092e32e7b:
>>
>> Merge branch 'fixes' of git://git.d
Hi Tom,
On Tuesday 19 February 2013 09:44 PM, Tom Rini wrote:
Hello,
The following changes since commit 9f024f62e4604274a23213dcee30016092e32e7b:
Merge branch 'fixes' of git://git.denx.de/u-boot-mips (2013-02-15 12:23:42
-0500)
are available in the git repository at:
git://git.denx.d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/21/2013 12:21 PM, Lukasz Majewski wrote:
> Dear All,
>
> I'd like to kindly ask for any feedback on this patch.
>
> It is now more than month on the u-boot mailing list...
OK, sorry, the generic name of the driver threw me for a minute. I'm
f
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/21/2013 12:25 PM, Nicolas Pitre wrote:
> On Thu, 21 Feb 2013, Tom Rini wrote:
[snip]
>>> uboot dug _itself_ into this hole. It's uboot's problem.
>>
>> A whole lot of people dug this particular hole. Joel is trying
>> to offer up a solution t
Dear Russell,
In message <20130221134656.gc17...@n2100.arm.linux.org.uk> you wrote:
>
> > Note that FIT images are relatively old (docs date back to March
> > 2008). This is more of another effort to try and update what the
> > kernel uses.
>
> So it's five years old and people haven't been that
The basic idea is taken from the linux-kernel, but further optimized.
First align the buffer to 8 bytes, then use ldrd/strd to read and store
in 8 byte quantities, then do the final bytes.
Tested using: 'date ; nand read.raw 0xE0 0x0 0x1 ; date'.
Without this patch, NAND read of 132MB too
Respin of my patch series for review. Only changes in patches 2 and 3:
env_nand.c: support falling back to redundant env when writing:
Print status message for each of the redundant copies when writing. So
when writing, we see which image is being written to. Also, when the first
attempt fai
Calculating the checksum of incompletely read data is useless.
Signed-off-by: Phil Sutter
---
common/env_nand.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/common/env_nand.c b/common/env_nand.c
index 60a87ec..0e1d17a 100644
--- a/common/env_nand.c
+++ b/common/env
Without this patch, when the currently chosen environment to be written
has bad blocks, saveenv fails completely. Instead, when there is
redundant environment fall back to the other copy. Environment reading
needs no adjustment, as the fallback logic for incomplete writes applies
to this case as we
The single message is misleading, since there is no equivalent success
note when reading the other copy succeeds. Instead, warn if one of the
redundant copies could not be loaded and emphasise on the error when
reading both fails.
Signed-off-by: Phil Sutter
---
common/env_nand.c | 12 -
Dear All,
I'd like to kindly ask for any feedback on this patch.
It is now more than month on the u-boot mailing list...
> Dear All,
>
> Any feedback about this patch?
>
> It has been on the list for quite long time.
>
>
> > Dear All,
> >
> > Any feedback about this patch?
> >
> > > T
I just noticed that I used 'tegra20.dtsi' in the tegra114.dtsi and
tegra30.dtsi files, which is obviously functionally wrong, but doesn't
break the build. I'll handle this when I apply this patchset to
u-boot-tegra/next (assuming it gets enough Acks). I'm also going to
submit a cleanup patch for th
Hi All,
I am planning to use devicetree on u-boot.
I have an experience to work with devicetree on Linux.
For u-boot, I have read doc from doc/README.fdt-control.
I see some dts usages on tegra boards.
I have lot of confusions with the concept itself.
Is Linux and u-boot devicetree concept and
When using the partial read feature of fatwrite the buffer we read into
can become unaligned not just due to initial location but the size of
our partial reads as well. Make this clear in the help text.
Signed-off-by: Tom Rini
---
common/cmd_fat.c |3 +++
1 file changed, 3 insertions(+)
di
tegra_mmc_init() now parses the DT info for bus width, WP/CD GPIOs, etc.
Tested on Seaboard, fully functional.
Tamonten boards (medcom-wide, plutux, and tec) use a different/new
dtsi file w/common settings.
Signed-off-by: Tom Warren
Signed-off-by: Thierry Reding
---
v2:
- all boards now call te
Tamonten boards (medcom-wide, plutux, and tec) use a different/new
dtsi file w/common settings.
Signed-off-by: Tom Warren
Acked-by: Thierry Reding
---
v3: new
v4: no change
v5: change /include/ to #include
v6: change AD DT files ARCH_CPU_DTS to "tegra20-tamonten.dtsi"
board/avionic-design/dts/
Linux dts files were used for those boards that didn't already
have sdhci info populated. Tamonten has their own dtsi file with
common sdhci nodes (sourced from Linux).
Signed-off-by: Tom Warren
Tested-by: Thierry Reding
---
v2:
- cleanup comments in dts files/match w/kernel files
- add sdhci al
dts Makefile has the arch & board include paths added to DTS_CPPFLAGS.
This allows the use of '#include "xyz"' in the dts/dtsi file which
helps the C preprocessor find common dtsi include files.
Signed-off-by: Tom Warren
---
---
v4: new
v5: add dts/dtsi paths to DTS_CPPFLAGS instead of DTC comman
This patchset adds device-tree support to the Tegra MMC driver.
All device config is done via properties in the DT files instead
of hard-coded config options/function arguments.
I've tested this on my Seaboard and everything works fine,
including card detect. For the other T20 boards, I've used
th
Stephen,
On Wed, Feb 20, 2013 at 5:15 PM, Stephen Warren wrote:
> On 02/20/2013 04:01 PM, Tom Warren wrote:
>> Stephen,
>>
>> On Wed, Feb 20, 2013 at 3:35 PM, Stephen Warren
>> wrote:
>>> On 02/20/2013 02:05 PM, Tom Warren wrote:
Linux dts files were used for those boards that didn't alrea
Thierry,
On Thu, Feb 21, 2013 at 2:00 AM, Thierry Reding
wrote:
> On Wed, Feb 20, 2013 at 02:05:46PM -0700, Tom Warren wrote:
>> This patchset adds device-tree support to the Tegra MMC driver.
>> All device config is done via properties in the DT files instead
>> of hard-coded config options/func
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/21/2013 01:58 AM, Bo Shen wrote:
> Hi Tom,
>
> On 2/21/2013 10:05, Tom Rini wrote:
>> On Wed, Feb 20, 2013 at 06:16:25PM +0800, Bo Shen wrote:
>>
>>> Change nand flash partition tablke according to
>>> www.at91.com/linux4sam
>>>
>>> more infor
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/21/2013 08:46 AM, Russell King - ARM Linux wrote:
> On Thu, Feb 21, 2013 at 08:20:56AM -0500, Tom Rini wrote:
>> On 02/21/2013 05:37 AM, Russell King - ARM Linux wrote:
>>> On Wed, Feb 20, 2013 at 07:37:10PM -0600, Joel A Fernandes
>>> wrote:
>>>
On Thu, Feb 21, 2013 at 08:20:56AM -0500, Tom Rini wrote:
> On 02/21/2013 05:37 AM, Russell King - ARM Linux wrote:
> > On Wed, Feb 20, 2013 at 07:37:10PM -0600, Joel A Fernandes wrote:
> >> Hello, I've been spinning some work-in-progress patches for FIT
> >> build support in the kernel. With the m
commit 39695029bc15041c809df3db4ba19bd729c447fa
Author: Charles Coldwell
Date: Tue Feb 19 08:27:33 2013 -0500
Changes to support the Xilinx 1000BASE-X phy (GTX/MGT)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index d0ed766..8a38ccb 100644
--- a/drivers/net/phy/phy.c
+++ b/dr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/20/2013 11:26 PM, Stephen Warren wrote:
> On 02/20/2013 06:37 PM, Joel A Fernandes wrote:
>> Hello, I've been spinning some work-in-progress patches for FIT
>> build support in the kernel. With the move to multiplatform
>> support on OMAP, I feel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/21/2013 05:37 AM, Russell King - ARM Linux wrote:
> On Wed, Feb 20, 2013 at 07:37:10PM -0600, Joel A Fernandes wrote:
>> Hello, I've been spinning some work-in-progress patches for FIT
>> build support in the kernel. With the move to multiplatfor
> "Mark" == Mark Jackson writes:
Mark> Currently WAIT0 irq is reset and then WAIT1 irq is enabled.
Mark> Fix it such that WAIT0 irq is enabled instead.
Mark> Signed-off-by: Mark Jackson
Mark> ---
Mark> arch/arm/cpu/armv7/am33xx/mem.c |2 +-
Mark> 1 file changed, 1 insertion(+), 1
Currently WAIT0 irq is reset and then WAIT1 irq is enabled.
Fix it such that WAIT0 irq is enabled instead.
Signed-off-by: Mark Jackson
---
arch/arm/cpu/armv7/am33xx/mem.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/am33xx/mem.c b/arch/arm/cpu/armv7/a
Hi Jean,
Accidentally I'm also currently debugging fat_write.
I have a problem with USB EHCI time-outs while writing but so far I have not
found a cure.
What I have found is this rather strange code in fat_write.c:
~line 659:
if (fat_val == 0xfff || fat_val == 0x)
On 19/02/13 14:55, Mark Jackson wrote:
> On 18/02/13 14:54, Tom Rini wrote:
>> On Mon, Feb 18, 2013 at 02:43:47PM +, Mark Jackson wrote:
>>> On 15/02/13 21:13, Tom Rini wrote:
On Thu, Feb 14, 2013 at 03:54:23PM +, Mark Jackson wrote:
> I'm trying to diagnose why our AM335x bas
Dear Simon Glass,
In message <1361379515-23802-18-git-send-email-...@chromium.org> you wrote:
> Add the CRC32 algorithm to the list of available hashes, and make
> the crc32 command use hash_command(). Add a new crc32_wd_buf() to
> make this possible, which puts its result in a buffer rather than
Dear Simon Glass,
In message <1361379515-23802-17-git-send-email-...@chromium.org> you wrote:
> Some hashing commands permit saving the hash in an environment variable,
> and verifying a hash from there. But the crc32 command does not support
> this. In order to permit crc32 to use the generic has
Hi Stefan,
On Wed, Feb 20, 2013 at 11:44 PM, Stefan Roese wrote:
> Hi Jagan,
>
> On 20.02.2013 18:25, Jagan Teki wrote:
>>> So please update to the latest version and try again.
>>
>> Sorry for not intimating the version I used, actually I am using the
>> latest u-boot version 2013.01.01
>> Below
Hi,
I use the last uboot from your git and boot with it on AM3517 EVM from SD
card
without NAND.
I use this option in uboot config : #define CONFIG_FAT_WRITE 1
I use intensively fatload / fatwrite commands at the boot before kernel
loading.
Sometimes, in about 2% of cases of boot, the FAT becom
On Wed, Feb 20, 2013 at 07:37:10PM -0600, Joel A Fernandes wrote:
> Hello,
> I've been spinning some work-in-progress patches for FIT build support
> in the kernel.
> With the move to multiplatform support on OMAP, I feel it is a good
> time to add FIT support, also looking at the proliferating nu
From: Scott Jiang
Spi driver for bf60x is different from old one, so implement a new
driver for it.
Signed-off-by: Scott Jiang
Signed-off-by: Sonic Zhang
Signed-off-by: Bob Liu
---
Changes in v4: None
Changes in v3: None
Changes in v2:
- Fix checkpatch issues
.../blackfin/include/asm/mach-c
1 - 100 of 125 matches
Mail list logo
