Re: [PATCH atusb/fw v2 2/3] atusb: fw: Update toolchain instructions

[Miquel Raynal <miquel.raynal@bootlin.com>]

Hello,

miquel.raynal@bootlin.com wrote on Wed, 19 Oct 2022 21:46:25 +0200:

> Hi Alexander,
> 
> aahringo@redhat.com wrote on Sat, 15 Oct 2022 21:02:08 -0400:
> 
> > Hi,
> > 
> > On Sat, Oct 15, 2022 at 4:58 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:  
> > >
> > > Hi Stefan,
> > >
> > > stefan@datenfreihafen.org wrote on Wed, 12 Oct 2022 19:54:49 +0200:
> > >    
> > > > Hello Miquel.
> > > >
> > > > On 06.09.22 10:21, Miquel Raynal wrote:    
> > > > > Those instructions do not work anymore for several reaons:
> > > > > - Two out of the three files to download return a 404 error:
> > > > >        * The binutils version does not exist, it was 2.21.1 or 2.21.1a
> > > > >          instead of just 2.21.
> > > > >        * The avr-libc is no longer hosted on the pointed website, I've
> > > > >          found an alternate.
> > > > > - The binutils version mentioned is not able to compile the firmware on
> > > > >    a recent distribution, the Internet advised to update its version and
> > > > >    it worked.
> > > > > - Most of these compilations will throw warnings if you use a recent
> > > > >    gcc. Sometimes -Werror is set and it fails the build. To avoid that,
> > > > >    just use --disable-werror in the ./configure options.
> > > > > - I had issues building the gcc doc but those issues are trivial to
> > > > >    fix inline.
> > > > >
> > > > > Update the instructions for building the toolchain and while at it,
> > > > > start the file by mentioning that this is maybe not useful anymore, and
> > > > > provide the packets to install.    
> > > >
> > > > I can see that it was a frustrating process to get this working. :/
> > > > Sorry to hear. The truth is only a handful of people did ever build the firmware themself, I think. Even I have not done it in a while. (ugh, 5 years ago most likely judging from the git log).    
> > >
> > > Oh I'm not blaming anyone here ;)
> > >
> > > By the way I would like to make a another round of tests because during
> > > my demos I could observe a wrong LQI, and I don't remember if the LQI
> > > was valid before my changes or not. I haven't got the time yet to get
> > > back to it. Or maybe the devices were too close to each other? I don't
> > > know, I'll need to figure it out so we don't break a useful existing
> > > feature.    
> > 
> > What is a wrong LQI here?  
> 
> I just took the time to reproduce the demo, I get an LQI of 0xff with
> both firmware versions (before and after my changes). There are 2
> meters between the devices, isn't it enough?

I hard a hard time putting my two devices "far enough from each other"
on a radio POV, so I used a shielded bag, multiple USB cable
extensions, a microwave and my co-worker Köry to finally get a
reduced LQI. So nevermind, the hardware/firmware works as expected and
the firmware update we proposed recently did not break anything.

I however found a nasty bug in the way the LQI was stored in the stack
(the control buffer skb->cb was initialized/reset after the LQI got
stored there), I will soon propose a fix.

Sorry for the burden, patches are coming soon.

Thanks,
Miquèl