On 12/07/2013 07:06, Fabio Estevam wrote:
> On Fri, Jul 12, 2013 at 2:00 AM, Joe Hershberger
> wrote:
>
>> On second thought, it's delegated in patchwork to Stefano and it's
>> marked rejected. Why is that Stefano?
>
> Ok, I think I understand the reason. I asked him to reject the 1/2
> patch o
Hi Marek, hi Albert,
On 12/07/2013 07:57, Albert ARIBAUD wrote:
>
> This being a bugfix patch, and having been tested twice, I suggest that
> it go in 2013.07, maybe with the commit message reduced to its first
> paragraph above -- although of course I do appreciate the second one,
> except it t
Afterthought:
On Fri, 12 Jul 2013 07:57:18 +0200, Albert ARIBAUD
wrote:
> except it tends to minimize Marek's own contribution to the fix, which
> is by far the most important.
'The most important' 'by far' being of course Marek's contribution, not
minimizing it. :)
Amicalement,
--
Albert.
__
Hi Marek,
On Fri, 12 Jul 2013 01:03:04 +0200, Marek Vasut wrote:
> The MX28 multi-layer AHB bus can be too slow and trigger the
> FEC DMA too early, before all the data hit the DRAM. This patch
> ensures the data are written in the RAM before the DMA starts.
> Please see the comment in the patch
On Fri, Jul 12, 2013 at 12:06 AM, Fabio Estevam wrote:
> On Fri, Jul 12, 2013 at 2:00 AM, Joe Hershberger
> wrote:
>
>> On second thought, it's delegated in patchwork to Stefano and it's
>> marked rejected. Why is that Stefano?
>
> Ok, I think I understand the reason. I asked him to reject the 1
On Fri, Jul 12, 2013 at 1:58 AM, Marek Vasut wrote:
> Dear Fabio Estevam,
>
>> On Fri, Jul 12, 2013 at 1:40 AM, Marek Vasut wrote:
>> > Dear Fabio Estevam,
>> >
>> >> From: Fabio Estevam
>> >>
>> >> mx28evk has a LAN8270 ethernet phy and we can use the phylib framework.
>> >>
>> >> One of the ad
On Fri, Jul 12, 2013 at 1:06 AM, Marek Vasut wrote:
> Dear Alexandre Pereira da Silva,
>
>> On Thu, Jul 11, 2013 at 5:36 PM, Marek Vasut wrote:
>> > Dear Alexandre Pereira da Silva,
>> >
>> >> On Thu, Jul 11, 2013 at 4:55 PM, Marek Vasut wrote:
>> > Make sure to check the direction too, it can g
On Thu, Jul 11, 2013 at 10:49 PM, Nishanth Menon wrote:
> On 21:49-20130711, Joel Fernandes wrote:
>> On Thu, Jul 11, 2013 at 4:52 PM, Nishanth Menon wrote:
>> > We do not use JFFS2 by default and it conflicts with
>> > CONFIG_CMD_FS_GENERIC (ls command is t
On Thu, Jul 11, 2013 at 5:36 PM, Marek Vasut wrote:
> Dear Alexandre Pereira da Silva,
>
>> On Thu, Jul 11, 2013 at 4:55 PM, Marek Vasut wrote:
>
> Make sure to check the direction too, it can go either from phy to fec or the
> other way IIRC.
Ok, it seems this was caused by a bad tftp server an
On Thu, Jul 11, 2013 at 8:18 PM, Fabio Estevam wrote:
> On Thu, Jul 11, 2013 at 8:03 PM, Marek Vasut wrote:
>> The MX28 multi-layer AHB bus can be too slow and trigger the
>> FEC DMA too early, before all the data hit the DRAM. This patch
>> ensures the data are written in the RAM before the DMA
On Fri, Jul 12, 2013 at 2:00 AM, Joe Hershberger
wrote:
> On second thought, it's delegated in patchwork to Stefano and it's
> marked rejected. Why is that Stefano?
Ok, I think I understand the reason. I asked him to reject the 1/2
patch of the series (it was a mx28evk related patch).
This one
On Thu, Jul 11, 2013 at 11:57 PM, Joe Hershberger
wrote:
> On Thu, Jul 11, 2013 at 9:45 PM, Fabio Estevam wrote:
>> Hi Joe,
>>
>> On Thu, Jun 6, 2013 at 9:04 PM, Fabio Estevam wrote:
>>> From: Fabio Estevam
>>>
>>> LAN8710/8720 are 10/100 Mbps PHYs, so fix the '.features' field.
>>>
>>> Cc: Joe
Dear Fabio Estevam,
> On Fri, Jul 12, 2013 at 1:40 AM, Marek Vasut wrote:
> > Dear Fabio Estevam,
> >
> >> From: Fabio Estevam
> >>
> >> mx28evk has a LAN8270 ethernet phy and we can use the phylib framework.
> >>
> >> One of the advantages of converting to phylib is that we no longer see a
>
On Thu, Jul 11, 2013 at 9:45 PM, Fabio Estevam wrote:
> Hi Joe,
>
> On Thu, Jun 6, 2013 at 9:04 PM, Fabio Estevam wrote:
>> From: Fabio Estevam
>>
>> LAN8710/8720 are 10/100 Mbps PHYs, so fix the '.features' field.
>>
>> Cc: Joe Hershberger
>> Cc: Nobuhiro Iwamatsu
>> Signed-off-by: Fabio Este
From: Fabio Estevam
mx28evk has a LAN8270 ethernet phy and we can use the phylib framework.
One of the advantages of converting to phylib is that we no longer see a timeout
prior to the first transfer in the 'tftp' command.
Signed-off-by: Fabio Estevam
---
After applying this patch I get:
U-B
On Fri, Jul 12, 2013 at 1:40 AM, Marek Vasut wrote:
> Dear Fabio Estevam,
>
>> From: Fabio Estevam
>>
>> mx28evk has a LAN8270 ethernet phy and we can use the phylib framework.
>>
>> One of the advantages of converting to phylib is that we no longer see a
>> timeout prior to the first transfer in
Dear Alexandre Pereira da Silva,
> On Fri, Jul 12, 2013 at 1:06 AM, Marek Vasut wrote:
> > Dear Alexandre Pereira da Silva,
> >
> >> On Thu, Jul 11, 2013 at 5:36 PM, Marek Vasut wrote:
> >> > Dear Alexandre Pereira da Silva,
> >> >
> >> >> On Thu, Jul 11, 2013 at 4:55 PM, Marek Vasut wrote:
>
Dear Fabio Estevam,
> From: Fabio Estevam
>
> mx28evk has a LAN8270 ethernet phy and we can use the phylib framework.
>
> One of the advantages of converting to phylib is that we no longer see a
> timeout prior to the first transfer in the 'tftp' command.
>
> Signed-off-by: Fabio Estevam
> --
On 23:25-20130711, Joel Fernandes wrote:
> On Thu, Jul 11, 2013 at 10:49 PM, Nishanth Menon wrote:
> > On 21:49-20130711, Joel Fernandes wrote:
> >> On Thu, Jul 11, 2013 at 4:52 PM, Nishanth Menon wrote:
> >> > We do not use JFFS2 by default and it conflicts with
&g
Dear Alexandre Pereira da Silva,
> On Thu, Jul 11, 2013 at 5:36 PM, Marek Vasut wrote:
> > Dear Alexandre Pereira da Silva,
> >
> >> On Thu, Jul 11, 2013 at 4:55 PM, Marek Vasut wrote:
> > Make sure to check the direction too, it can go either from phy to fec or
> > the other way IIRC.
>
> Ok,
On 18:17-20130711, Robert Nelson wrote:
> On Thu, Jul 11, 2013 at 5:17 PM, Nishanth Menon wrote:
> > On 17:05-20130711, Robert Nelson wrote:
> >> On Thu, Jul 11, 2013 at 5:03 PM, Nishanth Menon wrote:
> >> > On 17:02-20130711, Robert Nelson wrote:
> >
Hi,
> On Thu, Jul 11, 2013 at 8:18 PM, Fabio Estevam wrote:
> > On Thu, Jul 11, 2013 at 8:03 PM, Marek Vasut wrote:
> >> The MX28 multi-layer AHB bus can be too slow and trigger the
> >> FEC DMA too early, before all the data hit the DRAM. This patch
> >> ensures the data are written in the RAM
On 21:49-20130711, Joel Fernandes wrote:
> On Thu, Jul 11, 2013 at 4:52 PM, Nishanth Menon wrote:
> > We do not use JFFS2 by default and it conflicts with
> > CONFIG_CMD_FS_GENERIC (ls command is the same). Since most of our
> > BOOTCMD can be simplified by using the FS_GE
On Thu, Jul 11, 2013 at 4:52 PM, Nishanth Menon wrote:
> We do not use JFFS2 by default and it conflicts with
> CONFIG_CMD_FS_GENERIC (ls command is the same). Since most of our
> BOOTCMD can be simplified by using the FS_GENERIC, dropping JFFS2
>
> Signed-off-by: Nishanth Menon
> ---
> include/
Hi Joe,
On Thu, Jun 6, 2013 at 9:04 PM, Fabio Estevam wrote:
> From: Fabio Estevam
>
> LAN8710/8720 are 10/100 Mbps PHYs, so fix the '.features' field.
>
> Cc: Joe Hershberger
> Cc: Nobuhiro Iwamatsu
> Signed-off-by: Fabio Estevam
Any comments?
___
Signed-off-by: Masahiro Yamada
---
drivers/mtd/nand/nand_util.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/nand_util.c b/drivers/mtd/nand/nand_util.c
index 1d22b52..bf74fe8 100644
--- a/drivers/mtd/nand/nand_util.c
+++ b/drivers/mtd/nand/nand_util.c
@@
On Thu, Jul 11, 2013 at 8:03 PM, Marek Vasut wrote:
> The MX28 multi-layer AHB bus can be too slow and trigger the
> FEC DMA too early, before all the data hit the DRAM. This patch
> ensures the data are written in the RAM before the DMA starts.
> Please see the comment in the patch for full detai
On Thu, Jul 11, 2013 at 5:17 PM, Nishanth Menon wrote:
> On 17:05-20130711, Robert Nelson wrote:
>> On Thu, Jul 11, 2013 at 5:03 PM, Nishanth Menon wrote:
>> > On 17:02-20130711, Robert Nelson wrote:
>> >> On Thu, Jul 11, 2013 at 4:52 PM, Nishanth Menon wrot
The MX28 multi-layer AHB bus can be too slow and trigger the
FEC DMA too early, before all the data hit the DRAM. This patch
ensures the data are written in the RAM before the DMA starts.
Please see the comment in the patch for full details.
This patch was produced with an amazing help from Albert
Albert,
Please pull u-boot-tegra/master into ARM/master. Thanks!
./MAKEALL -s tegra AOK, checkpatch.pl is clean.
The following changes since commit 630aacb0859c6e26b2b0311d8e245da5e5b8ac67:
Merge branch 'u-boot-samsung/master' into 'u-boot-arm/master' (2013-07-10
20:4
0:47 +0200)
are availab
On 07/11/2013 05:33 PM, Nishanth Menon wrote:
For folks not using concatenated device tree with uImage, having
an handy function to find and load device tree is very handy.
So introduce findfdt and loadfdt and run findfdt by default to make
it easier on user scripts.
Signed-off-by: Nishanth Men
If no other bootoption works, try loading up device tree and zImage.
This is selected as the last option to allow backward compatibility as
well as support the recent trend in moving kernel boot to using zImage
and device tree.
NOTE: if uImage is present in bootpart, it will try this first and
wi
For folks not using concatenated device tree with uImage, having
an handy function to find and load device tree is very handy.
So introduce findfdt and loadfdt and run findfdt by default to make
it easier on user scripts.
Signed-off-by: Nishanth Menon
---
include/configs/omap3_beagle.h | 17 +
CMD_FS_GENERIC allows us to simplify where we load up our image from
either from ext2/fat etc. So, lets use that instead of cumbersome
options we currently use. Sticking with existing conventions,
defaults will be:
ramdisk=ramdisk.gz
bootpart=0:2 (second partition)
bootdir=/boot (/boot in second pa
As reported in http://marc.info/?l=u-boot&m=137358037827735&w=2
There is no need for the "xMB" variant, as the gpio pins used for
identification where never changed from the xMA when the newer silcon
was used for the xMB, So rename XM A revision as AB revision
and report accordingly
Reported-by:
We do not use JFFS2 by default and it conflicts with
CONFIG_CMD_FS_GENERIC (ls command is the same). Since most of our
BOOTCMD can be simplified by using the FS_GENERIC, dropping JFFS2
Signed-off-by: Nishanth Menon
---
include/configs/omap3_beagle.h |8
1 file changed, 8 deletions(-
With the latest transition to device tree, there is a need to simplify
the load of device tree depending on board type etc. While at it, simplify
few other changes as well.
Testing:
with a uEnv.txt as:
bootdir=/
bootpart=0:1
The following were the boot results:
Beagle (rev C1D): http://pastebin.c
e682930867f7dfc4a01784fe452fad9e962d65a
(BeagleBoard: config: use uImage.beagle for tftp)
Introduced uImage.beagle which does not happen to be default output
file of Linux kernel build make uImage (output is uImage).
So, replace uImage.beagle with uImage
Signed-off-by: Nishanth Menon
---
inclu
On 17:05-20130711, Robert Nelson wrote:
> On Thu, Jul 11, 2013 at 5:03 PM, Nishanth Menon wrote:
> > On 17:02-20130711, Robert Nelson wrote:
> >> On Thu, Jul 11, 2013 at 4:52 PM, Nishanth Menon wrote:
> >> > For folks not using concatenated device tree with
On Thu, Jul 11, 2013 at 5:03 PM, Nishanth Menon wrote:
> On 17:02-20130711, Robert Nelson wrote:
>> On Thu, Jul 11, 2013 at 4:52 PM, Nishanth Menon wrote:
>> > For folks not using concatenated device tree with uImage, having
>> > an handy function to find and loa
On 17:02-20130711, Robert Nelson wrote:
> On Thu, Jul 11, 2013 at 4:52 PM, Nishanth Menon wrote:
> > For folks not using concatenated device tree with uImage, having
> > an handy function to find and load device tree is very handy.
> >
> > So introduce findfdt and
On Thu, Jul 11, 2013 at 4:52 PM, Nishanth Menon wrote:
> For folks not using concatenated device tree with uImage, having
> an handy function to find and load device tree is very handy.
>
> So introduce findfdt and loadfdt and run findfdt by default to make
> it easier on user scripts.
>
> Signed-
We do not use JFFS2 by default and it conflicts with
CONFIG_CMD_FS_GENERIC (ls command is the same). Since most of our
BOOTCMD can be simplified by using the FS_GENERIC, dropping JFFS2
Signed-off-by: Nishanth Menon
---
include/configs/omap3_beagle.h |8
1 file changed, 8 deletions(-
If no other bootoption works, try loading up device tree and zImage.
This is selected as the last option to allow backward compatibility as
well as support the recent trend in moving kernel boot to using zImage
and device tree.
NOTE: if uImage is present in bootpart, it will try this first and
wi
e682930867f7dfc4a01784fe452fad9e962d65a
(BeagleBoard: config: use uImage.beagle for tftp)
Introduced uImage.beagle which does not happen to be default output
file of Linux kernel build make uImage (output is uImage).
So, replace uImage.beagle with uImage
Signed-off-by: Nishanth Menon
---
inclu
With the latest transition to device tree, there is a need to simplify
the load of device tree depending on board type etc. While at it, simplify
few other changes as well.
Testing:
with a uEnv.txt as:
bootdir=/
bootpart=0:1
The following were the boot results:
Beagle (rev C1D): http://pastebin.c
CMD_FS_GENERIC allows us to simplify where we load up our image from
either from ext2/fat etc. So, lets use that instead of cumbersome
options we currently use. Sticking with existing conventions,
defaults will be:
ramdisk=ramdisk.gz
bootpart=0:2 (second partition)
bootdir=/boot (/boot in second pa
For folks not using concatenated device tree with uImage, having
an handy function to find and load device tree is very handy.
So introduce findfdt and loadfdt and run findfdt by default to make
it easier on user scripts.
Signed-off-by: Nishanth Menon
---
include/configs/omap3_beagle.h | 17 +
Thanks Stefano,
On 07/11/2013 06:06 AM, Stefano Babic wrote:
(header for Freescale's i.MX processors) to allow the usage of
Freescale's tools to sign the u-boot image and provide a secure boot.
This has nothing to do with the Secure Boot extensions implemented by
Simon Glass, that can be in any
Dear Thierry Reding,
In message <20130711190849.ga17...@dhcp-172-17-186-34.nvidia.com> you wrote:
>
> > This depends a lot on a number of things. For example, you should be
> > able to use a ramdisk in NOR flash directly, i. e. without loading it
> > to RAM first - especially if it;s a comprtess
Dear Stephen Warren,
In message <51df024c.2080...@wwwdotorg.org> you wrote:
>
> > This depends a lot on a number of things. For example, you should be
> > able to use a ramdisk in NOR flash directly, i. e. without loading it
> > to RAM first - especially if it;s a comprtessed ramdis image, and th
Dear Alexandre Pereira da Silva,
> On Thu, Jul 11, 2013 at 4:55 PM, Marek Vasut wrote:
> > Dear Alexandre Pereira da Silva,
> >
> >> Hi,
> >>
> >> I am trying to make my ethernet work with u-boot on a custom IMX28
> >> board.
> >>
> >> This board uses the micrel KSZ8021 phy.
> >>
> >> The net
Dear Wolfgang Denk,
> Like many other projects, U-Boot has a tradition of including big
> blocks of License headers in all files. This not only blows up the
> source code with mostly redundant information, but also makes it very
> difficult to generate License Clearing Reports. An additional pro
On Thu, Jul 11, 2013 at 4:55 PM, Marek Vasut wrote:
> Dear Alexandre Pereira da Silva,
>
>> Hi,
>>
>> I am trying to make my ethernet work with u-boot on a custom IMX28 board.
>>
>> This board uses the micrel KSZ8021 phy.
>>
>> The network works fine on linux but won't work properly on u-boot.
>>
Hi,
I am trying to make my ethernet work with u-boot on a custom IMX28 board.
This board uses the micrel KSZ8021 phy.
The network works fine on linux but won't work properly on u-boot.
Here is the output:
=> dhcp
BOOTP broadcast 1
DHCP client bound to address 192.168.1.103
Using FEC device
TFTP
Dear Alexandre Pereira da Silva,
> Hi,
>
> I am trying to make my ethernet work with u-boot on a custom IMX28 board.
>
> This board uses the micrel KSZ8021 phy.
>
> The network works fine on linux but won't work properly on u-boot.
>
> Here is the output:
> => dhcp
> BOOTP broadcast 1
> DHCP c
On Thu, Jul 11, 2013 at 08:21:17PM +0200, Wolfgang Denk wrote:
> Dear Thierry Reding,
>
> In message <20130711150014.ga2...@dhcp-172-17-186-34.nvidia.com> you wrote:
> >
> > > I'm pretty sure it's all architectures, and this is a problem for device
> > > trees as well. The tricks done to deal wi
On 07/11/2013 12:21 PM, Wolfgang Denk wrote:
> Dear Thierry Reding,
>
> In message <20130711150014.ga2...@dhcp-172-17-186-34.nvidia.com> you wrote:
>>
>>> I'm pretty sure it's all architectures, and this is a problem for device
>>> trees as well. The tricks done to deal with highmem mean it's not
Dear Stefano Babic,
> Add functions to report the HAB (High Assurance Boot) status
> of e.g. i.MX6 CPUs.
>
> This is taken from
>
> git://git.freescale.com/imx/uboot-imx.git branch imx_v2009.08_3.0.35_4.0.0
> cpu/arm_cortexa8/mx6/generic.c
> include/asm-arm/arch-mx6/mx6_secure.h
>
> Signed-off-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/11/2013 02:21 PM, Wolfgang Denk wrote:
> Dear Thierry Reding,
[snip]
Also, when changing the behaviour, you should also update
the comments.
>>>
>>> Agreed.
>>
>> I'm not sure which comments you are referring to. I updated the
>> one
Dear Stefano Babic,
> Change to dynamically allocate the imx_header to correctly
> allocate the IVT, Boot Data and DCD at correct locations
> depending on the boot media.
>
> Also check that the Image Vector Table Offset + IVT +
> Boot Data + DCD <= Initial Load Region Size.
>
> Previously struc
Dear Thierry Reding,
In message <20130711150014.ga2...@dhcp-172-17-186-34.nvidia.com> you wrote:
>
> > I'm pretty sure it's all architectures, and this is a problem for device
> > trees as well. The tricks done to deal with highmem mean it's not
> > suitable for certain tasks, if I recall things
On 07/11/2013 11:11 AM, Otavio Salvador wrote:
On Thu, Jul 11, 2013 at 10:06 AM, Stefano Babic wrote:
>>
>>
Next step is to verify the kernel, that can be still done using Simon's patches
for
verified boot (CONFIG_OF_CONTROL must be set in the board configuarion file).
I didn't yet test
Dear Stefano Babic,
In message <1373548001-19728-7-git-send-email-sba...@denx.de> you wrote:
> Add support for setting the CSF (Command Sequence File) pointer
> which is used for HAB (High Assurance Boot) in the imximage by
> adding e.g.
This patch throws a checkpatch error that needs to be fixed
Configure the tca6424 gpio expander
This allows use of the debug and tri color LEDs.
Signed-off-by: Dan Murphy
---
v2 - Updated per comments - http://patchwork.ozlabs.org/patch/257603/
v3 - Updated documentation. No change to mux data the code is the
patch is required or I2C reads fail - http://
On Thu, Jul 11, 2013 at 10:06 AM, Stefano Babic wrote:
> (header for Freescale's i.MX processors) to allow the usage of
> Freescale's tools to sign the u-boot image and provide a secure boot.
>
> This has nothing to do with the Secure Boot extensions implemented by
> Simon Glass, that can be in an
Add the tca642x gpio expander driver
Datasheet:
http://www.ti.com/product/tca6424a
Signed-off-by: Dan Murphy
---
v2 - Updated per comments - http://patchwork.ozlabs.org/patch/257602/
v3 - Fixed checkpatch issues - http://patchwork.ozlabs.org/patch/257841/
drivers/gpio/Makefile |1 +
driv
On Thu, Jul 11, 2013 at 07:40:28PM +0200, Albert ARIBAUD wrote:
> Hi Tom,
>
> On Thu, 11 Jul 2013 12:15:50 -0400, Tom Rini wrote:
>
> > On Thu, Jun 27, 2013 at 11:41:59AM +0200, Albert ARIBAUD wrote:
> > > Hi Sascha,
> > >
> > > On Tue, 25 Jun 2013 11:42:53 +0200, Sascha Silbe
> > > wrote:
> >
On Jul 11, 2013 10:55 AM, "Dan Murphy" wrote:
>
> On 07/10/2013 06:56 PM, Nishanth Menon wrote:
> > On 07/10/2013 03:06 PM, Dan Murphy wrote:
> >> Configure the tca6424 gpio expander
> >> This allows use of the debug and tri color LEDs.
> >>
> >> Signed-off-by: Dan Murphy
> >> ---
> >> board/ti
Hi Tom,
On Thu, 11 Jul 2013 12:15:50 -0400, Tom Rini wrote:
> On Thu, Jun 27, 2013 at 11:41:59AM +0200, Albert ARIBAUD wrote:
> > Hi Sascha,
> >
> > On Tue, 25 Jun 2013 11:42:53 +0200, Sascha Silbe
> > wrote:
> >
> > > Hello Albert, hello Tom,
> > >
> > > Albert ARIBAUD writes:
> > >
> > >
On Thu, Jul 11, 2013 at 01:01:30PM -0400, Michael Cashwell wrote:
> Greetings,
>
> I've been absent for a while and couldn't find a way to search the
> list archives so I apologize if this has already been discussed?
>
> I've been fighting the SPL binary growing too large on OMAP4 (using
> custom
Hi Stefano,
On Thu, Jul 11, 2013 at 10:06 AM, Stefano Babic wrote:
> --- a/arch/arm/cpu/armv7/mx6/Makefile
> +++ b/arch/arm/cpu/armv7/mx6/Makefile
> @@ -27,7 +27,7 @@ include $(TOPDIR)/config.mk
>
> LIB= $(obj)lib$(SOC).o
Whole series looks good.
Only a minor comment:
> -COBJS = soc.o c
Greetings,
I've been absent for a while and couldn't find a way to search the list
archives so I apologize if this has already been discussed…
I've been fighting the SPL binary growing too large on OMAP4 (using custom
configs and features). It's annoying that too large just fails to run with no
Yes, the u-boot is based off of 2010.12:
The source with the odroid-u2 (Exynos4412) mods are in
https://github.com/hardkernel/u-boot
You are right, the problem is in enabling USB. I do not seem ot find
documentation as to the IO addresses and what values to poke/peek in them
to initialize and powe
On Thu, Jul 11, 2013 at 06:14:11PM +0200, Albert ARIBAUD wrote:
> On Thu, 11 Jul 2013 18:08:59 +0200, Albert ARIBAUD
> wrote:
>
> > Hi Tom,
> >
> > On Thu, 11 Jul 2013 11:54:09 -0400, Tom Rini wrote:
> >
> > > The new in the patch
> > > board/ti/am335x/u-boot.lds needed to be re-synced with
>
On Thu, Jun 27, 2013 at 11:41:59AM +0200, Albert ARIBAUD wrote:
> Hi Sascha,
>
> On Tue, 25 Jun 2013 11:42:53 +0200, Sascha Silbe
> wrote:
>
> > Hello Albert, hello Tom,
> >
> > Albert ARIBAUD writes:
> >
> > [Move environment to account for increase in U-Boot size]
> > > This patch is for 20
On Thu, 11 Jul 2013 18:08:59 +0200, Albert ARIBAUD
wrote:
> Hi Tom,
>
> On Thu, 11 Jul 2013 11:54:09 -0400, Tom Rini wrote:
>
> > The new in the patch
> > board/ti/am335x/u-boot.lds needed to be re-synced with
> > arch/arm/cpu/u-boot.lds again.
>
> Actually, I wonder why so many ARM .lds file
Hi Tom,
On Thu, 11 Jul 2013 11:54:09 -0400, Tom Rini wrote:
> The new in the patch
> board/ti/am335x/u-boot.lds needed to be re-synced with
> arch/arm/cpu/u-boot.lds again.
Actually, I wonder why so many ARM .lds files need to exist at all,
when arch/arm/cpu/u-boot[-spl].lds could be used most
I'm struggling to work out why I get the following compile error:-
arm-linux-ld.bfd -r -o /home/mpfj/uboot/u-boot/spl/common/libcommon.o
/home/mpfj/uboot/u-boot/spl/common/cmd_nvedit.o
/home/mpfj/uboot/u-boot/spl/common/console.o
/home/mpfj/uboot/u-boot/spl/common/dlmalloc.o
/home/mpfj/uboot
Dear Roger Quadros,
> Hi Marek,
>
> On 07/11/2013 03:35 PM, Marek Vasut wrote:
> > Dear Roger Quadros,
> >
> >> On 07/11/2013 02:16 AM, Dan Murphy wrote:
> >>> On 07/10/2013 05:20 PM, Marek Vasut wrote:
> Dear Dan Murphy,
>
> > Add a __weak function that can be overridden to reset
On 07/10/2013 06:56 PM, Nishanth Menon wrote:
> On 07/10/2013 03:06 PM, Dan Murphy wrote:
>> Configure the tca6424 gpio expander
>> This allows use of the debug and tri color LEDs.
>>
>> Signed-off-by: Dan Murphy
>> ---
>> board/ti/omap5_uevm/evm.c | 21 +
>> board/ti
On Thu, Jul 11, 2013 at 04:34:18PM +0200, Albert ARIBAUD wrote:
> Hi Mark,
>
> On Thu, 11 Jul 2013 14:45:08 +0100, Mark Jackson
> wrote:
>
> > On 11/07/13 14:28, Tom Rini wrote:
> > > On Thu, Jul 11, 2013 at 02:06:26PM +0100, Mark Jackson wrote:
> > >> On 18/06/13 13:11, Mark Jackson wrote:
> >
Roger
On 07/11/2013 09:23 AM, Roger Quadros wrote:
> Hi Marek,
>
> On 07/11/2013 03:35 PM, Marek Vasut wrote:
>> Dear Roger Quadros,
>>
>>> On 07/11/2013 02:16 AM, Dan Murphy wrote:
On 07/10/2013 05:20 PM, Marek Vasut wrote:
> Dear Dan Murphy,
>
>> Add a __weak function that can be
Remove incorrectly called and duplicate flush_dcache_range() call
from fec_mxc driver. The call is not needed, since the caches are
already flushed in fec_tbd_init(), moreover the second argument should
be the ending address, not size.
Signed-off-by: Marek Vasut
Reported-by: Albert Aribaud
Cc: S
Add config file
Signed-off-by: Lokesh Vutla
---
boards.cfg |1 +
include/configs/am43xx_evm.h | 143 ++
2 files changed, 144 insertions(+)
create mode 100644 include/configs/am43xx_evm.h
diff --git a/boards.cfg b/boards.cfg
index c
Add AM43xx support in the required places
Signed-off-by: Lokesh Vutla
---
arch/arm/cpu/armv7/Makefile |2 +-
arch/arm/cpu/armv7/omap-common/boot-common.c |3 ++-
drivers/serial/ns16550.c |5 +++--
3 files changed, 6 insertions(+), 4 deletions(-)
Add dpll and clock data for AM43xx
Signed-off-by: Lokesh Vutla
---
arch/arm/cpu/armv7/am33xx/Makefile |7 +-
arch/arm/cpu/armv7/am33xx/clock_am43xx.c | 120 ++
2 files changed, 126 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/cpu/armv7/am33xx/c
AM43xx is a low cost Cortex-A9 based application processor
targets higher performance applications and new specific end
equipments like Point of Sale requiring stringent security requirements.
This series add support for AM43xx Soc's.
Data for the following is not added:
-> SDRAM
-> DPLL Dividers
Adding the following data:
-> Prcm structure
-> Base addresses
-> Pin mux structure.
Signed-off-by: Lokesh Vutla
---
arch/arm/include/asm/arch-am33xx/cpu.h | 164 +++-
arch/arm/include/asm/arch-am33xx/hardware.h|8 +-
arch/arm/include/asm/arch-am33xx/hard
Add board specific information for AM43xx.
Signed-off-by: Lokesh Vutla
---
board/ti/am43xx/Makefile | 46 ++
board/ti/am43xx/board.c | 55 ++
board/ti/am43xx/board.h | 25 +
board/ti/am43x
Adding a new CONFIG_OMAP_COMMON which is included by all boards
that needs to build cpu/armv7/omap-common folder.
Signed-off-by: Lokesh Vutla
---
Makefile|2 +-
arch/arm/config.mk |2 +-
arch/arm/cpu/armv7/omap-common/Makefile |2 +
On 07/11/2013 09:31 AM, Tom Rini wrote:
> On Wed, Jul 10, 2013 at 03:06:02PM -0500, Dan Murphy wrote:
>
>> Add the tca642x gpio expander driver
>>
>> Datasheet:
>> http://www.ti.com/product/tca6424a
>>
>> Signed-off-by: Dan Murphy
>> ---
>> drivers/gpio/Makefile |1 +
>> drivers/gpio/tca642x
On 07/11/2013 09:30 AM, Tom Rini wrote:
> On Wed, Jul 10, 2013 at 06:56:15PM -0500, Nishanth Menon wrote:
>> On 07/10/2013 03:06 PM, Dan Murphy wrote:
>>> Configure the tca6424 gpio expander
>>> This allows use of the debug and tri color LEDs.
>>>
>>> Signed-off-by: Dan Murphy
>>> ---
>>> board/t
On Thu, Jul 11, 2013 at 08:39:28AM -0400, Tom Rini wrote:
> On Thu, Jul 11, 2013 at 11:46:19AM +0200, Wolfgang Denk wrote:
> > Dear Thierry Reding,
> >
> > In message <1373500071-6476-1-git-send-email-thierry.red...@gmail.com> you
> > wrote:
> > >
> > > The Linux kernel cannot unpack a ramdisk t
On Wed, Jul 10, 2013 at 10:08:13PM -0400, David Lee wrote:
> Hi.
>
> We had U-Boot booting Linux just fine. Then after some minor cleanup, we
> rebuild the images.
>
> Thereafter, we are now seeing U-Boot reporting the error below:
>
> *"ERROR: new format image overwritten ?** must reset the bo
Hi.
We had U-Boot booting Linux just fine. Then after some minor cleanup, we
rebuild the images.
Thereafter, we are now seeing U-Boot reporting the error below:
*"ERROR: new format image overwritten –** must reset the board to recover"*
We tried reverting the minor cleanup we had done and then
On Wed, Jul 10, 2013 at 03:05:09PM -0500, Dan Murphy wrote:
> Add the USB ehci support for the OMAP5 uEVM.
>
> Configure the uEVM mux data
> Add the flags to build the appropriate modules
> Add the usb call backs to initialize the EHCI controller
>
> Signed-off-by: Dan Murphy
[snip]
> diff --gi
Hi Stefano,
Sure, I can try this on my side. I will let you know about this shortly.
Thank you very much for giving your input.
Thanks & Regards,
Pardeep Singla
-Original Message-
From: Stefano Babic [mailto:sba...@denx.de]
Sent: Wednesday, July 10, 2013 8:25 AM
To: Kumar Singla Pardeep-
On Thu, Jul 11, 2013 at 11:55:59AM +0300, Roger Quadros wrote:
> On 07/11/2013 11:35 AM, Sricharan R wrote:
> > On Thursday 11 July 2013 01:28 PM, Roger Quadros wrote:
> >> On 07/11/2013 06:51 AM, Lokesh Vutla wrote:
> >>> On Thursday 11 July 2013 01:35 AM, Dan Murphy wrote:
> * Enable the OMA
Hi Mark,
On Thu, 11 Jul 2013 14:45:08 +0100, Mark Jackson
wrote:
> On 11/07/13 14:28, Tom Rini wrote:
> > On Thu, Jul 11, 2013 at 02:06:26PM +0100, Mark Jackson wrote:
> >> On 18/06/13 13:11, Mark Jackson wrote:
> >>> On 17/06/13 15:43, Mark Jackson wrote:
> >>
> >> Okay ... I've now got NOR boo
1 - 100 of 145 matches
Mail list logo
