Re: [coreboot] [RFC] board_status: Add serial log to `serial_console.txt`
I 'm with Vladimir on this one. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFC] board_status: Add serial log to `serial_console.txt`
On 19.02.2014 00:18, Paul Menzel wrote: >>> > > But in general I think I agree with Vladimir. CBMEM console should be >>> > > supported and if not then that should be fixed. > I also agree, but it’ll take more time and the above is a good > work-around for the mean time. Strongly disagree workarounds are like glue: they stick around. This one is one that will stick around once implemented. It's better to avoid workarounds if sane solution is within reach. In this case you still haven't even named a single board where CBMEMC doesn't work. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFC] board_status: Add serial log to `serial_console.txt`
Am Dienstag, den 11.02.2014, 00:04 +0100 schrieb Vladimir 'φ-coder/phcoder' Serbinenko: > On 10.02.2014 23:47, David Hendricks wrote: > > On Sun, Feb 9, 2014 at 4:50 AM, Paul Menzel wrote: > > currently no coreboot messages are stored for boards not supporting > > CBMEM console (or where this option is disabled (currently by default)) > > or no coreboot *romstage* messages are stored for boards, where the data > > cannot be preserved (passed to ramstage). > > > > Using the serial (or USB) console all these messages can be captured > > with no problem, so I propose to just add these captured messages into > > the file `serial_console.txt`. Of course this file probably contains > > also the payload and (Linux) kernel log, but I think that is fine. > > > > SeaBIOS’ `readserial.py` should be used for capturing the messages as it > > adds time stamps. > > > > Scripting this is going to be hard, as the log is captured on a > > different system. So for now I propose to add it manually. > > > > > > I don't think the script itself should be responsible for collecting > > serial output. Instead, how about adding an argument to override the > > default behavior of running "cbmem -c" on the target so that the user > > can pass in a filename? The user will simply capture the serial output > > using whatever tool they like, dump the output to a text file, and run > > the script with an argument to use the file instead of calling "cbmem > > -c". Here is a proof-of-concept: http://review.coreboot.org/#/c/5191 . David, thanks a lot for implementing this. > This requires user to do right manipulations. While keyboard and chair > are usually fine, the space between them exhibits strong bug-inducing > properties. The idea of the script is to reduce a possibility of user > error creating strange reports. In this case the common error I expect is > using a stale file from some other version. It's a particularly nasty one > as at first glance in may look fine but would be almost useless to track > how details changed from one submit to the next. If we let user supply > files at all, it should be added to report, not replace files, and it > should have some prefix to clearly indicate that user was involved in > creating them. E.g. user_serial_log.txt I agree with Vladimir that the file should be put there with a separate name. I am not sure about a common name though, as it could be also captured using a USB debug device or spkmodem(?). > > But in general I think I agree with Vladimir. CBMEM console should be > > supported and if not then that should be fixed. I also agree, but it’ll take more time and the above is a good work-around for the mean time. Thanks, Paul signature.asc Description: This is a digitally signed message part -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coding for free
how much money do you have to buy hardware that coreboot supports? That's always a first step. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] A Growing Concern
all of these upcoming devices? not practical. If you care that much, you have to vote with your money, and you have to accept that you'll get something not entirely what you wanted in features. ron On Tue, Feb 18, 2014 at 1:01 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > On 18.02.2014 06:21, amlo...@tfwno.gf wrote: >> As a privacy and freedom oriented PC/Linux user, it scares me how modern >> day devices are becoming extremely proprietary. Companies are beginning >> to ship their laptops/tablets with proprietary EFI systems which have >> some nasty things in them. I recently purchased a Dell Venue 8 Pro(one >> of many upcoming 8" windows 8.1(x86) tablets) and while i was searching >> through its BIOS, i noticed that it had the computrace option activated. >> After disabling it, i decided to try to put coreboot on it, only to find >> that its non-existent for my device. Although it says that its disabled, >> i dont trust it one bit. While it is a beautiful, fast and >> ultra-portable PC, it bothers me how there are no free alternatives for >> it. These types of devices are growing in numbers and will most likely >> continue on through the years. >> >> All I ask of you is to try and make EFI alternatives to all these >> upcoming devices. >> > All of them? Possible but will probably cost you millions in workforce. > If you really want coreboot on some devices that interest you, you'll > have to back it up with either work(do port yourself) or money (hire > someone, you can post a bounty) >> > > > > -- > coreboot mailing list: coreboot@coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] A Growing Concern
On Tuesday, February 18, 2014 12:21:38 AM amlo...@tfwno.gf wrote: > As a privacy and freedom oriented PC/Linux user, it scares me how modern > day devices are becoming extremely proprietary. Companies are beginning > to ship their laptops/tablets with proprietary EFI systems which have > some nasty things in them. I recently purchased a Dell Venue 8 Pro(one > of many upcoming 8" windows 8.1(x86) tablets) and while i was searching > through its BIOS, i noticed that it had the computrace option activated Well, it's your fault that this concern is growing. You bought a windows device. You paid microsoft to develop proprietary software, and you paid an IVB to develop proprietary firmware, instead of paying someone to develop free software and firmware for your device. The market is rich enough to allow you to make that choice. > All I ask of you is to try and make EFI alternatives to all these > upcoming devices. So, you paid someone to write firmware, which you neither trust nor like, but want me to do it for free? If software/firmware freedom is important to you, then I suggest you return the device to the store -- assuming you have this option -- and purchase a device which offers you what you want. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] A Growing Concern
On 18.02.2014 06:21, amlo...@tfwno.gf wrote: > As a privacy and freedom oriented PC/Linux user, it scares me how modern > day devices are becoming extremely proprietary. Companies are beginning > to ship their laptops/tablets with proprietary EFI systems which have > some nasty things in them. I recently purchased a Dell Venue 8 Pro(one > of many upcoming 8" windows 8.1(x86) tablets) and while i was searching > through its BIOS, i noticed that it had the computrace option activated. > After disabling it, i decided to try to put coreboot on it, only to find > that its non-existent for my device. Although it says that its disabled, > i dont trust it one bit. While it is a beautiful, fast and > ultra-portable PC, it bothers me how there are no free alternatives for > it. These types of devices are growing in numbers and will most likely > continue on through the years. > > All I ask of you is to try and make EFI alternatives to all these > upcoming devices. > All of them? Possible but will probably cost you millions in workforce. If you really want coreboot on some devices that interest you, you'll have to back it up with either work(do port yourself) or money (hire someone, you can post a bounty) > signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Coding for free
Hey, I am Nitin Issac Joy, 2nd Year Computer Science Engineering Student from India, wanting to contribute to coreboot. I want more hand-on experience with ASM and interfacing which is the reason why I am doing this. I know more than basic ASM, well versed in C. Can anyone of you guide me? Thankyou -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Ram Init: Intel i945: Timing parameters
Thanks Peter once again for helpful information. I was reading code line by line and going through i945 Express chipset document, tried to understand register settings and values. Seems to be tough job writing RAM init, and wouldn't have been possible without any documentation. Don't understand why Intel has made DRAM controller setup/Ram-init documentation NDA, and have made chipset documentation public ** Important Note This email (including any attachments) contains information which is confidential and may be subject to legal privilege. If you are not the intended recipient you must not use, distribute or copy this email. If you have received this email in error please notify the sender immediately and delete this email. Any views expressed in this email are not necessarily the views of IRESS Limited. It is the duty of the recipient to virus scan and otherwise test the information provided before loading onto any computer system. IRESS Limited does not warrant that the information is free of a virus or any other defect or error. ** -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Trouble with coreboot for Roda RK9 15" and 17"
Hello Dmitry, Am 03.02.2014 09:42, schrieb Дмитрий Багрянский: > Hello Nico, > > Could you please help me to solve some problems? > Laptop: Roda RK9 15" and 17" > > With model 13" the coreboot works well, but as for 15" and 17" models we > faced with the following problems: > 15" - I add vga bios from native BIOS Phoenix and when it is loading the > screen is brightened but the text may be distinguised. > 17" - I do the same actions, but when it is loading the screen is white and > then fades. There is one setting in the int15 handler that might be related to your problem. Have a look in `src/mainboard/roda/rk9/mainboard.c` line 72 (the 0x5f40 case). I don't recall exactly what this does, but according to the comment, we read the setting from the DIP-switch near the LVDS connectors. Maybe we've got the mapping for the DIP-switch values wrong. You could try values from 0x00 to 0x0f for X86_CX. Or adjust the offest: +2 instead of +1 did also work on the machine we did the original port for. Hope that helps. If it does, please share your findings. Best regards, Nico > > As for the 13" model there are no problems, everything works well with VGA > Bios. > > Thank you > Best regards, Dmitry Bagryanskiy. > -- M. Sc. Nico Huber Berater, SINA-Softwareentwicklung Public Sector secunet Security Networks AG Tel.: +49-201-5454-3635, Fax: +49-201-5454-1325 E-Mail: nico.hu...@secunet.com Mergenthalerallee 77, 65760 Eschborn, Deutschland www.secunet.com __ Sitz: Kronprinzenstraße 30, 45128 Essen, Deutschland Amtsgericht Essen HRB 13615 Vorstand: Dr. Rainer Baumgart (Vors.), Willem Bulthuis, Thomas Pleines Aufsichtsratsvorsitzender: Dr. Peter Zattler __ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Ram-init: Intel i945: sdram_detect_cas_latency_and_ram_speed
Thanks Peter for your support. I will have a look at provided links. ** Important Note This email (including any attachments) contains information which is confidential and may be subject to legal privilege. If you are not the intended recipient you must not use, distribute or copy this email. If you have received this email in error please notify the sender immediately and delete this email. Any views expressed in this email are not necessarily the views of IRESS Limited. It is the duty of the recipient to virus scan and otherwise test the information provided before loading onto any computer system. IRESS Limited does not warrant that the information is free of a virus or any other defect or error. ** -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Ram Init: Intel i945: Timing parameters
Thanks Vald ... not possible to break intel safe :).. wondering how coreboot team was able to write i945 ram init? ** Important Note This email (including any attachments) contains information which is confidential and may be subject to legal privilege. If you are not the intended recipient you must not use, distribute or copy this email. If you have received this email in error please notify the sender immediately and delete this email. Any views expressed in this email are not necessarily the views of IRESS Limited. It is the duty of the recipient to virus scan and otherwise test the information provided before loading onto any computer system. IRESS Limited does not warrant that the information is free of a virus or any other defect or error. ** -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] A Growing Concern
As a privacy and freedom oriented PC/Linux user, it scares me how modern day devices are becoming extremely proprietary. Companies are beginning to ship their laptops/tablets with proprietary EFI systems which have some nasty things in them. I recently purchased a Dell Venue 8 Pro(one of many upcoming 8" windows 8.1(x86) tablets) and while i was searching through its BIOS, i noticed that it had the computrace option activated. After disabling it, i decided to try to put coreboot on it, only to find that its non-existent for my device. Although it says that its disabled, i dont trust it one bit. While it is a beautiful, fast and ultra-portable PC, it bothers me how there are no free alternatives for it. These types of devices are growing in numbers and will most likely continue on through the years. All I ask of you is to try and make EFI alternatives to all these upcoming devices. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Untangling the UART
Hey! I have posted first half for series of patches that should untangle the mess of multiple different prototypes for the simple thing of getting some console output out of UART. There is little practical use of being able to compile coreboot with multiple type of UARTs in same build, so we can use same function prototypes for all different type of UARTs once we sort out the issue with passing the base address argument. Solving this part is available for review now on gerrit. Easiest way to access these in gerrit is to find CL 'SMM: Only have console with DEBUG_SMI', and check its dependencies. http://review.coreboot.org/#/c/5142 Thanks, Kyösti -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] how to model the Quark architecture
On Tue, Feb 18, 2014 at 10:33 AM, Peter Stuge wrote: > ron minnich wrote: >> I can't understand the point here. >> docs or code would help. > > Aaron Durbin wrote: >> Could you please provide explicit examples having c struct fields >> represented in devicetree that model another address space? > > No I can not. > > I do not have the capacity to deliver the ready-made architecture to > you guys. > > > I'm sorry I said anything, I was silly to think that design > discussion would be possible. I'm sorry you feel that way. I was asking for an example so I could better understand what you were getting at. You mentioned HT being a mistake, and since you noted that I was hoping you had an idea on what you wanted to see. And I don't think anyone was asking for a 'ready-made architecture.' I was seeking clarity. You clearly have opinions on mistakes made in the past, and I was seeking expansion on those opinions aside from the initial statements. Were you wanting some sort of attribute that suggested there is another address space of registers that need to be accessed? And all those registers detailed? -Aaron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] how to model the Quark architecture
On Tuesday, February 18, 2014 07:33:43 PM Peter Stuge wrote: > I'm sorry I said anything, I was silly to think that design > discussion would be possible. > I've been following this thread for the last couple of days, and I still have no idea what you're talking about. I bet mostly everyone else feels that way. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] how to model the Quark architecture
ron minnich wrote: > I can't understand the point here. > docs or code would help. Aaron Durbin wrote: > Could you please provide explicit examples having c struct fields > represented in devicetree that model another address space? No I can not. I do not have the capacity to deliver the ready-made architecture to you guys. I'm sorry I said anything, I was silly to think that design discussion would be possible. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] how to model the Quark architecture
On Tue, Feb 18, 2014 at 10:11 AM, Peter Stuge wrote: > Aaron Durbin wrote: >> > I think the most obvious thing is the message port architecture? >> > >> > Sure, we can skip modeling them and create some global functions for >> > sending messages to random ports, but that wouldn't be very impressive.. >> >> What do you mean by modeling them? > > Compare with how HT (doesn't) works, or with PCI. In what way? Something that is probe-able? And something that isn't? > > >> What is an impressive implementation for sending messages to ports? >> It's just another address space through index/data pairs. > > That's exactly what I disagree with. There is an architecture and I > would expect coreboot to model it rather than dumping an array of > magic number pairs into index/data. > > The coreboot devicetree doesn't model HT so well - it is treated as > "another address space". I think it would be better to avoid > repeating such a mistake? What is it that you are suggesting/wanting devicetree to do what in this case? I am failing to understand the mistake you are referring to. Could you please provide explicit examples having c struct fields represented in devicetree that model another address space? -Aaron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] how to model the Quark architecture
This is all pretty nebulous. I can't understand the point here. docs or code would help. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] how to model the Quark architecture
Aaron Durbin wrote: > > I think the most obvious thing is the message port architecture? > > > > Sure, we can skip modeling them and create some global functions for > > sending messages to random ports, but that wouldn't be very impressive.. > > What do you mean by modeling them? Compare with how HT (doesn't) works, or with PCI. > What is an impressive implementation for sending messages to ports? > It's just another address space through index/data pairs. That's exactly what I disagree with. There is an architecture and I would expect coreboot to model it rather than dumping an array of magic number pairs into index/data. The coreboot devicetree doesn't model HT so well - it is treated as "another address space". I think it would be better to avoid repeating such a mistake? //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] how to model the Quark architecture
On Tue, Feb 18, 2014 at 9:22 AM, Peter Stuge wrote: > Aaron Durbin wrote: >> I skimmed through the doc yesterday evening. It looks very much like >> BayTrail. What particular differences did you see where it would be >> different to cause issues for coreboot? > > I think the most obvious thing is the message port architecture? > > Sure, we can skip modeling them and create some global functions for > sending messages to random ports, but that wouldn't be very impressive.. What do you mean by modeling them? What is an impressive implementation for sending messages to ports? It's just another address space through index/data pairs. -Aaron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] how to model the Quark architecture
Aaron Durbin wrote: > I skimmed through the doc yesterday evening. It looks very much like > BayTrail. What particular differences did you see where it would be > different to cause issues for coreboot? I think the most obvious thing is the message port architecture? Sure, we can skip modeling them and create some global functions for sending messages to random ports, but that wouldn't be very impressive.. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] how to model the Quark architecture
On Tue, Feb 18, 2014 at 6:55 AM, Peter Stuge wrote: > ron minnich wrote: >> I"m not sure why I would want to start a coreboot port effort with this >> UEFI doc as my guide > > Look past all the UEFI babble. :) The doc is a good description of > what needs to be done to bring the platform up, and it's fairly > different from what coreboot does so far. I skimmed through the doc yesterday evening. It looks very much like BayTrail. What particular differences did you see where it would be different to cause issues for coreboot? -Aaron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] how to model the Quark architecture
ron minnich wrote: > I"m not sure why I would want to start a coreboot port effort with this > UEFI doc as my guide Look past all the UEFI babble. :) The doc is a good description of what needs to be done to bring the platform up, and it's fairly different from what coreboot does so far. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
