On Fri, Nov 07, 2014 at 09:13:27AM -0800, ron minnich wrote:
> I'm fine with regular releases with one proviso: if we announce a
> release date, and a version, and a test, then we drop all boards that
> are not working as of that date.
That seems a bit harsh to me, but I'm not against it. Again, just my
2 cents.
Another (softer) approach would be to mark the board as
deprecated/unstable in the build/kconfig, and then remove it from the
tree if it's not tested by the next release.
[...]
> Or else we add a level to mainboard:
> src/RELEASE/mainboard
> or we drop the mainboard as a name, and just have src/<release>/vendor/etc.
Git is better at that then some revision control systems, but it's
still not good at it. So I wouldn't recommend it.
[...]
> a release to me means that everything I find in src/mainboard/* is
> working for that release.
[...]
>we need a process for killing old junk, and a release process is
> as good as any.
Agreed.
-Kevin
On 2014-11-05 12:22, coreboot-request(a)coreboot.org wrote:
> Date: Wed, 5 Nov 2014 15:22:53 +0100
> From: Idwer Vollering <vidwer(a)gmail.com>
> To: coreboot <coreboot(a)coreboot.org>, Joseph Smith
> <joe(a)settoplinux.org>
> Subject: Re: [coreboot] Coreboot and HP Pavilion 6746C-L?
> Message-ID:
> <CAPp9OrnE7Huj75OGEXY8KuFLmnQEDtBYcH_PUg9rx2YsLvkY2w(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 2014-11-04 4:38 GMT+01:00 <theodore.preuninger(a)lycos.com>:
>
>> Step 1 (or equal to step 1) and step 5 From
>> http://h10025.www1.hp.com/ewfrf/wc/document?docname=bph05159&tmp_task=prodi…
>> [1] Intel Socket 370 Pentium III Celeron i810
>
> i810 might still work.
> Here's a photo of the board, with a close-up of the flash chip:
> http://i.ebayimg.com/00/s/MTYwMFgxNjAw/z/htIAAOSw7NNUJcHW/$_57.JPG [2]
>
> You still need spare flash chips and a way to program them.
> See http://www.coreboot.org/FAQ#How_do_I_.28re-.29flash_the_BIOS.3F [3]
>
> When you can program the chip you'll want to see console output, either
> over the serial or EHCI debug port.
>
>> DMI string baseboard-manufacturer: "Trigem Computer, Inc." DMI string
>> baseboard-product-name: "Cognac" DMI string baseboard-version: "None"
>> DMI string chassis-type: "Other" DMI chassis-type is not specific
>> enough.
>
> It actually is a desktop: blame the vendor or ODM for being lazy/lax
> and
> not filling that in.
>
>> Found ITE Super I/O, ID 0x8702 on port 0x2e
>
> Unsupported as-is, but generic enough to configure it to send serial
> output.
>
>> ========================================================================
>> WARNING! You may be running flashrom on an unsupported laptop. We
>> could not detect this for sure because your vendor has not setup the
>> SMBIOS tables correctly. You can enforce execution by adding '-p
>> internal:laptop=this_is_not_a_laptop' to the command line, but please
>> read the following warning if you are not sure.
>
> This one is easy to handle by yourself :)
>
> Idwer
#1 Ok, so let me get this straight....
It is possible, but it requires opening up the case to getting to the
hardware - while the computer is on?
#2 Also is it worth it, considering from the risk?
Risk URL ID
http://www.coreboot.org/FAQ#Can_I_do_any_serious_damage_mucking_around_with…
Thank you
Links:
------
[1]
http://h10025.www1.hp.com/ewfrf/wc/document?docname=bph05159&tmp_task=p…
[2] http://i.ebayimg.com/00/s/MTYwMFgxNjAw/z/htIAAOSw7NNUJcHW/$_57.JPG
[3] http://www.coreboot.org/FAQ#How_do_I_.28re-.29flash_the_BIOS.3F
Hi,
I got the schematics now and I see that J9B4 is connected to Embedded
Controller (EC), so I think that this is not 8250 UART2. Am I right?
I am not able to find the documentation what purpose is served by Embedded
Controller and does coreboot use it at all? Any pointers please. I am
trying to understand what is the purpose of COM port at J9B4. Any specific
document that I should refer to to understand it? I checked user guide and
schematics.
There are 2 com ports I see using usb to serial and Port0 is used for
console. Is another port on usb to serial is spare and can be used for
console or is it serving some other purpose in coreboot.
On Fri, Nov 7, 2014 at 3:51 PM, Gailu Singh <gailu96(a)gmail.com> wrote:
> Hi Experts,
>
> I have working console uart 0 on Baytrail CRB board. However I am trying
> to change to uart 2 (J9B4) DB9 connector. I have changed
> CONFIG_UART_FOR_CONSOLE=2 from menuconfig, cleaned and rebuild and flashed
> coreboot but do not see any log on port 2. Is there any other changes
> required apart from CONFIG_UART_FOR_CONSOLE ?
>
>
>
>
Hi Experts,
I have working console uart 0 on Baytrail CRB board. However I am trying to
change to uart 2 (J9B4) DB9 connector. I have changed
CONFIG_UART_FOR_CONSOLE=2 from menuconfig, cleaned and rebuild and flashed
coreboot but do not see any log on port 2. Is there any other changes
required apart from CONFIG_UART_FOR_CONSOLE ?
Am 06.11.2014 um 20:16 schrieb ron minnich:
> the last 15 years shows that the number of people who want to build is
> a tiny fraction of those who just want an image they can burn.
It solves a different issue, and yes, an important one.
> So, thinking as I type: John Lewis is Da Man in terms of maintaining a
> system that lets people pull an image, flash it automagically,
> recover, and so on, all without having to build it.
If we want to go for a library, we should also handle redistribution issues - vgabios, various firmware could be extracted from the running system or downloaded images and compared against known-good hashes, then added to partial images.
> So how about we forget about release cycles for the tree and think in
> terms of the problem of distribution of good images for people? Does
> that make things easier? I don't know.
The concern with having buildable source for users is relevant for a certain groups of tinkerers and vendors alike.
The former build everything from source (because they have unusual demands on their firmware), the latter want to be able to point to working code for reference boards that can serve as template for further development.
Since the most recent request was about keeping certain parts of the code stable, that's what I ran with.
Patrick
On Thu, Nov 6, 2014 at 9:32 AM, ron minnich <rminnich(a)gmail.com> wrote:
> On Thu, Nov 6, 2014 at 6:37 AM, Peter Stuge <peter(a)stuge.se> wrote:
>> Ron,
>>
>> ron minnich wrote:
>>> pose the question absent any thought to what might happen at some
>>> future time?
>>
>> I think coreboot has had BY FAR enough of thoughtless action.
>
> So I'll rephrase.
>
> "pose the question absent a bunch of bootless speculation about what
> might happen at some future time?"
>
> BTW, on reflection, I'm fine with http://review.coreboot.org/#/c/7149/.
Based on the community feedback and this email discussion, isolation
of the PI and AGESA source is the preferred development path. While we
were trying for a common interface, it is not necessary. I concede
that AMD has not contributed updates to AGESA releases and has had
poor community interactions. It should be more beneficial to the
development of coreboot to fix the long standing issues in the code. I
have removed my NACK(-2) on 7149 and it should be un-abandoned. Thanks
to each of you to your contributions and improvements to coreboot.
Regards,
Marc
--
http://se-eng.com
On Thu, Nov 6, 2014 at 8:32 AM, ron minnich <rminnich(a)gmail.com> wrote:
> On Thu, Nov 6, 2014 at 6:37 AM, Peter Stuge <peter(a)stuge.se> wrote:
> > Ron,
> >
> > ron minnich wrote:
> >> pose the question absent any thought to what might happen at some
> >> future time?
> >
> > I think coreboot has had BY FAR enough of thoughtless action.
>
> So I'll rephrase.
>
> "pose the question absent a bunch of bootless speculation about what
> might happen at some future time?"
>
> BTW, on reflection, I'm fine with http://review.coreboot.org/#/c/7149/.
>
> If you really want a full source-based coreboot for a chipset
> nowadays, it's not going to happen on any modern x86, I am sorry to
> say. And, it won't happen on many ARMs, particularly in the v8 space.
>
Certainly not for you, Ron, but speculating about the future direction of
Intel, in particular, and the entire ARM ecosystem in general is...
bootless?
Regards,
David
Ron,
ron minnich wrote:
> pose the question absent any thought to what might happen at some
> future time?
I think coreboot has had BY FAR enough of thoughtless action.
//Peter
Meng Qiaohui,
I noticed a file called ChangesRequiredForRambiWinboot.txt in Intel
released UEFI package, it can tell you how to modify coreboot/ACPI files to
boot Windows 7, you can download the package @
http://uefidk.intel.com/sites/default/files/2014-WW26-UEFI.CoreBoot.Payload…,
its decryption key @
http://uefidk.intel.com/sites/default/files/2014-WW26-UEFI.CoreBoot.Payload…
and release note @
http://uefidk.intel.com/sites/default/files/2014-WW26-UEFI.CoreBoot.Payload…
.
If you want to fully understand ACPI, go to http://www.acpi.info/ to
download the ACPI specification, reading it and practicing with your Bayley
Bay coreboot code is the best way to understand it.
-Fei
On Tue, Nov 4, 2014 at 3:07 AM, <mengqiaohui(a)mindray.com> wrote:
> ------------------------------
>
> Hi，expert.
>
> Now Coreboot with Intel FSP ,can load Linux on my BayleyBay.I
> tried to use Seabios 1.7.5 load Win7 64bit,but i got a blue screen
> issue,stop at A5(0x1000,0x000,0x105a23a1,0x100).Obviously I think this
> trouble was called by ACPI.Am I wrong? So I modify
> *src/soc/intel/fsp_baytrail/acpi/southcluster.asl* as follows.My serial
> ports message is attached.Then I can load Win7 64bit normaly,but the ACPI
> Table is not completed.
>
> *Scope (\_SB)*
> *{*
> * // GPIO Devices*
> * #include "gpio.asl"*
>
> *#if INCLUDE_LPSS*
> * // LPSS Devices*
> * #include "lpss.asl"*
> *#endif*
>
> *#if INCLUDE_SCC*
> * // SCC Devices*
> * //#include "scc.asl" -----Commented out code 1*
> *#endif*
>
> *#if INCLUDE_LPE*
> * // LPE Device*
> * //#include "lpe.asl"-----Commented out code 2*
> *#endif*
> *}*
>
>
> But I'm not quite understand ,I change the asl code is how to take
> effect?Looking for help to load win7 64bit normaly.How to modify the ACPI
> asl coed?
> Thanks in advance.
>
>
>
>
>
>
> This email (including any attachments) is intended for the sole use of the
> intended recipient/s and may contain material that is CONFIDENTIAL AND
> PRIVATE COMPANY INFORMATION.
> Any unauthorized review, use, disclosure, dissemination, forwarding,
> printing or copying of such information or any action taken in reliance on
> this e-mail is strictly prohibited.
>
>
> 发件人: Werner Zeh via coreboot <coreboot(a)coreboot.org> 收件人: Gailu Singh <
> gailu96(a)gmail.com>, coreboot(a)coreboot.org 日期: 2014-11-04 03:24 主题: Re:
> [coreboot] Coreboot with Intel FSP on BayleyBay Help 发件人： "coreboot" <
> coreboot-bounces(a)coreboot.org>
> ------------------------------
>
>
>
> Hi.
>
> Now you have coreboot running.
> coreboot searches for FSP, finds it and executes the first call into it.
> FSP returns with an error and what you see is this (taken from
> src/drivers/intel/fsp/cache_as_ram.inc):
>
> /*
> * Failures for postcode 0xBB - failed in the FSP:
> *
> * 0x00 - FSP_SUCCESS: Temp RAM was initialized successfully.
> * 0x02 - FSP_INVALID_PARAMETER: Input parameters are invalid.
> * 0x0E - FSP_NOT_FOUND: No valid microcode was found in the
> microcode region.
> * 0x03 - FSP_UNSUPPORTED: The FSP calling conditions were not met.
> * 0x07 - FSP_DEVICE_ERROR: Temp RAM initialization failed
> * 0x14 - FSP_ALREADY_STARTED: Temp RAM initialization has been invoked
> */
>
> So what you actually see is error code 0x07 from FSP. This can mean that
> your CPU is not supported by this FSP version.
> If you use GOLD1 or GOLD2, then a D0 stepping is not supported and if
> you have in advance a D0 stepping installed on your board,
> than you have to use GOLD3 FSP release as it was already mentioned.
>
> I had the same issue and it was due to missing D0-Support in GOLD1
> release. So, I would suggest to try the right FSP-release from Intel.
>
> Bye
> Werner
>
> Am 03.11.2014 um 17:23 schrieb Gailu Singh via coreboot:
> > With the changed TXE/descriptor, it moved ahead but now toggling
> > between POST codes 0x66 and 0x07. I checked
> > ./src/include/console/post_codes.h and these POST codes are not
> > defined there so I doubt that these are coming from coreboot code. Are
> > these post codes coming from FSP code? If yes, How do I interpret
> > them? Do I need to ask Intel? Any pointers please?
> >
> > On Sun, Nov 2, 2014 at 6:50 PM, Sean McNeil <seanmcneil3(a)gmail.com
> > <mailto:seanmcneil3@gmail.com <seanmcneil3(a)gmail.com>>> wrote:
>
> >
> > You mentioned just copying the .fd file, so I assumed it was being
> > used directly in your coreboot image. FSP needs to be incorporated
> > into flash, yes. It should, however, be patched with the BCT
> > program as what is provided in the .fd is usually not patched with
> > the a configuration that you desire. Thus you should run bct and
> > configure/patch the .fd and generate a .bin to include into coreboot.
> >
> > I am a little confused by your email below. You state that you are
> > not using the .fd directly then contradict yourself in the next
> > sentence. Bottom line is I would not include any .fd file from the
> > FSP archive directly. Use BCT to patch it and do not name it .fd.
> > This avoids any confusion regarding whether you are including a
> > patched FSP or not. Just because there is a bsf file included in
> > the GOLD release doesn't mean that the .fd was patched with those
> > settings and that it is valid.
> >
> > Best of luck to you. There are many issues you will have to
> > resolve dealing with new hardware. I've gone through the process
> > with a lot of support from Intel and it is not that easy.
> > Especially when certain components found on the CRB are not
> > provided on custom hardware.
> >
> > Cheers,
> > Sean
> >
> >
> > On 11/02/2014 08:01 PM, Gailu Singh wrote:
> >> Hi Sean,
> >>
> >> 1. This is not for a real project and we are trying to understand
> >> FSP interaction with coreboot to look at feasibility for
> >> considering coreboot in our future projects. Unfortunately I do
> >> not have board documentation so was not able to determine which
> >> one is serial port 0 though I know that port 0 is specified in
> >> coreboot config. That was the reason I was trying on all 3
> >> available ports.
> >> 2. I am not using .fd directly. I believe that FSP need to be
> >> included in bootloader (coreboot in this case) and we are
> >> providing path to coreboot so that it can be included in
> >> coreboot. In my original post I only said that I copied .fd to a
> >> path expected by coreboot configuration. May I know how did you
> >> conclude that I am using it directly? May be that can give me
> >> some pointer.
> >> 3. I had checked the bsf file in the FSP kit with BCT tool and it
> >> is configured for non-ECC RAM, so I believe that no change is
> >> required in .fd. Am I wrong?
> >> 4. Yes, I agree that there is no documentation available on how
> >> to create entire 8MB binary with Firmware Description, TXE,
> >> coreboot etc so for safe route I only touched upper 2 MB as
> >> recommended in one of the initial commit for baytrail FSP
> >> integration and some posts related to similar discussion.
> >>
> >>
> >>
> >> On Sun, Nov 2, 2014 at 3:49 PM, Sean McNeil
> >> <seanmcneil3(a)gmail.com <mailto:seanmcneil3@gmail.com
> <seanmcneil3(a)gmail.com>>> wrote:
>
> >>
> >> Coreboot and FSP are not as easy to understand as you can
> >> see. I also would suggest that you seek assistance from
> >> either Sage (who has good experience that I understand serves
> >> the USA and Europe markets and contributed the current
> >> Coreboot+FSP code) or perhaps a company in Asia such as Zien
> >> Solutions (of Vietnam). There are a number of issues that you
> >> are failing to understand:
> >>
> >> 1) As stated, the first serial port is actually connected to
> >> a USB->Serial converter and delivered out of the microUSB
> >> connector on the CRB.
> >> 2) You need to configure the FSP with Intels program to
> >> create a ROMable image and not use the .fd file directly.
> >> 3) BayleyBay needs to be configured for non-ECC RAM whereas
> >> Bakersport needs to be configured for ECC.
> >> 4) You don't necessarily need the TXE security module, but
> >> you could very well cause problems if it is partially
> >> overwritten. Best is to create a correct 8MB image to flash
> >> that has the proper Intel Firmware Description block at the
> >> beginning.
> >>
> >> Regards,
> >> Sean
> >>
> >>
> >> On 11/02/2014 02:25 AM, Gaumless via coreboot wrote:
> >>
> >> First, the serial ports: The serial console is on the
> >> first serial port on the micro-USB connection.
> >>
> >> The 0x0000 on the post code display means that it's not
> >> actually starting to boot - it's probably hanging in the
> >> TXE. There are known issues with upgrading to coreboot
> >> from some of the bayleybay roms. I thought Intel was
> >> going to document that, but I don't know if they did.
> >>
> >> The Gold 2 FSP doesn't support D0 parts, so if you have a
> >> D0, you need the Gold 3. Also, the FSP is targeted at
> >> the embedded sku Baytrail-I. It might work with M/D
> >> parts, I haven't tested that.
> >>
> >> Assuming all that is ok, you probably need to start from
> >> a different rom. It might be failing because of the TXE
> >> security. You'll probably need to talk to your Intel
> >> contact to get that update.
> >>
> >> Finally, if this is not a personal project, you might be
> >> interested in contacting Sage and look at purchasing a
> >> BSP to get up and running. Either way, let us know
> >> whether you make progress or need more help.
> >>
> >> Martin
> >>
> >>
> >> On Nov 1, 2014, at 11:48 AM, Gailu Singh via coreboot
> >> <coreboot(a)coreboot.org
> >> <mailto:coreboot@coreboot.org <coreboot(a)coreboot.org>>>
> wrote:
>
> >>
> >> Hi Experts,
> >>
> >> I am trying to boot BayleyBay CRB Rev 3 using
> >> coreboot and have no success so far. I have serial
> >> port (DB9) connected and using 115200 Baud Rate. No
> >> message comes on serial at all. Here is the procedure
> >> I followed.
> >>
> >> 1. Pulled latest coreboot from git.
> >> 2. Pulled following from BAY_TRAIL_FSP_KIT. The
> >> reason for doing it is that BAYTRAIL_FSP.fd is not
> >> in git and .config refers to it. Also .config refers
> >> to ../intel/cpu/baytrail/microcode
> >> a) created intel directory parallel to coreboot
> >> and copied BAYTRAIL_FSP_GOLD_002_10-JANUARY-2014.fd
> >> in to intel/fsp/baytrail/BAYTRAIL_FSP.fd
> >> b) Copied *.h from Microcode folder in the kit
> >> to intel/cpu/baytrail/microcode.
> >> 3. Configured the coreboot for mainboard as intel
> >> bayleybay. My .config is attached.
> >> 4. Build Coreboot. Below is the prints from cbfstool.
> >> cmos_layout.bin 0x0 cmos_layout 1132
> >> fallback/romstage 0x4c0 stage
> >> 27813
> >> fallback/ramstage 0x71c0 stage
> >> 67431
> >> fallback/payload 0x17980 payload 268859
> >> config 0x59400 raw 4363
> >> (empty) 0x5a540 null 744088
> >> cpu_microcode_blob.bin 0x110000 microcode 104448
> >> (empty) 0x129840 null 157528
> >> mrc.cache 0x14ffc0 (unknown) 65536
> >> (empty) 0x160000 null 393112
> >> fsp.bin 0x1bffc0 (unknown) 229376
> >> (empty) 0x1f8000 null 31640
> >> 5. Flashed the coreboot.rom in upper 2MB
> >> (0X0600000-0x07FFFFF)
> >> 6. Reboot the board
> >> 7. Nothing comes on Serial Console (DB9). Also tried
> >> to connect Micro usb cable which detects two serial
> >> ports but no output to any of them as well.
> >> 8. Before flashing coreboot.rom, 4 digit display was
> >> displaying something on two digits and rest two were
> >> zero. Now all 4 digits stays at zeros.
> >>
> >> Looking for help to get at least serial working so
> >> that I can get some logs to debug it. I do not have
> >> copy of original BIOS that was there in Flash and
> >> forgot to make a copy using programmer though I
> >> ensured that I only touch upper 2MB. I am stuck and
> >> have no logs to debug it.
> >>
> >> Thanks in advance.
> >> <my.config>
> >> --
> >> coreboot mailing list: coreboot(a)coreboot.org
> >> <
> mailto:coreboot@coreboot.org <coreboot(a)coreboot.org>>
> >> http://www.coreboot.org/mailman/listinfo/coreboot
> >>
> >>
> >>
> >
> >
> >
> >
>
>
> --
> coreboot mailing list: coreboot(a)coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>
>
>
>
> --
> coreboot mailing list: coreboot(a)coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>
On 11/06/2014 01:25 AM, ron minnich wrote:
> This discussion has gone way off base, as such discussions can do when
> licensing comes into the picture.
>
> Bruce asked a simple question: can we rename some directories/move
> some code around in response to a change in how a vendor is delivering
> their chipset support?
>
Ron, to clarify, Bruce did not originally pop this question.
See http://review.coreboot.org/#/c/7149/
> That's a pretty simple question.
>
> All of a sudden we're talking about what AMD should have done, should
> do now, or will do. That's not the question.
>
> Bruce, is it possible to rephrase your question in simple terms, one
> paragraph, and not bring in what 3rd parties such as Sage and AMD
> might do, and just pose the question absent any thought to what might
> happen at some future time?
>
Ron, see Marc's blocking review on patchset 2. That one brought the
speculations of what future might bring into this discussion.
> thanks
>
> ron
>
Kyösti
