matthieu castet wrote: > Daniel Drake wrote: >> Matthieu CASTET wrote: > >> >> Thanks for looking into all that. This just started happening on one >> of my devices (ZD1211B) - it cannot survive a rmmod/insmod cycle >> without me having to unplug it. Same problem with the vendor driver. >> Same for reboots. >> >> So, I researched the whole address space thing a bit further. I don't >> completely agree with the info above: >> - I think the load code comes before the load vector, but don't have >> solid evidence for this >> - I don't know why you think the bootloader firmware image ends at >> ffe8. My zd1211b_ub file is 4018 bytes, thats 0x7d9 words, i.e. >> it ends at 0xffd9. However, code in the vendor driver suggests it >> goes all the way up to cINT_VECT_ADDR (0xfff5). > I don't remember, but in my dump, some bits change before 0xfff5 when I > loaded Firmware. So I supposed it shouldn't be bootloader code. > >> - As hinted above I believe the interrupt vector begins at 0xfff5 >> > >> >> I reworked your patch slightly, and put it in the address-space branch >> of my git tree. > Ok
Unfortunately this breaks for non-affected users. Ulrich can no longer do a rmmod/insmod after applying this patch. Upon the insmod, the driver reads the interrupt vector entry, sees that it is 0xee00, so doesn't upload the firmware. However the driver fails soon after, it doesn't get interrupts so breaks on the first register read. >> >> As you suggested, at some point we should improve this further to >> reset the firmware and upload the one on the host system in this >> situation. Right now this doesn't really matter because we're >> compatible with all firmware releases. > Yes but it could be a problem if a user boot windows before. Same > problem if he uses vendor linux driver before. IRRC vendor driver use > different firmware from us. We use the same firmware as of version 2_15_0_0, but we do not depend on any firmware specific features. So at the moment it doesn't matter which firmware we're up against - we're compatible with all of them. > Matthieu > > PS : > For the zdofw project, I attach a sumary of instruction I made some time > ago. > It shows a problem : SKIP gt == LDRS R7. > I didn't have time to update to the lastest instructions you discovered. Hmm..nice find. I suspect my identification of LDRS is wrong, after all it smells like a very odd instruction according to the notes I have made. I have built up a partial understanding of r6, when we know more we will hopefully be able to re-evaluate this cmp/skip thing. I wonder if r5 has influence on skip in general, it doesn't seem widely used by the vendor firmware. I'm also keeping my eye open for a "skip backwards" instruction. There must be some small loops where they need to jump back a few instructions.. Maybe they just conditionally subtract from r7. Daniel ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Zd1211-devs mailing list - http://zd1211.ath.cx/ Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs
