[coreboot] Re: spkmodem output

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

[coreboot] Re: spkmodem output

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

[coreboot] Re: spkmodem output

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

[coreboot] Re: spkmodem output

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

[coreboot] Re: spkmodem output

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

[coreboot] Re: spkmodem output

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

[coreboot] Re: Does PCI driver code belong in coreboot (ARM)?

On a semi related topic, a significant issue exists in the absence of a one stop shop debug option that works universally on all x86 platforms. The lack of universality means that people can only realistically work on boards for which they can get a reliable debug output. That massively

[coreboot] Re: How to maintain AGESA-based ports long-term?

rks". You then have 50 boards to get working. and even then, at real world rates, 100 hours -> 25,000. There's only so much we can do. I at least would be way happier to see effort going into new boards. On Sat, Dec 4, 2021 at 8:48 PM Keith Emery mailto:k.emery@in

[coreboot] spkmodem output

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

[coreboot] Re: How to maintain AGESA-based ports long-term?

minnich wrote: 100 hours of work for 50 boards? 2 hours per board? Each one fully tested and working as before? 'm pretty surprised. On Sat, Dec 4, 2021 at 4:38 AM Keith Emery wrote: Getting the listed AGESA boards operating on the new scheduler is estimated to take around 100 hours of work. So

[coreboot] Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3

I'm happy to contribute financially. It just comes with the caveat that I need to know with some surety that I can finally have a working board at the end of it. On a side note is there any kind of crowd sourcing platform / escrow service for GPL projects? I know it's been talked about, and

[coreboot] Re: "Private" changes on Gerrit are now disabled and removed

. November 2021 10:31, "Keith Emery" schrieb: I'm fairly sure it say's 'you must publish the source code AND any changes'. Did that change at some point? I'm fairly sure that you don't understand the conditions under which the GPL takes effect. Since I'm not your lawyer, I won't discuss thi

[coreboot] Re: "Private" changes on Gerrit are now disabled and removed

more than a bit difficult for the best part of 5 years, maybe more. How many people have been making 'private' changes to GPL code? On 12/11/21 6:04 pm, Patrick Georgi wrote: 12. November 2021 03:47, "Keith Emery" schrieb: Um... It's said feature illegal? Sorry, but I don't

[coreboot] Re: spkmodem-recv

Stuge wrote: Keith Emery wrote: Can somebody please verify that the attached file can be interpreted by spkmodem-recv? $ sox test.wav -t s16 -L -c 1 -r 48000 - | ./spkmodem-recv | xxd 000: 25 % $ A single '%' is output. Is that what you would expect

[coreboot] Re: Atomic Accesses to Local APIC

https://youtu.be/qpMvS1Q1sos I'm sorry. :( On 6/10/21 7:47 am, Matt B wrote: My concern is more about surprise brokenness when trying to use the newest version, if any of those pentiums remain. On Tue, Oct 5, 2021 at 4:06 PM ron minnich > wrote: That's what

[coreboot] Re: Coreboot on newer laptops

Is that module functional? It refused to compile when I tried it for F2A85-M. On 17/9/21 1:29 am, Andreas Bauer wrote: If you don't have serial on the platform, the next best option is to enable flash log and read back the rom after an boot attempt.

[coreboot] Re: Coreboot on newer laptops

Have we physically checked to determine if the ME uses e-fuses and not a poly switch. Or are we just trusting Intel on these matters? On 17/9/21 12:37 am, Brian Milliron wrote: Using a hardware flasher isn't a workaround, the signature check is done in hardware by the ACM using keys fused into

[coreboot] Re: Firmware another laptop

client inxi: 3.0.38 Sent with ProtonMail <https://protonmail.com/> Secure Email. ‐‐‐ Original Message ‐‐‐ Il venerdì 20 agosto 2021 00:11, Keith Emery ha scritto: I think you meant to ask if it's possible to do. That can't be answered without more information about

[coreboot] Re: Firmware another laptop

I think you meant to ask if it's possible to do. That can't be answered without more information about the hardware... A lot more. At a minimum the precise model of mainboard, or a precise model number. On 20/8/21 12:02 am, Stefano via coreboot wrote: Good morning I can install the coreboot

[coreboot] Re: Build for F2A85-M Foobared, any ideas?

, Peter Stuge wrote: Hi Keith, Paul Menzel wrote: https://review.coreboot.org/plugins/gitiles/board-status/+/71278e2819996f2e6b0ac9ff444e5d31b8073677 Keith Emery wrote: It’s in the path name or logs in the directory I referenced: 4.13-917-g192177d34d refers to commit hash 192177d34d. I've tried

[coreboot] SPI Flash console output

Does anybody happen to know when or why SPI Flash console output broke? I kind of need it. The build only fails when I enable said option. The error is as follows, name of home directory redacted: coreboot/util/crossgcc/xgcc/bin/i386-elf-ld.bfd: build/bootblock/drivers/spi/spi-generic.o: in

[coreboot] Re: Build for F2A85-M Foobared, any ideas?

On 16/8/21 8:43 pm, Paul Menzel wrote: It’s in the path name or logs in the directory I referenced: 4.13-917-g192177d34d refers to commit hash 192177d34d.         I've tried both hash's refrencing both sucessfull builds for F2A85-M board. I just get:         error: pathspec '192177d34d' did

[coreboot] Build for F2A85-M Foobared, any ideas?

coreboot-4.14-1405-gad08265740-dirty Sun Aug 15 07:12:41 UTC 2021 bootblock starting (log level: 7)... CBFS: Found 'fallback/romstage' @0x30e00 size 0x4c910 in mcache @0x00034f7c BS: bootblock times (exec / console): total (unknown) / 12 ms coreboot-4.14-1405-gad08265740-dirty Sun Aug 15

[coreboot] Openbiosprog-spi

G,day all I just made an order on PCB cart for the OpenBiosprog_spi. As a result of mild brain damage on my part; I went ahead and ordered 200 boards. So in light of the above I am happy to mail out as many boards as anyone might want for the low low price of $1.20 AUD plus postage. Spread