[coreboot] [RFC] board_status: Add serial log to `serial_console.txt`
Dear coreboot folks, currently no coreboot messages are stored for boards not supporting CBMEM console (or where this option is disabled (currently by default)) or no coreboot *romstage* messages are stored for boards, where the data cannot be preserved (passed to ramstage). Using the serial (or USB) console all these messages can be captured with no problem, so I propose to just add these captured messages into the file `serial_console.txt`. Of course this file probably contains also the payload and (Linux) kernel log, but I think that is fine. SeaBIOS’ `readserial.py` should be used for capturing the messages as it adds time stamps. Scripting this is going to be hard, as the log is captured on a different system. So for now I propose to add it manually. 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
Re: [coreboot] [RFC] board_status: Add serial log to `serial_console.txt`
On 09.02.2014 13:50, Paul Menzel wrote: > Dear coreboot folks, > > > currently no coreboot messages are stored for boards not supporting > CBMEM console Is there any remaining? If so it's an issue to be fixed > (or where this option is disabled (currently by default)) Change the defaults. > or no coreboot *romstage* messages are stored for boards, where the data > cannot be preserved (passed to ramstage). > which boards are concerned? Which boards use ROMCC for romstage? Do they output anything useful in romstage? If so, can't it be compensated by ramstage? > Using the serial (or USB) console all these messages can be captured > with no problem, so I propose to just add these captured messages into > the file `serial_console.txt`. Of course this file probably contains > also the payload and (Linux) kernel log, but I think that is fine. > > SeaBIOS’ `readserial.py` should be used for capturing the messages as it > adds time stamps. > > Scripting this is going to be hard, as the log is captured on a > different system. So for now I propose to add it manually. > Having to capture serial makes setup needed for board-status more difficult. Certainely, one needs to have a recovery method for case of brick but having a complete serial setup will heavily reduce board-status input which already isn't huge. > > Thanks, > > Paul > > > signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFC] board_status: Add serial log to `serial_console.txt`
Am Sonntag, den 09.02.2014, 14:18 +0100 schrieb Vladimir 'φ-coder/phcoder' Serbinenko: > On 09.02.2014 13:50, Paul Menzel wrote: > > currently no coreboot messages are stored for boards not supporting > > CBMEM console > > Is there any remaining? If so it's an issue to be fixed Sorry, no idea. I thought there were some. At least not all boards have been tested to my knowledge. > > (or where this option is disabled (currently by default)) > > Change the defaults. It is not safe or wanted for all boards I believe. But others are more knowledgeable to comment on that issue. > > or no coreboot *romstage* messages are stored for boards, where the data > > cannot be preserved (passed to ramstage). > > which boards are concerned? Which boards use ROMCC for romstage? Do they > output anything useful in romstage? If so, can't it be compensated by > ramstage? In my case it is the Asus M2V-MX SE (AMD, pre-AGESA). > > Using the serial (or USB) console all these messages can be captured > > with no problem, so I propose to just add these captured messages into > > the file `serial_console.txt`. Of course this file probably contains > > also the payload and (Linux) kernel log, but I think that is fine. > > > > SeaBIOS’ `readserial.py` should be used for capturing the messages as it > > adds time stamps. > > > > Scripting this is going to be hard, as the log is captured on a > > different system. So for now I propose to add it manually. > > Having to capture serial makes setup needed for board-status more > difficult. Surely it will not be a requirement to capture the serial output. My proposal is about adding it, when it is captured already and what file name to use. > Certainly, one needs to have a recovery method for case of > brick You always need that in case of a brick. What is special about serial log? > but having a complete serial setup will heavily reduce board-status > input which already isn't huge. Again, it is not meant to be a requirement in addition to what is currently captured. 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
Re: [coreboot] [RFC] board_status: Add serial log to `serial_console.txt`
On 09.02.2014 14:34, Paul Menzel wrote: > Am Sonntag, den 09.02.2014, 14:18 +0100 schrieb Vladimir 'φ-coder/phcoder' > Serbinenko: >> On 09.02.2014 13:50, Paul Menzel wrote: > >>> currently no coreboot messages are stored for boards not supporting >>> CBMEM console >> >> Is there any remaining? If so it's an issue to be fixed > > Sorry, no idea. I thought there were some. At least not all boards have > been tested to my knowledge. > board-status is all about testing. When we see incomplete coreboot_console.txt it means there is a bug to be fixed, not workarounded. >>> (or where this option is disabled (currently by default)) >> >> Change the defaults. > > It is not safe or wanted for all boards I believe. But others are more > knowledgeable to comment on that issue. > I don't see any problem with enabling cbmemc by default on all boards. >>> or no coreboot *romstage* messages are stored for boards, where the data >>> cannot be preserved (passed to ramstage). >> >> which boards are concerned? Which boards use ROMCC for romstage? Do they >> output anything useful in romstage? If so, can't it be compensated by >> ramstage? > > In my case it is the Asus M2V-MX SE (AMD, pre-AGESA). > What is the info we need from it? ROMCC boards usually don't output much. >>> Using the serial (or USB) Your argument with USB console is completele broken as EHCI debug is not supported on ROMCC boards at all. >>> console all these messages can be captured >>> with no problem, so I propose to just add these captured messages into >>> the file `serial_console.txt`. Of course this file probably contains >>> also the payload and (Linux) kernel log, but I think that is fine. >>> >>> SeaBIOS’ `readserial.py` should be used for capturing the messages as it >>> adds time stamps. >>> >>> Scripting this is going to be hard, as the log is captured on a >>> different system. So for now I propose to add it manually. >> >> Having to capture serial makes setup needed for board-status more >> difficult. > > Surely it will not be a requirement to capture the serial output. My > proposal is about adding it, when it is captured already and what file > name to use. > And who will care about it then? >> Certainly, one needs to have a recovery method for case of >> brick > > You always need that in case of a brick. What is special about serial > log? > I use debricking setup perhaps every 20 flashes on a supported board. Not every time. >> but having a complete serial setup will heavily reduce board-status >> input which already isn't huge. > > Again, it is not meant to be a requirement in addition to what is > currently captured. > > > Thanks, > > Paul > > > signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFC] board_status: Add serial log to `serial_console.txt`
On 02/09/2014 07:34 AM, Paul Menzel wrote: > Sorry, no idea. I thought there were some. At least not all boards > have been tested to my knowledge. > Please stop just throwing half-thoght proposals out there when you have "no idea" (your words, not mine). Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Setting up build environment
2014-02-09 20:05 GMT+01:00 Andy Pont : > Hello Idwer, 8< > I have noticed that whenever I call make it gives a warning about not having > a compiler for aarch64-elf and also complains about not having an IASL > compiler and suggesting that I install the one that comes with CentOS. You do not need aarch64-elf to compile for qemu, but you can leave the built binaries around. Apparently CentOS installs, or will install, a really old version of iasl; here you'll see that they (still) use iasl-20090123-3.1.el6.x86_64: http://mirror.centos.org/centos/6.5/os/x86_64/Packages/ while the xgcc version is 20130626. --- Another possible solution is to compile SeaBIOS manually: $ git clone https://github.com/KevinOConnor/seabios.git seabios_github && cd seabios_github $ make menuconfig $ make IASL=/home/andy.pont/Software/coreboot/util/crossgcc/xgcc/bin/iasl Then adjust the coreboot configuration so that it uses the manually compiled ELF, found in seabios_github/out/bios.bin.elf and run 'make' again in the coreboot directory. > > Thanks, > > Andy. > -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Setting up build environment
Adding seabios at seabios dot org to the recipients. 2014-02-10 0:47 GMT+01:00 Andy Pont : > Hello! > >> Apparently CentOS installs, or will install, a really old version of >> iasl; here you'll see that they (still) use >> iasl-20090123-3.1.el6.x86_64: >> http://mirror.centos.org/centos/6.5/os/x86_64/Packages/ while the xgcc >> version is 20130626. > > After doing some poking around it appears that IASL doesn't like the fact > that my home directory is /home/andy.pont and I assume that it is the dot > that is upsetting it as if I clone coreboot into a subdirectory under > /home/andy then the default configuration builds correctly. > > Thanks for your help and guidance, it is much appreciated. > > Andy. > Actually, this happens when you clone coreboot into a dir where its parent dir has a dot in it, and compile for any board without touching the payload defaults: python ./tools/acpi_extract.py /home/idwer/tmp/coreboot.fresh/build/seabios/out/acpi-dsdt.lst > /home/idwer/tmp/coreboot.fresh/build/seabios/out/acpi-dsdt.off Traceback (most recent call last): File "./tools/acpi_extract.py", line 221, in for line in fileinput.input(): File "/usr/lib/python2.7/fileinput.py", line 252, in next line = self.readline() File "/usr/lib/python2.7/fileinput.py", line 344, in readline self._file = open(self._filename, self._mode) IOError: [Errno 2] No such file or directory: '/home/idwer/tmp/coreboot.fresh/build/seabios/out/acpi-dsdt.lst' make[2]: *** [/home/idwer/tmp/coreboot.fresh/build/seabios/out/acpi-dsdt.hex] Error 1 make[1]: *** [build] Error 2 make: *** [seabios] Error 2 rm build/cbfs/fallback/romstage_null.elf build/util/sconfig/sconfig.tab.c build/cbfs/fallback/bootblock.elf build/util/sconfig/lex.yy.c -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Setting up build environment
Idwer Vollering wrote: > Actually, this happens when you clone coreboot into a dir where its > parent dir has a dot in it, and compile for any board without touching > the payload defaults: > > python ./tools/acpi_extract.py > /home/idwer/tmp/coreboot.fresh/build/seabios/out/acpi-dsdt.lst > > /home/idwer/tmp/coreboot.fresh/build/seabios/out/acpi-dsdt.off > Traceback (most recent call last): > File "./tools/acpi_extract.py", line 221, in > for line in fileinput.input(): > File "/usr/lib/python2.7/fileinput.py", line 252, in next > line = self.readline() > File "/usr/lib/python2.7/fileinput.py", line 344, in readline > self._file = open(self._filename, self._mode) > IOError: [Errno 2] No such file or directory: > '/home/idwer/tmp/coreboot.fresh/build/seabios/out/acpi-dsdt.lst' The path isn't mangled in any way so the problem must be a dependency in the Makefile. Perhaps there's a pattern substitution which doesn't do greedy patterh matching where that's what would be needed. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Unable to start correctly coreboot on Asus f2a85-m REV 1.02
> Please double check IDSOPT_IDS_ENABLED. > > I have first-hand experience with Rudolf's suggestion to use that #define, I > have an F2A85-M as well. With IDSOPT_IDS_ENABLED, the serial output is > significantly longer. I suspect the build system does not catch the change > since it's not in menuconfig. > > Perhaps try 'make clean' followed by all the normal build steps? I tried several times but I still get the same result. I tried to start with clean git, and I've already used "make clean" to no avail. If in doubt, do not hesitate to create a rom for me that I test. So the output now that I can get without this: coreboot-4.0-5454-g400c05c-dirty vendredi 7 février 2014, 09:25:15 (UTC+0100) starting... POST: 0x34 BSP Family_Model: 00610f31 cpu_init_detectedx = POST: 0x37 agesawrapper_amdinitreset Thank -- Best regards, HacKurx www.hackurx.info -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
