Hi Gluglug
Can I raise the bug for the same.
Thanks
Ajoy
On Wed, Apr 15, 2015 at 7:53 PM, Ajoy Das <dasajoy80(a)gmail.com> wrote:
> Hi
> I have already tried that fix but it is not fixing the problem.
> Thanks
> Ajoy
>
>
> On Wed, Apr 15, 2015 at 1:29 PM, The Gluglug <info(a)gluglug.org.uk> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> X60/T60 couldn't boot on 3.19/higher without acpi=off. See:
>> https://bugzilla.kernel.org/show_bug.cgi?id=93171
>>
>> This patch fixed it:
>> https://bugzilla.kernel.org/show_bug.cgi?id=93171#c25
>>
>> And it's being merged:
>> https://bugzilla.kernel.org/show_bug.cgi?id=93171#c32
>>
>> That probably won't help you, so you'll have to open your own bug
>> report. I used Qemu myself very recently, but I haven't tested
>> GNU/Linux much on it (I use it mostly for testing payloads).
>>
>> On 15/04/15 07:37, Ajoy Das wrote:
>> > Its qemu-system-i386.
>> >
>> > On Tue, Apr 14, 2015 at 11:17 PM, The Gluglug <info(a)gluglug.org.uk>
>> > wrote:
>> >
>> > what computer is this?
>> >
>> > On 14/04/15 03:58, Ajoy Das wrote:
>> >>>> Hi
>> >>>>
>> >>>> I am running coreboot on qemu with the following sequence.
>> >>>>
>> >>>> coreboot -> seabios -> GRUB -> kernel.
>> >>>>
>> >>>> The kernel booting hangs at *All ACPI Tables successfully
>> >>>> acquired*
>> >>>>
>> >>>> coreboot-4.0 kernel 3.19
>> >>>>
>> >>>> when I pass acpi=off to the kernel command line parameter
>> >>>> the kernel boots fine in this scenario.
>> >>>>
>> >>>>
>> >>>> Is there any specific coreboot option is there to be enabled
>> >>>> for successful booting. or anyone knows of this issue.
>> >>>>
>> >>>> please help
>> >>>>
>> >>>>
>> >>>> Thanks
>> >>>>
>> >>>>
>> >>>>
>> >>
>> >
>> >
>> >
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1
>>
>> iQEcBAEBAgAGBQJVLhpJAAoJEP9Ft0z50c+UI9gH/2WwcYzlgaWmc4TuO09BPVdV
>> 3saFE27F1iClAe9p3MqcziEWySGjaL6p6Y8YhLJIKHF8N0ZyghdratcwLzL68LpX
>> V5HOhw84d/ra24rq1ZMMC7hf6GsUlqgvrefIiVCuApdlPWdDoq5j9X3lEqgC+3Yy
>> jNHh8hLQXbfmV6wJ5ewY+36VubtJ0qMhRPHMcUNrrZozbPBKD+jyZrdw6T/mLguq
>> G2ZYWr8ruWNPH6bi5tBEN6xlmh58sC1O16sb8cUkB8NX5OYAhJ3CQEnGwVF6xvZY
>> B9lz0iQsfqokRCmqUe5vDiq4n8HobbF9DbSu41+oMKOYPMdSDi75Kb+FsZx1BH4=
>> =LesB
>> -----END PGP SIGNATURE-----
>>
>
>
Hi All,
I can see the CONFIG_COLLECT_TIMESTAMPS macro in the source of coreboot,
but am unable to get the clear picture of it.
I want to collect all the timestamps of the drivers and to find out BOOT
TIME.
Please let me kow if any one has idea regarding this.
--
Thanks,
Rajashaker Goud Ranga
The QEMU x86_64 Q35 fails verification as of commit 6897f4e796c4645cec5d7a247dba78f002008080
The following tests failed:
CBMEM_TIMESTAMP_ACCESS_FAILURE
CBMEM_CONSOLE_CONTENT_TRUNCATED
Commits since last successful test:
6897f4e google/storm: indicate start of normal boot on LED ring
ace3e3f i2c/ww_ring: add a pattern for normal boot
a386bf7 google/storm: enable zero page access protection.
f96c7c7 i2c/ww_ring: update color definitions
8ac8ffa i2c/ww_ring: change colors for different display modes
<224 commits skipped>
90d0acb as3277: Fix month-off-by-one error for RTC driver
55cb84b bg4cd: define custom romstage entry
53b74f6 arm: allow custom stage entry code
1c78009 rk3288: Add a config variable hack to skip display init
b7641cc veyron: Activate Winbond SPI driver
See attached boot log for details
This message was automatically generated from Raptor Engineering's QEMU x86_64 Q35 test stand
Raptor Engineering offers coreboot consulting services! Please visit https://www.raptorengineeringinc.com for more information
Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineeringinc.com> regarding any issues stemming from this notification
On 04/21/2015 11:31 AM, Patrick Georgi via coreboot wrote:
> 2015-04-21 17:31 GMT+02:00 Gregg Levine<gregg.drwho8(a)gmail.com>:
>> I suspect somehow it was supposed to be internal to hs outfit only.
> Timothy provides boot testing of coreboot master with QEmu and a AMD
> board that he maintains as a service to the community.
>
>> And something changed with regards to the logic behind how those
>> annoying e-mail messages being sent to us.
> The system only sends mails when things look wrong.
> Right now coreboot is able to boot, but has issues with the cbmem
> console. According to Paul's analysis, that's why it's now reporting a
> failure.
>
>
> Patrick
>
This is correct. Please see the thread marked "cbmem console broken on
Intel hardware since ec5e5e0" for additional information on the
regression in coreboot itself.
If the community would like me to stop sending these notifications I
will do so; I could also adjust the maximum frequency if desired. As
stated this is intended to be a service so that broken boards are
detected and repaired; perhaps there should be an alternate way of
reporting the test failure (e.g. the board status repository could be
modified to store failed tests as well as successful ones?)
--
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645
http://www.raptorengineeringinc.com
Hi,
some of you might remember the flag days initiative, which led to some
useful information on how to keep up with upstream development while
maintaining local branches (or repos). If you don't, please look at
the marvel that is
http://coreboot.org/index.php?title=Flag_Days&oldid=10718
The short story is that for each change that required sweeping
changes, eg. a new function call that certain drivers need to
implement, a new argument to a function, or a Kconfig variable that is
retired a short blurb was written so developers could follow up.
Where practical, these could contain coccinelle patches, reducing work
for fellow developers even more.
With the switch to git, we dropped the habit.
Do we want to reestablish that routine?
A rule of thumb is that there's a flag day if a mainboard or chipset
that was copied out of the tree before your commit and submitted after
your commit needs to be adapted due to your change.
That sounds contrived, but it's actually quite common: people copy the
code for a mainboard similar to what they're working on, hack on it
for a while, then try to upstream. Chances are that there are changes
to the original mainboard code to follow up on.
My proposal on implementation is to integrate flag day docs with git:
let's create the convention that such changes come with documentation
in documentation/flagdays/, maybe keyed to the author's email address
to avoid conflicts, and some description, for example
documentation/flagdays/pgeorgi(a)google.com-rename-console.h-to-textout.h.md
(I don't actually want to do that rename, calm down :-) ).
>From there, a server side script can determine the commit date (which
is the effective date for when the change was submitted) and commit
id, and create a wiki page from those files.
Since I still hope that we eventually get rid of the wiki, I propose
to use plain text (.txt suffix) or markdown (.md suffix) as 'neutral'
formats. pandoc can make this into wiki syntax (or pretty much
everything else) with ease.
The same script could be used locally to generate the documentation as
well (ie. it resides somewhere below util/).
To allow for post-hoc additions of flag days, there should also be a
way to declare a commit id within the doc (eg. first line stating:
commit-id: 1a2b3c4)
If we go with this proposal (or some variant thereof), I'll take care
of the scripting and automation to generate the doc. It would be our
collective responsibility to remember when to write such docs, or to
request them to be added during review where needed.
Thoughts?
Patrick
--
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
Dear all,
While compiling coreboot, southbridge smm handler always compiles as empty
function irrespective of the code present in it.
As per declaration in smm.h, it is declared as attribute weak.
Since it is defined in my southbridge smm handler, it should take the
defined function which it is not happening (objdump shows that only the
southbridge smm handler function has only ret instruction, rest all
function have proper assembly code as per the required implementation .)
I need smm handler for enabling acpi mode during os booting.
Please help in solving this issue.
Regards,
N Solanki
On Tue, Apr 21, 2015 at 9:54 AM, Aaron Durbin <adurbin(a)chromium.org> wrote:
> On Mon, Apr 20, 2015 at 9:29 PM, Matt DeVillier
> <matt.devillier(a)gmail.com> wrote:
>> On 4/20/2015 3:29 PM, Aaron Durbin wrote:
>>> On Mon, Apr 20, 2015 at 9:23 AM, Matt DeVillier
>>> <matt.devillier(a)gmail.com> wrote:
>>>> On 4/20/2015 8:51 AM, Aaron Durbin wrote:
>>>>> On Fri, Apr 17, 2015 at 12:32 AM, Matt DeVillier
>>>>> <matt.devillier(a)gmail.com> wrote:
>>>>>> Greetings! When building upstream master tonight, discovered that cbmem console output is broken for Intel hardware (testing on google/panther). With some help on IRC from kmalkki, was able to determine the culprit is commit ec5e5e0 (New mechanism to define SRAM/memory map with automatic bounds checking). I verified this via bisecting; the prior commit, 06ef046, functions normally.
>>>>> Did this get fixed?
>>>> not as of yet (cdf92ea still has the issue)
>>> Try this if you have time? I'm sure I haven't handled all the cases,
>>> but it my work for you.
>>>
>>> http://review.coreboot.org/#/c/9851/
>>
>> applying this as a cherry-pick gives me garbage/binary output for 'cbmem -c'
>
> Thanks, Matt. That was my first pass w/o any real checking on my end.
> I may have time to tinker on my end to see what I can work out.
> However, there's a fundamental problem w/ the code as checked in and
> that previous changes. cbmem was enabled all the time, but that code
> wasn't exactly used based on compile time options. However, there's
> not compile-time check anymore. The decision to use cbmem console in
> various stages have to be done at runtime now. That creates more work
> outside of just fixing your problem.
>
> -Aaron
http://review.coreboot.org/9851 -- updated CL
http://review.coreboot.org/9933 -- to address cbmem console missing
large amounts of ramstage
2015-04-21 17:31 GMT+02:00 Gregg Levine <gregg.drwho8(a)gmail.com>:
> I suspect somehow it was supposed to be internal to hs outfit only.
Timothy provides boot testing of coreboot master with QEmu and a AMD
board that he maintains as a service to the community.
> And something changed with regards to the logic behind how those
> annoying e-mail messages being sent to us.
The system only sends mails when things look wrong.
Right now coreboot is able to boot, but has issues with the cbmem
console. According to Paul's analysis, that's why it's now reporting a
failure.
Patrick
The QEMU x86_64 Q35 fails verification as of commit 1abb6002ddc84dd6f2dc01e76475480445fa4271
Commits since last successful test:
1abb600 broadcom/cygnus: Fix missing writel->write32 transformation
7ab46f8 libpayload: add timer driver for cygnus
b048432 cygnus: add QSPI driver
82a7bc4 veyron: add new SDRAM configuration with ram-code 1101b
823f607 pistachio: Remove 50% DDR bandwidth restriction
51ad6ac pistachio: Decrease DDR ODT from 75R to 50R
59074ff pistachio: clean DDR2 initialization code
1e935bf cygnus: enable serial driver for depthcharge
5a2718c storm: print uber-sbl information
be7124e armv7: preserve bootblock invocation parameter
90fe582 ipq808x: add uber sbl parameter definitions
d99e082 urara: I2C clock and MFIO setup function for all interfaces
38063b0 pistachio: add clock setup for all I2C interfaces
9ff8f6f Unify byte order macros and clrsetbits
9418476 arm(64): Manually clean up the mess left by write32() transition
2f37bd6 arm(64): Globally replace writel(v, a) with write32(a, v)
1f60f97 arm(64): Change write32() argument order to match x86
d21a329 arm(64): Replace write32() and friends with writel()
24f9476 romstage_handoff: Fix for changing CBMEM structure
ebdef9f veyron_{brain,danger}: Specify vboot romstage and ramstage indices
3704e69 rk3288: disable rk808 DCDC_UV_ACT_REG restart converter function
19ee156 veyron: The ODT function is disabled for LPDDR3
c447f43 veyron: Sync up SDRAM configurations
5c8aacf rockchip: configure lpddr odt properly
9eb6f61 cbfs: Print absolute offsets of loaded files
5792e3b veyron_jerry: support K4B8G1646Q-4GB and H5TC8G63XXX-4GB ddr3
dbdd066 x86: Allow builds without ACPI tables
54cc8ba ipq806x: i2c: stop transfer as soon as an error is reported
f36cffc ipq806x: i2c: write function fixed to avoid spurious success
44c5105 libpayload: mips: Do not set C0_EBase_WG
ca0e89b libpayload: mips: Add macros to convert to/from KSEG{0,1} addresses
ef4e87b arch/mips: simplify cache operations
8cc3a2a rk3288: support single channel ddr
9f5ad9b libpayload: mips: Use KSEG1 to access DMA-coherent memory
2e70946 libpayload: mips: Set BASE_ADDRESS to 0
b8936ad urara: Identity map DRAM/SRAM
3537e95 mips: Allow memory to be identity mapped in the TLB
df4081e broadwell: Clear USB3.0 PORTSC status bits in sleep_prepare.
46d3ac1 broadwell: indent xhci code
1e6b591 broadwell: Skip pre-graphics delay in resume path
b2deb22 broadwell: Implement Recovery Button
f92edfe Arrange CBMEM table entries' IDs alphanumerically
dfd441d urara: add config of SPI bus and correct selection of winbond flash
8549797 imgtec/pistachio: Add spi_crop_chunk()
4038a7f gigabyte/ga-b75m-d3v: Add GIGABYTE GA-B75M-D3V mainboard
31ca97c southbridge/intel/bd82x6x: Add LPC id 0x1e49 for B75 chipset
bcff3bd mainboard/lenovo/t430s,t530,x230:enable usb3, set xhci overcurrent mapping
59aef5c southbrige/intel/bd82x6x: add XHCI overcurrent map config
f21b657 build system: improve portability by not relying on extraordinary dd options
01368ed Kconfig: rename CONSOLE_SERIAL_UART to DRIVERS_UART
c047b10 purin: add ns16550 driver
3a2ac88 console: copy ns16550 driver from u-boot
76e3303 chromeos: vboot2: Add TPM PCR extension support
5aecacc vboot2 workbuf alignment is now 16 bytes, not 8
cdf92ea rk3288: Disable ramstage compression by default
0b29a7b southbrige/intel/bd82x6x: XHCI replace magic values
7effaa4 riscv: use new-style CBFS header lookup
42001a7 vboot2: provide path for booting using alternative CBFS instances
3c90365 vboot2: Implement new vb2ex_hwcrypto API
23727ca vboot: make vboot2_verify_firmware return
7c25640 ipq806x: initialize UART even when console is not enabled
b67b715 ipq806x: uart: replace hardware accessors
ab7586f broadwell: Set C9/C10 vccmin
aafdddf broadwell: Disable XHCI compliance mode entry
2f2a5e5 panther: Fix pointer related errors in LAN code
45e5997 cbfstool: clean up source code
1161473 cbfstool: add the missing 'break'
5e273a4 cbfstool: add a command to duplicate a cbfs instance
458a12e cbfstool: allow user to explicitly specify header location
14ecb54 soc/intel/common: Add common reset code
a32b6b9 soc/intel/common: Add function to protect MRC cache
1006b10 broadwell: add ROM stage pre console init call back
3c6e5db libpayload udc: Support legal edge case of GET_CONFIGURATION call
dc83d35 libpayload udc: Only enable configuration if it's valid
e17d57e libpayload: Enforce strict packet handling order in ChipIdea driver
49a80ce libpayload: More defensive ChipIdea initialization
9a20a43 libpayload udc: Clear bit when it needs clearing
bd6901e libpayload udc: Deconfigure device when necessary
ea0bdf2 libpayload: Add zero length packet support to UDC framework
1bd3050 libpayload: Add USB device mode driver
2df124d lint: Add check for new board name scheme
139e106 kconfig: automatically include mainboards
e5d5942 cygnus: enable mmu
128de62 cygnus: configure memlayout
fcfd989 cygnus: add timer functions
352135e urara: Define UART used for serial console
b116a1a pistachio: Move console UART to a Kconfig variable
d82e0cf Fix non-x86 __PRE_RAM__ assertions and add FATAL_ASSERTS Kconfig option
f0d038f flash: use two bytes of device ID to identify stmicro chips
7dcc48b storm: Add STM flash support
3b1c238 qualcomm/ipq806x: add spi_crop_chunk()
e5fd1c9 spi: allow inclusion of Micronix and STM drivers in bootblock
fc08b76 armv7: set CBFS header to zero
d6aaca9 pistachio: add DDR2 initialization code
b7be358 ryu: Add support for EVT board with ID BASE3(1,1)
4e158bc armv7: work around hang in bootblock startup code
f61809a storm: handle dual purpose recovery button
20557c2 ryu: add support for p4 boards
8920865 ipq806x: extend GSBI driver to support i2c on any GSBI block
3cfb6a0 ipq806x: add LPASS clock control driver
7f70ad6 rk3288: Add software I2C support
1c2748d ipq806x: Add support for mmu in bootblock.
efe279d veyron_{brain,danger,rialto}: Enable eventlogging
44004b3 veyron_{brain,danger,rialto}: Use common watchdog reboot
e18c38e purin: add basic set of files for libpayload
0c253b6 rk3288: move reboot_from_watchdog() before rk808 setting
710e0a2 purin: add purin under mainboard
a6712f3 broadcom/cygnus: add new SoC driver
105f5b7 chromeos: Provide common watchdog reboot support
a5d2a8d veyron_*: Enable eventlogging
731bfef chromeos: Move memlayout.h/symbols.h into common directory
f97b88b Makefile: Fix dependency tracking for ramstage objects
16d0188 storm: define location for storing CBFS header value
6bfabce cbfs: look for CBFS header in a predefined place
7271e23 pistachio: report UART register width
6cc5e52 libpayload: read register width from coreboot table
9dccf1c uart: pass register width in the coreboot table
f7da3d2 libpayload: sync arch/arm/cache.c with coreboot
d73a8e5 blaze: add new Hynix 2GB BCT
e1298df exynos: return correct value when init_default_cbfs_media fails
ee28c86 rk3288: detect sdram size at runtime
d37bc75 veyron: move setup_chromeos_gpios() prototype to board.h
249f9cc rk3288: Handle framebuffer through memlayout, not the resource system
deaaab2 arch/mips: Fix bug when performing cache operations
fb03239 spi: Add function to read flash status register
1968b58 ARM: Remove -mno-unaligned-access
6addd40 libpayload: Take flash parameters from coreboot
a5aac76 drivers/spi: Pass flash parameters from coreboot to payload
f9b49e8 Add delay before reading GPIOs in gpio_base2_value()
92da778 urara: add board id information for urara board
90d0acb as3277: Fix month-off-by-one error for RTC driver
55cb84b bg4cd: define custom romstage entry
53b74f6 arm: allow custom stage entry code
1c78009 rk3288: Add a config variable hack to skip display init
b7641cc veyron: Activate Winbond SPI driver
See attached boot log for details
This message was automatically generated from Raptor Engineering's QEMU x86_64 Q35 test stand
Raptor Engineering offers coreboot consulting services! Please visit https://www.raptorengineeringinc.com for more information
Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineeringinc.com> regarding any issues stemming from this notification
