Hi Michael,
Michael Heimpold [m...@heimpold.de] wrote:
fw_setenv state=2
dd if=... of=/dev/mmcblk0...
fw_setenv state=1
How about:
fw_setenv state 1 sync
BR // Mats
___
U-Boot mailing list
U-Boot@lists.denx.de
Hi Robert, Albert,
Robert P. J. Day wrote:
just to be clear, i have no strong opinion on this either way, but
my understanding is that source files with the name of common/cmd_*.c
typically define at least one u-boot command with the U_BOOT_CMD macro.
as far as i can tell, cmd_disk.c is
Hi Albert,
Albert ARIBAUD wrote:
Maybe, but the problem you state is not about cmd_disk (or I am
missing the point). USB commands are in USB related files, e.g.
do_usbboot() is in cmd_usb.c, so that's where a conditional should be
put if you want to compile the command out, rather than in
Hi Jean,
Accidentally I'm also currently debugging fat_write.
I have a problem with USB EHCI time-outs while writing but so far I have not
found a cure.
What I have found is this rather strange code in fat_write.c:
~line 659:
if (fat_val == 0xfff || fat_val == 0x)
Jean Louis wrote:
Many thanks for your great help, I change the code as you say by :
~line 659:
if ((fat_val == 0xfff mydata-fatsize == 32) ||
(fat_val == 0x mydata-fatsize == 16))
break;
~line 904:
if ((curclust =
2013/2/28 Damien HUANG damien...@hotmail.com
After investigation, I believe the problem can be fixed at function
set_cluster within file fat_write.c under directory /fs/fat (patch file
was attached).
Hi Damien,
I found no trace of your patch in the mailing list (perhaps the attachment was
Dear Wolfgang,
I havn't seen the scripts of Alexandre but it sounds something like what
we have already implemented.
Wolfgang Denk wrote:
Please note that this is a feature standardized for example in the
Open Source Development Labs Carrier Grade Linux Requirements
Definition, which
Hi!
Look in drivers/serial/serial_ns16550.c
Changing ..COM3 to UART_BASE4 seems a bit unorthodox, Try changing to:
#define CONFIG_SYS_NS16550_COM4 UART4_BASE COM4!!!
#define CONFIG_CONS_INDEX 4
BR // Mats
___
U-Boot mailing list
Hi Tom,
Tom Rini wrote:
If you have specific bugfixes, please hit me up and CC the list.
[U-Boot] powerpc/lib: fix unsafe register handling in wait_ticks
(2012-01-27)
Out of curiosity and perhaps to have better success in the future; what is the
reason that this patch hasn't made it into the
Hi Ruud,
Ruud Commandeur wrote:
Once the size of the set_cluster call equals 0, the mmc command is
incomplete and times out. In the earlier reported problem, a patch is
mentioned, but not available for dowload here. Also in the latest
versions of the git repository I could not find a patch
Hi!
I have a system using a MPC5125 processor working fine using U-Boot 2012.07. I
have based my board adaption etc on the mpc5121ads board and also patched the
necessary parts of the serial port driver.
Now when I'm trying to migrate to U-Boot 2013.01 I face problems with a sudden
hang. I
Now when I'm trying to migrate to U-Boot 2013.01 I face problems with a
sudden hang. I see console output until the Flash: from
arch/powerpc/lib/board.c::board_init_r() but nothing more until the board
reboots on a watchdog reset after 30s.
Found that it was looping endlessly in
Dear Wolfgang Denk,
Found that it was looping endlessly in
arch/powerpc/lib/ticks.S::wait_ticks(). Reverting commit ppc: Create a
stack frame for wait_ticks() made everything work again.
This makes no sense to me - especially as it works on all other
systems.
If you say it works, it
Joakim Tjernlund/Transmode wrote on 2013/01/24 09:21:
Looking at the watchdog impl. I see it can be normal C code. This makes
wait_ticks unsafe
(even before my patch) as wait_ticks relies on r6 and r7 (and with my
patch r0 too)
to be unmodified.
Yes!
I can see in the assembly from my
with.
Best regards,
Mats Kärrman
--- a/arch/powerpc/lib/ticks.S
+++ b/arch/powerpc/lib/ticks.S
@@ -50,19 +50,24 @@ wait_ticks:
stwur1, -16(r1)
mflrr0 /* save link register */
stw r0, 20(r1) /* Use r0 or GDB will be unhappy */
- mr r7, r3
If watchdog is enabled, the arch/powerpc/lib/ticks.S::wait_ticks() function
calls the function specified by the WATCHDOG_RESET macro.
The wait_ticks function depends on the registers r0, r6 and r7 being
preserved however that is not guaranteed, e.g. if the reset function is a
C function this will
Marek Vasut marex at denx.de wrote:
In case a function argument is known/fixed size array in C, the argument is
still decoyed as pointer instead ( T f(U n[k]) ~= T fn(U *n) ) and therefore
calling sizeof on the function argument will result in the size of the
pointer,
not the size of the
Hi Alexey,
on: Monday, December 09, 2013 3:34 PM, Alexey Smishlayev wrote:
I would like to flash the environment variable values to my board,
rather than setting them at the prompt. I've founa a tool mkenvimage is
made specially for that. I used it to create a binary image of the
U-Boot
On: Tuesday, December 10, 2013 1:32 PM, Alexey Smishlayev wrote:
I'm not sure, if that's not something simple, that's why I wrote to this
list. I just don't know every little detail about using U-Boot.
I was thinking something like: [flash-sector-size] =
[U-Boot-configured-env-size]
and you
On Thursday, October 10, 2013 12:48 PM, Wolfgang Denk wrote:
This would allow to easily find out which components have actually
been built into the final product, so which licenses apply tho that.
You don't have to bother about license terms for code that you don't
actually use in your
Hi,
I used to have a working setup using U-Boot 2009.03 before upgrading to U-Boot
2012.07. The problem I'm facing is related to the escaping policies of
lib/hashtable.c.
What I did before was for example having something like this in my default
environment:
bootcmd=run first_boot
, or was it something else that was not
correct?
BR // Mats
From: Wolfgang Denk [w...@denx.de]
Sent: Thursday, November 01, 2012 9:00 PM
To: Mats Kärrman
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] hashtable lib and escaping
Dear Mats Kärrman,
In message
Thanks for your advice.
I did not say so, but I'm primarily relying on the default environment and not
so much the command line. I see now how to make this work by providing the
necessary amount of backslash'es. Maybe it was your statement:
THis syntax has never been correct. If it ever
Hi,
Any chance that you are not using the hush shell, but the old, simple
command interpreter?
Yup, a 100% chance. As I wrote before I rely only on the default environment,
apart from development work, so I removed everything I don't need, hush
included.
With some luck I will have time to
24 matches
Mail list logo
