[U-Boot-Users] bug tracing to PPC82xx system hang-up after enable_interrupts

[tony liu]

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


-----邮件原件-----
发件人: wd at denx.de [mailto:wd at denx.de] 
发送时间: 2008年2月1日 20:09
收件人: tony liu
主题: Re: 答复: U-Boot bug fix report (rellocate error)

In message <BD41C75853FA124BB535FAB82C56E2910196EC76 at sons-exch05.salira.com> 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: wd at denx.de
The first thing we do is kill all the lawyers.
(Shakespeare. II Henry VI, Act IV, scene ii)