Message ID | 20200821073111.134857-1-o-takashi@sakamocchi.jp (mailing list archive) |
---|---|
Headers | show |
Series | alsa-tools: efw-downloader: add initial version of firmwre downloader for Echo Audio Fireworks devices | expand |
Hi, Would I expect any reaction by maintainers of alsa-tools repository for the patches? On Fri, Aug 21, 2020 at 04:30:46PM +0900, Takashi Sakamoto wrote: > Hi, > > This patchset is for alsa-tool repository[1] to add a new command-line > tool, efw-downloader. The tools is designed to operate on-board flash > memory for devices based on Fireworks board module. The patches are also > available in my personal repository in github.com[2]. > > Fireworks board module was designed by Echo Digital Audio corporation. The > board module has on-board flash memory to store firmware blob and session > data. The contents of flash memory can be operated by software by a pair > of asynchronous transactions defined by Echo Digital Audio corporation. > > Echo Digital Audio corporation also designed file format of firmware. > Hardware Vendors including Echo Digital Audio corporation shipped > several versions of firmware by the format in driver packages for > Windows and macOS. > > The goal of this tool is to operate the flash memory to download any > version of firmware. In this patchset, limited functionalities are added; > read from the flash memory, and parse the content of file. The other > functionalities are planned to added in future work. > > I thinks it possible to put actual firmware blobs into somewhere > suitable for them (alsa-firmware or linux-firmware repositories). I > think it better to prepare the files by reading on-board flash memory, > with enough care of copyright of original firmware files shipped by > vendor. In the case, it's preferable to use file format different > from the original one. But it's my first time for this kind of work. > I'd like to ask some advices to alsa developers. > > [1] https://github.com/alsa-project/alsa-tools/ > [2] https://github.com/takaswie/alsa-tools/tree/topic/efw-downloader > > Takashi Sakamoto (25): > efw-downloader: start a new project to operate on-board flash memory > for Fireworks board module > efw-downloader: efw-proto: define EfwProto as derived object of > HinawaFwResp > efw-downloader: efw-proto: add constructor, destructor, bind, unbind > functions > efw-downloader: efw-proto: add responded signal > efw-downloader: efw-proto: add class virtual method to handle > responded signal > efw-downloader: efw-proto: add instance private structure > efw-downloader: efw-proto: emit responded signal at receiving response > efw-downloader: efw-proto: add function to finish transaction for > command frame > efw-downloader: efw-proto: add function to finish a pair of > transactions > efw-downloader: add parser for sub commands > efw-downloader: subcmd-device: implement 'device' sub command to > operate actual device > efw-downloader: subcmd-device: open firewire character device by > HinawaFwNode > efw-downloader: config-rom: parse config rom to detect supported > device > efw-downloader: subcmd-device: check supported models or not > efw-downloader: subcmd-device: bind Fireworks protocol > efw-downloader: node_dispatcher: add event dispatcher utilizing GLib > MainContext/MainLoop > efw-downloader: subcmd-device: support debug output for response of > Fireworks protocol > efw-downloader: efw-commands: add support for a part of hardware > command > efw-downloader: efw-commands: add support for commands in flash > category > efw-downloader: subcmd-device: add read operation > efw-downloader: file-cntr: add parser for data binary shipped by Echo > Digital Audio corporation > efw-downloader: subcmd-file: add 'file' sub command > efw-downloader: subcmd-file: add parse operation > efw-downloader: man: add online manual > efw-downloader: add README formatted by reStructuredText > > efw-downloader/COPYING | 674 ++++++++++++++++++ > efw-downloader/README.rst | 167 +++++ > efw-downloader/man/efw-downloader.1 | 162 +++++ > efw-downloader/meson.build | 14 + > efw-downloader/meson_options.txt | 5 + > efw-downloader/src/config-rom.c | 60 ++ > efw-downloader/src/config-rom.h | 26 + > efw-downloader/src/efw-commands.c | 243 +++++++ > efw-downloader/src/efw-commands.h | 57 ++ > .../src/efw-proto-sigs-marshal.list | 1 + > efw-downloader/src/efw-proto.c | 401 +++++++++++ > efw-downloader/src/efw-proto.h | 80 +++ > efw-downloader/src/file-cntr.c | 183 +++++ > efw-downloader/src/file-cntr.h | 39 + > efw-downloader/src/main.c | 54 ++ > efw-downloader/src/meson.build | 54 ++ > efw-downloader/src/node-dispatcher.c | 86 +++ > efw-downloader/src/node-dispatcher.h | 21 + > efw-downloader/src/op-device-read.c | 104 +++ > efw-downloader/src/op-file-parse.c | 106 +++ > efw-downloader/src/subcmd-device.c | 182 +++++ > efw-downloader/src/subcmd-file.c | 87 +++ > efw-downloader/src/subcmds.h | 16 + > 23 files changed, 2822 insertions(+) > create mode 100644 efw-downloader/COPYING > create mode 100644 efw-downloader/README.rst > create mode 100644 efw-downloader/man/efw-downloader.1 > create mode 100644 efw-downloader/meson.build > create mode 100644 efw-downloader/meson_options.txt > create mode 100644 efw-downloader/src/config-rom.c > create mode 100644 efw-downloader/src/config-rom.h > create mode 100644 efw-downloader/src/efw-commands.c > create mode 100644 efw-downloader/src/efw-commands.h > create mode 100644 efw-downloader/src/efw-proto-sigs-marshal.list > create mode 100644 efw-downloader/src/efw-proto.c > create mode 100644 efw-downloader/src/efw-proto.h > create mode 100644 efw-downloader/src/file-cntr.c > create mode 100644 efw-downloader/src/file-cntr.h > create mode 100644 efw-downloader/src/main.c > create mode 100644 efw-downloader/src/meson.build > create mode 100644 efw-downloader/src/node-dispatcher.c > create mode 100644 efw-downloader/src/node-dispatcher.h > create mode 100644 efw-downloader/src/op-device-read.c > create mode 100644 efw-downloader/src/op-file-parse.c > create mode 100644 efw-downloader/src/subcmd-device.c > create mode 100644 efw-downloader/src/subcmd-file.c > create mode 100644 efw-downloader/src/subcmds.h > > -- > 2.25.1 Thanks Takashi Sakamoto
On Wed, 26 Aug 2020 11:32:58 +0200, Takashi Sakamoto wrote: > > Hi, > > Would I expect any reaction by maintainers of alsa-tools repository for > the patches? I'm reviewing those patches now. Since it's based on meson build, it'll be tricky to include this in alsa-tools whether others are all autoconf. The tarball creation is done in the top directory and that assumes the execution of "make alsa-dist" in each subdirectory. Without this integration, the directory won't be included in the release. Could you work on it, too? thanks, Takashi > On Fri, Aug 21, 2020 at 04:30:46PM +0900, Takashi Sakamoto wrote: > > Hi, > > > > This patchset is for alsa-tool repository[1] to add a new command-line > > tool, efw-downloader. The tools is designed to operate on-board flash > > memory for devices based on Fireworks board module. The patches are also > > available in my personal repository in github.com[2]. > > > > Fireworks board module was designed by Echo Digital Audio corporation. The > > board module has on-board flash memory to store firmware blob and session > > data. The contents of flash memory can be operated by software by a pair > > of asynchronous transactions defined by Echo Digital Audio corporation. > > > > Echo Digital Audio corporation also designed file format of firmware. > > Hardware Vendors including Echo Digital Audio corporation shipped > > several versions of firmware by the format in driver packages for > > Windows and macOS. > > > > The goal of this tool is to operate the flash memory to download any > > version of firmware. In this patchset, limited functionalities are added; > > read from the flash memory, and parse the content of file. The other > > functionalities are planned to added in future work. > > > > I thinks it possible to put actual firmware blobs into somewhere > > suitable for them (alsa-firmware or linux-firmware repositories). I > > think it better to prepare the files by reading on-board flash memory, > > with enough care of copyright of original firmware files shipped by > > vendor. In the case, it's preferable to use file format different > > from the original one. But it's my first time for this kind of work. > > I'd like to ask some advices to alsa developers. > > > > [1] https://github.com/alsa-project/alsa-tools/ > > [2] https://github.com/takaswie/alsa-tools/tree/topic/efw-downloader > > > > Takashi Sakamoto (25): > > efw-downloader: start a new project to operate on-board flash memory > > for Fireworks board module > > efw-downloader: efw-proto: define EfwProto as derived object of > > HinawaFwResp > > efw-downloader: efw-proto: add constructor, destructor, bind, unbind > > functions > > efw-downloader: efw-proto: add responded signal > > efw-downloader: efw-proto: add class virtual method to handle > > responded signal > > efw-downloader: efw-proto: add instance private structure > > efw-downloader: efw-proto: emit responded signal at receiving response > > efw-downloader: efw-proto: add function to finish transaction for > > command frame > > efw-downloader: efw-proto: add function to finish a pair of > > transactions > > efw-downloader: add parser for sub commands > > efw-downloader: subcmd-device: implement 'device' sub command to > > operate actual device > > efw-downloader: subcmd-device: open firewire character device by > > HinawaFwNode > > efw-downloader: config-rom: parse config rom to detect supported > > device > > efw-downloader: subcmd-device: check supported models or not > > efw-downloader: subcmd-device: bind Fireworks protocol > > efw-downloader: node_dispatcher: add event dispatcher utilizing GLib > > MainContext/MainLoop > > efw-downloader: subcmd-device: support debug output for response of > > Fireworks protocol > > efw-downloader: efw-commands: add support for a part of hardware > > command > > efw-downloader: efw-commands: add support for commands in flash > > category > > efw-downloader: subcmd-device: add read operation > > efw-downloader: file-cntr: add parser for data binary shipped by Echo > > Digital Audio corporation > > efw-downloader: subcmd-file: add 'file' sub command > > efw-downloader: subcmd-file: add parse operation > > efw-downloader: man: add online manual > > efw-downloader: add README formatted by reStructuredText > > > > efw-downloader/COPYING | 674 ++++++++++++++++++ > > efw-downloader/README.rst | 167 +++++ > > efw-downloader/man/efw-downloader.1 | 162 +++++ > > efw-downloader/meson.build | 14 + > > efw-downloader/meson_options.txt | 5 + > > efw-downloader/src/config-rom.c | 60 ++ > > efw-downloader/src/config-rom.h | 26 + > > efw-downloader/src/efw-commands.c | 243 +++++++ > > efw-downloader/src/efw-commands.h | 57 ++ > > .../src/efw-proto-sigs-marshal.list | 1 + > > efw-downloader/src/efw-proto.c | 401 +++++++++++ > > efw-downloader/src/efw-proto.h | 80 +++ > > efw-downloader/src/file-cntr.c | 183 +++++ > > efw-downloader/src/file-cntr.h | 39 + > > efw-downloader/src/main.c | 54 ++ > > efw-downloader/src/meson.build | 54 ++ > > efw-downloader/src/node-dispatcher.c | 86 +++ > > efw-downloader/src/node-dispatcher.h | 21 + > > efw-downloader/src/op-device-read.c | 104 +++ > > efw-downloader/src/op-file-parse.c | 106 +++ > > efw-downloader/src/subcmd-device.c | 182 +++++ > > efw-downloader/src/subcmd-file.c | 87 +++ > > efw-downloader/src/subcmds.h | 16 + > > 23 files changed, 2822 insertions(+) > > create mode 100644 efw-downloader/COPYING > > create mode 100644 efw-downloader/README.rst > > create mode 100644 efw-downloader/man/efw-downloader.1 > > create mode 100644 efw-downloader/meson.build > > create mode 100644 efw-downloader/meson_options.txt > > create mode 100644 efw-downloader/src/config-rom.c > > create mode 100644 efw-downloader/src/config-rom.h > > create mode 100644 efw-downloader/src/efw-commands.c > > create mode 100644 efw-downloader/src/efw-commands.h > > create mode 100644 efw-downloader/src/efw-proto-sigs-marshal.list > > create mode 100644 efw-downloader/src/efw-proto.c > > create mode 100644 efw-downloader/src/efw-proto.h > > create mode 100644 efw-downloader/src/file-cntr.c > > create mode 100644 efw-downloader/src/file-cntr.h > > create mode 100644 efw-downloader/src/main.c > > create mode 100644 efw-downloader/src/meson.build > > create mode 100644 efw-downloader/src/node-dispatcher.c > > create mode 100644 efw-downloader/src/node-dispatcher.h > > create mode 100644 efw-downloader/src/op-device-read.c > > create mode 100644 efw-downloader/src/op-file-parse.c > > create mode 100644 efw-downloader/src/subcmd-device.c > > create mode 100644 efw-downloader/src/subcmd-file.c > > create mode 100644 efw-downloader/src/subcmds.h > > > > -- > > 2.25.1 > > > Thanks > > Takashi Sakamoto >
Hi, On Wed, Aug 26, 2020 at 01:31:53PM +0200, Takashi Iwai wrote: > On Wed, 26 Aug 2020 11:32:58 +0200, > Takashi Sakamoto wrote: > > > > Hi, > > > > Would I expect any reaction by maintainers of alsa-tools repository for > > the patches? > > I'm reviewing those patches now. Thanks for your review. > Since it's based on meson build, it'll be tricky to include this in > alsa-tools whether others are all autoconf. The tarball creation is > done in the top directory and that assumes the execution of "make > alsa-dist" in each subdirectory. Without this integration, the > directory won't be included in the release. > > Could you work on it, too? I didn't have enough care of distributing the package. Thank you for the indication. Although it's possible to write configure.ac/Makefile.am for efw-downloader, I'd like to use meson.build for my convenience, especially for the convenience of gnome module[1] in meson (Nowadays software in GNOME project including GLib is mostly build by meson). As long as I know, the concept of release creation in GNU Autotools is different from the one in meson build system. GNU Autotools distributes scripts generated from Makefile.am/configure.ac and so. On the other hand, meson distributes files maintained by git or mercurial. If we have a space to make enough arrangement for alsa-tools, the top-level Makefile should be changed to have two variables for subdirectories which includes software built by GNU Autotools and the others, then be changed further for configure/install/alsa-dist/clean targets. Nevertheless, the idea to mix all of software built by several types of build system into one repository is not so convenient itself. I'll take more time to investigate further for better packaging of alsa-tools. (Tools like Android repo is a bit over-engineering in the case, mmm) I decline the patchset for now. [1] https://mesonbuild.com/Gnome-module.html Thanks Takashi Sakamoto
On Thu, 27 Aug 2020 14:24:42 +0200, Takashi Sakamoto wrote: > > Hi, > > On Wed, Aug 26, 2020 at 01:31:53PM +0200, Takashi Iwai wrote: > > On Wed, 26 Aug 2020 11:32:58 +0200, > > Takashi Sakamoto wrote: > > > > > > Hi, > > > > > > Would I expect any reaction by maintainers of alsa-tools repository for > > > the patches? > > > > I'm reviewing those patches now. > > Thanks for your review. > > > Since it's based on meson build, it'll be tricky to include this in > > alsa-tools whether others are all autoconf. The tarball creation is > > done in the top directory and that assumes the execution of "make > > alsa-dist" in each subdirectory. Without this integration, the > > directory won't be included in the release. > > > > Could you work on it, too? > > I didn't have enough care of distributing the package. Thank you for the > indication. > > Although it's possible to write configure.ac/Makefile.am for > efw-downloader, I'd like to use meson.build for my convenience, especially > for the convenience of gnome module[1] in meson (Nowadays software in GNOME > project including GLib is mostly build by meson). > > As long as I know, the concept of release creation in GNU Autotools is > different from the one in meson build system. GNU Autotools distributes > scripts generated from Makefile.am/configure.ac and so. On the other > hand, meson distributes files maintained by git or mercurial. > > If we have a space to make enough arrangement for alsa-tools, the > top-level Makefile should be changed to have two variables for > subdirectories which includes software built by GNU Autotools and the > others, then be changed further for configure/install/alsa-dist/clean > targets. > > Nevertheless, the idea to mix all of software built by several types of > build system into one repository is not so convenient itself. I'll take > more time to investigate further for better packaging of alsa-tools. > (Tools like Android repo is a bit over-engineering in the case, mmm) > > I decline the patchset for now. OK. It's indeed awkward to mix up both auto-tools and meson. So the more suitable option would be either to modernize everything with meson, or just create a configure.ac for efw-downloader. Maybe the latter is easier, as the dependency would be only about hinawa and the check via pkgconfig is trivial even with automake. But, obviously, modernization is more appealing (with a risk of breakage, as always :) thanks, Takashi
Hi, On Thu, Aug 27, 2020 at 02:57:04PM +0200, Takashi Iwai wrote: > On Thu, 27 Aug 2020 14:24:42 +0200, Takashi Sakamoto wrote: > > On Wed, Aug 26, 2020 at 01:31:53PM +0200, Takashi Iwai wrote: > > > Since it's based on meson build, it'll be tricky to include this in > > > alsa-tools whether others are all autoconf. The tarball creation is > > > done in the top directory and that assumes the execution of "make > > > alsa-dist" in each subdirectory. Without this integration, the > > > directory won't be included in the release. > > > > > > Could you work on it, too? > > > > I didn't have enough care of distributing the package. Thank you for the > > indication. > > > > Although it's possible to write configure.ac/Makefile.am for > > efw-downloader, I'd like to use meson.build for my convenience, especially > > for the convenience of gnome module[1] in meson (Nowadays software in GNOME > > project including GLib is mostly build by meson). > > > > As long as I know, the concept of release creation in GNU Autotools is > > different from the one in meson build system. GNU Autotools distributes > > scripts generated from Makefile.am/configure.ac and so. On the other > > hand, meson distributes files maintained by git or mercurial. > > > > If we have a space to make enough arrangement for alsa-tools, the > > top-level Makefile should be changed to have two variables for > > subdirectories which includes software built by GNU Autotools and the > > others, then be changed further for configure/install/alsa-dist/clean > > targets. > > > > Nevertheless, the idea to mix all of software built by several types of > > build system into one repository is not so convenient itself. I'll take > > more time to investigate further for better packaging of alsa-tools. > > (Tools like Android repo is a bit over-engineering in the case, mmm) > > > > I decline the patchset for now. > > OK. It's indeed awkward to mix up both auto-tools and meson. > So the more suitable option would be either to modernize everything > with meson, or just create a configure.ac for efw-downloader. > Maybe the latter is easier, as the dependency would be only about > hinawa and the check via pkgconfig is trivial even with automake. > But, obviously, modernization is more appealing (with a risk of > breakage, as always :) The modernization is itself preferrable, but the idea of everything with meson is not better since we have several build systems in the world. In my opinion, the preferrable way is to enable developers to add software without limitations about its build system and dependency. As a quick glance, below applications have dependency to Gtk+2 or Gtk+3. For them, replacement with meson build system is reasonable: * echomixer * envy24control * hdajackretask * rmedigicontrol As you know, Gtk+2 is already obsoleted, thus the above should be ported to Gtk4[1]. Qlo10k1 is only an application of Qt3. I guess CMake is more preferrable than GNU Autotools in the case. As well as Gtk+2, Gt3 is already obsoleted. Hwmixvolume is written by Python 3, thus it's better to follow the standard way in Python world (setup.py). For the other software, it doesn't matter still to use GNU autotools. However, ld10k1 includes tools (ld10k1/lo10k1/dl10k1) seem to depend on local library (liblo10k1) but Makefile seems not to describe the dependency appropriately. At present, I have no proposal for the issue, but it's possible to split the software into several repositories depending on build system, like: * alsa-tools-meson * alsa-tools-cmake * alsa-tools-python * alsa-tools-autotools Then put release script to alsa-tools repository with git-submodules for them. [1] Debian Bug report logs - #967250 alsa-tools: depends on deprecated GTK 2 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967250 Regards Takashi Sakamoto