Joerg: I would be honored to be among the people creating the script for OS X and Linux. I already have a working script for all the pieces of the toolchain on OS X adapted from the bingo script I found on AVR freaks and several others I have found kicking around on the Web. The problem with building Simulavr was with the newer version I found on their website using git, I couldn't get that to build to save my soul. So I switched back to the old one SIMULAVR_VER="0.1.2.6" which builds with no trouble. The notes on the Simulavr website said that it doesn't build yet so I decided to wait until they get it fixed. This note from their website explains it: "In the moment we have only some old versions available for download." The only other possibility is "simavr" which I tried to build but was unsuccessful, there is no configure script so it is not very portable.
Thanks, Ed On Mar 17, 2011, at 10:52 PM, avarice-user- [email protected] wrote: > Send avarice-user mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/avarice-user > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of avarice-user digest..." > > > Today's Topics: > > 1. Patching Avarice (Ed) > 2. Re: Patching Avarice (Joerg Wunsch) > 3. Patching Avarice (Ed) > 4. Re: Patching Avarice (Weddington, Eric) > 5. Patching Avarice (Ed) > 6. Re: Patching Avarice (Joerg Wunsch) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 16 Mar 2011 20:24:39 -0700 > From: Ed <[email protected]> > Subject: [AVaRICE-user] Patching Avarice > To: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > Thanks for answering Eric, > > Yes those are the patches I'm refering to. > > I am trying to build an entire toolchain on OS X (10.5.8) and I want > to make sure all the latest patches are included, especially Avarice. > Avarice seems to be the most difficult to get to build and work on OS > X. > The patch from the AVR freaks is called "avarice_210.patch" and I got > it from here "http://www.cl.cam.ac.uk/~osc22/files/avr_gcc/avarice_210.patch > ". > > I am most concerned with the latest patches for libusb-1.0.8 as I have > not been able to get Avarice usb to work ever. (I have a jtagmkII). > But it is also necessary to make sure all the latest patches to the > files for all the newer I.C's from Atmel are included. > > I have make a script to build and install all of the AVR toolchain on > Mac OS X (10.5.8) including: > BINUTILS_VER="2.21" > GCC_VER="4.5.2" > GDB_VER="7.2" > GMP_VER="5.0.1" > MPFR_VER="3.0.0" > MPC_VER="0.8.2" > INSIGHT_VER="6.8-1" > AVARICE_VER="2.10" > AVRDUDE_VER="5.10" > AVRLIBC_VER="1.7.1" > SIMULAVR_VER="0.1.2.6" > > Although I still can't get Simulavr to build yet, I gave up after > about a week. > This script was modeled after the one on AVR freaks, but I have > modified it extensively to make it more user friendly and less prone > to remove anything it should not. > > I have been looking into trying to learn how to use "quilt" to bundle > all these patches together, but I don't really know what I am doing > yet, as this is all uncharted waters to me. > > Any help or advice would be much appreciated, > > Ed > > > > ------------------------------ > > Message: 2 > Date: Thu, 17 Mar 2011 08:22:04 +0100 > From: Joerg Wunsch <[email protected]> > Subject: Re: [AVaRICE-user] Patching Avarice > To: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > As Ed wrote: > >> I also have another patch listed by the people on AVR freaks which is >> from "Debian" for Avarice called: FTBFS: jtag2usb.cc:98: error: >> invalid conversion from 'const char*' to 'char*' >> the file is called "avarice_210.patch". > > This has already been fixed in the CVS version, so start with what's > in CVS right now. It's just I didn't have the time (and Internet > bandwidth before) to roll a new release since. > >> It appears that the patch program does not like the fact that the >> patch shows line 4485 is: " 72 * 4, // 72 interrupt vectors", >> and the line in the original file is not the same. ( 71 * 4, // 71 >> interrupt vectors). > > The original file experienced another bugfix meanwhile. The patch > needs to be adjusted. The patch itself breaks the formatting, btw. > It inserts spaces for indentation when the original file uses TABs. > > > As Weddington, Eric wrote: > >> I can see that #2842239 is a one line change which, of course, is >> easy. > > Agreed. > >> #2995091 - Fix gcc 4.4.1 warnings > > Should be not too difficult either. I disagree with part of the patch > though: > > - (void)write(ctrlPipe, cmd, 1); > + (void)(write(ctrlPipe, cmd, 1) != 0); > > This fixes a warning that has been introduced by some operating system > header, but I think the "fix" is just pointless. If the return value > of a function is already explicitly cast to (void), this should > clearly demonstrate the programmer's intention to (actively, rather > than silently/blindly) ignoring the function's return value. If a > certain operating system doesn't agree with that, the users should > complain to the OS rather than me, or the package maintainer for that > OS should add an OS-local patch. In my opinion, the suggested > workaround is just obfuscating things, making it harder to read. > > > > As Ed wrote: > > [Ed, please use your mailer's reply button rather than starting from > scratch, so the thread context remains intact.] > >> But it is also necessary to make sure all the latest patches to the >> files for all the newer I.C's from Atmel are included. > > Keep in mind that the entire Xmega debugging is currently defunct as > the appnote AVR067 doesn't document the breakpoint handling on Xmega > devices. Thus, I don't think adding the respective patch would get > you more than an "experimental" version of AVaRICE, which is still far > away from being "production use ready". (My very personal consequence > out of that dilemma is that I'm avoiding Xmega devices like the > plague. They are of no value to me if I cannot debug them. The day I > need a larger microcontroller, I'd seriously consider an ARM instead.) > >> SIMULAVR_VER="0.1.2.6" >> >> Although I still can't get Simulavr to build yet, I gave up after >> about a week. > > Better try the simulavr version from the git repository. Version > 0.1.2.6 is pretty outdated, and about the only reason it still exists > at all is that avr-libc's testsuite uses it. > > > Btw., we recently formed a mailinglist for some people who are > actively trying to setup a toolchain build script in particular for > Linux and MacOS X users. Do you want to join there? The idea is to > start with the "Bingo600 Linux build script" that is floating around > on avrfreaks.net. > > -- > cheers, J"org .-.-. --... ...-- -.. . DL8DTL > > http://www.sax.de/~joerg/ NIC: JW11-RIPE > Never trust an operating system you don't have sources for. ;-) > > > > ------------------------------ > > Message: 3 > Date: Thu, 17 Mar 2011 16:11:04 -0700 > From: Ed <[email protected]> > Subject: [AVaRICE-user] Patching Avarice > To: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > All: > Here is another problem with the bundle of Avarice patches, this patch > "warnings.patch" has a problem at line 198 of the patch file. The > patch process barfs on hunk #3 with an error: (Hunk #3 FAILED at 244. > 1 out of 3 hunks FAILED -- saving rejects to file src/ > jtag2prog.cc.rej). It appears the Avarice file src/jtag2prog.cc and > the patch file disagree as to what is and what is supposed to be > witness: > > warnings.patch starting at line # 198: > > @@ -246,8 +244,8 @@ > // Basically, we just open the file and copy blocks over to the > JTAG > // box. > struct stat ifstat; > - char *target = NULL; > - char *default_target = "binary"; > + const char *target = NULL; > + const char *default_target = "binary"; > unsigned int page_size; > bool done = 0; > bfd *file; > > This is the relevant sections of the file to be patched /src/ > jtag2prog.cc are: > > // Basically, we just open the file and copy blocks over to the > JTAG > // box. > struct stat ifstat; > char *target = NULL; > char default_target[] = "binary"; > unsigned int page_size; > bool done = 0; > bfd *file; > > This section of code was previously patched by another file called > "avarice-string-warning.patch". Here is the relevant patch from the > patch file: > > RCS file: /cvsroot/avarice/avarice/src/jtag2prog.cc,v > retrieving revision 1.3 > diff -u -r1.3 jtag2prog.cc > --- jtag2prog.cc 8 Aug 2006 21:27:34 -0000 1.3 > +++ jtag2prog.cc 21 Aug 2009 21:00:40 -0000 > @@ -247,7 +247,7 @@ > // box. > struct stat ifstat; > char *target = NULL; > - char *default_target = "binary"; > + char default_target[] = "binary"; > unsigned int page_size; > bool done = 0; > bfd *file; > > Its looks to me that the change is changing an array called > default_target to a constant char pointer called default_target. > > The question is, which patch is correct? Are they both correct? > > TIA, > Ed > > > > > ------------------------------ > > Message: 4 > Date: Thu, 17 Mar 2011 17:20:56 -0600 > From: "Weddington, Eric" <[email protected]> > Subject: Re: [AVaRICE-user] Patching Avarice > To: "Ed" <[email protected]>, <[email protected]> > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="us-ascii" > > Hi Ed, > > Well, I would think that we need to take a look at the usage of the > default_target variable. Is it really used as a variable, i.e., is > it reassigned another value elsewhere in the program? If not, then I > would think that it would be safe to say that it can be declared a > "const char *", a constant string, with the value given. > > Overall, since the warnings.patch file is to fix warnings, I think > it might be prudent to rebuild avarice from CVS and see what the > actual warnings are these days (I've been trying to do just that > recently to help you out, but I'm running into some Bootstrap > issues, and Joerg is helping me out with this offline). We should > see if the patch file fixes any of the currently existing warnings > and we should just fix those, rather than blindly applying the patch. > > I don't always assume that the patch does the right thing, > especially if the code has changed over time and the patch is a bit > stale. > > Eric > >> -----Original Message----- >> From: Ed [mailto:[email protected]] >> Sent: Thursday, March 17, 2011 5:11 PM >> To: [email protected] >> Subject: [AVaRICE-user] Patching Avarice >> >> All: >> Here is another problem with the bundle of Avarice patches, this >> patch >> "warnings.patch" has a problem at line 198 of the patch file. The >> patch process barfs on hunk #3 with an error: (Hunk #3 FAILED at 244. >> 1 out of 3 hunks FAILED -- saving rejects to file src/ >> jtag2prog.cc.rej). It appears the Avarice file src/jtag2prog.cc and >> the patch file disagree as to what is and what is supposed to be >> witness: >> >> warnings.patch starting at line # 198: >> >> @@ -246,8 +244,8 @@ >> // Basically, we just open the file and copy blocks over to the >> JTAG >> // box. >> struct stat ifstat; >> - char *target = NULL; >> - char *default_target = "binary"; >> + const char *target = NULL; >> + const char *default_target = "binary"; >> unsigned int page_size; >> bool done = 0; >> bfd *file; >> >> This is the relevant sections of the file to be patched /src/ >> jtag2prog.cc are: >> >> // Basically, we just open the file and copy blocks over to the >> JTAG >> // box. >> struct stat ifstat; >> char *target = NULL; >> char default_target[] = "binary"; >> unsigned int page_size; >> bool done = 0; >> bfd *file; >> >> This section of code was previously patched by another file called >> "avarice-string-warning.patch". Here is the relevant patch from the >> patch file: >> >> RCS file: /cvsroot/avarice/avarice/src/jtag2prog.cc,v >> retrieving revision 1.3 >> diff -u -r1.3 jtag2prog.cc >> --- jtag2prog.cc 8 Aug 2006 21:27:34 -0000 1.3 >> +++ jtag2prog.cc 21 Aug 2009 21:00:40 -0000 >> @@ -247,7 +247,7 @@ >> // box. >> struct stat ifstat; >> char *target = NULL; >> - char *default_target = "binary"; >> + char default_target[] = "binary"; >> unsigned int page_size; >> bool done = 0; >> bfd *file; >> >> Its looks to me that the change is changing an array called >> default_target to a constant char pointer called default_target. >> >> The question is, which patch is correct? Are they both correct? >> >> TIA, >> Ed >> >> >> -------------------------------------------------------------------------- >> ---- >> Colocation vs. Managed Hosting >> A question and answer guide to determining the best fit >> for your organization - today and in the future. >> http://p.sf.net/sfu/internap-sfd2d >> _______________________________________________ >> avarice-user mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/avarice-user > > > > ------------------------------ > > Message: 5 > Date: Thu, 17 Mar 2011 20:20:51 -0700 > From: Ed <[email protected]> > Subject: [AVaRICE-user] Patching Avarice > To: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; > delsp=yes > > Hi again: > I sorry to be such a pain but, here are two more problems with the > last patch file called: "avarice-2.10_atxmega256a3_support.patch". > > Problem #1: > All the file names in this patch are prefixed by "+++ > avarice-2.10_patched/src/xxxx". > The only way to get this patch to work is by removing all the "+++ > avarice-2.10_patched/" from the file names. Is there another way to > get "patch" to understand that the > sub-directory is not "+++ avarice-2.10_patched" but "+++ > avarice-2.10". > > Problem #2: > When I did fix the above problem the patches apply OK but the make > fails with a strange error: > > devdescr.cc:4799: error: brace-enclosed initializer used to > initialize ?unsigned int? > devdescr.cc:4799: error: brace-enclosed initializer used to > initialize ?dev_flags? > make[2]: *** [devdescr.o] Error 1 > make[1]: *** [all] Error 2 > make: *** [all-recursive] Error 1 > > The problem seems to be this large chunk of code being added: > > @@ -4476,6 +4476,95 @@ > fill_b2(0), // EECRAddress > }, > }, > + > + > + /*******************************************************/ > + /************** SUPPORT FOR ATXMEGA256A3 ***************/ > + /*******************************************************/ > + > +/* Datasheet (doc8068) specifies a size of 256 words (2Bytes) per > page and 512 pages. > +/* I assume the page size to be 128 words and 1024 pages, because > otherwise I can't > +/* reprogram the atxmega256a3 successfully */ > +#define BOOT_PAGES 16 > +#define APP_PAGES 1024 > +#define WORD_SIZE 2 > +#define F_PAGES_WORD_SIZE 256 * 1024 /*[Bytes]*/ /2 /*[words]*/ / > APP_PAGES /*[words/page]*/ > +#define F_PAGES_SIZE F_PAGES_WORD_SIZE * WORD_SIZE > +#define EE_PAGE_SIZE 32 > +#define EE_PAGES 128 > +#define BOOT_START_ADDR 0x40000 > +#define SRAM_START_ADDR 0x2000 > + > + > + { > + "atxmega256a3", > + 0x9842, > + F_PAGES_SIZE, APP_PAGES + BOOT_PAGES, // 270336 Bytes of flash > + EE_PAGE_SIZE, EE_PAGES, > // 4096 [0x1000] bytes EEPROM > + 0 * 4, // 36 interrupt vectors > + DEVFL_MKII_ONLY, > + NULL, // registers not yet defined > + true, > + { > + 0 // no mkI support > + }, > + { > + CMND_SET_DEVICE_DESCRIPTOR, > + { 0xFF,0xFF,0xFF,0xF9,0xFF,0x3D,0xB9,0xF8 }, // ucReadIO > + { 0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00 }, // ucReadIOShadow > + { 0xFF,0xFF,0x1F,0xE0,0xFF,0x1D,0xA9,0xF8 }, // ucWriteIO > + { 0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00 }, // ucWriteIOShadow > + { 0x73,0xFF,0x3F,0xFF,0xF7,0x3F,0xF7,0x3F, > + 0xF7,0x3F,0x5F,0x3F,0x37,0x37,0x36,0x00, > + 0x00,0x00,0x00,0x00,0xFF,0x0F,0x00,0x00, > + 0xF7,0x3F,0x36,0x00 }, // ucReadExtIO > + { 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, > + 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, > + 0x00,0x00,0x00,0x00 }, // ucReadIOExtShadow > + { 0x73,0xFF,0x3F,0xF8,0xF7,0x3F,0xF7,0x3F, > + 0xF7,0x3F,0x5F,0x2F,0x36,0x36,0x36,0x00, > + 0x00,0x00,0x00,0x00,0xFF,0x0F,0x00,0x00, > + 0xF7,0x3F,0x36,0x00 }, // ucWriteExtIO > + { 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, > + 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, > + 0x00,0x00,0x00,0x00 }, // ucWriteIOExtShadow > + 0x90, // ucIDRAddress > + 0x57, // ucSPMCRAddress Store Program Memory Control Register > + 0, // ucRAMPZAddress RAMPZ seems to be an instruction > + fill_b2(F_PAGES_SIZE), // uiFlashPageSize > + 32, // ucEepromPageSize > + fill_b4(BOOT_START_ADDR), // ulBootAddress > + fill_b2(0x40), // uiUpperExtIOLoc > + fill_b4(F_PAGES_SIZE * (APP_PAGES + BOOT_PAGES)), // ulFlashSize > + { 0x00 }, // ucEepromInst > + { 0x00 }, // ucFlashInst > + 0x3E, /* ucSPHaddr (Stack Pointer Higher ADDR) > + * In regs it's 0x1D and remapped in > I/O regs @ 0x3E*/ > + 0x3D, /* ucSPLaddr (Stack Pointer Lower ADDR) > + * In regs it's 0x1C and remapped in > I/O regs @ 0x3D*/ > + fill_b2(APP_PAGES + BOOT_PAGES), // uiFlashpages > + 0x00, // ucDWDRAddress > + 0x00, // ucDWBasePC > + 0x00, // ucAllowFullPageBitstream > + fill_b2(0x00), // uiStartSmallestBootLoaderSection > + 1, // EnablePageProgramming > + 0x02, // ucCacheType > + fill_b2(SRAM_START_ADDR), // uiSramStartAddr > + 0, // ucResetType > + 0, // ucPCMaskExtended > + 0, // ucPCMaskHigh > + 0, // ucEindAddress > + fill_b2(0), // EECRAddress > + }, > + }, > + > + > + /*******************************************************/ > + /*********** Eof SUPPORT FOR ATXMEGA256A3 **************/ > + /*******************************************************/ > + > + > + > // DEV_ATMEGA128RFA1 > { > "atmega128rfa1", > > It seems that somewhere in this mess is an extra curly brace, or one > missing and I don't understand this file format so I cannot discern > where exactly the problem lies. > If I remove this chunk of code all the patches apply fine and Avarice > builds to completing without any errors. > However, I don't know if it works as I haven't actually used it for > anything yet. > Perhaps tomorrow I'll get to it. > > TIA, > Ed > > > ------------------------------ > > Message: 6 > Date: Fri, 18 Mar 2011 06:52:34 +0100 > From: Joerg Wunsch <[email protected]> > Subject: Re: [AVaRICE-user] Patching Avarice > To: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > As Ed wrote: > >> I sorry to be such a pain but, here are two more problems with the >> last patch file called: "avarice-2.10_atxmega256a3_support.patch". > > Given my explanation about the current deficiencies of Xmega > debugging, are you sure you even *want* to apply that patch > at all? > >> It seems that somewhere in this mess is an extra curly brace, or one >> missing and I don't understand this file format so I cannot discern >> where exactly the problem lies. > > It's a struct initialization, but one of your previous patches > added more elements to this struct type. The Xmega256a3 patch > doesn't know about this addition, so it's got the wrong number > of fields in it. > -- > cheers, J"org .-.-. --... ...-- -.. . DL8DTL > > http://www.sax.de/~joerg/ NIC: JW11-RIPE > Never trust an operating system you don't have sources for. ;-) > > > > ------------------------------ > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > > ------------------------------ > > _______________________________________________ > avarice-user mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/avarice-user > > > End of avarice-user Digest, Vol 28, Issue 2 > ******************************************* > ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ avarice-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/avarice-user
