Re: [coreboot] board_status.sh output from PC Engines ALIX 2c3
Dear Sevan, Am Dienstag, den 12.08.2014, 02:27 +0100 schrieb Sevan / Venture37: It seems that the status-to-wiki.sh script is broken, apart from being non-portable, it appears that the board model/manufacturer is being used as the date on Linux when run in a bash shell date: invalid date `yangtze' […] Hmm, I have never seen this with `board_status.sh` on Debian. The last time I tried was last Sunday I believe. Hence I couldn't follow through with making a submission so instead, I've uploaded the contents of the text files created by board_status.sh to pastebin if anyone is interested. http://pastebin.com/r4H5ceN7 Thanks a lot. Could you please enable CBMEM console (menu Console) and time stamp capture (menu General)? Please check if CBMEM console is enabled in your payload (GRUB/SeaBIOS) too. 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
[coreboot] [Heads up] CPU_ADDR_BITS set to 36 bits again on most Intel device (was: [coreboot-gerrit] Patch merged into coreboot/master: a438049 model_106cx: don't blindly set Kconfig settings)
Dear coreboot folks, Am Sonntag, den 10.08.2014, 16:34 +0200 schrieb ger...@coreboot.org: the following patch was just integrated into master: commit a438049422fae85fe4df3ab3f89dbca797d6f5a9 Author: Aaron Durbin adur...@chromium.org Date: Tue Sep 17 22:01:48 2013 -0500 model_106cx: don't blindly set Kconfig settings The CPU_ADDR_BITS was being unconditionally set. Don't do that. […] See http://review.coreboot.org/6535 for details. since the submission of the commit above `CONFIG_CPU_ADDR_BITS` is set to 36 bits on most Intel devices instead of 32 bit, which it has been since almost two years after a bad conflict resolution in the revert commit 51676b14 (Revert Use broadcast SIPI to startup siblings) [1], where the checks from commit c7fb2ae6 (Intel cpus: use CPU_ADDR_BITS from Kconfig during CAR) [2] were removed. I was told it should not make a difference for machines below 4 GB, but it’d be great if you could test it on your Intel boards. Thanks, Paul [1] http://review.coreboot.org/1381 [2] http://review.coreboot.org/639 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] coreboot hackaton/meeting in Prague - october 2014 - official date set
Hi all, I would like to remind you our Prague hackaton meeting in October (16-19). I managed to get patronage from dean of the Faculty of Information Technology, Czech Technical University and also patronage from CESNET (Czech education and science network) To properly size the event room (so far I counted with 15 people, but we are nearly there!) and also for the hotel booking, I would like to ask you to sign in on doodle ASAP! If you intend to come, please use http://doodle.com/h6yar2mtxarvhv3x and sign in. If you are still unsure, but you want to most likely to come. Indicate that in the doodle too. I can do you some speculative booking of the hotel (which is penalty free, up to 16 september) I'm handling the people which are already on the doodle, via a private emails except for Cris Sommerland. He is prehaps using a nickname and I dont have any email of him. Cris, please can you write me an email? Or someone who has yours ;) If your email is not in the email conference archive, please write me an email too. The hotel is part of student dormitory, just google for The Masarykova Dormitory hotel and it has very reasonable prices and it is not far from the actual event place. The people which are already on the doodle list received an email from me where I'm asking them to fill in some details in the form, please do so! (if you dont have my email, please ping me too) I want to do the hotel booking tomorrow afternoon GMT +2. That does not mean that the hotel is full, I just can't promise you the room later. For late birds, I will try to get reservation in the early september, but I can't promise anything. Thanks Rudolf -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] board_status.sh output from PC Engines ALIX 2c3
Hi Paul, On 12 August 2014 07:11, Paul Menzel paulepan...@users.sourceforge.net wrote: Hmm, I have never seen this with `board_status.sh` on Debian. The last time I tried was last Sunday I believe. I'll try dig a little further tonight to see what's going on, I'm using voyager linux which is a minimal debian derivative intended for Alix Soekris boards. Hence I couldn't follow through with making a submission so instead, I've uploaded the contents of the text files created by board_status.sh to pastebin if anyone is interested. http://pastebin.com/r4H5ceN7 Thanks a lot. Could you please enable CBMEM console (menu Console) and time stamp capture (menu General)? Please check if CBMEM console is enabled in your payload (GRUB/SeaBIOS) too. Sure, will build a new image tonight post up the results for you. Sevan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [Heads up] CPU_ADDR_BITS set to 36 bits again on most Intel device (was: [coreboot-gerrit] Patch merged into coreboot/master: a438049 model_106cx: don't blindly set Kconfig settings)
I noticed this issue before, Kconfig will take default CPU_ADDR_BITS with the value 32 in src\cpu\intel\model_106cx\Kconfig instead of the value 36 src\cpu\x86\Kconfig. To avoid this issue, you have to override CPU_ADDR_BITS in your own Kconfig file same as what Baytrail project has done. On Tue, Aug 12, 2014 at 7:41 AM, Paul Menzel paulepan...@users.sourceforge.net wrote: Dear coreboot folks, Am Sonntag, den 10.08.2014, 16:34 +0200 schrieb ger...@coreboot.org: the following patch was just integrated into master: commit a438049422fae85fe4df3ab3f89dbca797d6f5a9 Author: Aaron Durbin adur...@chromium.org Date: Tue Sep 17 22:01:48 2013 -0500 model_106cx: don't blindly set Kconfig settings The CPU_ADDR_BITS was being unconditionally set. Don't do that. […] See http://review.coreboot.org/6535 for details. since the submission of the commit above `CONFIG_CPU_ADDR_BITS` is set to 36 bits on most Intel devices instead of 32 bit, which it has been since almost two years after a bad conflict resolution in the revert commit 51676b14 (Revert Use broadcast SIPI to startup siblings) [1], where the checks from commit c7fb2ae6 (Intel cpus: use CPU_ADDR_BITS from Kconfig during CAR) [2] were removed. I was told it should not make a difference for machines below 4 GB, but it’d be great if you could test it on your Intel boards. Thanks, Paul [1] http://review.coreboot.org/1381 [2] http://review.coreboot.org/639 -- 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] Intel HM76 support
2014-08-08 18:18 GMT-06:00 David Hendricks dhend...@google.com: The good news is that HM76 (or at least very similar chipsets) are already supported in coreboot :-) The bad news is that there are many other factors to consider which are specific to the platform you intend to target. Look around the codebase and try to find something that most matches the criteria you are targeting. The Kconfig files under src/mainboard/* list the components of each mainboard pretty well. Porting to a totally new mainboard can take a few days or maybe weeks if you have all the CPU/chipset documentation, mainboard schematics, and requisite vendor-provided binaries (especially for Intel platforms). If you have none of the documentation or binaries then it can take several months assuming you're skilled and knowledgeable of x86 platforms, years if not. Start with the Lenovo x230 (Ivy Bridge) since phcoder (a highly skilled and knowledgeable dude) wrote native RAM init code on his own, an impressive feat that probably took him a few months. If you have a business relationship with Intel you can ask them for a binary to do the same thing for whatever northbridge you are targeting. HTH. Thanks for the detailed response! Unfortunately, it doesn't look like I'll have time to work on this project for several months, if at all. The specific motherboard I'd like to add support for comes from the Lenovo IdeaPad Z500 Touch. It has an i5-3230M and an HM76. Again, I'd be happy to donate hardware to anyone willing to work on support for this or similar motherboards. -Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Baytrail SD card / eMMC interface
Marc, I don't seem to see an FSP configuration in BCT for eMMC in PCI or ACPI mode ... Martin - Is eMMC currently supported in coreboot? Thanks, Wen -Original Message- From: Marc Jones [mailto:marcj...@gmail.com] Sent: Thursday, August 7, 2014 3:09 PM To: Wen Wang Cc: Martin Roth; Julien Snell; Coreboot Subject: Re: [coreboot] Baytrail SD card interface Wen, The emmc device can be set to PCI mode or ACPI mode. If you can't find it in lspci, it is probably in ACPI mode. I'm not certain what mode the FSP sets up the device as. Marc On Thu, Aug 7, 2014 at 11:43 AM, Wen Wang wen.w...@adiengineering.com wrote: Thanks Martin! We probably missed something in the muxing setting. Looking forward to your patch. By the way, I also have started looking into the eMMC4.5. I do have it enabled in fsp and device tree, but it does not seem to work. lspci does not list eMMC device either. Is it currently supported in coreboot? - should I start a new thread on this topic? Thanks, Wen -Original Message- From: Martin Roth [mailto:martin.r...@se-eng.com] Sent: Thursday, August 7, 2014 11:08 AM To: Wen Wang; 'Julien Snell'; coreboot@coreboot.org Subject: Re: [coreboot] Baytrail SD card interface Wen, I'll push a patch for the muxing - I'd been meaning to do this and just got behind. I don't believe that SeaBIOS yet supports boot from SD (without a USB translator). Sage pushed a preliminary patch supporting SD boot on specific platforms to the SeaBIOS mailing list a while back, but I don't believe that worked on Bay Trail, and I don't believe that any additional work has been done on the patches since then. The thread starts here: http://www.coreboot.org/pipermail/seabios/2014-June/008105.html Here's a link to the patch: http://www.seabios.org/pipermail/seabios/attachments/20140611/32c1a351 /attac hment-0001.gz Hi Julien, Were those boards using Bay Trail and booting coreboot / SeaBIOS? I'm assuming you just meant that SD boot works in general. Martin On 08/07/2014 08:16 AM, Wen Wang wrote: Julien, Thanks much for the information! We must have missed something. For SD card, we have SD enabled in fsp, and the GPIO mux configured in coreboot. Is there anything else we need to do? Did you have to do anything in seabios? Thanks, Wen -Original Message- From: Julien Snell [mailto:juliensn...@cc-e.co.uk] Sent: Thursday, August 7, 2014 3:34 AM To: Wen Wang; coreboot@coreboot.org Subject: Re: [coreboot] Baytrail SD card interface Wen, SD Card , SD Card Boot work. We have designed several Boards with SD Card Boot. Although I would recommend USB3 Boot as it's a magnitude faster. Regards Julien Snell Cocom www.cc-e.co.uk Cocom design and manufacture internet connected devices (IoT) Introducing two new brands Mi-ProtoPCB, UK made lightning fast assembled PCB proto-types and Mi-Embedded, your very own customised embedded board. -Original Message- From: coreboot [mailto:coreboot-boun...@coreboot.org] On Behalf Of Wen Wang Sent: 06 August 2014 20:45 To: coreboot@coreboot.org Subject: [coreboot] Baytrail SD card interface Hello all, Does the current baytrail fsp coreboot code support SD/uSD card interface? Is anybody able to get it to work on Bayley Bay CRB? It does not seem to work on our CRB. We checked the SD3_PWREN signal, it always remains high and therefore the SD card doesn't get any power. Thanks, Wen -- 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 -- http://se-eng.com -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] qemu-armv7: code execution out of RAM or ROM using latest QEMU
On Mon, Aug 11, 2014 at 04:00:19PM -0700, ron minnich wrote: Sorry, in other words, how much ROM are you setting up on that qemu board? The 'execute outside ram or rom' is usually a jump to an IP that qemu does not recognize as ROM/RAM. ROM is probably represented in vexpress-a9 as vexpress.flash0 and vexpress.flash1. Both are 64M (0x400). I suspect our emulator is assuming SRAM in there somewhere, can you check? Certainly we depend on SRAM on the real hardware. vexpress.sram is 32M (0x200). This is memory map (info mtree) form qemu console - VE_NORFLASHALIAS=0 https://gist.github.com/pietrushnic/afe7bd2e036150888609 Same thing with VE_NORFLASHALIAS=-1: https://gist.github.com/pietrushnic/be916c58de8c9a710297 Thanks, Piotr -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] qemu-armv7: code execution out of RAM or ROM using latest QEMU
On Tue, Aug 12, 2014 at 05:30:03AM +0200, Patrick Georgi wrote: Am 12.08.2014 um 00:37 schrieb Piotr Król: Anyone know how to load bootblock debug symbols to gdb when debugging using '-s -S' option ? add-symbol-file $filename $loadaddr When I try: gdb$ target remote :1234 Remote debugging using :1234 gdb$ add-symbol-file build/cbfs/fallback/bootblock.debug 0x0 add symbol table from file build/cbfs/fallback/bootblock.debug at .text_addr = 0x0 Reading symbols from /home/pietrushnic/src/coreboot/build/cbfs/fallback/bootblock.debug...warning: section .text not found in /home/pietrushnic/src/coreboot/build/cbfs/fallback/bootblock.debug done. Same thing for romstage.debug. When using ramstage without address: gdb$ add-symbol-file build/cbfs/fallback/ramstage.debug The address where build/cbfs/fallback/ramstage.debug has been loaded is missing And with address: gdb$ add-symboadd-symbol-file build/cbfs/fallback/ramstage.debug 0x0 add symbol table from file build/cbfs/fallback/ramstage.debug at .text_addr = 0x0 Reading symbols from /home/pietrushnic/src/coreboot/build/cbfs/fallback/ramstage.debug...done. But util/crossgcc/xgcc/bin/armv7-a-eabi-gdb doesn't break on methods and does not show executed line of code. Symbols seems to be loaded but I cannot use them to debug. Any ideas how to debug qemu system using armv7-a-eabi-gdb ? Thanks, Piotr -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] earliest running code with qemu
I have just started looking at coreboot and trying to get familure with how a machine actually boots from the moment the power is turned on. Is the first piece of code to run (using qemu) found here in src/arch/x86/lib/c_start.S in _start? I was hoping to be able to play with the cache as RAM code but it seems this is not done with qemu (I understand it doesn't need to done as qemu sets things up a bit). I know it isn't necessary but, out of curiosity, could cache as RAM code run on qemu? -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] earliest running code with qemu
I'm sure it could run were someone to implement it. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
