On 11/08/2012 19:59, Benoît Thébaudeau wrote:
Hi Benoît,
That could be a solution. However, that would have to be done for i.MX25 and
i.MX35 too (I have patches to add/fix eSDHC support for these that I will post
shortly), which means more duplicated code that should rather be centralized
If this is not the correct place to post this, please direct to a more
appropriate place, as most of the traffic I see on this list is for commits and
patches.
I am currently working with a device that has lost its boot loader and
attempting to reload the device.
I have full debug access
Hi Jeroen,
Thanks for the patch!
On 08/10/12 23:06, Jeroen Hofstee wrote:
Switching back to nandecc sw fails to write correctly. A fix for this is
already mentioned in the thread below, lets fix it.
mentioned in http://lists.denx.de/pipermail/u-boot/2012-February/119002.html
I would expect
Dear Mike Frysinger,
In message 201208111348.25632.vap...@gentoo.org you wrote:
- This variable is readonly.
why don't we fix it to be read-only ?
Actually it is auto-restoring. Any value written to it will be lost
at the next reset, when the variable will be siigned it's
Dear =?utf-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?=,
In message 2028294275.2280404.1344620768178.javamail.r...@advansee.com you
wrote:
The board revision can be a useful env var, like its serial number.
It can be useful, but it appears not many boards needed it so far,
so I suggest we leave as is;
Dear =?utf-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?=,
In message 2098801045.2303154.1344708456703.javamail.r...@advansee.com you
wrote:
I had thought about that, but there is an issue. main_loop() sets this env
var,
so if ver is made read-only and the env is stored somewhere (NVRAM, etc.),
then
Dear =?utf-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?=,
In message 1666183421.2304101.1344712292461.javamail.r...@advansee.com you
wrote:
I have searched such a usage in the tree, but did not find any, so this should
not break anything.
You cannot expect to see the real, production environments in
Acked-by: Nikita Kiryanov nik...@compulab.co.il
On Sun, Aug 12, 2012 at 11:12 AM, Igor Grinberg grinb...@compulab.co.ilwrote:
Hi Jeroen,
Thanks for the patch!
On 08/10/12 23:06, Jeroen Hofstee wrote:
Switching back to nandecc sw fails to write correctly. A fix for this is
already
Hi Stefano,
On 08/12/2012 8:25, Stefano Babic wrote:
On 11/08/2012 19:59, Benoît Thébaudeau wrote:
Hi Benoît,
That could be a solution. However, that would have to be done for
i.MX25 and
i.MX35 too (I have patches to add/fix eSDHC support for these that
I will post
shortly), which
Dear Wolfgang Denk,
I had thought about that, but there is an issue. main_loop() sets
this env var,
so if ver is made read-only and the env is stored somewhere (NVRAM,
etc.), then
after an update of U-Boot with a newer version (stored env
untouched), ver will
still indicate the
Dear Wolfgang Denk,
I have searched such a usage in the tree, but did not find any, so
this should
not break anything.
You cannot expect to see the real, production environments in the
mainline source tree.
Right, but the same applied to serial# and ethaddr when they were added, except
Dear Wolfgang Denk,
I have searched such a usage in the tree, but did not find any,
so
this should
not break anything.
You cannot expect to see the real, production environments in the
mainline source tree.
Right, but the same applied to serial# and ethaddr when they were
On Sunday 12 August 2012 09:58:24 Benoît Thébaudeau wrote:
Dear Wolfgang Denk,
The correct fix for this would be the introduction of variable types,
including flags like read-only (as for serial# or ethaddr) or
volatile (i. e. not included in saveenv, as for filesize etc.)
I have been
On Sunday 12 August 2012 10:02:48 Benoît Thébaudeau wrote:
Dear Wolfgang Denk,
I have searched such a usage in the tree, but did not find any, so
this should
not break anything.
You cannot expect to see the real, production environments in the
mainline source tree.
Right, but
On 08/11/2012 09:21 PM, J.Hwan Kim wrote:
Hi, everyone
Is there any limit of file size for tftpboot?
I have a problem downloading the file of which file size is 65MB.
The procedure stops in the middle of downloading.
Thanks in advnace.
Best Regards,
J.Hwan Kim
Dear Mike Frysinger,
I have searched such a usage in the tree, but did not find any,
so
this should
not break anything.
You cannot expect to see the real, production environments in the
mainline source tree.
Right, but the same applied to serial# and ethaddr when
Dear =?utf-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?=,
you wrote:
If it's ack'ed, why does nobody apply it? What is the normal life cycle
of
patches like these that don't have a custodian?
And I explained to you:
They end on my table, and probably get merged when the next merge
window
Dear =?utf-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?=,
In message 1605401818.2306523.1344722631605.javamail.r...@advansee.com you
wrote:
Oh, great! This is good news. Thanks for the information. The merge window
should be renamed to submission window or something since it is not really a
merge
Dear Wolfgang Denk,
Dear =?utf-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?=,
you wrote:
If it's ack'ed, why does nobody apply it? What is the normal
life cycle of
patches like these that don't have a custodian?
And I explained to you:
They end on my table, and probably get
Dear =?utf-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?=,
In message 1642597694.2324115.1344780168514.javamail.r...@advansee.com you
wrote:
You cannot expect to see the real, production environments in the
mainline source tree.
Right, but the same applied to serial# and ethaddr when they were added,
Dear =?utf-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?=,
In message 1323086777.2324156.1344780597072.javamail.r...@advansee.com you
wrote:
Anyway, when you will have implemented read-only and volatile flags for env
vars, this patch will no longer be needed. But with the current code, there is
no way
Dear Jerry Van Baren,
In message 5027ceb1.1070...@gmail.com you wrote:
Probably what Mike said. Note that 64MB is 0x4000 and your load
No. 64 MiB is 0x0400; 0x4000 is 1024 MiB.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev
Dear =?utf-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?=,
In message 383502175.2331918.1344791463023.javamail.r...@advansee.com you
wrote:
OK. Actually, the only reason for which I need this patch is to make a
variable
read-only, and the only reason for which you reject it is because you fear
that
On 08/12/2012 11:06 PM, Wolfgang Denk wrote:
Dear =?utf-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?=,
In message 1323086777.2324156.1344780597072.javamail.r...@advansee.com you
wrote:
Anyway, when you will have implemented read-only and volatile flags for env
vars, this patch will no longer be needed.
Dear Wolfgang Denk,
OK. Actually, the only reason for which I need this patch is to
make a variable
read-only, and the only reason for which you reject it is because
you fear that
it breaks something.
So we could add a config like CONFIG_BOARD_REV_RO_VARIABLE to
enable the code in
Dear Jim Shimer,
While tuning ext2load, we found that usb_test_unit_ready was being called
every block read. We compared the usb block storage to the scsi block
storage cmd_scsi.c, and found that the scsi device was only calling its
scsi_setup_test_unit_ready() during scsi_can. It appears
On Sunday 12 August 2012 13:11:03 Benoît Thébaudeau wrote:
OK. Actually, the only reason for which I need this patch is to make a
variable read-only, and the only reason for which you reject it is because
you fear that it breaks something.
and because it bloats the codebase for 0 gain for the
Hi,
My you boot does not support if statement in it command line.
I thought it did. Is there some configuration setting that is required
here?
Bud Miljkovic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
-Original Message-
From: Holger Brunck [mailto:holger.bru...@keymile.com]
Sent: 09 August 2012 17:08
To: u-boot@lists.denx.de
Cc: Holger Brunck; Prafulla Wadaskar; Valentin Longchamp; Gerlando
Falauto
Subject: [PATCH] arm/km: remove unused code
For some reasons we had an own
On 09.08.2012 23:26, Wolfgang Denk wrote:
Dear Timo Ketola,
In message 1334223234-23383-4-git-send-email-t...@exertus.fi you wrote:
Signed-off-by: Timo Ketola t...@exertus.fi
---
.gitignore |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/.gitignore
30 matches
Mail list logo
