[coreboot] Some feedback regarding the coreboot hackaton poll

[echelon]

Hello all,

First of all I want to reassure everbody who participated to the poll for the 
hackaton in Paris, that it is NOT canceled (in the light of the recent 
events..) and that I am more deternined than ever to make it happen!..

On the other hand, at the time when I launched this poll (maybe a bit 
prematurelly), I was missing some important information regarding other 
initiatives about potential coreboot meetings in 2016, some of them related to 
important events which could have a big impact on the visibility of our project 
coreboot in the open source ecosystem. But I will let the persons which are 
driving these initiatives to make an anouncement themselves.

Regarding the hackaton in Paris, and taking into account these informations 
(not yet officially announced), I cannot yet anounce a firm date for the Paris 
venue, because we need to accomodate the Paris meeting with other important 
coreboot events which will take place in 2016.

Stay tunned..

Best regards,
  Florentin Demetrescu


-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Long boot delay with a large CBFS

[Stefan Reinauer]

* Ben Gardner  [151116 19:32]:
> [The previous email got chopped. This is a re-send.]
> 
> Hi all,
> 
> I have a 16 MB BIOS flash on a fsp_baytrail based design.
> 
> I tried expanding the CBFS to fill the whole space, but found that to
> cause a 10-15 sec boot delay.

Sounds like your CBFS file got corrupted. Anything you can share about
your build (e.g. log, source code) will raise the chance of getting this
fixed.

Are you running without ME firmware? What do your sections look like in
the firmware descriptor?

Stefan


-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] [ANNOUNCE] SeaBIOS 1.9.0

[Kevin O'Connor]

The 1.9.0 version of SeaBIOS has now been released.  For more
information on the release, please see:

http://seabios.org/Releases


New in this release:

* The default boot menu key is now the ESC key (instead of F12)
* Initial support for Trusted Platform Module (TPM) hardware and BIOS calls
* Initial support for chain loading SeaBIOS from Grub (via multiboot
  support)
* Initial support for booting from SD cards on real hardware
* virtio 1.0 device support
* The build will no longer include the build hostname or build time on
  "clean" builds.  This makes the build binaries more "reproducible".
* Basic support for running SeaBIOS on Baytrail Chromebooks
* SeaVGABIOS improvements:
* Improved support for old versions of x86emu (the "leal"
  instruction is now emulated)
* Several bug fixes and code cleanups


For information on obtaining SeaBIOS, please see:

http://seabios.org/Download


= git shortlog -n rel-1.8.0..rel-1.9.0 =

Kevin O'Connor (126):
  docs: add page for SeaVGABIOS
  docs: Add page describing the patch contribution process
  docs: Add page on available CBFS/fw_cfg runtime config files
  docs: Prefer triple backticks to multiple lines with single backticks
  smp: Fix smp race introduced in 0673b787
  docs: Note release date of 1.8.1
  vgabios: On bda_save_restore() the saved vbe_mode also has flags in it
  vgabios: Don't use extra stack if it appears a modern OS is in use
  docs: Clarify that pci-optionrom-exec doesn't apply to roms in cbfs
  checkstack: Replace function information tuple with class
  checkstack: Simplify yield calculations
  checkstack: Prefer passing "function" class instead of function address
  smbios: Use integer signature instead of string signature
  vgabios: Don't use "smsww" instruction - it confuses x86emu
  vgabios: Add config option for assembler fixups
  vgabios: Emulate "leal" instruction
  checkstack: Minor - continue if not a regular asm line
  Don't forward declare functions with "inline" in headers
  build: Support "make VERSION=xyz" to override the default build version
  tcg: Use seabios setup()/prepboot() calling convention for tcg
  build: CONFIG_VGA_FIXUP_ASM should depend on CONFIG_BUILD_VGABIOS
  bootorder: Update "extra pci root" buses bootorder format to match qemu
  Make sure all code checks for malloc failures
  docs: Note release date of 1.8.2
  block: Split process_op() command dispatch up into multiple functions
  block: Introduce default_process_op() with common command handling codes
  block: Route scsi style commands through 'struct disk_op_s'
  blockcmd: Introduce scsi_fill_cmd()
  ata: Handle ATA ATAPI drives directly via 'struct disk_op_s' requests
  ahci: Handle AHCI ATAPI drives directly via 'struct disk_op_s' requests
  usb-msc: Handle USB drives directly via 'struct disk_op_s' requests
  usb-uas: Handle USB drives directly via 'struct disk_op_s' requests
  lsi-scsi: Handle LSI drives directly via 'struct disk_op_s' requests
  esp-scsi: Handle ESP drives directly via 'struct disk_op_s' requests
  megasas: Handle Megasas drives directly via 'struct disk_op_s' requests
  virtio-scsi: Handle virtio drives directly via 'struct disk_op_s' requests
  pvscsi: Move pvscsi_fill_req() code into pvscsi_cmd()
  pvscsi: Handle pvscsi drives directly via 'struct disk_op_s' requests
  blockcmd: Remove unused scsi_process_op() and cdb_cmd_data()
  blockcmd: Convert cdb_is_read() to scsi_is_read()
  block: Rename process_XXX_op() functions to XXX_process_op()
  coreboot: Try to auto-detect if the CBFS anchor pointer is a relative 
pointer
  ps2: Support mode for polling the PS2 port instead of using irqs
  ata: Make sure "chanid" is relative to PCI device for bootorder file
  Don't enable interrupts prior to IVT and PIC setup
  ps2: Don't wait 100ms to discard possible extra reset receive byte
  timer: Delay timestamp counter init until after pmtimer is probed
  timer: Add CONFIG_TSC_TIMER build option to disable the CPU TSC timer
  ramdisk: Allow ramdisk support (CONFIG_FLASH_FLOPPY) under QEMU
  Minor - move declaration of CDRom_locks to code that uses it
  smm: ignore bits 16,18-31 of SMM revision ID at runtime too
  vgafb: Minor - move gfx_common() variables outside of switch statement
  sdcard: Check if card is present before sending commands to card
  sdcard: Implement controller frequency setting according to sdhci spec
  sdcard: Make sure controller support 3.3V before enabling it
  sdcard: Set timeout control register during init (to max allowed timeout)
  sdcard: Improve SD card initialization command sequence
  sdcard: Add proper delays during card power up
  mptable: Don't create mptable if it is very large
  optionroms: Don't run option rom on PCI bar if CBFS/fw_cfg version exists

Re: [coreboot] Understanding BIOS I/O Adresses

[panic]

Peter Stuge:
> Please don't post disassembly of code from outside the project. Thanks.

ok. noted.

>> In particular I'm interested in 0x80, 0x84/0x85, 0x8c/0x8d.
> 
>>From ports.lst:
> --P0080008F--
> PORT 0080-008F - DMA PAGE REGISTERS (74612)
> 
> ..
> 0084  RW  extra page register
> 0085  RW  extra page register
> 008C  RW  extra page register
> 008D  RW  extra page register
> 
> 
> So either something is being done with the DMA controller (seems
> unlikely in early boot) or these registers have a completely
> different meaning at that time in the platform lifecycle.

An idea is that, probably, these registers serve as scratchpad copy and
recover ax and dx because they are modified during the subroutines.

-- panic


-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] questions about veyron boards and the rk3288

[Anthony Martin]

1. Is veyron_mickey the ASUS Chromebit CS10?

2. Are any of the veyron_(danger|rialto|emile) products released yet?

3. Also, is the RK3288 TRM available without an NDA?

Cheers,
  Anthony

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] G505s status (and test report)

[Felix Held]

Hi Florentin!


As for adding support for Bolton and refactoring and unifying the FCH code, I 
would like to pick up the task, because I want to invest myself in coreboot dev 
again and I hope that I will have some time to spend in the near future...

Great!

IIRC someone in the IRC channel was also interested in the Bolton FCH; 
maybe you could work on that together. I don't remember the nickname though.



But I need to understand a little bit more the current architecture of coreboot 
and also the impact of recent developpements like the (proposed) switch from 
AGESA to native init..
But just to have an idea of the complexity of this task (refactoring amd fch 
code) can you give me some details of what needs to be done?
The FCH code of AGESA fam12, fam15tn and fam16kb isn't in a separate 
directory, but inside AGESA vendorcode. Which FCH code gets build, 
doesn't depend not on the southbridge Kconfig setting. Both fam12 and 
fam15tn trees include support for Hudson; the version in fam15tn is 
newer and likely has some bugfixes. The FCH code in fam16kb is different 
(Yangtze), but not too different.


I'd try to move the FCH support out of the different vendorcode/agesa 
subtrees into one tree structure in vendorcode/ages. Maybe see 
http://review.coreboot.org/#/c/7782/ for something to begin your work. 
When moving the code out of the AGESA subtrees you should adapt the 
Kconfig stuff, so that the selection of the FCH code depends on the 
selected southbridge. That might involve some patching to the subtrees 
where you factor out the FCH support.


When you have factored out the FCH vendorcode and somehow merged it into 
one directory structure where only the stuff relevant for one platform 
gets built, it should be relatively easy to extend the support for 
Bolton FCH.


On the AGESA stuff: It seems that the internal tree has support for all 
different families in one tree and only the source code which is 
relevant for one family gets built for that family. Before the code drop 
for each family everything unneeded for that family was removed and the 
remaining stuff of that tree was released for that family.


I can really recommend the 3 way folder compare mode of meld for the 
task of merging the 3 different FCH support code subtrees. fam12 and 
fam15tn have code for the same chips, but slightly different code; i'd 
use the newer version (fam15tn), since it likely contains some bugfixes.


To get the XHCI support on Bolton working, you'd at least have to patch 
Hudson2XhciResetService.c; in that file the code matches onto the PCI ID 
of the XHCI controller, which changed between Hudson and Bolton. You 
likely need to patch some other stuff as well to get the XHCI controller 
working.


When you have moved the FCH code out of the AGESA subtrees, it would be 
really great if you'd write native initialization for the FCH, which can 
be uses from both AGESA-based (maybe some glue code to AGESA is still 
needed for that) and native init based boards, but thats likely a 
non-trivial task.


I hope that this helps you a bit; that was more or less everything i 
remember from working on that. The current state of the code isn't 
pretty, but you'll see that quite quickly...


Also have a look at my (unfinished) Bolton support without working XHCI. 
Maybe it just needs the small patch that it also matches on the PCI ID 
of the XHCI controller in Bolton, but well, that would just be a hack.


Regards
Felix

--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] CBFS file format changed but documentation not updated

[Kevin O'Connor]

I noticed that commit 0d618afc modified the CBFS file format.  (It
looks like the "checksum" field was replaced with a new file
"attributes" feature.)  However, the CBFS documentation in the
repository (Documentation/cbfs.txt) was not updated.

It would be great if the documentation could be kept in sync with the
CBFS implementation.  (Or, if that's not feasible, I think it would be
preferable to remove Documentation/cbfs.txt .)  Having up to date
specifications helps other projects (eg, SeaBIOS) keep up with
changes.

Also, I didn't see any emails for the above change on the mailing
list.  What is the best way to keep up with notable architectural
changes in coreboot?

-Kevin

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] questions about veyron boards and the rk3288

[David Hendricks via coreboot]

On Tue, Nov 17, 2015 at 3:51 PM, Anthony Martin  wrote:

> 1. Is veyron_mickey the ASUS Chromebit CS10?
>

Yes.


> 2. Are any of the veyron_(danger|rialto|emile) products released yet?
>

No, but there are many Chromebooks which use the RK3288 and are available
in retail stores now.

-- 
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot