Re: [U-Boot] [PATCH] tools: fix FIT image with ramdisk
Hi Tom, > I've re-worded this as: > common/image.c: Fix regression with ramdisk load/entry points in FIT > > A FIT image with a ramdisk that sets the entry or load points to 0x0 > must be treated as meaning "leave in place" and NOT "relocate to 0x0". > This regression was introduced in a51ec63. Thanks! :) Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: Use well-known descriptor sizes when parsing configuration
Hi Julius, On Fri, 12 Jul 2013 17:30:16 -0700, Julius Werner wrote: > The existing USB configuration parsing code relies on the descriptors' > own length values when reading through the configuration blob. Since the > size of those descriptors is always well-defined, we should rather use > the known sizes instead of trusting device-provided values to be > correct. Also adds some safety to potential out-of-order descriptors. Question from the offspring of an USB ignoramus and a Devil's advocate: if the device, rather than relying on well-known sizes, provides its own values for lengths, maybe it's because it will let you read or write only that much, and if you try to read more, you might put the device in an unclean, or worse, non-functional, state? In that case, trying to read a well-known length instead could cause more issues than reading the device-maker-specified length, could it not? BTW, what is the real-world issue (hardware, conditions, expected outcome, actual outcome) which made this change needed? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm:exynos:fix: Fix clock calculation for Exynos4210 based targets.
Dear Tom, Please apply this patch to u-boot directly. I wish that this fix will be merged before release. On 13 July 2013 02:08, Lukasz Majewski wrote: > Provide proper setting for the APLL fout frequency calculation for > Exynos4 based targets (especially Exynos4210 - Trats board). > > > Signed-off-by: Lukasz Majewski > Cc: Minkyu Kang > --- > arch/arm/cpu/armv7/exynos/clock.c |9 - > 1 file changed, 4 insertions(+), 5 deletions(-) > > Acked-by: Minkyu Kang Thanks for patch. Minkyu Kang. -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools: fix FIT image with ramdisk
Am 12/07/2013 23:24, schrieb Tom Rini: > On Fri, Jul 12, 2013 at 03:09:23PM +0200, Stefano Babic wrote: > >> Booting a FIT image containing a ramdisk, >> the ramdisk is loaded at address 0x0 that causes >> bus errors for architectures that do not have >> RAM starting at address zero. >> >> Signed-off-by: Stefano Babic > > I've re-worded this as: > common/image.c: Fix regression with ramdisk load/entry points in FIT > > A FIT image with a ramdisk that sets the entry or load points to 0x0 > must be treated as meaning "leave in place" and NOT "relocate to 0x0". > This regression was introduced in a51ec63. > Great ! > And applied to u-boot/master, thanks! > Thanks ! Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ppc: mpc8323erdb: Fix compiler warning
Fix the following warning:
mpc8323erdb.c: In function 'mac_read_from_eeprom':
mpc8323erdb.c:198:3: warning: dereferencing type-punned pointer will break
strict-aliasing rules [-Wstrict-aliasing]
if (crc32(crc, buf, 24) == *(unsigned int *)&buf[24]) {
^
Size remains unchanged after and before fix:
textdata bss dec hex filename
206977 18748 23344 249069 3cced ./u-boot
Note the fix is the crudest possible, but also least intrusive.
Signed-off-by: Marek Vasut
Cc: Michael Barkowski
Cc: Tom Rini
Cc: Wolfgang Denk
---
board/freescale/mpc8323erdb/mpc8323erdb.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/board/freescale/mpc8323erdb/mpc8323erdb.c
b/board/freescale/mpc8323erdb/mpc8323erdb.c
index f29b2f4..710589f 100644
--- a/board/freescale/mpc8323erdb/mpc8323erdb.c
+++ b/board/freescale/mpc8323erdb/mpc8323erdb.c
@@ -184,7 +184,8 @@ void ft_board_setup(void *blob, bd_t *bd)
#if defined(CONFIG_SYS_I2C_MAC_OFFSET)
int mac_read_from_eeprom(void)
{
- uchar buf[28];
+ uint32_t bbuf[28 / 4];
+ uchar *buf = (uchar *)bbuf;
char str[18];
int i = 0;
unsigned int crc = 0;
@@ -195,7 +196,7 @@ int mac_read_from_eeprom(void)
printf("\nEEPROM @ 0x%02x read FAILED!!!\n",
CONFIG_SYS_I2C_EEPROM_ADDR);
} else {
- if (crc32(crc, buf, 24) == *(unsigned int *)&buf[24]) {
+ if (crc32(crc, buf, 24) == bbuf[24 / 4]) {
printf("Reading MAC from EEPROM\n");
for (i = 0; i < 4; i++) {
if (memcmp(&buf[i * 6], "\0\0\0\0\0\0", 6)) {
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/6] Enhance support for BeagleBone Black
Hi, Am 2013-07-11 15:54, schrieb Justin Waters: > Justin Waters (6): > am335x_evm: Make NAND support modular > am335x_evm: Add command line editing > am335x_evm: Rework bootcmd to handle two MMC devs > Add additional MLO images to .gitignore > am335x_evm: Add support for eMMC environment > am335x_evm: Add am335x_boneblack variant Applied your patches on v2013.07-rc3 and compiled the beaglebone target. Works fine on my BeagleBone Black. Tested-by: Stefan Agner -- Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools: fix FIT image with ramdisk
Dear Tom Rini, In message <20130712212416.GV13531@bill-the-cat> you wrote: > > A FIT image with a ramdisk that sets the entry or load points to 0x0 > must be treated as meaning "leave in place" and NOT "relocate to 0x0". Why is this the case? 0x0 could be a valid address on some systems. If we need a special address that "cannot exist", we should rather use the last address in the addressable range (i. e. (void *)(~0)). Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Imitation is the sincerest form of plagarism. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools: fix FIT image with ramdisk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/13/2013 07:21 AM, Wolfgang Denk wrote: > Dear Tom Rini, > > In message <20130712212416.GV13531@bill-the-cat> you wrote: >> >> A FIT image with a ramdisk that sets the entry or load points to >> 0x0 must be treated as meaning "leave in place" and NOT "relocate >> to 0x0". > > Why is this the case? 0x0 could be a valid address on some > systems. If we need a special address that "cannot exist", we > should rather use the last address in the addressable range (i. e. > (void *)(~0)). True enough, but we're not back to the behaviour of the previous release. In fact, this makes me wonder if there's not a solution to the problem I had before of wanting to just leave everything in-place (so that we could have a FIT image with an ARM multi-platform kernel that would be usable on multiple platforms without multiple copies of the zImage). - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR4bJiAAoJENk4IS6UOR1WMbgP/jNjjMJbAPNBLTlyPGPZxK92 K2tBEXezsaWV53MGVTaHt6ZcrpOhSo7j2DP7lO0/j9nH5TM9mJ6tWDKzZxaopMoT chyyDEN38IaY1LiklwqwyHj8tOCIbCGLtaG0vplHeodE8UFgmBU4QMpBqVvwBids vtNAjQy0MHI5LXDTY0OpVNzVIQD2Rm2y3xyPnRsuUWoY5BtGmcxs1X5KyoCKbQ3J qtG0Eb2nP2fuADSgOOTtA1CQRKrKoSk7k2r8fVPzZ85S+8goro8n+a7AgWhuvU+C WrGKxrlejbUejh7JZt0HGpNr1iIos+7+V3G5PP8pel4JOkaD/jdBgf4UgN2sADXM JKvkd65jiIRvW4Axw+tZ8omHzXRYPYNe6wgH9CKDtUbSWnRVdvXvtF78XEIMi1XX iDOAZVca+3qsrx0hJTc34++C2rBsONa5Yd88GwsNwb9BZufqs+uyhD0N19xBqjFC pd9cJwKuL1P7T7IEHP5N1anerJPNfUCtvZv5RnWKzZBGpvjfZUeZ2PcS2/nuXEHZ rj3jX9PvzGO1L/mgYCMQ39/6zH5Wge70ojbMkn/Lh+cWWZb4Y7LuUfGINH/XTjrb H+/OQ2RuDPje04X6e3ws1vAXwy8NF8mltcLwnusKkcqf3VhhTHoOOm/OHyjTLw5a tf4c94PHN023tdpUtsR1 =G4tN -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools: fix FIT image with ramdisk
On 07/13/2013 05:21 AM, Wolfgang Denk wrote: > Dear Tom Rini, > > In message <20130712212416.GV13531@bill-the-cat> you wrote: >> >> A FIT image with a ramdisk that sets the entry or load points to 0x0 >> must be treated as meaning "leave in place" and NOT "relocate to 0x0". > > Why is this the case? 0x0 could be a valid address on some systems. > If we need a special address that "cannot exist", we should rather use > the last address in the addressable range (i. e. (void *)(~0)). For the kernel, we created a special image type for "no relocation"; IH_TYPE_KERNEL_NOLOAD. Is an equivalent needed to the initrd? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools: fix FIT image with ramdisk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/13/2013 10:26 PM, Stephen Warren wrote: > On 07/13/2013 05:21 AM, Wolfgang Denk wrote: >> Dear Tom Rini, >> >> In message <20130712212416.GV13531@bill-the-cat> you wrote: >>> >>> A FIT image with a ramdisk that sets the entry or load points >>> to 0x0 must be treated as meaning "leave in place" and NOT >>> "relocate to 0x0". >> >> Why is this the case? 0x0 could be a valid address on some >> systems. If we need a special address that "cannot exist", we >> should rather use the last address in the addressable range (i. >> e. (void *)(~0)). > > For the kernel, we created a special image type for "no > relocation"; IH_TYPE_KERNEL_NOLOAD. Is an equivalent needed to the > initrd? No, because what we have today is insufficient for the kernel, you still have to specify the load/entry point, in FIT at least, even on NOLOAD. I'd have sworn at least, I couldn't find a way to get around this problem before... - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR4hM4AAoJENk4IS6UOR1WKOUP/1IVfyWujtl1d5EIqLWRbaRe BxkIafbsWE8MgmGHtDLhy/snJqHvi57Bs/egkV+mrhfOYmQIjYWOylKCyRhIXW/7 s+b0fLqo5y5fMjdtANdHIU0Jp6j7tkT+dIkU5SPWsGp38uHTDhP9TuDtwHtF4Brm uMhdxCT72x+VzyzwsUXRj0BY5LhJJULmOEHTm0t40Gs3wNCKx/SQKKOrNGwLH9n9 VzLlPZGX8ABKHdEcSjGExEJ1vXV5ulvKFKhUkSURoM0R9qG3/Esvw4nsnkLiobEK Bh1Ja6jX9uGR2afUS8JSgem6SYl/8wnBvNGMjWHR5gPNeY4Ujhv/Q4fc2qYhIJTa qHIZb+lMSlQCe7qBD3JaTeGfuPIQfVgLDQqqrLNKLLr47me8Vw8gMDf3PK9lKuwd 8H7zTlMvdUM3he+QrI4capLSmfYzNkgmfK2HC/V3aswJ38eJUrw/jIRRz4py/biK E1gz0dCAbVvlh7waN72szapFsZXT6/2bqLg1HQQM6H/Hsf18fA8XxkVCO7C29HJo 1e90TV0DYJ5qENWY6BFyI7B+f6wtWx0JP23tlcmEciag/nwd6TkSaf03X8mDKlhY yRs56ejWpogg/T5PIjj/L332yVwPuzsvZTWGTtAsV+C2V2xu7oo3esgvLzDbBmXO rXuYrHDKoRQ5+jnBE1aa =dxLu -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
