Hello.
On 09/04/2017 06:22 PM, Josef Filzmaier wrote:
Hello
That worked and I was able to flash the device and bring it up with the
patched driver. It showed up correctly as subHGz device in iwpan. I have
no other device to test against but I can trust you on this. Please go
ahead and send your final patches to the list so we can get them into
the firmware and kernel.
I have used git send-mail to do so. However, i have found a small bug within
the firmware after i sent the patch. (Caused by moving code between commits)
What is the procedure if i want to re-submit a patch(set) to the mailing list?
You would re-send the updated patches with a v2 or similar in the
subject prefix.
Also, how does the review process work?
I will have a look at your patches again, review the code, run them
through some scripts and build testing here and give you feedback.
Once I am happy with them I will give you my Acked-By line in a reply
for the kernel patch and it should get picked up in a git tree and find
its way to Linus tree from there.
The firmware patch I will take directly into the corresponding git repo.
And once I do a new release of the frimware I will generate the binaries
and make sure they are updated in linux-firmware.
I only have one odd thing related to the flashing process. The device
you got me comes up in LUFA DFU bootloader mode with the green and red
led blinking alternately. In this mode I can use the flash command you
gave me above. After the flashing it will stay in this mode and I have
to issue a
dfu-programmer at90usb1287 reset
to get into the firmware/application. After that the device enumerates
and the atusb driver takes care of it.
That would be all fine if it only would be the case for the initial
flashing. For me the device always comes up in the bootloader mode,
though. I have to issue the reset command (not the flashing) each time I
plug it in.
Did I miss something here? Any trick to have the device boot the
firmware directly and only go into bootloader mode if the program button
on the back side is pressed?
We did apply a custom bootloader here because this is the behaviour we need
in order to deliver updates.
Oh, that explains it. :) For my use case of testing the driver against
the hardware I can deal with it. Having a bootloader available to be
flashed which jumps directly into the firmware might be nice for others
though.
regards
Stefan Schmidt
--
To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
