Re: [coreboot] Real name policy

[Gregg Levine]

Hello!
That's a great reason right there. Who knows how much they contributed
to the state of the art, and did not properly sign it. But in the end
while their world was collapsing around them, we knew who they were
via Groklaw.
-
Gregg C Levine gregg.drw...@gmail.com
"This signature fought the Time Wars, time and again."


On Mon, Mar 5, 2018 at 8:50 PM, David Hendricks
 wrote:
>
>
> On Mon, Mar 5, 2018 at 1:13 PM, taii...@gmx.com  wrote:
>>
>> I can't understand as to why doing a git commit requires your "real" name
>
>
> SCO.
>
> Ref: https://lkml.org/lkml/2004/5/23/10
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Real name policy

[David Hendricks]

On Mon, Mar 5, 2018 at 1:13 PM, taii...@gmx.com  wrote:

> I can't understand as to why doing a git commit requires your "real" name


SCO.

Ref: https://lkml.org/lkml/2004/5/23/10
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] ARM Veyron Speedy - Replacing 11.6 inch display for 15 inch

[Julius Werner]

I have access to the schematics for Speedy... I'm not allowed to share
them, but I'm happy to look up something specific for you if it helps.

Nico is right, only one of the four DP lanes coming out of the SoC is
routed to the connector. If your panel requires more than that, you're
probably SOL. Although I'm not even sure where they would go on that
connector... there's only 20 pins, and they all seem to be used already.
(I'm not really sure how standardized those connectors are, tbh... if you
buy a panel with a different pinout, obviously nothing will work and it
might even damage the panel and/or the mainboard.)

I also remember that RK3288 PLLs often had some issues with jitter (at
least they had for HDMI, not sure if it applies to DP). The code we
implemented (clock.c:pll_para_config) does whatever it can to meet the
pixel clock as exactly as possible, but maybe that wasn't actually the best
way to do it. In your case you end up with a very large input divisor (NR =
59), so you're essentially dividing the 24MHz oscillator down to 407KHz and
then multiplying it back up (thus amplifying noise). Maybe try hacking that
function to hardcode the result to NR = 1, NF = 23, NO = 4 (leading to VCO
= 552000KHz, output = 138000KHz) or NR = 4, NF = 91, NO = 4 (leading to VCO
= 546000KHz, output = 136500KHz) and see if that helps. (In fact, that
latter configuration is closer to the target frequency of 136620KHz than
the one you get... what you're seeing is sort of a freak accident resulting
from a compounding of rounding errors during the calculation. You're
welcome to try to fix the code if you want, but it's kinda difficult to get
all the different requirements right at once... for example, you'd have
less errors if it were calculating in Hz, but we went with KHz since we
were afraid it could overflow in some situations.)
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] ENE KB3940Q-A1 embedded controller custom firmware

[Youness Alaoui]

Thanks for the advice Mike, but I think you misunderstood the issue. I
wasn't talking about the internal memory of the EC, but rather about
accessing the EC firmware in SPI flash via an external SPI flasher.
The problem is that the SPI flash power rail is the same as the EC
chip, so as soon as we power the SPI flash to read it, it will also
power the EC chip, which will drive the SPI I/O pins high/low to read
its firmware, and since the EC executes the firmware from the flash,
that means that the SPI flash will constantly be accessed by the EC
and the external flasher can't take control of the I/O.
However, it looks like if the EC firmware crashes, it will stop using
the flash and will therefore 'release' the I/O pins for the external
flasher to use them.
If I short MISO with VCC, then the EC will read its firmware as being
all 0xFF (which is the same as when I corrupted the flash by erasing
its first sector), and that will cause it to crash and release the SPI
flash, then we can read it. No need to solder or enable debug mode or
anything like that.

Anyways, my true purpose is to use software flashing only, I already
have read/write/sector_erase support written but it requires the use
of the Index I/O (LPC port 0x380) which I can only access when I flash
the machine with the AMI BIOS, but which becomes inaccessible if I
only have coreboot. I think it's because AMI will send EC
vendor-specific commands via LPC port 62h/66h to configure it and
enable the Index I/O access. I've suggested to Paul if we could a
reduced firmware that would only log to UART all the accesses to the
EC via the LPC port 62/66 (kind of like doing SerialICE for the EC) so
we could document the vendor specific commands AMI uses to enable
Index I/O. Once we know that, we should be able to read/write to the
EC flash using software only.


On Mon, Mar 5, 2018 at 4:04 PM, Mike Banon  wrote:
>> otherwise, the EC prevents us from accessing it
> Maybe KB3940Q has the same protection as KB9012 : unless the EC's
> ground pin has been shortened with motherboard's ground _before_ you
> have powered a motherboard, you would not have any access; otherwise,
> EC will go into debug mode and you'll have the full access to its'
> internal memory. To avoid the soldering, you could look through the
> instructions described here -
> http://dangerousprototypes.com/docs/Flashing_KB9012_with_Bus_Pirate ;
> in short : use a keyboard flex cable to reach EC spi pins as well as
> its' ground, and a test hook clip to easily get a ground of your
> motherboard
>
> On Mon, Mar 5, 2018 at 11:00 PM, Youness Alaoui
>  wrote:
>> On Sun, Mar 4, 2018 at 4:50 AM, Paul Kocialkowski  wrote:
>>> Hi,
>>>
>>> Le vendredi 16 février 2018 à 14:09 -0500, Youness Alaoui a écrit :
 > > Sure, you can trust hardware flashing more than software flashing,
 > > but
 > > I really need software flashing. If it was just for me, yeah, I
 > > could
 > > fiddle with it to flash it by hardware for my personal needs, but
 > > when
 > > it's about deploying it to all our customer base, that's another
 > > story, the only solution is software flashing. Obviously, it would
 > > have to work in coreboot, so whatever coreboot is doing wrong (or
 > > AMI
 > > is doing right.. my guess is that it's probably something with the
 > > EC
 > > ACPI code), we'd have to figure that out first in order to get the
 > > read/write support.
 >
 > Either way, since the EC firmware resides in the SPI flash, it'll be
 > no
 > issue to reflash it both by software and hardware.

 On the librems, the EC firmware resides in a separate 64KB SPI flash,
 it's not shared with the bios, and I haven't found a way to access it.
>>>
>>> Is it really only 64 KiB? The chip definitely supports more and it seems
>>> a bit small to fit the whole firmware.
>>>
>>
>> Yes, it's a MX25L512. I can send you the firmwares that were on it if
>> you're curious (each machine revision had a different firmware, even
>> though it's the same ene chip in all of them, I don't know enough
>> about the EC to know if that's normal).
>>
>> The cool thing is that I was able to flash the chip externally, but
>> only when I corrupted the EC firmware (I erased the first page and the
>> laptop crashed before I finished re-programming it by software). I
>> reproduced it twice again, if the EC firmware has crashed, it stops
>> accessing the SPI flash and we can program it with an external
>> flasher, otherwise, the EC prevents us from accessing it. So I think
>> it might be possible to simply short the MOSI/MISO to VCC to cause the
>> firmware to be unreadable, so the EC doesn't boot, then we should be
>> able to read/write from the EC with a pomona clip.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Real name policy

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

One of the main reasons for this kind of requirement is to ensure that
the project stays in legal compliance, and that the provided code is in
fact licenseable.  Without a record of the real copyright holder of any
given part of the codebase, it is far more difficult know if the code
provided is tainted (think vendor employee stealing code and submitting
it for includsion).

Not knowing who contributed code also makes license enforcement
problematic, as it could be argued there is no known copyright holder.
This opens a whole new can of worms, as without the release of copyright
from the real holder the work defaults to All Rights Reserved status
under at least US law and I think the Berne convention as well.

On 03/05/2018 03:13 PM, taii...@gmx.com wrote:
> I can't understand as to why doing a git commit requires your "real"
> name and while I could simply make something up I instead I wish to
> protest this policy and hear out a justification for it.
> 
> This is a project with a main goal of improving security however having
> your name on the internet is almost always going to be bad security.
> 


- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJanbR3AAoJEK+E3vEXDOFbfYMH/3Qie1ip2fphBOzjRT/U3o5E
QDoQlGUx5Ajha/FL0vefSfUnTWCtVGL07mf6taUPSHTtr4VMzYBodRcElRi7OW20
FFg5pH3agJjHpDkd6KNZK7jirZCjRM4lbM8Vw+SeRcibKTAiQwJJr+MD+yWdJlJh
IitJsITfJRqw74DI8RZaohdYbCmMk26FxgQo5pKF2iiPTkfSBgSsL7+SJ1XvgeFb
4BhKvYbP2hRdMFcq003x/1Faw2q2JmgSnZTA8d+9jumOfkYBEjFDZElwX2JUR7kf
G4pxTH3IOKbpXeFh/Af6lt4aFNMcw9KoHhVAJjR4PFUIUUGqYkSw9cy6otB3FPM=
=wfuP
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] Real name policy

[taii...@gmx.com]

I can't understand as to why doing a git commit requires your "real" 
name and while I could simply make something up I instead I wish to 
protest this policy and hear out a justification for it.


This is a project with a main goal of improving security however having 
your name on the internet is almost always going to be bad security.


--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] ENE KB3940Q-A1 embedded controller custom firmware

[Mike Banon]

> otherwise, the EC prevents us from accessing it
Maybe KB3940Q has the same protection as KB9012 : unless the EC's
ground pin has been shortened with motherboard's ground _before_ you
have powered a motherboard, you would not have any access; otherwise,
EC will go into debug mode and you'll have the full access to its'
internal memory. To avoid the soldering, you could look through the
instructions described here -
http://dangerousprototypes.com/docs/Flashing_KB9012_with_Bus_Pirate ;
in short : use a keyboard flex cable to reach EC spi pins as well as
its' ground, and a test hook clip to easily get a ground of your
motherboard

On Mon, Mar 5, 2018 at 11:00 PM, Youness Alaoui
 wrote:
> On Sun, Mar 4, 2018 at 4:50 AM, Paul Kocialkowski  wrote:
>> Hi,
>>
>> Le vendredi 16 février 2018 à 14:09 -0500, Youness Alaoui a écrit :
>>> > > Sure, you can trust hardware flashing more than software flashing,
>>> > > but
>>> > > I really need software flashing. If it was just for me, yeah, I
>>> > > could
>>> > > fiddle with it to flash it by hardware for my personal needs, but
>>> > > when
>>> > > it's about deploying it to all our customer base, that's another
>>> > > story, the only solution is software flashing. Obviously, it would
>>> > > have to work in coreboot, so whatever coreboot is doing wrong (or
>>> > > AMI
>>> > > is doing right.. my guess is that it's probably something with the
>>> > > EC
>>> > > ACPI code), we'd have to figure that out first in order to get the
>>> > > read/write support.
>>> >
>>> > Either way, since the EC firmware resides in the SPI flash, it'll be
>>> > no
>>> > issue to reflash it both by software and hardware.
>>>
>>> On the librems, the EC firmware resides in a separate 64KB SPI flash,
>>> it's not shared with the bios, and I haven't found a way to access it.
>>
>> Is it really only 64 KiB? The chip definitely supports more and it seems
>> a bit small to fit the whole firmware.
>>
>
> Yes, it's a MX25L512. I can send you the firmwares that were on it if
> you're curious (each machine revision had a different firmware, even
> though it's the same ene chip in all of them, I don't know enough
> about the EC to know if that's normal).
>
> The cool thing is that I was able to flash the chip externally, but
> only when I corrupted the EC firmware (I erased the first page and the
> laptop crashed before I finished re-programming it by software). I
> reproduced it twice again, if the EC firmware has crashed, it stops
> accessing the SPI flash and we can program it with an external
> flasher, otherwise, the EC prevents us from accessing it. So I think
> it might be possible to simply short the MOSI/MISO to VCC to cause the
> firmware to be unreadable, so the EC doesn't boot, then we should be
> able to read/write from the EC with a pomona clip.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] ENE KB3940Q-A1 embedded controller custom firmware

[Youness Alaoui]

On Sun, Mar 4, 2018 at 4:50 AM, Paul Kocialkowski  wrote:
> Hi,
>
> Le vendredi 16 février 2018 à 14:09 -0500, Youness Alaoui a écrit :
>> > > Sure, you can trust hardware flashing more than software flashing,
>> > > but
>> > > I really need software flashing. If it was just for me, yeah, I
>> > > could
>> > > fiddle with it to flash it by hardware for my personal needs, but
>> > > when
>> > > it's about deploying it to all our customer base, that's another
>> > > story, the only solution is software flashing. Obviously, it would
>> > > have to work in coreboot, so whatever coreboot is doing wrong (or
>> > > AMI
>> > > is doing right.. my guess is that it's probably something with the
>> > > EC
>> > > ACPI code), we'd have to figure that out first in order to get the
>> > > read/write support.
>> >
>> > Either way, since the EC firmware resides in the SPI flash, it'll be
>> > no
>> > issue to reflash it both by software and hardware.
>>
>> On the librems, the EC firmware resides in a separate 64KB SPI flash,
>> it's not shared with the bios, and I haven't found a way to access it.
>
> Is it really only 64 KiB? The chip definitely supports more and it seems
> a bit small to fit the whole firmware.
>

Yes, it's a MX25L512. I can send you the firmwares that were on it if
you're curious (each machine revision had a different firmware, even
though it's the same ene chip in all of them, I don't know enough
about the EC to know if that's normal).

The cool thing is that I was able to flash the chip externally, but
only when I corrupted the EC firmware (I erased the first page and the
laptop crashed before I finished re-programming it by software). I
reproduced it twice again, if the EC firmware has crashed, it stops
accessing the SPI flash and we can program it with an external
flasher, otherwise, the EC prevents us from accessing it. So I think
it might be possible to simply short the MOSI/MISO to VCC to cause the
firmware to be unreadable, so the EC doesn't boot, then we should be
able to read/write from the EC with a pomona clip.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] $7 cheap FT232H board as EHCI debug dongle for coreboot - would it work?

[Kyösti Mälkki]

On Mon, Mar 5, 2018 at 6:13 PM, Mike Banon  wrote:
> Thank you for your results, Georg! Although this "adafruit board"
> costs twice more ( $15 ) and has a microUSB instead of a sturdy
> full-sized one, your report gives me more confidence in the success of
> the idea.

With the male-A type connector, FT PCB will end up hanging aside
the laptop with no designed mechanical flex. Bump it, and with bad
luck you break the female-A connector on the DUT PCB. To avoid it you
would need A-A extension cables. Overall, I would say setup is less
fragile with micro-USB.

Also that PCB is wider than the USB male-A connector, it will block
neighbouring connectors on a desktop boards' IO shield. Again, A-A
extension needed.

Kyösti

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] ARM Veyron Speedy - Replacing 11.6 inch display for 15 inch

[Nico Huber]

On 05.03.2018 12:02, Mark Wylde wrote:
> Thanks Nico for taking your valuable time to answer my questions. I
> really appreciate it, and knowing that it should be possible makes me
> feel better about continuing the project. 
> 
> I've ordered another display that has better matching specifications.
> I'll reply here to let others know if it works or not although I agree
> this is probably not a coreboot issue.
> 

Well that though might have come too hasty. There is some board specific
information that coreboot might miss, e.g. how many lanes are actually
implemented. If the original display needed only a single DP lane, maybe
they omitted the traces for the other lanes (in your log, coreboot tries
to train 2 lanes). And maybe there is more that I didn't consider.

A log of the successful training with the original display might give
more clues. In case you haven't tried yet, you can probably also let
Linux do the DP training. And last but not least, there is a edp_debug()
definition at the top of `soc/rockchip/common/edp.c`.

Nico

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] $7 cheap FT232H board as EHCI debug dongle for coreboot - would it work?

[Vadim Bendebury]

it's just  a list with an applied rs232 filter, DigiKey has tons of 3 pin
UART cables as well.

-vb

On Mon, Mar 5, 2018 at 8:22 AM, Nico Huber  wrote:

> On 05.03.2018 17:06, Vadim Bendebury wrote:
> > Did you consider one of these:
> >
> > https://www.digikey.com/products/en/cable-assemblies/
> smart-cables/468?k=ftdi+uart==ftdi+uart=
> 316=ffe001d4=0=0=1=25
> >
> > there are many options, it is important to match the cable's VDD to your
> > board's (1.8V vs 3.3V), the rest of the parameters is way less important.
>
> Wait, these are RS232 parts. Nobody was talking about RS232 here. What
> do you want to fry with them?
>
> Nico
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] $7 cheap FT232H board as EHCI debug dongle for coreboot - would it work?

[Nico Huber]

On 05.03.2018 17:06, Vadim Bendebury wrote:
> Did you consider one of these:
> 
> https://www.digikey.com/products/en/cable-assemblies/smart-cables/468?k=ftdi+uart==ftdi+uart=316=ffe001d4=0=0=1=25
> 
> there are many options, it is important to match the cable's VDD to your
> board's (1.8V vs 3.3V), the rest of the parameters is way less important.

Wait, these are RS232 parts. Nobody was talking about RS232 here. What
do you want to fry with them?

Nico

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] $7 cheap FT232H board as EHCI debug dongle for coreboot - would it work?

[Mike Banon]

> Not likely those PCBs have gone through much testing on assembly line, how 
> about 4...

From about 100-200 reviews for these cheap " aliexpress boards " so
far I've found just one negative that's quality related and not
shipping related ( FTDI chip was badly soldered ) - quite a low
failure rate. These boards are very simple and their failure rate
mostly depends on the failure rate of FTDI chips and their soldering
quality

> It writes just the same you get with cbmem -c utility, assuming you
can reach OS on the DUT.

Didn't know that, but its' too late ;)

Best regards,
Mike Banon

On Mon, Mar 5, 2018 at 1:36 PM, Kyösti Mälkki  wrote:
> On Mon, Mar 5, 2018 at 12:18 PM, Mike Banon  wrote:
>> 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 ;)
>>
>
> Not likely those PCBs have gone through much testing on assembly line,
> how about 4...
>
>> 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
>>
>
> It won't become a compatible replacement, as you would need to modify
> the (proprietary) software of both device-under-test and the host.
> FT232H could be made to work with linux kernel early_printk=dbgp but I
> don't think anyone has done that.
>
> FX2LP approach was able to mimic the net20dc USB descriptors,
> including the special response of debug feature and endpoint number
> assignment.
>
>> 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
>
> It writes just the same you get with cbmem -c utility, assuming you
> can reach OS on the DUT.
>
> Kyösti

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] $7 cheap FT232H board as EHCI debug dongle for coreboot - would it work?

[Mike Banon]

Thank you for your results, Georg! Although this "adafruit board"
costs twice more ( $15 ) and has a microUSB instead of a sturdy
full-sized one, your report gives me more confidence in the success of
the idea. Perhaps this information could be somehow included to the
coreboot wiki, especially to the EHCI Debug Port page -
https://www.coreboot.org/EHCI_Debug_Port - because I've learned about
FT232H just accidentally, it's not described anywhere at the wiki.
Huge thanks to both Kyosti and Nico for making this dongle possible

On Mon, Mar 5, 2018 at 2:15 PM, Georg Wicherski  wrote:
> On 03/05/2018 11:36 AM, Kyösti Mälkki wrote:
>> Not likely those PCBs have gone through much testing on assembly line,
>> how about 4...
>
> Have a couple of these:  and none
> of them failed me thus far. Also using them successfully for Coreboot
> early debugging, thanks to Kyösti's help!
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] $7 cheap FT232H board as EHCI debug dongle for coreboot - would it work?

[Mike Banon]

These digikey cables do not explicitly mention that they have FT232H
chip, also they cost $23.5 minimum while aliexpress board costs $7 -
3x times less expensive

On Mon, Mar 5, 2018 at 7:06 PM, Vadim Bendebury  wrote:
> Did you consider one of these:
>
> https://www.digikey.com/products/en/cable-assemblies/smart-cables/468?k=ftdi+uart==ftdi+uart=316=ffe001d4=0=0=1=25
>
> there are many options, it is important to match the cable's VDD to your
> board's (1.8V vs 3.3V), the rest of the parameters is way less important.
>
> -vb
>
>
> On Sat, Mar 3, 2018 at 5:27 AM, Mike Banon  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
>>
>> 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-USB-to-JTAG-UART-FIFO-SPI-I2C-Module/32818305310.html
>>
>> 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
>>
>> --
>> coreboot mailing list: coreboot@coreboot.org
>> https://mail.coreboot.org/mailman/listinfo/coreboot
>
>

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] $7 cheap FT232H board as EHCI debug dongle for coreboot - would it work?

[Vadim Bendebury]

Did you consider one of these:

https://www.digikey.com/products/en/cable-assemblies/smart-cables/468?k=ftdi+uart==ftdi+uart=316=ffe001d4=0=0=1=25

there are many options, it is important to match the cable's VDD to your
board's (1.8V vs 3.3V), the rest of the parameters is way less important.

-vb


On Sat, Mar 3, 2018 at 5:27 AM, Mike Banon  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
>
> 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-USB-to-JTAG-UART-FIFO-SPI-I2C-
> Module/32818305310.html
>
> 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
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] AMD Geode LX800

[Wolfgang Kamp - datakamp]

Hi,

I know the AMD Geode LX is a very old platform but still active.
When SeaBIOS looks for a PCI VGA device to run a Video-BIOS option ROM (AMD), 
it looks for i/o and memory enabled in PCI command register.
But it finds only memory enabled and i/o disabled. So the option ROM will never 
be executed.
Could anyone help with an idea to find the problem in coreboot  nothbridge LX 
PCI initialization?

Best regards,

Wolfgang Kamp
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] $7 cheap FT232H board as EHCI debug dongle for coreboot - would it work?

[Georg Wicherski]

On 03/05/2018 11:36 AM, Kyösti Mälkki wrote:
> Not likely those PCBs have gone through much testing on assembly line,
> how about 4...

Have a couple of these:  and none
of them failed me thus far. Also using them successfully for Coreboot
early debugging, thanks to Kyösti's help!

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] ARM Veyron Speedy - Replacing 11.6 inch display for 15 inch

[Mark Wylde]

Thanks Nico for taking your valuable time to answer my questions. I really 
appreciate it, and knowing that it should be possible makes me feel better 
about continuing the project. 

I've ordered another display that has better matching specifications. I'll 
reply here to let others know if it works or not although I agree this is 
probably not a coreboot issue.

‐‐‐ Original Message ‐‐‐

On March 4, 2018 2:10 PM, Nico Huber  wrote:

> ​​
> 
> Hello Mark,
> 
> On 04.03.2018 11:45, Mark Wylde wrote:
> 
> > 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:
> 
> snip
> 
> > 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
> > 
> > 
> > -
> 
> This is the DP training sequence. DP has two communication channels to
> 
> the display, 1. up to 4 data lanes for the picture data operating at GHz
> 
> rates that have to be trained, 2. an AUX channel operating at MHz speed
> 
> that is supposed to just work (it does here).
> 
> Basically, your display keeps telling through the AUX channel "I can't
> 
> hear you, speak louder!". Until the highest voltage is reached.
> 
> > 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.
> 
> The 3.3V are the power supply voltage for the display. This is (usually)
> 
> not configurable, but if it were, then likely not from coreboot but the
> 
> EC. You should make sure that the electrical characteristics (4.3.1 in
> 
> that datasheet) match those of the old display. If they don't, all bets
> 
> are off.
> 
> > 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.
> 
> This, however, is about the i/o voltage for the data lanes, and unre-
> 
> lated to the 3.3V.
> 
> > \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
> >  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?
> 
> It's the maximum specified for DP.
> 
> > 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?
> 
> Your problem has nothing to do with coreboot, I guess. Though, that log
> 
> is useful for debugging of course. If the electrical characteristics
> 
> match those of the old display (i.e. we can expect that the new display
> 
> is generally operational), it might be a signal integrity problem, or
> 
> something is not connected correctly at all...
> 
> The C201 generally shouldn't care about the size or the resolution of
> 
> the display. At the eDP 

Re: [coreboot] $7 cheap FT232H board as EHCI debug dongle for coreboot - would it work?

[Kyösti Mälkki]

On Mon, Mar 5, 2018 at 12:18 PM, Mike Banon  wrote:
> 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 ;)
>

Not likely those PCBs have gone through much testing on assembly line,
how about 4...

> 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
>

It won't become a compatible replacement, as you would need to modify
the (proprietary) software of both device-under-test and the host.
FT232H could be made to work with linux kernel early_printk=dbgp but I
don't think anyone has done that.

FX2LP approach was able to mimic the net20dc USB descriptors,
including the special response of debug feature and endpoint number
assignment.

> 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

It writes just the same you get with cbmem -c utility, assuming you
can reach OS on the DUT.

Kyösti

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] $7 cheap FT232H board as EHCI debug dongle for coreboot - would it work?

[Mike Banon]

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  wrote:
> Hi Mike
>
> On Sat, Mar 3, 2018 at 3:27 PM, Mike Banon  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-USB-to-JTAG-UART-FIFO-SPI-I2C-Module/32818305310.html
>>
>> 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, 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

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot