avrdude r1160 Segmentation fault

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

avrdude r1160 Segmentation fault

Enoch W.
Hi,

Please be advised that the above mentioned revision is causing a seg
fault during flash write using Atmel's JTAG Mk II. It wasn't so a couple
of days ago so I assume it is a result of May 3 numerous changes.

Thanks, Enoch.



_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: avrdude r1160 Segmentation fault

Enoch W.
Enoch <[hidden email]> writes:

> Hi,
>
> Please be advised that the above mentioned revision is causing a seg
> fault during flash write using Atmel's JTAG Mk II. It wasn't so a couple
> of days ago so I assume it is a result of May 3 numerous changes.
>
> Thanks, Enoch.

FYI, I rolled back to Joerg's latest submission (r1140) and it works
"rock solid".

Thanks, Enoch.


_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: avrdude r1160 Segmentation fault

Joerg Wunsch
In reply to this post by Enoch W.
As Enoch wrote:

> Please be advised that the above mentioned revision is causing a seg
> fault during flash write using Atmel's JTAG Mk II. It wasn't so a couple
> of days ago so I assume it is a result of May 3 numerous changes.

Any chance for a debugger stacktrace?

I don't see a segfault over here with the JTAGICEmkII.
--
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)

_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: avrdude r1160 Segmentation fault

Enoch W.
Joerg Wunsch <[hidden email]> writes:

> As Enoch wrote:
>
>> Please be advised that the above mentioned revision is causing a seg
>> fault during flash write using Atmel's JTAG Mk II. It wasn't so a couple
>> of days ago so I assume it is a result of May 3 numerous changes.
>
> Any chance for a debugger stacktrace?
>
> I don't see a segfault over here with the JTAGICEmkII.

Hi Joerg,

Will try ASAP.
No surprise, I am here with Debian and its our of sync libs
while you are riding on FreeBSD :-)

Regards, Enoch.

P/S I said in a followup, your latest SVN r1140 works well.


_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: avrdude r1160 Segmentation fault

Joerg Wunsch
As Enoch wrote:

> No surprise, I am here with Debian and its our of sync libs
> while you are riding on FreeBSD :-)

OK, tried it on an Ubuntu, and can confirm the segfault:

Writing | ################################################## | 100% 0.04s

avrdude: 336 bytes of flash written

Program received signal SIGSEGV, Segmentation fault.
0x0000000000433f93 in jtagmkII_open (pgm=0x6db9c0, port=0x1 <Address 0x1 out of bounds>) at jtagmkII.c:1555
1555      if (strncmp(port, "usb", 3) == 0) {
(gdb) bt
#0  0x0000000000433f93 in jtagmkII_open (pgm=0x6db9c0, port=0x1 <Address 0x1 out of bounds>) at jtagmkII.c:1555
#1  0x000000000041b756 in do_op (pgm=0x6db9c0, p=0x834100, upd=0x663430, flags=UF_NONE) at update.c:322
#2  0x0000000000404408 in main (argc=<optimized out>, argv=<optimized out>) at main.c:1241

So "port" is given as 0x01 here.  Stack frame #1 is:

pgm->vfy_led(pgm, ON);

No idea offhand why that triggers a jtagmkII_open() with bogus
arguments.
--
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)

_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: avrdude r1160 Segmentation fault

René Liebscher
Hi,

could you try to revert main.c to version 1159. I moved the display of
the programmer before the open command, to see their pin outputs before
they try to open, so I could see what they had read from the config file
and internally processed with the new pin definitions. (I did this
testing without having actually the hardware connected, so open always
ended the program. And originally I did not intend to check in the file.)

It seems jtagmkii_display needs you to call jtagmkii_open beforehand. At
least I get there some problems (with Ubuntu 12.10), and it looks as
would be overwritten somewhere some memory. This might be the reason for
the problem. reverting the file should make disappear the segfault. On
the other hand, if this really overwrites some memory then there must be
some other problem in the code of jtagmkii too, as normally some
checking of return values or error codes should reveal the fact that the
progammer was not opened beforehand.

René


On 04.05.2013 18:36, Joerg Wunsch wrote:

> As Enoch wrote:
>
>> No surprise, I am here with Debian and its our of sync libs
>> while you are riding on FreeBSD :-)
> OK, tried it on an Ubuntu, and can confirm the segfault:
>
> Writing | ################################################## | 100% 0.04s
>
> avrdude: 336 bytes of flash written
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000000000433f93 in jtagmkII_open (pgm=0x6db9c0, port=0x1 <Address 0x1 out of bounds>) at jtagmkII.c:1555
> 1555      if (strncmp(port, "usb", 3) == 0) {
> (gdb) bt
> #0  0x0000000000433f93 in jtagmkII_open (pgm=0x6db9c0, port=0x1 <Address 0x1 out of bounds>) at jtagmkII.c:1555
> #1  0x000000000041b756 in do_op (pgm=0x6db9c0, p=0x834100, upd=0x663430, flags=UF_NONE) at update.c:322
> #2  0x0000000000404408 in main (argc=<optimized out>, argv=<optimized out>) at main.c:1241
>
> So "port" is given as 0x01 here.  Stack frame #1 is:
>
> pgm->vfy_led(pgm, ON);
>
> No idea offhand why that triggers a jtagmkII_open() with bogus
> arguments.


_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: avrdude r1160 Segmentation fault

René Liebscher
Hi,

ok, maybe not overwritten memory, but at least it writes (and reads)
data using an uninitialized file descriptor. This brings then the
strange output that I see on my terminal.

It obviously writes to fd 0 which is stdin, and that I see in terminal,
0>/dev/null lets disappear it. I never tried before to write something
in stdin, I did not even know that could work.


René


On 04.05.2013 21:49, René Liebscher wrote:

> Hi,
>
> could you try to revert main.c to version 1159. I moved the display of
> the programmer before the open command, to see their pin outputs
> before they try to open, so I could see what they had read from the
> config file and internally processed with the new pin definitions. (I
> did this testing without having actually the hardware connected, so
> open always ended the program. And originally I did not intend to
> check in the file.)
>
> It seems jtagmkii_display needs you to call jtagmkii_open beforehand.
> At least I get there some problems (with Ubuntu 12.10), and it looks
> as would be overwritten somewhere some memory. This might be the
> reason for the problem. reverting the file should make disappear the
> segfault. On the other hand, if this really overwrites some memory
> then there must be some other problem in the code of jtagmkii too, as
> normally some checking of return values or error codes should reveal
> the fact that the progammer was not opened beforehand.
>
> René
>
>
> On 04.05.2013 18:36, Joerg Wunsch wrote:
>> As Enoch wrote:
>>
>>> No surprise, I am here with Debian and its our of sync libs
>>> while you are riding on FreeBSD :-)
>> OK, tried it on an Ubuntu, and can confirm the segfault:
>>
>> Writing | ################################################## | 100%
>> 0.04s
>>
>> avrdude: 336 bytes of flash written
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x0000000000433f93 in jtagmkII_open (pgm=0x6db9c0, port=0x1 <Address
>> 0x1 out of bounds>) at jtagmkII.c:1555
>> 1555      if (strncmp(port, "usb", 3) == 0) {
>> (gdb) bt
>> #0  0x0000000000433f93 in jtagmkII_open (pgm=0x6db9c0, port=0x1
>> <Address 0x1 out of bounds>) at jtagmkII.c:1555
>> #1  0x000000000041b756 in do_op (pgm=0x6db9c0, p=0x834100,
>> upd=0x663430, flags=UF_NONE) at update.c:322
>> #2  0x0000000000404408 in main (argc=<optimized out>, argv=<optimized
>> out>) at main.c:1241
>>
>> So "port" is given as 0x01 here.  Stack frame #1 is:
>>
>> pgm->vfy_led(pgm, ON);
>>
>> No idea offhand why that triggers a jtagmkII_open() with bogus
>> arguments.
>
>
> _______________________________________________
> avrdude-dev mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/avrdude-dev


_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: avrdude r1160 Segmentation fault

Joerg Wunsch
In reply to this post by Joerg Wunsch
As Joerg Wunsch wrote:

> So "port" is given as 0x01 here.  Stack frame #1 is:
>
> pgm->vfy_led(pgm, ON);
>
> No idea offhand why that triggers a jtagmkII_open() with bogus
> arguments.

The entire pgm structure appears to be garbled after some point:

(gdb) p *pgm
$2 = {id = 0x6df060, desc = "Atmel JTAG ICE mkII", '\000' <repeats 60 times>, type = "JTAGMKII", '\000' <repeats 23 times>,
  port = "usb", '\000' <repeats 4092 times>, initpgm = 0x436170 <jtagmkII_initpgm>, pinno = {0 <repeats 11 times>}, pin = {{
      mask = {0}, inverse = {0}}, {mask = {0}, inverse = {0}}, {mask = {0}, inverse = {0}}, {mask = {0}, inverse = {0}}, {
      mask = {0}, inverse = {0}}, {mask = {0}, inverse = {0}}, {mask = {2}, inverse = {494780232499200}}, {mask = {0},
      inverse = {0}}, {mask = {0}, inverse = {0}}, {mask = {0}, inverse = {0}}, {mask = {0}, inverse = {0}}},
  exit_vcc = EXIT_VCC_UNSPEC, exit_reset = EXIT_RESET_UNSPEC, exit_datahigh = EXIT_DATAHIGH_UNSPEC,
  conntype = CONNTYPE_PARALLEL, ppidata = 0, ppictrl = 0, baudrate = 0, usbvid = 0, usbpid = 0,
  usbdev = '\000' <repeats 255 times>, usbsn = '\000' <repeats 255 times>, usbvendor = '\000' <repeats 255 times>,
  usbproduct = '\000' <repeats 164 times>"\215, \355\265\240\367ư>\000\000\000\000\000\000\000\000\360\257\216\000\000\000\000\000\202\000\000\000\002\000\000\000\000\000\000\000@\000\000\000\000\001\000\000\000\000\000\000Ч@\000\000\000\000\000Ч@\000\000\000\000\000Ч@\000\000\000\000\000Ч@\000\000\000\000\000 RC\000\000\000\000\000 `C",
  bitclock = 2.1648138439186728e-317, ispdelay = 4390448, fd = {ifd = 4237280, pfd = 0x40a7e0, usb = {handle = 0x40a7e0,
      rep = 4237280, wep = 0, eep = 4381616, max_xfer = 0}}, page_size = 4393312, rdy_led = 0, err_led = 0, pgm_led = 0,
  vfy_led = 0x4346d0 <jtagmkII_open>, initialize = 0x433500 <jtagmkII_close>, display = 0x430320 <jtagmkII_paged_write>,
  enable = 0x42f580 <jtagmkII_paged_load>, disable = 0x42f1e0 <jtagmkII_page_erase>, powerup = 0,
  powerdown = 0x42fe90 <jtagmkII_write_byte>, program_enable = 0x434b70 <jtagmkII_read_byte>, chip_erase = 0,
  cmd = 0x434b60 <jtagmkII_print_parms>, cmd_tpi = 0, spi = 0, open = 0, close = 0x42ef40 <jtagmkII_set_sck_period>,
  paged_write = 0, paged_load = 0, page_erase = 0, write_setup = 0, write_byte = 0,
  read_byte = 0x42dc10 <jtagmkII_parseextparms>, read_sig_bytes = 0x42e4a0 <jtagmkII_setup>,
  print_parms = 0x42dc00 <jtagmkII_teardown>, set_vtarget = 0x2e65647564727661, set_varef = 0x666e6f63, set_fosc = 0,
  set_sck_period = 0, setpin = 0, getpin = 0, highpulsepin = 0, parseexitspecs = 0, perform_osccal = 0, parseextparams = 0,
  setup = 0, teardown = 0,
  config_file = '\000' <repeats 4000 times>, ">\003\000\000\000\000\000\000\200Df\000\000\000\000\000\004\000\000\000\000\000\000\000A\000\000\000\000\000\000\000\001\000\000\000\001\000\000\002\024\000\000\000\000\000\000\000\320\360m\000\000\000\000\000\320\360m\000\000\000\000\000\350\360m\000\000\000\000\000\300\360m\000\000\000\000\000\300\360m\000\000\000\000\000!\000\000\000\000\000\000", lineno = 1734440042, cookie = 0x0, flag = 0 '\000'}

This is the (segfaulting) 64-bit Linux.  In contrast, the (working)
32-bit FreeBSD has:

(gdb) p *pgm
$1 = {id = 0x43d086c0, desc = "Atmel JTAG ICE mkII", '\0' <repeats 60 times>,
  type = "JTAGMKII", '\0' <repeats 23 times>, port = "usb", '\0' <repeats 1020 times>,
  initpgm = 0x8072fc0 <jtagmkII_initpgm>, pinno = {0 <repeats 11 times>}, pin = {{mask = {0}, inverse = {
        0}} <repeats 11 times>}, exit_vcc = EXIT_VCC_UNSPEC, exit_reset = EXIT_RESET_UNSPEC,
  exit_datahigh = EXIT_DATAHIGH_UNSPEC, conntype = CONNTYPE_USB, ppidata = 0, ppictrl = 0,
  baudrate = 115200, usbvid = 0, usbpid = 0, usbdev = '\0' <repeats 255 times>,
  usbsn = '\0' <repeats 255 times>, usbvendor = '\0' <repeats 255 times>,
  usbproduct = '\0' <repeats 255 times>, bitclock = 9.9999999999999995e-07, ispdelay = 0, fd = {
    ifd = 1139389824, pfd = 0x43e9b580, usb = {handle = 0x43e9b580, rep = 130, wep = 2, eep = 0,
      max_xfer = 64}}, page_size = 256, rdy_led = 0x80521f0 <pgm_default_led>,
  err_led = 0x80521f0 <pgm_default_led>, pgm_led = 0x80521f0 <pgm_default_led>,
  vfy_led = 0x80521f0 <pgm_default_led>, initialize = 0x807ad20 <jtagmkII_initialize>,
  display = 0x80772e0 <jtagmkII_display>, enable = 0x8072a10 <jtagmkII_enable>,
  disable = 0x80799a0 <jtagmkII_disable>, powerup = 0x8052200 <pgm_default_powerup_powerdown>,
  powerdown = 0x8052200 <pgm_default_powerup_powerdown>,
  program_enable = 0x8072a00 <jtagmkII_program_enable_dummy>,
  chip_erase = 0x80799f0 <jtagmkII_chip_erase>, cmd = 0, cmd_tpi = 0, spi = 0,
  open = 0x807ac20 <jtagmkII_open>, close = 0x8077420 <jtagmkII_close>,
  paged_write = 0x8079350 <jtagmkII_paged_write>, paged_load = 0x8078130 <jtagmkII_paged_load>,
  page_erase = 0x8078620 <jtagmkII_page_erase>, write_setup = 0,
  write_byte = 0x8078e80 <jtagmkII_write_byte>, read_byte = 0x8077ac0 <jtagmkII_read_byte>,
  read_sig_bytes = 0, print_parms = 0x80772c0 <jtagmkII_print_parms>, set_vtarget = 0, set_varef = 0,
  set_fosc = 0, set_sck_period = 0x8076e90 <jtagmkII_set_sck_period>, setpin = 0, getpin = 0,
  highpulsepin = 0, parseexitspecs = 0, perform_osccal = 0,
  parseextparams = 0x8073150 <jtagmkII_parseextparms>, setup = 0x8073ba0 <jtagmkII_setup>,
  teardown = 0x8073130 <jtagmkII_teardown>, config_file = "avrdude.conf", '\0' <repeats 1011 times>,
  lineno = 829, cookie = 0x43dfe040, flag = 4 '\004'}

--
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)

_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: avrdude r1160 Segmentation fault

Joerg Wunsch
As Joerg Wunsch wrote:

> The entire pgm structure appears to be garbled after some point:

More datapoints: update.c obviously has a different idea about
struct programmer_t than anyone else:

(gdb) bt
#0  0x0000000000434723 in jtagmkII_open (pgm=0x6dc9c0, port=0x1 <Address 0x1 out of bounds>) at jtagmkII.c:1555
#1  0x000000000041bee6 in do_op (pgm=0x6dc9c0, p=0x835100, upd=0x664430, flags=UF_NONE) at update.c:322
#2  0x0000000000404157 in main (argc=<optimized out>, argv=<optimized out>) at main.c:1241
(gdb) p sizeof (struct programmer_t)
$19 = 9880
(gdb) up
#1  0x000000000041bee6 in do_op (pgm=0x6dc9c0, p=0x835100, upd=0x664430, flags=UF_NONE) at update.c:322
322         pgm->vfy_led(pgm, ON);
(gdb) p sizeof (struct programmer_t)
$20 = 9976
(gdb) up
#2  0x0000000000404157 in main (argc=<optimized out>, argv=<optimized out>) at main.c:1241
1241        rc = do_op(pgm, p, upd, uflags);
(gdb) p sizeof (struct programmer_t)
$21 = 9880

I think it's really time for a unified "avrdude.h" file.
--
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)

_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: avrdude r1160 Segmentation fault

Joerg Wunsch
As Joerg Wunsch wrote:

> As Joerg Wunsch wrote:
>
> > The entire pgm structure appears to be garbled after some point:
>
> More datapoints: update.c obviously has a different idea about
> struct programmer_t than anyone else:

The confusion arose out of pindefs.h testing for HAVE_STDINT_H, and
then either using uint32_t or unsigned long for pinmask_t, depending
on whether <stdint.h> is supposed to be available or not.

Testing for one of the HAVE_* macros requires to include "ac_cfg.h"
before.  Failure to do so resulted in a struct programmer_t with two
different definitions for the pinmask arrays.  No deal for 32-bit
systems, but both arrays differed in size for 64-bit systems.
(Shouldn't the fallback type be "unsigned int" anyway, rather than
"unsigned long"?)

Yes, there should be a single, combined libavrdude.h file. ;-)
--
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)

_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: avrdude r1160 Segmentation fault

René Liebscher
HI,

as C guarantees only 16 bit for an int but 32 bit for a long, you better
take the long as fallback. (even if is unlikely that avrdude will ever
be compiled for a machine with only 16 bit integer.)

René


On 06.05.2013 11:59, Joerg Wunsch wrote:

> As Joerg Wunsch wrote:
>
>> As Joerg Wunsch wrote:
>>
>>> The entire pgm structure appears to be garbled after some point:
>> More datapoints: update.c obviously has a different idea about
>> struct programmer_t than anyone else:
> The confusion arose out of pindefs.h testing for HAVE_STDINT_H, and
> then either using uint32_t or unsigned long for pinmask_t, depending
> on whether <stdint.h> is supposed to be available or not.
>
> Testing for one of the HAVE_* macros requires to include "ac_cfg.h"
> before.  Failure to do so resulted in a struct programmer_t with two
> different definitions for the pinmask arrays.  No deal for 32-bit
> systems, but both arrays differed in size for 64-bit systems.
> (Shouldn't the fallback type be "unsigned int" anyway, rather than
> "unsigned long"?)
>
> Yes, there should be a single, combined libavrdude.h file. ;-)


_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: avrdude r1160 Segmentation fault

Joerg Wunsch
As René Liebscher wrote:

> as C guarantees only 16 bit for an int but 32 bit for a long, you
> better take the long as fallback. (even if is unlikely that avrdude
> will ever be compiled for a machine with only 16 bit integer.)

We rely on default integers being 32 bit in AVRDUDE in so many places,
so I think this is a moot point.

If you really think it's necessary, you could still check for UINT_MAX
being large enough.  I think that's better than potentially allocating
64-bit integers here.

--
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)

_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: avrdude r1160 Segmentation fault

Hannes Weisbach-2

Am 06.05.2013 um 20:19 schrieb Joerg Wunsch:

> As René Liebscher wrote:
>
>> as C guarantees only 16 bit for an int but 32 bit for a long, you
>> better take the long as fallback. (even if is unlikely that avrdude
>> will ever be compiled for a machine with only 16 bit integer.)
>
> We rely on default integers being 32 bit in AVRDUDE in so many places,
> so I think this is a moot point.
>
> If you really think it's necessary, you could still check for UINT_MAX
> being large enough.  I think that's better than potentially allocating
> 64-bit integers here.
Shouldn't we require a C99-compliant compiler, so we are sure to have stdint.h? We then can use proper types throughout avrdude. I mean avrftdi uses C99 features right now (VSAs, //-style comments, declaration placement) as does other parts of avrdude (variadic macros), so we might as well make it explicit.
gcc/clang is available for Windows (mingw), Linux, *BSD, OS X, ... so which major platform causes the holdup? Or is there some other reason I'm missing?

Regards,
Hannes
_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: avrdude r1160 Segmentation fault

Joerg Wunsch
As Hannes Weisbach wrote:

> gcc/clang is available for Windows (mingw), Linux, *BSD, OS X,
> ... so which major platform causes the holdup? Or is there some
> other reason I'm missing?

AVRDUDE used to be compilably on Visual C in the past, I think,
and Microsoft stopped any development on C, so they are frozen
on C90 level.

But you're probably right, we might have lost this ability quite
some time ago by using various other C99 features.
--
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)

_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev