September 2005 - U-Boot

[U-Boot-Users] gunzip question about large uImages
by Robin Getz 13 Mar '06

13 Mar '06

Quick Question: It looks to me that the max uncompressed image size is hard coded to 4Meg (0x400000 bytes). Any thoughts why? Long question: We were having some problems booting large uImages (reported here ~ month ago). It seemed as if the were not being decompressed properly. When we had someone (Aubrey Li) dig into it he found/pointed out that in the latest cvs, u-boot/common/cmd_bootm.c the function do_bootm defines what looks to be a uncompressed max length as: uint unc_len = 0x400000; This is passed to gunzip if the image needs to be uncompressed. --snip-- case IH_COMP_GZIP: printf (" Uncompressing %s ... ", name); if (gunzip ((void *)ntohl(hdr->ih_load), unc_len, (uchar *)data, &len) != 0) { puts ("GUNZIP ERROR - must RESET board to recover\n"); SHOW_BOOT_PROGRESS (-6); do_reset (cmdtp, flag, argc, argv); } break; --snip-- gunzip takes this as the second parameter and sets it to dstlen. int gunzip(void *dst, int dstlen, unsigned char *src, unsigned long *lenp) This is passed to the inflation routine as s.avail_out = dstlen; where inflate from u-boot/lib_generic/zlib.c uses this to halt decompression if the image size can not fit. -- snip -- from int inflate(z, f) -- if (f == Z_PACKET_FLUSH && z->avail_in == 0 && z->avail_out != 0) r = inflate_packet_flush(z->state->blocks); --snip -- from local int inflate_flush(s, z, r)-- /* compute number of bytes to copy as far as end of window */ n = (uInt)((q <= s->write ? s->write : s->end) - q); if (n > z->avail_out) n = z->avail_out; if (n && r == Z_BUF_ERROR) r = Z_OK; /* update counters */ z->avail_out -= n; z->total_out += n; -- When unc_len is increased - our problem goes away... So: two questions: - what is the best way to manage the size of unc_len? in include/configs/platform.h? Or just make it really_really big? - do you want a patch in u-boot/common/cmd_bootm.c/gunzip to check to see if the image was completely decompressed? OR - do you want a patch in u-boot/lib_generic/zlib.c to return an error if it runs out of room? Thanks -Robin

2 1

[U-Boot-Users] Why exceptions are enabled before exception vector code is copied
by Cedric VINCENT 13 Mar '06

13 Mar '06

Dear Wolfgang. Can I ask you why exceptions are enabled before exception vector code is copied to the low RAM pages ? (I am talking about U-Boot/PPC) On my board, U-Boot crashes before relocation (when debugging) since Xilinx Microprocessor Debugger (XMD) makes a spurious "Machine Check Exception". For other reasons, such an exception could arrived before u-boot starts. Finally, it is a bug or a very strange coding behaviour... Cedric VINCENT.

2 6

[U-Boot-Users] [PATCH] I2C2 support for MPC8548CDS
by Zajac Adam-AAZ004 13 Mar '06

13 Mar '06

The attached patch adds I2C2 support for the MPC8548CDS board. I've performed a limited testing on our MPC8548CDS board and everything seems to be working fine. Since this processor is brand new, I may need to revise the changes when we build our real system based on '8548. Thanks, Adam Zajac <<mpc8548cds_i2c2.patch.gz>>

2 1

[U-Boot-Users] malloc with no return check?
by Andrew Dyer 13 Mar '06

13 Mar '06

I noticed the au1xxx ethernet driver has a malloc where the return value isn't checked. I did some more looking while waiting for a slow flash programmer and at least these files seem to do the same thing: ./drivers/ns8382x.c ./drivers/bcm570x.c ./drivers/rtl8139.c ./drivers/eepro100.c ./drivers/dc2114x.c ./drivers/e1000.c ./drivers/sk98lin/skge.c ./drivers/cfb_console.c ./drivers/natsemi.c ./drivers/inca-ip_sw.c ./drivers/rtl8169.c ./drivers/pcnet.c ./cpu/mips/au1x00_eth.c ./cpu/ppc4xx/serial.c ./cpu/ppc4xx/405gp_enet.c ./cpu/ppc4xx/440gx_enet.c ./cpu/i386/serial.c ./cpu/mpc8xx/scc.c ./common/hush.c ./cpu/mpc8xx/spi.c ?maybe ./cpu/mpc8260/spi.c ?maybe ./cpu/mpc85xx/ether_fcc.c ./cpu/mpc8260/ether_fcc.c ./cpu/mpc5xxx/fec.c ./cpu/mpc8220/fec.c ./tools/easylogo/easylogo.c I didn't look under the board directory or check all varieties of alloc :-) I will submit patches for the mips stuff hopefully next week. -- Hardware, n.: The parts of a computer system that can be kicked.

3 4

[U-Boot-Users] [PATCH] in tftp client, recover from lost ACKs
by Brenda J. Butler 13 Mar '06

13 Mar '06

CHANGELOG entry: * Patch by John McCarthy and Brenda J. Butler, 8 July 2005 When the tftp client sends an ack but it gets lost, the server will resend the block. The client was now expecting the next block and ignored this block, the server never got an ack, and they got stuck. Now the tftp client will ack the block the second (and subsequent) time(s) allowing the tftp session to proceed. This little fix assumes that the server will resend exactly the same contents (same size from same offset). Here is the patch for you to look at; it is also in an attachment where the tabs and lines are preserved better. Apply to top of head checkout with patch -p0 < uboot2.patch Index: net/tftp.c =================================================================== RCS file: /u00/cvs/u-boot3/net/tftp.c,v retrieving revision 1.1 retrieving revision 1.3 diff -u -r1.1 -r1.3 --- net/tftp.c 15 Mar 2005 17:53:28 -0000 1.1 +++ net/tftp.c 5 Jul 2005 19:48:46 -0000 1.3 @@ -246,17 +246,17 @@ } } - if (TftpBlock == TftpLastBlock) { - /* - * Same block again; ignore it. - */ - break; - } - TftpLastBlock = TftpBlock; NetSetTimeout (TIMEOUT * CFG_HZ, TftpTimeout); - store_block (TftpBlock - 1, pkt + 2, len); + if (TftpBlock != TftpLastBlock) { + /* + * Same block again; do everything again + * except store it. Hope the server sent + * exactly the same length/contents. + */ + store_block (TftpBlock - 1, pkt + 2, len); + } /* * Acknoledge the block just received, which will prompt

2 1

[U-Boot-Users] [PATCH] fix [id]cache_status for MPC85xx processors
by Murray.Jensen＠csiro.au 13 Mar '06

13 Mar '06

The existing code for the [id]cache_status commands on MPC85xx processors looks at the wrong bit to determine if the L1 cache is enabled. It looks at the most significant bit when it should look at the least significant bit. This patch corrects this bug. Cheers! Murray... CHANGELOG entry: * Patch by Murray Jensen <Murray.Jensen(a)csiro.au>, July 19, 2005: - fix bug in [id]cache_status commands for MPC85xx processors; should look at LSB of L1CSRn registers to determine if L1 cache is enabled, not the MSB. Copyright: This patch is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. -- Murray Jensen, CSIRO Manufacturing & Infra. Tech. Phone: +61 3 9662 7763 Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 9662 7853 Internet: Murray.Jensen(a)csiro.au To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference. The information contained in this e-mail may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this e-mail in error, please delete it immediately and notify Murray Jensen on +61 3 9662 7763. Thank you.

2 1

[U-Boot-Users] [PATCH] fix fw_setenv with uninitialised environment
by Murray.Jensen＠csiro.au 12 Mar '06

12 Mar '06

In tools/env/fw_env.c when the environment is uninitialised, and the default_environment[] array is used instead, if a setenv is done there is a good chance that the array bounds will be exceeded. Cheers! Murray... CHANGELOG entry: * Patch by Murray Jensen <Murray.Jensen(a)csiro.au>, July 15, 2005: - fix array overflow with fw_setenv on uninitialised environment Copyright: This patch is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. -- Murray Jensen, CSIRO Manufacturing & Infra. Tech. Phone: +61 3 9662 7763 Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 9662 7853 Internet: Murray.Jensen(a)csiro.au To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference. The information contained in this e-mail may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this e-mail in error, please delete it immediately and notify Murray Jensen on +61 3 9662 7763. Thank you.

2 1

[U-Boot-Users] PATCH: Add support for EmbeddedPlanet EP88x boards
by Yuli Barcohen 12 Mar '06

12 Mar '06

The attached patch adds support for EmbeddedPlanet EP88x boards. It was tested on EP88xC board with MPC885 processor, 64MB RAM, and 16MB flash. CHANGELOG Add support for EmbeddedPlanet EP88x boards -- ======================================================================== Yuli Barcohen | Phone +972-9-765-1788 | Software Project Leader yuli(a)arabellasw.com | Fax +972-9-765-7494 | Arabella Software, Israel ========================================================================

3 5

[U-Boot-Users] extra headers in xilinx ml300 board
by Michael Libeskind 12 Mar '06

12 Mar '06

/board/xilinx/xilinx_enet/emac_adapter.c and /board/xilinx/xilinx_iic/iic_adapter.c both have a #include <configs/ml300.h> which I believe prevents users from making other board configs under the /board/xilinx directory based on the ML300 that use the xilinx_enet and xilinx_iic adapaters. Can this be removed?

2 3

[U-Boot-Users] [PATCH] board support for the mpc8540eval board
by Ron Alder 12 Mar '06

12 Mar '06

The attached patch adds support for the MPC8540 EVAL board. The patch is based on the top of the cvs tree as of 11 July 2005. CHANGELOG entry: * Patch by Ron Alder, 11 July 2005 Add Xianghua Xiao and Lunsheng Wang's support for the GDA MPC8540 EVAL board.

2 1