Wolfgang,
For the FAT size issue, I believe something is wrong in my building caches.
Because when I reconfigure FAT support back to my CONFIG_COMMANDS and recompile
again, I can't build such a big u-boot.bin any more. Then I remove FAT again,
make distclean; add FAT back; make distclean; make again. I am still unable to
get the previous so big one. Following is the final size even with FAT enabled:
-rwxrwxr-x 1 dev dev 147384 2008-02-02 00:52 u-boot.bin
For the enable_interrupt() will cause my board abnormal issue, I found some
threads to it (Malloc buffer is smaller than ENV_SIZE, which would cause
env_ptr to be an invalid pointer -- 0x0000008 in env_relocate()). Either to
adjust the judgment in lib_ppc/board.c or to enlarge the CFG_MALLOC_LEN to be a
much bigger value than CFG_ENV_SIZE can make the pointer valid and prevent the
system from being abnormal. But I think to change the judgement in
lib_ppc/board.c should be preferred. According to the codes, it is going to
automatically enlarge the TOTAL_MALLOC_LEN by CFG_ENV_SZE unless following
conditions:
ENV_ADDR+ENV_SIZE is bigger than or equal to CFG_MONITOR_BASE
AND
ENV_ADDR is smaller than or equal to CFG_MONITOR_BASE
Since things when ENV_ADDR+ENV_SIZE is equal to CFG_MONITOR_BASE should be also
considered as an condition to enlarge the TOTAL_MALLOC_LEN by CFG_ENV_SIZE, the
above judgment should be changed as:
ENV_ADDR+ENV_SIZE is bigger than CFG_MONITOR_BASE
AND
ENV_ADDR is smaller than or equal to CFG_MONITOR_BASE
Regards,
Tony
-----邮件原件-----
发件人: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
发送时间: 2008年2月1日 20:09
收件人: tony liu
主题: Re: 答复: U-Boot bug fix report (rellocate error)
In message <[EMAIL PROTECTED]> you wrote:
>
> Thanks for replying me. I'll post messages to the mailing list in the
> later. And also I will get and try the 1.3.1 revision.
You should have posted *this* message on the ML, too.
> The answer to the question why my u-boot is so big is: I've enabled the
> FAT support; if I disable this, the U-boot can be in about 160K.
No, that cannot be the reason. FAT code does not make for 200 kB, it
adds a mere 8 kB of code & data:
-> size fs/fat/libfat.a
text data bss dec hex filename
5532 132 8 5672 1628 fat.o (ex fs/fat/libfat.a)
1220 576 0 1796 704 file.o (ex fs/fat/libfat.a)
> The answer to the question why I think it needs to preserve RAM for
> environment is: according to the codes in lib_ppc/board.c, it seems when
> ENV is defined in a place behind of TEXT_BASE + sizeof(u-boot.bin) in
> FLASH, system needs to preserve a bigger MALLOC size in memory.
You have to configure your system correctly.
> flash. But I still don't know why it needs to reserve more memory when
> ENV is defined behind of TEXT + sizeof(u-boot.bin) in flash.
If your environment size is smaller than a full sector size, U-Boot
will try not to overwrite the remaining part of the sector, so it
needs a scratch buffer of the size of your flash sector.
If you reply, please do so on the ML!
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
The first thing we do is kill all the lawyers.
(Shakespeare. II Henry VI, Act IV, scene ii)
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
U-Boot-Users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/u-boot-users
