* 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
* Re: Fwd: boot kernel with append device tree
From: Sascha Hauer @ 2016-11-07 7:49 UTC (permalink / raw)
To: Alex Vazquez; +Cc: barebox
In-Reply-To: <CAOTEMUQt95XDorid8sj9FHkpCpUJYnqNeRbBU+33aLYz2oM+gw@mail.gmail.com>
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: Configure RAM size on iMX53 board
From: Sascha Hauer @ 2016-11-07 7:43 UTC (permalink / raw)
To: Jose Luis Zabalza; +Cc: barebox
In-Reply-To: <CAKZffXHVZ9tvhcgVz=fWciYQr98wrZjZbxiL4QQJEP8DzGuz7Q@mail.gmail.com>
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 |
_______________________________________________
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-05 6:39 UTC (permalink / raw)
To: barebox
In-Reply-To: <20161104071821.jqrhtfmgz3432527@pengutronix.de>
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);
}
=========================================
==========<cut board.c>==================
#include <common.h>
#include <environment.h>
#include <fcntl.h>
#include <platform_data/eth-fec.h>
#include <fs.h>
#include <init.h>
#include <nand.h>
#include <net.h>
#include <partition.h>
#include <linux/sizes.h>
#include <gpio.h>
#include <mci.h>
#include <generated/mach-types.h>
#include <mach/imx53-regs.h>
#include <mach/iomux-mx53.h>
#include <mach/devices-imx53.h>
#include <mach/generic.h>
#include <mach/imx-nand.h>
#include <mach/iim.h>
#include <mach/imx5.h>
#include <mach/esdctl.h>
#include <asm/armlinux.h>
#include <io.h>
#include <asm/mmu.h>
........ other device init functions ......
static int myboard_init(void)
{
imx_esdctl_disable();
arm_add_mem_device("ram0", MX53_CSD0_BASE_ADDR, SZ_512M);
return 0;
}
core_initcall(myboard_init);
========================================
Thanks in advanced.
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* [PATCH] mfd: mc13892: more descriptive charger register defines
From: Alexander Kurz @ 2016-11-04 9:19 UTC (permalink / raw)
To: barebox; +Cc: Alexander Kurz
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>
---
arch/arm/boards/efika-mx-smartbook/board.c | 4 +--
include/mfd/mc13892.h | 40 +++++++++++++++++++++++-------
2 files changed, 32 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boards/efika-mx-smartbook/board.c b/arch/arm/boards/efika-mx-smartbook/board.c
index d7c11dc..d7c5681 100644
--- a/arch/arm/boards/efika-mx-smartbook/board.c
+++ b/arch/arm/boards/efika-mx-smartbook/board.c
@@ -74,9 +74,7 @@ static void efikamx_power_init(struct mc13xxx *mc)
/* Externally powered */
mc13xxx_reg_read(mc, MC13892_REG_CHARGE, &val);
- val |= MC13782_CHARGE_ICHRG0 | MC13782_CHARGE_ICHRG1 |
- MC13782_CHARGE_ICHRG2 | MC13782_CHARGE_ICHRG3 |
- MC13782_CHARGE_CHGAUTOB;
+ val |= MC13782_CHARGE_ICHRG_FULL | MC13782_CHARGE_CHGAUTOB;
mc13xxx_reg_write(mc, MC13892_REG_CHARGE, val);
/* power up the system first */
diff --git a/include/mfd/mc13892.h b/include/mfd/mc13892.h
index c92a462..8b52239 100644
--- a/include/mfd/mc13892.h
+++ b/include/mfd/mc13892.h
@@ -29,21 +29,43 @@
/* REG_CHARGE */
-#define MC13782_CHARGE_VCHRG0 (1 << 0)
-#define MC13782_CHARGE_VCHRG1 (1 << 1)
-#define MC13782_CHARGE_VCHRG2 (1 << 2)
-#define MC13782_CHARGE_ICHRG0 (1 << 3)
-#define MC13782_CHARGE_ICHRG1 (1 << 4)
-#define MC13782_CHARGE_ICHRG2 (1 << 5)
-#define MC13782_CHARGE_ICHRG3 (1 << 6)
+#define MC13782_CHARGE_VCHRG_3800 (0 << 0)
+#define MC13782_CHARGE_VCHRG_4100 (1 << 0)
+#define MC13782_CHARGE_VCHRG_4150 (2 << 0)
+#define MC13782_CHARGE_VCHRG_4200 (3 << 0)
+#define MC13782_CHARGE_VCHRG_4250 (4 << 0)
+#define MC13782_CHARGE_VCHRG_4300 (5 << 0)
+#define MC13782_CHARGE_VCHRG_4375 (6 << 0)
+#define MC13782_CHARGE_VCHRG_4450 (7 << 0)
+#define MC13782_CHARGE_VCHRG_MASK (7 << 0)
+#define MC13782_CHARGE_ICHRG_0 (0 << 3)
+#define MC13782_CHARGE_ICHRG_80 (1 << 3)
+#define MC13782_CHARGE_ICHRG_240 (2 << 3)
+#define MC13782_CHARGE_ICHRG_320 (3 << 3)
+#define MC13782_CHARGE_ICHRG_400 (4 << 3)
+#define MC13782_CHARGE_ICHRG_480 (5 << 3)
+#define MC13782_CHARGE_ICHRG_560 (6 << 3)
+#define MC13782_CHARGE_ICHRG_640 (7 << 3)
+#define MC13782_CHARGE_ICHRG_720 (8 << 3)
+#define MC13782_CHARGE_ICHRG_800 (9 << 3)
+#define MC13782_CHARGE_ICHRG_880 (10 << 3)
+#define MC13782_CHARGE_ICHRG_960 (11 << 3)
+#define MC13782_CHARGE_ICHRG_1040 (12 << 3)
+#define MC13782_CHARGE_ICHRG_1200 (13 << 3)
+#define MC13782_CHARGE_ICHRG_1600 (14 << 3)
+#define MC13782_CHARGE_ICHRG_FULL (15 << 3)
+#define MC13782_CHARGE_ICHRG_MASK (15 << 3)
#define MC13782_CHARGE_TREN (1 << 7)
#define MC13782_CHARGE_ACKLPB (1 << 8)
#define MC13782_CHARGE_THCHKB (1 << 9)
#define MC13782_CHARGE_FETOVRD (1 << 10)
#define MC13782_CHARGE_FETCTRL (1 << 11)
#define MC13782_CHARGE_RVRSMODE (1 << 13)
-#define MC13782_CHARGE_PLIM0 (1 << 15)
-#define MC13782_CHARGE_PLIM1 (1 << 16)
+#define MC13782_CHARGE_PLIM_600 (0 << 15)
+#define MC13782_CHARGE_PLIM_800 (1 << 15)
+#define MC13782_CHARGE_PLIM_1000 (2 << 15)
+#define MC13782_CHARGE_PLIM_1200 (3 << 15)
+#define MC13782_CHARGE_PLIM_MASK (3 << 15)
#define MC13782_CHARGE_PLIMDIS (1 << 17)
#define MC13782_CHARGE_CHRGLEDEN (1 << 18)
#define MC13782_CHARGE_CHGTMRRST (1 << 19)
--
2.1.4
_______________________________________________
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-04 7:18 UTC (permalink / raw)
To: Jose Luis Zabalza; +Cc: barebox
In-Reply-To: <CAKZffXFSfTJJiwj2ZOB7nT-DWZ7_AqyysZkavNM++c4LSp6tZg@mail.gmail.com>
Hi,
On Thu, Nov 03, 2016 at 09:30:03PM +0100, Jose Luis Zabalza wrote:
> Hello everybody
>
> I have two iMX53 custom boards. They are the same board but 512MB vs
> 1GB RAM version. Both boards are working with the same Uboot binary
> but I would like use Barebox.
>
> I have to be able to run Barebox on 1GB version but the same Barebox
> binary don't work on 512MB version.
>
> I use imx-usb-loader to put Barebox on the board. On 1GB version
> Barebox are working OK and load Linux kernel successfully. On 512MB
> Barebox are loaded successfully but don't work. lsusb tell me the
> board is working on Serial Download mode yet. No message is printed on
> the console.
>
> Do I have to set Barebox for work with different RAM size?
Just like Andrey already said, barebox detects the RAM size by reading
back the values from the SDRAM controller to determine its memory
layout, so the configured values must be correct. In your case they can
only be correct for the 1GB version.
What you can do in this case is:
- in your boards lowlevel.c detect your actual RAM size by testing for
mirrors in the SDRAM Address space.
- Instead of imx53_barebox_entry() call barebox_arm_entry() with the
actual RAM size.
This should already bring you through the lowlevel setup succesfully.
Then in your board file add this:
#include <mach/esdctl.h>
static int myboard_init(void)
{
imx_esdctl_disable();
arm_add_mem_device("ram0", MX53_CSD0_BASE_ADDR, size);
return 0;
}
core_initcall(myboard_init);
Note you can't use a variable to safe the calculated SDRAM size from
lowlevel.c to your board file. It's probably best to do the same test
again.
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