* 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
* [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: 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
* 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: [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: [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] 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: 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: 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: 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
* [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
* [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 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 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 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
* 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] 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
* 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
* 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
* [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
* [PATCH] MIPS: drop redundant start_barebox() declaration
From: Antony Pavlov @ 2016-11-07 9:02 UTC (permalink / raw)
To: barebox
The start_barebox() function is defined in the <common.h> header file.
Signed-off-by: Antony Pavlov <antonynpavlov@gmail.com>
---
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
_______________________________________________
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: Alex Vazquez @ 2016-11-07 8:25 UTC (permalink / raw)
To: Sascha Hauer; +Cc: barebox
In-Reply-To: <20161107074924.blkryleb2eb5bkhy@pengutronix.de>
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
>>
>> Do I have to configure something more in Barebox?
>
> Which version are you using. Is it something older?
>
>> Thanks!
>> Regards!
>> P.D
>> I have enabled CONFIG_ARM_APPENDED_DTB and I create the new zimage with
>> (cat zImage <filename>.dtb > zImage_w_dtb )
>> P.D.2.
>> I have a little problem and i can't send email to list.
>>
>> Delivery to the following recipient failed permanently:
>> [6]barebox@lists.infradead.org
>> Technical details of permanent failure:
>> Google tried to deliver your message, but it was rejected by the server
>> for the recipient domain [7]lists.infradead.org by
>> [8]bombadil.infradead.org. [2001:1868:205::9].
>> The error that the other server returned was:
>> 550-Mailing lists do not accept HTML mail. See
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> 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] mtd: spi-nor: add MX25U2033E
From: Sascha Hauer @ 2016-11-07 7:58 UTC (permalink / raw)
To: Alexander Kurz; +Cc: barebox
In-Reply-To: <1478197480-27488-1-git-send-email-akurz@blala.de>
On Thu, Nov 03, 2016 at 07:24:40PM +0100, Alexander Kurz wrote:
> This chip can be found in 4th generation Kindle devices
>
> Signed-off-by: Alexander Kurz <akurz@blala.de>
> ---
> drivers/mtd/spi-nor/spi-nor.c | 1 +
> 1 file changed, 1 insertion(+)
Applied, thanks
Sascha
>
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index 748b328..45be586 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -526,6 +526,7 @@ static const struct spi_device_id spi_nor_ids[] = {
> { "mx25l3205d", INFO(0xc22016, 0, 64 * 1024, 64, 0) },
> { "mx25l3255e", INFO(0xc29e16, 0, 64 * 1024, 64, SECT_4K) },
> { "mx25l6405d", INFO(0xc22017, 0, 64 * 1024, 128, 0) },
> + { "mx25u2033e", INFO(0xc22532, 0, 64 * 1024, 4, SECT_4K) },
> { "mx25u4035", INFO(0xc22533, 0, 64 * 1024, 8, SECT_4K) },
> { "mx25u8035", INFO(0xc22534, 0, 64 * 1024, 16, SECT_4K) },
> { "mx25u6435f", INFO(0xc22537, 0, 64 * 1024, 128, SECT_4K) },
> --
> 2.1.4
>
>
> _______________________________________________
> 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: [PATCH] scripts imx-image: add DCD NOP command support
From: Sascha Hauer @ 2016-11-07 7:56 UTC (permalink / raw)
To: Alexander Kurz; +Cc: barebox
In-Reply-To: <1478197957-27579-1-git-send-email-akurz@blala.de>
Hi Alexander,
On Thu, Nov 03, 2016 at 07:32:37PM +0100, Alexander Kurz wrote:
> The DCD NOP command is available for all flash header v2 devices (i.MX28,
> 50, 53, 6 and 7).
>
> Signed-off-by: Alexander Kurz <akurz@blala.de>
> ---
> scripts/imx/README | 1 +
> scripts/imx/imx-image.c | 28 ++++++++++++++++++++++++++++
> scripts/imx/imx.c | 11 +++++++++++
> scripts/imx/imx.h | 1 +
> 4 files changed, 41 insertions(+)
Applied, but ... out of curiosity, what do we need this for?
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] mfd: mc13892: more descriptive charger register defines
From: Sascha Hauer @ 2016-11-07 7:54 UTC (permalink / raw)
To: Alexander Kurz; +Cc: barebox
In-Reply-To: <1478251146-32717-1-git-send-email-akurz@blala.de>
On Fri, Nov 04, 2016 at 10:19:06AM +0100, Alexander Kurz wrote:
> Make access to the mc13892 charger parameter voltage, current and max power
> dissipation readable in terms of millivolts, milliamps and milliwatts.
>
> Signed-off-by: Alexander Kurz <akurz@blala.de>
Applied, thanks
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
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