In that case, I'd also like to point you to the deadline for submitting
main track talks which is tomorrow(!).
https://fosdem.org/2019/news/2018-08-10-call-for-participation/
Having a coreboot/LinuxBoot talk there would be awesome. Ron/David,
could you submit something or do you have someone in mind who can do that?
There's also lightning talks, deadline is a bit later.
OK, I'm submitting a request for a stand. I need a backup contact for
the stand. Who is willing to do that? AFAICS we can still change the
backup contact later if life happens.
Regards,
Carl-Daniel
On 02.11.2018 20:48, David Hendricks wrote:
>
>
> On Fri, Nov 2, 2018 at 9:15 AM 'Ron Minnich' via linuxboot
> <linuxboot(a)googlegroups.com <mailto:linuxboot@googlegroups.com>> wrote:
>
> I"m leaning to yes, by which I mean if you do it, I'll show up.
>
> I can't believe I said that.
> On Fri, Nov 2, 2018 at 7:20 AM Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006(a)gmx.net
> <mailto:c-d.hailfinger.devel.2006@gmx.net>> wrote:
> >
> > Hi!
> >
> > FOSDEM next year will be on 2 & 3 February 2019.
> > The deadline for applying for a stand is today.
> > Do we want a coreboot/flashrom/LinuxBoot stand/booth?
>
>
> Same as what Ron said. I think someone from FB can be there to talk
> about coreboot/LinuxBoot stuff and perhaps bring some hardware to demo.
>
>
Hi Ivan,
On 03.04.2018 20:03, Ivan Ivanov wrote:
> I have noticed that both coreboot and seabios are using the very old
> versions of LZMA SDK.
True. I introduced the lzma code in coreboot (back when it was called
LinuxBIOS) when we were working on OLPC XO-1 support.
> If we will upgrade our LZMA libraries from the
> outdated-by-12-years 4.42 to the current version 18.04 , speed and
> compression ratio should improve and maybe a few bugs will be fixed.
Do you have any numbers for this? An improved compression ratio and
improved speed would be nice indeed, but how does the size of the
decompression code change? If the decompression code grows more than the
size reduction from better compression, it would be a net loss. A
significantly reduced decompression speed would also be a problem.
Decompression speed would have to be measured both for stream
decompression (i.e. the decompressor gets the compressed data in
single-byte or multibyte chunks) as well as full-size decompression
(i.e. the decompressor can access all compressed data at once). We also
have to make sure that stream decompression still works after the change.
> Do you think it should be done, or you are OK with using such an
> outdated version?
A size benefit for the resulting image is a good reason to switch.
Regards,
Carl-Daniel
Hi folks,
is there a branch that has all the outstanding KGPE-D16 changes merged? I will be happy to test, but I feat I won't find the time to test all those fixes each in a separate branch. Also some specification of what tests need to be conducted would help.
The outstanding KGPE-D16 bugs on my personal list are boot failures that require to turn off/on AC and the power consumption issues in idle that forced me to pull out one of the CPU packages and its RAM. But as far as I understood these were not targeted in the recent changes but could be "accidentially" fixed (e.g. by removal of some old buggy code) - correct?
Cheers, Daniel
Hi,
I have a question reguarding the build process.
Since crossgcc has been updated and gcc is now at version 8.1 I always
encounter an error when building coreboot:
coreboot/src/console/vtxprintf.c:102: undefined reference to
'__udivmoddi4'
Since coreboot uses crossgcc and its own libgcc libraries, I figured
that the __udivmoddi4 function has not yet been implemented.
Anyway I have incurred in this failure several times and even with the
latest 4.9 release. Shouldn't I be able to build at least this latest
release using unmodified crossgcc or am I missing something else?
thanks,
salvatore
Dne 30.5.2018 v 16:06 Mike Banon napsal(a):
> Hi Rudolf,
>
> Regarding this part:
> " To check if IMC is active check if PCI 0:14.3 0x40 bit7 set. "
> what command do I need to use to check this?
Try:
sudo setpci -s 14.3 40.b
Despite command name, it will print the value.
Thanks
Rudolf
I tried to adapt coreboot to HiFive-Unleashed and boot bbl with coreboot and run linux.
My changes are as follows:
https://github.com/hardenedlinux/coreboot-HiFiveUnleashed/tree/HiFive-Unl...
My code can run bbl, but it doesn't respond when bbl exits m-mode and enters linux.
I use freedom-u-sdk to compile bbl. In order not to conflict with the coreboot memory address, execute the following command.
riscv64-elf-objcopy --change-addresses 0x200000 work/riscv-pk/bbl ../coreboot/payload.elf
I don't know what I missed, what should I do, I hope to get your help.
------------------
王翔
安全研究员
广州市腾御安信息科技有限公司
广州市天河区珠江新城华穗路406号保利克洛维二期中景A座1020-1024
Had a lot of access problems recently, both to coreboot website and
its' repositories. Was it a DDoS attack? How to make sure that the
sources at review coreboot repository haven't been modified during
this event?
Best regards,
Ivan
Hi,
Season's greetings to everyone! :-)
I've been able to get my Asus KGPE-D16 running with coreboot 4.6 and Qubes 4 and I'm pleased to report it has been nice and stable over the holiday period, save for a few minor issues.
Suspend works fine on a fresh install of Qubes 4, however applying the latest updates then stops this from working. (It goes in to suspend but does not resume properly). I'm assuming this is now a Qubes issue.
My Intel Optane 900p NVME drive does not work reliably with Qubes 4. It initially appears fine but anywhere between 4-12 hours after boot the system will panic and switch to a read-only file system - you can't run any commands without an "Input/Output Error" even in Dom 0. The only course of action when this is encountered appears to be a hard reset. Unsurprisingly, getting any kind of logs about what is actually happening has proven fruitless so far :-(
I have therefore switched to a normal SATA drive for the last week and this has been nice and stable. I suspect my best course of action to get a higher performing filesystem is to move to 4 SATA SSDs in RAID 10. If anyone has any other suggestions to get faster drive access with this platform (particularly good random read/write performance for using lots of concurrent VMs in Qubes) or possible approaches to fix my NVME drive issue, they would be much appreciated.
My only other minor issue at the moment is lack of fan control. If I run "sudo pwmconfig" in dom0 I get the message "There are no pwm-capable sensor modules installed". I suspect I need to enable some additional modules, so if anyone can provide me some explicit directions on how to do this, it would again be much appreciated.
Kind regards,
Pete
Hello there, I have a question regarding coreboot.
I was wondering if work was still being done to port coreboot to the Dell
OptiPlex 7010. I was looking at commit
882d3c3574cc24f1bcf16b71c5090cc71ef725a6, but it seems the board didn’t
boot at that stage in time. I have also not found much information
regarding 4f19f4a7ebe7783830343d5ffc917142266fabf9 either, so I was
wondering if work was still being done to port coreboot to the OptiPlex
7010, given its stock firmware doesn’t really work that great (I'd be happy
to elaborate), even at revision A29, so I wanted to replace it with
coreboot.
Thanks.
Hello,
I just started looking into adding support for the dell r610. This is
mostly because you can get them really cheap and they perform well for
my type of workloads. However looking at the wiki it looks like I have
my work cut out for me if I am able to do this at all. From the
following dump it looks like I have a currently unsupported chipset,
cpu, and superIO.
$ root@plex-8316f3de71:~# dmidecode -t 2
# dmidecode 3.1
Getting SMBIOS data from sysfs.
SMBIOS 2.6 present.
Handle 0x0200, DMI type 2, 9 bytes
Base Board Information
Manufacturer: Dell Inc.
Product Name: 0K399H
Version: A03
Serial Number: ..CN697029680164.
Asset Tag: Not Specified
$ root@plex-8316f3de71:~# superiotool -d
superiotool r6637
Found SMSC EMC2700LPC (id=0x67, rev=0x01) at 0x2e
No dump available for this Super I/O
$ root@plex-8316f3de71:~# inteltool
CPU: ID 0x106a5, Processor Type 0x0, Family 0x6, Model 0x1a, Stepping
0x5
Northbridge: 8086:3403 (unknown)
Southbridge: 8086:2918 (ICH9)
It looks like I will have to contact SMSC which was acquired by
microchip in 2012 so hopefully they are still able to give me the
datasheet. Additionally I will need to get the datasheet from intel for
CPU north/south bridge which from the docs sounds like it might take a
while if they will even give it to me at all.
Does this seem like a good place to start? I wasn't able to find much
outside of https://www.coreboot.org/Developer_Manual so figured I would
ask for a little bit of help getting started on the mailing list first.
Thanks for looking
