Dear Alexander Stein, In message <201105050906.35834.alexander.st...@systec-electronic.com> you wrote: > > > Are you also still using the old environment code in your port, or is > > the new, hash table based one? When using the old code, there are > > additional penalties for using a needlessly big environment as each > > call to setenv() will recalculate the checksum. > > I was digging into this problem for a short time. And yes, the CRC > checksumcalculation takes about 25ms each run. So setenv is called for each > stdin,stdout and stderr. which sums up to ~75ms. > So you're right this is the old environment code. Here a dcache will speed up > the execution of course.
Even more so would reducing the environment size to some reasonable value. Currently you are using some 2 KiB, so say you set the environment size to 8 KiB. This would be 1/16 of your current size, which means the ~75ms would shrink to less than 5 ms. You are wasting 70 ms (only here - there are other places which will add to this figure) just because this inappropriate configuration. > But our standard startup just stars U-Boot and copies the Linux kernel into > RAM and starts it. There is not much use of dcache during copy here. You are wrong. There is a huge difference between perrforming a copy operation in single write cycles to uncached RAM versus writing to a cached area where the cache flushes willoperate in burst mode. Also, the U-Boot code will run faster, too, so copying and decompression is much faster. You repeat the same mistake again: you make assumptions about what may or may not be fast or slow on your system without actually measuring it. Donald Knuth is right again: "Early optimization is the root of much evil." > > > It is using a 32-Bit RAM-Bus. So, no. > > > > And your NOR flash? > > It is connected 16-bit like most devices only support, but it is setup to use > page read mode. Well, many systems use two 16 bit chips in parallel to give a 32 bit bus. > > DC of makes things awfully slow. See comments of commits c3330e9, > > 95c6f6d and 7e4a9e6 - for plain RAM bound operations like > > copying/uncompressing an image from RAM to RAM switchign on the DC can > > accelerate the system by a factor of up to >15. > > Yes, from RAM to RAM, dcache will help a lot. But we neither copy from RAM to > RAM nor do we uncompressing. There is still a huge diference in memory bandwith between using plain single write cycles versus burst mode accesses. Don't speculate. Measure yourself! 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: w...@denx.de "Send lawyers, guns and money..." - Lyrics from a Warren Zevon song _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
