* [PATCH] command.h: drop unused Struct_Section attribute
From: Antony Pavlov @ 2016-11-07 9:04 UTC (permalink / raw)
To: barebox
Signed-off-by: Antony Pavlov <antonynpavlov@gmail.com>
---
include/command.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/command.h b/include/command.h
index 2e72780..43ee454 100644
--- a/include/command.h
+++ b/include/command.h
@@ -89,8 +89,6 @@ int run_command(const char *cmd);
#endif /* __ASSEMBLY__ */
-#define Struct_Section __attribute__ ((unused,section (".barebox_cmd")))
-
#define BAREBOX_CMD_START(_name) \
extern const struct command __barebox_cmd_##_name; \
const struct command __barebox_cmd_##_name \
--
2.9.3
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply related
* Re: Fwd: boot kernel with append device tree
From: Sascha Hauer @ 2016-11-07 9:48 UTC (permalink / raw)
To: Alex Vazquez; +Cc: barebox
In-Reply-To: <CAOTEMUR=cw8C7K6SwUtUs1PjJB2f8OCBMsmPd1Pe_gwGWJpGfA@mail.gmail.com>
On Mon, Nov 07, 2016 at 09:25:41AM +0100, Alex Vazquez wrote:
> Hi Sasha!
>
> > Which version are you using. Is it something older?
>
> I am using barebox-2016.03.0
>
>
> Regards!
>
> 2016-11-07 8:49 GMT+01:00 Sascha Hauer <s.hauer@pengutronix.de>:
> > Hi Alex,
> >
> > Added the list to Cc
> >
> > Please configure your mailer to send plain text, then the server won't
> > reject your mails.
> >
> > On Fri, Nov 04, 2016 at 01:10:30PM +0100, Alex Vazquez wrote:
> >> Hi, all!
> >> I have create a zImage with the device tree appended.
> >> I have removed oftree_loc in the configuration file.
> >> My problem is when I try to launch the kernel, it indicates that it has
> >> the device tree added but fails to boot.
> >>
> >> barebox:/# boot
> >> booting kernel from /dev/[1]nand0.kernel.bb
> >> Loading ARM Linux zImage '/dev/[2]nand0.kernel.bb'
> >> zImage: concatenated oftree detected
> >> commandline: console=ttyS0,115200 rw ip=none ...
> >> arch_number: 0
> >>
> >> If I don't removed oftree_loc in the configuration file. Load oftree
> >> (nand) and boot fine.
> >>
> >> barebox:/# boot
> >> booting kernel from /dev/[3]nand0.kernel.bb
> >> Loading ARM Linux zImage '/dev/[4]nand0.kernel.bb'
> >> zImage: concatenated oftree detected
> >> Loading devicetree from '/dev/[5]nand0.oftree.bb'
> >> commandline: console=ttyS0,115200 rw ip=none ...
> >> Booting Linux on physical CPU 0x0
Is CONFIG_OFTREE enabled in your build?
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* Re: Fwd: boot kernel with append device tree
From: Alex Vazquez @ 2016-11-07 11:01 UTC (permalink / raw)
To: Sascha Hauer; +Cc: barebox
In-Reply-To: <20161107094802.bhy2wowbri7q3sra@pengutronix.de>
> Is CONFIG_OFTREE enabled in your build?
Yes.
2016-11-07 10:48 GMT+01:00 Sascha Hauer <s.hauer@pengutronix.de>:
> On Mon, Nov 07, 2016 at 09:25:41AM +0100, Alex Vazquez wrote:
>> Hi Sasha!
>>
>> > Which version are you using. Is it something older?
>>
>> I am using barebox-2016.03.0
>>
>>
>> Regards!
>>
>> 2016-11-07 8:49 GMT+01:00 Sascha Hauer <s.hauer@pengutronix.de>:
>> > Hi Alex,
>> >
>> > Added the list to Cc
>> >
>> > Please configure your mailer to send plain text, then the server won't
>> > reject your mails.
>> >
>> > On Fri, Nov 04, 2016 at 01:10:30PM +0100, Alex Vazquez wrote:
>> >> Hi, all!
>> >> I have create a zImage with the device tree appended.
>> >> I have removed oftree_loc in the configuration file.
>> >> My problem is when I try to launch the kernel, it indicates that it has
>> >> the device tree added but fails to boot.
>> >>
>> >> barebox:/# boot
>> >> booting kernel from /dev/[1]nand0.kernel.bb
>> >> Loading ARM Linux zImage '/dev/[2]nand0.kernel.bb'
>> >> zImage: concatenated oftree detected
>> >> commandline: console=ttyS0,115200 rw ip=none ...
>> >> arch_number: 0
>> >>
>> >> If I don't removed oftree_loc in the configuration file. Load oftree
>> >> (nand) and boot fine.
>> >>
>> >> barebox:/# boot
>> >> booting kernel from /dev/[3]nand0.kernel.bb
>> >> Loading ARM Linux zImage '/dev/[4]nand0.kernel.bb'
>> >> zImage: concatenated oftree detected
>> >> Loading devicetree from '/dev/[5]nand0.oftree.bb'
>> >> commandline: console=ttyS0,115200 rw ip=none ...
>> >> Booting Linux on physical CPU 0x0
>
>
> Is CONFIG_OFTREE enabled in your build?
>
> Sascha
>
>
> --
> Pengutronix e.K. | |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* [PATCH] commands: spi: fix chip select validation
From: Stefan Lengfeld @ 2016-11-07 15:10 UTC (permalink / raw)
To: barebox
The chip selects are numbered 0..(max chip selects - 1). Chip select
with number <max chip selects> is invalid. Fix the check for that. Using
the out of bound chip select may hang your board.
Signed-off-by: Stefan Lengfeld <s.lengfeld@phytec.de>
---
commands/spi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/commands/spi.c b/commands/spi.c
index 21db9ae..6603b34 100644
--- a/commands/spi.c
+++ b/commands/spi.c
@@ -68,8 +68,8 @@ static int do_spi(int argc, char *argv[])
return -ENODEV;
}
- if (spi.chip_select > spi.master->num_chipselect) {
- printf("spi chip select (%d)> master num chipselect (%d)\n",
+ if (spi.chip_select >= spi.master->num_chipselect) {
+ printf("spi chip select (%d) >= master num chipselect (%d)\n",
spi.chip_select, spi.master->num_chipselect);
return -EINVAL;
}
--
1.9.1
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply related
* Designware MAC reset timeout after Linux reboot
From: Ian Abbott @ 2016-11-07 17:56 UTC (permalink / raw)
To: barebox
Hi everyone,
I'm using barebox 2016.10.0 with some custom BSP patches for my Cyclone
V socfpga based board. I've noticed that after issuing a reboot in
Linux, followed by an 'ifup eth0' command in barebox, I get a "eth0: MAC
reset timeout" error, which causes dwc_ether_init() to bail out early.
My Linux kernel is Linux 4.1.17, plus LTSI-4.1.17 patches, plus Altera
patches from linux-socfpga kernel branch socfpga-4.1.22-ltsi, in that
order (git rebase is a wonderful thing!).
Socfpga has two Ethernet MAC controllers. Like several other Cyclone V
boards, my board's device tree disables the first one (&gmac0) and
aliases ethernet0 to the second one (&gmac1).
I don't need the ethernet to work to boot Linux, and Linux manages to
reinitialize the ethernet okay, so it's more of a inconvenience to me
than a show-stopper - I just need to power-cycle the board if I want
ethernet access in barebox.
I am aware of Trent Piepho's patch (commit
f0ae0c33f52ced89da080673ca89a3c5f2ea70e6) which brings the PHY out of
power-down mode before resetting the MAC DMA controller. In fact, the
PHY doesn't seem to be in power-down mode in my case, as the value read
from the MII_BMCR in phy_resume() is 0x1140 (BMCR_ANENABLE |
BMCR_FULLDPLX | BMCR_SPEED1000).
There must be something else stopping the software reset of the MAC
completing successfully, but I'm not sure what. The Cyclone V Hard
Processor System Technical Reference Manual says this about the MAC DMA
software reset bit:
| Note: * The Software reset system is driven only by this bit. *
| The reset operation is completed only when all resets in all
| active clock domains are de-asserted. Therefore, it is
| essential that all the PHY inputs clocks (applicable for the
| selected PHY interface) are present for the software reset
| completion.
Perhaps the timeout isn't waiting long enough. If I interrupt the 'ifup
eth0' command and display the approriate 'Bus_Mode' register
(0xff703000) with the 'md' command, the DMAMAC_SRST bit (bit 0) is no
longer set:
barebox@xxxx:/ md -l 0xff703000+4
ff703000: 00020100
I tried porting over a few old patches from the U-Boot version of the
driver, in particular these two patches for the mac_reset() function:
http://git.denx.de/?p=u-boot.git;a=patch;h=7091915ad7a58d7884b7353b87373847ae943e1c
http://git.denx.de/?p=u-boot.git;a=patch;h=227ad7b2b6fab024fff6f60613b0e90c9e3a6724
They didn't solve my problem, but I'll send those two patches and a
couple of others adapted from the U-Boot version of the driver to the
list separately.
Sorry for waffling on for so long. Thanks for your time, and any
helpful hints you can offer! On the whole, hacking PTXdist and barebox
is a much more pleasant experience than hacking U-Boot and Yocto!
--
-=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=-
-=( Web: http://www.mev.co.uk/ )=-
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* [PATCH 1/4] net/designware: Consecutive writes to the same register to be avoided
From: Ian Abbott @ 2016-11-07 18:16 UTC (permalink / raw)
To: barebox; +Cc: Ian Abbott
In-Reply-To: <20161107181624.4262-1-abbotti@mev.co.uk>
There are a few registers where consecutive writes to the same location
should be avoided or have a delay.
According to Synopsys, here is a list of the registers and bit(s) where
consecutive writes should be avoided or a delay is required:
DMA Registers:
Register 0 Bit 7
Register 6 All bits except for 24, 16-13, 2-1.
GMAC Registers:
Registers 0-3 All bits
Registers 6-7 All bits
Register 10 All bits
Register 11 All bits except for 5-6.
Registers 16-47 All bits
Register 48 All bits except for 18-16, 14.
Register 448 Bit 4.
Register 459 Bits 0-3.
[Original U-Boot patch by Dinh Nguyen <dinguyen@altera.com>]
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
---
drivers/net/designware.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/designware.c b/drivers/net/designware.c
index 1d662a7..21fb44e 100644
--- a/drivers/net/designware.c
+++ b/drivers/net/designware.c
@@ -248,8 +248,8 @@ static int dwc_ether_init(struct eth_device *dev)
dev->set_ethaddr(dev, priv->macaddr);
writel(FIXEDBURST | PRIORXTX_41 | BURST_16, &dma_p->busmode);
- writel(FLUSHTXFIFO | readl(&dma_p->opmode), &dma_p->opmode);
- writel(STOREFORWARD | TXSECONDFRAME, &dma_p->opmode);
+ writel(readl(&dma_p->opmode) | FLUSHTXFIFO | STOREFORWARD |
+ TXSECONDFRAME, &dma_p->opmode);
writel(FRAMEBURSTENABLE | DISABLERXOWN, &mac_p->conf);
return 0;
}
--
2.10.1
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply related
* [PATCH 0/4] net/designware: A few patches from U-Boot
From: Ian Abbott @ 2016-11-07 18:16 UTC (permalink / raw)
To: barebox
Here are a few old-ish patches for the Synopsys Designware Ethernet
driver, ported over from U-Boot.
1) net/designware: Consecutive writes to the same register to be avoided
2) net/designware: Do not select MIIPORT for RGMII interface
3) net: designware: Respect "bus mode" register contents on SW reset
4) net/designware: add explicit reset of {tx|rx}_currdescnum
drivers/net/designware.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* [PATCH 2/4] net/designware: Do not select MIIPORT for RGMII interface
From: Ian Abbott @ 2016-11-07 18:16 UTC (permalink / raw)
To: barebox; +Cc: Ian Abbott
In-Reply-To: <20161107181624.4262-1-abbotti@mev.co.uk>
Do not select MIIPORT for RGMII interface
[Original U-Boot patch by Vipin Kumar <vipin.kumar@st.com>]
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
---
drivers/net/designware.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/designware.c b/drivers/net/designware.c
index 21fb44e..85e4c58 100644
--- a/drivers/net/designware.c
+++ b/drivers/net/designware.c
@@ -129,7 +129,9 @@ static int mac_reset(struct eth_device *dev)
u64 start;
writel(DMAMAC_SRST, &dma_p->busmode);
- writel(MII_PORTSELECT, &mac_p->conf);
+
+ if (priv->interface != PHY_INTERFACE_MODE_RGMII)
+ writel(MII_PORTSELECT, &mac_p->conf);
start = get_time_ns();
while (readl(&dma_p->busmode) & DMAMAC_SRST) {
--
2.10.1
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply related
* [PATCH 3/4] net: designware: Respect "bus mode" register contents on SW reset
From: Ian Abbott @ 2016-11-07 18:16 UTC (permalink / raw)
To: barebox; +Cc: Ian Abbott
In-Reply-To: <20161107181624.4262-1-abbotti@mev.co.uk>
"bus mode" register contains lots of fields and some of them don't
expect to be written with 0 (zero). So since we're only interested in
resetting MAC (which is done with setting the least significant bit of
this register with "0") I believe it's better to modify only 1 bit of
the register.
[Original U-Boot patch by Alexey Brodkin <abrodkin@synopsys.com>]
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
---
drivers/net/designware.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/designware.c b/drivers/net/designware.c
index 85e4c58..6702d4c 100644
--- a/drivers/net/designware.c
+++ b/drivers/net/designware.c
@@ -128,7 +128,7 @@ static int mac_reset(struct eth_device *dev)
struct eth_dma_regs *dma_p = priv->dma_regs_p;
u64 start;
- writel(DMAMAC_SRST, &dma_p->busmode);
+ writel(readl(&dma_p->busmode) | DMAMAC_SRST, &dma_p->busmode);
if (priv->interface != PHY_INTERFACE_MODE_RGMII)
writel(MII_PORTSELECT, &mac_p->conf);
--
2.10.1
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply related
* [PATCH 4/4] net/designware: add explicit reset of {tx|rx}_currdescnum
From: Ian Abbott @ 2016-11-07 18:16 UTC (permalink / raw)
To: barebox; +Cc: Ian Abbott
In-Reply-To: <20161107181624.4262-1-abbotti@mev.co.uk>
Driver "init" function might be called multiple times.
On every "init" Tx/Rx buffer descriptors are initialized: "descs_init"
-> "{tx|rx}_descs_init".
In its turn those init functions set MAC's "{tx|rx}desclistaddr" to
point on the first buffer descriptor in the list.
So CPU to start operation from the first buffer descriptor as well after
every "init" we have to reset "{tx|rx}_currdescnum".
[Original U-Boot patch by Alexey Brodkin <abrodkin@synopsys.com>]
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
---
drivers/net/designware.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/designware.c b/drivers/net/designware.c
index 6702d4c..bd20a87 100644
--- a/drivers/net/designware.c
+++ b/drivers/net/designware.c
@@ -176,6 +176,7 @@ static void tx_descs_init(struct eth_device *dev)
desc_p->dmamac_next = &desc_table_p[0];
writel((ulong)&desc_table_p[0], &dma_p->txdesclistaddr);
+ priv->tx_currdescnum = 0;
}
static void rx_descs_init(struct eth_device *dev)
@@ -207,6 +208,7 @@ static void rx_descs_init(struct eth_device *dev)
desc_p->dmamac_next = &desc_table_p[0];
writel((ulong)&desc_table_p[0], &dma_p->rxdesclistaddr);
+ priv->rx_currdescnum = 0;
}
static void descs_init(struct eth_device *dev)
--
2.10.1
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply related
* Re: Configure RAM size on iMX53 board
From: Jose Luis Zabalza @ 2016-11-08 5:09 UTC (permalink / raw)
To: barebox
In-Reply-To: <20161107074346.pb4uivigwa5gbj6z@pengutronix.de>
Thanks Sascha
RAM memory reference is MT41K128M16JT-125 XIT
https://www.micron.com/parts/dram/ddr3-sdram/mt41k128m16jt-125-xit
================<cut>=========================
barebox 2016.09.0-00071-ga38b701-dirty #11 Tue Nov 8 05:56:31 CET 2016
Board: MyBoard i.MX53
detected i.MX53 revision 2.1
CS0: 0x20000000
CS1: 0x20000000
...
================<cut>=========================
2016-11-07 8:43 GMT+01:00 Sascha Hauer <s.hauer@pengutronix.de>:
> On Sat, Nov 05, 2016 at 07:39:53AM +0100, Jose Luis Zabalza wrote:
>> Thanks Sascha, but something I do wrong
>>
>> I tried set fixed size to 512M, but neither works.
>>
>> With these changes does not work or 512MB board or 1GB board.
>>
>> =========<cut lowlevel.c>===============
>>
>> #include <common.h>
>> #include <mach/imx53-regs.h>
>> #include <mach/esdctl.h>
>> #include <mach/generic.h>
>> #include <asm/barebox-arm-head.h>
>> #include <asm/barebox-arm.h>
>>
>> void __naked barebox_arm_reset_vector(void)
>> {
>> imx5_cpu_lowlevel_init();
>> arm_setup_stack(MX53_IRAM_BASE_ADDR + MX53_IRAM_SIZE - 8);
>> // imx53_barebox_entry(NULL);
>> barebox_arm_entry(MX53_CSD0_BASE_ADDR,SZ_512M,NULL);
>> }
>
> Hm, it should work like this, but maybe the memory layout is not what we
> expect. Could you apply the following and see what we get for both
> memory variants (still using imx53_barebox_entry() above so that you
> actually get to that point)?
>
> Sascha
>
> --------------------------------8<--------------------------------------
>
> From c3024dcd0e9c494adeb3f9ffbb6ec41ee4787b2d Mon Sep 17 00:00:00 2001
> From: Sascha Hauer <s.hauer@pengutronix.de>
> Date: Mon, 7 Nov 2016 08:41:01 +0100
> Subject: [PATCH] ARM: i.MX53: Add some memory debug
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
> arch/arm/mach-imx/esdctl.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm/mach-imx/esdctl.c b/arch/arm/mach-imx/esdctl.c
> index 106e648..d217495 100644
> --- a/arch/arm/mach-imx/esdctl.c
> +++ b/arch/arm/mach-imx/esdctl.c
> @@ -276,6 +276,9 @@ static void imx_esdctl_v3_add_mem(void *esdctlbase, struct imx_esdctl_data *data
>
> static void imx_esdctl_v4_add_mem(void *esdctlbase, struct imx_esdctl_data *data)
> {
> + printf("CS0: 0x%08lx\n", imx_v4_sdram_size(esdctlbase, 0));
> + printf("CS1: 0x%08lx\n", imx_v4_sdram_size(esdctlbase, 1));
> +
> add_mem(data->base0, imx_v4_sdram_size(esdctlbase, 0),
> data->base1, imx_v4_sdram_size(esdctlbase, 1));
> }
> --
> 2.10.1
>
> --
> Pengutronix e.K. | |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
--
jlz.3008 a t gmail.com
Linux Counter 172551
https://linuxcounter.net/cert/172551.png
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* Re: Fwd: boot kernel with append device tree
From: Sascha Hauer @ 2016-11-08 7:29 UTC (permalink / raw)
To: Alex Vazquez; +Cc: barebox
In-Reply-To: <CAOTEMURrS==8jFv=K4s_puQKxK+27fJ3PyMV05j5XWoyJPucPg@mail.gmail.com>
On Mon, Nov 07, 2016 at 12:01:25PM +0100, Alex Vazquez wrote:
> > Is CONFIG_OFTREE enabled in your build?
> Yes.
Ok, could you please try the following patch? Another possibility would
be to disable CONFIG_OFTREE, but it would be good if you could test the
patch anyway since the same bug is still present in current master.
Sascha
----------------------------------8<--------------------------------
From 500e5f87f9943958fa4662e29261a0abb4df24d9 Mon Sep 17 00:00:00 2001
From: Sascha Hauer <s.hauer@pengutronix.de>
Date: Tue, 8 Nov 2016 08:23:17 +0100
Subject: [PATCH] ARM: Fix appended device tree when CONFIG_OFTREE is enabled
When CONFIG_OFTREE is enabled the appended device tree is unflattened
and put into data->of_root_node, but there it is never used again.
To actually use the appended device tree put it into data->oftree
instead.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
arch/arm/lib/bootm.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index 28b4f4a..8977d08 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -244,12 +244,21 @@ static int do_bootz_linux_fdt(int fd, struct image_data *data)
}
if (IS_BUILTIN(CONFIG_OFTREE)) {
- data->of_root_node = of_unflatten_dtb(oftree);
- if (!data->of_root_node) {
+ struct device_node *root;
+
+ root = of_unflatten_dtb(oftree);
+ if (!root) {
pr_err("unable to unflatten devicetree\n");
ret = -EINVAL;
goto err_free;
}
+ data->oftree = of_get_fixed_tree(root);
+ if (!data->oftree) {
+ pr_err("Unable to get fixed tree\n");
+ ret = -EINVAL;
+ goto err_free;
+ }
+
free(oftree);
} else {
data->oftree = oftree;
--
2.10.1
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply related
* Re: Configure RAM size on iMX53 board
From: Sascha Hauer @ 2016-11-08 7:53 UTC (permalink / raw)
To: Jose Luis Zabalza; +Cc: barebox
In-Reply-To: <CAKZffXG6vuJjaQqB9QYSMeSocWZY33vFLSrWfCFf=0ATMM1fkQ@mail.gmail.com>
On Tue, Nov 08, 2016 at 06:09:52AM +0100, Jose Luis Zabalza wrote:
> Thanks Sascha
>
> RAM memory reference is MT41K128M16JT-125 XIT
> https://www.micron.com/parts/dram/ddr3-sdram/mt41k128m16jt-125-xit
>
> ================<cut>=========================
> barebox 2016.09.0-00071-ga38b701-dirty #11 Tue Nov 8 05:56:31 CET 2016
>
>
> Board: MyBoard i.MX53
> detected i.MX53 revision 2.1
> CS0: 0x20000000
> CS1: 0x20000000
> ...
>
> ================<cut>=========================
So you have 512MiB on each chip select, so I assume that on the 512MiB
board variants CS1 is not equipped. In that case you can in lowlevel.c
test if you find SDRAM on CS1 and if not, disable the chip select
completely in the SDRAM controller.
I am not sure how you can detect if there's SDRAM on CS1. I've seen
situations in which the board just hangs if you access non existent RAM
areas.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* Re: [PATCH] MIPS: drop redundant start_barebox() declaration
From: Sascha Hauer @ 2016-11-08 7:54 UTC (permalink / raw)
To: Antony Pavlov; +Cc: barebox
In-Reply-To: <20161107090210.21176-1-antonynpavlov@gmail.com>
On Mon, Nov 07, 2016 at 12:02:10PM +0300, Antony Pavlov wrote:
> The start_barebox() function is defined in the <common.h> header file.
>
> Signed-off-by: Antony Pavlov <antonynpavlov@gmail.com>
Applied, thanks
Sascha
> ---
> arch/mips/boot/main_entry.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/mips/boot/main_entry.c b/arch/mips/boot/main_entry.c
> index 015150bf..43a78c2 100644
> --- a/arch/mips/boot/main_entry.c
> +++ b/arch/mips/boot/main_entry.c
> @@ -25,7 +25,6 @@
> #include <asm/mipsregs.h>
> #include <asm/addrspace.h>
>
> -extern void start_barebox(void);
> extern void handle_reserved(void);
>
> void main_entry(void);
> --
> 2.9.3
>
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* Re: [PATCH] command.h: drop unused Struct_Section attribute
From: Sascha Hauer @ 2016-11-08 7:55 UTC (permalink / raw)
To: Antony Pavlov; +Cc: barebox
In-Reply-To: <20161107090425.22615-1-antonynpavlov@gmail.com>
On Mon, Nov 07, 2016 at 12:04:25PM +0300, Antony Pavlov wrote:
> Signed-off-by: Antony Pavlov <antonynpavlov@gmail.com>
> ---
> include/command.h | 2 --
> 1 file changed, 2 deletions(-)
Applied, thanks
Sascha
>
> diff --git a/include/command.h b/include/command.h
> index 2e72780..43ee454 100644
> --- a/include/command.h
> +++ b/include/command.h
> @@ -89,8 +89,6 @@ int run_command(const char *cmd);
>
> #endif /* __ASSEMBLY__ */
>
> -#define Struct_Section __attribute__ ((unused,section (".barebox_cmd")))
> -
> #define BAREBOX_CMD_START(_name) \
> extern const struct command __barebox_cmd_##_name; \
> const struct command __barebox_cmd_##_name \
> --
> 2.9.3
>
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* Re: [PATCH] commands: spi: fix chip select validation
From: Sascha Hauer @ 2016-11-08 7:56 UTC (permalink / raw)
To: Stefan Lengfeld; +Cc: barebox
In-Reply-To: <1478531456-11232-1-git-send-email-s.lengfeld@phytec.de>
On Mon, Nov 07, 2016 at 04:10:56PM +0100, Stefan Lengfeld wrote:
> The chip selects are numbered 0..(max chip selects - 1). Chip select
> with number <max chip selects> is invalid. Fix the check for that. Using
> the out of bound chip select may hang your board.
>
> Signed-off-by: Stefan Lengfeld <s.lengfeld@phytec.de>
> ---
> commands/spi.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Applied, thanks
Sascha
>
> diff --git a/commands/spi.c b/commands/spi.c
> index 21db9ae..6603b34 100644
> --- a/commands/spi.c
> +++ b/commands/spi.c
> @@ -68,8 +68,8 @@ static int do_spi(int argc, char *argv[])
> return -ENODEV;
> }
>
> - if (spi.chip_select > spi.master->num_chipselect) {
> - printf("spi chip select (%d)> master num chipselect (%d)\n",
> + if (spi.chip_select >= spi.master->num_chipselect) {
> + printf("spi chip select (%d) >= master num chipselect (%d)\n",
> spi.chip_select, spi.master->num_chipselect);
> return -EINVAL;
> }
> --
> 1.9.1
>
>
> _______________________________________________
> barebox mailing list
> barebox@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/barebox
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* Re: Designware MAC reset timeout after Linux reboot
From: Sascha Hauer @ 2016-11-08 8:08 UTC (permalink / raw)
To: Ian Abbott; +Cc: barebox
In-Reply-To: <29eaf37e-819f-dfdd-0403-350682193845@mev.co.uk>
Hi Ian,
On Mon, Nov 07, 2016 at 05:56:51PM +0000, Ian Abbott wrote:
> Hi everyone,
>
> I'm using barebox 2016.10.0 with some custom BSP patches for my Cyclone V
> socfpga based board. I've noticed that after issuing a reboot in Linux,
> followed by an 'ifup eth0' command in barebox, I get a "eth0: MAC reset
> timeout" error, which causes dwc_ether_init() to bail out early. My Linux
> kernel is Linux 4.1.17, plus LTSI-4.1.17 patches, plus Altera patches from
> linux-socfpga kernel branch socfpga-4.1.22-ltsi, in that order (git rebase
> is a wonderful thing!).
>
> Socfpga has two Ethernet MAC controllers. Like several other Cyclone V
> boards, my board's device tree disables the first one (&gmac0) and aliases
> ethernet0 to the second one (&gmac1).
>
> I don't need the ethernet to work to boot Linux, and Linux manages to
> reinitialize the ethernet okay, so it's more of a inconvenience to me than a
> show-stopper - I just need to power-cycle the board if I want ethernet
> access in barebox.
Have you searched in the Linux code what it does differently so that it
can successfully reset the MAC?
>
> I am aware of Trent Piepho's patch (commit
> f0ae0c33f52ced89da080673ca89a3c5f2ea70e6) which brings the PHY out of
> power-down mode before resetting the MAC DMA controller. In fact, the PHY
> doesn't seem to be in power-down mode in my case, as the value read from the
> MII_BMCR in phy_resume() is 0x1140 (BMCR_ANENABLE | BMCR_FULLDPLX |
> BMCR_SPEED1000).
>
> There must be something else stopping the software reset of the MAC
> completing successfully, but I'm not sure what. The Cyclone V Hard
> Processor System Technical Reference Manual says this about the MAC DMA
> software reset bit:
>
> | Note: * The Software reset system is driven only by this bit. *
> | The reset operation is completed only when all resets in all
> | active clock domains are de-asserted. Therefore, it is
> | essential that all the PHY inputs clocks (applicable for the
> | selected PHY interface) are present for the software reset
> | completion.
>
> Perhaps the timeout isn't waiting long enough. If I interrupt the 'ifup
> eth0' command and display the approriate 'Bus_Mode' register (0xff703000)
> with the 'md' command, the DMAMAC_SRST bit (bit 0) is no longer set:
>
> barebox@xxxx:/ md -l 0xff703000+4
> ff703000: 00020100
The timeout is 10ms, this should be way enough. The return value of
dwc_ether_init() is not checked, so the driver happily continues with
further register writes, I assume there must be something that clears
this bit afterwards, either directly or indirectly.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* Re: Designware MAC reset timeout after Linux reboot
From: Steffen Trumtrar @ 2016-11-08 8:59 UTC (permalink / raw)
To: Ian Abbott; +Cc: barebox
In-Reply-To: <29eaf37e-819f-dfdd-0403-350682193845@mev.co.uk>
Hi!
On Mon, Nov 07, 2016 at 05:56:51PM +0000, Ian Abbott wrote:
> Hi everyone,
>
> I'm using barebox 2016.10.0 with some custom BSP patches for my Cyclone V
> socfpga based board. I've noticed that after issuing a reboot in Linux,
> followed by an 'ifup eth0' command in barebox, I get a "eth0: MAC reset
> timeout" error, which causes dwc_ether_init() to bail out early. My Linux
> kernel is Linux 4.1.17, plus LTSI-4.1.17 patches, plus Altera patches from
> linux-socfpga kernel branch socfpga-4.1.22-ltsi, in that order (git rebase
> is a wonderful thing!).
>
FYI: I just tested on a Socrates board with Linux 4.9-rc3 and barebox 2016.08.0
and can not reproduce your problem. Does that always happen or just sometimes?
Regards,
Steffen
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* [PATCH] net: phy: micrel: Do not overwrite reserved bits
From: Sascha Hauer @ 2016-11-08 11:54 UTC (permalink / raw)
To: Barebox List
ksz8021_config_init() unconditionally sets the KSZPHY_OMSO_RMII_OVERRIDE
bit. This is since the initial micrel phy commit, so it's not
reproducible where this comes from and why this is done. Neither U-Boot
nor the kernel ever touch this bit and so should we. Also, instead
of doing a write only operation, read/modify/write the bit we actually
want to change.
This fixes operation on a KSZ8081MLX which is a MII only phy.
KSZPHY_OMSO_RMII_OVERRIDE is reserved here and must be written to 0.
KSZPHY_OMSO_MII_OVERRIDE is default 1 and must be written as 1.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
drivers/net/phy/micrel.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index 9a30cb7..0ca359b 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -72,8 +72,12 @@ static int kszphy_config_init(struct phy_device *phydev)
static int ksz8021_config_init(struct phy_device *phydev)
{
- const u16 val = KSZPHY_OMSO_B_CAST_OFF | KSZPHY_OMSO_RMII_OVERRIDE;
+ u16 val;
+
+ val = phy_read(phydev, MII_KSZPHY_OMSO);
+ val |= KSZPHY_OMSO_B_CAST_OFF;
phy_write(phydev, MII_KSZPHY_OMSO, val);
+
return 0;
}
--
2.10.1
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply related
* Re: Designware MAC reset timeout after Linux reboot
From: Ian Abbott @ 2016-11-08 12:13 UTC (permalink / raw)
To: Sascha Hauer; +Cc: barebox
In-Reply-To: <20161108080856.qyorpnvj4serg6ym@pengutronix.de>
On 08/11/16 08:08, Sascha Hauer wrote:
> Hi Ian,
>
> On Mon, Nov 07, 2016 at 05:56:51PM +0000, Ian Abbott wrote:
>> Hi everyone,
>>
>> I'm using barebox 2016.10.0 with some custom BSP patches for my Cyclone V
>> socfpga based board. I've noticed that after issuing a reboot in Linux,
>> followed by an 'ifup eth0' command in barebox, I get a "eth0: MAC reset
>> timeout" error, which causes dwc_ether_init() to bail out early. My Linux
>> kernel is Linux 4.1.17, plus LTSI-4.1.17 patches, plus Altera patches from
>> linux-socfpga kernel branch socfpga-4.1.22-ltsi, in that order (git rebase
>> is a wonderful thing!).
>>
>> Socfpga has two Ethernet MAC controllers. Like several other Cyclone V
>> boards, my board's device tree disables the first one (&gmac0) and aliases
>> ethernet0 to the second one (&gmac1).
>>
>> I don't need the ethernet to work to boot Linux, and Linux manages to
>> reinitialize the ethernet okay, so it's more of a inconvenience to me than a
>> show-stopper - I just need to power-cycle the board if I want ethernet
>> access in barebox.
>
> Have you searched in the Linux code what it does differently so that it
> can successfully reset the MAC?
The Linux code paths are more convoluted, including calls into the reset
manager. I found the code that resets the MAC DMA controller though -
see below....
>> I am aware of Trent Piepho's patch (commit
>> f0ae0c33f52ced89da080673ca89a3c5f2ea70e6) which brings the PHY out of
>> power-down mode before resetting the MAC DMA controller. In fact, the PHY
>> doesn't seem to be in power-down mode in my case, as the value read from the
>> MII_BMCR in phy_resume() is 0x1140 (BMCR_ANENABLE | BMCR_FULLDPLX |
>> BMCR_SPEED1000).
>>
>> There must be something else stopping the software reset of the MAC
>> completing successfully, but I'm not sure what. The Cyclone V Hard
>> Processor System Technical Reference Manual says this about the MAC DMA
>> software reset bit:
>>
>> | Note: * The Software reset system is driven only by this bit. *
>> | The reset operation is completed only when all resets in all
>> | active clock domains are de-asserted. Therefore, it is
>> | essential that all the PHY inputs clocks (applicable for the
>> | selected PHY interface) are present for the software reset
>> | completion.
>>
>> Perhaps the timeout isn't waiting long enough. If I interrupt the 'ifup
>> eth0' command and display the approriate 'Bus_Mode' register (0xff703000)
>> with the 'md' command, the DMAMAC_SRST bit (bit 0) is no longer set:
>>
>> barebox@xxxx:/ md -l 0xff703000+4
>> ff703000: 00020100
>
> The timeout is 10ms, this should be way enough. The return value of
> dwc_ether_init() is not checked, so the driver happily continues with
> further register writes, I assume there must be something that clears
> this bit afterwards, either directly or indirectly.
The bit is supposed to clear itself, but I guess something else could be
clearing it too.
The code to reset the MAC DMA controller in Linux kernel 4.1 is
dwmac1000_dma_init() in
"drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c". In Linux kernel
4.6, the function is dwmac_dma_reset() in "dwmac_lib.c". In both cases,
the code to reset the DMA controller is basically as follows:
u32 value = readl(ioaddr + DMA_BUS_MODE);
int limit;
/* DMA SW reset */
value |= DMA_BUS_MODE_SFT_RESET;
writel(value, ioaddr + DMA_BUS_MODE);
limit = 10;
while (limit--) {
if (!(readl(ioaddr + DMA_BUS_MODE) & DMA_BUS_MODE_SFT_RESET))
break;
mdelay(10);
}
if (limit < 0)
return -EBUSY;
It's interesting that it only bothers to check for reset completion
every 10 ms (timing out after 100 ms), so it must be expecting it to
take a while!
I'll experiment with the timeout on my board to see if the bit ever
clears itself.
--
-=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=-
-=( Web: http://www.mev.co.uk/ )=-
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* Re: Designware MAC reset timeout after Linux reboot
From: Ian Abbott @ 2016-11-08 12:25 UTC (permalink / raw)
To: Steffen Trumtrar; +Cc: barebox
In-Reply-To: <20161108085957.qqvl2ojnllll6hjn@pengutronix.de>
On 08/11/16 08:59, Steffen Trumtrar wrote:
> Hi!
>
> On Mon, Nov 07, 2016 at 05:56:51PM +0000, Ian Abbott wrote:
>> Hi everyone,
>>
>> I'm using barebox 2016.10.0 with some custom BSP patches for my Cyclone V
>> socfpga based board. I've noticed that after issuing a reboot in Linux,
>> followed by an 'ifup eth0' command in barebox, I get a "eth0: MAC reset
>> timeout" error, which causes dwc_ether_init() to bail out early. My Linux
>> kernel is Linux 4.1.17, plus LTSI-4.1.17 patches, plus Altera patches from
>> linux-socfpga kernel branch socfpga-4.1.22-ltsi, in that order (git rebase
>> is a wonderful thing!).
>>
>
> FYI: I just tested on a Socrates board with Linux 4.9-rc3 and barebox 2016.08.0
> and can not reproduce your problem. Does that always happen or just sometimes?
It always happens on my board. I could try reproducing it on a Socrates
board. I have a couple of Socrates version 1.2 boards and a Socrates
2.0 board, so I could try and reproduce the problem if I find time to
set it up.
My board is actually a prototype. The PHY clock was originally wired up
to completely the wrong pin on the FPGA (since it was based on an older
NiosII based design). It has been surgically altered so the PHY clock
is on a different wrong pin, but at least the new pin is clocked at the
correct frequency. This may or may not be related to my problem, but
the PHY seems to work OK before bringing up the MAC controller - miitool
shows it manages to establish a link at the physical level.
--
-=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=-
-=( Web: http://www.mev.co.uk/ )=-
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* [PATCH 1/2] of: partitions: Support new binding
From: Sascha Hauer @ 2016-11-08 13:41 UTC (permalink / raw)
To: Barebox List
The new binding recommends to put the partitions into a subnode
with compatible "fixed-partitions". Add support for this binding.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
drivers/of/partition.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/of/partition.c b/drivers/of/partition.c
index b6621f7..bdf5945 100644
--- a/drivers/of/partition.c
+++ b/drivers/of/partition.c
@@ -80,6 +80,13 @@ int of_parse_partitions(struct cdev *cdev, struct device_node *node)
return -EINVAL;
for_each_child_of_node(node, n) {
+ if (of_device_is_compatible(n, "fixed-partitions")) {
+ node = n;
+ break;
+ }
+ }
+
+ for_each_child_of_node(node, n) {
of_parse_partition(cdev, n);
}
--
2.10.1
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply related
* [PATCH 2/2] of: of_find_path: Add support for new partition binding
From: Sascha Hauer @ 2016-11-08 13:41 UTC (permalink / raw)
To: Barebox List
In-Reply-To: <20161108134149.3811-1-s.hauer@pengutronix.de>
The partitions now may be in a subnode of the actual device node.
Eventually go another step up in the hierarchy if required.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
drivers/of/of_path.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/of/of_path.c b/drivers/of/of_path.c
index 8e1931f..1f5106d 100644
--- a/drivers/of/of_path.c
+++ b/drivers/of/of_path.c
@@ -56,7 +56,12 @@ static int __of_find_path(struct device_node *node, const char *part, char **out
dev = of_find_device_by_node_path(node->full_name);
if (!dev) {
- dev = of_find_device_by_node_path(node->parent->full_name);
+ struct device_node *devnode = node->parent;
+
+ if (of_device_is_compatible(devnode, "fixed-partitions"))
+ devnode = devnode->parent;
+
+ dev = of_find_device_by_node_path(devnode->full_name);
if (!dev)
return -ENODEV;
}
--
2.10.1
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply related
* [PATCH] serial: i.MX uart: Allow DTE mode in lowlevel code
From: Sascha Hauer @ 2016-11-08 13:42 UTC (permalink / raw)
To: Barebox List
Some consoles must be configured for DTE mode. Allow to set this
in lowlevel code.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
include/serial/imx-uart.h | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/include/serial/imx-uart.h b/include/serial/imx-uart.h
index 901b26a..b40044e 100644
--- a/include/serial/imx-uart.h
+++ b/include/serial/imx-uart.h
@@ -146,6 +146,15 @@ static inline void imx_uart_setup(void __iomem *uartbase,
writel(UCR1_UARTEN, uartbase + UCR1);
}
+static inline void imx_uart_set_dte(void __iomem *uartbase)
+{
+ u32 ufcr;
+
+ ufcr = readl(uartbase + UFCR);
+ ufcr |= UFCR_DCEDTE;
+ writel(ufcr, uartbase + UFCR);
+}
+
static inline void imx50_uart_setup(void __iomem *uartbase)
{
imx_uart_setup(uartbase, 66666666);
--
2.10.1
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply related
* [PATCH] ARM: i.MX: OCOTP: Add functions to access fuses field wise
From: Sascha Hauer @ 2016-11-08 13:43 UTC (permalink / raw)
To: Barebox List
Add functions to access the OCOTP fuses field wise, similar to what has
been done for the IIM. Also add a i.MX6 fusemap header file.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
arch/arm/mach-imx/include/mach/imx6-fusemap.h | 63 ++++++++++++++++++++++++++
arch/arm/mach-imx/include/mach/ocotp.h | 20 +++++++++
arch/arm/mach-imx/ocotp.c | 65 +++++++++++++++++++++++++++
3 files changed, 148 insertions(+)
create mode 100644 arch/arm/mach-imx/include/mach/imx6-fusemap.h
create mode 100644 arch/arm/mach-imx/include/mach/ocotp.h
diff --git a/arch/arm/mach-imx/include/mach/imx6-fusemap.h b/arch/arm/mach-imx/include/mach/imx6-fusemap.h
new file mode 100644
index 0000000..5fdd904
--- /dev/null
+++ b/arch/arm/mach-imx/include/mach/imx6-fusemap.h
@@ -0,0 +1,63 @@
+#ifndef __MACH_IMX_IMX6_OCOTP_H
+#define __MACH_IMX_IMX6_OCOTP_H
+
+#include <mach/ocotp.h>
+
+#define IMX6_OCOTP_TESTER_LOCK (OCOTP_WORD(0x400) | OCOTP_BIT(0) | OCOTP_WIDTH(2))
+#define IMX6_OCOTP_BOOT_CFG_LOCK (OCOTP_WORD(0x400) | OCOTP_BIT(2) | OCOTP_WIDTH(2))
+#define IMX6_OCOTP_MEM_TRIM_LOCK (OCOTP_WORD(0x400) | OCOTP_BIT(4) | OCOTP_WIDTH(2))
+#define IMX6_OCOTP_SJC_RESP_LOCK (OCOTP_WORD(0x400) | OCOTP_BIT(6) | OCOTP_WIDTH(2))
+#define IMX6_OCOTP_MAC_ADDR_LOCK (OCOTP_WORD(0x400) | OCOTP_BIT(8) | OCOTP_WIDTH(2))
+#define IMX6_OCOTP_GP1_LOCK (OCOTP_WORD(0x400) | OCOTP_BIT(10) | OCOTP_WIDTH(2))
+#define IMX6_OCOTP_GP2_LOCK (OCOTP_WORD(0x400) | OCOTP_BIT(12) | OCOTP_WIDTH(2))
+#define IMX6_OCOTP_SRK_LOCK (OCOTP_WORD(0x400) | OCOTP_BIT(14) | OCOTP_WIDTH(1))
+#define IMX6_OCOTP_ANALOG_LOCK (OCOTP_WORD(0x400) | OCOTP_BIT(18) | OCOTP_WIDTH(2))
+#define IMX6_OCOTP_MISC_CONF_LOCK (OCOTP_WORD(0x400) | OCOTP_BIT(22) | OCOTP_WIDTH(1))
+
+/* 0 <= n <= 1 */
+#define IMX6_OCOTP_UNIQUE_ID(n) (OCOTP_WORD(0x410 + 0x10 * (n)) | OCOTP_BIT(0) | OCOTP_WIDTH(32))
+#define IMX6_OCOTP_SI_REV (OCOTP_WORD(0x430) | OCOTP_BIT(16) | OCOTP_WIDTH(4))
+#define IMX6_OCOTP_NUM_CORES (OCOTP_WORD(0x430) | OCOTP_BIT(20) | OCOTP_WIDTH(2))
+#define IMX6_OCOTP_SATA_RST_SRC (OCOTP_WORD(0x430) | OCOTP_BIT(24) | OCOTP_WIDTH(1))
+#define IMX6_OCOTP_MLB_DISABLE (OCOTP_WORD(0x430) | OCOTP_BIT(26) | OCOTP_WIDTH(1))
+#define IMX6_OCOTP_VPU_DISABLE (OCOTP_WORD(0x440) | OCOTP_BIT(15) | OCOTP_WIDTH(1))
+#define IMX6_OCOTP_SPEED_GRADING (OCOTP_WORD(0x440) | OCOTP_BIT(16) | OCOTP_WIDTH(2))
+#define IMX6_OCOTP_BOOT_CFG1 (OCOTP_WORD(0x450) | OCOTP_BIT(0) | OCOTP_WIDTH(8))
+#define IMX6_OCOTP_BOOT_CFG2 (OCOTP_WORD(0x450) | OCOTP_BIT(8) | OCOTP_WIDTH(8))
+#define IMX6_OCOTP_BOOT_CFG3 (OCOTP_WORD(0x450) | OCOTP_BIT(16) | OCOTP_WIDTH(8))
+#define IMX6_OCOTP_BOOT_CFG4 (OCOTP_WORD(0x450) | OCOTP_BIT(24) | OCOTP_WIDTH(8))
+#define IMX6_OCOTP_SEC_CONFIG (OCOTP_WORD(0x460) | OCOTP_BIT(1) | OCOTP_WIDTH(1))
+#define IMX6_OCOTP_DIR_BT_DIS (OCOTP_WORD(0x460) | OCOTP_BIT(3) | OCOTP_WIDTH(1))
+#define IMX6_OCOTP_BT_FUSE_SEL (OCOTP_WORD(0x460) | OCOTP_BIT(4) | OCOTP_WIDTH(1))
+#define IMX6_OCOTP_DDR3_CONFIG (OCOTP_WORD(0x460) | OCOTP_BIT(8) | OCOTP_WIDTH(8))
+#define IMX6_OCOTP_HDCP (OCOTP_WORD(0x460) | OCOTP_BIT(16) | OCOTP_WIDTH(1))
+#define IMX6_OCOTP_SJC_DISABLE (OCOTP_WORD(0x460) | OCOTP_BIT(20) | OCOTP_WIDTH(1))
+#define IMX6_OCOTP_WDOG_ENABLE (OCOTP_WORD(0x460) | OCOTP_BIT(21) | OCOTP_WIDTH(1))
+#define IMX6_OCOTP_JTAG_SMODE (OCOTP_WORD(0x460) | OCOTP_BIT(22) | OCOTP_WIDTH(2))
+#define IMX6_OCOTP_KTE (OCOTP_WORD(0x460) | OCOTP_BIT(26) | OCOTP_WIDTH(1))
+#define IMX6_OCOTP_JTAG_HEO (OCOTP_WORD(0x460) | OCOTP_BIT(27) | OCOTP_WIDTH(1))
+#define IMX6_OCOTP_TZASC_ENABLE (OCOTP_WORD(0x460) | OCOTP_BIT(28) | OCOTP_WIDTH(1))
+#define IMX6_OCOTP_SDMMC_HYS_EN (OCOTP_WORD(0x460) | OCOTP_BIT(29) | OCOTP_WIDTH(1))
+#define IMX6_OCOTP_eMMC_RESET_EN (OCOTP_WORD(0x460) | OCOTP_BIT(30) | OCOTP_WIDTH(1))
+#define IMX6_OCOTP_NAND_READ_CMD_CODE1 (OCOTP_WORD(0x470) | OCOTP_BIT(0) | OCOTP_WIDTH(8))
+#define IMX6_OCOTP_NAND_READ_CMD_CODE2 (OCOTP_WORD(0x470) | OCOTP_BIT(8) | OCOTP_WIDTH(8))
+#define IMX6_OCOTP_BT_LPB_POLARITY (OCOTP_WORD(0x470) | OCOTP_BIT(20) | OCOTP_WIDTH(1))
+#define IMX6_OCOTP_LPB_BOOT (OCOTP_WORD(0x470) | OCOTP_BIT(21) | OCOTP_WIDTH(2))
+#define IMX6_OCOTP_MMC_DLL_DLY (OCOTP_WORD(0x470) | OCOTP_BIT(24) | OCOTP_WIDTH(7))
+#define IMX6_OCOTP_TEMPERATURE_GRADE (OCOTP_WORD(0x480) | OCOTP_BIT(6) | OCOTP_WIDTH(2))
+#define IMX6_OCOTP_POWER_GATE_CORES (OCOTP_WORD(0x4d0) | OCOTP_BIT(31) | OCOTP_WIDTH(1))
+#define IMX6_OCOTP_USB_VID (OCOTP_WORD(0x4f0) | OCOTP_BIT(0) | OCOTP_WIDTH(16))
+#define IMX6_OCOTP_USB_PID (OCOTP_WORD(0x4f0) | OCOTP_BIT(16) | OCOTP_WIDTH(16))
+/* 0 <= n <= 7 */
+#define IMX6_OCOTP_SRK_HASH(n) (OCOTP_WORD(0x580 + 0x10 * (n)) | OCOTP_BIT(0) | OCOTP_WIDTH(32))
+#define IMX6_OCOTP_SJC_RESP_31_0 (OCOTP_WORD(0x600) | OCOTP_BIT(0) | OCOTP_WIDTH(32))
+#define IMX6_OCOTP_SJC_RESP_55_32 (OCOTP_WORD(0x610) | OCOTP_BIT(0) | OCOTP_WIDTH(24))
+#define IMX6_OCOTP_MAC_ADDR_31_0 (OCOTP_WORD(0x620) | OCOTP_BIT(0) | OCOTP_WIDTH(32))
+#define IMX6_OCOTP_MAC_ADDR_47_32 (OCOTP_WORD(0x630) | OCOTP_BIT(0) | OCOTP_WIDTH(16))
+#define IMX6_OCOTP_GP1 (OCOTP_WORD(0x660) | OCOTP_BIT(0) | OCOTP_WIDTH(32))
+#define IMX6_OCOTP_GP2 (OCOTP_WORD(0x670) | OCOTP_BIT(0) | OCOTP_WIDTH(32))
+#define IMX6_OCOTP_PAD_SETTINGS (OCOTP_WORD(0x6d0) | OCOTP_BIT(0) | OCOTP_WIDTH(6))
+#define IMX6DQ_OCOTP_TEST_PORT_DISABLE (OCOTP_WORD(0x6e0) | OCOTP_BIT(1) | OCOTP_WIDTH(1))
+#define IMX6SDL_OCOTP_FIELD_RETURN (OCOTP_WORD(0x6e0) | OCOTP_BIT(0) | OCOTP_WIDTH(1))
+
+#endif /* __MACH_IMX_IMX6_OCOTP_H */
diff --git a/arch/arm/mach-imx/include/mach/ocotp.h b/arch/arm/mach-imx/include/mach/ocotp.h
new file mode 100644
index 0000000..430bc75
--- /dev/null
+++ b/arch/arm/mach-imx/include/mach/ocotp.h
@@ -0,0 +1,20 @@
+#ifndef __MACH_IMX_OCOTP_H
+#define __MACH_IMX_OCOTP_H
+
+#define OCOTP_WORD_MASK_WIDTH 8
+#define OCOTP_WORD_MASK_SHIFT 0
+#define OCOTP_WORD(n) ((((n) - 0x400) >> 4) & ((1 << OCOTP_WORD_MASK_WIDTH) - 1))
+
+#define OCOTP_BIT_MASK_WIDTH 5
+#define OCOTP_BIT_MASK_SHIFT (OCOTP_WORD_MASK_SHIFT + OCOTP_WORD_MASK_WIDTH)
+#define OCOTP_BIT(n) (((n) & ((1 << OCOTP_BIT_MASK_WIDTH) - 1)) << OCOTP_BIT_MASK_SHIFT)
+
+#define OCOTP_WIDTH_MASK_WIDTH 5
+#define OCOTP_WIDTH_MASK_SHIFT (OCOTP_BIT_MASK_SHIFT + OCOTP_BIT_MASK_WIDTH)
+#define OCOTP_WIDTH(n) ((((n) - 1) & ((1 << OCOTP_WIDTH_MASK_WIDTH) - 1)) << OCOTP_WIDTH_MASK_SHIFT)
+
+int imx_ocotp_read_field(uint32_t field, unsigned *value);
+int imx_ocotp_write_field(uint32_t field, unsigned value);
+int imx_ocotp_permanent_write(int enable);
+
+#endif /* __MACH_IMX_OCOTP_H */
diff --git a/arch/arm/mach-imx/ocotp.c b/arch/arm/mach-imx/ocotp.c
index 17b944b..3acec7f 100644
--- a/arch/arm/mach-imx/ocotp.c
+++ b/arch/arm/mach-imx/ocotp.c
@@ -28,6 +28,7 @@
#include <clock.h>
#include <regmap.h>
#include <linux/clk.h>
+#include <mach/ocotp.h>
/*
* a single MAC address reference has the form
@@ -87,6 +88,8 @@ struct ocotp_priv {
struct regmap_config map_config;
};
+static struct ocotp_priv *imx_ocotp;
+
static int imx6_ocotp_set_timing(struct ocotp_priv *priv)
{
u32 clk_rate;
@@ -282,6 +285,66 @@ static int imx_ocotp_reg_write(void *ctx, unsigned int reg, unsigned int val)
return 0;
}
+static void imx_ocotp_field_decode(uint32_t field, unsigned *word,
+ unsigned *bit, unsigned *mask)
+{
+ unsigned width;
+
+ *word = ((field >> OCOTP_WORD_MASK_SHIFT) & ((1 << OCOTP_WORD_MASK_WIDTH) - 1)) * 4;
+ *bit = (field >> OCOTP_BIT_MASK_SHIFT) & ((1 << OCOTP_BIT_MASK_WIDTH) - 1);
+ width = ((field >> OCOTP_WIDTH_MASK_SHIFT) & ((1 << OCOTP_WIDTH_MASK_WIDTH) - 1)) + 1;
+ *mask = (1 << width) - 1;
+}
+
+int imx_ocotp_read_field(uint32_t field, unsigned *value)
+{
+ unsigned word, bit, mask, val;
+ int ret;
+
+ imx_ocotp_field_decode(field, &word, &bit, &mask);
+
+ ret = imx_ocotp_reg_read(imx_ocotp, word, &val);
+ if (ret)
+ return ret;
+
+ val >>= bit;
+ val &= mask;
+
+ dev_dbg(&imx_ocotp->dev, "%s: word: 0x%x bit: %d mask: 0x%x val: 0x%x\n",
+ __func__, word, bit, mask, val);
+
+ *value = val;
+
+ return 0;
+}
+
+int imx_ocotp_write_field(uint32_t field, unsigned value)
+{
+ unsigned word, bit, mask;
+ int ret;
+
+ imx_ocotp_field_decode(field, &word, &bit, &mask);
+
+ value &= mask;
+ value <<= bit;
+
+ ret = imx_ocotp_reg_write(imx_ocotp, word, value);
+ if (ret)
+ return ret;
+
+ dev_dbg(&imx_ocotp->dev, "%s: word: 0x%x bit: %d mask: 0x%x val: 0x%x\n",
+ __func__, word, bit, mask, value);
+
+ return 0;
+}
+
+int imx_ocotp_permanent_write(int enable)
+{
+ imx_ocotp->permanent_write_enable = enable;
+
+ return 0;
+}
+
static uint32_t inc_offset(uint32_t offset)
{
if ((offset & 0x3) == 0x3)
@@ -412,6 +475,8 @@ static int imx_ocotp_probe(struct device_d *dev)
if (ret)
return ret;
+ imx_ocotp = priv;
+
if (IS_ENABLED(CONFIG_IMX_OCOTP_WRITE)) {
dev_add_param_bool(&(priv->dev), "permanent_write_enable",
NULL, NULL, &priv->permanent_write_enable, NULL);
--
2.10.1
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox