Re: [coreboot] STACK_SIZE pcengines apu1
I'd bet it's just a single large allocation somewhere. You can try adding CFLAGS_ramstage += -Wstack-usage=1024 somewhere in coreboot/Makefile.inc and then clean+rebuild your code while passing '-k' to make. You'll get a bunch of compiler warnings, and one of them is likely to be the culprit. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] STACK_SIZE pcengines apu1
On Thu, Sep 10, 2015 at 4:34 PM, Maxime de Roucy wrote: > Le jeudi 10 septembre 2015 à 09:02 -0500, Aaron Durbin a écrit : >> That's quite the stack usage. It'd be interesting to know what's >> using all that stack. Could you apply this patch and run w/ it? It'd >> help narrow down at what point in the boot where the stack gets used >> up. > > You will find the spew log of the modified coreboot you asked. > (it's a reboot, not a boot… I don't know if that's change something). BS: BS_DEV_INIT times (us): entry 0 run 358353 exit 0 CPU0: stack: 00148000 - 0014a000, lowest used address 00149a2c, stack used: 1492 bytes CBMEM: IMD: root @ d000 254 entries. IMD: root @ dfffec00 62 entries. Moving GDT to dfffea00...ok Finalize devices... Devices finalized agesawrapper_amdinitlate() returned AGESA_SUCCESS agesawrapper_amdS3Save() returned AGESA_SUCCESS SF: Detected MX25L1605D with sector size 0x1000, total 0x20 SF: Successfully erased 4096 bytes @ 0x1000 SF: Detected MX25L1605D with sector size 0x1000, total 0x20 SF: Successfully erased 4096 bytes @ 0x BS: BS_POST_DEVICE times (us): entry 9377 run 3502 exit 113447 CPU0: stack: 00148000 - 0014a000, lowest used address 00148d34, stack used: 4812 bytes So I'd get either agesawrapper_amdinitlate() or agesawrapper_amdS3Save(). In either case it's in AGESA. > -- > Regards > Maxime -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Hotel rooms: coreboot conference 2015
My sincere apologies, the email address seems to be out of order. Please use wissenschaftszent...@wzbonn.de for booking a bed+breakfast room at the conference venue. Regards, Carl-Daniel On 10.09.2015 22:14, Carl-Daniel Hailfinger wrote: > The venue still has 7 very affordable single/double rooms available! > > Email i...@wzbonn.de and tell them you're attending the coreboot > conference. Those rooms are reserved for conference participants. > > Regards, > Carl-Daniel > > > On 05.09.2015 03:12, coreboot conference wrote: >> Dear vendors, developers, users and interested parties, >> >> On behalf of the Federal Office for Information Security (BSI) Germany I >> would >> like to invite you to the coreboot conference and developer meeting on >> October 9-11 2015 in Bonn, Germany. >> >> This conference and developer meeting is geared towards manufacturers of >> hardware (processors, chipsets, mainboards and servers/ laptops/ tablets/ >> desktops/ appliances) as well as developers of firmware with an interest in >> coreboot and the possibilities it offers as well as (potential) coreboot >> users. Both professionals and hobbyists are invited. >> >> Please see the full text of the invitation at >> http://coreboot.org/coreboot_conference_Bonn_2015 >> >> Sincerely, >> Carl-Daniel Hailfinger > -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] STACK_SIZE pcengines apu1
Le jeudi 10 septembre 2015 à 09:02 -0500, Aaron Durbin a écrit : > That's quite the stack usage. It'd be interesting to know what's > using all that stack. Could you apply this patch and run w/ it? It'd > help narrow down at what point in the boot where the stack gets used > up. You will find the spew log of the modified coreboot you asked. (it's a reboot, not a boot… I don't know if that's change something). -- Regards MaximeCBFS @ 0 size 1ff9c0 CBFS: Locating 'cmos_layout.bin' CBFS: Found @ offset 140 size 774 coreboot-4.1-302-gbad0cc0-dirty Sun Sep 6 17:23:04 UTC 2015 ramstage starting... BS: BS_PRE_DEVICE times (us): entry 0 run 0 exit 0 CPU0: stack: 00148000 - 0014a000, lowest used address 00149ce4, stack used: 796 bytes SB800 - Smbus.c - alink_ab_indx - Start. SB800 - Smbus.c - alink_ab_indx - End. BS: BS_DEV_INIT_CHIPS times (us): entry 0 run 7163 exit 0 CPU0: stack: 00148000 - 0014a000, lowest used address 00149ce4, stack used: 796 bytes Enumerating buses... Show all devs... Before device enumeration. Root Device: enabled 1 CPU_CLUSTER: 0: enabled 1 APIC: 00: enabled 1 DOMAIN: : enabled 1 PCI: 00:00.0: enabled 1 PCI: 00:01.0: enabled 0 PCI: 00:04.0: enabled 1 PCI: 00:05.0: enabled 1 PCI: 00:06.0: enabled 1 PCI: 00:07.0: enabled 1 PCI: 00:08.0: enabled 1 PCI: 00:11.0: enabled 1 PCI: 00:12.0: enabled 1 PCI: 00:12.2: enabled 1 PCI: 00:13.0: enabled 1 PCI: 00:13.2: enabled 1 PCI: 00:14.0: enabled 1 PCI: 00:14.1: enabled 0 PCI: 00:14.2: enabled 0 PCI: 00:14.3: enabled 1 PNP: 002e.0: enabled 0 PNP: 002e.2: enabled 1 PNP: 002e.3: enabled 1 PNP: 002e.10: enabled 0 PNP: 002e.11: enabled 0 PNP: 002e.8: enabled 0 PNP: 002e.f: enabled 0 PNP: 002e.7: enabled 0 PNP: 002e.107: enabled 0 PNP: 002e.607: enabled 0 PNP: 002e.e: enabled 0 PCI: 00:14.4: enabled 1 PCI: 00:14.5: enabled 0 PCI: 00:15.0: enabled 1 PCI: 00:15.1: enabled 0 PCI: 00:15.2: enabled 0 PCI: 00:15.3: enabled 0 PCI: 00:16.0: enabled 1 PCI: 00:16.2: enabled 1 PCI: 00:18.0: enabled 1 PCI: 00:18.1: enabled 1 PCI: 00:18.2: enabled 1 PCI: 00:18.3: enabled 1 PCI: 00:18.4: enabled 1 PCI: 00:18.5: enabled 1 PCI: 00:18.6: enabled 1 PCI: 00:18.7: enabled 1 Compare with tree... Root Device: enabled 1 CPU_CLUSTER: 0: enabled 1 APIC: 00: enabled 1 DOMAIN: : enabled 1 PCI: 00:00.0: enabled 1 PCI: 00:01.0: enabled 0 PCI: 00:04.0: enabled 1 PCI: 00:05.0: enabled 1 PCI: 00:06.0: enabled 1 PCI: 00:07.0: enabled 1 PCI: 00:08.0: enabled 1 PCI: 00:11.0: enabled 1 PCI: 00:12.0: enabled 1 PCI: 00:12.2: enabled 1 PCI: 00:13.0: enabled 1 PCI: 00:13.2: enabled 1 PCI: 00:14.0: enabled 1 PCI: 00:14.1: enabled 0 PCI: 00:14.2: enabled 0 PCI: 00:14.3: enabled 1 PNP: 002e.0: enabled 0 PNP: 002e.2: enabled 1 PNP: 002e.3: enabled 1 PNP: 002e.10: enabled 0 PNP: 002e.11: enabled 0 PNP: 002e.8: enabled 0 PNP: 002e.f: enabled 0 PNP: 002e.7: enabled 0 PNP: 002e.107: enabled 0 PNP: 002e.607: enabled 0 PNP: 002e.e: enabled 0 PCI: 00:14.4: enabled 1 PCI: 00:14.5: enabled 0 PCI: 00:15.0: enabled 1 PCI: 00:15.1: enabled 0 PCI: 00:15.2: enabled 0 PCI: 00:15.3: enabled 0 PCI: 00:16.0: enabled 1 PCI: 00:16.2: enabled 1 PCI: 00:18.0: enabled 1 PCI: 00:18.1: enabled 1 PCI: 00:18.2: enabled 1 PCI: 00:18.3: enabled 1 PCI: 00:18.4: enabled 1 PCI: 00:18.5: enabled 1 PCI: 00:18.6: enabled 1 PCI: 00:18.7: enabled 1 Mainboard APU1 Enable. Root Device scanning... root_dev_scan_bus for Root Device setup_bsp_ramtop, TOP MEM: msr.lo = 0xe000, msr.hi = 0x setup_bsp_ramtop, TOP MEM2: msr.lo = 0x1f00, msr.hi = 0x0001 CPU_CLUSTER: 0 enabled DOMAIN: enabled CPU_CLUSTER: 0 scanning... AP siblings=1 CPU: APIC: 00 enabled CPU: APIC: 01 enabled DOMAIN: scanning... PCI: pci_scan_bus for bus 00 PCI: 00:00.0 [1022/1510] ops PCI: 00:00.0 [1022/1510] enabled Capability: type 0x01 @ 0x50 Capability: type 0x10 @ 0x58 Capability: type 0x05 @ 0xa0 Capability: type 0x0d @ 0xb0 Capability: type 0x08 @ 0xb8 Capability: type 0x01 @ 0x50 Capability: type 0x10 @ 0x58 PCI: 00:04.0 subordinate bus PCI Express PCI: 00:04.0 [1022/1512] enabled Capability: type 0x01 @ 0x50 Capability: type 0x10 @ 0x58 Capability: type 0x05 @ 0xa0 Capability: type 0x0d @ 0xb0 Capability: type 0x08 @ 0xb8 Capability: type 0x01 @ 0x50 Capability: type 0x10 @ 0x58 PCI: 00:05.0 subordinate bus PCI Express PCI: 00:05.0 [1022/1513] enabled Capability: type 0x01 @ 0x50 Capability: type 0x10 @ 0x58 Capability: type 0x05 @ 0xa0 Capability: type 0x0d @ 0xb0 Capability: type 0x08 @ 0xb8 Capability: type 0x01 @ 0x50 Capability: type 0x10 @ 0x58 PCI: 00:06.0 subordinate bus PCI Express PCI: 00:06.0 [1022/1514] enabled PCI: Static device PCI: 00:07.0 not found, disabling it. PCI: Static device PCI: 00:08.0 not found, disabling it. PCI: 00:11.0 [1002/4390] enabled PCI: 00:12.0 [1002/4397] ops PCI: 00:12.0 [1002/4397] enabled PCI: 00:12.2 [1002/4396] ops PCI: 00:12.2 [1002/4396] enabled PCI: 00:13.0 [1002/4397] ops PCI: 00:13
Re: [coreboot] coreinfo "General Protection Fault Exception"
Le jeudi 10 septembre 2015 à 15:35 +, Marc Jones a écrit : > It looks like coreinfo is the only payload, so there is nothing to > exit back to. What were you expecting to happen? > > You can try using seabios with multiple payloads or work with bayou > as a multiple payload loader. No, coreinfo isn't the only payload. SeaBIOS is the main payload, I also have memtest and ipxe (once I also have nvramcui). I didn't expect coreinfo to launch to the next payload when it stop. I expect it to reboot the computer as nvramcui do. max@max-laptop % ./cbfstool coreboot.rom print coreboot.rom: 2048 kB, bootblocksize 1576, romsize 2097152, offset 0x0 alignment: 64 bytes, architecture: x86 Name Offset Type Size … genroms/ipxe.rom 0x6a880raw 56832 img/coreinfo 0x786c0payload 65500 img/memtest0x88700payload 147240 … -- Regards Maxime signature.asc Description: This is a digitally signed message part -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Hotel rooms: coreboot conference 2015
The venue still has 7 very affordable single/double rooms available! Email i...@wzbonn.de and tell them you're attending the coreboot conference. Those rooms are reserved for conference participants. Regards, Carl-Daniel On 05.09.2015 03:12, coreboot conference wrote: > Dear vendors, developers, users and interested parties, > > On behalf of the Federal Office for Information Security (BSI) Germany I would > like to invite you to the coreboot conference and developer meeting on > October 9-11 2015 in Bonn, Germany. > > This conference and developer meeting is geared towards manufacturers of > hardware (processors, chipsets, mainboards and servers/ laptops/ tablets/ > desktops/ appliances) as well as developers of firmware with an interest in > coreboot and the possibilities it offers as well as (potential) coreboot > users. Both professionals and hobbyists are invited. > > Please see the full text of the invitation at > http://coreboot.org/coreboot_conference_Bonn_2015 > > Sincerely, > Carl-Daniel Hailfinger -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreinfo "General Protection Fault Exception"
It looks like coreinfo is the only payload, so there is nothing to exit back to. What were you expecting to happen? You can try using seabios with multiple payloads or work with bayou as a multiple payload loader. Marc On Thu, Sep 10, 2015 at 12:54 AM Maxime de Roucy wrote: > Hello, > > On a pcengines apu1 when I tried to leave coreinfo (press ESC) I get a > "General Protection Fault Exception". > > I attached my .config file of coreinfo (it's the default configuration) > and the console output when coreinfo crash. > -- > Regards > Maxime de Roucy-- > 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] STACK_SIZE pcengines apu1
On Sun, Sep 6, 2015 at 9:10 AM, Maxime de Roucy wrote: > Hello, > > I am building a coreboot rom for my pcengines apu1. > A bug is logged during the boot process : > http://review.coreboot.org/gitweb?p=board-status.git;a=blob;f=pcengines/apu1/4.0-9873-g7b9762f/2015-06-04T15:16:28Z/coreboot_console.txt;hb=HEAD#l1281 > > In order to solve it I applied this changed : > > diff --git a/src/Kconfig b/src/Kconfig > index 9c01687..c8b8ad2 100644 > --- a/src/Kconfig > +++ b/src/Kconfig > @@ -427,7 +427,7 @@ config HEAP_SIZE > config STACK_SIZE > hex > default 0x0 if (ARCH_RAMSTAGE_ARM || ARCH_RAMSTAGE_MIPS || > ARCH_RAMSTAGE_RISCV) > - default 0x1000 > + default 0x2000 > > config MAX_CPUS > int > > I don't see the bug line anymore, instead I see : > > CPU0: stack: 00148000 - 0014a000, lowest used address 00148d34, stack > used: 4812 bytes > > I now the patch is not good since it change the default stack size for > all the boards. I didn't found the right place the change the stack > size only for pcengines apu1 board. > But maybe those informations can help developers to improve coreboot. That's quite the stack usage. It'd be interesting to know what's using all that stack. Could you apply this patch and run w/ it? It'd help narrow down at what point in the boot where the stack gets used up. Also, that you used 4812 bytes just means you overwrote the other CPU's stack at some point when STACK_SIZE == 4KiB. diff --git a/src/lib/hardwaremain.c b/src/lib/hardwaremain.c index b3c0c35..8a241b2 100644 --- a/src/lib/hardwaremain.c +++ b/src/lib/hardwaremain.c @@ -378,6 +378,8 @@ static void bs_walk_state_machine(void) bs_report_time(state); state->complete = 1; + + checkstack(_estack, 0); } } > -- > Regards > Maxime de Roucy > -- > 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] unbricking an Acer CB5
On 2015-09-06 17:52, Holger Brunn wrote: Dear readers, I played with compiling my own coreboot image for my Acer CB5 [1] and failed miserably - the bios is messed up and the device won't boot any more. Now I'm busy following some guides to undo the damage [2], [3] by flashing the original bios again, but given I'm quite clueless about hardware, I'd like to ask you for advice about how to proceed: I ordered a Raspberry PI, some connector cables [4], and then I probably need a clip to connect the chip [5]. My question to you is how to locate the chip? The mainboard looks like that: http://opensource.holgerbrunn.net/debian-on-acer-cb5/images/DSC01629.JPG and the only chip that looks like those in the examples is U37 in the lower right. Is there any way to know beforehand if it's the correct one? And then when connecting the pins, can I look up somewhere what the correct assignment is or is this trial and error? I can't read what is printed on it, but if relevant, I'll get a magnifying glass to post the text. Yes, u37 looks like it. But, bear in mind many Chromebooks have the SPI on the other side of the board. If the chip is the wrong size (early Chromebooks had a separate EC on a 512k SPI) Flashrom will crap out and complain when you try to flash an 8MB binary to it. Pin assignment is available in various articles on the web, this is one I found by searching - https://github.com/bibanon/Coreboot-ThinkPads/wiki/Hardware-Flashing-with-Raspberry-Pi. I have used a magnifying app on my smart-phone before, but it's unnecessary. HTH, John. Thank you a lot in advance, and be sure that I won't come back whining if anything goes wrong and I fry the chip following your advice - that's entirely my fault then. I'll log the process on the above website if successful so that the next person messing this up won't have to bother you. Regards, Holger Links: [1] https://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices/acer-cb5-311-chromebook-13 [2] http://www.tnhh.net/2014/08/25/unbricking-chromebook-with-beaglebone.html [3] https://johnlewis.ie/unbricking-a-samsung-series-5-550-chromebook [4] https://www.conrad.nl/nl/raspberry-pi-verbindingskabel-rb-cb5-025-bont-banana-pi-pcduino-arduino-raspberry-pi-a-b-b-1290220.html?sc.ref=Homepage [5] http://www.digikey.nl/product-detail/en/5250/501-1311-ND/745102 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
