[U-Boot-Users] RE: U-Boot-Users digest, Vol 1 #1593 - 11 msgs
atul.sabharwal at exgate.tek.com
atul.sabharwal at exgate.tek.com
Tue Dec 6 19:30:30 CET 2005
For the 870 PPC processors, there is a check get_immr(0xFFFF) > 0x800 to
decide if it's a 866 and above processors. We are using IMMR at offset
0?
The comment says that these processors have IMMR lower half at a higher
address? The PLL's I am setting were working before. Any idea what
might
Be the problem with this check ?
What does get_immr() return ? Value of IMMR or value of a register at
an offset n from value of IMMR ? I am assuming the latter.
--
Atul
-----Original Message-----
From: u-boot-users-admin at lists.sourceforge.net
[mailto:u-boot-users-admin at lists.sourceforge.net] On Behalf Of
u-boot-users-request at lists.sourceforge.net
Sent: Wednesday, November 02, 2005 5:53 AM
To: u-boot-users at lists.sourceforge.net
Subject: U-Boot-Users digest, Vol 1 #1593 - 11 msgs
Send U-Boot-Users mailing list submissions to
u-boot-users at lists.sourceforge.net
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/u-boot-users
or, via email, send a message with subject or body 'help' to
u-boot-users-request at lists.sourceforge.net
You can reach the person managing the list at
u-boot-users-admin at lists.sourceforge.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of U-Boot-Users digest..."
Today's Topics:
1. Re: NetConsole tstc problems (Stefan Roese)
2. Re: NetConsole tstc problems (Wolfgang Denk)
3. Re: Low-boot configuration for MPC8272ADS (Bastos Fernandez
Alexandre)
4. Re: Low-boot configuration for MPC8272ADS (Yuli Barcohen)
5. custom mpc83xx based board support (Boris)
6. Re: Low-boot configuration for MPC8272ADS (Dmytro Bablinyuk)
7. RE: custom mpc83xx based board support (Chu hanjin-r52514)
8. Re: custom mpc83xx based board support (Wolfgang Denk)
9. Re: Help about tftp download (Jerry Van Baren)
10. Re: NAND flash support (Ladislav Michl)
11. [PATCH] Add ECC check to MIP405 specific Memtest (Denis Peter)
--__--__--
Message: 1
From: Stefan Roese <sr at denx.de>
To: u-boot-users at lists.sourceforge.net
Subject: Re: [U-Boot-Users] NetConsole tstc problems
Date: Wed, 2 Nov 2005 08:51:57 +0100
Cc: Brian Prodoehl <bjprodoehl at uwalumni.com>
Hi Brian,
On Tuesday 01 November 2005 22:19, Brian Prodoehl wrote:
> Has anyone else experienced problems with NetConsole's tstc? In
> particular, defining CONFIG_BOOT_RETRY_TIME makes NetConsole almost
> unusable for me, because then readline() in main.c blocks on tstc and
the
> result (for me, at least) is that NetConsole accepts a character every
> second or so.
Depending on your network driver, tstc() can take pretty long. I
experienced a
similar problem in sleep() using tstc() via ctrlc(). I solved this
problem
using a "better" timeout mechanism with get_timer(). This could probably
help
here too.
> For everything that doesn't depend on tstc, NetConsole works
> beautifully for me. I'm just wondering if anyone else has seen
problems, or
> if anyone has suggestions on how to make tstc less of a show-stopper
> (something I haven't been able to accomplish).
Take a look at the sleep() fix:
http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=commit;h=c4c13df284
cb06156c16ee6aef49b8d23be3fadd
Best regards,
Stefan
--__--__--
Message: 2
To: Brian Prodoehl <bjprodoehl at uwalumni.com>
Cc: u-boot-users at lists.sourceforge.net
From: Wolfgang Denk <wd at denx.de>
Subject: Re: [U-Boot-Users] NetConsole tstc problems
Date: Wed, 02 Nov 2005 08:59:28 +0100
In message <20051101151924.c9ww4408kw8ososc at secure.uwalumni.com> you
wrot=
e:
> Has anyone else experienced problems with NetConsole's tstc? In
partic=
ular,
> defining CONFIG_BOOT_RETRY_TIME makes NetConsole almost unusable for
me=
,
> because then readline() in main.c blocks on tstc and the result (for
me=
, at
> least) is that NetConsole accepts a character every second or so. For
> everything that doesn't depend on tstc, NetConsole works beautifully
fo=
r me.=20
> I'm just wondering if anyone else has seen problems, or if anyone has
> suggestions on how to make tstc less of a show-stopper (something I
hav=
en't
> been able to accomplish).
Please use current code. A fix inthis area has been checked in a
couple of days ago.
Best regards,
Wolfgang Denk
--=20
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Of course there's no reason for it, it's just our policy.
--__--__--
Message: 3
From: Bastos Fernandez Alexandre <ALEBAS at televes.com>
To: "'u-boot-users at lists.sourceforge.net'"
<u-boot-users at lists.sourceforge.net>
Cc: "'DmytroBablinyuk<dmytro.bablinyuk at rftechnology.com.au>'"
<DmytroBablinyuk<dmytro.bablinyuk at rftechnology.com.au>>
Date: Wed, 2 Nov 2005 09:28:17 +0100
Subject: [U-Boot-Users] Re: Low-boot configuration for MPC8272ADS
Dmytro,
Please apply my patch with Flash HRCW for MPC8272ADS and try
then the MPC8272ADS_lowboot_config. This worked fine for me
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/19395
Best regards
Alex BASTOS
> -----Original Message-----
> To: u-boot-users at lists.sourceforge.net
> From: Dmytro Bablinyuk <dmytro.bablinyuk at rftechnology.com.au>
> Date: Wed, 02 Nov 2005 16:39:12 +1100
> Subject: [U-Boot-Users] Re: Low-boot configuration for MPC8272ADS
>
>
> > 1. I have updated (latest snapshot) u-boot:
> >
> > include/configs/MPC8260ADS.h
> >
> > #define CFG_HRCW_MASTER 0x0e72b605
> >
> > board/mpc8260ads/config.mk
> >
> > TEXT_BASE = 0xff800000
>
> 1. I tried 'make MPC8272ADS_lowboot_config' but it keeps resetting
with
> or without BDI attached (JP9 in position MEMORY, SW2 is FLASH ON).
>
> 2. Burn (to burn I need to move JP9 in position BCSR, otherwise it's
> just resetting)
> 8272>load
> 8272>unlock 0xff800000 0x40000 32
> 8272>erase 0xFF800000 BLOCK
> 8272>prog 0xFF800000 u-boot.bin BIN
>
> 3. Move JP9 in position MEMORY
>
> 4. Power cycle
>
> 5. Board keeps resetting with or without BDI.
>
> Can anybody help, please?
> Thank you
>
>
>
>
--__--__--
Message: 4
From: Yuli Barcohen <yuli at arabellasw.com>
Date: Wed, 2 Nov 2005 11:46:39 +0200
To: Dmytro Bablinyuk <dmytro.bablinyuk at rftechnology.com.au>
CC: u-boot-users at lists.sourceforge.net
Subject: Re: [U-Boot-Users] Low-boot configuration for MPC8272ADS
>>>>> Dmytro Bablinyuk writes:
Dmytro> I've seen one thread on this subject
Dmytro> http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/19224
Dmytro> and tried to repeat the same trick.
Dmytro> 1. I have updated (latest snapshot) u-boot:
Dmytro> include/configs/MPC8260ADS.h
Dmytro> #define CFG_HRCW_MASTER 0x0e72b605
IMHO this HRCW value is incompatible with MPC8272 (reserved fields are
not cleared, for example). Read the chip's manual to find correct values
(or copy them from BCSR-supplied HRCW).
Dmytro> board/mpc8260ads/config.mk
Dmytro> TEXT_BASE = 0xff800000
This is unnecessary because lowboot_config takes care of TEXT_BASE.
Dmytro> 2. Using BDI2000 (MPC8272ADS JP9 is configured to take Hard
Dmytro> Reset Configuration source from BCSR - otherwise board
Dmytro> keep reseting)
Probably because your BDI configuration file tries to use default IMMR
0x0F000000 while in fact the IMMR is 0xF0000000 due to the HRCW.
Dmytro> load
Dmytro> unlock 0xff800000 0x40000 32
Dmytro> erase 0xFF800000 BLOCK
Dmytro> prog 0xFF800000 u-boot.bin BIN
Dmytro> 3. Change JP9 to take Hard Reset Configuration from FLASH
Dmytro> (SW2 Boot Source is FLASH)
Dmytro> After power cycling BDI and board - the board keep reseting
Dmytro> (BDI is attached to the board).
See above.
Dmytro> Yes, 0xFFF00100 is not valid breakpoint anymore - I guess it
Dmytro> should be something like 0x00000100. But I suspect even I
Dmytro> got u-boot wrong BDI still should "freeze" the board instead
Dmytro> of reseting. Is anyone got BDI and u-boot working on
Dmytro> MPC8272ADS in low boot mode? Any help is really
Dmytro> appreciated. Below is output of BDI while reseting and BDI
Dmytro> init from config file.
[...deleted...]
--
========================================================================
Yuli Barcohen | Phone +972-9-765-1788 | Software Project Leader
yuli at arabellasw.com | Fax +972-9-765-7494 | Arabella Software, Israel
========================================================================
--__--__--
Message: 5
Date: Wed, 2 Nov 2005 01:54:54 -0800 (PST)
From: Boris <br_sing at yahoo.com>
To: u-boot-users at lists.sourceforge.net
Subject: [U-Boot-Users] custom mpc83xx based board support
Hello
I'm planning to prepare embedded Linux installation
on custom made board using mpc83xx CPU. As much as I
understand, to support it I'll need to write support
code in boards directory and header file in
include/configs. What are the chances that existing
code for mpc8349ads will work ? and if not can I cook
something based on this code with minimal changes ?
Another question is whether 2.6.* kernel configured
and built for mpc83xx family should work with any
board
based on this CPU or some board specific changes
must be done in the kernel ?
thanks,
Boris
__________________________________
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com
--__--__--
Message: 6
To: u-boot-users at lists.sourceforge.net
From: Dmytro Bablinyuk <dmytro.bablinyuk at rftechnology.com.au>
Date: Wed, 02 Nov 2005 20:56:13 +1100
Subject: [U-Boot-Users] Re: Low-boot configuration for MPC8272ADS
>
> Please apply my patch with Flash HRCW for MPC8272ADS and try
> then the MPC8272ADS_lowboot_config. This worked fine for me
>
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/19395
>
Thank you very much Alex,
As I understand, there is a patch that is not included in current u-boot
snapshot.
Sorry, could you please attach that patch or post a link (the link above
is a link to my original message).
Do you know why BDI keeps resetting - is it because HRCW couldn't be
read? What about if flash is blank?
Thank you
--__--__--
Message: 7
From: Chu hanjin-r52514 <Hanjin.Chu at freescale.com>
To: "'Boris'" <br_sing at yahoo.com>, u-boot-users at lists.sourceforge.net
Subject: RE: [U-Boot-Users] custom mpc83xx based board support
Date: Wed, 2 Nov 2005 18:09:07 +0800
You can take 8349ADS code as reference by make MPC8349ADS_config under
u-boot. This code has worked on MPC8349E Processor Card made by
Freescale. The 2.6 kernel also support this board. I think most of the
code dont need to be modified. You can compare the hardware between your
board and Freescale reference board.
Best Regards
Neil Chu
-----Original Message-----
From: u-boot-users-admin at lists.sourceforge.net
[mailto:u-boot-users-admin at lists.sourceforge.net]On Behalf Of Boris
Sent: Wednesday, November 02, 2005 5:55 PM
To: u-boot-users at lists.sourceforge.net
Subject: [U-Boot-Users] custom mpc83xx based board support
Hello
I'm planning to prepare embedded Linux installation
on custom made board using mpc83xx CPU. As much as I
understand, to support it I'll need to write support
code in boards directory and header file in
include/configs. What are the chances that existing
code for mpc8349ads will work ? and if not can I cook
something based on this code with minimal changes ?
Another question is whether 2.6.* kernel configured
and built for mpc83xx family should work with any
board
based on this CPU or some board specific changes
must be done in the kernel ?
thanks,
Boris
__________________________________
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
--__--__--
Message: 8
To: Boris <br_sing at yahoo.com>
Cc: u-boot-users at lists.sourceforge.net
From: Wolfgang Denk <wd at denx.de>
Subject: Re: [U-Boot-Users] custom mpc83xx based board support
Date: Wed, 02 Nov 2005 11:58:17 +0100
In message <20051102095455.97277.qmail at web36315.mail.mud.yahoo.com> you
w=
rote:
>=20
> I'm planning to prepare embedded Linux installation
> on custom made board using mpc83xx CPU. As much as I
> understand, to support it I'll need to write support=20
> code in boards directory and header file in=20
> include/configs. What are the chances that existing
> code for mpc8349ads will work ? and if not can I cook
It will not work. You will hav e to port U-Boot to your hardware.
There is no way around this.
> something based on this code with minimal changes ?
> Another question is whether 2.6.* kernel configured
> and built for mpc83xx family should work with any
> board
> based on this CPU or some board specific changes=20
> must be done in the kernel ?=20
Yes. See for example the TQM834x support in U-Boot and Linux 2.6
(patches submitted on the mailing list, checked in on our GIT repo).
Best regards,
Wolfgang Denk
--=20
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Gods don't like people not doing much work. People who aren't busy
all the time might start to _think_. - Terry Pratchett, _Small Gods_
--__--__--
Message: 9
Date: Wed, 02 Nov 2005 07:58:32 -0500
From: Jerry Van Baren <gerald.vanbaren at smiths-aerospace.com>
To: u-boot-users at lists.sourceforge.net
Subject: Re: [U-Boot-Users] Help about tftp download
Li Weichen wrote:
>>Another suggestion: from a (linux) box command line, tftp to your
server
>>and verify that it works. Your message is indicating that your server
>>is 192.168.4.1 and the file you are trying to get is
>>/tftpboot/u-boot.bin so do the following (I'm typing this from memory,
>>so it may not be quite right)...
>>
>>$ tftp 192.168.4.1
>>tftp> get /tftpboot/u-boot.bin
>
> Sorry but after I typed tftp 192.168.4.1, it came up with message
looks like
> get uImage froam tftp server automatically.
>
>>Getting TFTP to work (i.e. properly configured) usually solves the
>>problem in my experience.
>>
>>gvb
Hi Li,
You result description ment nothing to me. Please cut & paste real
messages. Are you typing "tftp 192.168.4.1" from your _host_ (linux
server) command line?
OK, I ran a real instance on my home box (Debian 3.1 x86)
vanbaren at dellserver:~$ uname -a
Linux dellserver.lan 2.4.27-050821 #17 SMP Sun Aug 21 22:46:01 EDT 2005
i686 GNU/Linux
vanbaren at dellserver:~$ dpkg-query -l "*tftp*"
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err:
uppercase=bad)
||/ Name Version Description
+++-==============-==============-======================================
======
ii tftp 0.17-13 Trivial file transfer protocol client
ii tftpd 0.17-13 Trivial file transfer protocol server
vanbaren at dellserver:~$ ls /tftpboot/hello_world
hello_world
vanbaren at dellserver:~$ tftp localhost
tftp> get hello_world
Received 101214 bytes in 0.1 seconds
tftp> get /tftpboot/hello_world
Received 101214 bytes in 0.0 seconds
tftp> quit
vanbaren at dellserver:~$ grep tftp /etc/inetd.conf
tftp dgram udp wait nobody /usr/sbin/tcpd
/usr/sbin/in.tftpd /tftpboot
I was a little surprised that the tftp "get" worked with the /tftpboot
full path. On a different box that I used (RH), it is configured as "-s
/tftpboot" for the option (rather than "/tftpboot") so tftpd treats
paths as relative to /tftpboot and thus the get "/tftpboot/foo" won't
work because there is no /tftpboot/tftpboot/foo on the server. This
should not be your problem since your configuration matches mine.
HTH,
gvb
--__--__--
Message: 10
Date: Wed, 2 Nov 2005 14:18:53 +0100
To: Mike Rapoport <mike.rapoport at gmail.com>
Cc: Wolfgang Denk <wd at denx.de>,
Terence Soh <Terence.Soh at appliedbiosystems.com>,
u-boot-users at lists.sourceforge.net
Subject: Re: [U-Boot-Users] NAND flash support
From: Ladislav Michl <ladis at linux-mips.org>
On Tue, Nov 01, 2005 at 04:22:28PM +0200, Mike Rapoport wrote:
> I've tried to make it as clean as possible, but there still may be
> some junk I used for debugging.
Thanks a lot. Updated version (with timeout handling) follows -
generated
against testing-NAND branch. Wolfgang, could you apply?
I also got another board with NAND chip for testing and I was able to
reproduce your problem with with bus error. I'll look at it as soon as
I get some spare time.
Signed-off-by: Ladislav Michl <ladis at linux-mips.org>
CHANGELOG:
* Add hook to NAND erase and implement nand_wait function.
Patch by Mike Rapoport, 1 Nov 2005
diff --git a/common/Makefile b/common/Makefile
--- a/common/Makefile
+++ b/common/Makefile
@@ -37,7 +37,7 @@ COBJS = main.o ACEX1K.o altera.o bedbug.
cmd_i2c.o cmd_ide.o cmd_immap.o cmd_itest.o cmd_jffs2.o \
cmd_load.o cmd_log.o \
cmd_mem.o cmd_mii.o cmd_misc.o cmd_mmc.o \
- cmd_nand.o cmd_net.o cmd_nvedit.o \
+ cmd_nand.o cmd_nand_new.o cmd_net.o cmd_nvedit.o \
cmd_pci.o cmd_pcmcia.o cmd_portio.o \
cmd_reginfo.o cmd_reiser.o cmd_scsi.o cmd_spi.o cmd_universe.o
cmd_usb.o cmd_vfd.o \
command.o console.o devices.o dlmalloc.o docecc.o \
diff --git a/drivers/nand/nand_base.c b/drivers/nand/nand_base.c
--- a/drivers/nand/nand_base.c
+++ b/drivers/nand/nand_base.c
@@ -189,7 +189,11 @@ static void nand_release_device (struct
spin_unlock (&this->chip_lock);
}
#else
-#define nand_release_device(mtd) do {} while(0)
+static void nand_release_device (struct mtd_info *mtd)
+{
+ struct nand_chip *this = mtd->priv;
+ this->select_chip(mtd, -1); /* De-select the NAND device */
+}
#endif
/**
@@ -831,8 +835,34 @@ static int nand_wait(struct mtd_info *mt
#else
static int nand_wait(struct mtd_info *mtd, struct nand_chip *this, int
state)
{
- /* TODO */
- return 0;
+ unsigned long timeo;
+
+ if (state == FL_ERASING)
+ timeo = CFG_HZ * 400;
+ else
+ timeo = CFG_HZ * 20;
+
+ if ((state == FL_ERASING) && (this->options & NAND_IS_AND))
+ this->cmdfunc(mtd, NAND_CMD_STATUS_MULTI, -1, -1);
+ else
+ this->cmdfunc(mtd, NAND_CMD_STATUS, -1, -1);
+
+ reset_timer_masked();
+
+ while (1) {
+ if (get_timer_masked() > timeo)
+ return 0;
+
+ if (this->dev_ready) {
+ if (this->dev_ready(mtd))
+ break;
+ } else {
+ if (this->read_byte(mtd) & NAND_STATUS_READY)
+ break;
+ }
+ }
+
+ return this->read_byte(mtd);
}
#endif
diff --git a/include/bmp_logo.h b/include/bmp_logo.h
diff --git a/include/nand.h b/include/nand.h
--- a/include/nand.h
+++ b/include/nand.h
@@ -50,7 +50,14 @@ static inline int nand_block_isbad(nand_
static inline int nand_erase(nand_info_t *info, ulong off, ulong size)
{
- return 0; /* FIXME */
+ struct erase_info instr;
+
+ instr.mtd = info;
+ instr.addr = off;
+ instr.len = size;
+ instr.callback = 0;
+
+ return info->erase(info, &instr);
}
#endif
--__--__--
Message: 11
Date: Wed, 02 Nov 2005 13:49:03 +0100
To: wd at denx.de
From: Denis Peter <d.peter at mpl.ch>
Cc: u-boot-users at lists.sourceforge.net
Subject: [U-Boot-Users] [PATCH] Add ECC check to MIP405 specific Memtest
--=====================_20085110==_
Content-Type: text/plain; charset="us-ascii"; format=flowed
Dear Wolfgang,
the attached patch against the current CVS adds ECC check to the MIP405
specific Memtest.
CHANGELOG:
* Patch by Denis Peter, 2. Nov 2005
add ECC Check to MIP405 specific Memtest
With best regards,
Denis
----------------------------------------------
MPL AG
CH-5405 Daettwil Switzerland
http://www.mpl.ch
Tel. ++41 (0)56 483 34 34
Fax ++41 (0)56 493 30 20
--=====================_20085110==_
Content-Type: application/octet-stream; name="checkecc.patch"
Content-Disposition: attachment; filename="checkecc.patch"
Content-Transfer-Encoding: base64
ZGlmZiAtcHVyTiB1LWJvb3Qtb3JpZy9ib2FyZC9tcGwvY29tbW9uL21lbXRzdC5jIHUtYm9v
dC9i
b2FyZC9tcGwvY29tbW9uL21lbXRzdC5jCi0tLSB1LWJvb3Qtb3JpZy9ib2FyZC9tcGwvY29t
bW9u
L21lbXRzdC5jCTIwMDUtMTEtMDEgMTE6MjI6MzguMDAwMDAwMDAwICswMTAwCisrKyB1LWJv
b3Qv
Ym9hcmQvbXBsL2NvbW1vbi9tZW10c3QuYwkyMDA1LTExLTAxIDExOjMxOjE1LjAwMDAwMDAw
MCAr
MDEwMApAQCAtMjIsMjggKzIyLDYgQEAKICAqCiAgKi8KIAotLyogTk9UIFVzZWQgeWV0Li4u
Ci0g
IGFkZCBmb2xsb3dpbmcgY29kZSB0byBQSVA0MDUuYyA6Ci1pbnQgdGVzdGRyYW0gKHZvaWQp
Ci17
Ci0JdW5zaWduZWQgY2hhciBzWzMyXTsKLQlpbnQgaTsKLQotCWkgPSBnZXRlbnZfciAoInRl
c3Rt
ZW0iLCBzLCAzMik7Ci0JaWYgKGkgIT0gMCkgewotCQlpID0gKGludCkgc2ltcGxlX3N0cnRv
dWwg
KHMsIE5VTEwsIDEwKTsKLQkJaWYgKChpID4gMCkgJiYgKGkgPCAweGYpKSB7Ci0JCQlwcmlu
dGYg
KCJ0ZXN0aW5nICIpOwotCQkJaSA9IG1lbV90ZXN0ICgwLCByYW1zaXplLCBpKTsKLQkJCWlm
IChp
ID4gMCkKLQkJCQlwcmludGYgKCJFUlJPUiAiKTsKLQkJCWVsc2UKLQkJCQlwcmludGYgKCJP
ayAi
KTsKLQkJfQotCX0KLQlyZXR1cm4gKDEpOwotfQotKi8KIAogCiAjaW5jbHVkZSA8Y29tbW9u
Lmg+
CkBAIC01ODIsNiArNTYwLDUyIEBAIGludCBtZW1fdGVzdCAodW5zaWduZWQgbG9uZyBzdGFy
dCwg
dW5zaWcKIAkJd2hpbGUgKHByb2ctLSA+IDApCiAJCQlwcmludGYgKCJcYiBcYiIpOwogCX0K
KyNp
ZmRlZiBDT05GSUdfNDA1R1AKKwkvKiBDaGVjayBFQ0MgKi8KKwltdGRjciAobWVtY2ZnYSwg
bWVt
X2VjY2NmKTsKKwlpID0gbWZkY3IgKG1lbWNmZ2QpOworCWlmIChpKSB7IC8qIGVjYyBlbmFi
bGVk
ICovCisJCW10ZGNyIChtZW1jZmdhLCBtZW1fZWNjZXJyKTsKKwkJaSA9IG1mZGNyIChtZW1j
Zmdk
KTsKKwkJaSAmPSAweEZGRjBGMDAwOyAvKiBtYXNrIHVudXNlZCBiaXRzICovCisJCWlmIChp
KSB7
CisJCQlwdXRzICgiXG5FUlJPUiBpbiBFQ0M6XG4iKTsKKwkJCWlmIChpICYgMHhGMDAwMDAw
MCkg
eworCQkJCWZvciAocHJvZyA9IDA7IHByb2cgPCA0O3Byb2crKykgeworCQkJCQkvKiB0aGlz
IG1h
eSBiZSBkb2N1bWVudGVkIHRoZSB3cm9uZyB3YXk6CisJCQkJCSAqIEFuIGVycm9yIG9uIEQ2
IGNh
dXNlcyB0byBzZXQgdGhlIEVycm9yIGluIGxhbmUgMworCQkJCQkgKiBpbnN0ZWFkIG9mIGxh
bmUg
MAorCQkJCQkgKiBpZigoaSYweEYwMDAwMDAwKSAmICgweDEwMDAwMDAwIDw8IHByb2cpKQor
CQkJ
CQkgKi8KKwkJCQkJaWYgKChpICYgMHhGMDAwMDAwMCkgJiAoMHg4MDAwMDAwMCA+PiBwcm9n
KSkK
KwkJCQkJCXByaW50ZiAoIiAgLSBFdmVuIFdvcmQgTGFuZSAlZFxuIixwcm9nKTsKKwkJCQl9
CisJ
CQl9CisJCQlpZiAoaSAmIDB4MEYwMDAwMDApIHsKKwkJCQlmb3IgKHByb2cgPSAwOyBwcm9n
IDwg
NDsgcHJvZysrKSB7CisJCQkJCS8qIHNlZSBhYm92ZSAqLworCQkJCQlpZiAoKGkgJiAweDBG
MDAw
MDAwKSAmICgweDA4MDAwMDAwID4+IHByb2cpKQorCQkJCQkJcHJpbnRmICgiICAtIE9kZCBX
b3Jk
IExhbmUgJWRcbiIscHJvZyk7CisJCQkJfQorCQkJfQorCQkJaWYgKGkgJiAweDAwQzAwMDAw
KSB7
CisJCQkJcHJpbnRmICgiIC0gRUNDIEVycm9yIGluICVzJXNDaGVjayBCaXRzXG4iLAorCQkJ
CQko
aSAmIDB4MDA4MDAwMDApID8gImxvd2VyICIgOiAiIiwKKwkJCQkJKGkgJiAweDAwNDAwMDAw
KSA/
ICJ1cHBlciAiIDogIiIpOworCQkJfQorCQkJaWYgKGkgJiAweDAwMDBGMDAwKSB7CisJCQkJ
Zm9y
IChwcm9nID0gMDsgcHJvZyA8IDQ7IHByb2crKykgeworCQkJCQlpZiAoKGkgJiAweDAwMDBG
MDAw
KSAmICgweDAwMDA4MDAwID4+IHByb2cpKQorCQkJCQkJcHJpbnRmICgiICAtIGluIEJhbmsg
JWRc
biIscHJvZyk7CisJCQkJfQorCQkJfQorCQkJc3RhdHVzPVRFU1RfRkFJTEVEOworCQl9CisJ
CWVs
c2UgeworCQkJcHV0cyAoIlxuRUNDIEJpdCdzIE9rXG4iKTsKKwkJfQorCX0KKyNlbmRpZgog
CiAJ
aWYgKHN0YXR1cyA9PSBURVNUX0ZBSUxFRCkKIAkJZXJyb3JzKys7Cg==
--=====================_20085110==_--
--__--__--
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
End of U-Boot-Users Digest
More information about the U-Boot
mailing list