Hi Tom,
On Thu, Aug 9, 2012 at 9:31 PM, Tom Rini wrote:
> Make the lowlevel_init function that these platforms have which just
> sets up the stack and calls a C function available to all armv7
> platforms. As part of this we change some of the macros that are used
> to be more clear. Previously
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
>> ---
>> .gitignore |4
>> 1 files changed, 4 insertions(+), 0 deletions(-)
>>
>> diff --git a/.gitignore b/.gitig
> -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 a
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
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 th
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 appear
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
> > ena
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 =?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
>
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 <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
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 wer
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
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
> merg
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 me
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
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
>
> --
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.
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.)
> >
>
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 ethadd
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
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 indi
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
> > sh
Acked-by: Nikita Kiryanov
On Sun, Aug 12, 2012 at 11:12 AM, Igor Grinberg wrote:
> 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
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 i
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.),
>
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 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'
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 exp
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 throug
30 matches
Mail list logo