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
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 en
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 pro
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
U-Boot
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 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
http://lists.denx.de/mailman/lis
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 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
> 2013/2/28 Damien HUANG
>
> 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
dropped by the
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 ((curclu
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)
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 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
Marek Vasut 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 array.
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 p
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 r
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 wat
Joakim Tjernlund/Transmode wrote on 2013/01/24 09:58:35:
> > >
> > > Me neither, there is not a lot details. I do recall having other
> problems with
> > > wait_ticks from time to time, sometimes the TB counter(mtfbu, mftb in
> get_ticks)
> > > would not increment so one would just loop forever 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 wo
> 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 arch/
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 see
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 l
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 worke
indicate "by chance", 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
>
&g
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
first_boot=
25 matches
Mail list logo
