[coreboot] Re: Syntax highlighting screwed up (orange function parameters)?

[Julius Werner]

> We do not have coreboot specific changes to the syntax highlighting code 
> (e.g. this is stock Gerrit). 2.16.7 had a number of changes in their syntax 
> highlighting though, and typically Chromium is not running on a release build 
> but something in between releases or highly customized.

Ah, okay. I think it's this:
https://bugs.chromium.org/p/gerrit/issues/detail?id=10658

That still doesn't explain why it's not matching braces, but I guess
the parser may have always been broken and we just didn't notice
because it uses the same color for so many things.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Syntax highlighting screwed up (orange function parameters)?

[Stefan Reinauer]

On 29 Apr 2019 17:46, Julius Werner  wrote:> Wanna file a bug at https://bugs.chromium.org/p/gerrit/issues/list ?



Are we sure this is a general Gerrit bug? I've not seen the same thing

on the Chromium Gerrit so I'm assuming it's specific to the coreboot

installation. I've opened a coreboot bug for now

(https://ticket.coreboot.org/issues/205), if Patrick (or whoever

manages that stuff) decides it's not specific to our setup we can

still complain to Gerrit directly.
We do not have coreboot specific changes to the syntax highlighting code (e.g. this is stock Gerrit). 2.16.7 had a number of changes in their syntax highlighting though, and typically Chromium is not running on a release build but something in between releases or highly customized.Stefan
___

coreboot mailing list -- coreboot@coreboot.org

To unsubscribe send an email to coreboot-le...@coreboot.org


___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Syntax highlighting screwed up (orange function parameters)?

[Julius Werner]

> Wanna file a bug at https://bugs.chromium.org/p/gerrit/issues/list ?

Are we sure this is a general Gerrit bug? I've not seen the same thing
on the Chromium Gerrit so I'm assuming it's specific to the coreboot
installation. I've opened a coreboot bug for now
(https://ticket.coreboot.org/issues/205), if Patrick (or whoever
manages that stuff) decides it's not specific to our setup we can
still complain to Gerrit directly.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] KGPE-D16: coreboot-4.5 stuck in boot loop. Help on getting the system to boot or flash newer version

[Pablo Correa Gómez]

Hello and thank you in advance for your time.

 I recently bought a KGPE-D16 motherboard with a single AMD Opeteron
8262SE and coreboot installed. I bought from another supplier 4 memory
sticks Samsung 8GB (M393B1K70DH0-YK0) that per this thread[1] should
work with coreboot. I am able to start the assembled system and to get
serial output. According to the logs, coreboot first does the
initialisation and training of the memory and then start working on the
PCIs. At one point in the boot sequence, I get the following message:

Loaded segments
BS: BS_PAYLOAD_LOAD times (us): entry 0 run 80561 exit 0
POST: 0x7b
Jumping to boot code at 000ff06e(b7cc1000)
POST: 0xf8
CPU0: stack: 0015 - 00151000, lowest used address 001509e0, stack
used: 1568 bytes
entry= 0x000ff06e
lb_start = 0x0010
lb_size  = 0x00116270
buffer   = 0xbfdd3000

Then it stalls for like 20-30 seconds and the booting process restarts
from the beginning. I had considered different options in order to boot
and I would like to know if someone would have any recommendations.
Right now my priority is to get the system up and working. I can worry
about installing coreboot later, but having it now is for sure a plus:
  1) Buy a new chip with the original ASUS BIOS in order to boot the
system.
  2) Externally flash the chip I have right now with a newer version of
coreboot. I probably have enough things at home to flash it, but I have
not found information from ASUS. In coreboot there is some information
but very general and not enough for my knowledge. As far as I have read
from flashrom, I should be able to flash it using a Raspberry Pi or a
BeagleBone Black, but KGPE-D16 is not marked as supported and I don't
know which model is the BIOS chip to check if it is supported.
  3) The moderboard datasheet has a section called: "Force BIOS
recovery setting", which says that in order to flash the proprietary
BIOS, it is as simple as changing a jumper an inserting an USB stick. I
would have already done it if I would not be reluctant to believe that
it is that simple.

Which are your thoughts about this ideas? Any other one that would be
simpler and would let me boot the full system?

Thank you very much,
Pablo.


NOTE: I have tried with the 4 sticks in the orange slots, the 4 sticks
in the 4 further DIMMs from the CPU (2 orange, 2 black) and those
configurations both 1.35 and 1.5V. Logs are slightly different, in the
training section, but the problem while booting remains. A USB stick
with Debian Installer has been plugged-in during since boot process
begins.

[1] https://mail.coreboot.org/pipermail/coreboot/2017-February/083151.h
tml
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: [TF-A] [LPC] Bootloader miniconf

[Matteo Carlini]

Hi Marek,

Thanks for raising the topic across the communities. The question is probably 
how many people from the various projects are going to attend Plumbers this 
year in Lisbon, so to create some critical mass.

The TF.org project is planning a significant presence at the Open Source 
Firmware Conference happening the week before in California (https://osfc.io/), 
sponsoring the event and submitting few engineering topics. This is another 
great opportunity to meet and chat on Boot/Firmware topics as well.

Having a boot miniconf the week after in Europe may be a natural extension, but 
I'm wondering if people would be willing to travel and attend two similar 
events in a row...

Thanks,
Matteo
[Arm & TrustedFirmware.org]

> -Original Message-
> From: TF-A  On Behalf Of Marek
> Vasut via TF-A
> Sent: 29 April 2019 14:39
> To: Marek Vasut 
> Cc: u-boot-custodi...@lists.denx.de; t...@lists.trustedfirmware.org;
> coreboot@coreboot.org
> Subject: [TF-A] [LPC] Bootloader miniconf
>
> Hi,
>
> I was pondering whether it would make sense to organize a bootloader
> miniconf at Linux Plumbers [1]. The Linux kernel is what we often start, the
> bootloader projects generally do similar things, hence I think being able to
> meet face-to-face and discuss how to make things better/nicer would be
> beneficial.
>
> Feel free to expand the CC list to other interested parties.
>
> Thoughts ?
>
> [1] https://www.linuxplumbersconf.org/
>
> --
> Best regards,
> Marek Vasut
> --
> TF-A mailing list
> t...@lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-a
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] [LPC] Bootloader miniconf

[Marek Vasut]

Hi,

I was pondering whether it would make sense to organize a bootloader
miniconf at Linux Plumbers [1]. The Linux kernel is what we often start,
the bootloader projects generally do similar things, hence I think being
able to meet face-to-face and discuss how to make things better/nicer
would be beneficial.

Feel free to expand the CC list to other interested parties.

Thoughts ?

[1] https://www.linuxplumbersconf.org/

-- 
Best regards,
Marek Vasut
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Fwd: Re: Fwd: Re: Fwd: F2A85M IOMMU still not working for RIchland CPUS

[Kinky Nekoboi]

OK i have switched the PSU to an hopefully more high quality Seasonic
Focus+ Platinum 750W ... lets see if System freezes still apear.

Am 29.04.19 um 08:53 schrieb Kinky Nekoboi:
>
> OK maybe it could also be my cheap Corsair VS550 PSU.
>
> Am 29.04.19 um 08:26 schrieb Kinky Nekoboi:
>>
>> Still has stability issues as in random system freezes.
>>
>> I have already replaced the RAM with a NEW Kingston DDR3-1600 16GB kit.
>>
>> System freezes up totally with no further response sending Sysrequest
>> has no use.
>>
>> my newly installed GTX 680 works great.
>>
>> Am 22.04.19 um 14:44 schrieb Kinky Nekoboi:
>>>
>>>
>>> Am 22.04.19 um 11:13 schrieb Mike Banon:
 For some reason the config inside your rom is trimmed and includes
 just 5 lines:

 # This image was built using coreboot 4.9-1334-gdb3f0e3ebd-dirty
 CONFIG_VENDOR_ASUS=y
 CONFIG_BOARD_ASUS_F2A85_M=y
 CONFIG_HUDSON_XHCI_FWM=y
 # CONFIG_DRIVERS_INTEL_WIFI is not set

 Perhaps that's indeed the only difference from default config - but
 why IOMMU wasn't working initially, then? That's still a mystery,
 and I would appreciate if you could send the full .config from your
 coreboot build directory to complete the investigation.
>>>
>>> YES indeed this is the diff from the default config.
>>>
>>> .config locally also seems to works like this now
>>>

 By the way, I noticed that you have CONFIG_HUDSON_XHCI_FWM=y .
 Enabling the CONFIG_HUDSON_XHCI_ENABLE / CONFIG_HUDSON_XHCI_FWM
 options results in XHCI blob being added to your coreboot image -
 it is hidden inside the " apu/amdfw 0x1fdc0 raw 66048 ". If you'd
 like your coreboot build to get closer to libreboot, you could get
 rid of XHCI blob by disabling these options.
>>> Yeah i am aware of this, but i would like to use USB3

 Also, it seems that you either forgot to add the AtomBIOS blob for
 your integrated GPU (pci1002,.rom), or plan to use this board
 in a headless mode. I'm not sure if it is possible to get the
 graphical output without it... ( if I'm wrong, how are you getting
 it? using that Nvidia GT210 which is running its' own blob? )

>>> Yeah i am using that nvidia card, as it works with nouveau with no
>>> addional blob on OS level
 Best regards,
 Mike Banon

 On Mon, Apr 22, 2019 at 8:42 AM Kinky Nekoboi
  wrote:

 Here is the filelink:

 https://nekoboi.moe/nextcloud/index.php/s/DfYGsdNzHHxGKHA

 the .config file should be included in the rom.

 Am 21.04.19 um 20:13 schrieb Mike Banon:
> SMU is still inside your coreboot build, it's just hardcoded
> as an array of hex values inside the
> 
> ./coreboot/src/vendorcode/amd/agesa/f15tn/Proc/GNB/Modules/GnbInitTN/GnbSmuFirmwareTN.h
> file. That's why you couldn't see SMU firmware as a separate
> binary at your CBFS. Just like a microcode, which is also set
> up inside some .c/.h files. Yes, please send your working
> build when it's possible, and also your current
> ./coreboot/.config please - this is also very important.
>
> Have a nice weekends ;-)
>
> On Sun, Apr 21, 2019 at 6:36 PM Kinky Nekoboi
>  
> wrote:
>
> Yes IOMMU works fine with 0x0600111f microcode.
>
> No i dont tried the reversed eng. SMU when it is no
> already inside coreboot.
>
> I wasnt able to send an email attached with my rom file
> ... i am not at home right now so i will provied your with
> a file link to my rom later .. proberally on Tuesday.
>
> IMC was dropped out of the standart config and also out of
> the nconfig menu as i experienced. You can see this in the
> absensce of fan control ( what is not problem if you have
> a FAN that is not extrem loud at 12V)
>
> Am 21.04.19 um 09:29 schrieb Mike Banon:
>> So IOMMU is working for you even with 0x0600111f
>> microcode installed? That's very good. I wonder what was
>> wrong initially, and hope that you could send a board
>> status report or - at least - please upload your current
>> .config to somewhere (e.g. pastebin) and post a link!
>>
>> > are there any other blobs present in my rom now besides
>> microcode ?
>>
>> The microcode blob has been present in your coreboot even
>> before my ucode.sh patch, it just was an older 0x0600110f
>> version (more vulnerable to some spectres and perhaps
>> more buggy IOMMU - e.g. at our G505S we could get IOMMU
>> working properly only with this 0x0600111f update).
>>
>> > my build rom in attachment for inspection
>>
>> I can't see 

[coreboot] Re: Fwd: Re: Fwd: Re: Fwd: F2A85M IOMMU still not working for RIchland CPUS

[Kinky Nekoboi]

OK maybe it could also be my cheap Corsair VS550 PSU.

Am 29.04.19 um 08:26 schrieb Kinky Nekoboi:
>
> Still has stability issues as in random system freezes.
>
> I have already replaced the RAM with a NEW Kingston DDR3-1600 16GB kit.
>
> System freezes up totally with no further response sending Sysrequest
> has no use.
>
> my newly installed GTX 680 works great.
>
> Am 22.04.19 um 14:44 schrieb Kinky Nekoboi:
>>
>>
>> Am 22.04.19 um 11:13 schrieb Mike Banon:
>>> For some reason the config inside your rom is trimmed and includes
>>> just 5 lines:
>>>
>>> # This image was built using coreboot 4.9-1334-gdb3f0e3ebd-dirty
>>> CONFIG_VENDOR_ASUS=y
>>> CONFIG_BOARD_ASUS_F2A85_M=y
>>> CONFIG_HUDSON_XHCI_FWM=y
>>> # CONFIG_DRIVERS_INTEL_WIFI is not set
>>>
>>> Perhaps that's indeed the only difference from default config - but
>>> why IOMMU wasn't working initially, then? That's still a mystery,
>>> and I would appreciate if you could send the full .config from your
>>> coreboot build directory to complete the investigation.
>>
>> YES indeed this is the diff from the default config.
>>
>> .config locally also seems to works like this now
>>
>>>
>>> By the way, I noticed that you have CONFIG_HUDSON_XHCI_FWM=y .
>>> Enabling the CONFIG_HUDSON_XHCI_ENABLE / CONFIG_HUDSON_XHCI_FWM
>>> options results in XHCI blob being added to your coreboot image - it
>>> is hidden inside the " apu/amdfw 0x1fdc0 raw 66048 ". If you'd like
>>> your coreboot build to get closer to libreboot, you could get rid of
>>> XHCI blob by disabling these options.
>> Yeah i am aware of this, but i would like to use USB3
>>>
>>> Also, it seems that you either forgot to add the AtomBIOS blob for
>>> your integrated GPU (pci1002,.rom), or plan to use this board in
>>> a headless mode. I'm not sure if it is possible to get the graphical
>>> output without it... ( if I'm wrong, how are you getting it? using
>>> that Nvidia GT210 which is running its' own blob? )
>>>
>> Yeah i am using that nvidia card, as it works with nouveau with no
>> addional blob on OS level
>>> Best regards,
>>> Mike Banon
>>>
>>> On Mon, Apr 22, 2019 at 8:42 AM Kinky Nekoboi
>>>  wrote:
>>>
>>> Here is the filelink:
>>>
>>> https://nekoboi.moe/nextcloud/index.php/s/DfYGsdNzHHxGKHA
>>>
>>> the .config file should be included in the rom.
>>>
>>> Am 21.04.19 um 20:13 schrieb Mike Banon:
 SMU is still inside your coreboot build, it's just hardcoded as
 an array of hex values inside the
 
 ./coreboot/src/vendorcode/amd/agesa/f15tn/Proc/GNB/Modules/GnbInitTN/GnbSmuFirmwareTN.h
 file. That's why you couldn't see SMU firmware as a separate
 binary at your CBFS. Just like a microcode, which is also set
 up inside some .c/.h files. Yes, please send your working build
 when it's possible, and also your current ./coreboot/.config
 please - this is also very important.

 Have a nice weekends ;-)

 On Sun, Apr 21, 2019 at 6:36 PM Kinky Nekoboi
  
 wrote:

 Yes IOMMU works fine with 0x0600111f microcode.

 No i dont tried the reversed eng. SMU when it is no already
 inside coreboot.

 I wasnt able to send an email attached with my rom file ...
 i am not at home right now so i will provied your with a
 file link to my rom later .. proberally on Tuesday.

 IMC was dropped out of the standart config and also out of
 the nconfig menu as i experienced. You can see this in the
 absensce of fan control ( what is not problem if you have a
 FAN that is not extrem loud at 12V)

 Am 21.04.19 um 09:29 schrieb Mike Banon:
> So IOMMU is working for you even with 0x0600111f microcode
> installed? That's very good. I wonder what was wrong
> initially, and hope that you could send a board status
> report or - at least - please upload your current .config
> to somewhere (e.g. pastebin) and post a link!
>
> > are there any other blobs present in my rom now besides
> microcode ?
>
> The microcode blob has been present in your coreboot even
> before my ucode.sh patch, it just was an older 0x0600110f
> version (more vulnerable to some spectres and perhaps more
> buggy IOMMU - e.g. at our G505S we could get IOMMU working
> properly only with this 0x0600111f update).
>
> > my build rom in attachment for inspection
>
> I can't see it - perhaps the mailing list didn't accept
> this big attachment.
>
> > AMD SMU firmware
>
> Have you tried running this free firmware replacement
> (https://github.com/zamaudio/smutool/) and is it working?
>
> You could also