Hi Fabio,
Sorry for not replying sooner.
I want to enable two LVDS channels because I noticed that the kernel
does not "seem" to initialize properly them if they are not initialized
before by the bootloader.
I'm also trying to understand the reason for this behavior.
Igor
Hi Igor,
On Fri, Apr
From: Sonic Zhang
The gpio spec for bf54x and bf60x differ a lot from the old gpio driver for
bf5xx.
A lot of machine macros are used to accomodate both code in one gpio driver.
This patch split the old gpio driver and move new gpio2 support to the generic
gpio driver folder.
- To enable gpio2
Hello,
I'm using customized mpc8315e board with a PHY called DP83848 ,
I have changed tsec file to support DP83848, and link's status led is blinkging
after cable is connected to PC.
But when I set the ip etc and to ping a PC , I got this error:
> ping 192.168.2.157
Trying eTSEC0
startup_
Hi Andy,
Could you please apply this patch?
http://patchwork.ozlabs.org/patch/217104/
Thanks.
- dongsheng
> -Original Message-
> From: Wang Dongsheng-B40534
> Sent: Monday, March 11, 2013 5:31 PM
> To: Fleming Andy-AFLEMING
> Cc: 'u-boot@lists.denx.de'
> Subject: RE: [PATCH] powerpc/mp
Hi to all.
Someone has experience in initialization DDR3 RAM 32bit width mode for this
processor?
Thanks
--
View this message in context:
http://u-boot.10912.n7.nabble.com/uboot-for-cavium-octeon-2-MIPS-SOC-tp153711.html
Sent from the U-Boot mailing list archive at Nabble.com.
On Wed, May 1, 2013 at 9:14 PM, Marek Vasut wrote:
> Stuff it into common init sequence, but only if it really is necessary to wipe
> those registers and iomux_setup[] table doesn't do it for some reason.
>
> But then, if iomux_setup[] table doesn't configure them, there's a deeper
> problem.
Ri
Dear Fabio Estevam,
> On Wed, May 1, 2013 at 9:13 PM, Marek Vasut wrote:
> > How come? Doesn't the board/...mx23.../spl_boot.c use that? Or iomux.c in
> > FSL's parlance.
>
> I meant mxs_pinctrl_regs structure is only referenced for mx28 currently:
>
> #ifdef CONFIG_MX28
> static void mx28_mem_
2013/5/2 Marek Vasut :
> Dear Kuo-Jung Su,
>
>> 2013/4/30 Marek Vasut :
>> > Dear Kuo-Jung Su,
>> >
>> >> 2013/4/26 Marek Vasut :
>> >> > Dear Kuo-Jung Su,
>> >> >
>> >> >> From: Kuo-Jung Su
>> >> >>
>> >> >> This patch add supports to both Faraday FUSBH200 and FOTG210,
>> >> >> these controllers
On Wed, May 1, 2013 at 9:13 PM, Marek Vasut wrote:
> How come? Doesn't the board/...mx23.../spl_boot.c use that? Or iomux.c in
> FSL's
> parlance.
I meant mxs_pinctrl_regs structure is only referenced for mx28 currently:
#ifdef CONFIG_MX28
static void mx28_mem_init(void)
{
struct mxs_p
On Wed, May 1, 2013 at 9:15 PM, Marek Vasut wrote:
> You'll end up messing with configuration registers on already-running RAM.
> That
HW_DRAM_CTL08, bit 16 (START) is 0 (inactive) after a reset, so no
need to turn off the RAM.
___
U-Boot mailing list
Dear Fabio Estevam,
> On Wed, May 1, 2013 at 8:29 PM, Marek Vasut wrote:
> > Do you not need to stop the DRAM if it's already running? Like after a
> > software reset?
>
> I don't think this is needed. FSL bootlets code does not do this.
You'll end up messing with configuration registers on alr
Dear Fabio Estevam,
> On Wed, May 1, 2013 at 8:28 PM, Marek Vasut wrote:
> > Lost of duplicated code here.
>
> What do you suggest?
Stuff it into common init sequence, but only if it really is necessary to wipe
those registers and iomux_setup[] table doesn't do it for some reason.
But then, i
Dear Fabio Estevam,
> On Wed, May 1, 2013 at 8:28 PM, Marek Vasut wrote:
> > Uh, should the pinctrl/iomux stuff not set these up properly?
>
> This is mx23 and EMI pins specific, so I think it is OK to do it in
> the board file.
Yes, but should the iomux_setup[] configure that already?
Best re
Dear Fabio Estevam,
> On Wed, May 1, 2013 at 8:27 PM, Marek Vasut wrote:
> > Dear Fabio Estevam,
> >
> >> From: Fabio Estevam
> >>
> >> Provide a mxs_pinctrl_regs structure for mx23.
> >>
> >> Signed-off-by: Fabio Estevam
> >
> > So the pinctrl structure was always wrong on mx23? Otavio?
>
Dear Fabio Estevam,
> On Wed, May 1, 2013 at 8:26 PM, Marek Vasut wrote:
> > Dear Fabio Estevam,
> >
> >> From: Fabio Estevam
> >>
> >> Currently when accessing an element of mxs_pinctrl_regs structure we do:
> >>
> >> &pinctrl_regs->hw_pinctrl_emi_ds_ctrl_set
> >>
> >> The 'hw_pinctrl' pref
On Wed, May 1, 2013 at 8:28 PM, Marek Vasut wrote:
> Uh, should the pinctrl/iomux stuff not set these up properly?
This is mx23 and EMI pins specific, so I think it is OK to do it in
the board file.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://l
On Wed, May 1, 2013 at 8:29 PM, Marek Vasut wrote:
> Do you not need to stop the DRAM if it's already running? Like after a
> software
> reset?
I don't think this is needed. FSL bootlets code does not do this.
___
U-Boot mailing list
U-Boot@lists.denx
On Wed, May 1, 2013 at 8:28 PM, Marek Vasut wrote:
> Lost of duplicated code here.
What do you suggest?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
On Wed, May 1, 2013 at 8:27 PM, Marek Vasut wrote:
> Dear Fabio Estevam,
>
>> From: Fabio Estevam
>>
>> Provide a mxs_pinctrl_regs structure for mx23.
>>
>> Signed-off-by: Fabio Estevam
>
> So the pinctrl structure was always wrong on mx23? Otavio?
pinctrl structure was never used on mx23 in U
On Wed, May 1, 2013 at 8:26 PM, Marek Vasut wrote:
> Dear Fabio Estevam,
>
>> From: Fabio Estevam
>>
>> Currently when accessing an element of mxs_pinctrl_regs structure we do:
>>
>> &pinctrl_regs->hw_pinctrl_emi_ds_ctrl_set
>>
>> The 'hw_pinctrl' prefix is a redundant information as we already k
Dear Fabio Estevam,
> From: Fabio Estevam
>
> HW_DRAM_CTL27, HW_DRAM_CTL28 and HW_DRAM_CTL35 are not initialized as per
> FSL bootlets code.
>
> mx23 Reference Manual mark HW_DRAM_CTL27 and HW_DRAM_CTL28 as "reserved".
>
> HW_DRAM_CTL8 is setup as the last element.
>
> So skip the initializat
Dear Fabio Estevam,
> From: Fabio Estevam
>
> There is no need to write to DRAM_CTL8 register prior to
> nitialize_dram_values().
>
> Fix a comment related to writing to DRAM_CTL8.
>
> Also, DRAM_CTL18 register on mx23 does not contain DRAM init complete bit,
> so remove this setting as this i
Dear Fabio Estevam,
> From: Fabio Estevam
>
> Registers HW_PINCTRL_DRIVE9, HW_PINCTRL_DRIVE10, HW_PINCTRL_DRIVE11,
> HW_PINCTRL_DRIVE12, HW_PINCTRL_DRIVE13 and HW_PINCTRL_DRIVE14 control the
> drive strength and the voltage selection for the DDR pins.
>
> The reset values of the voltage selecti
Dear Fabio Estevam,
> From: Fabio Estevam
>
> Registers HW_PINCTRL_DRIVE9, HW_PINCTRL_DRIVE10, HW_PINCTRL_DRIVE11,
> HW_PINCTRL_DRIVE12, HW_PINCTRL_DRIVE13 and HW_PINCTRL_DRIVE14 control the
> drive strength and the voltage selection for the DDR pins.
>
> The reset values of the voltage selecti
Dear Fabio Estevam,
> From: Fabio Estevam
>
> Provide a mxs_pinctrl_regs structure for mx23.
>
> Signed-off-by: Fabio Estevam
So the pinctrl structure was always wrong on mx23? Otavio?
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.
Dear Fabio Estevam,
> From: Fabio Estevam
>
> Currently when accessing an element of mxs_pinctrl_regs structure we do:
>
> &pinctrl_regs->hw_pinctrl_emi_ds_ctrl_set
>
> The 'hw_pinctrl' prefix is a redundant information as we already know that
> we are accessing a pinctrl register.
>
> Signed
Adding Jim back into the conversation since he got dropped a couple of
emails back.
On Wed, May 1, 2013 at 4:20 PM, Tom Warren wrote:
>
>
>
> On Wed, May 1, 2013 at 12:33 PM, Marek Vasut wrote:
>
>> Dear Tom Rini,
>>
>> > On Wed, May 01, 2013 at 09:16:45AM -0700, Tom Warren wrote:
>> > > Tom,
On Wed, May 1, 2013 at 12:33 PM, Marek Vasut wrote:
> Dear Tom Rini,
>
> > On Wed, May 01, 2013 at 09:16:45AM -0700, Tom Warren wrote:
> > > Tom,
> > >
> > > On Tue, Apr 30, 2013 at 10:20 AM, Tom Rini wrote:
> > > > On Tue, Apr 30, 2013 at 09:21:18AM -0700, Tom Warren wrote:
> > > > > Marek,
> >
From: Fabio Estevam
FSL bootlets code set the PORT_PRIORITY_ORDER field of register HW_EMI_CTRL
as 0x2, which means:
PORT0231 = 0x02 Priority Order: AXI0, AHB2, AHB3, AHB1
Signed-off-by: Fabio Estevam
---
arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c |2 +-
1 file changed, 1 insertion(+), 1 d
From: Fabio Estevam
Disable the internal pad keepers to match the code from FSL bootlets and provide
better stability.
Signed-off-by: Fabio Estevam
---
board/olimex/mx23_olinuxino/spl_boot.c |4
1 file changed, 4 insertions(+)
diff --git a/board/olimex/mx23_olinuxino/spl_boot.c
b/bo
From: Fabio Estevam
HW_DRAM_CTL27, HW_DRAM_CTL28 and HW_DRAM_CTL35 are not initialized as per
FSL bootlets code.
mx23 Reference Manual mark HW_DRAM_CTL27 and HW_DRAM_CTL28 as "reserved".
HW_DRAM_CTL8 is setup as the last element.
So skip the initialization of these DRAM_CTL registers.
Signed
From: Fabio Estevam
There is no need to write to DRAM_CTL8 register prior to
nitialize_dram_values().
Fix a comment related to writing to DRAM_CTL8.
Also, DRAM_CTL18 register on mx23 does not contain DRAM init complete bit, so
remove this setting as this is also not done by FSL bootlets code.
From: Fabio Estevam
Disable the internal pad keepers to match the code from FSL bootlets and provide
better stability.
Signed-off-by: Fabio Estevam
---
board/freescale/mx23evk/spl_boot.c |4
1 file changed, 4 insertions(+)
diff --git a/board/freescale/mx23evk/spl_boot.c
b/board/free
From: Fabio Estevam
Registers HW_PINCTRL_DRIVE9, HW_PINCTRL_DRIVE10, HW_PINCTRL_DRIVE11,
HW_PINCTRL_DRIVE12, HW_PINCTRL_DRIVE13 and HW_PINCTRL_DRIVE14 control the drive
strength and the voltage selection for the DDR pins.
The reset values of the voltage selection pins are '1', which is marked as
From: Fabio Estevam
Registers HW_PINCTRL_DRIVE9, HW_PINCTRL_DRIVE10, HW_PINCTRL_DRIVE11,
HW_PINCTRL_DRIVE12, HW_PINCTRL_DRIVE13 and HW_PINCTRL_DRIVE14 control the drive
strength and the voltage selection for the DDR pins.
The reset values of the voltage selection pins are '1', which is marked as
From: Fabio Estevam
Currently when accessing an element of mxs_pinctrl_regs structure we do:
&pinctrl_regs->hw_pinctrl_emi_ds_ctrl_set
The 'hw_pinctrl' prefix is a redundant information as we already know that we
are
accessing a pinctrl register.
Signed-off-by: Fabio Estevam
---
arch/arm/c
From: Fabio Estevam
Provide a mxs_pinctrl_regs structure for mx23.
Signed-off-by: Fabio Estevam
---
arch/arm/include/asm/arch-mxs/regs-pinctrl.h | 68 ++
1 file changed, 68 insertions(+)
diff --git a/arch/arm/include/asm/arch-mxs/regs-pinctrl.h
b/arch/arm/include/as
Prior to this series running 'memtester' utility in Linux on a mx23evk
always resulted in many errors during stress testing, if the kernel is loaded
via U-boot.
Running the same test and loading the kernel via FSL bootlets resulted on
zero errors.
Adjust U-boot so that it can also pass the 'memt
On Fri, Apr 26, 2013 at 06:10:15AM -0700, Simon Glass wrote:
> Hi Tom,
>
> On Mon, Apr 22, 2013 at 9:08 AM, Simon Glass wrote:
> > Hi Tom,
> >
> > On Mon, Apr 22, 2013 at 8:18 AM, Tom Rini wrote:
> >> On Sat, Apr 20, 2013 at 11:42:35AM -0700, Simon Glass wrote:
> >>
> >>> This series adds gener
Unifies the openrisc boards linker scripts into a common one.
Signed-off-by: Stefan Kristiansson
---
arch/openrisc/config.mk | 2 ++
{board/openrisc/openrisc-generic => arch/openrisc/cpu}/u-boot.lds | 0
2 files changed, 2 insertions(+)
rename {board/op
Since there are two memory areas defined, vectors and ram,
the linker will error when neither of them are specified for a
section.
Signed-off-by: Stefan Kristiansson
---
board/openrisc/openrisc-generic/u-boot.lds | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/openrisc/
This set of patches does:
Fix a bug in the openrisc-generic u-boot.lds linker script
that would cause an error due to that no memory region was
specified for u_boot_lists.
And then move the above mentioned file into arch/openrisc/cpu/
to unify the linker script for all openrisc boards (we only ha
Dear Kuo-Jung Su,
> 2013/4/30 Marek Vasut :
> > Dear Kuo-Jung Su,
> >
> >> 2013/4/26 Marek Vasut :
> >> > Dear Kuo-Jung Su,
> >> >
> >> >> From: Kuo-Jung Su
> >> >>
> >> >> This patch add supports to both Faraday FUSBH200 and FOTG210,
> >> >> these controllers slightly differ from standard EHC
Dear Tom Rini,
> On Wed, May 01, 2013 at 09:16:45AM -0700, Tom Warren wrote:
> > Tom,
> >
> > On Tue, Apr 30, 2013 at 10:20 AM, Tom Rini wrote:
> > > On Tue, Apr 30, 2013 at 09:21:18AM -0700, Tom Warren wrote:
> > > > Marek,
> > > >
> > > > > -Original Message-
> > > > > From: Marek Vas
Hello Heiko,
On 29 April 2013 21:14, Heiko Schocher wrote:
> Hello Naveen,
>
> On 26.04.2013 05:08, Naveen Krishna Ch wrote:
>> On 14 April 2013 22:48, Heiko Schocher wrote:
>>> Hello Naveen Krishna,
>>>
>>>
>>> On 13.04.2013 06:42, Naveen Krishna Ch wrote:
On 6 April 2013 07:07, Navee
On Wed, May 01, 2013 at 09:16:45AM -0700, Tom Warren wrote:
> Tom,
>
>
> On Tue, Apr 30, 2013 at 10:20 AM, Tom Rini wrote:
>
> > On Tue, Apr 30, 2013 at 09:21:18AM -0700, Tom Warren wrote:
> >
> > > Marek,
> > >
> > > > -Original Message-
> > > > From: Marek Vasut [mailto:ma...@denx.de]
Tom,
On Tue, Apr 30, 2013 at 10:20 AM, Tom Rini wrote:
> On Tue, Apr 30, 2013 at 09:21:18AM -0700, Tom Warren wrote:
>
> > Marek,
> >
> > > -Original Message-
> > > From: Marek Vasut [mailto:ma...@denx.de]
> > > Sent: Monday, April 29, 2013 4:47 PM
> > > To: Jim Lin
> > > Cc: u-boot@lis
On 05/01/2013 05:14 PM, Tom Rini wrote:
> On Wed, May 01, 2013 at 10:59:16AM +0200, Michal Simek wrote:
>
>> Fpga code is pretty old and none has tried to clean it up.
>> My attempt is related to new code I want to push to mainline
>> which is add support for checking bitstream and if bitstream
>>
On 05/01/2013 05:03 PM, Tom Rini wrote:
> On Wed, May 01, 2013 at 10:59:20AM +0200, Michal Simek wrote:
>
>> In bitstream decoding you can directly check device
>> which you want to load and in fpga.c are fpga_validate
>> and fpga_dev_info functions which should be used for it.
>>
>> Signed-off-by
On Wed, May 01, 2013 at 10:59:16AM +0200, Michal Simek wrote:
> Fpga code is pretty old and none has tried to clean it up.
> My attempt is related to new code I want to push to mainline
> which is add support for checking bitstream and if bitstream
> is valid for the selected device.
> For this I
On Wed, May 01, 2013 at 10:59:20AM +0200, Michal Simek wrote:
> In bitstream decoding you can directly check device
> which you want to load and in fpga.c are fpga_validate
> and fpga_dev_info functions which should be used for it.
>
> Signed-off-by: Michal Simek
[snip]
> +++ b/drivers/fpga/fpga
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/01/2013 03:45 AM, Michal Simek wrote:
> On 04/30/2013 05:44 PM, Tom Rini wrote:
>> On Tue, Apr 30, 2013 at 11:26:44AM +0200, Michal Simek wrote:
>>
>>> Hi Tom,
>>>
>>> please pull these microblaze changes to your tree. 2 of that
>>> patches was
On Tue, Apr 30, 2013 at 01:54:41PM -0700, Paul B. Henson wrote:
> On 4/29/2013 1:57 AM, Sascha Silbe wrote:
> >>MX28EVK U-Boot > ubifsmount recovery
> >>
> >>UBIFS error (pid 0): ubifs_get_sb: cannot open "recovery", error -22
> >>UBIFS error (pid 0): ubifs_mount: Error reading superblock on volum
From: Egbert Eich
The 512 byte block size was hard coded in the ext4 file systems.
Large harddisks today support bigger block sizes typically 4096
bytes.
This patch removes this limitation.
Signed-off-by: Egbert Eich
---
Changes for v2:
Microblaze uses gpio which is connected to the system reset.
Currently gpio subsystem wasn't used for it.
Add gpio driver and change Microblaze reset logic to be done
via gpio subsystem.
There are various configurations which Microblaze can have
that's why gpio_alloc/gpio_alloc_dual(for dual chan
There is no reason to include net.h header in fpga code.
Signed-off-by: Michal Simek
---
Changes in v2: None
common/cmd_fpga.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/common/cmd_fpga.c b/common/cmd_fpga.c
index aa14ceb..5e1d037 100644
--- a/common/cmd_fpga.c
+++ b/common/cmd_fpga.
Devcfg device requires to load bitstream in binary format.
But u-boot also has an option for loading bitstream in bit
format. Let's handle both cases by zynqpl driver.
Also add suport for loading partial bitstreams.
The first driver version was done by:
Joe Hershberger
Signed-off-by: Michal Sime
In bitstream decoding you can directly check device
which you want to load and in fpga.c are fpga_validate
and fpga_dev_info functions which should be used for it.
Signed-off-by: Michal Simek
---
Changes in v2: None
common/cmd_fpga.c | 94 -
Ensure that wrong bitstream won't be loaded
to current device.
Signed-off-by: Michal Simek
---
Changes in v2:
- New patch in this series
drivers/fpga/fpga.c | 20
drivers/fpga/xilinx.c | 2 ++
include/xilinx.h | 1 +
include/zynqpl.h | 8
4 files ch
No functional changes.
Signed-off-by: Michal Simek
---
Changes in v2: None
I had to shorten some debug messages and divide them
to two parts to pass checkpatch.
---
common/cmd_fpga.c | 213 +++---
1 file changed, 107 insertions(+), 106 deletions(-
CONFIG_FPGA in past was a bitfield where bits
were use for vendor identification.
This fix should be the part of this commit:
"Improve configuration of FPGA subsystem"
(sha1: 0133502e39ff89b67c26cb4015e0e7e8d9571184)
Signed-off-by: Michal Simek
---
Changes in v2:
- Fix grammer in the commit mess
No functional changes.
Signed-off-by: Michal Simek
---
Changes in v2:
- Fix compilation warnings
drivers/fpga/fpga.c | 216
1 file changed, 98 insertions(+), 118 deletions(-)
diff --git a/drivers/fpga/fpga.c b/drivers/fpga/fpga.c
index 26d24
Fpga code is pretty old and none has tried to clean it up.
My attempt is related to new code I want to push to mainline
which is add support for checking bitstream and if bitstream
is valid for the selected device.
For this I need to do cleanup code and move code
from cmd_fpga.c to fpga.c in driver
On 30/04/2013 23:15, Anatolij Gustschin wrote:
> Many boot image configuration files refer to the
> appropriate documentation file, but these references
> contain typos in the directory and file name. Fix
> them. Also fix reference to doc/README.SPL file.
>
> Signed-off-by: Anatolij Gustschin
> C
On 04/30/2013 04:50 PM, Tom Rini wrote:
> On Tue, Apr 30, 2013 at 11:49:33AM +0200, Michal Simek wrote:
>
>> Hi Tom and Albert,
>>
>> please pull this patchset related to arm zynq to your tree.
>> I haven't got any ACK for gem and platform changes but the whole patchset
>> was reviewed by Tom.
>>
On 04/30/2013 05:44 PM, Tom Rini wrote:
> On Tue, Apr 30, 2013 at 11:26:44AM +0200, Michal Simek wrote:
>
>> Hi Tom,
>>
>> please pull these microblaze changes to your tree.
>> 2 of that patches was reviewed by you.
>>
>> Thanks,
>> Michal
>>
>> The following changes since commit d10f68ae47b67acab
66 matches
Mail list logo
