* [U-Boot] [PATCH 1/8] fs/fs.c: read up to EOF when len would read past EOF
2015-07-01 23:04 [U-Boot] [PATCH 0/8] assortment of fixes/enhancements Marcel Ziswiler
@ 2015-07-01 23:04 ` Marcel Ziswiler
2015-07-02 5:46 ` Marek Vasut
2015-07-01 23:04 ` [U-Boot] [PATCH 2/8] net: asix: fix operation without eeprom Marcel Ziswiler
` (6 subsequent siblings)
7 siblings, 1 reply; 28+ messages in thread
From: Marcel Ziswiler @ 2015-07-01 23:04 UTC (permalink / raw)
To: u-boot
From: Max Krummenacher <max.krummenacher@toradex.com>
http://lists.denx.de/pipermail/u-boot/2012-September/134347.html
allows for reading files in chunks from the shell.
When this feature is used to read past the end of a file an error
was returned instead of returning the bytes read up to the end of
file. Thus the following fails in the shell:
offset = 0
len = chunksize
do
read file, offset, len
write data
until bytes_read < len
The patch changes the behaviour to printing an informational
message and returning the actual read number of bytes.
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
---
fs/fs.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/fs/fs.c b/fs/fs.c
index ac0897d..827b143 100644
--- a/fs/fs.c
+++ b/fs/fs.c
@@ -301,10 +301,8 @@ int fs_read(const char *filename, ulong addr, loff_t offset, loff_t len,
unmap_sysmem(buf);
/* If we requested a specific number of bytes, check we got it */
- if (ret == 0 && len && *actread != len) {
- printf("** Unable to read file %s **\n", filename);
- ret = -1;
- }
+ if (ret == 0 && len && *actread != len)
+ printf("** %s shorter than offset + len **\n", filename);
fs_close();
return ret;
--
1.9.3
^ permalink raw reply related [flat|nested] 28+ messages in thread* [U-Boot] [PATCH 1/8] fs/fs.c: read up to EOF when len would read past EOF
2015-07-01 23:04 ` [U-Boot] [PATCH 1/8] fs/fs.c: read up to EOF when len would read past EOF Marcel Ziswiler
@ 2015-07-02 5:46 ` Marek Vasut
2015-07-02 6:01 ` Marcel Ziswiler
0 siblings, 1 reply; 28+ messages in thread
From: Marek Vasut @ 2015-07-02 5:46 UTC (permalink / raw)
To: u-boot
On Thursday, July 02, 2015 at 01:04:46 AM, Marcel Ziswiler wrote:
> From: Max Krummenacher <max.krummenacher@toradex.com>
>
> http://lists.denx.de/pipermail/u-boot/2012-September/134347.html
> allows for reading files in chunks from the shell.
>
> When this feature is used to read past the end of a file an error
> was returned instead of returning the bytes read up to the end of
> file. Thus the following fails in the shell:
>
> offset = 0
> len = chunksize
> do
> read file, offset, len
> write data
> until bytes_read < len
>
> The patch changes the behaviour to printing an informational
> message and returning the actual read number of bytes.
>
> Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
> Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
So this behaves like read(2) now, right ?
Acked-by: Marek Vasut <marex@denx.de>
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 28+ messages in thread
* [U-Boot] [PATCH 2/8] net: asix: fix operation without eeprom
2015-07-01 23:04 [U-Boot] [PATCH 0/8] assortment of fixes/enhancements Marcel Ziswiler
2015-07-01 23:04 ` [U-Boot] [PATCH 1/8] fs/fs.c: read up to EOF when len would read past EOF Marcel Ziswiler
@ 2015-07-01 23:04 ` Marcel Ziswiler
2015-07-02 5:50 ` Marek Vasut
2015-07-08 3:55 ` Joe Hershberger
2015-07-01 23:04 ` [U-Boot] [PATCH 3/8] generic-board: allow showing custom board info Marcel Ziswiler
` (5 subsequent siblings)
7 siblings, 2 replies; 28+ messages in thread
From: Marcel Ziswiler @ 2015-07-01 23:04 UTC (permalink / raw)
To: u-boot
From: Marcel Ziswiler <marcel.ziswiler@toradex.com>
This patch fixes operation of our on-board AX88772B chip without EEPROM
but with a ethaddr coming from the regular U-Boot environment. This is
a forward port of some remaining parts initially implemented by
Antmicro.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
---
drivers/usb/eth/asix.c | 27 ++++++++++++++++++++++++++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/eth/asix.c b/drivers/usb/eth/asix.c
index c8697ae..3926d50 100644
--- a/drivers/usb/eth/asix.c
+++ b/drivers/usb/eth/asix.c
@@ -1,5 +1,8 @@
/*
* Copyright (c) 2011 The Chromium OS Authors.
+ * Copyright (c) 2012-2014 Toradex, Inc.
+ *
+ * Patched for AX88772B by Antmicro Ltd <www.antmicro.com>
*
* SPDX-License-Identifier: GPL-2.0+
*/
@@ -64,8 +67,14 @@
AX_MEDIUM_AC | AX_MEDIUM_RE)
/* AX88772 & AX88178 RX_CTL values */
+#define AX_RX_CTL_RH2M 0x0200 /* Enable IP header in receive
+ buffer aligned on 32-bit
+ boundary */
+#define AX_RX_CTL_RH1M 0x0100 /* Enable RX-Header mode 0 */
#define AX_RX_CTL_SO 0x0080
#define AX_RX_CTL_AB 0x0008
+#define AX_RX_HEADER_DEFAULT (AX_RX_CTL_RH1M | \
+ AX_RX_CTL_RH2M)
#define AX_DEFAULT_RX_CTL \
(AX_RX_CTL_SO | AX_RX_CTL_AB)
@@ -426,7 +435,15 @@ static int asix_init(struct eth_device *eth, bd_t *bd)
debug("** %s()\n", __func__);
- if (asix_write_rx_ctl(dev, AX_DEFAULT_RX_CTL) < 0)
+ if ((dev->pusb_dev->descriptor.idVendor == 0x0b95) &&
+ (dev->pusb_dev->descriptor.idProduct == 0x772b)) {
+ if (asix_write_rx_ctl(dev, AX_DEFAULT_RX_CTL |
+ AX_RX_HEADER_DEFAULT) < 0)
+ goto out_err;
+ } else if (asix_write_rx_ctl(dev, AX_DEFAULT_RX_CTL) < 0)
+ goto out_err;
+
+ if (asix_write_hwaddr(eth) < 0)
goto out_err;
do {
@@ -447,6 +464,10 @@ static int asix_init(struct eth_device *eth, bd_t *bd)
goto out_err;
}
+ /* Wait some more to avoid timeout on first transfer
+ (e.g. EHCI timed out on TD - token=0x8008d80) */
+ udelay(25000);
+
return 0;
out_err:
return -1;
@@ -533,6 +554,10 @@ static int asix_recv(struct eth_device *eth)
return -1;
}
+ if ((dev->pusb_dev->descriptor.idVendor == 0x0b95) &&
+ (dev->pusb_dev->descriptor.idProduct == 0x772b))
+ buf_ptr += 2;
+
/* Notify net stack */
net_process_received_packet(buf_ptr + sizeof(packet_len),
packet_len);
--
1.9.3
^ permalink raw reply related [flat|nested] 28+ messages in thread* [U-Boot] [PATCH 2/8] net: asix: fix operation without eeprom
2015-07-01 23:04 ` [U-Boot] [PATCH 2/8] net: asix: fix operation without eeprom Marcel Ziswiler
@ 2015-07-02 5:50 ` Marek Vasut
2015-07-02 6:12 ` Marcel Ziswiler
2015-07-08 3:55 ` Joe Hershberger
1 sibling, 1 reply; 28+ messages in thread
From: Marek Vasut @ 2015-07-02 5:50 UTC (permalink / raw)
To: u-boot
On Thursday, July 02, 2015 at 01:04:47 AM, Marcel Ziswiler wrote:
Hi!
[...]
> @@ -64,8 +67,14 @@
> AX_MEDIUM_AC | AX_MEDIUM_RE)
>
> /* AX88772 & AX88178 RX_CTL values */
> +#define AX_RX_CTL_RH2M 0x0200 /* Enable IP header in
receive
> + buffer aligned on 32-bit
> + boundary */
The comments need a bit of polishing, though it is not the main problem I have
with this patch. The multiline comments should be like this according to kernel
coding style (to my knowledge):
/*
* foo
* bar
* baz
*/
> +#define AX_RX_CTL_RH1M 0x0100 /* Enable RX-Header mode
0 */
> #define AX_RX_CTL_SO 0x0080
> #define AX_RX_CTL_AB 0x0008
> +#define AX_RX_HEADER_DEFAULT (AX_RX_CTL_RH1M | \
> + AX_RX_CTL_RH2M)
>
> #define AX_DEFAULT_RX_CTL \
> (AX_RX_CTL_SO | AX_RX_CTL_AB)
> @@ -426,7 +435,15 @@ static int asix_init(struct eth_device *eth, bd_t *bd)
>
> debug("** %s()\n", __func__);
>
> - if (asix_write_rx_ctl(dev, AX_DEFAULT_RX_CTL) < 0)
> + if ((dev->pusb_dev->descriptor.idVendor == 0x0b95) &&
> + (dev->pusb_dev->descriptor.idProduct == 0x772b)) {
I don't like hardcoding these constants here (and further down).
I understand that those are AX88792B chips (or whatever the number
is, there's a B at the end and they're not exactly compatible with
the original AX88792), but what about making this a bit more generic?
What I expect is that when AX88792C comes, we'd just add another
if (idVendor == ... ) into this code here with another magic number
and it will become an unmaintainable horror.
Maybe add a function which handles quirks of each revision (B, C, ...)
of the ASIX chip and definitelly define those magic numbers as macros.
> + if (asix_write_rx_ctl(dev, AX_DEFAULT_RX_CTL |
> + AX_RX_HEADER_DEFAULT) < 0)
> + goto out_err;
> + } else if (asix_write_rx_ctl(dev, AX_DEFAULT_RX_CTL) < 0)
> + goto out_err;
> +
> + if (asix_write_hwaddr(eth) < 0)
> goto out_err;
>
> do {
[...]
^ permalink raw reply [flat|nested] 28+ messages in thread* [U-Boot] [PATCH 2/8] net: asix: fix operation without eeprom
2015-07-02 5:50 ` Marek Vasut
@ 2015-07-02 6:12 ` Marcel Ziswiler
2015-07-02 18:39 ` Marek Vasut
0 siblings, 1 reply; 28+ messages in thread
From: Marcel Ziswiler @ 2015-07-02 6:12 UTC (permalink / raw)
To: u-boot
On 2 July 2015 07:50:59 CEST, Marek Vasut <marex@denx.de> wrote:
>On Thursday, July 02, 2015 at 01:04:47 AM, Marcel Ziswiler wrote:
>
>Hi!
>
>[...]
>
>> @@ -64,8 +67,14 @@
>> AX_MEDIUM_AC | AX_MEDIUM_RE)
>>
>> /* AX88772 & AX88178 RX_CTL values */
>> +#define AX_RX_CTL_RH2M 0x0200 /* Enable IP header in
>receive
>> + buffer aligned on 32-bit
>> + boundary */
>
>The comments need a bit of polishing, though it is not the main problem
>I have
>with this patch.
I was hesitant at first but then decided to submit it anyway to get some feedback on the thematic. So thank you very much!
>The multiline comments should be like this according
>to kernel
>coding style (to my knowledge):
>
>/*
> * foo
> * bar
> * baz
> */
Yeah, sorry. My bad. I since got educated in doing this but stumble over it at times on older patches.
>> +#define AX_RX_CTL_RH1M 0x0100 /* Enable RX-Header mode
>0 */
>> #define AX_RX_CTL_SO 0x0080
>> #define AX_RX_CTL_AB 0x0008
>> +#define AX_RX_HEADER_DEFAULT (AX_RX_CTL_RH1M | \
>> + AX_RX_CTL_RH2M)
>>
>> #define AX_DEFAULT_RX_CTL \
>> (AX_RX_CTL_SO | AX_RX_CTL_AB)
>> @@ -426,7 +435,15 @@ static int asix_init(struct eth_device *eth,
>bd_t *bd)
>>
>> debug("** %s()\n", __func__);
>>
>> - if (asix_write_rx_ctl(dev, AX_DEFAULT_RX_CTL) < 0)
>> + if ((dev->pusb_dev->descriptor.idVendor == 0x0b95) &&
>> + (dev->pusb_dev->descriptor.idProduct == 0x772b)) {
>
>I don't like hardcoding these constants here (and further down).
>I understand that those are AX88792B chips (or whatever the number
>is, there's a B at the end and they're not exactly compatible with
>the original AX88792), but what about making this a bit more generic?
AX88772B actually and yes there seem to be C variants of that same chip out now as well but we haven't gotten our hands on any such yet. I just do remember that ASIX does not take backwards compatibility too serious.
>What I expect is that when AX88792C comes, we'd just add another
>if (idVendor == ... ) into this code here with another magic number
>and it will become an unmaintainable horror.
Understood.
>Maybe add a function which handles quirks of each revision (B, C, ...)
>of the ASIX chip and definitelly define those magic numbers as macros.
Agreed.
>> + if (asix_write_rx_ctl(dev, AX_DEFAULT_RX_CTL |
>> + AX_RX_HEADER_DEFAULT) < 0)
>> + goto out_err;
>> + } else if (asix_write_rx_ctl(dev, AX_DEFAULT_RX_CTL) < 0)
>> + goto out_err;
>> +
>> + if (asix_write_hwaddr(eth) < 0)
>> goto out_err;
>>
>> do {
>
>[...]
^ permalink raw reply [flat|nested] 28+ messages in thread* [U-Boot] [PATCH 2/8] net: asix: fix operation without eeprom
2015-07-02 6:12 ` Marcel Ziswiler
@ 2015-07-02 18:39 ` Marek Vasut
0 siblings, 0 replies; 28+ messages in thread
From: Marek Vasut @ 2015-07-02 18:39 UTC (permalink / raw)
To: u-boot
On Thursday, July 02, 2015 at 08:12:32 AM, Marcel Ziswiler wrote:
> On 2 July 2015 07:50:59 CEST, Marek Vasut <marex@denx.de> wrote:
> >On Thursday, July 02, 2015 at 01:04:47 AM, Marcel Ziswiler wrote:
> >
> >Hi!
Hi!
> >[...]
> >
> >> @@ -64,8 +67,14 @@
> >>
> >> AX_MEDIUM_AC | AX_MEDIUM_RE)
> >>
> >> /* AX88772 & AX88178 RX_CTL values */
> >>
> >> +#define AX_RX_CTL_RH2M 0x0200 /* Enable IP header in
> >
> >receive
> >
> >> + buffer aligned on 32-bit
> >> + boundary */
> >
> >The comments need a bit of polishing, though it is not the main problem
> >I have
> >with this patch.
>
> I was hesitant at first but then decided to submit it anyway to get some
> feedback on the thematic. So thank you very much!
No worries :)
> >The multiline comments should be like this according
> >to kernel
> >coding style (to my knowledge):
> >
> >/*
> >
> > * foo
> > * bar
> > * baz
> > */
>
> Yeah, sorry. My bad. I since got educated in doing this but stumble over it
> at times on older patches.
Yeah, the code in certain areas of U-Boot isn't the pinacle of coding style
excellence for sure.
> >> +#define AX_RX_CTL_RH1M 0x0100 /* Enable RX-Header mode
> >
> >0 */
> >
> >> #define AX_RX_CTL_SO 0x0080
> >> #define AX_RX_CTL_AB 0x0008
> >>
> >> +#define AX_RX_HEADER_DEFAULT (AX_RX_CTL_RH1M | \
> >> + AX_RX_CTL_RH2M)
> >>
> >> #define AX_DEFAULT_RX_CTL \
> >>
> >> (AX_RX_CTL_SO | AX_RX_CTL_AB)
> >>
> >> @@ -426,7 +435,15 @@ static int asix_init(struct eth_device *eth,
> >
> >bd_t *bd)
> >
> >> debug("** %s()\n", __func__);
> >>
> >> - if (asix_write_rx_ctl(dev, AX_DEFAULT_RX_CTL) < 0)
> >> + if ((dev->pusb_dev->descriptor.idVendor == 0x0b95) &&
> >> + (dev->pusb_dev->descriptor.idProduct == 0x772b)) {
> >
> >I don't like hardcoding these constants here (and further down).
> >I understand that those are AX88792B chips (or whatever the number
> >is, there's a B at the end and they're not exactly compatible with
> >the original AX88792), but what about making this a bit more generic?
>
> AX88772B actually and yes there seem to be C variants of that same chip out
> now as well but we haven't gotten our hands on any such yet. I just do
> remember that ASIX does not take backwards compatibility too serious.
Yeah, that I can confirm this.
> >What I expect is that when AX88792C comes, we'd just add another
> >if (idVendor == ... ) into this code here with another magic number
> >and it will become an unmaintainable horror.
>
> Understood.
>
> >Maybe add a function which handles quirks of each revision (B, C, ...)
> >of the ASIX chip and definitelly define those magic numbers as macros.
>
> Agreed.
OK, thanks! :-)
[...]
^ permalink raw reply [flat|nested] 28+ messages in thread
* [U-Boot] [PATCH 2/8] net: asix: fix operation without eeprom
2015-07-01 23:04 ` [U-Boot] [PATCH 2/8] net: asix: fix operation without eeprom Marcel Ziswiler
2015-07-02 5:50 ` Marek Vasut
@ 2015-07-08 3:55 ` Joe Hershberger
2015-07-08 6:39 ` Marcel Ziswiler
1 sibling, 1 reply; 28+ messages in thread
From: Joe Hershberger @ 2015-07-08 3:55 UTC (permalink / raw)
To: u-boot
Hi Marcel,
On Wed, Jul 1, 2015 at 6:04 PM, Marcel Ziswiler <marcel@ziswiler.com> wrote:
> From: Marcel Ziswiler <marcel.ziswiler@toradex.com>
>
> This patch fixes operation of our on-board AX88772B chip without EEPROM
> but with a ethaddr coming from the regular U-Boot environment. This is
> a forward port of some remaining parts initially implemented by
> Antmicro.
>
> Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> ---
> drivers/usb/eth/asix.c | 27 ++++++++++++++++++++++++++-
> 1 file changed, 26 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/eth/asix.c b/drivers/usb/eth/asix.c
> index c8697ae..3926d50 100644
> --- a/drivers/usb/eth/asix.c
> +++ b/drivers/usb/eth/asix.c
> @@ -1,5 +1,8 @@
> /*
> * Copyright (c) 2011 The Chromium OS Authors.
> + * Copyright (c) 2012-2014 Toradex, Inc.
> + *
> + * Patched for AX88772B by Antmicro Ltd <www.antmicro.com>
> *
> * SPDX-License-Identifier: GPL-2.0+
> */
> @@ -64,8 +67,14 @@
> AX_MEDIUM_AC | AX_MEDIUM_RE)
>
> /* AX88772 & AX88178 RX_CTL values */
> +#define AX_RX_CTL_RH2M 0x0200 /* Enable IP header in receive
> + buffer aligned on 32-bit
> + boundary */
Definitely use checkpatch.pl on this series. I recommend patman.
> +#define AX_RX_CTL_RH1M 0x0100 /* Enable RX-Header mode 0 */
> #define AX_RX_CTL_SO 0x0080
> #define AX_RX_CTL_AB 0x0008
> +#define AX_RX_HEADER_DEFAULT (AX_RX_CTL_RH1M | \
> + AX_RX_CTL_RH2M)
I'm guessing this is ported from the ASIX Linux driver. Perhaps
mention in the log where it came from.
>
> #define AX_DEFAULT_RX_CTL \
> (AX_RX_CTL_SO | AX_RX_CTL_AB)
> @@ -426,7 +435,15 @@ static int asix_init(struct eth_device *eth, bd_t *bd)
>
> debug("** %s()\n", __func__);
>
> - if (asix_write_rx_ctl(dev, AX_DEFAULT_RX_CTL) < 0)
> + if ((dev->pusb_dev->descriptor.idVendor == 0x0b95) &&
> + (dev->pusb_dev->descriptor.idProduct == 0x772b)) {
Please don't use magic numbers. Also, ideally don't create PID hacks.
> + if (asix_write_rx_ctl(dev, AX_DEFAULT_RX_CTL |
> + AX_RX_HEADER_DEFAULT) < 0)
> + goto out_err;
> + } else if (asix_write_rx_ctl(dev, AX_DEFAULT_RX_CTL) < 0)
> + goto out_err;
> +
> + if (asix_write_hwaddr(eth) < 0)
> goto out_err;
>
> do {
> @@ -447,6 +464,10 @@ static int asix_init(struct eth_device *eth, bd_t *bd)
> goto out_err;
> }
>
> + /* Wait some more to avoid timeout on first transfer
> + (e.g. EHCI timed out on TD - token=0x8008d80) */
> + udelay(25000);
Is this always needed or is it only helpful to your device?
> +
> return 0;
> out_err:
> return -1;
> @@ -533,6 +554,10 @@ static int asix_recv(struct eth_device *eth)
> return -1;
> }
>
> + if ((dev->pusb_dev->descriptor.idVendor == 0x0b95) &&
> + (dev->pusb_dev->descriptor.idProduct == 0x772b))
Again, Avoid PID hacks and at least magic numbers.
> + buf_ptr += 2;
> +
> /* Notify net stack */
> net_process_received_packet(buf_ptr + sizeof(packet_len),
> packet_len);
Thanks,
-Joe
^ permalink raw reply [flat|nested] 28+ messages in thread* [U-Boot] [PATCH 2/8] net: asix: fix operation without eeprom
2015-07-08 3:55 ` Joe Hershberger
@ 2015-07-08 6:39 ` Marcel Ziswiler
0 siblings, 0 replies; 28+ messages in thread
From: Marcel Ziswiler @ 2015-07-08 6:39 UTC (permalink / raw)
To: u-boot
Hi Joe
On 8 July 2015 05:55:28 CEST, Joe Hershberger <joe.hershberger@gmail.com> wrote:
>Definitely use checkpatch.pl on this series.
Yeah, it's been late and I somehow forgot about it. I already run v2 about to be posted through it now.
> I recommend patman.
So far I have not used that one yet but thanks for the tip.
>I'm guessing this is ported from the ASIX Linux driver. Perhaps
>mention in the log where it came from.
As mentioned in the log it actually came from Antmicro who did an initial port way back 2011.
>Please don't use magic numbers.
I already got rid of this in v2.
> Also, ideally don't create PID hacks.
Understood, unfortunately I don't know what the effect of this on other ASIX variants is.
>Is this always needed or is it only helpful to your device?
Good question which posting it here I hoped to get some more feedback about.
Cheers
Marcel
^ permalink raw reply [flat|nested] 28+ messages in thread
* [U-Boot] [PATCH 3/8] generic-board: allow showing custom board info
2015-07-01 23:04 [U-Boot] [PATCH 0/8] assortment of fixes/enhancements Marcel Ziswiler
2015-07-01 23:04 ` [U-Boot] [PATCH 1/8] fs/fs.c: read up to EOF when len would read past EOF Marcel Ziswiler
2015-07-01 23:04 ` [U-Boot] [PATCH 2/8] net: asix: fix operation without eeprom Marcel Ziswiler
@ 2015-07-01 23:04 ` Marcel Ziswiler
2015-07-03 3:27 ` Simon Glass
2015-07-01 23:04 ` [U-Boot] [PATCH 4/8] logos: add Toradex logo Marcel Ziswiler
` (4 subsequent siblings)
7 siblings, 1 reply; 28+ messages in thread
From: Marcel Ziswiler @ 2015-07-01 23:04 UTC (permalink / raw)
To: u-boot
From: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Allow showing custom board info from a checkboard() function being
implemented if CONFIG_CUSTOM_BOARDINFO is specified.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
---
common/board_info.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/board_info.c b/common/board_info.c
index 42d0641..a692f74 100644
--- a/common/board_info.c
+++ b/common/board_info.c
@@ -19,7 +19,7 @@ int __weak checkboard(void)
*/
int show_board_info(void)
{
-#ifdef CONFIG_OF_CONTROL
+#if defined(CONFIG_OF_CONTROL) && !defined(CONFIG_CUSTOM_BOARDINFO)
DECLARE_GLOBAL_DATA_PTR;
const char *model;
--
1.9.3
^ permalink raw reply related [flat|nested] 28+ messages in thread* [U-Boot] [PATCH 3/8] generic-board: allow showing custom board info
2015-07-01 23:04 ` [U-Boot] [PATCH 3/8] generic-board: allow showing custom board info Marcel Ziswiler
@ 2015-07-03 3:27 ` Simon Glass
0 siblings, 0 replies; 28+ messages in thread
From: Simon Glass @ 2015-07-03 3:27 UTC (permalink / raw)
To: u-boot
Hi Marcel,
On 1 July 2015 at 17:04, Marcel Ziswiler <marcel@ziswiler.com> wrote:
> From: Marcel Ziswiler <marcel.ziswiler@toradex.com>
>
> Allow showing custom board info from a checkboard() function being
> implemented if CONFIG_CUSTOM_BOARDINFO is specified.
>
Can you reword this? It seems confusing. From what I can tell you are
turning off the device tree model display if CONFIG_CUSTOM_BOARDINFO
is enabled.
> Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> ---
> common/board_info.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/common/board_info.c b/common/board_info.c
> index 42d0641..a692f74 100644
> --- a/common/board_info.c
> +++ b/common/board_info.c
> @@ -19,7 +19,7 @@ int __weak checkboard(void)
> */
> int show_board_info(void)
> {
> -#ifdef CONFIG_OF_CONTROL
> +#if defined(CONFIG_OF_CONTROL) && !defined(CONFIG_CUSTOM_BOARDINFO)
> DECLARE_GLOBAL_DATA_PTR;
> const char *model;
>
> --
> 1.9.3
>
Regards,
Simon
^ permalink raw reply [flat|nested] 28+ messages in thread
* [U-Boot] [PATCH 4/8] logos: add Toradex logo
2015-07-01 23:04 [U-Boot] [PATCH 0/8] assortment of fixes/enhancements Marcel Ziswiler
` (2 preceding siblings ...)
2015-07-01 23:04 ` [U-Boot] [PATCH 3/8] generic-board: allow showing custom board info Marcel Ziswiler
@ 2015-07-01 23:04 ` Marcel Ziswiler
2015-07-01 23:04 ` [U-Boot] [PATCH 5/8] colibri_vf: remove spurious new line Marcel Ziswiler
` (3 subsequent siblings)
7 siblings, 0 replies; 28+ messages in thread
From: Marcel Ziswiler @ 2015-07-01 23:04 UTC (permalink / raw)
To: u-boot
From: Stefan Agner <stefan.agner@toradex.com>
Use the boot loader splash screen from WinCE which matches our
wallpapers position wise. Although the logo is an 8-bit indexed BMP as
well colours looked odd at first in U-Boot. After converting to full
RGB palette and converting back to an indexed BMP using imagemagick
the Logo showed up properly.
$ convert tools/logos/toradex-rgb.bmp -type Palette -colors 256 \
-compress none -verbose BMP3:tools/logos/toradex.bmp
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
---
tools/logos/toradex.bmp | Bin 0 -> 24982 bytes
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 tools/logos/toradex.bmp
diff --git a/tools/logos/toradex.bmp b/tools/logos/toradex.bmp
new file mode 100644
index 0000000000000000000000000000000000000000..3e2dcf23358dd46fc7b1bb0dae70d3ba985606ee
GIT binary patch
literal 24982
zcmeHPy>H~k6(3!0Ppji;#g)jt)k#_{wd9K2#Q*^=NL&Xlg21U<8%UaK+}lmcz@3r8
zfPpKV!nJ|?0|wHjaPQK8fh$)A3?uJj-pr63?s8A3a}M4CL=NZUy*Iyk^WK{wSAYD=
z=YLa_e*aLZ5_0byDD@|}AE+Uf|Mdf<P9y$<Lad;4aB!dw9z0MF;P2q!Z`5EgP!Em{
z)o?ge$H&KN5I<3e=V$8d>`X=FOvUf4RF-9GwOXm?&!4O0&+n+q7w at T?zki_KefM4U
z{`>E%7cX9 at 4?p}+ee}^sYW=T|)$^Ax)NlX&5B0nM{8Rnmzn`m5KKVp_`st_Yv(G+L
zFJHb?UwrX}`tr*!)mLAArM~|9YxT`H->7fD{Z at VV-FNEy@4r_+{P2VN at y8$4Pe1*n
ze*XDq7JPr*Bd|wckH8**|6c?$-BY$WuXH)>+4$GltT&d^Dw`HM`*ot!Z`8f993j0-
z)2$!rUtO!-SQ0X^-mmg*71<5T=*=whD64cerzMc+B?zC=6_$mH3O3tvSK1o<LQ{fn
zB&EG%WnAcLMi@*>T@|n=0S?u4y2i3urHi;E<0ZADLN604a at 3Vdz+-S{=(3z(U(17X
znYN6Qr7kB^4V;ov=iHE?rY_KKnQ&(-KGM5~6zSz0hL2#*Gz!F5#Bx;SV790BUc(Z0
zTv-Oqn?tM$W9kcC%w|iVo9ld5RfuJ#p|YwFOR0^@Y6e(ik%uM7P-H~~<O`ioml`Lh
zi_r+?4k#c_Knq%8Lx*KlVfCBAQpF%dg7c}COP$KqNCS@*)L<ptlZ5j)M9DRW$Uw!Q
z-k5_FV`hXv#kzp!44-Z7RD;q@sjZ_v)g>(yr6y$P3UnRR#$JdDh!I0)kSeB$piwli
zoMCm70SR_rmkN-I^b~gactsR=W&uNkn%r4}ZY+6frZ7y<DoivOB15BQY;7$~)rcVC
z=5Pg7GEf>S2_kA?G+<#9tYAS&ASQ!Xr<WlHmeajtaEYWk$(JBrlH-XCOA}>0*K!x;
z-B at Ca2s%}0dokq%Dw5+IL1Ak-Q^#^bYnnQ9HPUNgiS<~)g3>jFWrb^jJ7eblQ;MrE
z)6qmnQw<9XREmU~Rys%ZlDn0p6HB%TK#rXgjE<WkInxP8Y-?%RH-?(yvgE|o3U36I
zy=0cr7A!*yg!+BllM1CTm$3el0<U1hP{gTT;*zy@$Ga0t=w<Y>oIrxH=TwAO&Jie;
z)Q0qODds^L?T!Li5>?ehFKK<y960gsFE`T__#84?)eHj~bgPJEg^L}M-1!Nw9222k
z#pP!%)Qj!qOy#IJBd}*P@DFTu*<Mn7VrvU*M(zpjCY6j6KCxX*aM5=$>d;GEPKY4c
z%LW6(=k?zrh`(^O6LjJbQQ{RaBrJ{1v)0XWhaD~?jQcR00xyjh7%-bxT%;)~_XILD
z4)U`x!I9$#ZS55Ku~W9hJ-tlHbmll6VMZ|t%HkSRf%G%<R<zp*F|eFocV@;W5!i!g
zoKlE6g)Cw@gLp6pq2%sZduzNZXG>k+1?)ry5jMn^Xzu~;8BGGmm#Aww#h0|+q!!~#
zh|6L4E_wD6s9=nX)w<58B1W(%tX?KylBO^-gk@Fbvl2(-1+b38edRD5!c^it(YUM=
z&?yoTHYX)2pWGqK$-{CAf%pV=G}I6#1ou6-z#`n_PzLusJYp>30La$jzNfJSJwFaq
zKm^)M>pG)S7+EYcbZEv&!Tt+&L*&AU0c{3E`1`wSgXK;f9G3NNJg|BhJ$V&%C8XMV
z5yY1`2fL>_nce%}xkrI(bJujQSb{aBV0~vme{n2hSa*5*<k?fC0MP7vz}YlXXD_cJ
zFydwrm~GgPqq*BDWh79O*iIzw*ceaomteE&$s2sVf}S`gG9i;!-`UHn2#mE=6fev<
zkw?34wneOO$9roR?Wz<c$)x6xJ>k3x3Z=X%$Oek)4R(1N?Q9!%p}udsM_`Y at 9)Udq
zdj$3f>=D=_ut#7g1dfhR;S1NZ)A5s?x@~D3CDUxNSX at uy!IqYx>XUQ^oo}Y;rl8-k
z7=~y_Sua}B_%8Q{<7bywk}ggk??@{yFtzrODuu13q}y2?kiiZ1p`)-cw+LQpOIj5Z
z04l;B4L0~ifuwSd2hyR`rbVrW3!=C<Z1=h5ns&vulJU9VXzr&++q%^1QyNVZ7x);W
zmR56rXErFYa#5q>Jq+MoTP at vA;FTe!r(UZj3!T>|jGMM;$+WZJ`o<&4SvVQNwDa-T
z<7W*d;ql_QMSep;2+PAci{oD_Pqx7=*0e{#Y~UESmGXFnWe&^1b*qhrGv#Iq(lXQf
zlqs~-fQucgCe4oLCl_rfp=8|AJX9RO5?%qd(+Xdqn6weglu&CDsMc6w2RIC|(E3_9
zn0wk#aH6`tJ>lvbX5vjUl#jSe*F-lMxW~s~D6g(|(9AZLL(!`;pQh<#RuBvzw*_+(
zmZ`K}&L?U5^rnV}U}>R*PnL*<;6HbRgItRiH(OT><{=Aezw*Gorfj*<m(`f?!=t9D
zv`Tu}-=Vj$%z3(RCt at N`<^~@zRU5E8F{tF$m83E?KvuA9u^7!vKRaJAM79fBTUv*y
zQRiD0ZB$XO!t+1$)`!pK1Bi7OomuQ!nTto=-Rd<hERE^T{F#NX@i2)7bYm&1BB&ED
zL(ySrEM1MoiGkeCfjT6sOfT=9$c9$VVOq?S>`qM$<r;g}xjT2<LeMKX?e15vX<|8I
z1!=s081cA_>+Z&qhgvy6h#B*+ScX{~va&91Fxx?ENy%`S;1p|o7f&f+Y<=Z6HCt{0
z7w*8k>>Fn`v1EhZig%1j=OJ`r8Ig5d*S!G at Lo}1uI7bOB7DJvd(J7|2Ewtfqz;KLs
z`QWD{yQL=%xKOUIVm7d3ohijsI+3^?1JH>jW7hP>K*ZQN!ZISw53pdZk`LrMX*ro7
zHz?Mqi}b<ffVmiBT5GoD;WUJxD?7K{2fpP~^(Xus1(RJBY;a`FSQ?Nad&Y0BJF)cI
z_+9B^Q)EL}^12i^<hRRdiJIlxNz3m68!8SI3NQ_<qpOC2sW%Tiji349(8cNTv2#TD
zbb4`R7I}PAm2U4g%5JNoHjD<AG_}EZ{R{yu-!3digvC4{FV6&Hxj<BdELbslUQdWt
zK*gKXjkmuxT7e%Z?UWpFsEB9ev?Xpor#<B33l7-Rl|Mds8IH*}D0M7{-Md2uihNQR
zmQ1T<EpcePVsRD+B!e%49r__wt+|S6rBP?Hy||^m=CSoa-}c1J*ezwqN&LfpU7XGn
zGMFqlNXYtR;tuQgfL0w#2F$K_pDP1M1MR|+09%E&)$olHCd860a*zd?)ioPT2EXb~
zZpzI5hd3;~SksrjGhdI<t(T$VGwDTp9}_dsM@#t8l}TdXp=}*Y__z;Jc$v`hFOYl}
zmgJyI8`Ov-ct0V+h~*|0M4%!#0!IQw!d{$BH$g4dNCfP&-kf)5Y^b1i_f0F`B1;RO
zY!foMMT#bpty!xOmTt;@IcWMfVo4FAH&0$~R(QmcCp63gevBf*nXM5PgcH&-$pmcB
zF02L8E_CmOCHWq!{)DB~($cy1{#erJHeyLL_nNS@S`bFk?MD%yB(MVw0T(E1xE|Bu
z5xI7Wg&vW*+Eq>GCcL~rI6{QGg|H0Iu3O_AE_y_a1f*7F&|<lj&8yw5P=9>1n`ReJ
zw7PJ_a$iWnvawt9Nq6PzVY(b-n1Iuq5si7VbNH%Pe6k{w?X9pnmK?1GMLHxG&s$%j
z(*})f$l9EU)rDs^82W8s!E?k|vOUV at fy86-!pOU<adqrRmwfp9NMiR(RLF<pOU9JX
zBKZ?prG^ZGKc#gnISvdiQ`RiDQtV{C(J*k_B&c#^Y*w_LqF^G(f_FrWC9f!7Qad^9
zq1@KY^F2mqY|}oOqcKF|E}fs9d5`pTDX%J$*>&p7V=}$AXKBQ!fhEZqR4v|Bu+lMT
ztx#@AAzpj!!z6k&OsF*xAPwsxW6A2fjTQ~Tclocdfdm@$Ak*P$ayB+1cHNf-maGn~
za|c<P<`jp6A|A9)nr(<@L8Q`!>Jk(MSjZt8Yg{KSM%=k^<5A(GdQ8DhfQZp`Kk_uO
zg=GJu^#+y$4(Ho&@X%xgjEy at tG(z%BxMMSsoedf<akH}z8~_=2W2UGdEtneG*ujri
zcqHy<L74Zsi-8OPd37c3d@G>_mPR7^p{(uB%3u$7%!xwFG_qTm+isjW<YKW2%(4|$
zGk6kT%GpwrmN^U(TJWP2tBz(af;P4xQS))5V)lOH)5Ov!=52i^$WVHFPcB$D!DK_)
zcn217+-)bqoWL#X4j+C=$Vp7cCR)-)5NF!V$Gi<{!nOH%!@+uAYuVgG0z>o0#(%*I
zKhw37FCv*>Ywp|{)fn9<Je(3f<Mjf<0E?lECoN8WXmOi0dorV=JHI$X$vap1`9m4<
z)_YSg@t1d;mJ`;^m``BVy5=K|-0;gN9>?e@!8b5_ztv4LK;BVm3h38(A`LUu at b4cC
z3*$J5vBlEpuLfEa{|9IpLSn{^?F{%e;oN=i0F#g1y1V%`Z7kt8dnQ%IVv)<)lDtWk
z&a&44MDoR=SeeaKWV8^D0I*mVt~PJGOmE9#<+EV64omZv35q*tnIPTyZuW`Z5)f&7
z-0QnZ<Au)qzUx5-0W9t78Nrn9@`m3^6|>cMjrbfb_@#o*NK0+sFpH85hr<%SLUPny
zE|XoV@k7oK<8Ll8?R>UQf{oje5g!dZu{Y;JSgM3SvvA_W*F$cfAp}RVe5D<G(7}wO
z6e)$fZ+uN}v7%n9Vnk}?VW|S2%6PQQi!(p$=S@M~9ErSJ??<%_(ACwm{+}5T?I4zF
z2tNb$lY7fi6UhIL0Gf+Ijq4z<vU*U!B!GoE-C;)X0T){rA4>=yyJ at w83nXkzX3_A8
zHL<%Nj>fWqygWbM5y|ixM_$oHzUW)u&fB58h?8WuMhmOl+nmPNO9K at AHaUbOvk-H-
zE*B{p0Wza?ECHRF&|1}KMT;Vb)I5kuu`n;XMHbOJ?nlSt)6?<s<Nog35(?`jRYx&=
z5R@ieP#6+}Q39>fxM>5Rcrs}hTgJj-f-H;$3}Oild(o;>{w1C^VEN|7>B92OOY%w_
zdFLhp+AEQGeVyJeER(d6*cUDur4n_#KA3t at db_ZcO^xrQ1NkjBvKKI~(CF>L(rs!2
z2-+e!9eV{h?$qTi!_w>wENsEd9?O0z;Wo at c7^!gG3~>69zH_U$O)phkc7Ir6YWyAU
RodMc`0Q`TRs=7z!{{x@?rvLx|
literal 0
HcmV?d00001
--
1.9.3
^ permalink raw reply [flat|nested] 28+ messages in thread* [U-Boot] [PATCH 5/8] colibri_vf: remove spurious new line
2015-07-01 23:04 [U-Boot] [PATCH 0/8] assortment of fixes/enhancements Marcel Ziswiler
` (3 preceding siblings ...)
2015-07-01 23:04 ` [U-Boot] [PATCH 4/8] logos: add Toradex logo Marcel Ziswiler
@ 2015-07-01 23:04 ` Marcel Ziswiler
2015-07-02 5:52 ` Marek Vasut
2015-07-01 23:04 ` [U-Boot] [PATCH 6/8] image-fdt.c: store returned error value Marcel Ziswiler
` (2 subsequent siblings)
7 siblings, 1 reply; 28+ messages in thread
From: Marcel Ziswiler @ 2015-07-01 23:04 UTC (permalink / raw)
To: u-boot
From: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Remove spurious new line in configuration file.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
---
include/configs/colibri_vf.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/configs/colibri_vf.h b/include/configs/colibri_vf.h
index aff2810..2523f32 100644
--- a/include/configs/colibri_vf.h
+++ b/include/configs/colibri_vf.h
@@ -69,7 +69,6 @@
"512k(u-boot-env)," \
"-(ubi)"
-
#define CONFIG_MMC
#define CONFIG_FSL_ESDHC
#define CONFIG_SYS_FSL_ESDHC_ADDR 0
--
1.9.3
^ permalink raw reply related [flat|nested] 28+ messages in thread* [U-Boot] [PATCH 6/8] image-fdt.c: store returned error value
2015-07-01 23:04 [U-Boot] [PATCH 0/8] assortment of fixes/enhancements Marcel Ziswiler
` (4 preceding siblings ...)
2015-07-01 23:04 ` [U-Boot] [PATCH 5/8] colibri_vf: remove spurious new line Marcel Ziswiler
@ 2015-07-01 23:04 ` Marcel Ziswiler
2015-07-02 5:52 ` Marek Vasut
2015-07-01 23:04 ` [U-Boot] [PATCH 7/8] mtd/nand/ubi: assortment of alignment fixes Marcel Ziswiler
2015-07-01 23:04 ` [U-Boot] [PATCH 8/8] tftp.c: fix CONFIG_TFTP_TSIZE for small files Marcel Ziswiler
7 siblings, 1 reply; 28+ messages in thread
From: Marcel Ziswiler @ 2015-07-01 23:04 UTC (permalink / raw)
To: u-boot
From: Max Krummenacher <max.krummenacher@toradex.com>
This fixes the following warning (and the runtime error reporting):
../common/image-fdt.c:491:4: warning: 'fdt_ret' may be used
uninitialized in this function [-Wmaybe-uninitialized]
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
---
common/image-fdt.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/common/image-fdt.c b/common/image-fdt.c
index 80e3e63..d9fce17 100644
--- a/common/image-fdt.c
+++ b/common/image-fdt.c
@@ -492,7 +492,8 @@ int image_setup_libfdt(bootm_headers_t *images, void *blob,
}
}
if (IMAGE_OF_SYSTEM_SETUP) {
- if (ft_system_setup(blob, gd->bd)) {
+ fdt_ret = ft_system_setup(blob, gd->bd);
+ if (fdt_ret) {
printf("ERROR: system-specific fdt fixup failed: %s\n",
fdt_strerror(fdt_ret));
goto err;
--
1.9.3
^ permalink raw reply related [flat|nested] 28+ messages in thread* [U-Boot] [PATCH 6/8] image-fdt.c: store returned error value
2015-07-01 23:04 ` [U-Boot] [PATCH 6/8] image-fdt.c: store returned error value Marcel Ziswiler
@ 2015-07-02 5:52 ` Marek Vasut
2015-07-03 3:21 ` Simon Glass
0 siblings, 1 reply; 28+ messages in thread
From: Marek Vasut @ 2015-07-02 5:52 UTC (permalink / raw)
To: u-boot
On Thursday, July 02, 2015 at 01:04:51 AM, Marcel Ziswiler wrote:
> From: Max Krummenacher <max.krummenacher@toradex.com>
>
> This fixes the following warning (and the runtime error reporting):
> ../common/image-fdt.c:491:4: warning: 'fdt_ret' may be used
> uninitialized in this function [-Wmaybe-uninitialized]
>
> Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
> Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Acked-by: Marek Vasut <marex@denx.de>
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 28+ messages in thread
* [U-Boot] [PATCH 6/8] image-fdt.c: store returned error value
2015-07-02 5:52 ` Marek Vasut
@ 2015-07-03 3:21 ` Simon Glass
0 siblings, 0 replies; 28+ messages in thread
From: Simon Glass @ 2015-07-03 3:21 UTC (permalink / raw)
To: u-boot
On 1 July 2015 at 23:52, Marek Vasut <marex@denx.de> wrote:
> On Thursday, July 02, 2015 at 01:04:51 AM, Marcel Ziswiler wrote:
>> From: Max Krummenacher <max.krummenacher@toradex.com>
>>
>> This fixes the following warning (and the runtime error reporting):
>> ../common/image-fdt.c:491:4: warning: 'fdt_ret' may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
>>
>> Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
>> Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
>
> Acked-by: Marek Vasut <marex@denx.de>
Acked-by: Simon Glass <sjg@chromium.org>
^ permalink raw reply [flat|nested] 28+ messages in thread
* [U-Boot] [PATCH 7/8] mtd/nand/ubi: assortment of alignment fixes
2015-07-01 23:04 [U-Boot] [PATCH 0/8] assortment of fixes/enhancements Marcel Ziswiler
` (5 preceding siblings ...)
2015-07-01 23:04 ` [U-Boot] [PATCH 6/8] image-fdt.c: store returned error value Marcel Ziswiler
@ 2015-07-01 23:04 ` Marcel Ziswiler
2015-07-02 5:53 ` Marek Vasut
2015-07-01 23:04 ` [U-Boot] [PATCH 8/8] tftp.c: fix CONFIG_TFTP_TSIZE for small files Marcel Ziswiler
7 siblings, 1 reply; 28+ messages in thread
From: Marcel Ziswiler @ 2015-07-01 23:04 UTC (permalink / raw)
To: u-boot
From: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Various U-Boot adoptions/extensions to MTD/NAND/UBI did not take buffer
alignment into account which led to failures of the following form:
ERROR: v7_dcache_inval_range - start address is not aligned - 0x1f7f0108
ERROR: v7_dcache_inval_range - stop address is not aligned - 0x1f7f1108
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
---
common/cmd_ubi.c | 2 +-
drivers/mtd/nand/nand_util.c | 2 +-
fs/ubifs/super.c | 4 ++--
fs/ubifs/ubifs.c | 4 ++--
lib/gzip.c | 2 +-
5 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/common/cmd_ubi.c b/common/cmd_ubi.c
index cbc10c5..30a1259 100644
--- a/common/cmd_ubi.c
+++ b/common/cmd_ubi.c
@@ -363,7 +363,7 @@ int ubi_volume_read(char *volume, char *buf, size_t size)
tbuf_size = vol->usable_leb_size;
if (size < tbuf_size)
tbuf_size = ALIGN(size, ubi->min_io_size);
- tbuf = malloc(tbuf_size);
+ tbuf = memalign(ARCH_DMA_MINALIGN, tbuf_size);
if (!tbuf) {
printf("NO MEM\n");
return ENOMEM;
diff --git a/drivers/mtd/nand/nand_util.c b/drivers/mtd/nand/nand_util.c
index ee2c24d..395ba2d 100644
--- a/drivers/mtd/nand/nand_util.c
+++ b/drivers/mtd/nand/nand_util.c
@@ -839,7 +839,7 @@ int nand_torture(nand_info_t *nand, loff_t offset)
patt_count = ARRAY_SIZE(patterns);
- buf = malloc(nand->erasesize);
+ buf = memalign(ARCH_DMA_MINALIGN, nand->erasesize);
if (buf == NULL) {
puts("Out of memory for erase block buffer\n");
return -ENOMEM;
diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c
index 10f8fff..ac0d13f 100644
--- a/fs/ubifs/super.c
+++ b/fs/ubifs/super.c
@@ -57,7 +57,7 @@ struct inode *iget_locked(struct super_block *sb, unsigned long ino)
{
struct inode *inode;
- inode = (struct inode *)malloc(sizeof(struct ubifs_inode));
+ inode = (struct inode *)memalign(ARCH_DMA_MINALIGN, sizeof(struct ubifs_inode));
if (inode) {
inode->i_ino = ino;
inode->i_sb = sb;
@@ -104,7 +104,7 @@ void iput(struct inode *inode)
/*
* Allocate and use new inode
*/
- ino = (struct inode *)malloc(sizeof(struct ubifs_inode));
+ ino = (struct inode *)memalign(ARCH_DMA_MINALIGN, sizeof(struct ubifs_inode));
memcpy(ino, inode, sizeof(struct ubifs_inode));
/*
diff --git a/fs/ubifs/ubifs.c b/fs/ubifs/ubifs.c
index 6dd6174..03f9f79 100644
--- a/fs/ubifs/ubifs.c
+++ b/fs/ubifs/ubifs.c
@@ -108,7 +108,7 @@ static inline struct crypto_comp *crypto_alloc_comp(const char *alg_name,
struct crypto_comp *ptr;
int i = 0;
- ptr = malloc(sizeof(struct crypto_comp));
+ ptr = memalign(ARCH_DMA_MINALIGN, sizeof(struct crypto_comp));
while (i < UBIFS_COMPR_TYPES_CNT) {
comp = ubifs_compressors[i];
if (!comp) {
@@ -723,7 +723,7 @@ static int do_readpage(struct ubifs_info *c, struct inode *inode,
* destination area to a multiple of
* UBIFS_BLOCK_SIZE.
*/
- buff = malloc(UBIFS_BLOCK_SIZE);
+ buff = memalign(ARCH_DMA_MINALIGN, UBIFS_BLOCK_SIZE);
if (!buff) {
printf("%s: Error, malloc fails!\n",
__func__);
diff --git a/lib/gzip.c b/lib/gzip.c
index ff37d4f..2a74411 100644
--- a/lib/gzip.c
+++ b/lib/gzip.c
@@ -25,7 +25,7 @@ static void *zalloc(void *x, unsigned items, unsigned size)
size *= items;
size = (size + ZALLOC_ALIGNMENT - 1) & ~(ZALLOC_ALIGNMENT - 1);
- p = malloc (size);
+ p = memalign(ARCH_DMA_MINALIGN, size);
return (p);
}
--
1.9.3
^ permalink raw reply related [flat|nested] 28+ messages in thread* [U-Boot] [PATCH 7/8] mtd/nand/ubi: assortment of alignment fixes
2015-07-01 23:04 ` [U-Boot] [PATCH 7/8] mtd/nand/ubi: assortment of alignment fixes Marcel Ziswiler
@ 2015-07-02 5:53 ` Marek Vasut
2015-07-02 21:35 ` Scott Wood
0 siblings, 1 reply; 28+ messages in thread
From: Marek Vasut @ 2015-07-02 5:53 UTC (permalink / raw)
To: u-boot
On Thursday, July 02, 2015 at 01:04:52 AM, Marcel Ziswiler wrote:
> From: Marcel Ziswiler <marcel.ziswiler@toradex.com>
>
> Various U-Boot adoptions/extensions to MTD/NAND/UBI did not take buffer
> alignment into account which led to failures of the following form:
>
> ERROR: v7_dcache_inval_range - start address is not aligned - 0x1f7f0108
> ERROR: v7_dcache_inval_range - stop address is not aligned - 0x1f7f1108
>
> Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
What about using ALLOC_CACHE_ALIGN_BUFFER() and friends instead ? See
include/common.h for their definition, this is what those functions are
exactly for.
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 28+ messages in thread
* [U-Boot] [PATCH 7/8] mtd/nand/ubi: assortment of alignment fixes
2015-07-02 5:53 ` Marek Vasut
@ 2015-07-02 21:35 ` Scott Wood
2015-07-03 13:44 ` Marek Vasut
0 siblings, 1 reply; 28+ messages in thread
From: Scott Wood @ 2015-07-02 21:35 UTC (permalink / raw)
To: u-boot
On Thu, 2015-07-02 at 07:53 +0200, Marek Vasut wrote:
> On Thursday, July 02, 2015 at 01:04:52 AM, Marcel Ziswiler wrote:
> > From: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> >
> > Various U-Boot adoptions/extensions to MTD/NAND/UBI did not take buffer
> > alignment into account which led to failures of the following form:
> >
> > ERROR: v7_dcache_inval_range - start address is not aligned - 0x1f7f0108
> > ERROR: v7_dcache_inval_range - stop address is not aligned - 0x1f7f1108
> >
> > Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
>
> What about using ALLOC_CACHE_ALIGN_BUFFER() and friends instead ? See
> include/common.h for their definition, this is what those functions are
> exactly for.
ALLOC_CACHE_ALIGN_BUFFER() is for statically allocating an aligned buffer.
Dynamically allocating an aligned buffer is exactly what memalign() is for.
-Scott
^ permalink raw reply [flat|nested] 28+ messages in thread
* [U-Boot] [PATCH 7/8] mtd/nand/ubi: assortment of alignment fixes
2015-07-02 21:35 ` Scott Wood
@ 2015-07-03 13:44 ` Marek Vasut
2015-07-06 21:25 ` Scott Wood
0 siblings, 1 reply; 28+ messages in thread
From: Marek Vasut @ 2015-07-03 13:44 UTC (permalink / raw)
To: u-boot
On Thursday, July 02, 2015 at 11:35:19 PM, Scott Wood wrote:
> On Thu, 2015-07-02 at 07:53 +0200, Marek Vasut wrote:
> > On Thursday, July 02, 2015 at 01:04:52 AM, Marcel Ziswiler wrote:
> > > From: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> > >
> > > Various U-Boot adoptions/extensions to MTD/NAND/UBI did not take buffer
> > > alignment into account which led to failures of the following form:
> > >
> > > ERROR: v7_dcache_inval_range - start address is not aligned -
> > > 0x1f7f0108 ERROR: v7_dcache_inval_range - stop address is not aligned
> > > - 0x1f7f1108
> > >
> > > Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> >
> > What about using ALLOC_CACHE_ALIGN_BUFFER() and friends instead ? See
> > include/common.h for their definition, this is what those functions are
> > exactly for.
>
> ALLOC_CACHE_ALIGN_BUFFER() is for statically allocating an aligned buffer.
You're confusing this with DEFINE_ALIGN_BUFFER, no ?
> Dynamically allocating an aligned buffer is exactly what memalign() is for.
Isn't memalign()ed memory aligned only to the start address, while the end
address (and thus the length) is not aligned ? This is what memalign(3) has
to say:
"
The function posix_memalign() allocates size bytes and places the
address of the allocated memory in *memptr. The address of the
allo? cated memory will be a multiple of alignment, which must
be a power of two and a multiple of sizeof(void *). If size is 0,
then the value placed in *memptr is either NULL, or a unique pointer
value that can later be successfully passed to free(3).
The obsolete function memalign() allocates size bytes and returns a
pointer to the allocated memory. The memory address will be a mul?
tiple of alignment, which must be a power of two.
"
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 28+ messages in thread
* [U-Boot] [PATCH 7/8] mtd/nand/ubi: assortment of alignment fixes
2015-07-03 13:44 ` Marek Vasut
@ 2015-07-06 21:25 ` Scott Wood
2015-07-06 21:45 ` Marek Vasut
0 siblings, 1 reply; 28+ messages in thread
From: Scott Wood @ 2015-07-06 21:25 UTC (permalink / raw)
To: u-boot
On Fri, 2015-07-03 at 15:44 +0200, Marek Vasut wrote:
> On Thursday, July 02, 2015 at 11:35:19 PM, Scott Wood wrote:
> > On Thu, 2015-07-02 at 07:53 +0200, Marek Vasut wrote:
> > > On Thursday, July 02, 2015 at 01:04:52 AM, Marcel Ziswiler wrote:
> > > > From: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> > > >
> > > > Various U-Boot adoptions/extensions to MTD/NAND/UBI did not take
> > > > buffer
> > > > alignment into account which led to failures of the following form:
> > > >
> > > > ERROR: v7_dcache_inval_range - start address is not aligned -
> > > > 0x1f7f0108 ERROR: v7_dcache_inval_range - stop address is not aligned
> > > > - 0x1f7f1108
> > > >
> > > > Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> > >
> > > What about using ALLOC_CACHE_ALIGN_BUFFER() and friends instead ? See
> > > include/common.h for their definition, this is what those functions are
> > > exactly for.
> >
> > ALLOC_CACHE_ALIGN_BUFFER() is for statically allocating an aligned buffer.
>
> You're confusing this with DEFINE_ALIGN_BUFFER, no ?
OK, not "statically", but on the stack. It is not appropriate to turn
dynamic allocations into stack allocations without considering how large the
allocation can be. It'd also be more intrusive a change than necessary, even
if the sizes were small enough.
> > Dynamically allocating an aligned buffer is exactly what memalign() is
> > for.
>
> Isn't memalign()ed memory aligned only to the start address, while the end
> address (and thus the length) is not aligned ?
The end address is aligned if the size passed to memalign is aligned. Maybe
add a wrapper that calls memalign() with the size rounded up to
ARCH_DMA_MINALIGN?
> This is what memalign(3) has
> to say:
>
> "
> The function posix_memalign() allocates size bytes and places the
> address of the allocated memory in *memptr. The address of the
> allo? cated memory will be a multiple of alignment, which must
> be a power of two and a multiple of sizeof(void *). If size is 0,
> then the value placed in *memptr is either NULL, or a unique pointer
> value that can later be successfully passed to free(3).
>
> The obsolete function memalign() allocates size bytes and returns a
> pointer to the allocated memory. The memory address will be a mul?
> tiple of alignment, which must be a power of two.
> "
posix_memalign() does not exist in U-Boot, and it's not clear to me why
memalign() should be considered obsolete. Is the difference just the ability
to return -EINVAL?
-Scott
^ permalink raw reply [flat|nested] 28+ messages in thread
* [U-Boot] [PATCH 7/8] mtd/nand/ubi: assortment of alignment fixes
2015-07-06 21:25 ` Scott Wood
@ 2015-07-06 21:45 ` Marek Vasut
2015-07-06 21:50 ` Scott Wood
0 siblings, 1 reply; 28+ messages in thread
From: Marek Vasut @ 2015-07-06 21:45 UTC (permalink / raw)
To: u-boot
On Monday, July 06, 2015 at 11:25:35 PM, Scott Wood wrote:
> On Fri, 2015-07-03 at 15:44 +0200, Marek Vasut wrote:
> > On Thursday, July 02, 2015 at 11:35:19 PM, Scott Wood wrote:
> > > On Thu, 2015-07-02 at 07:53 +0200, Marek Vasut wrote:
> > > > On Thursday, July 02, 2015 at 01:04:52 AM, Marcel Ziswiler wrote:
> > > > > From: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> > > > >
> > > > > Various U-Boot adoptions/extensions to MTD/NAND/UBI did not take
> > > > > buffer
> > > > > alignment into account which led to failures of the following form:
> > > > >
> > > > > ERROR: v7_dcache_inval_range - start address is not aligned -
> > > > > 0x1f7f0108 ERROR: v7_dcache_inval_range - stop address is not
> > > > > aligned - 0x1f7f1108
> > > > >
> > > > > Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> > > >
> > > > What about using ALLOC_CACHE_ALIGN_BUFFER() and friends instead ? See
> > > > include/common.h for their definition, this is what those functions
> > > > are exactly for.
> > >
> > > ALLOC_CACHE_ALIGN_BUFFER() is for statically allocating an aligned
> > > buffer.
> >
> > You're confusing this with DEFINE_ALIGN_BUFFER, no ?
>
> OK, not "statically", but on the stack. It is not appropriate to turn
> dynamic allocations into stack allocations without considering how large
> the allocation can be. It'd also be more intrusive a change than
> necessary, even if the sizes were small enough.
Fine.
> > > Dynamically allocating an aligned buffer is exactly what memalign() is
> > > for.
> >
> > Isn't memalign()ed memory aligned only to the start address, while the
> > end address (and thus the length) is not aligned ?
>
> The end address is aligned if the size passed to memalign is aligned.
> Maybe add a wrapper that calls memalign() with the size rounded up to
> ARCH_DMA_MINALIGN?
I agree.
> > This is what memalign(3) has
> >
> > to say:
> >
> > "
> > The function posix_memalign() allocates size bytes and places the
> > address of the allocated memory in *memptr. The address of the
> > allo? cated memory will be a multiple of alignment, which must
> > be a power of two and a multiple of sizeof(void *). If size is 0,
> > then the value placed in *memptr is either NULL, or a unique pointer
> > value that can later be successfully passed to free(3).
> >
> > The obsolete function memalign() allocates size bytes and returns a
> > pointer to the allocated memory. The memory address will be a mul?
> > tiple of alignment, which must be a power of two.
> > "
>
> posix_memalign() does not exist in U-Boot, and it's not clear to me why
> memalign() should be considered obsolete. Is the difference just the
> ability to return -EINVAL?
The args are also totally different.
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 28+ messages in thread
* [U-Boot] [PATCH 7/8] mtd/nand/ubi: assortment of alignment fixes
2015-07-06 21:45 ` Marek Vasut
@ 2015-07-06 21:50 ` Scott Wood
2015-07-06 21:57 ` Marek Vasut
0 siblings, 1 reply; 28+ messages in thread
From: Scott Wood @ 2015-07-06 21:50 UTC (permalink / raw)
To: u-boot
On Mon, 2015-07-06 at 23:45 +0200, Marek Vasut wrote:
> On Monday, July 06, 2015 at 11:25:35 PM, Scott Wood wrote:
> > On Fri, 2015-07-03 at 15:44 +0200, Marek Vasut wrote:
> > >
> > > This is what memalign(3) has
> > >
> > > to say:
> > >
> > > "
> > > The function posix_memalign() allocates size bytes and places the
> > > address of the allocated memory in *memptr. The address of the
> > > allo? cated memory will be a multiple of alignment, which must
> > > be a power of two and a multiple of sizeof(void *). If size is 0,
> > > then the value placed in *memptr is either NULL, or a unique pointer
> > > value that can later be successfully passed to free(3).
> > >
> > > The obsolete function memalign() allocates size bytes and returns a
> > > pointer to the allocated memory. The memory address will be a mul?
> > > tiple of alignment, which must be a power of two.
> > > "
> >
> > posix_memalign() does not exist in U-Boot, and it's not clear to me why
> > memalign() should be considered obsolete. Is the difference just the
> > ability to return -EINVAL?
>
> The args are also totally different.
...in order to accommodate returning an error value.
-Scott
^ permalink raw reply [flat|nested] 28+ messages in thread
* [U-Boot] [PATCH 7/8] mtd/nand/ubi: assortment of alignment fixes
2015-07-06 21:50 ` Scott Wood
@ 2015-07-06 21:57 ` Marek Vasut
0 siblings, 0 replies; 28+ messages in thread
From: Marek Vasut @ 2015-07-06 21:57 UTC (permalink / raw)
To: u-boot
On Monday, July 06, 2015 at 11:50:39 PM, Scott Wood wrote:
> On Mon, 2015-07-06 at 23:45 +0200, Marek Vasut wrote:
> > On Monday, July 06, 2015 at 11:25:35 PM, Scott Wood wrote:
> > > On Fri, 2015-07-03 at 15:44 +0200, Marek Vasut wrote:
> > > > This is what memalign(3) has
> > > >
> > > > to say:
> > > >
> > > > "
> > > > The function posix_memalign() allocates size bytes and places the
> > > > address of the allocated memory in *memptr. The address of the
> > > > allo? cated memory will be a multiple of alignment, which must
> > > > be a power of two and a multiple of sizeof(void *). If size is 0,
> > > > then the value placed in *memptr is either NULL, or a unique pointer
> > > > value that can later be successfully passed to free(3).
> > > >
> > > > The obsolete function memalign() allocates size bytes and returns a
> > > > pointer to the allocated memory. The memory address will be a mul?
> > > > tiple of alignment, which must be a power of two.
> > > > "
> > >
> > > posix_memalign() does not exist in U-Boot, and it's not clear to me why
> > > memalign() should be considered obsolete. Is the difference just the
> > > ability to return -EINVAL?
> >
> > The args are also totally different.
>
> ...in order to accommodate returning an error value.
... of course.
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 28+ messages in thread
* [U-Boot] [PATCH 8/8] tftp.c: fix CONFIG_TFTP_TSIZE for small files
2015-07-01 23:04 [U-Boot] [PATCH 0/8] assortment of fixes/enhancements Marcel Ziswiler
` (6 preceding siblings ...)
2015-07-01 23:04 ` [U-Boot] [PATCH 7/8] mtd/nand/ubi: assortment of alignment fixes Marcel Ziswiler
@ 2015-07-01 23:04 ` Marcel Ziswiler
2015-07-02 5:54 ` Marek Vasut
7 siblings, 1 reply; 28+ messages in thread
From: Marcel Ziswiler @ 2015-07-01 23:04 UTC (permalink / raw)
To: u-boot
From: Max Krummenacher <max.krummenacher@toradex.com>
CONFIG_TFTP_TSIZE should limit a tftp downloads progress to 50 '#'
chars. Make this work also for small files.
If the file size is small, i.e. smaller than 2 tftp block sizes the
number of '#' can get much larger. i.e. with a 1 byte file 65000
characters are printed, with a 512 byte file around 500.
When using CONFIG TFTP BLOCKSIZE together with CONFIG_IP_DEFRAG the
issue is more notable.
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
---
net/tftp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/tftp.c b/net/tftp.c
index 3e99e73..1853fe7 100644
--- a/net/tftp.c
+++ b/net/tftp.c
@@ -249,6 +249,8 @@ static void show_block_marker(void)
if (tftp_tsize) {
ulong pos = tftp_cur_block * tftp_block_size +
tftp_block_wrap_offset;
+ if(pos > tftp_tsize)
+ pos = tftp_tsize;
while (tftp_tsize_num_hash < pos * 50 / tftp_tsize) {
putc('#');
--
1.9.3
^ permalink raw reply related [flat|nested] 28+ messages in thread* [U-Boot] [PATCH 8/8] tftp.c: fix CONFIG_TFTP_TSIZE for small files
2015-07-01 23:04 ` [U-Boot] [PATCH 8/8] tftp.c: fix CONFIG_TFTP_TSIZE for small files Marcel Ziswiler
@ 2015-07-02 5:54 ` Marek Vasut
0 siblings, 0 replies; 28+ messages in thread
From: Marek Vasut @ 2015-07-02 5:54 UTC (permalink / raw)
To: u-boot
On Thursday, July 02, 2015 at 01:04:53 AM, Marcel Ziswiler wrote:
> From: Max Krummenacher <max.krummenacher@toradex.com>
>
> CONFIG_TFTP_TSIZE should limit a tftp downloads progress to 50 '#'
> chars. Make this work also for small files.
>
> If the file size is small, i.e. smaller than 2 tftp block sizes the
> number of '#' can get much larger. i.e. with a 1 byte file 65000
> characters are printed, with a 512 byte file around 500.
>
> When using CONFIG TFTP BLOCKSIZE together with CONFIG_IP_DEFRAG the
> issue is more notable.
>
> Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
> Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> ---
> net/tftp.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/net/tftp.c b/net/tftp.c
> index 3e99e73..1853fe7 100644
> --- a/net/tftp.c
> +++ b/net/tftp.c
> @@ -249,6 +249,8 @@ static void show_block_marker(void)
> if (tftp_tsize) {
> ulong pos = tftp_cur_block * tftp_block_size +
> tftp_block_wrap_offset;
> + if(pos > tftp_tsize)
Nitpick:
if[SPACE](...
Reviewed-by: Marek Vasut <marex@denx.de>
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 28+ messages in thread