Hello!
I decided to revisit an old project from those days, and found that it
built almost correctly, after making a number of changes. For example
it looked as if our friend Eric was the originator behind it. I needed
to change his work directory settings to match the one I set up for
this interpretation of the process to build for an oldy but a goody.
It's the build process for the Intel 440GX, and the script file I'm
putting on this message shows what is happening towards the ending.
But it wasn't a normal ending, and I believe it could be easily
explained by a missing utility.
I can supply the original blob the things below came from. And I
remember a discussion as to what the target would have been found in,
I myself find it interesting that it's the original target that was
used for the Bochs project that's still running after about as many
years as I've known about our project.
-----
Gregg C Levine gregg.drwho8(a)gmail.com
"This signature fought the Time Wars, time and again."
Previously it works, but now #coreboot needs registered nicks.
On Mon, Oct 29, 2018 at 3:43 AM Patrick Georgi via coreboot <
coreboot(a)coreboot.org> wrote:
> Not sure if that is still working but
> https://matrix.org/blog/2015/06/22/the-matrix-org-irc-bridge-now-bridges-...
> should help connect to IRC via matrix.
>
> Choose your own protocol ;-)
>
> Am So., 28. Okt. 2018, 15:11 hat Philipp Stanner <stanner(a)posteo.de>
> geschrieben:
>
>> Hey,
>>
>> have you guys already heard of Matrix?
>> https://matrix.org/blog/home/
>>
>> It's some sort of modern IRC, using JSON to format messages. It's more
>> modern than IRC. Features are:
>> * Source code formatting and highlighting in messages
>> * multiple devices
>> * history + history synchronization between multiple devices
>> * possible E2C encryption
>>
>> and many more.
>> In theory it will be a decentralized protocol, but there aren't that
>> many servers yet and actually only one working server-software
>>
>> Many projects, especially tech-based ones like the Rust programming
>> language already use the service.
>>
>> Personally I think it's an enormous progress to IRC. I would give it a
>> chance if I were you :)
>>
>> P.
>>
>> --
>> coreboot mailing list: coreboot(a)coreboot.org
>> https://mail.coreboot.org/mailman/listinfo/coreboot
>>
> --
> coreboot mailing list: coreboot(a)coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
--
My website: https://vimacs.lcpu.club
Please do not send me Microsoft Office/Apple iWork documents. Send
OpenDocument instead! http://fsf.org/campaigns/opendocument/
Hi,
Dne 25. 10. 18 v 9:17 Zheng Bao napsal(a):
> Any more ideas? Thanks.
Maybe the bus topology is different in coreboot. It would explain why SATA works, because it is on bus 0.
Thanks,
Rudolf
I suggest you better check
1. power on sequence,
2. every power/ voltage rail stability during boot process.
3. Over/undershoot.
4. all crystal osc frequency stability during boot process.
5. Try to print the DID early during bootblock and romstage.
Provide your observations.
Regards,
Naresh G Solanki
Hi,
We are building a FSP integrated coreboot image. We are using Intel FSP 2.0.
While booting the coreboot image we get the following FSP performance data logs.
Coreboot FSP Performance Data
ID: 950 - 951: 2347842343 - 2126500026 --> 170ms
ID: 952 - 953: #^!1175958314 - 3141289776 --> 1792ms
ID: 954 - 955: #^!1702555243 - #^!1465185826 --> 182ms
ID: 956 - 957: #^!1094328449 - #^!1091128442 --> 2ms
ID:952 - 953 is FSP_TEMP_RAM_EXIT which takes around 1.7 sec. Below are the queries:
1. What is happening in FSP_TEMP_RAM_EXIT phase ?
2. Can we reduce this time further ?
Please provide your feedback.
Thanks & Regards,
Antony
L&T Technology Services Ltd
www.LntTechservices.com<http://www.lnttechservices.com/>
This Email may contain confidential or privileged information for the intended recipient (s). If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system.
Hi,
Dne 23. 10. 18 v 1:57 Marc Jones napsal(a):
> Does VxWorks use the ACPI tables for IRQ routing? You might need that.
Yes good question. Usually OS uses ACPI, or MPTable or what BIOS provided in
the PCI device itself.
It seems because you are asking for the virtual wire mode IOAPIC is not supported and legacy PIC mode
maybe needed?
Does this OS configure LINT0 for ExtINT on at least one CPU? (this is how virtual wire can be implemented)
Or second way to do that, is to program IO-APIC 0 or 2 depending on chipset to ExtInt. This will cause PIC interrupts
to be delivered to the CPU.
Please note that for PCI devices you also need to program PCI IRQ router and ELCR register if you are going to use the PIC mode,
Thanks
Rudolf
Can any one recommend a source for basic pc bios info? There's a lot to learn and some good links would be greatly appreciated. I'm a geek but I don't know much about bios code, data structures relevant to bioses, etc.
Hello,
In the latest cbfstool I am missing the capability to control the location of a XIP stage.
A XIP stage is always located on the first available position.
So far I haven't found a way to either define the position (the base parameter conflicts with the XIP one) and I also haven't been able to make it fill downwards which is sufficient as well.
Am I overlooking something or have these possibilities been removed?
Best regards,
Wim Vervoorn
