I had a bit of a brainwave regarding what might be happening with this spkmodem output. I was hoping to collect peoples thoughts in regards to weather I might be at least possibly on the right track.
When I enable spkmodem in the coreboot config, I get output from the PC speaker. But spkmodem-recv interprets the tones as consistent gibberish. The output is consistent with a mismatch in the baud rates, but there appears no apparent way to select anything different in the spkmodem-recv software. If the CPU is running coreboot as fast as possible while receiving those instructions from a relatively slow SPI bus. Is it possible that I've somehow overclocked the SPI bus, leading to a mismatch in the baud rates?
Keith Emery wrote:
When I enable spkmodem in the coreboot config, I get output from the PC speaker. But spkmodem-recv interprets the tones as consistent gibberish. The output is consistent with a mismatch in the baud rates, but there appears no apparent way to select anything different in the spkmodem-recv software.
spkmodem uses a fixed baudrate, IIRC 1200.
Did you look at a recording in a spectrum analyzer software? Maybe that would help identify modulation timing issues.
If the CPU is running coreboot as fast as possible while receiving those instructions from a relatively slow SPI bus. Is it possible that I've somehow overclocked the SPI bus, leading to a mismatch in the baud rates?
SPI isn't involved in tone timing, I think only the (emulated) legacy timer is used for that.
//Peter
I've looked at the wave forms in audacity, and tried to manually figure out if it made any sense. I think at one point I got a 'S.P.K.' which now having located and read the code that actually generates the tones. Is consistent with it's startup sequence of trying to say 'SPEAKER'. However spkmodem-recv still just prints illegible symbols.
On 6/12/21 11:59 pm, Peter Stuge wrote:
Keith Emery wrote:
When I enable spkmodem in the coreboot config, I get output from the PC speaker. But spkmodem-recv interprets the tones as consistent gibberish. The output is consistent with a mismatch in the baud rates, but there appears no apparent way to select anything different in the spkmodem-recv software.
spkmodem uses a fixed baudrate, IIRC 1200.
Did you look at a recording in a spectrum analyzer software? Maybe that would help identify modulation timing issues.
Because coreboot isn't being loaded from the SPI chip one instruction at a time. It's using the CPU cache as ram and executing from there... derp.
More sleep, more coffee. Those are basically the same thing, right!
If the CPU is running coreboot as fast as possible while receiving those instructions from a relatively slow SPI bus. Is it possible that I've somehow overclocked the SPI bus, leading to a mismatch in the baud rates?
SPI isn't involved in tone timing, I think only the (emulated) legacy timer is used for that.
//Peter _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
To verify that spkmodem.c is not the source of the issue. I decided I would try to part off the code from the console, and then compile it. Producing a wav file that I could then manually interpret, certify as good, and use to fix or replace spkmodem-recv. My efforts however were once again stumped when I realized the paired off code accessing the low level hardware with the OS still loaded, will just cause a segmentation fault.
Is there an easy way to run the executable under say QEMU, but emulating just the PC hardware rather than a whole OS?
On 7/12/21 12:46 am, Keith Emery wrote:
I've looked at the wave forms in audacity, and tried to manually figure out if it made any sense. I think at one point I got a 'S.P.K.' which now having located and read the code that actually generates the tones. Is consistent with it's startup sequence of trying to say 'SPEAKER'. However spkmodem-recv still just prints illegible symbols.
On 6/12/21 11:59 pm, Peter Stuge wrote:
Keith Emery wrote:
When I enable spkmodem in the coreboot config, I get output from the PC speaker. But spkmodem-recv interprets the tones as consistent gibberish. The output is consistent with a mismatch in the baud rates, but there appears no apparent way to select anything different in the spkmodem-recv software.
spkmodem uses a fixed baudrate, IIRC 1200.
Did you look at a recording in a spectrum analyzer software? Maybe that would help identify modulation timing issues.
Because coreboot isn't being loaded from the SPI chip one instruction at a time. It's using the CPU cache as ram and executing from there... derp.
More sleep, more coffee. Those are basically the same thing, right!
If the CPU is running coreboot as fast as possible while receiving those instructions from a relatively slow SPI bus. Is it possible that I've somehow overclocked the SPI bus, leading to a mismatch in the baud rates?
SPI isn't involved in tone timing, I think only the (emulated) legacy timer is used for that.
//Peter _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Keith Emery wrote:
To verify that spkmodem.c is not the source of the issue. I decided I would try to part off the code from the console, and then compile it. Producing a wav file that I could then manually interpret, certify as good, and use to fix or replace spkmodem-recv. My efforts however were once again stumped when I realized the paired off code accessing the low level hardware with the OS still loaded, will just cause a segmentation fault.
Is there an easy way to run the executable under say QEMU, but emulating just the PC hardware rather than a whole OS?
What if you build coreboot for emulation/qemu with spkmodem console? Does QEMU produce actual sound? I don't know whether QEMU has a speaker output.
Otherwise, you can take a chance and run your program as root in userspace after adding a call to iopl(3); before any in/out calls.
If your kernel is using the PIT then the system might lock up, but I don't expect that modern systems need the PIT so I think it's fine.
Finally, you could try compiling the source code for DOS, that should work fine on actual hardware.
//Peter
On Tue, Dec 7, 2021 at 10:00 AM Peter Stuge peter@stuge.se wrote:
What if you build coreboot for emulation/qemu with spkmodem console? Does QEMU produce actual sound? I don't know whether QEMU has a speaker output.
To add to this, QEMU will produce tones with the spkmodem console if you add "-soundhw pcspk" to your qemu command line. I have tried it, but spkmodem-recv was unable to decode the signal. I do recall being able to get it working once on actual hardware by modifying the timing in spkmodem.c such that the baud rate was some ridiculously low number like 10 baud, and then messing with the #defines in spkmodem-recv, but I don't remember what I set those defines to.
Nicholas
I spoke with Phcoder (the original author) about this ages ago, and he recommended not actually playing sound with it, but using it with an audio cable between the output device and input device. I assume you'd be able to use it at a much higher speed that way.
Martin
Dec 7, 2021, 10:37 by nic.c3.14@gmail.com:
On Tue, Dec 7, 2021 at 10:00 AM Peter Stuge peter@stuge.se wrote:
What if you build coreboot for emulation/qemu with spkmodem console? Does QEMU produce actual sound? I don't know whether QEMU has a speaker output.
To add to this, QEMU will produce tones with the spkmodem console if you add "-soundhw pcspk" to your qemu command line. I have tried it, but spkmodem-recv was unable to decode the signal. I do recall being able to get it working once on actual hardware by modifying the timing in spkmodem.c such that the baud rate was some ridiculously low number like 10 baud, and then messing with the #defines in spkmodem-recv, but I don't remember what I set those defines to.
Nicholas _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Martin Roth via coreboot wrote:
I spoke with Phcoder (the original author) about this ages ago, and he recommended not actually playing sound with it, but using it with an audio cable between the output device and input device. I assume you'd be able to use it at a much higher speed that way.
Modulation surely works better in cable but I /have/ successfully used spkmodem over air, it was just long ago and I guess neither transmitter nor receiver are tested much so maybe something is broken now..
Sound output from QEMU would be a great test; try -audiodev wav to save straight to a file; ie. digital lossless transmission.
//Peter
Unfortunately my living situation at the moment is sporadic. So I end up having to do things piecemeal from several different computers.
I tried that which was suggested below with some degree of success. QEMU produces spkmodem tones, which I recorded and emailed to myself; in the hope of being able to continue the work once I got home. Unfortunately once I got there, I discovered that the recording was an eclectic mix of spkmodem tones, family disputes, and the best of Australian Crawl. All conveniently loop mixed into the file I was trying to interpret.
So I set out to repeat the experiment on my local computer. Only to find that the current master branch of Coreboot fails to build the tool chain. I was following the tutorial to the letter, but received the following:
[redacted]/src/coreboot/util/genbuild_h/genbuild_h.sh: 59: -v: not found
The tool-chain then failed to build IASL:
Building IASL v20210331 for host ... failed. Check 'build-IASL/build.log'. make[1]: *** [Makefile:23: build_iasl] Error 1 make: *** [util/crossgcc/Makefile.inc:30: crossgcc-i386] Error 2
I checked the log, which states:
cp: cannot stat 'iasl': No such file or directory
On 8/12/21 7:11 am, Martin Roth via coreboot wrote:
I spoke with Phcoder (the original author) about this ages ago, and he recommended not actually playing sound with it, but using it with an audio cable between the output device and input device. I assume you'd be able to use it at a much higher speed that way.
Martin
Dec 7, 2021, 10:37 by nic.c3.14@gmail.com:
On Tue, Dec 7, 2021 at 10:00 AM Peter Stuge peter@stuge.se wrote:
What if you build coreboot for emulation/qemu with spkmodem console? Does QEMU produce actual sound? I don't know whether QEMU has a speaker output.
To add to this, QEMU will produce tones with the spkmodem console if you add "-soundhw pcspk" to your qemu command line. I have tried it, but spkmodem-recv was unable to decode the signal. I do recall being able to get it working once on actual hardware by modifying the timing in spkmodem.c such that the baud rate was some ridiculously low number like 10 baud, and then messing with the #defines in spkmodem-recv, but I don't remember what I set those defines to.
Nicholas _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Hi Keith,
On 10.12.21 09:28, Keith Emery wrote:
So I set out to repeat the experiment on my local computer. Only to find that the current master branch of Coreboot fails to build the tool chain. I was following the tutorial to the letter, but received the following:
[redacted]/src/coreboot/util/genbuild_h/genbuild_h.sh: 59: -v: not found
that's a known cosmetic issue. Calling `genbuild_h.sh` at that time seems spurious. I guess, you can ignore it.
The tool-chain then failed to build IASL:
Building IASL v20210331 for host ... failed. Check 'build-IASL/build.log'. make[1]: *** [Makefile:23: build_iasl] Error 1 make: *** [util/crossgcc/Makefile.inc:30: crossgcc-i386] Error 2
I checked the log, which states:
cp: cannot stat 'iasl': No such file or directory
That looks like a later error only shown because the script goes on even when the build failed. The actual error might be earlier in the log. If in doubt, please attach the whole file.
Nico
Am I correct in my understanding that bison is complaining about some component of the tool chain?
I don't remember using any different versions.
On 10/12/21 10:20 pm, Nico Huber wrote:
Hi Keith,
On 10.12.21 09:28, Keith Emery wrote:
So I set out to repeat the experiment on my local computer. Only to find that the current master branch of Coreboot fails to build the tool chain. I was following the tutorial to the letter, but received the following:
[redacted]/src/coreboot/util/genbuild_h/genbuild_h.sh: 59: -v: not found
that's a known cosmetic issue. Calling `genbuild_h.sh` at that time seems spurious. I guess, you can ignore it.
The tool-chain then failed to build IASL:
Building IASL v20210331 for host ... failed. Check 'build-IASL/build.log'. make[1]: *** [Makefile:23: build_iasl] Error 1 make: *** [util/crossgcc/Makefile.inc:30: crossgcc-i386] Error 2
I checked the log, which states:
cp: cannot stat 'iasl': No such file or directory
That looks like a later error only shown because the script goes on even when the build failed. The actual error might be earlier in the log. If in doubt, please attach the whole file.
Nico
The coreboot tool chain builder appears to have downloaded three different versions of acpica-unix2, which is apparently the provider of IASL. According to this:
https://www.acpica.org/downloads/
It requires Bison 2.4.1 or greater. Was this a recent change to the tool chain build script? I haven't had any trouble until just now.
On 10/12/21 10:56 pm, Keith Emery wrote:
Am I correct in my understanding that bison is complaining about some component of the tool chain?
I don't remember using any different versions.
On 10/12/21 10:20 pm, Nico Huber wrote:
Hi Keith,
On 10.12.21 09:28, Keith Emery wrote:
So I set out to repeat the experiment on my local computer. Only to find that the current master branch of Coreboot fails to build the tool chain. I was following the tutorial to the letter, but received the following:
[redacted]/src/coreboot/util/genbuild_h/genbuild_h.sh: 59: -v: not found
that's a known cosmetic issue. Calling `genbuild_h.sh` at that time seems spurious. I guess, you can ignore it.
The tool-chain then failed to build IASL:
Building IASL v20210331 for host ... failed. Check 'build-IASL/build.log'. make[1]: *** [Makefile:23: build_iasl] Error 1 make: *** [util/crossgcc/Makefile.inc:30: crossgcc-i386] Error 2
I checked the log, which states:
cp: cannot stat 'iasl': No such file or directory
That looks like a later error only shown because the script goes on even when the build failed. The actual error might be earlier in the log. If in doubt, please attach the whole file.
Nico
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
On 10.12.21 12:56, Keith Emery wrote:
Am I correct in my understanding that bison is complaining about some component of the tool chain?
`bison` just shows warnings. The actual problem is the C compiler showing some errors (actually just warnings, but acpica is configured to make them errors). The problematic code is generated by `flex`. So in a way your installed `flex` is not fully compatible with your installed C compiler (GCC or clang most likely). You could try dif- ferent versions of these, or try to disable the `-Werror` option when acpica is built.
Nico
I don't remember using any different versions.
In retrospect I think the multiple downloads were caused by my running make more than once. But I've since tried the same code on a completely fresh download of coreboot, with no difference. I also tried modifying the build script to use the latest version of IASL, which also made no difference. I really don't understand what could have changed to prevent IASL from building all of a sudden like that. :/
On 10/12/21 10:20 pm, Nico Huber wrote:
Hi Keith,
On 10.12.21 09:28, Keith Emery wrote:
So I set out to repeat the experiment on my local computer. Only to find that the current master branch of Coreboot fails to build the tool chain. I was following the tutorial to the letter, but received the following:
[redacted]/src/coreboot/util/genbuild_h/genbuild_h.sh: 59: -v: not found
that's a known cosmetic issue. Calling `genbuild_h.sh` at that time seems spurious. I guess, you can ignore it.
The tool-chain then failed to build IASL:
Building IASL v20210331 for host ... failed. Check 'build-IASL/build.log'. make[1]: *** [Makefile:23: build_iasl] Error 1 make: *** [util/crossgcc/Makefile.inc:30: crossgcc-i386] Error 2
I checked the log, which states:
cp: cannot stat 'iasl': No such file or directory
That looks like a later error only shown because the script goes on even when the build failed. The actual error might be earlier in the log. If in doubt, please attach the whole file.
Nico _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
On Sat, Dec 4, 2021 at 10:26 PM Keith Emery k.emery.nbn@internode.on.net wrote:
spkmodem-recv software. If the CPU is running coreboot as fast as possible while receiving those instructions from a relatively slow SPI bus. Is it possible that I've somehow overclocked the SPI bus, leading to a mismatch in the baud rates?
I don't think that the speed of the SPI bus would have any noticable effect, as it's still several orders of magnitude faster than the rates that spkmodem deals with. Looking through the code, I've determined that the protocol is as follows: - 200 Hz tone when idle - Each character is sent out bit by bit as a 2 kHz tone for 5ms for a 1 bit and a 4 kHz tone for 5 ms for a 0 bit (which works out to 200 baud) - 1 kHz tone for 5 ms signalling the end of the character
However, the SPI bus typically runs at tens of MHz, which should be plenty enough to have no effect on spkmodem transmission. Even if it did slow down the instruction retrieval rates by a significant amount, the most likely effect would just be prolonging the length of each tone, as that appears to be the most timing sensitive code. Also, the tones are generated by the (emulated) PIT timer, which, once programmed, should produce the set frequency independent of everything else. Since each bit is mapped to different frequencies, the actual baud rate it is running doesn't technically matter, and the receiving code should only be looking for changes in frequency to decode the data.
Based on this I think spkmodem-recv and/or the methods of recording the output are more likely to blame. The spkmodem-recv code is very picky about the format of the recorded signal, as it implements its own decoding directly from the sampled audio data. I've looked at its code and it's sort of a mess, and it is somewhat difficult to understand the decoding algorithm at first glance. From some initial analysis I think it's also picky about the exact timings and possibly even the volume of the tones, but it looks like there are some defines at the top which appear to be thresholds of some sort. You could try messing around with those to see if they change anything, but it would take me a bit more time to figure out exactly how the decoding algorithm works.
Regards, Nicholas
-
Keith Emery -
Martin Roth -
Nicholas -
Nico Huber -
Peter Stuge