August 2014 - coreboot - mail.coreboot.org

Re: [coreboot] qemu-armv7: code execution out of RAM or ROM using latest QEMU
by Piotr Król Aug. 14, 2014

Aug. 14, 2014

On Mon, Aug 11, 2014 at 04:00:19PM -0700, ron minnich wrote: During debugging I found that stack is initialized in range 0x40000-0x7FF00 (using .Stack and .Stack_size). When coreboot code is executed: reset init_stack_loop call_bootblock main +- armv7_invalidate_caches +- icache_invalidate_all +- dcache_invalidate_all +- dcache_foreach <- here we have ldmia instruction that cause execution out of RAM/ROM I see that SP value change but stack memory dump (x/50x 0x7FE00) show all 0xffffffff. So my questions are: - how to check on qemu-system-arm that stack was correctly initialized and works fine ? - it looks like instruction like stmdb sp!, {r0, r1, r4, r5, r6, r7, r9, r10, r11, lr} is unable to dump register values on the stack - is above range initialized for stack really correct for qemu ? - memory map show that in that range flash0 is mapped (for '-bios' option), when I memsaved this range I get all 0xffffffff, or maybe I'm confusing some different types of memory ? Thanks, Piotr

1 0

Re: [coreboot] board_status.sh output from PC Engines ALIX 2c3
by Sevan / Venture37 Aug. 14, 2014

Aug. 14, 2014

> On 12 August 2014 07:11, Paul Menzel <paulepanter(a)users.sourceforge.net> wrote: >> 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. done, this time there was no coreboot_timestamp.txt created http://pastebin.com/16LBAfBL Sevan / Venture37

1 0

Re: [coreboot] earliest running code with qemu
by Carl-Daniel Hailfinger Aug. 13, 2014

Aug. 13, 2014

Am 13.08.2014 07:05 schrieb ron minnich: > I'm sure it could run were someone to implement it. A few years ago, I implemented partial MTRR support in Qemu. To be exact, I added support for not throwing away the MTRR contents after a write and now you can actually read the MTRRs after writing. That said, you'd have to add real MTRR handling to get CAR (cache-as-RAM) to work in Qemu. I once had some half-finished patches, but that was before Qemu used QOM. It might be possible to salvage these half-finished patches once I dig up my old hard drive. The mechanics of implementing CAR are a bit tricky, but I think overall maybe 200 lines of code should suffice. If you're still interested, tell me and I'll try to dig up my old patch over the next few weeks (old hard drive is in a pile, and I don't know which one has that patch). Regards, Carl-Daniel

2 1

earliest running code with qemu
by John de la Garza Aug. 13, 2014

Aug. 13, 2014

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?

2 1

Re: [coreboot] qemu-armv7: code execution out of RAM or ROM using latest QEMU
by Piotr Król Aug. 13, 2014

Aug. 13, 2014

On Mon, Aug 11, 2014 at 01:51:16PM -0700, ron minnich wrote: > I can't recall for ARM, it's been more than a year since I used qemu > on that platform. That said, ... on the platforms we use ROM is in low > memory. What's your coreboot system.map say? > I'm not sure what 'coreboot system.map' is but I will assume that you mean {bootblock, romstage, ramstage}.map. CONFIG_BOOTBLOCK_BASE is 0x10000 CONFIG_ROMSTAGE_BASE is 0x20000 CONFIG_SYS_SDRAM_BASE is 0x1000000 Uploaded files: https://gist.github.com/pietrushnic/7fea530d3498cf5ac5cfo Meanwhile I objdumped bootblock and found that ldmia instruction that breaks qemu execution came from dcache_foreach method. Anyone know how to load bootblock debug symbols to gdb when debugging using '-s -S' option ? Thanks, Piotr

3 3

Re: [coreboot] qemu-armv7: code execution out of RAM or ROM using latest QEMU
by Piotr Król Aug. 13, 2014

Aug. 13, 2014

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 (0x4000000). > > 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 (0x2000000). 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

1 0

Re: [coreboot] Baytrail SD card / eMMC interface
by Wen Wang Aug. 12, 2014

Aug. 12, 2014

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:marcj303@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.wang(a)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.roth@se-eng.com] > Sent: Thursday, August 7, 2014 11:08 AM > To: Wen Wang; 'Julien Snell'; coreboot(a)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:JulienSnell@cc-e.co.uk] >> Sent: Thursday, August 7, 2014 3:34 AM >> To: Wen Wang; coreboot(a)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-bounces@coreboot.org] On Behalf Of >> Wen Wang >> Sent: 06 August 2014 20:45 >> To: coreboot(a)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(a)coreboot.org >> http://www.coreboot.org/mailman/listinfo/coreboot >> >> >> >> > > > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot -- http://se-eng.com

1 0

Re: [coreboot] Intel HM76 support
by Alex Henrie Aug. 12, 2014

Aug. 12, 2014

2014-08-08 18:18 GMT-06:00 David Hendricks <dhendrix(a)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

1 0

[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)
by Paul Menzel Aug. 12, 2014

Aug. 12, 2014

Dear coreboot folks, Am Sonntag, den 10.08.2014, 16:34 +0200 schrieb gerrit(a)coreboot.org: > the following patch was just integrated into master: > commit a438049422fae85fe4df3ab3f89dbca797d6f5a9 > Author: Aaron Durbin <adurbin(a)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

2 1

Re: [coreboot] board_status.sh output from PC Engines ALIX 2c3
by Paul Menzel Aug. 12, 2014

Aug. 12, 2014

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

2 1