Re: [U-Boot] the mips cache code question ?
Sorry for the two successive posts, I looked at the disassembly... On Wed, Dec 1, 2010 at 1:26 AM, 奥刘 wrote: > Dear All: > > Recently , i have build a embedded environment with Uboot . And My Chip > is adm5120 , mips4kc code. > > In the file .\cpu\mips\cache.s , i found some code confounded . > > line 152 to line 156 : > > cache_op Index_Store_Tag_I t0 > PTR_ADDU t0, a2 > bne t0, t1, 1b > /* fill once, so data field parity is correct */ > PTR_LI t0, INDEX_BASE > > the code 'PTR_LI t0, INDEX_BASE' is in the branch delay slot , so this > instruction will be implement every branch cycle. > > Is it right ? Then the cache operation logic seems wrong . The assembler does insert a 'NOP' instruction in the branch delay slot, even with ".set noreorder", so this is OK: 810005a8: bd14cache 0x14,0(t0) 810005ac: 01064021addut0,t0,a2 810005b0: 1509fffdbne t0,t1,810005a8 810005b4: nop -- Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] the mips cache code question ?
hello, On Wed, Dec 1, 2010 at 10:27 AM, Andrew Dyer wrote: > On Dec 1, 2010 12:26 AM, "奥刘" wrote: > >> In the file .\cpu\mips\cache.s , i found some code confounded . >> >> line 152 to line 156 : >> >> cache_op Index_Store_Tag_I t0 >> PTR_ADDU t0, a2 >> bne t0, t1, 1b >> /* fill once, so data field parity is correct */ >> PTR_LI t0, INDEX_BASE >> >> the code 'PTR_LI t0, INDEX_BASE' is in the branch delay slot , so this >> instruction will be implement every branch cycle. >> >> Is it right ? Then the cache operation logic seems wrong . It would seem. a NOP is needed in this case. seem every branch is incorrect. a disassembly would be best way to confirm. assembler might insert it for us. > > From a quick glance I think the code is OK. I would suggest > disassembling the executable code to make sure of what the assembler > did. > > The answer depends on what mode the assembler is in. For MIPS > assembler there is a 'reorder mode' where the assembler will fill in > the branch delay slot for you or place a nop if necessary, and the > next instruction in the source is really the one after the delay slot, > or there is noreorder mode where the next instruction after the branch > is what is put in the delay slot. > > Normally the assembler runs in reorder mode, and you use a '.set > reorder' and '.set noreorder' to switch between them. Noreorder mode > is commonly used in code that requires precise control of where > instructions get executed (cache & tlb handling) the file does specify noreorder! This is interesting, and of course I will be looking at a disassembly of my u-boot later, it is not available to me now. Tho, the cache's work, and have seen nothing that makes it seem otherwise.. -- Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] DEC21140 driver && netconsole && new target.
Hello, On Wed, Nov 24, 2010 at 4:18 PM, Wolfgang Denk wrote: > Dear Scott Nicholas, > > In message you > wrote: >> > > There is no dec21140 Ethernet driver in mainline U-Boot, so it's > pretty unlikely that there will be much feedback. Just don't be > disappointed. I mean drivers/net/dc2114x.c, whatever name it goes by. > > If would be great if you could submit your patches here - please see > http://www.denx.de/wiki/U-Boot/Patches for details. I may. But I can't test changes to dc2114x itself, is why I asked the list. Because maybe the board that does use it, does not exactly follow behavior of mine? Little would be gained from including my target to mainline. Afaik, it's only in this 1 router. The chip and board both out of production. But I can submit. I'm currently trying to have MIPS startup code use unlzma on the rest, so that I may fit the entire binary into the same 64k sector used currently. Would such a patch seem useful for submission as well? seems not much MIPS use in here. -- Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] DEC21140 driver && netconsole && new target.
Hello, I have a board which uses dec21140-like ethernet, non-pci. In Linksys' GPL release is old u-boot (seems 1.1.4). I had same problem with 2010.09, in that when I enable netconsole, I saw each putc/puts twice! I read dec2114x datasheet in detail, and firstly, wonder if anyone else has tested this driver with netconsole. I made many changes to mine to ensure MIPS cache coherency, but here are my findings for those interested to maybe one day find in the mailing list archive.. the TX/RX descriptors can be rings or chains. the driver seems to setup chains and use the End of Ring bit as well. Thus, in the net_send routine, the chipset should send buffer1, see buffer2size=0, and start again at ring base. If TX ring has only 1 entry, it see's the same descriptor again, and sends the packet twice. Since the chipset makes use of next descriptor if buffer2 size is 0, I made use of buffer2 itself. Then with buffer1size=0, it will only use buffer2. This is labeled "next" currently in the descriptor struct. So that, inside the net_send routine, you would set next = cpu_to_le32(phys_to_bus((u32)packet)); instead of buf. then des1 can be set as: des1 = cpu_to_le32(TD_LS | TD_FS | (length << 11)); This is currently good for 1 tx descriptor and u-boots small packets which never use >1, and certainly fixes a lot. Also, my board is the Linksys T-Mobile branded WRTU54G-TM, uses ADM8668 chipset for those curious, but this is from DEC21140 datasheet. Please inform me if this is not the case for whichever target uses it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
