coreboot March 2018

coreboot@coreboot.org

62 participants
103 discussions

Re: [coreboot] $7 cheap FT232H board as EHCI debug dongle for coreboot - would it work?
by Mike Banon 05 Mar '18

05 Mar '18

Hi Kyosti, Thank you very much for your reply! I will try to get a couple of these FT232H boards: perhaps just 1 is required for the successful setup, but these boards are not common (just 15 or 20 search results) so maybe its' a good idea to take 2 ;) If this FT232H board works, it would be an ideal replacement both for commercial AMIDebug Rx / Ajays NET20DC (because much cheaper) and FX2LP (because no DIY will be required). Maybe this info could even be added to the official coreboot wiki, but I don't have an account there and it seems hard to get, so I'm using the DangerousPrototypes wiki Will write an update when I'd get the boards and test them with AMD G505S laptop. I'm curious what Lenovo G505S is writing to the coreboot log while it boots Best regards, Mike Banon On Sat, Mar 3, 2018 at 4:57 PM, Kyösti Mälkki <kyosti.malkki(a)gmail.com> wrote: > Hi Mike > > On Sat, Mar 3, 2018 at 3:27 PM, Mike Banon <mikebdp2(a)gmail.com> wrote: >> Good day! I am looking for the dirt cheap EHCI debug dongle. Initially >> I found these instructions for FX2LP - >> https://www.coreboot.org/DIY_EHCI_debug_dongle - but they require a >> lot of manual soldering/mods which depend on your boards revision and >> I am not sure if the currently produced boards are 100% compatible >> with the wiki instructions > > PCBs indeed have some variations. I pretty much abandoned all efforts > with FX2LP. However, some people were able to emulate the discontinued > net20dc dongle product with the FX2LP approach, to the level it was > operational with proprietary windows kernel debugger. > >> >> But then I noticed a coreboot has USBDEBUG_DONGLE_FTDI_FT232H option: >> " Use this with FT232H usb-to-uart. Configuration is hard-coded to use >> 8n1, no flow control " >> >> Kyösti Mälkki tested it " with gizmosphere/gizmo1 Explorer add-on >> board, which exposes the following device: >> 0x0403 Future Technology Devices International, Ltd >> 0x6014 FT232H Single HS USB-UART/FIFO IC " >> but gizmo1 is expensive and I am not a fan of the single board >> computers (SBCs) : they all require the binary blobs which could >> contain the scary backdoors >> > > Just forget all the talk about gizmo1, it was just the way I was able > to test it i.e. I had the hardware at hand. > >> However, there are $7 cheap FT232H boards with USB available at AliExpress: >> >> https://www.aliexpress.com/item/NEW-CJMCU-FT232H-Multifunction-High-Speed-U… >> >> I plan to get a couple of these boards, connect them to each other >> with 1P 2.54mm wires, plug the 1st board into master PC >> (coreboot-PC-under-debug) USB 2.0 port and the 2nd board into slave PC >> (another coreboot PC which will be logging the debug info) >> >> Please tell me: could this setup work in theory, or there are obvious >> shortcomings that could prevent it from working? >> > > Sounds good with three wires, cross RX&TX, add GND. Only the 1st board > (DUT) has to be FT232H, 2nd can be regular uart-to-usb like FT232R or > PL2103(?), This FT232H board also does the job of external SPI flash > recovery with flashrom. > > And.. kudos for Nico H for the initial FT232H init sequence code. > > Kyösti

1 0

Re: [coreboot] how does FSP play its role in Haswell/Broadwell/Skylake
by Matt DeVillier 05 Mar '18

05 Mar '18

Haswell and Broadwell don't use FSP, they use the MRC blob for RAM init. For Haswell, coreboot does all of the silicon init as well; for Broadwell, coreboot does most of the silicon init, and some bits are handled by another blob (refcode.elf). Skylake uses FSP (1.1 or 2.0, depending on the board in question) for both RAM and silicon init. cheers, Matt On Sun, Mar 4, 2018 at 11:12 PM, Zheng Bao <fishbaoz(a)hotmail.com> wrote: > Hi, > > how does FSP play its role in Haswell/Broadwell/Skylake? > > > Take the Broadwell as the example, which I ported coreboot successfully. > > > I use the mrc.bin and vboot.bin from Chromebook BIOS image. > > I use the ME tool, fitc, to add the IFD to the BIOS image. > > The final image works well and boots linux. > > > But where is FSP? Or which is FSP? > > > Zheng > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot >

1 0

how does FSP play its role in Haswell/Broadwell/Skylake
by Zheng Bao 05 Mar '18

05 Mar '18

Hi, how does FSP play its role in Haswell/Broadwell/Skylake? Take the Broadwell as the example, which I ported coreboot successfully. I use the mrc.bin and vboot.bin from Chromebook BIOS image. I use the ME tool, fitc, to add the IFD to the BIOS image. The final image works well and boots linux. But where is FSP? Or which is FSP? Zheng

1 0

ARM Veyron Speedy - Replacing 11.6 inch display for 15 inch
by Mark Wylde 04 Mar '18

04 Mar '18

The ASUS C201 comes with an 11.6inch EDP display. I was wondering if you could simply swap it for a 15'' EDP display. I tried it, but as expected it didn't work, however the backlight came on and I had the following logs: ---------------------------------------------------------------- Attempting to setup EDP display. do not get hpd single, force hpd Extracted contents: header: 00 ff ff ff ff ff ff 00 serial number: 0d ae c4 15 00 00 00 00 28 17 version: 01 04 basic params: 95 22 13 78 02 chroma info: ef 05 90 54 52 93 29 25 50 54 established: 00 00 00 standard: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 descriptor 1: 5e 35 80 96 70 38 14 40 2c 1c 24 00 58 c1 10 00 00 18 descriptor 2: 00 00 00 fe 00 4e 31 35 36 48 47 45 2d 45 41 42 0a 20 descriptor 3: 00 00 00 fe 00 43 4d 4e 0a 20 20 20 20 20 20 20 20 20 descriptor 4: 00 00 00 fe 00 4e 31 35 36 48 47 45 2d 45 41 42 0a 20 extensions: 00 checksum: 1d Manufacturer: CMN Model 15c4 Serial Number 0 Made week 40 of 2013 EDID version: 1.4 Digital display 6 bits per primary color channel DisplayPort interface Maximum image size: 34 cm x 19 cm Gamma: 220% Check DPMS levels Supported color formats: RGB 4:4:4 First detailed timing is preferred timing Established timings supported: Standard timings supported: Detailed timings Hex of detail: 5e358096703814402c1c240058c110000018 Detailed mode (IN HEX): Clock 136620 KHz, 158 mm x c1 mm 0780 07ac 07c8 0816 hborder 0 0438 043a 043e 044c vborder 0 -hsync -vsync Did detailed timing Hex of detail: 000000fe004e3135364847452d4541420a20 ASCII string: N156HGE-EAB Hex of detail: 000000fe00434d4e0a202020202020202020 ASCII string: CMN Hex of detail: 000000fe004e3135364847452d4541420a20 ASCII string: N156HGE-EAB Checksum Checksum: 0x1d (valid) Configuring PLL at ff760040 with NF = 1346, NR = 59 and NO = 4 (VCO = 547525KHz, output = 136881KHz) requested signal parameters: lane 0 voltage 0.6V pre_emph 0dB requested signal parameters: lane 1 voltage 0.6V pre_emph 0dB using signal parameters: voltage 0.6V pre_emph 0dB requested signal parameters: lane 0 voltage 0.8V pre_emph 0dB requested signal parameters: lane 1 voltage 0.8V pre_emph 0dB using signal parameters: voltage 0.8V pre_emph 0dB requested signal parameters: lane 0 voltage 1.2V pre_emph 0dB requested signal parameters: lane 1 voltage 1.2V pre_emph 0dB using signal parameters: voltage 1.2V pre_emph 0dB clock recovery reached max voltage clock recovery failed link train failed! edp enable err ---------------------------------------------------------------- It looks to me (as a complete noob) that the display (http://www.yslcd.com.tw/docs/product/N156HGE-EAB.pdf) needs around 3.3 volts. Looking at the code, it seems the ./src/soc/rockchip/common/edp.c handles this part of the booting process. Line 38 seems to imply the maximum voltage is 1.2v. ---------------------------------------------------------------- static const char *voltage_names[] = { "0.4V", "0.6V", "0.8V", "1.2V" }; ---------------------------------------------------------------- Is there a reason this is the maximum? Unfortunately there doesn't seem to be much information on the specifications of the C201, I guess as it's not really an open machine. Maybe the motherboard can only handle that voltage? I'm extremely new to coreboot, and to be honest not even sure the C201 can even handle a 15'' display. Does anyone know if I'm on the right track, or if this is a pointless exercise? Thank you and sorry if these are silly questions. Mark

1 0

(libre) Add-on cards for getting higher SSD throughput on the KGPE-D16?
by Daniel Kulesz 03 Mar '18

03 Mar '18

Hi, after plugging a rather newish 2,5 SATA SSD to my KGPE-D16, I realized that the regular SATA ports connected to the SP5100 on this board can only handle SATA2, limiting transfer speeds to max. 300 MB/s. I thought about various options what I could do now: (1) try to get the PIKE 9230 card => but does come with a co-processor and non-free firmware like the SAS Pike cards? Seems almost impossible to get one though (2) get the PIKE 2008 card => will SATA3 work without non-free firmware? (3) put in some PCIe SATA3 card => any recommended chips that respect freedom? (4) get a m.2 SSD instead together with some PCIe adapter => the cards don't have a co-processor, right? (5) stay with SATA2 and live with the limited speed Any recommendations for a freedom-respecting choice? Cheers, Daniel

4 5

Re: [coreboot] $7 cheap FT232H board as EHCI debug dongle for coreboot - would it work?
by Kyösti Mälkki 03 Mar '18

03 Mar '18

Hi Mike On Sat, Mar 3, 2018 at 3:27 PM, Mike Banon <mikebdp2(a)gmail.com> wrote: > Good day! I am looking for the dirt cheap EHCI debug dongle. Initially > I found these instructions for FX2LP - > https://www.coreboot.org/DIY_EHCI_debug_dongle - but they require a > lot of manual soldering/mods which depend on your boards revision and > I am not sure if the currently produced boards are 100% compatible > with the wiki instructions PCBs indeed have some variations. I pretty much abandoned all efforts with FX2LP. However, some people were able to emulate the discontinued net20dc dongle product with the FX2LP approach, to the level it was operational with proprietary windows kernel debugger. > > But then I noticed a coreboot has USBDEBUG_DONGLE_FTDI_FT232H option: > " Use this with FT232H usb-to-uart. Configuration is hard-coded to use > 8n1, no flow control " > > Kyösti Mälkki tested it " with gizmosphere/gizmo1 Explorer add-on > board, which exposes the following device: > 0x0403 Future Technology Devices International, Ltd > 0x6014 FT232H Single HS USB-UART/FIFO IC " > but gizmo1 is expensive and I am not a fan of the single board > computers (SBCs) : they all require the binary blobs which could > contain the scary backdoors > Just forget all the talk about gizmo1, it was just the way I was able to test it i.e. I had the hardware at hand. > However, there are $7 cheap FT232H boards with USB available at AliExpress: > > https://www.aliexpress.com/item/NEW-CJMCU-FT232H-Multifunction-High-Speed-U… > > I plan to get a couple of these boards, connect them to each other > with 1P 2.54mm wires, plug the 1st board into master PC > (coreboot-PC-under-debug) USB 2.0 port and the 2nd board into slave PC > (another coreboot PC which will be logging the debug info) > > Please tell me: could this setup work in theory, or there are obvious > shortcomings that could prevent it from working? > Sounds good with three wires, cross RX&TX, add GND. Only the 1st board (DUT) has to be FT232H, 2nd can be regular uart-to-usb like FT232R or PL2103(?), This FT232H board also does the job of external SPI flash recovery with flashrom. And.. kudos for Nico H for the initial FT232H init sequence code. Kyösti

1 0

$7 cheap FT232H board as EHCI debug dongle for coreboot - would it work?
by Mike Banon 03 Mar '18

03 Mar '18

Good day! I am looking for the dirt cheap EHCI debug dongle. Initially I found these instructions for FX2LP - https://www.coreboot.org/DIY_EHCI_debug_dongle - but they require a lot of manual soldering/mods which depend on your boards revision and I am not sure if the currently produced boards are 100% compatible with the wiki instructions But then I noticed a coreboot has USBDEBUG_DONGLE_FTDI_FT232H option: " Use this with FT232H usb-to-uart. Configuration is hard-coded to use 8n1, no flow control " Kyösti Mälkki tested it " with gizmosphere/gizmo1 Explorer add-on board, which exposes the following device: 0x0403 Future Technology Devices International, Ltd 0x6014 FT232H Single HS USB-UART/FIFO IC " but gizmo1 is expensive and I am not a fan of the single board computers (SBCs) : they all require the binary blobs which could contain the scary backdoors However, there are $7 cheap FT232H boards with USB available at AliExpress: https://www.aliexpress.com/item/NEW-CJMCU-FT232H-Multifunction-High-Speed-U… I plan to get a couple of these boards, connect them to each other with 1P 2.54mm wires, plug the 1st board into master PC (coreboot-PC-under-debug) USB 2.0 port and the 2nd board into slave PC (another coreboot PC which will be logging the debug info) Please tell me: could this setup work in theory, or there are obvious shortcomings that could prevent it from working? Best regards, Mike Banon

1 0

Re: [coreboot] ARMv8 MMU changes
by Julius Werner 03 Mar '18

03 Mar '18

Thanks for the details. I agree that adding 48-bit support is better than PA!=VA, but I really think you should implement the L0 table instead of messing with the granule size. This should really not be hard to do since our paging code is already recursive... just add an L0_ADDR_SHIFT and use it instead of L1_ADDR_SHIFT in mmu_init() and get_pte(), and then duplicate the code block handling L1 in init_xlat_table() for L0. That should be everything you need. You can see that L1 is essentially already implemented as optional right now with those BITS_PER_VA > L1_ADDR_SHIFT tests, even though that never really matters at the moment with BITS_PER_VA hardcoded to 33. But you should be able to just do the same thing for L0 (and maybe make L1 non-optional instead because I don't think we ever anticipate not needing it at this point). Changing the granule size would not only break the assumption that pages are 4K (which we probably have in a bunch of code) and make it impossible to map smaller boundaries which you sometimes need to do (e.g. SRAM areas don't always start or end at 64K boundaries), it also makes your page tables incredibly bloated (64K *each*, and you usually need at least 3) which would essentially make this unusable for SRAM systems. Adding L0 only costs you one extra 4K table and is much more flexible. It would be nice if you could do this change in both coreboot and libpayload since we're trying to keep both implementations in sync. On Fri, Mar 2, 2018 at 10:36 AM, David Hendricks <david.hendricks(a)gmail.com> wrote: > > > On Thu, Mar 1, 2018 at 11:30 PM, Patrick Rudolph < > patrick.rudolph(a)9elements.com> wrote: > >> Am Donnerstag, den 01.03.2018, 14:11 -0800 schrieb Julius Werner: >> > Hi Patrick et. al., >> > >> > Continuing from what you said on IRC, let's please discuss this >> > before you spend time to work on any major changes to the ARMv8 MMU >> > code. I don't think that should be necessary (especially changing the >> > GRANULE_SIZE which is a complication I'd really like to avoid >> > having), and I'd like to understand what you're trying to do first. >> > Can you explain what memory ranges you need to map on your SoC and >> > why they need to be so large? >> > >> Hi Julius, >> the Cavium SoC expose the MMIO space at 1 << 47 with a size of 1 << 47. >> As coreboot does use PA=VA mapping, I have to extend the VA space to 48 >> bit and that seems to work fine with 64KB granule. >> >> The change in coreboot is minimal, I'm not sure if all armv8 CPUs >> support's that granule, but a Kconfig should do for now. >> > > Yes, the architecture reference manual for ARMv8 mentions that 4KB, 16KB, > and 64KB are supported for VMSAv8-64. >

1 0

Re: [coreboot] ARMv8 MMU changes
by Patrick Rudolph 02 Mar '18

02 Mar '18

Am Donnerstag, den 01.03.2018, 14:11 -0800 schrieb Julius Werner: > Hi Patrick et. al., > > Continuing from what you said on IRC, let's please discuss this > before you spend time to work on any major changes to the ARMv8 MMU > code. I don't think that should be necessary (especially changing the > GRANULE_SIZE which is a complication I'd really like to avoid > having), and I'd like to understand what you're trying to do first. > Can you explain what memory ranges you need to map on your SoC and > why they need to be so large? > Hi Julius, the Cavium SoC expose the MMIO space at 1 << 47 with a size of 1 << 47. As coreboot does use PA=VA mapping, I have to extend the VA space to 48 bit and that seems to work fine with 64KB granule. The change in coreboot is minimal, I'm not sure if all armv8 CPUs support's that granule, but a Kconfig should do for now. I'd really want to avoid using a 4KB granule, as I'd have to implement either level0 page talbes, or use PA!=VA mappings. Regards, Patrick > Thanks, > Julius -- Patrick Rudolph 9elements GmbH, Kortumstraße 19-21, 44787 Bochum, Germany Email: patrick.rudolph(a)9elements.com Phone: +49 234 / 68 94 188 Sitz der Gesellschaft: Bochum Handelsregister: Amtsgericht Bochum, HRB 13207 Geschäftsführung: Eray Basar, Sebastian Deutsch

2 1

ARMv8 MMU changes
by Julius Werner 01 Mar '18

01 Mar '18

Hi Patrick et. al., Continuing from what you said on IRC, let's please discuss this before you spend time to work on any major changes to the ARMv8 MMU code. I don't think that should be necessary (especially changing the GRANULE_SIZE which is a complication I'd really like to avoid having), and I'd like to understand what you're trying to do first. Can you explain what memory ranges you need to map on your SoC and why they need to be so large? Thanks, Julius

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot March 2018