Hi Wolfgang G. and list,
I was looking to do some basic tests on a C_CAN module inside our SOC at
u-boot
level, till the Linux OS is up and working to test basic CAN features.
I couldn't figure out if CAN framework is supported in u-boot and would
really appreciate if
someone can help me out
Hi Tom,
On Thu, Apr 25, 2013 at 11:51 AM, Simon Glass s...@chromium.org wrote:
Hi Tom,
On Tue, Apr 23, 2013 at 7:50 AM, Tom Rini tr...@ti.com wrote:
On Mon, Apr 22, 2013 at 06:44:53PM -0500, Kim Phillips wrote:
On Sat, 20 Apr 2013 16:03:20 -0700
Simon Glass s...@chromium.org wrote:
On
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
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.
Also not all
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
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
No functional changes.
Signed-off-by: Michal Simek michal.si...@xilinx.com
---
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
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 michal.si...@xilinx.com
---
Changes in v2:
- Fix
No functional changes.
Signed-off-by: Michal Simek michal.si...@xilinx.com
---
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
Ensure that wrong bitstream won't be loaded
to current device.
Signed-off-by: Michal Simek michal.si...@xilinx.com
---
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 |
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 michal.si...@xilinx.com
---
Changes in v2: None
common/cmd_fpga.c | 94
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 joe.hershber...@ni.com
There is no reason to include net.h header in fpga code.
Signed-off-by: Michal Simek michal.si...@xilinx.com
---
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
---
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
From: Egbert Eich e...@suse.com
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 e...@suse.com
---
Changes for v2:
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 volume
'recovery'
-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 reviewed by
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 michal.si...@xilinx.com
[snip]
+++
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 need
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: Michal
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
is valid
Tom,
On Tue, Apr 30, 2013 at 10:20 AM, Tom Rini tr...@ti.com 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:
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 tr...@ti.com 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:
Hello Heiko,
On 29 April 2013 21:14, Heiko Schocher h...@denx.de wrote:
Hello Naveen,
On 26.04.2013 05:08, Naveen Krishna Ch wrote:
On 14 April 2013 22:48, Heiko Schocher h...@denx.de wrote:
Hello Naveen Krishna,
On 13.04.2013 06:42, Naveen Krishna Ch wrote:
On 6 April 2013 07:07,
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 tr...@ti.com wrote:
On Tue, Apr 30, 2013 at 09:21:18AM -0700, Tom Warren wrote:
Marek,
-Original Message-
From: Marek Vasut
Dear Kuo-Jung Su,
2013/4/30 Marek Vasut ma...@denx.de:
Dear Kuo-Jung Su,
2013/4/26 Marek Vasut ma...@denx.de:
Dear Kuo-Jung Su,
From: Kuo-Jung Su dant...@faraday-tech.com
This patch add supports to both Faraday FUSBH200 and FOTG210,
these controllers slightly differ
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
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 stefan.kristians...@saunalahti.fi
---
board/openrisc/openrisc-generic/u-boot.lds | 2 +-
1 file changed, 1 insertion(+), 1
Unifies the openrisc boards linker scripts into a common one.
Signed-off-by: Stefan Kristiansson stefan.kristians...@saunalahti.fi
---
arch/openrisc/config.mk | 2 ++
{board/openrisc/openrisc-generic = arch/openrisc/cpu}/u-boot.lds | 0
2 files changed,
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 s...@chromium.org wrote:
Hi Tom,
On Mon, Apr 22, 2013 at 8:18 AM, Tom Rini tr...@ti.com wrote:
On Sat, Apr 20, 2013 at 11:42:35AM -0700, Simon Glass wrote:
This series
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
From: Fabio Estevam fabio.este...@freescale.com
Provide a mxs_pinctrl_regs structure for mx23.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
arch/arm/include/asm/arch-mxs/regs-pinctrl.h | 68 ++
1 file changed, 68 insertions(+)
diff --git
From: Fabio Estevam fabio.este...@freescale.com
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:
From: Fabio Estevam fabio.este...@freescale.com
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
From: Fabio Estevam fabio.este...@freescale.com
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
From: Fabio Estevam fabio.este...@freescale.com
Disable the internal pad keepers to match the code from FSL bootlets and provide
better stability.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
board/freescale/mx23evk/spl_boot.c |4
1 file changed, 4 insertions(+)
diff
From: Fabio Estevam fabio.este...@freescale.com
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
From: Fabio Estevam fabio.este...@freescale.com
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
From: Fabio Estevam fabio.este...@freescale.com
Disable the internal pad keepers to match the code from FSL bootlets and provide
better stability.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
board/olimex/mx23_olinuxino/spl_boot.c |4
1 file changed, 4 insertions(+)
From: Fabio Estevam fabio.este...@freescale.com
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 fabio.este...@freescale.com
---
On Wed, May 1, 2013 at 12:33 PM, Marek Vasut ma...@denx.de 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 tr...@ti.com wrote:
On Tue, Apr 30, 2013 at 09:21:18AM -0700, Tom Warren wrote:
Marek,
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 twarren.nvi...@gmail.com wrote:
On Wed, May 1, 2013 at 12:33 PM, Marek Vasut ma...@denx.de wrote:
Dear Tom Rini,
On Wed, May 01, 2013 at 09:16:45AM -0700, Tom
Dear Fabio Estevam,
From: Fabio Estevam fabio.este...@freescale.com
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
Dear Fabio Estevam,
From: Fabio Estevam fabio.este...@freescale.com
Provide a mxs_pinctrl_regs structure for mx23.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
So the pinctrl structure was always wrong on mx23? Otavio?
Best regards,
Marek Vasut
Dear Fabio Estevam,
From: Fabio Estevam fabio.este...@freescale.com
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
Dear Fabio Estevam,
From: Fabio Estevam fabio.este...@freescale.com
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
Dear Fabio Estevam,
From: Fabio Estevam fabio.este...@freescale.com
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
Dear Fabio Estevam,
From: Fabio Estevam fabio.este...@freescale.com
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
On Wed, May 1, 2013 at 8:26 PM, Marek Vasut ma...@denx.de wrote:
Dear Fabio Estevam,
From: Fabio Estevam fabio.este...@freescale.com
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
On Wed, May 1, 2013 at 8:27 PM, Marek Vasut ma...@denx.de wrote:
Dear Fabio Estevam,
From: Fabio Estevam fabio.este...@freescale.com
Provide a mxs_pinctrl_regs structure for mx23.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
So the pinctrl structure was always wrong on mx23?
On Wed, May 1, 2013 at 8:28 PM, Marek Vasut ma...@denx.de 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:29 PM, Marek Vasut ma...@denx.de 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
On Wed, May 1, 2013 at 8:28 PM, Marek Vasut ma...@denx.de 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
Dear Fabio Estevam,
On Wed, May 1, 2013 at 8:26 PM, Marek Vasut ma...@denx.de wrote:
Dear Fabio Estevam,
From: Fabio Estevam fabio.este...@freescale.com
Currently when accessing an element of mxs_pinctrl_regs structure we do:
pinctrl_regs-hw_pinctrl_emi_ds_ctrl_set
The
Dear Fabio Estevam,
On Wed, May 1, 2013 at 8:27 PM, Marek Vasut ma...@denx.de wrote:
Dear Fabio Estevam,
From: Fabio Estevam fabio.este...@freescale.com
Provide a mxs_pinctrl_regs structure for mx23.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
So the pinctrl
Dear Fabio Estevam,
On Wed, May 1, 2013 at 8:28 PM, Marek Vasut ma...@denx.de 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?
Dear Fabio Estevam,
On Wed, May 1, 2013 at 8:28 PM, Marek Vasut ma...@denx.de 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.
Dear Fabio Estevam,
On Wed, May 1, 2013 at 8:29 PM, Marek Vasut ma...@denx.de 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 Wed, May 1, 2013 at 9:15 PM, Marek Vasut ma...@denx.de 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
On Wed, May 1, 2013 at 9:13 PM, Marek Vasut ma...@denx.de 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)
{
2013/5/2 Marek Vasut ma...@denx.de:
Dear Kuo-Jung Su,
2013/4/30 Marek Vasut ma...@denx.de:
Dear Kuo-Jung Su,
2013/4/26 Marek Vasut ma...@denx.de:
Dear Kuo-Jung Su,
From: Kuo-Jung Su dant...@faraday-tech.com
This patch add supports to both Faraday FUSBH200 and FOTG210,
Dear Fabio Estevam,
On Wed, May 1, 2013 at 9:13 PM, Marek Vasut ma...@denx.de 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
On Wed, May 1, 2013 at 9:14 PM, Marek Vasut ma...@denx.de 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
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.
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]
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
From: Sonic Zhang sonic.zh...@analog.com
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
67 matches
Mail list logo
