Re: [coreboot] SPI controller and Lock bits

[Youness Alaoui]

On Wed, Oct 17, 2018 at 9:42 AM R S  wrote:
>
> Yes, thanks Youness for all the hard work and research. You provided an 
> exceptional service. I enjoyed your rants and explanations both on Purism's 
> blog and here. Hopefully Purism can fill that void you are leaving behind.
>
Thanks! I had a lot of fun, and this community is really great! I hope
we still get to work together again in the future and cross paths!

> On Tue, Oct 16, 2018 at 7:45 PM Sam Kuper  wrote:
>>
>> Hi Youness,
>>
>> On 15/10/2018, Youness Alaoui  wrote:
>> > One thing to note is that this week will be my last week at Purism as
>> > I'm going on sabbatical for a few months, and I may or may not (most
>> > likely won't) come back to Purism in a few months.
>>
>> Thank you for your efforts to make Coreboot work on the Librems, and
>> for the enthusiasm you displayed here in the mailing list and on the
>> Purism blog.
>>
>> Although I might have sounded critical on occasion, this was never
>> personal; it was always out of a concern to avoid missing
>> opportunities to achieve the most secure and privacy-protecting
>> machines available within the constraints of the hardware and the
>> business model. I.e. my "criticisms" were always intended to be
>> constructive. I hope that they did not form any part of your decision
>> to take a break from Purism, and if they did, I apologise.
>>
>> I wish you a good sabbatical, in any case.
>>
Thanks!
I understand that the criticism was never personal, and I think you
all were justified in being critical as well, but then things started
to change for the better in purism and it took time for people here
(understandably) to see that the change was not just smoke and
mirrors. I hope that with me gone, they'll find a good replacement and
they'll continue working with the coreboot community and keep moving
forward, instead of backward.
No, you or anyone else's criticism here had zero part in my decision
to leave. On the contrary, I really enjoyed working with the coreboot
community, you're all very welcoming, so thanks for that! I'm leaving
because I'm feeling close to a burnout, and I don't want to get stuck
in one, so I dropped both Purism and a second client I had, in order
to concentrate on my health and well being. The reason I might not be
coming back to Purism in the future is because they have a new
contract for employees/contractors which I disagree with and I'm not
ready to sign. It's still a draft though so if the feedback is taken
into consideration and lawyers don't reject the feedback and the final
version of the contract is acceptable to me, then I might come back.
We'll see what happens! :)



>>
>> > @Sam
>> > for 90% of the users, they would either :
>> > - never [flash the ROM]
>> > - only do it when a new update is released and interests them, i.e:
>> > once or twice a year.
>> > So [...] it would be far
>> > from annoying to users since most won't care or notice that all that
>> > is needed, and if they do, they won't care to have to do it so rarely.
>>
>> I fear that even performed rarely, it might be beyond some users'
>> abilities. But...
>>
Yeah, it might make someone not update if they realize they need to do
that, but I guess if they'd only need to do it in order to break the
root of trust and overwrite the bootblock or whatever, then that might
be good. Either way, it's better than having the WP# hard wired to VCC
as it is right now.

>> > It will however, especially with cover-opening protections (either
>> > using glitter/whatever methods on screws to notice if they'd been
>> > opened, or with an EC handling a cover switch notification), that
>> > could be very helpful to increase their security.
>>
>> ... I agree that making it tamper-evident is indeed potentially valuable.
>>
>>
>> >> Your assumption fails against a BadHeads attack.
>> > Yes indeed, I wrote a proof of concept which was a Heads that would
>> > extend PCRs with the same values that coreboot did (and have a
>> > coreboot with measured boot disabled) and it passed the TOTP
>> > authentication.
>>
>> Many thanks for confirming this to the mailing list. I was hoping to
>> write and somehow disseminate (e.g. to the Heads developers) a POC
>> myself, but I'm glad to be spared that need.
>>
>> If you could send your POC to the Heads team for integration into the
>> test suite, that would be great. This flaw in Heads needs to be fixed
>> (if it hasn't already been). Having the POC in the test suite would
>> also help to detect future regressions, once the issue is fixed (if it
>> *

Re: [coreboot] SPI controller and Lock bits

[Youness Alaoui]

Hi Everyone!

Sorry for the 2 weeks late reply, I've read your responses, but I've
been too busy and dealing with stuff and haven't had/taken the time to
reply but your input was very much appreciated and not ignored!
One thing to note is that this week will be my last week at Purism as
I'm going on sabbatical for a few months, and I may or may not (most
likely won't) come back to Purism in a few months. So this feature
will probably be my last coreboot contribution (for a while at least).

I'm going to try and reply quickly to some of the comments.
@Sam

> This seems to imply that each time a Librem user wants to internally
flash the ROM, she would have to:

Yes, updating the flash would be a relatively complicated process
which is ok, because for me and you, sure, we'd update the rom a few
times a day/week, but for 90% of the users, they would either :
- never do it
- only do it when a new update is released and interests them, i.e:
once or twice a year.
So it's a complicated process (as you've outlined) but it would be far
from annoying to users since most won't care or notice that all that
is needed, and if they do, they won't care to have to do it so rarely.
It will however, especially with cover-opening protections (either
using glitter/whatever methods on screws to notice if they'd been
opened, or with an EC handling a cover switch notification), that
could be very helpful to increase their security.

> Your assumption fails against a BadHeads attack.
Yes indeed, I wrote a proof of concept which was a Heads that would
extend PCRs with the same values that coreboot did (and have a
coreboot with measured boot disabled) and it passed the TOTP
authentication. That's something that other possible solutions would
try to mitigate (such as vboot I think).


 @Nico:
> You two might have different kinds of updates in mind. You don't need
a switch for every update.
Well, I hadn't thought this through to be honest, but in theory you
could still flash early in the boot process (in heads) if the
protection bits aren't set on the flash. So using the jumper might
only allow flashing within the OS itself. Or maybe if the bootblock
locks its own region, maybe setting the jumpre would allow the user to
flash a new root of trust only.
I suppose that's where vboot comes through, and I've left Kyle to
investigate all that (though he says we don't need it, but I'm
starting to think he's wrong and I think he could be convinced easily
enough, I'll point him to this thread which should do the trick).
Anyways, I'm leaving Purism now and going on vacation so I'm not going
to bother trying to wrap my head around all that.

FYI: What I'm trying to do is to improve the security for current
machines, so the discussion on the jumper/etc.. is irrelevant for
machines already in the hands of customers.

@ Sam :
>Youness and others at Purism: it would be great if Purism could be
> sure not only to spec, but also to list on the Librem specification
> pages on the website, a SPI flash ROM chip that *does* obey its
> write-protect pin regardless of firmware. Thanks :)
I didn't realize that "some chips don't obey the write-protect pin",
but rather my understanding is that the write protect pin is there to
say "the protected blocks are protected/not-protected according to
hardware.
The SPI flash (according to the datasheets I've read) can protect
regions either with "don't protect" or "protected by WP#" or
"protected until power-cycle".
The status register bits can be written to either as volatile or
non-volatile (for non volatile, you need another command iirc, and you
can't do it with hardware sequencing, same for the 'protect until
power cycle', which also needs to write to status-register-2 which
can't be done with hardware sequencing either).
So, really, a flash rom chip does obey its WP pin, it just depends on
how it's set.

On Fri, Oct 5, 2018 at 6:14 AM Nico Huber  wrote:
>
> Hi,
>
> Am 05.10.18 um 08:39 schrieb Martin Kepplinger:
> > is there already a gerrit change you are working on this? Do plan to
> > support / test
> > a X230 flash chip's lock bits?
> > * MX25L6406E/MX25L6408E
> > * EN25QH64
> > * MX25L3206E
>
> not about this request in particular but such flash-chip features in
> general: IMO, the best solution is to implement these in (lib)flashrom
> and integrate that into coreboot. I wouldn't say that it's wasted time
> to implement it in coreboot directly. But, in the long run, taking
> shortcuts or maintaining redundant implementations will slow the pro-
> ject down overall.
>
> Nico
> --
> 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] SPI controller and Lock bits

[Youness Alaoui]

On Sat, Sep 29, 2018 at 12:21 PM Nico Huber  wrote:
>
> On 9/27/18 10:29 PM, Youness Alaoui wrote:
> > Thanks everyone for the responses.
> > So far my understanding on the task at hand is :
> > - Add a CONFIG to decide if we set FLOCKDN or not (and one to decide
> > if we lock it on the resume path?)
>
> Maybe no config at all, see discussion of PRR34_LOCKDN below. But if,
> then only one config, IMO: On the resume path FLOCKDN should always be
> set.
>
> > - Remove the chipset_lockdown devicetree config and change the code to
> > always assume it's LOCKDOWN_COREBOOT (this applies to all platforms,
> > right?)
>
> Yes, unless somebody objects. Please make sure to add the right
> reviewers to this patch. I expect some resistance.
>
Ok, this is already done, but I want to finish/test my work before I
send for review and I might not have time until the end of the week.

> > - remove the call to fast_spi_pr_dlock() and fix the comment above
> > that function to be more accurate
>
> Please also check the tree for code that sets PRRs. IIRC, it is used
> somewhere to protect the MRC cache. I would set the discrete lock
> directly after writing the region.
>
Ok, thanks, will do.
Note: I've also changed the fast_spi_pr_dlock() function to take 5 u8
arguments to allow the caller to lock each prr individually instead of
being an all or nothing.

> > - Add .config CONFIG options or maybe optional devicetree configs for
> > how to setup the registers so coreboot can prepare them (due to the
> > resume path) ?
>
> Hmm, I would add Kconfig options for this as well. I you want to match
> the configuration of your payload, it definitely doesn't belong into the
> devicetree. Note that "prepare" also implies to lock them on the resume
> path.
>
Yeah, so far, the KConfigs I added are :
FAST_SPI_LOCK_REGISTERS
FAST_SPI_LOCK_REGISTERS_ON_RESUME
FAST_SPI_LOCK_PRR34_REGISTERS
FAST_SPI_LOCK_PRR34_REGISTERS_ON_RESUME
FAST_SPI_PRR3_REGISTER (hex value)
FAST_SPI_PRR4_REGISTER (hex value)

This way, a user can lock/unlock the register (since it affects more
than just the PRRs) and they can override/set the PRR3 and PRR4 values
and decide whether to lock them or not or only on resume, etc.. I
think those should be enough for most use cases and it's enough for
what I need.

> >> AIUI, FLOCKDN always locks the PRRs.
> > Actually from what I can see, the FLOCKDN will lock a few registers,
> > among which it will lock the "discrete PR locks" register, and it will
> > lock the PR 0, 1 and 2, but there's also a PRR34_LOCKDN bit to
> > separately lock the PRR 3 and 4. So technically, I could leave FLOCKDN
> > set, and in the payload, just set protected range in PRR3 or PRR4,
> > then set the PRR34_LOCKDN. Unfortunately, I can't do that because the
> > PRR3 and 4 were already locked with the discrete lock register (if I
> > remove the call to fast_spi_pr_dlock(), it should be fine for my needs
> > though I think, since you said swseq would also fail for protected
> > ranges).
>
> Ah, that PRR34_LOCKDN was only introduced with SKL. Didn't know it or
> at least didn't remember it. In this case it seems best to always set
> FLOCKDN in coreboot. The payload can then still protect additional
> regions with PRR3/4. On the resume path, coreboot would set both FLOCKDN
> and PRR34_LOCKDN, right?

On resume, even if coreboot sets them, the PRRs need to be filled,
which is why I also added the hex value of the PRR in the KConfig.
I also want to keep FLOCKDN unlocked, so Heads can set the write
protect bits in the flash then prevent writing to the status register
via hwseq before locking it with FLOCKDN.

>
> >> Also note that swseq is not an option anymore since Skylake (IIRC, the
> >> ME protects the flash-cycle go bit in its default configuration). With
> >> only hwseq, you can only access the flash chip's first status register
> >> which makes many security features unusable. So we have to rely on the
> >> protected regions :-/ I hope Intel is going to fix that for future plat-
> >> forms (or with an ME update if that could add more hwseq commands).
> >
> > Well, I saw the opmenu/optypes/etc.. registers still being set in
> > skylake (their offsets were not in the datasheet though), so I figured
> > swseq is still there, just undocumented. It might work on systems
> > where the ME is disabled. I'd have to test. I was thinking of using
> > swseq and add the write-register-2 opcode and use it to set SPR1 and
> > lock the entire flash until it gets power cycled. I don't know if that
> > would work during suspend, but if it does, it might help with the
> > resume path at least (but would prevent up

Re: [coreboot] SPI controller and Lock bits

[Youness Alaoui]

Oh boy, lots of emails to answer! So first, thanks for everyone who
shared their input, I very much appreciate it.

> I think you can decide what hardware your products include, right? I
meant dedicated hardware on the mainboard.

Yes, but I'm currently looking for a solution to existing hardware,
not for the next laptop Purism produces. And by 'dedicated hardware' I
thought you meant only allow users to update their BIOS using an
external SPI flasher, which would be impractical of course.

> >
> > It's not just the part. A single simple part like that has all kinds of
> > follow-on effects that are not obvious unless you've been at a company
> > which designs and builds consumer electronics.
>
> Thank you for the perspective. I do understand that changing one
> component can affect others.
>
> Purism isn't a typical laptop company. The addition of hardware
> switches, to control webcam, mic and Wi-Fi, is one of the USPs for
> their Librem models. These undoubtedly had knock-on effects for the
> BOM. Purism was undeterred by that. In that context...
>
> I'm just asking for one more switch.
>
> So, Youness and others at Purism: if you are reading this, please do
> spec a momentary switch to control flashing on future Librems. Your
> security-conscious users will thank you for it.

Yes, I already suggested it for the next iteration. It wouldn't be a
switch though, but rather a low profile 90-degrees jumper on the
motherboard.
As for your question earlier about someone forgetting it. I would
assume that it would be easy to have the Heads menu show a big warning
to the user if it's left unprotected (I assume there would be a way to
detect if WP# is 1/0 through a GPIO (or other method) without being
able to use that GPIO to override the WP# value).
Right now, if you boot into linux while ignoring tampering, you get
your ttys in red, as a huge and very visible warning.
Also, yes Sam, you did understand me perfectly, thanks!


>
> --
> 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] SPI controller and Lock bits

[Youness Alaoui]

On Thu, Sep 27, 2018 at 10:18 PM Sam Kuper  wrote:
>
> On 28/09/2018, Peter Stuge  wrote:
> > Youness Alaoui wrote:
> >> avoid any malware writing to the flash
> >
> > Just disallow flash writes by the platform. Allow flash writes only
> > by dedicated hardware (maybe ChromeEC?) which implements a simple and
> > efficient security protocol.
>
> Relevant URL: 
> https://www.chromium.org/chromium-os/ec-development#TOC-Write-Protect

We don't have/use ChromeEC and I think that telling every user that
they'd need dedicated hardware to update their BIOS makes no sense.

>
>
> > Looking for a software solution is IMO like Intel trying to secure SMM.
>
> Hear, hear!
>

I don't see why that would be true, the software solution is pretty
simple. You boot, you can write to the flash in a secure environment,
once you decide you don't need to write to the flash, you lock it
until your next reboot.


> This is a pretty useful feature, and it would be nice if it weren't tied to 
> heads (or any payload for that matter). What about tianocore's capsule update 
> mechanism, as well as stuff like fwupd ? Any way to have something like a 
> common solution ?

Tianocore is a payload, so tianocore's update mechanism is still about
doing the update in the payload.. All heads is going to do is to run a
script that calls flashrom (and actually use cbfstool to
extract/inject the heads-specific cbfs files into the new image, such
as the user's pgp keys for example, before flashing).. so it will have
to be tied to heads either way.
Heads is the one booting into your OS, so it can read-only lock the
entire flash before the user (real or malicious) gets control. The use
of heads is already tied in with the use a gpg key (nitrokey, yubikey,
librem key), and you'd already need to have the key inserted (and pin
valid) before it would give you access to a recovery shell, and the
same can be done before it allows the flash to be updated.
I hadn't thought of the use case of fwupd (which we're currently
adding support for) since it wouldn't be able to flash from the OS,
but I think that having the update file deosited in /boot under a
specific filename and rebooting would be all that fwupd would need to
do, then on the next boot, heads would find the file and suggest to
the user to flash it.

> --
> 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] SPI controller and Lock bits

[Youness Alaoui]

Thanks everyone for the responses.
So far my understanding on the task at hand is :
- Add a CONFIG to decide if we set FLOCKDN or not (and one to decide
if we lock it on the resume path?)
- Remove the chipset_lockdown devicetree config and change the code to
always assume it's LOCKDOWN_COREBOOT (this applies to all platforms,
right?)
- remove the call to fast_spi_pr_dlock() and fix the comment above
that function to be more accurate
- Add .config CONFIG options or maybe optional devicetree configs for
how to setup the registers so coreboot can prepare them (due to the
resume path) ?

Can you please confirm the ones with question marks? Is there some
rule on "add as little CONFIG options as possible" ?

> AIUI, FLOCKDN always locks the PRRs.
Actually from what I can see, the FLOCKDN will lock a few registers,
among which it will lock the "discrete PR locks" register, and it will
lock the PR 0, 1 and 2, but there's also a PRR34_LOCKDN bit to
separately lock the PRR 3 and 4. So technically, I could leave FLOCKDN
set, and in the payload, just set protected range in PRR3 or PRR4,
then set the PRR34_LOCKDN. Unfortunately, I can't do that because the
PRR3 and 4 were already locked with the discrete lock register (if I
remove the call to fast_spi_pr_dlock(), it should be fine for my needs
though I think, since you said swseq would also fail for protected
ranges).

On Thu, Sep 27, 2018 at 1:09 PM Dhaval Sharma  wrote:
>
> "but once you boot an OS, Heads would first lock the flash so it can't be 
> written to'. Is this some kind of a OS driver? The typical usage of all 
> locking register which are write once is to have them locked up within BIOS 
> itself which is within the most trusted boundary. Best we could do it push 
> out the locking part to the latest stages but not completely out IMHO.

The problem is we want to allow users to update their flash and
coreboot doesn't have a "flash update utility" integrated, so it has
to happen in the payload, which is why coreboot needs to not lock
anything then let the payload do the locking for us instead. Heads is
the linux-based payload we're using, and the idea is that Heads would
lock the flash before it actually boots any OS (from HDD or from USB),
this way you can only update your flash from within Heads itself and
Heads will ensure that the image you're trying to flash is properly
signed, or that you authenticate first before it would allow you to do
that (prevents someone from booting into a live USB and flash a
malicious bios).

> You can have write opcodes in the menu, they won't work on protected regions. 
> But if you have
> a partially protected flash (e.g. vboot), they are still useful.
Ok, that's interesting. I was actually thinking of just completely
disabling writing to any region, but maybe I can use the PRR instead.

> Also note that swseq is not an option anymore since Skylake (IIRC, the
> ME protects the flash-cycle go bit in its default configuration). With
> only hwseq, you can only access the flash chip's first status register
> which makes many security features unusable. So we have to rely on the
> protected regions :-/ I hope Intel is going to fix that for future plat-
> forms (or with an ME update if that could add more hwseq commands).

Well, I saw the opmenu/optypes/etc.. registers still being set in
skylake (their offsets were not in the datasheet though), so I figured
swseq is still there, just undocumented. It might work on systems
where the ME is disabled. I'd have to test. I was thinking of using
swseq and add the write-register-2 opcode and use it to set SPR1 and
lock the entire flash until it gets power cycled. I don't know if that
would work during suspend, but if it does, it might help with the
resume path at least (but would prevent updating flash after a reboot
and would force user to shut down and boot). I guess I have some
trial-error to do.
Actually, if status register remains the same through a
reboot/suspend/resume, and swseq doesn't work on skylake at all, I
could just set the protect bits and prevent writing to status register
on resume path.

> One way would be to let coreboot decide, e.g. prepare the configuration
> and don't lock it, and let the payload lock. The payload could validate
> this configuration before locking (and issue a warning if coreboot
> didn't set the expected bits).

Thanks, that's a good idea, I forgot about the suspend/resume case.
This implies I need coreboot to know about what config the payload
will want to set. I'm not sure if that should go into a CONFIG or a
devicetree config. Since it might be user-configured, it makes more
sense for it to go into .config, right ?

Thanks again,
Youness.

>
>
> On Thu, Sep 27, 2018 at 9:55 PM Lance Zhao  wrote:
>>
>> Okay, then I believe we should leave the decision on CONFIG instead of force 
>> lockdown blindly. As of now, that's still optional I believe.
>>
>>
>> On Thu, Sep 27, 2018 at 3:49 AM Nico Huber  wrote:
>>>
>>> Am 26.09.18 um 22:26 schrieb Lance 

[coreboot] SPI controller and Lock bits

[Youness Alaoui]

Hi,

I'm trying to add a way to lock the SPI flash to be read-only via
software *after* coreboot boots. The scenario is basically with using
Heads, you could authenticate to it (with a yubikey/nitrokey/librem
key) then be able to flash a new rom (update your BIOS), but once you
boot an OS, Heads would first lock the flash so it can't be written
to.
This should add some security to avoid any malware writing to the
flash, or someone booting into a USB stick and using that to flash a
malicious BIOS, but still gives the user the freedom of updating their
flash whenever they want to.

The problem is that I can't make the flash read-only because the SPI
interface is already locked down by coreboot (see
src/soc/intel/skylake/lockdown.c and
src/soc/intel/common/block/fast_spi/fast_spi.c).

There's a couple of things happening here :
First, the FLOCKDN bit is set which prevents us from enabling the
write protection. the BIOS Interface lock down is controlled by the
chipset_lockdown config variable, but the FLOCKDN is not behind a
config variable.
The second thing is that if I wanted to use the protected ranges
feature to lock specific regions, they are all getting locked using
the discrete lock register even while being unused. The locking of the
protected ranges was added in this change :
https://review.coreboot.org/c/coreboot/+/21064 and it passed without
notice among the move that the commit was supposed to do.

The commit states that the lockdown is meant to "support platform
security guidelines", but I think that this is not actually good
because coreboot leaves everything read-write and locks down the
registers so we can't make it read-only. I think that the security
guidelines would say to disable the write protection before locking
the registers down.

Either way, I'm going to need to add a way to make this configurable,
so my main questions here are :
- Should I create a new config variable to decide on whether or not to
lock the spi registers and another one to decide on whether or not to
lock the protected ranges ?
- Should I make the chipset_lockdown (currently used for locking the
BIOS CNTL register from LPC and SPI controllers) into an OR-ed flags
variable where we can say : chipset_lockdown = LOCKDOWN_COREBOOT |
LOCKDOWN_SPI | LOCKDOWN_PROTECTED_RANGES ?
- Should I make a single new config variable to decide what to
lockdown (LPC_BIOS, SPI_BIOS, SPI_BAR, SPI_PROTECTED_RANGES) and only
set them if the CHIPSET_LOCKDOWN_COREBOOT is set ? And if
chipset_lockdown is set to CHIPSET_LOCKDOWN_FSP not lockdown anything
at all ?
- Do we want to keep the protected ranges locked down at all, have
them configurable or completely remove that as I don't see the point
in using the discrete lock register ?

Once I see a consensus on what's the best way to move forward, I'll
implement it and push it for review.

Note: I think these only affect hardware sequencing though so I assume
someone could always use software sequencing to do the writes. As long
as the FLOCKDN bit isn't set though, I could remove all write-related
opcodes from the software sequencing register, which would also
prevent someone using swseq to do writes.

Thanks,
Youness.

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

Re: [coreboot] T450S + Coreboot

[Youness Alaoui]

On Sat, Sep 8, 2018 at 2:31 PM Peter Stuge  wrote:
>
> Youness Alaoui wrote:
> > So, back to the ME, we know exactly what it does, it's all extremely
> > well documented and explained
>
> I disagree with this.
>
> It is absolutely true that *some* of what the ME does is extremely well
> documented and explained by the vendor, web services APIs and all, but
> I would argue that in fact *most* of what the ME does is *not* documented
> by the vendor, nor by independent research.
>
I mostly agree, I was referring to Mike's talk about the remote
control features, so yes, I should have said "AMT is well documented",
but yes, there are huge portions of what the ME itself does (such as
the power on sequence, or what/how it sets some registers) which are
totally undocumented.
So yes, even if we don't know exactly what the ME does during the
power sequence (among other things), we still know that "it
initializes hardware", we just don't know how it achieves that task.
So we know "what it does", but we don't know "exactly what it does"
and we don't know "how it does it", which is where I was wrong in my
previous statement.

However, we need to differentiate between "this ME is something
obscure that we have no idea what it's for" versus "we know what this
ME thing is supposed to be for or what it's supposed to be doing, we
just have no way to be sure that it doesn't do anything else or that
it does what it's supposed to".
I disagree with the idea that the ME is this black box, this sort of
"hidden spy device" that gives full remote capabilities to some
unknown entity in the same way that I would disagree that because MS
Windows is closed source that any Windows machine is fully
remote-controlled by M$ employees at any time or that the OS is
commissioned by the CIA or whatever. I do agree that because it's
closed source, we can't know whether it is or not, but it's just not a
guarantee that it is.


> Since the ME is colocated with the x86 VM host, has access to all x86 VM
> memory *and* is a proprietary machine or subsystem I actually don't
> believe that we will ever "know exactly what it does".
>
Well, we could know, if we reverse engineer its code from the maskrom
to the BUP, but yes, it would be very hard to fully know for certain.
Besides, I'd assume that anything malicious would probably be written
in silicon rather than in reverse-engineerable code. So I'd apply the
same idea to the whole PCH/CPU. The major problem with the ME when
compared to my previous comparison with MS Windows is that we can
chose Linux instead of Windows, but we can't choose to disable or to
use a custom ME firmware (i.e: the not-user-controlled issue).

>
> > Now the problem is that it's closed source, and not user controlled
>
> Right.
>
>
> //Peter
>
> --
> 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] T450S + Coreboot

[Youness Alaoui]

 remote management purposes, perhaps there are
> infinite possibilities of what you could do with this core. So it
> could be turned into the competitive advantage which will be valid
> even from a paranoid point of view. It will be really nice to see it
> happen. But it didn't happen yet - and I am worried that Intel's
> hostile actions might prevent the completion of your benevolent
> research or at least prevent it from going public. Because I remember
> how they took down your "FSP Reverse Engineering" articles as well as
> the source code associated with it. What will prevent them from doing
> it again? And if they can't DMCA your work because the reverse
> engineering is legal at many countries including USA, they could just
> threaten to stop supplying Librem laptops with their CPUs (like they
> probably did) and it's all over now.
Even if I do finish this, the ME wouldn't be "open" because there
would still be code executing from the ROM all the way to the moment
the exploit happens, so it's not a magical solution, but it is better
than nothing and it would give us user-control of the CPU. Also, Intel
didn't "take down" my article, and it had nothing to do with the DMCA
or whatever. It was not a cease letter, it was not an Intel
lawyer contacting us, or anything of the sort. It was a software
manager who sent a nice and respectful email, asking us to remove the
article because the license of the FSP prevents reverse engineering. I
believe we are in the right, and there are plenty of responses we
could have given, but I think it was better to simply remove it
instead of fighting it, no harm done.

>
> Actually it might be a good idea for Purism to at least consider the
> switch to AMD Ryzen CPUs. Yes, unlike the 15h/early16h gen AMD CPUs,
> their new Ryzen CPUs contain the PSP, Platform Security Processor -
> which is also a management engine. But it is significantly younger
> than Intel ME (Skylake's ME is already generation 11), so PSP should
> have less sophisticated protections and it should be easier to
> "jailbreak" this "young PSP" rather than "modern ME". Early ME
> implementations were also weak, after all, and I expect "young PSP" to
> be weak also. Also, those AMD CPUs do not suffer from the
> recently-discovered Intel-specific vulnerabilities and their
> performance-degrading patches will not be required. Finally, AMD had a
> good collaboration history with coreboot (although this collaboration
> is not active currently, it might be renewed if there will be enough
> mutual interest) - and I believe AMD at least will not be as hostile
> towards your opensource/reverse-engineering efforts as Intel is
> currently. If any of these statements seems reasonable to you, please
> think of trying to make your Purism company to at least consider this
> AMD switch.
>
That's a very weak argument. The PSP isn't "less sophisticated" than
the ME because it's younger.. that's just not how software works.
Maybe the PSP is smaller/simpler, and therefore less likely to have
bugs that can be exploited, maybe the QA team at AMD is better than
the one at Intel, or that they have additional tests/steps in their
validation. As for "I believe AMD at least will not be as hostile"..
why do you believe that? what makes you believe that? why would you
suggest AMD, a corporation, would be less likely to try and defend
what it considers to be its rights?
That being said, future hardware is not exclusively Intel, all avenues
are explored. If AMD is indeed better, then AMD might be chosen, but
that decision won't be based on "the PSP will be easier to crack
because it's younger" nor will it be based on "for some unknown
reason, AMD will be fine with us reverse engineering it".
Besides, my understanding is that coreboot does not support ryzen
CPUs, so a huge amount of work would be required if we went that way,
no ?

> Best regards,
> Mike
>
> "disable Intel hyperthreading" :
> [1] - https://news.ycombinator.com/item?id=17829790
> [2] - https://marc.info/?l=openbsd-tech=153504937925732=2
> speaker as a microphone:
> [3] - 
> https://security.stackexchange.com/questions/154343/can-a-speaker-be-used-as-a-microphone
> [4] - https://mail.coreboot.org/pipermail/coreboot/2018-January/085979.html
> On Thu, Aug 30, 2018 at 12:41 AM Youness Alaoui
>  wrote:
> >
> >  Wow, Mike, seriously, I am going to side 100% with Nico, you are
> > spreading FUD, making your own personal opinions (which are themselves
> > derived from other people's FUD) and stating them as the universal
> > law.
> > The ME is not known to be a backdoor. It doesn't mean that it's not a
> > backdoor, it simply means that it's not known to be a backdoor. The
> > fa

Re: [coreboot] T450S + Coreboot

[Youness Alaoui]

On Thu, Aug 30, 2018 at 2:15 AM Brian Herman
 wrote:
>
> Sorry, I'm going to read the documentation more and make this a personal goal 
> by the end of 2019. I didn't want to stir up so much drama. Time and money 
> are not constraints on this particular problem. One way or another by January 
> 22, 2019 I will have either figured it out or I will pay to figure it out. I 
> have used Linux since college. I have no kids. I have no girlfriend. I have 
> tons of free time.
>
Sorry to see your thread going off-topic.
I don't know if it will help you but I've wirtten detailed blog posts
on my experience in getting coreboot to work on the broadwell and
skylake librems. It's not a "guide how to port to coreboot" but it
explains some of the problems I've had and it might help you save some
time.
You can go to https://puri.sm/coreboot/timeline/ and search for
"Youness" to see my blog posts in chronological order on the right
side bar.
Good luck with your project!

> Make It So,
> Brian Herman
>
>
>
>
>
>
>
>
>
>
>
> So you have made it to the end..
> Thanks for reading!
>
> On Wed, Aug 29, 2018 at 4:42 PM Youness Alaoui 
>  wrote:
>>
>>  Wow, Mike, seriously, I am going to side 100% with Nico, you are
>> spreading FUD, making your own personal opinions (which are themselves
>> derived from other people's FUD) and stating them as the universal
>> law.
>> The ME is not known to be a backdoor. It doesn't mean that it's not a
>> backdoor, it simply means that it's not known to be a backdoor. The
>> fact that it's closed source and not user-controlled (Even if you had
>> the sources, you can't modify them and update it to your custom ME
>> version) is where the problem actually is. There *might* be a backdoor
>> hidden somewhere in there, or maybe there isn't, nobody knows, but
>> there has been a lot of research done on the ME and so far, none have
>> been found as far as I know.
>>
>> Your worry about what the ME does, how it can give someone control
>> over the PC, etc.. are NOT what qualifies it as a "backdoor", but like
>> Nico said, it's a frontdoor, it's not a "hidden access", it's a
>> "promoted access" to the PC, it's the main ME functionality which is
>> well documented. You don't have to use some "only known to some secret
>> person" trick to access the ME, you just need to point your web
>> browser to the right port on localhost.
>> Your comparison of saying the ME is a backdoor is like saying that a
>> webcam is a spying device because it can capture images of you! Yeah,
>> sure, that's technically true, it can capture images of you, but only
>> after you plug it in and open an image capture software, and you still
>> have control of those images. The fact that the webcam schematics
>> isn't open means that it could still have a small wifi or GSM chip
>> embedded inside which makes it send the images to the CIA, but it's
>> not a guarantee that it does. So, yes, you can complain that the
>> webcam isn't open hardware so you can't technically trust what it
>> does, but you can't just come out and say with absolute certainty that
>> any and all webcams in the world are spying devices for the CIA,
>> that's just ridiculous.
>>
>> So, back to the ME, we know exactly what it does, it's all extremely
>> well documented and explained, the fact that it allows remote control
>> of the PC is actually the reason for its existence and it's a very
>> very valid reason in the corporate context and the fact that those
>> features also 'coincidentally' resemble the features of an actual
>> 'trojan horse' virus, doesn't mean that the ME itself is a virus..
>> otherwise the 'rm' linux command would be considered a virus since it
>> deletes files and there are some viruses that can delete your files as
>> well
>> Now the problem is that it's closed source, and not user controlled
>> (remote control features *are* user controlled, I'm talking about
>> being able to replace the firmware with your own), so yes, it can't be
>> audited by the larger open source community, but that also doesn't
>> guarantee any security necessarily (how many open source programs
>> still have security bugs?).
>>
>> Either way, you yourself said earlier, when talking about the AtomBIOS
>> that "it could be disassembled quite well with AtomDis -
>> https://github.com/mikebdp2/AtomDis - reducing any security concerns
>> regarding this blob to a minimum.", well, the ME can be disassembled
>> with any x86 disassembler, so why can't you also say that "reduces any

Re: [coreboot] T450S + Coreboot

[Youness Alaoui]

 Wow, Mike, seriously, I am going to side 100% with Nico, you are
spreading FUD, making your own personal opinions (which are themselves
derived from other people's FUD) and stating them as the universal
law.
The ME is not known to be a backdoor. It doesn't mean that it's not a
backdoor, it simply means that it's not known to be a backdoor. The
fact that it's closed source and not user-controlled (Even if you had
the sources, you can't modify them and update it to your custom ME
version) is where the problem actually is. There *might* be a backdoor
hidden somewhere in there, or maybe there isn't, nobody knows, but
there has been a lot of research done on the ME and so far, none have
been found as far as I know.

Your worry about what the ME does, how it can give someone control
over the PC, etc.. are NOT what qualifies it as a "backdoor", but like
Nico said, it's a frontdoor, it's not a "hidden access", it's a
"promoted access" to the PC, it's the main ME functionality which is
well documented. You don't have to use some "only known to some secret
person" trick to access the ME, you just need to point your web
browser to the right port on localhost.
Your comparison of saying the ME is a backdoor is like saying that a
webcam is a spying device because it can capture images of you! Yeah,
sure, that's technically true, it can capture images of you, but only
after you plug it in and open an image capture software, and you still
have control of those images. The fact that the webcam schematics
isn't open means that it could still have a small wifi or GSM chip
embedded inside which makes it send the images to the CIA, but it's
not a guarantee that it does. So, yes, you can complain that the
webcam isn't open hardware so you can't technically trust what it
does, but you can't just come out and say with absolute certainty that
any and all webcams in the world are spying devices for the CIA,
that's just ridiculous.

So, back to the ME, we know exactly what it does, it's all extremely
well documented and explained, the fact that it allows remote control
of the PC is actually the reason for its existence and it's a very
very valid reason in the corporate context and the fact that those
features also 'coincidentally' resemble the features of an actual
'trojan horse' virus, doesn't mean that the ME itself is a virus..
otherwise the 'rm' linux command would be considered a virus since it
deletes files and there are some viruses that can delete your files as
well
Now the problem is that it's closed source, and not user controlled
(remote control features *are* user controlled, I'm talking about
being able to replace the firmware with your own), so yes, it can't be
audited by the larger open source community, but that also doesn't
guarantee any security necessarily (how many open source programs
still have security bugs?).

Either way, you yourself said earlier, when talking about the AtomBIOS
that "it could be disassembled quite well with AtomDis -
https://github.com/mikebdp2/AtomDis - reducing any security concerns
regarding this blob to a minimum.", well, the ME can be disassembled
with any x86 disassembler, so why can't you also say that "reduces any
security concerns regarding the ME to a minimum".

We're about to get full control back of the ME. I've been working for
the past few weeks on reproducing the PTResearch buffer overflow
exploit on the ME, and yesterday they released a PoC for Apollolake
(in case you missed it : https://github.com/ptresearch/IntelTXE-PoC),
so with the progress I made and with that, I should be able to soon
port it to skylake (and write docs on how to port to other platforms
as well) which will at least give us the ability to gain back the
'user-controlled' aspect of it as we'd have code execution on it.
Which by the way, also means that BootGuard can be disabled (since the
ME is the one checking for the boot guard signatures), which should
enable the ability to port coreboot to a lot more machines (including
the T450S that this thread is supposed to be about). Hopefully

On Wed, Aug 29, 2018 at 5:50 AM Mike Banon  wrote:
>
> > What suspicious activities? I know, for many people the Intel ME firmware
> > contains unwanted features. But these features are documented.
> > In your world, a device becomes backdoored because somebody
> > didn't read the manual?!?
>
> Somewhere I've seen a report about Intel ME suspicious network
> activities (if I remember correctly they were using Wireshark on a PC
> placed between a computer with ME and the outside network) which has
> affected my personal opinion. Although it could be argued that its
> just some OEM has set up their ME in such a way, maybe even in a
> documented way (although a way undesirable to the end user), still it
> didn't look good to me. In addition, regarding all those Intel ME
> vulnerabilities recently discovered: one could assume that at least
> some of these "vulnerabilities" @ were actually the backdoors which
> have 

Re: [coreboot] Intel ME what is it? And when did this dangerous thing get installed?

[Youness Alaoui]

I think there's a good explanation of it in the FAQ of the libreboot
project here : https://libreboot.org/faq.html#intelme
If there are more specific questions that you have, ask them and I
might be able to answer them!

On Wed, Aug 29, 2018 at 2:36 AM Gregg Levine  wrote:
>
> Hello!
> Would one of you, or even any of you please take some time out of your
> busy schedule and ponder the subject? And of course try to respond
> accordingly?
>
> Bootguard sadly I am familiar with, but the Intel ME product I confess
> I understand a portion about it. And not enough to mention here.
> -
> Gregg C Levine gregg.drw...@gmail.com
> "This signature fought the Time Wars, time and again."
>
> --
> 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] Using linux as payload

[Youness Alaoui]

Hi,

I might not be the best one to answer your question, but here are my thoughts :
- the "unknown type 'payload'" error is probably because cbfs changed
the type name from "payload' to "simple elf" since you can add elfs in
there that are not actual 'payloads'. I think though that it
auto-changed the file type to 'simple elf', since you can see in the
cbfs print :
fallback/payload   0xc7a80simple elf5244700 none
So the payload is added, it has type "simple elf" and is 5.2MB (which
is the bzImage + initrd.cpio size).
Then in your cbmem log you can see that it did find the payload and
that it decompressed all the sections and everything seems fine :
CBFS: Locating 'fallback/payload'
CBFS: Found @ offset c7b80 size 5006d5
[...]

And then it jumps into it (i.e: it executes the payload) :
Jumping to boot code at 0004(8fe11000)

The reason that's the last messages you see is simply because linux
does not print any messages to cbmem (SeaBIOS does, and if you look at
your old logs, you'd see right after that "jumping to boot code"
there's the SeaBIOS debug messages starting).

So I think it's all good for you, but your problem is actually with
your linux (Heads) configuration itself, you probably simply do not
have the right graphics driver enabled in the kernel, so linux boots
but it doesn't initialize the GPU so nothing appears. You can either
find and enable your GPU driver in the kernel and rebuild Heads, or
you can tell coreboot to initialize the gpu (either with the GOP
driver+VBT or by running the option rom) and tell it to initialize the
VGA framebuffer (probably in text mode though I'm not sure) or
whatever is needed to actually get some graphics output.
I remember trying a few different options and configurations for the
Librem and in the end, I simply removed the vgabios/vbt from coreboot,
told coreboot not to initialize the graphics, and added the i915
kernel driver to heads and that was all that was needed. Once heads
booted, the kernel driver initialized the graphics and that's it.

I hope that helps,
Youness.

On Sat, Aug 18, 2018 at 4:51 AM Jorge Fernandez Monteagudo
 wrote:
>
> Hi all!
>
>
> I have a coreboot from master git working ok in my AMD Bettong demoboard with 
> SeaBIOS and now
>
> I'm trying to use a bzImage (2651888 bytes) and initrd.cpio.xz (2604544 
> bytes) generated by Heads in
>
> order to test the linux payload.
>
>
> When I compile the coreboot I see:
>
>
> Created CBFS (capacity = 8388056 bytes)
> CBFS   apu/amdfw
> CBFS   AGESA
> CBFS   fallback/romstage
> CBFS   fallback/ramstage
> CBFS   cmos_layout.bin
> CBFS   pci1002,9874.rom
> CBFS   fallback/dsdt.aml
> CBFS   fallback/payload
> W: Unknown type 'payload' ignored
> CBFS   coreboot.rom
> CBFSLAYOUT  coreboot.rom
>
> This image contains the following sections that can be manipulated with this 
> tool:
>
> 'COREBOOT' (CBFS, size 8388096, offset 512)
>
> It is possible to perform either the write action or the CBFS add/remove 
> actions on every section listed above.
> To see the image's read-only sections as well, rerun with the -w option.
> CBFSPRINT  coreboot.rom
>
> Name   Offset Type   Size   Comp
> cbfs master header 0x0cbfs header32 none
> fallback/romstage  0x80   stage   32220 none
> fallback/ramstage  0x7ec0 stage   56689 none
> cmos_layout.bin0x15c80cmos_layout  1516 none
> fallback/dsdt.aml  0x162c0raw  6673 none
> (empty)0x17d40null32856 none
> apu/amdfw  0x1fdc0raw622592 none
> pci1002,9874.rom   0xb7e00optionrom   64512 none
> fallback/payload   0xc7a80simple elf5244700 none
> (empty)0x5c8200   null   228248 none
> AGESA  0x5ffdc0   raw690436 none
> (empty)0x6a8740   null  1405592 none
> bootblock  0x7ffa00   bootblock 912 none
>
> Built amd/bettong (FP4)
>
>
> The "W: Unknown type 'payload' ignored" message is ok? Maybe the payload 
> doesn't fit in the
>
> coreboot image?
>
>
> Now when I boot the board the last messages I can see on serial console are:
>
>
> ...
>
> Writing table forward entry at 0x0500
> Wrote coreboot table at: 0500, 0x10 bytes, checksum 5ffd
> Writing coreboot table at 0x8fe11000
>  0. -0fff: CONFIGURATION TABLES
>  1. 1000-0009: RAM
>  2. 000c-8fdd9fff: RAM
>  3. 8fdda000-8fff: CONFIGURATION TABLES
>  4. 9000-cfff: RESERVED
>  5. f800-fbff: RESERVED
>  6. fed4-fed44fff: RESERVED
>  7. 0001-00022eff: 

Re: [coreboot] Kaby Lake FSP

[Youness Alaoui]

Great, thanks!
I understand that as platform ages, it gets less development, I was
mostly asking because I saw that coffeelake FSP headers are in
coreboot but there are no FSP images for coffeelake on github yet,
which is basically the same/similar issue as what we complained about
with regards to Kabylake, and your answer was only about Kabylake, so
I was hoping other platforms are "in the works" for being kept up to
date between public and "internal" releases.

Thanks,
Youness.
On Wed, Jul 18, 2018 at 8:05 PM Desimone, Nathaniel L
 wrote:
>
> Hi Youness,
>
> In general yes, Intel does plan to continue developing of FSP for future 
> platforms. We will make a good faith effort to keep the publically posted FSP 
> binary freshly updated. I would like to caution that as a platform ages, our 
> internal development shifts to newer ones. Accordingly, I would expect the 
> frequency of FSP releases to lengthen as a platform ages.
>
> Thanks,
> Nate
>
> -Original Message-
> From: Youness Alaoui [mailto:kakar...@kakaroto.homelinux.net]
> Sent: Monday, July 16, 2018 12:29 PM
> To: Desimone, Nathaniel L 
> Cc: coreboot 
> Subject: Re: [coreboot] Kaby Lake FSP
>
> Hi Nate,
>
> Thanks a lot for listening to our request and taking care of this! I'm happy 
> to see the binaries finally updated and the FSP headers in coreboot having a 
> matching publicly available binary to use.
> You've only mentioned Kabylake in your email, is it safe to assume that 
> you'll use these same practices for future platforms as well ?
>
> Thanks,
> Youness.
> On Tue, Jul 10, 2018 at 9:04 PM Desimone, Nathaniel L 
>  wrote:
> >
> > Hi All,
> >
> > I am a UEFI firmware architect working for Intel Corp. One of my focus 
> > areas is FSP. There was some prior discussion here regarding the lack of 
> > public updates for Kaby Lake FSP binaries and headers and questions 
> > regarding specialized FSP binaries being built for specific boards. I would 
> > like to clear up some of these questions and concerns. We just pushed all 
> > of the recently released versions of Kaby Lake FSP (3.1.0 through 3.6.0) to 
> > https://github.com/IntelFsp/FSP/tree/Kabylake. While there might appear to 
> > be forks of Kaby Lake FSP, they are actually just snapshots at different 
> > points in time. For example, there is one commit labelled as "Gold release 
> > for Kaby Lake FSP" that appears to be special fork for IoT devices... this 
> > commit is actually just Kaby Lake FSP Release 2.6.0 without any IoT 
> > specific modifications. Apologies for the confusing commit messages and for 
> > the temporary lapse in updates.
> >
> > With Best Regards,
> >
> > Nate
> >
> > --
> > 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] Kaby Lake FSP

[Youness Alaoui]

Hi Nate,

Thanks a lot for listening to our request and taking care of this! I'm
happy to see the binaries finally updated and the FSP headers in
coreboot having a matching publicly available binary to use.
You've only mentioned Kabylake in your email, is it safe to assume
that you'll use these same practices for future platforms as well ?

Thanks,
Youness.
On Tue, Jul 10, 2018 at 9:04 PM Desimone, Nathaniel L
 wrote:
>
> Hi All,
>
> I am a UEFI firmware architect working for Intel Corp. One of my focus areas 
> is FSP. There was some prior discussion here regarding the lack of public 
> updates for Kaby Lake FSP binaries and headers and questions regarding 
> specialized FSP binaries being built for specific boards. I would like to 
> clear up some of these questions and concerns. We just pushed all of the 
> recently released versions of Kaby Lake FSP (3.1.0 through 3.6.0) to 
> https://github.com/IntelFsp/FSP/tree/Kabylake. While there might appear to be 
> forks of Kaby Lake FSP, they are actually just snapshots at different points 
> in time. For example, there is one commit labelled as "Gold release for Kaby 
> Lake FSP" that appears to be special fork for IoT devices... this commit is 
> actually just Kaby Lake FSP Release 2.6.0 without any IoT specific 
> modifications. Apologies for the confusing commit messages and for the 
> temporary lapse in updates.
>
> With Best Regards,
>
> Nate
>
> --
> 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] Porting coreboot to new board

[Youness Alaoui]

This is the best I can do for you :

https://ark.intel.com/products/89608/Intel-Xeon-Processor-E3-1505M-v5-8M-Cache-2_80-GHz

Product Collection: Intel® Xeon® Processor E3 v5 Family
Code Name: Products formerly Skylake

kakaroto@kakaroto:~/coding/purism/coreboot$ git grep SOC_INTEL_SKYLAKE
| grep mainboard
src/mainboard/google/chell/Kconfig: select SOC_INTEL_SKYLAKE
src/mainboard/google/glados/Kconfig: select SOC_INTEL_SKYLAKE
src/mainboard/google/lars/Kconfig: select SOC_INTEL_SKYLAKE
src/mainboard/intel/kblrvp/Kconfig: select SOC_INTEL_SKYLAKE
src/mainboard/intel/kunimitsu/Kconfig: select SOC_INTEL_SKYLAKE
src/mainboard/intel/saddlebrook/Kconfig: select SOC_INTEL_SKYLAKE
src/mainboard/purism/librem_skl/Kconfig: select SOC_INTEL_SKYLAKE

I'm going to assume that the skylake Xeon is supported and will work
(from a coreboot standpoint) just the same as a Core i5 or whatever,
but it might not be the case. That will be your job to figure the rest
out.

Good luck,
Youness.


On Wed, May 30, 2018 at 3:35 PM, Zvi Vered  wrote:
> Hello Youness,
>
> Thank you very much for the detailed information !
>
> Can you please tell what is the best starting point for a XEON board ?
> I think there are no "Intel® XEON® Processor E3-1505M v5" boards in last
> version of coreboot.
> Am I right ?
>
> Best regards,
> Zvika
>
> On Tue, May 29, 2018 at 9:15 PM Youness Alaoui
>  wrote:
>>
>> Hi,
>>
>> I suggest you read the wiki :
>> https://www.coreboot.org/Developer_Manual and
>> https://www.coreboot.org/Motherboard_Porting_Guide
>> I would also suggest maybe (optional) that you read my blog posts
>> about my own experience porting coreboot to a new motherboard :
>> https://puri.sm/posts/diving-back-into-coreboot-development/
>> https://puri.sm/posts/librem-13-coreboot-report-january-12-2017/
>> https://puri.sm/posts/librem-13-coreboot-report-february-3rd-2017/
>> https://puri.sm/posts/librem-13-coreboot-report-february-25th-2017/
>> https://puri.sm/posts/coreboot-on-the-librem-13-v2-part-1/
>> https://puri.sm/posts/coreboot-on-the-skylake-librems-part-2/
>>
>> To answer your specific questions : It depends on your machine, is it
>> AMD or is it Intel? Is it Ivybridge or Broadwell or Skylake or
>> Apollolake, etc.. ? Does it have soldered RAM or does it use SODIMMs?
>> Depending on the CPU architecture, the CPU 'brand' and even the model
>> of the CPU itself, the port will be done very differently. You'd first
>> want to find a mainboard that is as close as your current one, and
>> start modifying that, there isn't "one mainboard to use as base"
>> because the code, files, etc.. are almost unique depending on the
>> CPU/northbridge/southbridge model, so use the closest one as your
>> base.
>> As far as I know, the file board_info.txt is just information about
>> the board, it's not getting used by coreboot, it's more of an
>> indication for developers.
>> As for the other files, it will depend once again on your board. I'd
>> say Kconfig and devicetree.cb are mandatory, the rest may or may not
>> be mandatory depending on your hardware. The cmos.layout for example
>> isn't mandatory, but you'd probably need it if you enable CMOS support
>> in your KConfig, The 'spd' files containing the RAM's SPD EEPROM
>> information are mandatory only if your board has soldered RAM (common
>> in laptops but not in desktops), but they are not needed (and actually
>> can't be provided) if the motherboard has SODIMM slots instead. So it
>> all depends. Your best bet is to look at what's there and see if you
>> need it or not and if you do, understand what it's for and what needs
>> to be changed in order to match your board.
>> Don't forget that before you get your board to boot with coreboot, you
>> will probably have to flash it and brick your board 100 times, so make
>> sure you have a backup of your original ROM copied somewhere safe and
>> that you have the hardware to re-program the SPI flash externally (and
>> test that it works), before you attempt to flash it.
>> Also, make sure you are patient, and ready to learn!
>>
>> Good luck!
>> Youness.
>>
>>
>> On Mon, May 28, 2018 at 10:31 PM, Zvi Vered  wrote:
>> > Hello,
>> >
>> > I have to port coreboot to a new "Mainboard" not listed in menuconfig.
>> > Is there a basic "Mainboard" I should use as a starting point that will
>> > be
>> > copied to my board ?
>> >
>> > The file board_info.txt contains few parameters.
>> > How can I know the meaning of each parameter and its possible values ?
>> >
>> >

Re: [coreboot] Porting coreboot to new board

[Youness Alaoui]

Hi,

I suggest you read the wiki :
https://www.coreboot.org/Developer_Manual and
https://www.coreboot.org/Motherboard_Porting_Guide
I would also suggest maybe (optional) that you read my blog posts
about my own experience porting coreboot to a new motherboard :
https://puri.sm/posts/diving-back-into-coreboot-development/
https://puri.sm/posts/librem-13-coreboot-report-january-12-2017/
https://puri.sm/posts/librem-13-coreboot-report-february-3rd-2017/
https://puri.sm/posts/librem-13-coreboot-report-february-25th-2017/
https://puri.sm/posts/coreboot-on-the-librem-13-v2-part-1/
https://puri.sm/posts/coreboot-on-the-skylake-librems-part-2/

To answer your specific questions : It depends on your machine, is it
AMD or is it Intel? Is it Ivybridge or Broadwell or Skylake or
Apollolake, etc.. ? Does it have soldered RAM or does it use SODIMMs?
Depending on the CPU architecture, the CPU 'brand' and even the model
of the CPU itself, the port will be done very differently. You'd first
want to find a mainboard that is as close as your current one, and
start modifying that, there isn't "one mainboard to use as base"
because the code, files, etc.. are almost unique depending on the
CPU/northbridge/southbridge model, so use the closest one as your
base.
As far as I know, the file board_info.txt is just information about
the board, it's not getting used by coreboot, it's more of an
indication for developers.
As for the other files, it will depend once again on your board. I'd
say Kconfig and devicetree.cb are mandatory, the rest may or may not
be mandatory depending on your hardware. The cmos.layout for example
isn't mandatory, but you'd probably need it if you enable CMOS support
in your KConfig, The 'spd' files containing the RAM's SPD EEPROM
information are mandatory only if your board has soldered RAM (common
in laptops but not in desktops), but they are not needed (and actually
can't be provided) if the motherboard has SODIMM slots instead. So it
all depends. Your best bet is to look at what's there and see if you
need it or not and if you do, understand what it's for and what needs
to be changed in order to match your board.
Don't forget that before you get your board to boot with coreboot, you
will probably have to flash it and brick your board 100 times, so make
sure you have a backup of your original ROM copied somewhere safe and
that you have the hardware to re-program the SPI flash externally (and
test that it works), before you attempt to flash it.
Also, make sure you are patient, and ready to learn!

Good luck!
Youness.


On Mon, May 28, 2018 at 10:31 PM, Zvi Vered  wrote:
> Hello,
>
> I have to port coreboot to a new "Mainboard" not listed in menuconfig.
> Is there a basic "Mainboard" I should use as a starting point that will be
> copied to my board ?
>
> The file board_info.txt contains few parameters.
> How can I know the meaning of each parameter and its possible values ?
>
> The board kontron/kt690 for example contains few files like: cmos.layout,
> devicetree.cb, etc
> Are all those files mandatory ?
> Is there a list of mandatory files or routines required in order to port a
> board ?
>
> Your help is highly appreciated.
> Best regards,
> Zvika
>
> --
> 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] FSP 2.0 headers in coreboot

[Youness Alaoui]

On Fri, May 18, 2018 at 2:59 PM, Nico Huber  wrote:
>
> I have to admit, I don't like your patch. While it gets the job done,
> it brings `MemInfoHob.h` and `FspsUpd.h` out of sync, so the state in
> coreboot as a whole would match neither version.
>
Good point. It is a Frankenstein, but it was either that or have
#ifdefs in the fsp vendorcode itself to determine if attribute X is
available or not, etc..

>> - or abandon my patch (which means I can never send a working
>> board-status for the librems without having a dirty tree or a version
>> commit hash that doesn't match upstream)
>> - or have the possibility to choose between the two (either via
>> #ifdefs or via a variants method).
>
> If we can't get a new, fitting binary out of Intel, I would prefer this,
> or, more bluntly, just copy the GitHub version and revert the changes
> that need the additional UPD.
>
> In other words, whatever happens, I think we should have the headers
> of the latest public release in the tree.
>

I agree, that's probably the cleanest solution, but I didn't suggest
it because I figured people would be yelling about removing
functionality that might need to be re-added eventually if Intel end
up doing an updated release.

>> - or, if Intel people are reading this right now (or someone here can
>> poke them directly), have the public release updated so this matter
>> can be dropped entirely (the public update would need to be released
>> *very* soon though).
>
> Even if you (Purism) poke them about it, that might help. But I would
> like to see that Google does that too (IMHO, they profit most from the
> mess). Any of you should have more leverage than the customer of a
> customer of a customer of a potential customer of Intel has, that I
> work for ;)
I know no-one at Intel to poke them about. I'll ask if Todd has
contacts that might be able to help. I'm hoping that some of the
people that are working for Intel are following this email thread but
if they are, they haven't raised their hands. Anyone knows or can
suggest the name of someone that we might poke ? I'm guessing those
working for Google who actually received the newer FSP from Intel
might know who to ask, and since they are the ones that would be
affected by their code/features being removed if we revert to github
version of header, it might help put some pressure on this issue (so
far, I haven't seen any incentive to make them do that).

>
>> Should we put this to a vote now, or should we discuss the
>> possibilities/alternatives some more, if anyone has ideas on how to
>> tackle this specific issue ?
>
> Well, my vote, in order of preference:
>
>  1. Poke Intel.
>  2. Get a verbatim copy of the GitHub headers in (in a way of [least] effort 
> for
> the community). Maybe in a month from now? no matter the outcome
> from 1.
>
> Nico

I agree, and I give my 100% vote for that as well. It will be much
better than an #ifdef mess and would be a good incentive for the
people from Intel not saying "no, too much hassle to update the file,
we got nothing to lose anyway if we just ignore this".
So let's see who can poke who from Intel, let's give a deadline (1 or
2 months? if bureaucracy means it will take longer, we might revisit
if we at least got a confirmation that the issue is being looked at on
Intel's side), then once deadline is reached, we revert to public
headers and remove functionality that prevents building (access to
nonexistent fields in UPD) and in the future, reject patches on gerrit
for non public blobs.

Thanks!

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

Re: [coreboot] Exception on Skylake after enabling ACPI timer emulation

[Youness Alaoui]

Hi Piotr,

Great, I'm glad the ucode was indeed the issue, and that I was lucky
enough to spot it.
I think it doesn't get added correctly because the path might be wrong
? unless you put the ucode bin file in the root directory of coreboot,
then it might not find it, or maybe it's another option to actually
tell it to add the file to cbfs.
See our ucode related configs in :
https://code.puri.sm/kakaroto/coreboot-files/src/master/configs/config.librem13v2

CONFIG_SUPPORT_CPU_UCODE_IN_CBFS=y
CONFIG_CPU_MICROCODE_CBFS_GENERATE=y
CONFIG_CPU_UCODE_BINARIES="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/cpu_microcode_blob.bin"

Also note these two options which get passed to the FSP so the
microcode can get applied :
CONFIG_CPU_MICROCODE_CBFS_LEN=0x18000
CONFIG_CPU_MICROCODE_CBFS_LOC=0xFFE115A0

That location address makes cbfstool add the ucode binary in cbfs at
the right offset so it's at that address, and the len has to match (or
be superior) to the ucode file size.

I hope that helps,
Youness.



On Sun, May 20, 2018 at 7:25 PM, Piotr Król <piotr.k...@3mdeb.com> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
>
>
> On 05/18/2018 07:53 PM, Youness Alaoui wrote:
>> Hi Piotr,
>
> Hi Youness,
>
>> Here's my librem13v2 info as reported by coreboot : CPU: Intel(R)
>> Core(TM) i7-6500U CPU @ 2.50GHz CPU: ID 406e3, Skylake D0, ucode:
>> 00c1 CPU: AES supported, TXT NOT supported, VT supported MCH:
>> device id 1904 (rev 08) is Skylake-U PCH: device id 9d48 (rev 21)
>> is Skylake-U Premium IGD: device id 1916 (rev 07) is Skylake ULT
>> GT2
>>
>> So I can see that we have the exact same CPU, MCH, PCH and IGD,
>> but there is one difference that I noticed, your line said : CPU:
>> ID 406e3, Skylake D0, ucode: 
>
> Good catch. I'm not sure why I can't include microcode that I obtained
> using get_blobs.sh. I marked:
>
> CONFIG_CPU_UCODE_BINARIES="cpu_microcode_blob.bin"
>
> But my results is:
>
> Name   Offset Type   Size   Comp
> cbfs master header 0x0cbfs header32 none
> fallback/romstage  0x80   stage   47588 none
> fallback/ramstage  0xbb00 stage   84189 none
> vgaroms/seavgabios.bin 0x20440raw 28672 none
> config 0x274c0raw   457 none
> revision   0x27700raw   580 none
> payload_revision   0x27980raw   239 none
> (empty)0x27ac0null 1240 none
> fspm.bin   0x27fc0fsp389120 none
> payload_config 0x87000raw  1682 none
> (empty)0x87700null 2200 none
> fsps.bin   0x87fc0fsp188416 none
> fallback/postcar   0xb6000stage   31352 none
> fallback/dsdt.aml  0xbdac0raw 12879 none
> fallback/payload   0xc0d80simple elf  73920 none
> (empty)0xd2e80null  2877080 none
> cpu_microcode_blob.bin 0x391540   microcode   0 none
> (empty)0x3915c0   null  1976792 none
> bootblock  0x573fc0   bootblock   49152 none
>
> So something wrong with size. I added microcode manually and things
> look better right now. Thank you.
>
> What is correct way to include binary microcode? In PC Engines we had
> to create our own method [1]. I wonder what would be correct way for tha
> t.
>
> [1] https://github.com/pcengines/coreboot/pull/132/files
>
> Best Regards,
> - --
> Piotr Król
> Embedded Systems Consultant
> https://3mdeb.com | @3mdeb_com
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCAAdFiEE4DCbLYWmfoRjKeNLsu5x6WeqnkwFAlsCA90ACgkQsu5x6Weq
> nkwJGQ//e5ujrAgQUyV97vEG92kz/nCv8qYKRAUUvjkeq2htz6RMy/FK74HxbOPM
> ITZvVc14ecWscpNyKCwWeWSAkf9UIxYR4MdN5D7CVsxP1/V3+H0uKi9JbrjPa4qe
> RVbPTpZC0vvadQ797KbVbj/i/i9B1j06LugAMF+utU0bB8oTb0bl2fliD62G7jbp
> JJTgX0cXyVQdfKV8593Wiy2lsrIi7nev701Yynpx4Qap+DBMLfQqFB6QEcCVopH0
> gNIMnLgkK8PKlwfgj4+puAWnObpKkzaXZY1avoxCVzFllYF9Z9UoiNB8ZFjFEJ6P
> GkfNe/gxw8Rnh09eZH2z4peE2Ja0MFiBqyfbyiKMj7f1VYK+qEDhBZoV7NM2agZR
> iExXCINvLvBu8WTkaJ83dKjQwZ+NHqpfngqwdwW9kthMyHLyt0amSyYaJbsHJhAQ
> CDHaXCNFjvFA7BFSKiBuG4FLc+XMHEFSxP3EGfcWq3aPZ2LmjS/GrwRRHYjDvbBR
> JxNkppaWXrPRJ7XOmy94g9gL4hmcWD3QX40lqRGyQt0ZWDpG0FgjsoX6GBxhGSCL
> LH3SGTwYoXKGqUp39YaPPACq0nJtxkTtCMK+ZH0D9Q173lngGewc5BtASgQIGWl6
> UW6G8A/EmDmpCFA3xe3Rlj+PWm46w3cBWEizx4pPSYoycMYlSBk=
> =mfsi
> -END PGP SIGNATURE-
>
> --
> 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] Exception on Skylake after enabling ACPI timer emulation

[Youness Alaoui]

Hi Piotr,

The Librems use the FSP 2.0 for SKL because I was told (I can't
remember by who, but I think it was on coreboot IRC channel) that the
FSP 2.0 works for both Skylake and Kabylake and that FSP 2.0 was
better supported within coreboot than FSP 1.1. We had the Librems use
FSP 1.1 before, but when we upgraded from coreboot 4.6 to coreboot
4.7, we also upgraded to using FSP 2.0 (as you can see in our
changelog : 
https://code.puri.sm/kakaroto/coreboot-files/src/master/Changelog.txt)
It wasn't particularly straightforward because of two issues :
1 - the FSP 2.0 headers in coreboot do not match the FSP 2.0 header
from the public github binaries. You can see our patch to fix it here
: https://review.coreboot.org/26108 (once coreboot.org maintenance is
done).
2 - the FSP 2.0 doesn't set the AC and DC Lodline values, so you need
to set those manually in devicetree.cb otherwise the CPU will have a
tendency to overheat under load within a few milliseconds then
shutdown (see patch here : https://review.coreboot.org/25324 )

Other than that, the FSP 2.0 has been working great for our SKL
platform. I don't remember specifics, but I believe it was a lot less
trouble and fixed issues from when we were using the FSP 1.1.

I also can't find any information on MSR 0x121 anywhere, but I can
confirm that it has the expected value that coreboot sets :
root@librem13:~# rdmsr 0x121
2fba2e2501311808

From the crash though, I doubt your problem is the FSP, because it's a
crash on doing the 'wrmsr' instruction, probably because your CPU
doesn't recognize that MSR as being valid or something like that.

Here's my librem13v2 info as reported by coreboot :
CPU: Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz
CPU: ID 406e3, Skylake D0, ucode: 00c1
CPU: AES supported, TXT NOT supported, VT supported
MCH: device id 1904 (rev 08) is Skylake-U
PCH: device id 9d48 (rev 21) is Skylake-U Premium
IGD: device id 1916 (rev 07) is Skylake ULT GT2

So I can see that we have the exact same CPU, MCH, PCH and IGD, but
there is one difference that I noticed, your line said :
CPU: ID 406e3, Skylake D0, ucode: 

It looks like you haven't set a microcode for the CPU, and I think
that might be your actual problem. I remember being unable to boot the
machine without a microcode update, but I think it was because the FSP
itself would crash/refuse to boot if one wasn't set, so the very first
thing I did was to add the microcode update to coreboot and consider
it "on skylake and above, you can't boot without a valid microcode
update". In your case, that looks like that might be your problem. It
might be that the 0x121 MSR didn't exist or wasn't valid in the
default CPU ucode, and is only valid (or can only be set) after the
ucode update is applied, so I suggest you first try that, and see if
it solves any of your issues.

Good luck!
Youness.

On Fri, May 18, 2018 at 1:31 PM, Nico Huber  wrote:
> Hello Piotr,
>
> On 17.05.2018 18:20, Banik, Subrata wrote:
 FSP2.0, I'm following Librem Purism options since they seem to boot the
 same SoC. They use KabyLake FSP obtained by get_blobss.sh [1], if you
 think this is incorrect then I would like to know why, because it may
 mean that Pursim code is also incorrect from Intel point of view.
>>
>> SKL won't be compatible with KBL FSP. Please don’t try to use KBL FSP
>> and mix match with SKL Coreboot. No one tested that combination.
>
> Unless FSP is calling home, we can't say anything about the actual test
> coverage. KBL FSP somehow works on SKL. I assume the code is written for
> both platforms, the binaries are usually just not validated for all SKUs
> supported by the code (and it's often not documented for which they were
> validated).
>
> I wouldn't be surprised if the KBL FSP was more tested on SKL by now;
> not by Intel but by their customers and individuals. There's one simple
> reason: The older SKL FSP lacks most of the configuration options and
> is not well maintained within coreboot. So the KBL FSP works better (but
> you don't get any guarantee for that). OTOH, the KBL FSP release on
> GitHub is also not well integrated (although it was released half a year
> later, it's way behind regarding the header files in coreboot). The only
> Kabylake FSP binary 100% compatible with coreboot is the Google Support
> Package (not published separately, but you can carve it out of their
> firmware images).
>
> To wrap it up, if you want a public FSP binary that was validated for
> SKL, you'll have to use the old FSP1.1 version; or push Intel to publish
> something new. I would talk to your Intel support contact in any case,
> sometimes binaries pop up that nobody knew about.
>
> Nico
>
> PS. I can confirm that the KabylakeFsp0001 drop from last summer works
> with a 25W SKL-S CPU. Judging from the commit date, I also run it
> with that MSR write applied.
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

-- 

Re: [SeaBIOS] Librem 15v3 hangs at Booting from Hard Disk...

[Youness Alaoui]

On Wed, May 9, 2018 at 9:14 PM, Philip C.  wrote:
> Hello everyone!
>
> I've been having some issues with a laptop recently. My Librem 15v3 was
> bouncing along, until one day I ran into an apt-get upgrade issue. I
> attempted to fix the affected script by pointing it to the base directory
> busybox lived. The upgrade completed without any apparent issue.

This is clearly totally unrelated to SeaBIOS, and it looks like an
linux/grub installation problem.

>
> But, now no matter what I do, unattended boots hang on
>
> SeaBIOS (version rel-1.11.0-0-g63451fc)
> Booting from Hard Disk...
> _

If you see nothing after that, then that probably means that SeaBIOS
executed whatever was on the drive's boot sector and that failed to do
anything, so grub crashed or there was no grub in the first place, or
it was misconfigured and it stopped instead of showing some error
message, etc.. whatever the issue is, it looks like it's not related
to SeaBIOS.

>
> I have tried reinstalling the OS, using their live boot ISO. Each time, no
> matter which disk I configure (/dev/sda or /dev/nvme0n1), the install fails
> with the message
>
> Installation failed Failed to run update-initramfs on the target The exit
> code was 2
What OS is that ? What's the error of update-initramfs ? Did you try
to run update-initramfs manually to see what error it gives you ? I
remember seeing a similar error related to a busybox depedency (this
error https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864143) and I
can't remember the exact fix, but it was something like : edit
/etc/initramfs-tools/initramfs.conf and change the "BUSYBOX=auto" to
either "y" or "n", one of them fixes it. Or maybe it was the file
/usr/share/initramfs-tools/conf-hooks.d/cryptsetup, or maybe you have
to add a line "BUSYBOXDIR=/bin" to the config..
Either way, you should fix whatever is causing that first.

>
> I have upgraded coreboot, no joy. I have also tried manually running grub,
> from the installer, ie
>
> mkdir /mnt/root
> cryptsetup luksOpen /dev/sda3 root
> mount /dev/mapper/root /mnt/root
> mount /dev/sda1 /mnt/root/boot
> grub-install --boot-directory=/mnt/root/boot /dev/sda
> update-grub2
>
Yeah, upgrading coreboot won't change anything if your hard drive
doesn't have a working grub installed on it.
I think your issue here might be that "update-grub2" will update the
grub files in /boot (from the live USB), not in /mnt/root/boot. I
would suggest to simplify your life and just "mount /dev/sda1 /boot"
so the update would work (even if you manually use grub-mkconfig -o
/mnt/root/boot, it will still scan some things in /boot, and it might
mess things up, so just mount it on top of the existing /boot and call
update-grub)


> The folks at purism/librem seem to be as confused as I am. Does anyone here
> have any insight into how I can fix this problem?
I haven't heard of this issue, usually, if it's related to coreboot, I
get asked for my opinion, but I suppose I wasn't poked about it by
tech support because it's a linux/install problem, and indeed, it's
not related to coreboot.

As for all that stuff about getting seabios debug, I don't know how
much that will help you. I'm sure all you'll see is something like
"jumping into boot sector" then nothing, it's not like the cbmem
console log will have the grub debug output in it saying "I'm about to
crash because I can't find my config" for example. Unless SeaBIOS sets
up a segfault handler or something prior to jumping into boot drive
and writes to the log a crash report, I have no idea if it does that.

>
> Thanks!
>
I hope that helps, good luck. And if you need more help, I suggest not
to spam this mailing list with non-seabios-development related
questions, you can continue emailing me directly.
Youness.

___
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios

Re: [coreboot] FSP 2.0 headers in coreboot

[Youness Alaoui]

I feel like this discussion is getting slightly out of hand, so let's
try to regroup a bit and move the discussion back to the original
topic : how to handle the FSP headers in coreboot.
I fully understand and agree with Nico's frustration about the blobs
situation and I think that's a bigger conversation than needed right
now. I do encourage discussing it and finding a good solution to avoid
having a similar mess in the future (or now, but in a different thread
to avoid going off-topic). I think Nico's idea of setting up rules for
how/what to merge in the future is a good idea and needs to be further
discussed until everyone is happy with the rules defined.

I would personally say "if the FSP headers in coreboot are for FSP
2.5.0 which is newer, then why isn't that 2.5.0 file made public?". If
we were to have a rule, then maybe forcing blobs to be available
publicly before having coreboot use/integrate them is a good step, so
if you plan on pushing a commit that adds FSP 3.0 to coreboot, then
that commit won't be merged until the associated blob becomes publicly
available (even if it's on intel's github and is non redistributable),
because merging commits that adds headers/support for some blob that
nobody has access to makes no sense if we think of coreboot as a
project that any enthusiast can clone and build for any machine if
they want to.

Now, back to the discussion about the "incompatible FSP headers", here
are the possibilities :
- should we merge my patch that makes the FSP header compatible with
the public blob, and let the CrOs coreboot clone have its own commit
that reverts it,
- or abandon my patch (which means I can never send a working
board-status for the librems without having a dirty tree or a version
commit hash that doesn't match upstream)
- or have the possibility to choose between the two (either via
#ifdefs or via a variants method).
- or, if Intel people are reading this right now (or someone here can
poke them directly), have the public release updated so this matter
can be dropped entirely (the public update would need to be released
*very* soon though).

Should we put this to a vote now, or should we discuss the
possibilities/alternatives some more, if anyone has ideas on how to
tackle this specific issue ?

Thanks,
Youness.



On Thu, May 10, 2018 at 9:34 PM, Nico Huber  wrote:
> On 11.05.2018 01:39, Timothy Pearson wrote:
>> Not to jump too far into the fray, but couldn't this be handled by
>> simply not blocking coreboot development on proprietary blobs?  For
>> instance, if someone wants to implement a feature that requires
>> repository-wide changes (e.g. the timestamp stuff that went in a couple
>> of years back) that happens to break only some blobby boards, that the
>> feature should be implemented anyway and the broken blobby boards added
>> back in as the vendor has time / inclination to fix?
>
> If we maintain the code for end users and not for vendors, vendors won't
> do anything. And the end users can't, I would call them developers
> otherwise.
>
>>
>> Basically, this seems to be what Linux already does for kernel work.
>> The benefit of upstreaming open code is that other people will maintain
>> it for you, but if you really need to publish a binary only driver
>> (NVIDIA) then you have the full burden of maintenance on yourself as the
>> vendor.  This encourages contribution back without putting an arbitrary
>> administrative limit on what kind of blob level is acceptable.
>
> The difference here is that Linux made it. It's not only accepted by
> vendors but actively employed. I fear for coreboot, currently, it's
> mostly the silicon vendor's customers that want (or maybe even only
> accept) it. Plus coreboot is firmware, nobody is used to maintain firm-
> ware.
>
> IMHO, we should make coreboot most easy to port to the widest range of
> boards possible. To extend the community. If that's only feasible
> through blobs (atm?), I can take it. But if a blob only helps that
> one company who built it, I don't see much value in it.
>
> Nico
>
> --
> 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] FSP 2.0 headers in coreboot

[Youness Alaoui]

Sorry for being late to answer to my own thread (busy busy busy).

A few notes :
The initial check-in of the kabylake FSP was uploaded with a BSD
license : 
https://github.com/IntelFsp/FSP/tree/d88078a708e768c7b6ee5cbc996299d303c3c702/KabylakeFspBinPkg
Later commits added Intel's Restricted Use License Agreement (which
basically prevents redistribution (and reverse engineering)).
That's also why the header commit I submitted didn't update the
headers to match the Gold release, but only what was in the initial
'BSD' release, which thankfully is compatible with the Gold release
(besides, most of the changes, other than the license header, were to
add typos and remove fields, since the header in coreboot is
technically 'newer').

Regarding Nico's idea of signing blobs, for old unmaintained blobs,
they could still be signed with a coreboot specific "this is a known
working, not guaranteed to be malware free but guaranteed to be
unmodified for years, or unmodified since its official release" key,
and a coreboot maintainer would have the private key to sign old blobs
with that key. That would at least resolve the condition of "all blobs
must be signed".

I do agree with Julius that headers should remain in coreboot, and not
move to the blobs.git, and I agree that removing old boards doesn't
make sense. Yes, I think coreboot is meant for enthusiasts and
tinkerers who want to build an image for their boards, and that's why
I'm suggesting to make the headers match the github version, because
it's now impossible to build anything with FSP (whether a google
board, or a Purism board for example) without first modifying coreboot
because the only FSP available to enthusiasts and tinkerers is the
github one.

In general, I like Nico's idea of setting up rules for blobs, but my
worry is that no matter how great and logical the rules are, the
blob-makers might simply ignore them.. you can ask for signed blobs,
but what if they refuse to sign it? Or even better, you can ask for
redistributable blobs, but what if they refuse to make them
redistributable? Will you simply stop supporting any boards that
depend on those blobs? You'd have to eventually compromise (for the
sake of the users/project) and break your own rules that you worked so
hard to perfect... Since they control the blobs, they have the power,
unless you think "integrate in coreboot" is a hard requirement for
them, and in that case, if you set up those rules, they would be
forced to follow them, that can actually help get things done the
right way instead of just asking nicely and never getting a positive
response. I don't really know... it might work for Intel/CrOS for
example, but maybe not for other vendors who wouldn't need to be
integrated in coreboot...

Anyway, to resolve the immediate issue with the header, how about
adding a 'variants' system, like we already have with mainboards?
Something like :
src/vendorcode/intel/fsp/fsp2_0/variants/google/*.h
src/vendorcode/intel/fsp/fsp2_0/variants/github/*.h
and in the Kconfig, we could just set FSP_VARIANT_DIR="github"
That would be (I assume) much less messy than having #ifdefs to
define-or-not specific fields in the UPD structures.
The only issue would be with regards to fields that coreboot uses that
aren't available in a variant, like for example, the
PcieRpClkSrcNumber field that doesn't exist in the github header but
is used in coreboot, there are a couple of solutions to that :
1 - add #define HAVE_PCIE_RP_CLK_SRC_NUMBER (for example) in the
headers and have #ifdefs everywhere in coreboot code. This is not a
great idea
2 - have something like "#define PcieRpClkSrcNumber UnusedUpdSpace26",
but that would add so much problems that it's a very stupid idea...
why am I ever writing this?
3 - manually add the missing fields somewhere in the Upd and only have
the changes between two variants where the field offsets change in the
structure.
4 - anyone else with better ideas?

Using solution 3 above, The 'google' variant would be the current
header, and the 'github' variant would be the header after my patch
[1] applied to it (so it's a mix between the google and the real
github header, but with field offsets matching what the github blob
would return), all the fields are still there, I think there are 3
fields that coreboot uses which aren't in the official header, and
they just end up in unused space, but at least the MemInfoHob will be
correct.

What do you think ?
Youness.


On Wed, May 9, 2018 at 3:49 AM, Nico Huber  wrote:
> On 09.05.2018 01:04, Nico Huber wrote:
>>  Unless a pointer as described above exists for a given plat-
>>  form that relies on a blob, all changes* to that platform
>>  *shall* be refused.
>>>
>>> I think this is counter-productive, as is removing any old boards that
>>> don't comply. I am okay with creating new rules for future platforms, but
>>> there is no reason to throw perfectly good and working boards out just
>>> because they weren't 

[coreboot] FSP 2.0 headers in coreboot

[Youness Alaoui]

Hi,

I've just pushed a commit for review on gerrit
(https://review.coreboot.org/#/c/coreboot/+/26108/) and I'm hoping to
open the discussion here on whether the public coreboot code should
have the FSP headers that match the public FSP headers or if they
should match the 'google fsp' headers.

My understanding of the situation is that chromebooks ship with a
google-modified FSP image and the fsp headers in coreboot have been
added by google employees even before the FSP was officially made
public by Intel. I also somewhat understood that the fsp headers in
coreboot would not be updated to match the public release because it
would break everyone building coreboot for their chromebooks or
something like that.

I'm a bit tired of always having that commit that fixes the header
applied locally in all my branches, and I think that it makes much
more sense for coreboot to have the fsp headers that match the public
release and for the google/chromebook coreboot repository to have the
"non-standard header" committed to it instead.
Worst case scenario, we could add #ifdefs to determine what the
structure contents should be depending on the target platform.

Maybe everyone will say "of course, that makes sense" or maybe
everyone will say "nope, I disagree", but hopefully we can have the
discussion here (or on gerrit) and decide how to handle this use case.
Note: I only pushed for skylake/kabylake, but apollolake/canonlake are
probably also affected by this mismatch of headers.

Thanks,
Youness.

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

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

[Youness Alaoui]

An update on the use of Index I/O to access the SPI flash from
software. I figured out the problem with coreboot. We weren't setting
the LPC I/O decode range 0x380-0x383 in the LPC PCI config (gen1_dec
config in devicetree) which would allow us to talk to the EC using
Index I/O on port 0x380. Once I set that, I was able to access Index
I/O on my coreboot-ed machine, and that opens up the software-based
flashing support.


On Mon, Mar 5, 2018 at 5:34 PM, Youness Alaoui
<kakar...@kakaroto.homelinux.net> wrote:
> 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 <mikeb...@gmail.com> 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
>> <kakar...@kakaroto.homelinux.net> wrote:
>>> On Sun, Mar 4, 2018 at 4:50 AM, Paul Kocialkowski <cont...@paulk.fr> 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 res

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 <mikeb...@gmail.com> 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
> <kakar...@kakaroto.homelinux.net> wrote:
>> On Sun, Mar 4, 2018 at 4:50 AM, Paul Kocialkowski <cont...@paulk.fr> 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 <cont...@paulk.fr> 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]

>> 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.
The 'ectool' is able to read it (ram idx reads if i remember
correctly) but it only worked with AMI BIOS. So there will definitely
be some work to be done there. You probably know a lot more about this
already, like what this 'ram idx' is, and why it didn't work in
coreboot, or if it's possible to read/write the flash using this EDI
interface, etc...

>
>> > Latest status update for Origami-EC firmware:
>> > https://www.mail-archive.com/coreboot@coreboot.org/msg50646.html
>>
>> Thanks! Good to see the status update on that.
>
> In order to kickstart the development of the Origami-EC firmware, I am
> designing evaluation boards for both the KB9012 and the KB3930 that
> will expose most of the I/O ports with headers, LEDs, buttons,
> connectors, etc. The design is done with KiCAD and will be released
> under the GPLv3+ as part of the Origami-EC project. I am also preparing
> a debug board to reflash the EC on the G505s from the keyboard
> connector.
>
> There is also ongoing work on the emulator and the SerialICE-like
> library for relatying and tracing I/O on the device via UART. Also,
> note that the emulator can now emulate a virtual console so it's
> already possible to build and interract with the firmware!
>
That's some really great news. A dev board will definitely be useful
for testing/debugging/developing Origami-EC!

> Cheers,
>
> Paul
>
>> > On Mon, Feb 5, 2018 at 9:47 PM, Youness Alaoui
>> > <kakar...@kakaroto.homelinux.net> wrote:
>> > > Hi Marty,
>> > >
>> > > Unfortunately, the EC firmware on the Librems is not open and we
>> > > have
>> > > someone working on that aspect, but with everything we have to
>> > > handle,
>> > > I think it's only being done part time.
>> > > We found something similar to you with the private submodule for
>> > > the
>> > > PS/2 module on the OLPC code.
>> > > More specifically :
>> > > http://lists.laptop.org/pipermail/openec/2011-January/000158.html
>> > > And http://dev.laptop.org/git/users/rsmith/ec-1.75/tree/?h=3930-A
>> > > 1
>> > >
>> > > I had opened a ticket a while ago here :
>> > > https://tracker.pureos.net/T178 which mentions Origami-EC. I
>> > > don't
>> > > know the status of that project, maybe you can contact the
>> > > developer
>> > > (Paul Kocialkowski) and see where he's at with his development of
>> > > that
>> > > project (which, I need to mention, hasn't been publicly launched
>> > > yet,
>> > > as far as I know) and he might benefit from your help if you are
>> > > interested in doing that.
>> > > The last time we spoke he said :
>> > > "The OLPC code is nowhere close to usable on any other platform.
>> > > Additionally, it is so poorly written that I don't think it is a
>> > > suitable codebase for any future development. On the other hand,
>> > > my
>> > > Origami-EC project (that I will publicly launch soon) should
>> > > provide a
>> > > flexible codebase to add support for new devices."
>> > >
>> > > Note that the tracker ticket above is quite outdated, we know how
>> > > to
>> > > dump the EC (the problem was that it can't be done via hardware
>> > > because the EC is on the same power rail as the 64KB flash chip,
>> > > so
>> > > when we power the flash via hardware, the EC boots and takes
>> > > control
>> > > of the SPI lines) but for some reason, we could only dump it via
>> > > software (using ectool) through the AMI BIOS firmware, with
>> > > cor

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

[Youness Alaoui]

On Tue, Feb 6, 2018 at 4:41 AM, Mike Banon <mikeb...@gmail.com> wrote:
> Thank you very much for telling about EC-1.75 project!
> http://dev.laptop.org/git/users/rsmith/ec-1.75/tree/?h=3930-A1
> Maybe some of its' elements could be borrowed for Origami
> if the hardware is similar? (haven't compared the datasheets)
>

There will probably be some things in common. I don't know how much of
ec-1.75 is good enough to be reused though, or if it's maintainable,
etc.. but yes, it could be a good starting point.

> @ Youness and Marty :
>
> Proprietary firmware of KB9012 explicitly disables EDI - ENE Debug Interface
> (the protocol used to access the internal memory of KB9012) unless pin
> 42 is grounded
> _before_ powering the KB9012 controller ! Maybe its the same with your
> another KB ?
> If you ground that pin (not necessarily 42, your KB's pin number could
> be different)
> to put your EC into debug mode, maybe then you could successfully
> read/write it ?
>
> Here is the full description of my successful KB9012 hardware flashing setup
> through the keyboard port using a flex cable with soldered wires: 0.5mm pitch
> makes it hard to solder directly to keyboard port, and also I like
> flex cable solution
> because its much faster to remove/insert a cable than to
> solder/desolder the wires
>
> http://dangerousprototypes.com/docs/Flashing_KB9012_with_Bus_Pirate
>
> ^^^ Had to unite three grounds ( programmer's, mainboard's and KB9012's 42 
> pin )
> to make it work
>
> Currently we are actively working on the inclusion of KB9012 flashing support
> to the official flashrom - but its already possible via the unofficial 
> patches.
> Changes 23258 - 23263 at the https://review.coreboot.org/#/q/project:flashrom
>
> I haven't compared the datasheets of KB9012 and your KB, so I don't know
> if they are using exactly the same debug interface or it is slightly different
> (please check if there are differences, maybe you'll have to write some code)
>
> I trust hardware flashing more than the software, especially your
> current AMI BIOS setup
> which isn't free software. Maybe the direct hardware flashing is also
> possible for you

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.

>
> Latest status update for Origami-EC firmware:
> https://www.mail-archive.com/coreboot@coreboot.org/msg50646.html

Thanks! Good to see the status update on that.

>
> Best regards,
> Mike Banon
>
> On Mon, Feb 5, 2018 at 9:47 PM, Youness Alaoui
> <kakar...@kakaroto.homelinux.net> wrote:
>> Hi Marty,
>>
>> Unfortunately, the EC firmware on the Librems is not open and we have
>> someone working on that aspect, but with everything we have to handle,
>> I think it's only being done part time.
>> We found something similar to you with the private submodule for the
>> PS/2 module on the OLPC code.
>> More specifically :
>> http://lists.laptop.org/pipermail/openec/2011-January/000158.html
>> And http://dev.laptop.org/git/users/rsmith/ec-1.75/tree/?h=3930-A1
>>
>> I had opened a ticket a while ago here :
>> https://tracker.pureos.net/T178 which mentions Origami-EC. I don't
>> know the status of that project, maybe you can contact the developer
>> (Paul Kocialkowski) and see where he's at with his development of that
>> project (which, I need to mention, hasn't been publicly launched yet,
>> as far as I know) and he might benefit from your help if you are
>> interested in doing that.
>> The last time we spoke he said :
>> "The OLPC code is nowhere close to usable on any other platform.
>> Additionally, it is so poorly written that I don't think it is a
>> suitable codebase for any future development. On the other hand, my
>> Origami-EC project (that I will publicly launch soon) should provide a
>> flexible codebase to add support for new devices."
>>
>> Note that the tracker ticket above is quite outdated, we know how to
>> dump the EC (the problem was that it can't be done via hardware
>> because the EC is on the same power rail as the 64KB flash chip, so
>> when we power the flash via hardware, the EC boots and takes control
>> of the SPI lines) but for some reason, we could only d

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

[Youness Alaoui]

Hi Marty,

Unfortunately, the EC firmware on the Librems is not open and we have
someone working on that aspect, but with everything we have to handle,
I think it's only being done part time.
We found something similar to you with the private submodule for the
PS/2 module on the OLPC code.
More specifically :
http://lists.laptop.org/pipermail/openec/2011-January/000158.html
And http://dev.laptop.org/git/users/rsmith/ec-1.75/tree/?h=3930-A1

I had opened a ticket a while ago here :
https://tracker.pureos.net/T178 which mentions Origami-EC. I don't
know the status of that project, maybe you can contact the developer
(Paul Kocialkowski) and see where he's at with his development of that
project (which, I need to mention, hasn't been publicly launched yet,
as far as I know) and he might benefit from your help if you are
interested in doing that.
The last time we spoke he said :
"The OLPC code is nowhere close to usable on any other platform.
Additionally, it is so poorly written that I don't think it is a
suitable codebase for any future development. On the other hand, my
Origami-EC project (that I will publicly launch soon) should provide a
flexible codebase to add support for new devices."

Note that the tracker ticket above is quite outdated, we know how to
dump the EC (the problem was that it can't be done via hardware
because the EC is on the same power rail as the 64KB flash chip, so
when we power the flash via hardware, the EC boots and takes control
of the SPI lines) but for some reason, we could only dump it via
software (using ectool) through the AMI BIOS firmware, with coreboot,
we only get 0xFF returned, I don't believe we had time to investigate
the cause for that.

Sorry for not having any better news for you, but I hope this helps a
little you at least.

Good luck,
Youness.


On Fri, Feb 2, 2018 at 10:17 AM, Marty E. Plummer
 wrote:
> Greetings,
>
> Currently working on a port for the hp g7-2247us laptop, which features
> an ene kb3940q ec, which hopefully should be very similar to the kb3930
> ec, which has a datasheet available to the public in a few places.
>
> Said similar ec is used in some OLPC devices, as well as some purism
> devices, and I was hoping someone in the list would have some contacts
> with those guys so as to be able to use their ec firmware as a bit of a
> reference design, but the OLPC ec firmware repo has a 'private'
> submodule which I cannot access and I simply cannot find a repo for the
> purism ec firmware to reference.
>
> Any assistance you could provide on this matter would be greatly
> appreciated.
>
> Marty E. Plummer
>
> --
> 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] Coreboot Purism BIOS is free? open?

[Youness Alaoui]

On Sat, Dec 23, 2017 at 11:32 PM, taii...@gmx.com  wrote:
> On 12/23/2017 07:16 PM, Todd Weaver wrote:
>
>> Intel did not mislead, we told them, and continue to, that we _want_ an
>> ME-less design (which is their term for what we asked for). And as we
>> grow our leverage will grow, and our influence will grow. This is a
>> long-term strategy and is playing out as planned.
>>
>> They will not adjust based on small quantities, but quantity =
>> leverage, and our influence changes as volumes grow. (e.g. $ =
>> influence)
>
> You will never have that type of leverage, if google can't pull it off then
> no one can.

Yeah, I agree with you on that, I don't think any leverage could make
Intel budge on that at this point.

>
> Even the NSA only got HAP, not a CPU without ME all together and the US
> government probably spends hundreds of millions with intel every year.
>
> x86-64 will always have ME/PSP and it simply can't be disabled, pretending
> otherwise is doing a disservice to many who look to the big shots for advice
> and pipe dreams like that being spread to the masses are the main reason I
> dislike purism so much.

You know of the ROM Bypass stuff, right? The first byte of the flash
contains a JMP instruction into the ROMB partition in the flash
(that's why the IFD magic number is at offset 0x10, not 0x0), so if
you put the right flag in the flash to enable ROM Bypass, then you
could get full unsigned/unchecked code (since the code in the ROM is
what checks signatures).
Now, that actually doesn't work because it's a feature that is
disabled on production chips, only pre-production chips allow the ROM
Bypass feature. What if someone finds a way to enable that feature on
a production chip ? What if you can make your CPU think it's in
preproduction mode thanks to some microcode update for example ? Then
you can get fully user controlled ME from the very first instruction.

I'm not saying it's possible or that it will be possible, but I'm
saying that it's not a "pipe dream" like you seem to think.
Even better, forget HAP, forget ROM Bypass, how about using the
exploit that PT announced at BlackHat to get your own unsigned code to
execute on the ME. You get full user control of the ME that way, and
while we know that the HAP bit happens at the end of the BUP module's
task, it's possible the exploit happens at the start (it does happen
when it tries to read a config file, so it could be early in the BUP).
The entire code from the first instruction all the way to the time the
exploit runs, could be reverse engineered, so even if you don't
control what happens there, you could at least have the source for it
and audit it to make sure it's not doing anything you wouldn't want it
to do, then have your exploit run and execute your own user controlled
ME firmware.
It's not an as perfect solution as being able to do a ROM Bypass and
control everything from the very first JMP, but it's something doable
today, it's not even a "maybe", so again, it's not a pipe dream.

>
> People will think "well gee why buy an actually-libre-right-now TALOS 2 when
> I can simply wait a few years when the eggheads have cracked ME and I can
> keep getting cheap soul-less computers" as tim said the discovery of HAP etc
> probably set back libre computing a decade.
>
> I hope you are buying a TALOS 2.

I think people buying a TALOS 2 and people buying a Librem are two
very distinct types of people. I very much doubt that someone has ever
had to decide between buying a Librem and a TALOS. No one in need of a
computer and in need of a open hardware machine will decide to "wait a
few years" either.. when you need a new PC, you buy a new PC. If you
want a TALOS, then you buy a TALOS, if you don't want it, or you want
a laptop, or if you don't have the budget for it, then you look
elsewhere, you're not going to just read some article and decide to
wait years without a computer in the hope that what you actually want
might be released by then.



> > > > A good summary is that we want to "bring
> > > > blob-free to the hardware that people want", rather than "bring
> > > > blob-free hardware to the people who want it".

> This is great; and I may quote you on that :)

Yeah, Todd, you can quote me. I also really liked that when I thought of it :p
And thanks for answering Nico's questions and correcting my
statements. I didn't even know an i.mx8 librem 13/15 had already been
thought of, that's pretty cool if it's in the plans!

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

Re: [coreboot] Coreboot Purism BIOS is free? open?

[Youness Alaoui]

On Sat, Dec 23, 2017 at 12:28 AM, Zoran Stojsavljevic
 wrote:
> Hello Youness,
>
> With all due respect, you write too long emails, trying to defend
> Purism. Lot of yours argument I do not buy.
> Some of them I do.
>
I know I write too long emails, a long time ago I stopped trying to
make them shorter, because I always fail. Some like to read them, some
won't read them, and that's ok.
I wasn't trying to defend Purism though, I was answering Taiidan's
questions. Maybe he'll accept the answers, maybe he'll disagree with
my answer, or maybe he won't bother to read the long email either.


> But, hey, this is what you/Purism have/has to offer, and this is a
> sort of fair deal. We all know what you are offering,
> in regards to x86, so let it be. Some people will buy Taiidan's facts,
> some yours, and some will stay in between.
>
Yes, there is a lot of choices for a lot of needs and the person
making the decision is the user, they decide what they want, so they
can't be wrong. I remember when Purism was even suggesting GluGlub on
the website as an alternative (a "non-competitor"). I think that was
taken down after some political conflict between Leah and us, i'm not
entirely sure though.

Have a nice weekend, happy christmas (if you care) and happy new year!

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

Re: [coreboot] Coreboot Purism BIOS is free? open?

[Youness Alaoui]

On Tue, Dec 19, 2017 at 8:04 PM, taii...@gmx.com <taii...@gmx.com> wrote:
> On 12/18/2017 01:59 PM, Youness Alaoui wrote:
>
>> As for Taiidan's response, I think Matt's response to it is pretty
>> good already, and I'm tired of seeing Taiidan jumping at the chance to
>> talk against Purism every chance he gets
>
> I simply want people to have all the facts before they spend thousands on a
> computer - as I have stated before you guys really need to change your
> marketing as it is confusing a lot of people.

First of all, I feel like this email is genuinely curious/humble
rather than hateful as I've had the impression in the past, so thank
you for that. That's why I decided to answer you, as I've previously
preferred not to. This response will probably be long though, so if
anyone reading here decides to TL;DR, that's perfectly fine by me.
The facts are there for people and I don't think that there is
anything wrong with the marketing. Some people might be confused but I
think that's unavoidable, no matter what we do or how we say things or
which things are put on the front, there will always be people who
will be confused.

>
> I of course would be more than happy to assist with this task, please
> remember *people are still going to purchase your products if your marketing
> is entirely up front and honest* - will you loose a few sales? of course,
> but it is better to do that then have unhappy customers.

That's your issue here, you think that the marketing is not honest,
but it is. It's not about losing sales or anything like that. You'd be
surprised to know just how many "unhappy customers" there are compared
to how many customers are actually happy about their devices. Other
than a couple of people (like you or Nico) who have stated that they'd
be unhappy with such a device, I haven't heard of anyone complaining.
I think that you are simply projecting your own needs or wants to a
much larger proportion of our customers. Would some people prefer a
100% open machine, yes, can they buy such a machine from somewhere
else, yes, did they misunderstand what the librem actually was when
they bought it, probably not.

>
> I humbly request:
> Remove "Libre" from the product names,

Now this is ridiculous (sorry) for multiple reasons. First of all, it
would be a nightmare to suddenly change a brand's name just to satisfy
one non-customer, and secondly, it makes no sense, the fact that the
device is called a Librem doesn't mean that it's open source hardware!
What's next, you will ask LibreOffice from refusing to install on any
hardware if they detect binary blobs on it ? Or that they remove
support for non libre document formats? Would you say that libreboot
should not be installed on laptops for which the schematics are not
open source ? etc..
The laptops are the "Librem series" they are not "The Libre hardware
series", and you need to differentiate between the two. The brand name
is not meant to trap customers either.

> Remove "every chip hand selected to respect privacy" (Intel chips do not do
> this),

This one, I kind of agree with you on it. I understand where it comes
from, it's about the peripherals, USB chip, webcam chip, the wifi
chip, the fact that the ethernet chip (on the previous models with
ethernet) was added instead of using the intel integrated one, etc...
So, yes, every chip is indeed hand selected to optimize the privacy
and security when an alternative is available, it is not however a
guarantee that the CPU itself is privacy-respecting. The sentence is
there to basically say "we are not a white-label reseller", but I do
agree with you that it can be (easily) interpreted to mean that the
intel CPU is privacy-respecting when it is not necessarily true.

> Clearly mention and define the difference between a coreboot device with FSP
> and one without in the product description

How and where? There is nothing clearer than the fact that coreboot
comes with binary blobs. We have written countless blog posts about
it, I regularly post progress updates, we have discussed which binary
blobs are present and what they do, we have a link somewhere to point
to the https://www.coreboot.org/Binary_situation page, it's even
actually mentioned that "we have yet to free the Intel FSP" in the
Roadmap page, this is not something that is hidden from customers by
any stretch of the imagination, and your statement makes it sound like
we're hiding this on purpose from the customers.
Would you also suggest to any manufacturer that sells laptops with
Ubuntu on them to specify that "Ubuntu is not really free software
because it has binary firmwares in it" ? No, because the important
part is that you're running Ubuntu, it doesn't matter that it has a
binary firmware file in it somewhere... this is the same thing, it
ships with coreboot, yeay, it has an open so

Re: [coreboot] Coreboot Purism BIOS is free? open?

[Youness Alaoui]

I think there is a plan to move librems to non-x86 architecture
eventually (considering that RYF is our long term plan, there is no
choice in moving out of x86 eventually), I think the efforts on the
risc-v front are the most promising and I think that's where the true
competition to x86 will be, but to be honest, I don't really follow,
understand or know much of anything that happens in the hardware space
since I'm a software guy at heart (i.e: all I know is that x86, ARM,
PPC and Risc-V use different instruction sets). I hear a lot about PPC
(with Talos for example), but I don't think PPC is as open as Risc-v
(ISA or something). All I know about PPC really is that it was fun to
reverse engineer during my PS3 days :)
Anyways, as far as I know, for risc-v, it's not there yet, so we're
waiting for that to be ready for the masses before moving to it. I
have absolutely no idea if it's "close" or if it's really a long term
plan for risc-v to be able to compete with x86 in terms of
performance/power usage/features/etc...

Note: this is not an official statement, I never really bothered to
ask in details about such things, I simply write code and yell at it
for not working...

As for the collaboration, again, I have no idea about any of the
business/manufacturing logistics, but if you think there's something
there that can be done, I suggest you contact Todd (I added him in CC)
and you could discuss things, he'll know what to answer you!

Thanks!

On Tue, Dec 19, 2017 at 3:54 PM, Timothy Pearson
<tpear...@raptorengineering.com> wrote:
>
> Thank you for the detailed explanation.  I guess this is an area in
> which experience matters; it is absolutely unacceptable (and not
> unexpected) that Intel misled your CEO, but this is sadly not an
> uncommon tactic in the industry.
>
> One item I would like to call out though is the following:
>
>> if old or non-x86 architectures were so appealing, you would have seen that 
>> become the norm rather than the exception)
>
> No one is denying that the easiest course of action for everyone would
> have been for Intel or AMD to release owner-controllable CPUs.  That
> being said, individuals and organizations needing privacy and owner
> control are /not/ their target market, nor are those entities Intel (or
> AMD)'s secondary (or even tertiary) market.  Both Intel and AMD rely on
> their lock-in and close association with Windows and related software to
> provide cheap, but wholly locked down, CPUs *by design*.  You could look
> at it as the hardware vendor simply providing a leased tool on which to
> run the leased software -- in such a market, cost trumps everything,
> owner control is looked at as "enabling piracy", and as a result x86 is
> not an appropriate platform for anyone needing control or privacy.
>
> In this environment, one must make a choice between convenience (x86)
> and owner control.  As you mentioned, the only middle ground is
> relegated to ancient computers, and that is not where we place any hope
> at all.  Trying to switch architectures may be hard, but it is only
> going to get harder day after day as people continue to cling to false
> hope that the x86 platform may ever be brought under their control.  The
> simple fact is, the purchaser of an x86 machine is not Intel or AMD's
> customer, nor are the ODMs.  Their primary customers, in an odd sort of
> way, are actually the software vendors that require x86 for their
> existing applications, and they are the ones that will call the shots on
> features or antifeatures in the x86 walled garden.
>
> I wonder, though, if given this information if possibly Raptor and
> Purism might have some common business ground here?  Purism has
> experience with laptop mechanicals and related concerns, and we have
> experience with truly blob-free, powerful hardware -- combining those
> two could yield an interesting machine...
>
> On 12/19/2017 02:41 PM, Youness Alaoui wrote:
>> On Tue, Dec 19, 2017 at 2:07 PM, Timothy Pearson
>> <tpear...@raptorengineering.com> wrote:
>> On 12/19/2017 11:51 AM, Dame Más wrote:
>>>>> I finished the University and I have free time to do things. And this
>>>>> seems like an interesting project to which I dedicate many hours.
>>>>>
>>>>> The truth is that I read a lot these days. The work you do kakaroto is
>>>>> impressive.
>>>>> In general Purism is doing something big, and I spoke ahead of time.
>>>>>
>>>>> I saw that in the directory
>>>>> coreboot/3rdparty/blobs/mainboard/purism/
>>>>> there is no content, it is right?
>>>>>
>>>>> Thanks
>>
>> The main question I have, and this is an honest question, is why Purism

Re: [coreboot] Coreboot Purism BIOS is free? open?

[Youness Alaoui]

On Tue, Dec 19, 2017 at 2:07 PM, Timothy Pearson
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 12/19/2017 11:51 AM, Dame Más wrote:
>> I finished the University and I have free time to do things. And this
>> seems like an interesting project to which I dedicate many hours.
>>
>> The truth is that I read a lot these days. The work you do kakaroto is
>> impressive.
>> In general Purism is doing something big, and I spoke ahead of time.
>>
>> I saw that in the directory
>> coreboot/3rdparty/blobs/mainboard/purism/
>> there is no content, it is right?
>>
>> Thanks
>
> The main question I have, and this is an honest question, is why Purism
> chose to use the x86 platform as a base for libre hardware, when it has
> been known for some time that said hardware could never be made fully
> blob-free?
>
> There were (and are) other good ways to make a system that could be
> fully blob-free, for instance ARM, and given the engineering effort that
> is said to have been put into the Purism machines I wonder what we could
> have had if said effort had been put into an aarch64 system instead of
> an x86 system?

That's a very good question and you're not the first one to ask it.

I think it's a combination of quite a few things. First, the fact that
I don't think there were any realistically powerfuly/competing
ARM/PPC/risc systems available at the time (or if there were, the
price would have been too high to make it a "security focused laptop
for everyone"). The purpose of Purism is not to satisfy a niche
market, but rather to be something everyone will want whether or not
they care about the security like we do, but which would still provide
them with that security that they need. I think even now, you can't
have an ARM device that could compete with an i7 in terms of
performance.

The second reason is that Todd (CEO) was in talks with Intel and was
unfortunately lead to believe that they were open to release an
ME-less design CPU for his needs, it ended up not being the case.

The last reason is because I think that through this discussion
(https://mail.coreboot.org/pipermail/coreboot/2014-August/078511.html)
Todd thought that it would be possible to get a binary blob free
coreboot/CPU with a few months of work. He didn't realize that it was
a much harder thing to achieve because the FSP takes a lot of time to
reverse engineer (remember, he thought he would have an ME-less CPU
from Intel), but from what I read in one of his answers, he had
already decided on x86 by the time he wrote that mail to the mailing
list, so I'm not sure if it really answers your question.

I think those that provide non-x86 (or pre-2008 x86) machines are
already there to fill the blob-free need, and it's not healthy to just
compete with them. A good summary is that we want to "bring blob-free
to the hardware that people want", rather than "bring blob-free
hardware to the people who want it".

Finally, I'll paste you one of my explanations from an email I sent
here last May, which kind of summarizes it all (from
https://mail.coreboot.org/pipermail/coreboot/2017-May/084166.html)

"[...], You ask why Purism doesn't just create laptops using FX2 or ARM or
whatever... Well, because that's not what most people want, out there. If
you want a RYF laptop using old or underpowered hardware or non-x86
architectures, that's a problem that has already been solved, there are
various resellers of such devices. The idea here is not to "Use what we can
find to make RYF" but rather "Bring RYF to the hardware that people want".
What I believe Purism is trying to do is to create a modern laptop for
*everyone* with the extra value of security and privacy, and in the process
make FLOSS appealing to mainstream instead of letting it be confined in a
niche. I think everyone will be better off with tools to protect their
privacy/security without asking them to throw the baby with the bathwater
by requiring them to use hardware that does not interest them (otherwise,
if old or non-x86 architectures were so appealing, you would have seen that
become the norm rather than the exception)."

I hope that fully answers your question.

Thanks!
Youness.


>
> - --
> 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
>
> iQEcBAEBAgAGBQJaOWOAAAoJEK+E3vEXDOFbBZEH/1loBwNG4m2ZrqmQ0qXRrYYy
> 9i+bMDTA/a85sPMWm870rJ2qG79Wy9s1w6P/qXIf3iFACDWWt5DpB6/NP6t8hjUp
> R9848GoBH2oCt0gO2Ydbt2ThGCP96q2JQoz2sz5Qo/CWXeBccTHZogA7CRc/u/zO
> Uj6qSTUUEoxt7Ul0AAoaT0UIYvJJoDjatKX61Rv96hA6RtDGib7nWZ+UwiuD3+wS
> iiYO+lkZzrhAprrLIH8Y58IMQ8RlQYRIguWQhmD5+A6I933Xyv81QTwonaDKATBC
> fwi3psMjmem4vg1pfJdBOowzMwx9ZItjjuvhPVkNfgpUP1gkZb+OQbFjounucaY=
> =iQzP
> -END PGP SIGNATURE-

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

Re: [coreboot] Coreboot Purism BIOS is free? open?

[Youness Alaoui]

Hi Dame,

The coreboot on Purism machines is indeed open and available, and it
is all merged into upstream coreboot, so there is no specific
repository for it other than the coreboot repository (the code is in
src/mainboard/purism/ subdirectory).
Here is the build script we use to build coreboot for our machines,
from scratch : 
https://forums.puri.sm/t/building-coreboot-from-source-official-script/1264
I haven't updated the build script in a while, so it's actually
building from here : https://code.puri.sm/kakaroto/coreboot.git but
those commits were merged upstream and the upstream coreboot
repository is all you need now.
Note that to disable the ME, we need to use the '-S -e MFS' option to
me_cleaner (the script also uses my own repository for me_cleaner, but
my patches to me_cleaner were also merged upstream, so you can just
use the upstream repository for me_cleaner. See my pull request here :
https://github.com/corna/me_cleaner/pull/70) .
You can read more about the efforts to disable the ME and the need for
the -e option by reading my blog post here :
https://puri.sm/posts/deep-dive-into-intel-me-disablement/
You said you want to implement coreboot for some 7th and 8th
generation Intel computers. Then you'd probably also be interested in
the blog posts I wrote about the porting experience. You can find all
my posts on the right sidebar of our coreboot timeline page here :
https://puri.sm/coreboot/timeline/
If you still have any questions, feel free to ask.

As for Taiidan's response, I think Matt's response to it is pretty
good already, and I'm tired of seeing Taiidan jumping at the chance to
talk against Purism every chance he gets, but I won't rant about that
today, I will only add this to the discussion :
* The original question was on whether our coreboot port was available
or not because the OP wanted to know how we disable the ME, you
completely missed the question and decided to give advice on what
device to buy instead...
* You seem to think that the purism laptops are selling at a premium
because it comes with coreboot? I'm pretty sure that the Cost/MSRP
margin is the same or lower than from other laptop manufacturers, the
"premium" you'd pay is because of the low volume of machines we are
making, Dell/Lenovo can of course sell for lower prices because they
get economy of scale, which we don't. It's not because we are
increasing our revenue and using coreboot as an excuse to do it.
* You said "they are charging for a whitebox re-brand.", that's
actually a completely false statement, the motherboard is our own and
it is designed to avoid having any firmware-based hardware so a
binary-blob-free linux distribution can run on it. It is not a
whitebox re-brand. If it was a whitebox re-brand, then yeah, we'd be
selling for a lot lower price considering we'd be able to also take
advantage of the economies of scale.
* You are encouraging the purchase of lenovo machines, but as far as I
know, lenovo is not actively working on reverse enginering the FSP.
Also, the only reason that Lenovo can have a libreboot running on it
is because the community did the port, not because the company itself
is working towards freeing it or investing anything to provide more
freedom to users. So yeah, sure, you could say "don't pay a 30$
premium for coreboot, buy a lenovo and do the port yourself" (assuming
you know how to do the port, or you buy one that is already ported) ,
but you might as well say "don't pay a 30$ premium for coreboot, buy a
lenovo, do the port yourself, then reverse engineer the FSP yourself
while you're at it" and it would be more accurate. And that's of
course ignoring the question of the harware kill switches, the fact
that you can't compare a 200$ refurbished laptop from 6 years ago with
a higher priced laptop from today, or that lenovo won't answer you if
you ask tech support questions on coreboot or linux, etc...
* We worked on disabling the ME on the purism laptops. Yes, the lion's
share of the work was done by others (Corna for me_cleaner and
Positive Technologies for the HAP bit), but not only did it require a
significant amount of work from our side as well, to test, validate
and package the ME disablement work (see above blog post link), but we
are the first manufacturer to offer it standard and without us doing
it, it could be argued whether or not this differentiation would have
convinced System76 and Dell to also pursue offering machines with the
ME disabled. So, encouraging those who are trying to pioneer the work
might actually help the entire community. Do you think it might
convince Intel to offer ME-less designs if they see half the
manufacturers starting to ship unofficially-disabled ME machines ?
Maybe, maybe not, but at least someone is trying to move things along
instead of only complaining about the status of things.

I could go on, but I think that's enough.

Hopefully, this helps clarify the situation.

Thanks,
Youness.

On Mon, Dec 18, 2017 at 4:07 AM, Dame Más 

Re: [coreboot] Black screen during SeaBIOS boot

[Youness Alaoui]

Try a 'cbmem -t' to see how long coreboot itself took to boot. There
might be some delay somewhere causing it to take longer to boot
(current system I'm on, it takes 8 seconds, and on other systems I saw
it take 15 seconds, because it waits for the ME to respond until it
times out) so it might not all be seabios' fault.
Also I just tried removing the VGABIOS and setting Coreboot to run the
GOP driver, and I got a black screen in seabios (even in grub, screen
shows text only after linux boots and inits the driver I think). I'd
suggest you try the proper vgabios and no GOP driver, just to see if
it helps, then see what happens without the vgabios.
Note: i only have one VGA device here.

On Fri, Dec 15, 2017 at 12:59 PM, awokd via coreboot
 wrote:
> On Fri, December 15, 2017 11:10 am, Daniel K wrote:
>
>> Starting up with coreboot and SeaBIOS, the screen is completely black for
>> around 30 seconds before my on-disc bootloader (grub2) is loaded and
>> displayed.
>>
>> I'm assuming SeaBIOS counts down with some timer before launching the
>> on-disc bootloader but I don't see anything.
>>
>> I want to use coreboot in text-mode so I'm not including a VGA rom.
>
> That might be why you are getting the delay. Try adding it and see. I ran
> into the delay too and think that's what fixed it.
>
>> According to lspci (attached), I have two VGA devices:
>
> You might need to edit src/device/Kconfig with:
>
> config MULTIPLE_VGA_ADAPTERS
> bool
> default y
>
>
>
> --
> 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] Disabling Intel ME 11 via undocumented mode

[Youness Alaoui]

In my opinion, the ME is indeed disabled because the entire ME
functionality is disabled, no ME processes are running, and the kernel
on its own is irrelevant, even if it keeps running.
However, I do not have anymore a strong counter opinion to your
statement that you don't consider the ME to be disabled as I
originally did.
It all depends on how we choose to see it, I consider it to be
disabled, and you consider that it's not. It will always differ on
each person's interpretation of the definition of the word "disabled".

All I could find online about the actual definition of the word
"disabled" is either :
* related to a person, in which the definition is "having a physical
or mental condition that limits movements, senses, or activities."
* related to a device or a mechanism in which the definition is either :
  * "rendered inoperative (as by being damaged or deliberately
altered)" (Merriam-Webster dictionary)
  * "not in proper working order; out of commission" (Collins dictionary)

The definition of "To disable" is better as it has more meanings
("disabled" has the majority of definitions related to a disabled
person) :
  * "put out of action" (Oxford dictionary)
  * "to make ineffective or inoperative" (Merriam-Webster dictionary)
  * "To deprive of capability or effectiveness, especially to impair
the physical abilities of." (The Free Dictionary)
  * "to stop a machine or piece of equipment from working properly"
(The MacMillian dictionary)
  * "If someone or something disables a system or mechanism, they stop
it working, usually temporarily." (The Collins dictionary)
  * "to make ineffective, unfit, or incapable, as by crippling" (The
Collins dictionary)
  * "to switch off (an electronic device)" (The Collins dictionary)

I believe that the ME is "disabled" according to all but the last of
these definitions. The ME 11.x with the HAP bit is rendered
ineffective, it's deprived of functionality and it's not working
properly, etc.. The definition which does not match the current status
is the "to switch off", which is not the case here and which is
probably the definition (or close to it) that you have in your mind
when you think of the word "disabled".

So again, like I said, I believe it it disabled and I don't think I'd
be convinced that it's not, but if you say that you don't think it's
disabled, I won't disagree with you either, I'll simply assume you see
things differently. Hopefully, you are also able to understand that
when I say the ME is disabled, it's not because of a desire to
mislead. I believe therefore that we are both right in our
interpretations.
FYI, for me "limited" means that it retains some functionality, but
not all, like for example, the Consumer version of the ME is a limited
ME when compared to the Corporate version. In our case, no
functionality is left, so I can't consider it merely as being limited.
You could say it's limited because the 'kernel functionality' remains,
but I don't see the kernel as a feature, so for me, it doesn't work.

Thanks for reading!
Youness.


On Thu, Dec 14, 2017 at 11:15 AM, Timothy Pearson
<tpear...@raptorengineering.com> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Thank you for the detailed response; I figured there had to be some
> basic miscommunication somewhere. :-)  So I assume we now agree that the
> ME on Sylake + is not disabled, merely limited?
>
> On 12/14/2017 01:20 AM, Youness Alaoui wrote:
>> Hi,
>>
>> From the PT article you linked to, after the stage 5 of BUP execution :
>> "It is at this stage that we find HAP processing; in this mode, BUP
>> hangs instead of executing InitScript. This means that the remaining
>> sequence of actions in normal mode has nothing to do with HAP and will
>> not be considered. The main thing we would like to note is that in HAP
>> mode, BUP initializes the entire platform (ICC, Boot Guard) but does
>> not start the main ME processes."
>>
>> As for the kernel, that's my mistake, I remembered that prior to ME
>> 11.x, the KERNEL module was removed by me_cleaner, and BUP was the
>> first process loaded. I hadn't realized that the execution order
>> changed in ME 11.x, and that explains why the KERNEL module cannot be
>> removed by me_cleaner in ME 11.x.
>> On ME 10.x and lower, the BUP module was the first executed, and it
>> would then load the KERNEL, so if BUP is halted before it did that,
>> then the kernel doesn't run. In ME 11.x however, they changed the
>> order, the KERNEL module is first to be loaded, but it only starts the
>> BUP process :
>> "The first process that the kernel creates is BUP, which runs in its
>> own address

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

[Youness Alaoui]

Hi,

>From the PT article you linked to, after the stage 5 of BUP execution :
"It is at this stage that we find HAP processing; in this mode, BUP
hangs instead of executing InitScript. This means that the remaining
sequence of actions in normal mode has nothing to do with HAP and will
not be considered. The main thing we would like to note is that in HAP
mode, BUP initializes the entire platform (ICC, Boot Guard) but does
not start the main ME processes."

As for the kernel, that's my mistake, I remembered that prior to ME
11.x, the KERNEL module was removed by me_cleaner, and BUP was the
first process loaded. I hadn't realized that the execution order
changed in ME 11.x, and that explains why the KERNEL module cannot be
removed by me_cleaner in ME 11.x.
On ME 10.x and lower, the BUP module was the first executed, and it
would then load the KERNEL, so if BUP is halted before it did that,
then the kernel doesn't run. In ME 11.x however, they changed the
order, the KERNEL module is first to be loaded, but it only starts the
BUP process :
"The first process that the kernel creates is BUP, which runs in its
own address space in ring-3. The kernel does not launch any other
processes itself; this is done by BUP itself"
So, you are right, on Skylake+ (ME 11.x), the kernel would be running
but the BUP process is the one halted and no other processes get
launched, but on ME 10.x and lower, the kernel wouldn't be running
since BUP is loaded first (this is true for me_cleaned ME 10.x, and
I'm not sure what exactly the MeAltDisable flag does, which is the
equivalent of HAP on previous versions, but there wasn't any specific
research done on that).

I hadn't realized that until now when researching an error-free
response to you, so thanks for helping me notice that mistake in my
understanding.

Youness.



On Wed, Dec 13, 2017 at 12:54 PM, Timothy Pearson
<tpear...@raptorengineering.com> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> According to Positive Technologies, on Skylake and higher (like the
> Purism machines) the kernel loads the BUP, and the HAP bit only disables
> the normal userspace processes [1].
>
> What proof do you have that the kernel itself is halted?
>
> [1] http://blog.ptsecurity.com/2017/08/disabling-intel-me.html
>
> On 12/13/2017 11:34 AM, Youness Alaoui wrote:
>>> I guess I still disagree with the use of the word "disabled".  If the ME
>>> wasn't required for boot, and was actually disabled within a few cycles
>>> of its CPU starting, the remaining attack surface simply wouldn't exist.
>>>  This is not what happens though, and AFAIK even the ME kernel continues
>>> to run since the ME needs to continue handling platform power events.
>>> If this many holes are present in even the ROM code, then having the ME
>>> kernel running remains a massive security problem.
>>>
>>
>> I'm just going to answer the bit about the use of the term "disabled".
>> I've explained it in my blog post before (here if you missed it :
>> https://puri.sm/posts/deep-dive-into-intel-me-disablement/) but I do
>> believe the ME is in this case Disabled. What you are thinking about
>> is what I called "Removed". The reason it's called disabled is because
>> the ME stops running, it's not actively doing anything, it doesn't
>> respond to HECI, it doesn't even boot into the kernel. You said that
>> "the ME kernel continues to run", but that's not the case. The entire
>> ME core stops execution during the bring-up phase, so it's technically
>> disabled because it stops itself at some point after boot.
>> Having the ME *removed* would be interesting because that would mean
>> that even the bring up phase wouldn't get executed and we could remove
>> the entire ME firmware from the flash. But that still wouldn't mean
>> that nothing runs on the ME core because there is still some small
>> code embeded in the ROM.
>> Anyways, that's my justification on why using the term "disabled" is
>> valid in this case when HAP is enabled. You are free to disagree if
>> that didn't convince you.
>
>
> - --
> 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
>
> iQEcBAEBAgAGBQJaMWk6AAoJEK+E3vEXDOFbTnkH/30CN22Q0JG0bxxvG7NaRjUX
> i4bsAVpdP+rbd9IlmMHDCPtYnmdoBWq81yXZx8iBAzTx5DJrU0lA0Kqr0RzIyNRx
> pE4omRU2St342bQS5bf/UsFwT2WKR2vlE8u8NR4YiOXnJNySJ1gSQqzxB4uGwd7I
> rcyMnScr4IKEgwiE3GA7HU4vHE2w66M6g0skhYQtquAm3ypajmwLUbFwsgiAp0l1
> Azbt9pUFlp7McZTJusuRroWsDv1oOWQit3nH54i0yP6EajGWbZJ4+sAEQJSXVr9Q
> 6iuVDE8WfZsydARlvfM+hc0TyrGIv08EnLkhNOQjA4bfab6TxK1l2EnNE1STwXc=
> =7rNS
> -END PGP SIGNATURE-
>
> --
> 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] Disabling Intel ME 11 via undocumented mode

[Youness Alaoui]

> I guess I still disagree with the use of the word "disabled".  If the ME
> wasn't required for boot, and was actually disabled within a few cycles
> of its CPU starting, the remaining attack surface simply wouldn't exist.
>  This is not what happens though, and AFAIK even the ME kernel continues
> to run since the ME needs to continue handling platform power events.
> If this many holes are present in even the ROM code, then having the ME
> kernel running remains a massive security problem.
>

I'm just going to answer the bit about the use of the term "disabled".
I've explained it in my blog post before (here if you missed it :
https://puri.sm/posts/deep-dive-into-intel-me-disablement/) but I do
believe the ME is in this case Disabled. What you are thinking about
is what I called "Removed". The reason it's called disabled is because
the ME stops running, it's not actively doing anything, it doesn't
respond to HECI, it doesn't even boot into the kernel. You said that
"the ME kernel continues to run", but that's not the case. The entire
ME core stops execution during the bring-up phase, so it's technically
disabled because it stops itself at some point after boot.
Having the ME *removed* would be interesting because that would mean
that even the bring up phase wouldn't get executed and we could remove
the entire ME firmware from the flash. But that still wouldn't mean
that nothing runs on the ME core because there is still some small
code embeded in the ROM.
Anyways, that's my justification on why using the term "disabled" is
valid in this case when HAP is enabled. You are free to disagree if
that didn't convince you.

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

Re: [coreboot] What’s the release plan for coreboot 4.7?

[Youness Alaoui]

Hi,

What happened with the plan for the 4.7 release? I thought it was
supposed to be out at the end of October, now we're approaching the
end of November.
Was it forgotten, delayed or cancelled ? If delayed, what's the
blocking issue ?

Thanks,
Youness.

On Wed, Oct 4, 2017 at 11:24 AM, Martin Roth  wrote:
> The release will happen towards the end of the month.   Generally I
> try to have the release scheduled a bit before the month ends so
> there's a little room to slip. I'll sit down this weekend and start
> sorting out where we are and send out another email with release
> plans.
>
> If there are any bugs in the bug tracker that people would
> specifically like help with getting fixed before the next release,
> please reply here.
>
> If developers could take a look at coverity and see if there are any
> issues there that they can fix, that would be great.
>
> Please start testing any boards that you have and uploading the
> results to the board-status repo so we know what's working.  If you
> have boards that don't boot, please reply here, and try to bisect the
> issue to find where it stopped working.
>
> Martin
>
>
>
> On Tue, Oct 3, 2017 at 9:33 AM, Paul Menzel
>  wrote:
>> Dear coreboot folks,
>>
>>
>> It’s October and coreboot 4.7 is supposed to be tagged in this month.
>>
>> Are there more specific plans already, when the release will happen?
>>
>>
>> Thanks,
>>
>> Paul
>> --
>> 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 mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] greetings and laptop questions

[Youness Alaoui]

> While I understand your frustration, and agree with the general thrust
> of your email, and disregarding the "10 years", the Samsung Chromebook
> Plus (and many other devices of similar age) beg to differ.
> There are devices from 2016 and 2017 shipping with coreboot and no CPU
> level blobs in the firmware (the only CPU side blob would be the
> kernel's GPU driver).

Sorry, I'm so deep into Intel stuff right now that I completely missed
the possibility of non-x86 hardware. Yes, there is newer hardware with
no blobs in coreboot, my statement is only true for intel-related
hardware. I don't even know about AMD actually, but I believe it's a
similar situation for AMD. But in the case of the Chromebook Plus, I
checked, and it's an ARM based CPU, which is why coreboot is blob free
for it.
The original post was about a laptop to run virtual machines, so I
assume x86 is a requirement, but my statement was about coreboot
itself, not about the laptop requirement, which made it false. Thanks
for the correction!



>
> Please keep the dimension right, newest is Ivy Bridge and that is 5
> years old.

My bad, you're right. The '10 years old' was in reference to ME-less
CPU designs and I confused it with FSP-less coreboot.
As for the ivybridge being the newest, that's again my bad, I used
this to look up when the native intel raminit stopped being supported
;
https://www.coreboot.org/Intel_Native_Raminit#Sandybridge.2FIvybridge
and it said sandybridge/ivybridge, and I thought they were the same,
not one being successor of the other.

I guess that will teach me to email while I'm tired and busy/distracted.



>
>> The original email asked about a
>> coreboot port, not a libreboot port. Every time I see purism
>> mentioned, you have to jump in to insult and dishonestly say that
>> Purism is dishonest. If you want to claim bullshit like that, at least
>> find something real and concrete to back it up. I've ignored you many
>> times, but I'm fed up of your one-man vendetta against Purism. What
>> happened to you for you to have so much hate against us?
>
> It's not him alone, you might remember our discussion about it (it
> ended with you writing poems that I didn't even had the time to read
> in the end, please don't do that again).

You're not hateful from what I could see. You disagree with Purism and
you don't like it, but I haven't seen you jumping at every occasion to
talk bad about it.
As for our last discussion, that's what it was, a discussion, which
unfortunately, I got a little over-verbose in my last response and
killed the discussion, but I don't feel like Taiidan wants to discuss
anything. Either way, I don't plan on opening any new discussions
about Purism here.

>
>>
>> Extremely funny how you then say that System76 is "a fine choice"
>> considering that System76 doesn't even come with coreboot, and even if
>> it did come with coreboot, it would of course, still depend on the
>> FSP. Also, System76 hardware depends on components which do require
>> binary blobs, as opposed to Purism laptops, so I don't get why
>> System76 is "a fine choice" if Purism isn't.
>
> It's pretty simple, System76 seems to advertise what say sell, Purism
> doesn't. I'd say they do most things right, but not the advertisement.
> Most Linux supporting vendors are honest about their products. Yet,
> Purism makes claims such as:
>
>"Only by selecting each and every chip in our Librem laptops can
> we guarantee your privacy, security and freedom are protected."
>
> Where I still argue, it's the opposite with Intel inside.
>
> Everything else, they seem to do alright. I'd fully support them if
> they'd stop the false advertisement of being super secure. They are
> not, just a little better than the rest (by hardware design, don't
> know about the details of their software and how secure the hard-
> ware is configured).
>
> So my conclusion, Purism draws customers from other Linux supporting
> vendors with dishonest marketing. If that doesn't bother you, fine.
> But please don't get angry if it bothers honest people.

I disagree with your statement that it's false advertisement and that
it's dishonest marketing. I won't explain why I think you're wrong
here, because :
1 - I already explained it in length in my previous long email that
you never read
2 - It doesn't market itself as "being super secure" as you said, but
rather as being "security and privacy focused", which it is. You are
free to find anywhere on the website where it says security or privacy
without stating "a focus on" or "-focused" along with it.
2 - It's my opinion/interpretation and you have a different one, and
that's fine, you are entitled to it. Your view/interpretation of a
statement does not mean everyone needs to see it your way and that the
conclusion that it's being dishonest which your drew from it, is going
to be the absolute truth.
3 - By stating that it "bothers honest people", right after saying
that it doesn't bother me, you're implying that I'm 

Re: [coreboot] greetings and laptop questions

[Youness Alaoui]

On Sun, Oct 8, 2017 at 6:15 PM, taii...@gmx.com  wrote:
>
>>
>> (I also am looking at system76 and Purism but I am bit leery of spending a
>> lot with a small / new company - comments appreciated)
>
> Purism dishonestly markets their products - while they claim that their
> laptops "respect freedom and privacy" their version of coreboot is nothing
> more than a wrapper layer for intel FSP (binary blob that does all the
> hardware init) which is next to pointless for the amount of money you would
> spend on one as all it does is move trust from vendor to OEM not avoiding
> the hypothetical OEM firmware backdoors.
>
> System76 is a fine choice if all you want is a laptop that runs linux
> without difficulty.
>

I don't get why you constantly try to discredit Purism and insult
everything we do. You complain about coreboot being "useless" because
it uses FSP, but you fail to mention that anything using coreboot will
use the FSP unless it's 10 year old hardware (Sandybridge is the
latest FSP-free supported CPU). The original email asked about a
coreboot port, not a libreboot port. Every time I see purism
mentioned, you have to jump in to insult and dishonestly say that
Purism is dishonest. If you want to claim bullshit like that, at least
find something real and concrete to back it up. I've ignored you many
times, but I'm fed up of your one-man vendetta against Purism. What
happened to you for you to have so much hate against us?

Extremely funny how you then say that System76 is "a fine choice"
considering that System76 doesn't even come with coreboot, and even if
it did come with coreboot, it would of course, still depend on the
FSP. Also, System76 hardware depends on components which do require
binary blobs, as opposed to Purism laptops, so I don't get why
System76 is "a fine choice" if Purism isn't.

To answer Jim, the Purism Librem 15 doesn't support 32 GB of RAM, but
it does run coreboot and will come with a disabled ME (blog post
announcing that is pending). If you need a laptop which runs linux
without the need for any of the binary firmware blobs (firmware-linux
package in debian), where the company is actively working on
eliminating the remaining blobs in the system (the ME, the FSP and
VGABIOS) then you might want to look at Purism, if you don't care
about those issues and/or require 32GB of RAM (which our laptops don't
support), then you should discard Purism from your list of choices and
look for something else.

I hope that helps.
.

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

Re: [coreboot] SPI Flash debug console on H8SCM

[Youness Alaoui]

Hi Fabian,

It was ported to older intel architectures by Nicola Corna here :
https://review.coreboot.org/#/c/21107/
I don't know what would need to be done to port it to work with amd,
but in theory, all it needs is for the chipset to support SPI
operations. If it can read and write to the spi flash for the purposes
of the mrc.cache, then it should be easy to make it work.
The real work to port it to other architectures was pretty much only
to make sure the spi controller doesn't use global variables so it
could be included in the bootblock and romstage.

Good luck.
Youness.


On Fri, Sep 15, 2017 at 12:40 PM, Fabian  wrote:
> Hi everyone,
>
> I try to get coreboot run on my H8SCM. Sadly I get no log over serial or USB. 
> So I want to give SPI console a try. It seems to be a very new feature 
> introduced here [1].
>
> When I compile coreboot it fails with this warning:
> warning: (CPU_SPECIFIC_OPTIONS && CPU_SPECIFIC_OPTIONS && 
> CPU_SPECIFIC_OPTIONS && CPU_SPECIFIC_OPTIONS && CONSOLE_SPI_FLASH) selects 
> BOOT_DEVICE_SPI_FLASH_RW_NOMMAP_EARLY which has unmet direct dependencies 
> (SPI_FLASH && BOOT_DEVICE_SPI_FLASH_RW_NOMMAP)
>
> As written in [1] it's only tested for Skylake. How much effort is necessary 
> to port it to my board? Are there more Information about SPI console? Or is 
> there an other way to get log from my board?
>
> One more question to the AMD experts: There are two motherboard models 
> "H8SCM" and "H8SCM (Fam10)". Whats the difference?
>
> Greetings,
> Fabian
>
> [1] https://mail.coreboot.org/pipermail/coreboot/2017-June/084538.html
>
> --
> 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

[SeaBIOS] [PATCH] hw/nvme: Enable NVMe support for non-qemu hardware

[Youness Alaoui]

I submitted this a while back (April 25th) here :
https://review.coreboot.org/#/c/19443/
And I was just told that it wasn't the right place for it! So I'm
sending you an updated patch to enable NVMe.
I noticed that this was already submitted on May 10th by Kevin
O'Connor (https://mail.coreboot.org/pipermail/seabios/2017-May/011356.html)
but the patch was incomplete, so I've updated mine to mention it.
Patch is inlined below for review.

Thanks!
Youness.


>From ff8e3f40cbf5a4cc6035635ae23462505265a74a Mon Sep 17 00:00:00 2001
From: Youness Alaoui <youness.ala...@puri.sm>
Date: Tue, 25 Apr 2017 11:21:05 -0400
Subject: [PATCH] hw/nvme: Enable NVMe support for non-qemu hardware

NVMe support was tested on purism/librem13 laptops and SeaBIOS has
no problems in detecting and booting the drives.

This is a continuation of commit 235a8190 which was incomplete.

Signed-off-by: Youness Alaoui <youness.ala...@puri.sm>
---
 src/hw/nvme.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/hw/nvme.c b/src/hw/nvme.c
index 1c2bce5..11583ad 100644
--- a/src/hw/nvme.c
+++ b/src/hw/nvme.c
@@ -599,7 +599,7 @@ nvme_cmd_readwrite(struct nvme_namespace *ns,
struct disk_op_s *op, int write)
 int
 nvme_process_op(struct disk_op_s *op)
 {
-if (!CONFIG_NVME || !runningOnQEMU())
+if (!CONFIG_NVME)
 return DISK_RET_SUCCESS;

 struct nvme_namespace *ns = container_of(op->drive_gf, struct
nvme_namespace,
-- 
2.4.11

___
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios

Re: [SeaBIOS] [PATCH] hw/nvme: Enable NVMe support for non-qemu hardware

[Youness Alaoui]

Thanks! And sorry, seems I registered using one email address and sent
the patch using another.

On Mon, Jun 12, 2017 at 9:12 PM, Kevin O'Connor <ke...@koconnor.net> wrote:
> On Mon, Jun 12, 2017 at 05:53:24PM -0600, Youness Alaoui wrote:
>> I submitted this a while back (April 25th) here :
>> https://review.coreboot.org/#/c/19443/
>> And I was just told that it wasn't the right place for it! So I'm
>> sending you an updated patch to enable NVMe.
>> I noticed that this was already submitted on May 10th by Kevin
>> O'Connor (https://mail.coreboot.org/pipermail/seabios/2017-May/011356.html)
>> but the patch was incomplete, so I've updated mine to mention it.
>> Patch is inlined below for review.
>
> Thanks.  I committed this.
>
> -Kevin

___
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios

[coreboot] SPI Flash debug console

[Youness Alaoui]

Hi everyone,

I mentioned this during my presentation at the coreboot conference
last week, and I was waiting for it to be merged before I announced it
on the mailing list.

For those of you working on recent hardware (this was tested on
skylake only, for broadwell to work, we need to add the spi controller
to romstage and convert it to use CAR_GLOBAL, I don't know about other
archs), if you don't have a debug header, or if you don't want to go
through the trouble of soldering on UART pads or you just don't have
any easy access to the debug console, then you can enable the "SPI
Flash console output" option in the Console menu.
It will automatically add an area to the FMAP which will contain your
console log. After you turn on the machine, you can dump the SPI flash
and use cbfstool to get the full console log :
cbfstool coreboot.rom read -r CONSOLE -f console.log

The console log will contain all stages including the bootblock and
romstage, so it's useful to debug memory init issues. Since most of us
debugging coreboot on new mainboards will already have our external
SPI flasher hooked up, we can just read the rom before writing a new
one to it and get the log at the same time.

Note that the console log will not be reset on poweroff/reboot, it
will continue to grow until the whole area is full, at which point it
will stop writing anything to the flash. This is to avoid excessive
SPI writes in case you forget to disable the option once you get the
machine booting.

That's it, I hope it's useful to someone else!

Thanks to Matt DeVillier and Aaron Durbin for helping
debug/test/review the implementation.

Youness.

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

Re: [coreboot] Denver conference

[Youness Alaoui]

lol, I don't know, but I assumed we need to go to a registration desk
and get the https://www.coreboot.org/Denver2017#Goodies and I assumed
a lanyard is included in there :p How else will you know who I am?! :p

On Thu, Jun 1, 2017 at 3:51 PM, Matt DeVillier <matt.devill...@gmail.com> wrote:
> On Thu, Jun 1, 2017 at 2:46 PM, Youness Alaoui
> <kakar...@kakaroto.homelinux.net> wrote:
>>
>> Then I suppose once they arrive at the conference registration booth
>> to get their lanyard, they'll be told hat they haven't paid yet and
>> that they can pay now in cash (and credit cards?). Not that
>> complicated :)
>
>
> wait -- we get lanyards this year?  sweet!

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

Re: [coreboot] Denver conference

[Youness Alaoui]

Then I suppose once they arrive at the conference registration booth
to get their lanyard, they'll be told hat they haven't paid yet and
that they can pay now in cash (and credit cards?). Not that
complicated :)

On Thu, Jun 1, 2017 at 3:39 PM, Zoran Stojsavljevic
<zoran.stojsavlje...@gmail.com> wrote:
> Good. Two reasons here:
> [1] The email delivery is not reliable (very seldom reason, 0.1%).
> [2] The list of attendees are not filled correctly, so for double checking
> Coreboot email list is used. ;-)
>
> What if somebody (who applied) does NOT belong to Coreboot list? ;-)
>
> Zoran
>
> On Thu, Jun 1, 2017 at 9:31 PM, Youness Alaoui
> <kakar...@kakaroto.homelinux.net> wrote:
>>
>> If you registered for the conference, and didn't receive the invoice
>> to pay the conference attendance fees, then let Martin know that you
>> didn't receive the invoice. If you received it, then pay it and that's
>> it.
>>
>> On Thu, Jun 1, 2017 at 2:35 PM, Zoran Stojsavljevic
>> <zoran.stojsavlje...@gmail.com> wrote:
>> >> If you are planning on attending and have not received these emails,
>> >> please let me know immediately so we can get you accounted for.
>> >
>> > Not sure if I understood logic behind this email... What are other
>> > (parallel) means of communications here??? So, let say, I did not get
>> > the
>> > email with the important notification, so I should let somebody know for
>> > something I do not know??? Based upon what else??? Hm Brm!
>> > ;-)
>> >
>> > Zoran
>> >
>> > On Thu, Jun 1, 2017 at 7:44 PM, Martin Roth <gauml...@gmail.com> wrote:
>> >>
>> >> Everyone who is attending the Denver conference should have gotten an
>> >> invoice from the Software Freedom Conservancy, and an email about the
>> >> conference from me.
>> >>
>> >> If you are planning on attending and have not received these emails,
>> >> please let me know immediately so we can get you accounted for.
>> >>
>> >> Thanks.
>> >> Martin
>> >>
>> >> --
>> >> 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 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] Denver conference

[Youness Alaoui]

If you registered for the conference, and didn't receive the invoice
to pay the conference attendance fees, then let Martin know that you
didn't receive the invoice. If you received it, then pay it and that's
it.

On Thu, Jun 1, 2017 at 2:35 PM, Zoran Stojsavljevic
 wrote:
>> If you are planning on attending and have not received these emails,
>> please let me know immediately so we can get you accounted for.
>
> Not sure if I understood logic behind this email... What are other
> (parallel) means of communications here??? So, let say, I did not get the
> email with the important notification, so I should let somebody know for
> something I do not know??? Based upon what else??? Hm Brm! ;-)
>
> Zoran
>
> On Thu, Jun 1, 2017 at 7:44 PM, Martin Roth  wrote:
>>
>> Everyone who is attending the Denver conference should have gotten an
>> invoice from the Software Freedom Conservancy, and an email about the
>> conference from me.
>>
>> If you are planning on attending and have not received these emails,
>> please let me know immediately so we can get you accounted for.
>>
>> Thanks.
>> Martin
>>
>> --
>> 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 mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] GPIO PADRSTCFG conflict in datasheet

[Youness Alaoui]

Hi,

I just found this file here :
https://github.com/IntelFsp/FSP/blob/Skylake/SkylakeFspBinPkg/Include/GpioConfig.h
It defines the reset values for GPIO in this enum :
typedef enum {
GpioResetDefault = 0x0, ///< Leave value of pad reset unmodified
GpioResetPwrGood = 0x1, ///< GPP: RSMRST; GPD: DSW_PWROK; (PadRstCfg =
00b = "Powergood")
GpioResetDeep = 0x3, ///< Deep GPIO Reset (PadRstCfg = 01b = "Deep GPIO Reset")
GpioResetNormal = 0x5, ///< GPIO Reset (PadRstCfg = 10b = "GPIO Reset" )
GpioResetResume = 0x7 ///< GPP: Reserved; GPD: RSMRST; (PadRstCfg =
11b = "Resume Reset" )
} GPIO_RESET_CONFIG;

We can see it specifically says that 00b is "GPP: RSMRST; GPD:
DSW_PWROK" and 11b is "GPP: Reserved; GPD: RSMRST". So I'm leaning
towards the datasheet not having a typo, but rather they just have
different values for RSMRST depending on whether it's GPP or GPD, so I
vote for changing the define in coreboot so it stops being confusing
for those who want to use RSMRST.

I'll send a patch shortly to do it as I suggested in my previous
email, unless someone else has a better idea.

Thanks,
Youness.


On Thu, May 18, 2017 at 2:56 PM, Youness Alaoui
<kakar...@kakaroto.homelinux.net> wrote:
> Hi,
>
> I'm working on a skylake port and I've noticed something with the PADRSTCFG
> field of the GPIO Pad configuration. If you look at the 100-series datasheet
> volume 2
> (https://www-ssl.intel.com/content/www/us/en/chipsets/100-series-chipset-datasheet-vol-2.html).
> The Pad configuration DW0 for GPP_A, GPP_B, GPP_C, etc.. (page 1179, 1249)
> up to GPP_I (page 1319) has bits 31:30 (PADRSTCFG) defined like this :
> 00 = RSMRST#
> 01 = Host deep reset.
> 10 = PLTRST#
> 11 = Reserved
>
> But the Pad configuration DW0 for GPD pads (page 1296) has it defined like
> this :
> 00 = DSW_PWROK
> 01 = Host deep reset.
> 10 = PLTRST#
> 11 = RSMRST#
>
> The problem here is that while the DEEP and PLTRST values are the same, the
> RSMRST value is 0 for GPP gpio pads, and 3 for GPD gpio pads. In the skylake
> and apollolake gpio_defs.h file, it is defined like this (with different
> naming for apollolake but same values) :
> #define  PADRSTCFG_DSW_PWROK 0
> #define  PADRSTCFG_DEEP 1
> #define  PADRSTCFG_PLTRST 2
> #define  PADRSTCFG_RSMRST 3
>
> These defines are only valid for GPD pads, if someone was to use a RSMRST
> reset config on a GPP pad, they would be setting the pad to a 'reserved'
> configuration, which could have unexpected behavior.
> There are two possibilities here, either the datasheet is wrong (and PWROK
> should be 3 so the RSMRST value is consistent for both GPP and GPD), or the
> datasheet is correct, and in both cases, the value in coreboot is wrong.
>
> If someone from Intel is reading this list, or if someone here knows someone
> inside Intel who could confirm whether or not the datasheet has an error,
> that would be great.
> In the meantime, I would maybe suggest to change the defines to  :
> #define PADRSTCFG_GPD_RSMRST3
> #define PADRSTCFG_GPP_RSMRST0
>
> This would affect both skylake and apollolake, and note that the only
> skylake+ boards that use RSMRST seem to be the kblrvp in the rvp7 variant
> which sets it for GPP_A12 and GPP_E3 (which means those two gpios have the
> wrong setting due to the wrong define).
>
> What do you think ?
>
> Thanks,
> Youness.

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

Re: [coreboot] VGA rom doesn't work

[Youness Alaoui]

Congratulations on getting the ME working again.
Your VGA device is 8086,1616, so that's what you need to set. The
8086,0406 is probably just the default one in coreboot, but you still
have to configure it.
In 'make menuconfig', go to Devices menu and set the "VGA Device ID"
to "8086,1616", then recompile, and it will work.
I had the exact same issue . Search for "VGA" in this blog post to
read about it (I didn't say much about it other than what I just said)
: https://puri.sm/posts/librem-13-coreboot-report-february-3rd-2017/

Good luck,
Youness.

On Wed, May 24, 2017 at 7:50 PM, Alejandro Flores  wrote:
> Now that my ME problem is solved I turn to another problem.
>
> The video bios does not seem to function. During seabios boot screen no
> video is displayed. Only when grub auto loads does the video start.
>
> When I use cbfstool auron_yuna.bin print
> it shows pci8086,0406.rom at offset 0x7004c0
>
> However when I check lspci -n it shows an address of 8086:1616 for pci
> device 00.02.0 VGA compatible controller.
>
> Which of these should I use for coreboot VGA device PCI ID?
>
> --
> 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] GPIO PADRSTCFG conflict in datasheet

[Youness Alaoui]

Hi,

I'm working on a skylake port and I've noticed something with the PADRSTCFG
field of the GPIO Pad configuration. If you look at the 100-series
datasheet volume 2 (
https://www-ssl.intel.com/content/www/us/en/chipsets/100-series-chipset-datasheet-vol-2.html).
The Pad configuration DW0 for GPP_A, GPP_B, GPP_C, etc.. (page 1179, 1249)
up to GPP_I (page 1319) has bits 31:30 (PADRSTCFG) defined like this :
00 = RSMRST#
01 = Host deep reset.
10 = PLTRST#
11 = Reserved

But the Pad configuration DW0 for GPD pads (page 1296) has it defined like
this :
00 = DSW_PWROK
01 = Host deep reset.
10 = PLTRST#
11 = RSMRST#

The problem here is that while the DEEP and PLTRST values are the same, the
RSMRST value is 0 for GPP gpio pads, and 3 for GPD gpio pads. In the
skylake and apollolake gpio_defs.h file, it is defined like this (with
different naming for apollolake but same values) :
#define  PADRSTCFG_DSW_PWROK 0
#define  PADRSTCFG_DEEP 1
#define  PADRSTCFG_PLTRST 2
#define  PADRSTCFG_RSMRST 3

These defines are only valid for GPD pads, if someone was to use a RSMRST
reset config on a GPP pad, they would be setting the pad to a 'reserved'
configuration, which could have unexpected behavior.
There are two possibilities here, either the datasheet is wrong (and PWROK
should be 3 so the RSMRST value is consistent for both GPP and GPD), or the
datasheet is correct, and in both cases, the value in coreboot is wrong.

If someone from Intel is reading this list, or if someone here knows
someone inside Intel who could confirm whether or not the datasheet has an
error, that would be great.
In the meantime, I would maybe suggest to change the defines to  :
#define PADRSTCFG_GPD_RSMRST3
#define PADRSTCFG_GPP_RSMRST0

This would affect both skylake and apollolake, and note that the only
skylake+ boards that use RSMRST seem to be the kblrvp in the rvp7 variant
which sets it for GPP_A12 and GPP_E3 (which means those two gpios have the
wrong setting due to the wrong define).

What do you think ?

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

Re: [coreboot] Remote security exploit in all 2008+ Intel platforms

[Youness Alaoui]

Thanks Peter, well said! I enjoyed that little graphic too :)
@Taiidan, I hadn't thought of PAVP, but the idea is to remove/neutralize
the ME entirely, not to intercept its messages.  If we take control of the
ME, we'll probably just call 'halt' to make sure that core is disabled. I
don't see how that affects the DMCA.
Either way, the DMCA exception is still there for our purposes, even if
that wasn't what we were doing.
As for your FX-2 idea, I already explained my thoughts on that.

@Nico, Thanks for a civil and interesting response, I'll reply inline to
your comments below, but a disclaimer, the things I'm saying below are my
own opinions and interpretations on things, and a lot of it is based on
things I've heard. The accuracy of what I heard, which is often a second
hand account of events, may not be 100%, so keep that in mind.

On Wed, May 3, 2017 at 3:45 PM, Nico Huber <nic...@gmx.de> wrote:

> On 03.05.2017 01:39, Youness Alaoui wrote:
> > to answer Nico's other post:
> > I'm quite surprised and disappointed by your answer. You have every right
> > to say that you are disappointed or distrusting Purism due to past
> actions,
> > but I find it harsh for you to be repeatedly saying "fraud" and "scammed"
> > when that is not the case at all. I think Ron has responded quite well to
> > that and said exactly what I wanted to say, there is a difference between
> > being naive and underestimating the task, vs actively "trying to scam
> > people". If they were scamming people, they wouldn't have shipped any
> > product and they wouldn't have reimbursed those who changed their mind or
> > were unsatisfied with what they got, and actually, I wouldn't even have
> > been contracted in the first place.
>
> Finally! I was hoping for some statement like this. I didn't know about
> any reimbursement taking place. See, what was publicly visible was some
> drawing of customers away from free firmware supporting vendors. Amend-
> ments were not publicly visible, FWIW. OTOH, the way you wrote it im-
> plies that only those who complained got a refund, or was the reimburse-
> ment an explicit offer?
>

Yes, there were reimbursements. How the reimbursements have taken place, I
don't know, but I know that some got refunds, some got upgrades,
downgrades, sidegrades, etc.. depending on what the customer wanted. I know
that Purism has been struggling for a bit (one of the reasons most of the
employees are volunteers) as it was lacking funds (hence the recent
kickfurther for the v2 stock). Customers who had the highest requirements
and expectations for the touchpad requested reimbursements and got them.
The original campaign promised a great touchpad experience, unfortunately
the touchpads of the first batches of laptops (before the one currently
being made) did have limitations. While those touchpads do work, they're
not the ultimate user experience, and Purism hasn't had the time and
resources to work on fixing that driver (I was originally going to reverse
engineer the BYD driver, but instead I was thrown into working on
coreboot).
I don't have any other details on how it happened, it it was an explicit
offer, if there are conditions, etc.. If you're curious, you can drop in
#purism and ask your questions, I'm sure there are people more
knowledgeable than me that can answer you.


> > Attributing to malice what was the result of honest mistakes, while you
> > know how complex this is both on the software and hardware side, is why
> > your tone was disappointing. Careless name-calling leads to people
> getting
> > hurt and flame wars and all that.
>
> Carelessly promising free software (that is impossible to deliver) with
> the name of free projects on it... I think that was a huge offense to
> many developers. Don't you think that hurt people too? So don't tell me
> I started this.
>
>

I never said you started anything, and yes, using some FOSS project's
reputation to boost your own by association when there really wasn't any
contribution is cause for anger and disappointment, I never said otherwise
either. The only thing that I said is that there's a difference between
being naive and making unintentional mistakes versus being a scammer and
intentionally misleading people. Eventually people have to forgive past
mistakes, especially if they were unintentional and efforts are made to
move things in the right direction (which it is now afaik). I agree with
you though that past mistakes have to be owned up by those who made them,
and apologies should be made. You (and everyone else) doesn't owe Purism
anything, so you don't have to accept their excuses either, but it's just
better when everyone is on good terms I think.
Like I told you in my first email, you have every right to be disappointed
and mistrusting of Purism due to their past mis

Re: [coreboot] Will we maintain Skylake/FSP1.1?

[Youness Alaoui]

I thought FSP 1.1 was for skylake and FSP 2.0 for Kabylake, I didn't
realize 2.0 would be compatible with skylake too. Does this mean a skylake
port could use fsp 1.1 or 2.0 ? In that case, is the 2.0 version better
maintained, more stable, easier to integrate, etc.. or are both 1.1 and 2.0
implementations equivalent at this point?
I also don't see the 2.0 release in https://github.com/IntelFsp/FSP/ so I
assume getting my hands on it would mean grabbing it from somewhere else

Thanks,
Youness.

On Tue, May 9, 2017 at 11:19 AM, Aaron Durbin  wrote:

> On Tue, May 9, 2017 at 10:14 AM, Nico Huber 
> wrote:
> > Hi,
> >
> > I was walking through the Skylake FSP1.1 support in coreboot and asked
> > myself if it is worth to clean it up and maintain the code? given that
> > the upcoming release of Kabylake FSP should be able to supersede it (I
> > presume it is?). Are there any plans yet to drop it once the next FSP
> > is released? (when will that be anyway?)
>
> I wanted to get rid of it, but Intel claimed they had customers using it
> still.
>
> >
> > Btw. does anybody feel like a maintainer for soc/intel/skylake/?
>
> Personally feel? Or want?
>
> >
> > In it's current state it's very hard to use from a mainboard porter's
> > point of view. Many of the selectable Kconfig settings are useless
> > (either don't compile or don't run) for FSP1.1, and there's a `struct
> > pei_data` [1] that seems to be a remnant of compatibility for a dif-
> > ferent blob ;)
>
> That's just an old remnant of passing data around. It could be removed
> as you annotated isolating those pieces to different structs and/or
> variables for passing data around. The name is obviously not
> applicable w.r.t. its current use.
>
> >
> > Best regards,
> > Nico
> >
> > PS. Microcode updates are also missing in the upstream blobs repo. Is
> > that a licensing problem? If I try to download them from Intel, it
> > asks me to click to accept that I'll prevent further distribution.
> > I could prepare a patch to add them but somebody else would have
> > to sign it off.
> >
> > [1] https://review.coreboot.org/#/c/19638/
> >
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] PCIe Role-based error reporting

[Youness Alaoui]

Hi,

I'm looking at the src/device/pciexp_device.c file trying to understand
what it does and I've noticed this in pciexp_enable_aspm :
/* Enable ASPM role based error reporting. */
devcap = pci_read_config32(endp, endp_cap + PCI_EXP_DEVCAP);
devcap |= PCI_EXP_DEVCAP_RBER;
pci_write_config32(endp, endp_cap + PCI_EXP_DEVCAP, devcap);

This looks like it tries to write a bit to 1 to enable Role-based
error-reporting in the DEVCAP (offset 0x04) in the PCIe capability, but
according to the spec (looking at page 612 of the spec version 3.0 that I
found here  :
http://composter.com.ua/documents/PCI_Express_Base_Specification_Revision_3.0.pdf),
that structure is read-only (it's the device capabilities register, not the
device control register).
Is that an error ?
I tracked that code (moved, then moved again) all the way to this change
from 2011 : https://review.coreboot.org/#/c/735/ but for some reason git
blame can't find the file in commits before that.

That code is probably harmless since it's a Read-only field anyways, but
I'm wondering if the code that should be there shouldn't instead be
enabling the bits 0:3 in the device control register to enable the error
reporting. Also, I don't see how this actually relates to ASPM (it only
gets called if ASPM is enabled).

Does anyone know if I'm on the right track in my interpretation or if I
misunderstood the spec or what that code is meant to do ?

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

Re: [coreboot] Remote security exploit in all 2008+ Intel platforms

[Youness Alaoui]

Looks like I failed at answering Taiidan without generating a flame war.
Sorry if anyone got offended, that wasn't my aim.
To answer the various questions that were thrown, here's what I think :

Taiidan, you ask why Purism doesn't just create laptops using FX2 or ARM or
whatever... Well, because that's not what most people want, out there. If
you want a RYF laptop using old or underpowered hardware or non-x86
architectures, that's a problem that has already been solved, there are
various resellers of such devices. The idea here is not to "Use what we can
find to make RYF" but rather "Bring RYF to the hardware that people want".
What I believe Purism is trying to do is to create a modern laptop for
*everyone* with the extra value of security and privacy, and in the process
make FLOSS appealing to mainstream instead of letting it be confined in a
niche. I think everyone will be better off with tools to protect their
privacy/security without asking them to throw the baby with the bathwater
by requiring them to use hardware that does not interest them (otherwise,
if old or non-x86 architectures were so appealing, you would have seen that
become the norm rather than the exception).

As for the ME and DMCA, I believe this exempts us from it :
https://www.ftc.gov/news-events/blogs/techftc/2016/10/
dmca-security-research-exemption-consumer-devices
...Considering that the research is done in order to protect users. Also,
an exploit to run a custom firmware on the ME isn't something that gives
access to copyrighted material, so I'm not sure why the DMCA would even
apply here.
As for your argument of an arms race and Intel "fixing" the weaknesses
allowing us to neutralize the ME, I don't see how that would matter either,
because you will be able to control the image on your own machine
*today*... if you neutralize it today, even if Intel wanted to take over
the ME in your system to patch it, well... they can't get in, because you
already neutralized it. And if they want to change it for future models,
they will have to change it in the silicon of future models, which is way
out in the future.

To answer Sam:
Thanks for the kudos! The reason C is used is because I didn't think to use
anything else. I love C and that's what I like to use. But beyond that
answer, there are many reasons for using C. It's because this is an
assembly to C translation, if the code is 'prone to errors' it's only
because the original ME binary instructions had those errors in it, which
is good for us, since we're looking for exploits. Also, the long term goal
is to be able to generate binary-compatible images (imagine, you compile
the ME source and get a binary with the same hash as the one intel is
providing, so you can be 100% sure that it's the same code that you're
auditing as the one that is running). If we were to use any high level
language, we would never have enough fine control over the resulting binary
to be able to get binary compatibility.

Zoran: Thanks for your comments and encouragement! :) the talks with Intel
as far as I know are not for open-sourcing the ME (which is a much harder
thing to ask for), but rather for a ME-less design. Basically, for Intel to
release a chip with the ME core simply disabled and with no firmware
running on it. That's a much easier goal to attain, but then again, we're
talking about Intel, so it's still a difficult goal to attain, but Todd has
been bugging them for a while and is constantly in talks with Intel to try
and achieve that.


to answer Nico's other post:
I'm quite surprised and disappointed by your answer. You have every right
to say that you are disappointed or distrusting Purism due to past actions,
but I find it harsh for you to be repeatedly saying "fraud" and "scammed"
when that is not the case at all. I think Ron has responded quite well to
that and said exactly what I wanted to say, there is a difference between
being naive and underestimating the task, vs actively "trying to scam
people". If they were scamming people, they wouldn't have shipped any
product and they wouldn't have reimbursed those who changed their mind or
were unsatisfied with what they got, and actually, I wouldn't even have
been contracted in the first place.

Attributing to malice what was the result of honest mistakes, while you
know how complex this is both on the software and hardware side, is why
your tone was disappointing. Careless name-calling leads to people getting
hurt and flame wars and all that.

I would just like to answer you with a few more items that I believe are
true (I may be mistaken myself as I'm still quite new to Purism):

   - Everything that was promised is still on the roadmap and a
   work-in-progress (as far as I know), so it's more of an issue of missing
   the deadlines/estimates rather than not wanting to deliver anything that
   was promised. The "Vision" of the company in an initial crowdfunding
   campaign does not mean "this is an immediately attainable milestone".
   - The 

Re: [coreboot] Remote security exploit in all 2008+ Intel platforms

[Youness Alaoui]

On Mon, May 1, 2017 at 7:22 PM, taii...@gmx.com  wrote:

> On 05/01/2017 06:44 PM, ron minnich wrote:
>
> On Mon, May 1, 2017 at 1:17 PM Rene Shuster 
>> wrote:
>>
>> Yes Puri.sm has been debunked.
>>>
>>> I disagree. I've seen the systems. From what I can see, Puri.sm has made
>> a
>> good faith effort to go as far possible *with modern x86 chipsets* toward
>> getting rid of the blobs. They can't get to 100%, but they're trying to
>> get
>> as close as possible.
>>
>> ron
>>
> Name one thing that they have done themselves?
>
> https://www.reddit.com/r/linux/comments/3anjgm/on_the_librem
> _laptop_purism_doesnt_believe_in/ (yeah its leah but shes right about the
> coreboot community being corrupted)
>
> Everything they "do" is someone elses code, and their "coreboot" has zero
> actual init code it is entirely blobbed.
>
> Their marketing is the only thing that is good.
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>

Without entering into a flamewar, you're asking "name one thing that they
have done themselves" and I will answer that.
Full disclaimer: I am working for Purism, and I have been a paid contractor
working since last December (part time initially, full time since March) on
bringing coreboot and the ME-disablement effort to the Librem line of
laptops (more precisely Librem 13 v1, and now working on the Librem 13 v2
hardware which is set to be released/shipped next month).

First, here's a timeline of the coreboot work explained here :
https://puri.sm/coreboot/timeline/
That timeline mentions for example that the original port was made by
coreboot developers (which seems to be a huge scandal for some reason)
after Purism donated 4 laptops for that work.
You can also read my blog posts on what exactly I have done (in great
detail) in order to bring coreboot to the Librem (from the "I'm a total
n00b" to the "I'm still a n00b but slightly less") :
https://puri.sm/posts/diving-back-into-coreboot-development/
https://puri.sm/posts/librem-13-coreboot-report-january-12-2017/
https://puri.sm/posts/librem-13-coreboot-report-february-3rd-2017/
https://puri.sm/posts/librem-13-coreboot-report-february-25th-2017/
https://puri.sm/posts/preventing-interference-from-the-old-bios-while-flashing-coreboot/
There's also a pretty big article about NVMe issues that I'm (currently)
fixing, which is half-written and which I'd be happy to send you the link
to once it's published.

Ron couldn't be more right when he says that you can't appreciate how much
work it is to go from a "it works" to a "it's tested/verified and made into
a *product* for actual users". It took me 6 months of work to finish the 4
days of work that Duncan Laurie did (I believe it took him 4 days to do the
initial port, feel free to correct me if I'm mistaken, and yes of course, I
am totally new to the coreboot world, so a lot/most of that time was spent
on the learning curve).

You can also see my actual contributions to coreboot (and one unmerged to
SeaBIOS) here : https://review.coreboot.org/#/q/owner:%22Alaoui%22
I have also contributed in the past couple of weeks to flashrom by
reviewing and commenting in Nico Huber's branch which adds Skylake support
to flashrom : https://review.coreboot.org/#/q/topic:intel_chipset_support

Now that was the coreboot work that was done, here is the ME work that was
done :
While the me_cleaner was tested and verified to work on the Librem (see
here:
https://puri.sm/posts/neutralizing-intel-management-engine-on-librem-laptops/),
the actual work of me_cleaner was done by someone else, but the testing and
verification was still done by us, I think that counts for something. Also
note that an advantage of the librems here is that they come unfused which
is what allows me_cleaner to work on them (see
https://puri.sm/learn/intel-me/). Any laptop with the boot guard fuse
enabled will shut down immediatly if the ME is cleaned with me_cleaner.

For actual ME-related work that wasn't done by someone else, I will point
you to this file :
https://github.com/kakaroto/purism-playground/blob/master/me_re/romp.c
That is a full C re-implementation of the ROMP module (the smallest of the
two modules that me_cleaner does not remove).
This is the RAPI header it uses :
https://github.com/kakaroto/purism-playground/blob/master/me_re/rapi.h
That code is a C reimplementation with every instruction accounted for. It
has not been compiled (it serves more as a proof of concept/pseudocode,
although it should probably compile), and it's not meant to generate a
binary-compatible file (that could be a long term goal to generate binary
compatible images from C source with official intel-provided images).
Note that I have done the entire Assembly->C conversion myself, but I do
want to give credit to Igor Skochinsky for his help (which saved me
weeks/months of work) as he shared his notes of his ME reverse engineering
efforts (memory 

Re: [coreboot] Intel ME The Way of the Static Analysis

[Youness Alaoui]

Thanks for the links.
This is the article that I had seen :
http://blog.ptsecurity.com/2017/04/intel-me-way-of-static-analysis.html


On Tue, Apr 25, 2017 at 10:38 AM, Shawn  wrote:

> slide:
> https://www.troopers.de/downloads/troopers17/TR17_ME11_Static.pdf
>
> video:
> https://www.youtube.com/watch?v=2_aokrfcoUk
>
> --
> 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] [VERY IMPORTANT] Announcement regarding Apollo Lake Coreboot building

[Youness Alaoui]

Zoran,

The blog post is not meant to be documentation, it's just a progress report
and a *blog post* about the experience and I'm sure it's much less
confusing than your emails have been so far.
in menuconfig, in the Chipset section, there's "Add Intel descriptor.bin
file" (which is what you had enabled, causing the build to fail) and under
it, there is "Path and filename of the descriptor.bin file", you set it
there.
You'll also probably need to extract and include the ME region as well, and
clone the blobs repository for the microcode updates to be generated from
tree.
Apart from that, I suggest you be careful with what you're doing to avoid
bricking your device, learn what you can about the process, read
documentation and even read the code if you need to. Randomly thinking that
there's a "very important announcement" because you didn't understand how
to compile coreboot (and then refusing to give your config and telling
developers to look into this 'bug' without giving any more information) is
not really the way to incite people to help you.

Good luck
Youness.

On Thu, Feb 23, 2017 at 10:29 AM, Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> wrote:

> Hello Youness (and others),
>
> Here, I need to apologize to all Coreboot recipients. Since it was a
> while, I did peak into that. But... It is NOT You(ness). You got my
> attention, and, since you blog is very confusing (lack of  some systematic
> knowledge) about INTEL BSP Technology.
>
> I really admire your effort. And just because of that I (after some 6+
> hours of investigation) I'll try to strengthen out your logs, which are, I
> should say, puzzled, scrambled all over place. Pieces of Truth are there,
> and you got on the right path. Although... Labyrinth (unsorted kludges and
> facts) for most of folks.
>
> *I did NOT expect that ... will make out of this Rocket Science.* And
> yes, they did make it??? Why, that is the question? ;-)
>
> I got it. Not quite up to ground level (I need to understand more about
> make menuconfig setup). But in order to make (example) 8MB Coreboot, you
> need to take the TRUE APL-I BIOS and to apply IFD tool, in order to extract
> first 4K (4096) File Descriptor. And SBIOS part as well. Not sure how many
> parts should be extracted?!
>
> Here is what GOOGLE designers posted for Emerald Lake 2, in 3rdparty:
>
> [user@localhost emeraldlake2]$ ls -al
> total 2120
> drwxrwxr-x. 2 user user4096 Feb 18 01:57 .
> drwxrwxr-x. 3 user user4096 Feb 18 01:57 ..
> -rw-rw-r--. 1 user user   4096 Feb 18 01:57 descriptor.bin
> -rw-rw-r--. 1 user user   2093056 Feb 18 01:57 me.bin
> -rw-rw-r--. 1 user user   65536 Feb 18 01:57 snm_2120.dat
> [user@localhost emeraldlake2]$ pwd
> /home/intel/projects/coreboot/coreboot/3rdparty/blobs/mainbo
> ard/intel/emeraldlake2
> [user@localhost emeraldlake2]$
>
> And, for descriptor.bin, there is the following:
>
> [image: Inline image 1]
>
> This (location 0x0010) I have checked with many BIOSes found on the
> open net, . Most, but I did not find any instance of Apollo Lake, to build
> proper Coreboot.com.
>
> So, I need to extract at least SBIOS and descriptor.bin from real (UEFI)
> BIOS, and put, where?
>
> And then, to add to the Coreboot image. Using make menuconfig. Where and
> how?
>
> (Courtesy Aaron Durbin): http://elinux.org/Minnowboard:MinnowMaxCoreboot#
> TXE_and_SPI_descriptor
>
> Thank you all,
> Zoran
>
> On Thu, Feb 23, 2017 at 12:30 AM, Youness Alaoui <
> kakar...@kakaroto.homelinux.net> wrote:
>
>> Zoran, read this : https://puri.sm/posts/librem
>> -13-coreboot-report-january-12-2017/
>> It might help you understand what that IFD and 0x5aa5f00f is (little
>> endian makes it 0x0FF0A55A)
>> I had the same confusion when I started, and when I figured things out, I
>> wrote that blog post that explained the process.
>>
>>
>> On Wed, Feb 22, 2017 at 11:51 AM, Zoran Stojsavljevic <
>> zoran.stojsavlje...@gmail.com> wrote:
>>
>>> So, the final word here: In building of INTEL skus' Coreboot INTEL FIT
>>> tool (under NDA) is A MUST/mandatory, and INTEL is the road block if you
>>> are not working with them (having the NDA signed with them)?
>>>
>>> What about the concept of an Open Source??? ;-)
>>>
>>> I am at this point very confused... Really, I am. I did NOT find
>>> anywhere in any document that for Coreboot building INTEL FIT is
>>> mandatory???
>>>
>>> Thank you,
>>> Zoran
>>>
>>> On Wed, Feb 22, 2017 at 5:40 PM, Aaron Durbin <adur...@google.com>
>>> wrote:
>>>
>>>> On Wed, Feb 22, 2017 at 10:18 AM, Zoran Sto

Re: [coreboot] [VERY IMPORTANT] Announcement regarding Apollo Lake Coreboot building

[Youness Alaoui]

Zoran, read this :
https://puri.sm/posts/librem-13-coreboot-report-january-12-2017/
It might help you understand what that IFD and 0x5aa5f00f is (little endian
makes it 0x0FF0A55A)
I had the same confusion when I started, and when I figured things out, I
wrote that blog post that explained the process.


On Wed, Feb 22, 2017 at 11:51 AM, Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> wrote:

> So, the final word here: In building of INTEL skus' Coreboot INTEL FIT
> tool (under NDA) is A MUST/mandatory, and INTEL is the road block if you
> are not working with them (having the NDA signed with them)?
>
> What about the concept of an Open Source??? ;-)
>
> I am at this point very confused... Really, I am. I did NOT find anywhere
> in any document that for Coreboot building INTEL FIT is mandatory???
>
> Thank you,
> Zoran
>
> On Wed, Feb 22, 2017 at 5:40 PM, Aaron Durbin  wrote:
>
>> On Wed, Feb 22, 2017 at 10:18 AM, Zoran Stojsavljevic
>>  wrote:
>> > Aaron,
>> >
>> > Not that I am trying to be pest/bad guy. Please, believe me on this.
>> Just
>> > about the simple logic, which SHOULD NOT be deniable!
>> >
>> > I did what I know about Coreboot, hands on, from 3.3 years ago. Then, I
>> > built the VERY first Emerald Lake 2 (CCG CRB) -> Cougar Canyon 2 CRB as
>> > payload SeaBIOS, and WIN 8.0 32bit. I was really amazed. Then.
>> >
>> > And I read much more these days, and a bit emailed with Martin
>> (forth/back),
>> > so Martin can give me a jump start. And then I read more. And more. And
>> for
>> > 5 full days I was doing this exercise (with lot of pain).
>> >
>> > So, I'll quote you:
>> >
>> >> That file is the FSP blob. Nothing more. As Nico pointed out that is
>> >> something completely different from the flash descriptor. The flash
>> >> descriptor can be obtained from the original released BIOS or you have
>> >> to generate it using Intel's FIT tool.
>> >
>> > Please, guide me through this process. Or point to some documents about
>> this
>> > process I can read about?
>>
>> IIRC, FIT is provided by Intel to its customers under NDA. You'll have
>> to contact your Intel rep for that. It's quite the barrier to entry
>> for using these devices, but that's a policy decision from Intel.
>>
>> Or you can take a previously released bios for this board and do
>> similar as the instructions on the Minnow Max page:
>> http://elinux.org/Minnowboard:MinnowMaxCoreboot#TXE_and_SPI_descriptor
>>
>> Note, TXE/CSE on apollolake does not have its own region in the flash.
>> It's in something intel calls IFWI and has its own new format that
>> lives in the "BIOS" region. There's a tool (util/cbfstool/ifwitool.c)
>> which takes an existing image with the IFWI and makes it work with
>> coreboot's implementation/support for apollolake.
>>
>> >
>> > Thank you,
>> > Zoran
>> >
>> > On Wed, Feb 22, 2017 at 5:05 PM, Aaron Durbin 
>> wrote:
>> >>
>> >> On Wed, Feb 22, 2017 at 10:01 AM, Zoran Stojsavljevic
>> >>  wrote:
>> >> > I can admit my errors:
>> >> >
>> >> > This is what I have:
>> >> >
>> >> > user@localhost FspBin]$ pwd
>> >> >
>> >> > /home/user/projects/coreboot/coreboot/APL-I_FSP/ApolloLakeFs
>> pBinPkg/FspBin
>> >> > [user@localhost FspBin]$ ls -al
>> >> > total 672
>> >> > drwxr-xr-x. 2 user user   4096 Feb 11 12:19 .
>> >> > drwxr-xr-x. 6 user user   4096 Feb 11 12:19 ..
>> >> > -rw-r--r--. 1 user user 136832 Feb 11 12:19 ApolloLakeFsp.bsf
>> >> > -rw-r--r--. 1 user user 540672 Feb 11 12:19 ApolloLakeFsp.fd
>> >> > [user@localhost FspBin]$
>> >> >
>> >> > I use one in RED.
>> >> >
>> >> > Need the clarification. Please, do it for me.
>> >>
>> >> That file is the FSP blob. Nothing more. As Nico pointed out that is
>> >> something completely different from the flash descriptor. The flash
>> >> descriptor can be obtained from the original released BIOS or you have
>> >> to generate it using Intel's FIT tool.
>> >>
>> >> >
>> >> > Zoran
>> >> >
>> >> > On Wed, Feb 22, 2017 at 4:56 PM, Nico Huber 
>> >> > wrote:
>> >> >>
>> >> >> On 22.02.2017 08:12, Zoran Stojsavljevic wrote:
>> >> >> > Hello to community,
>> >> >> >
>> >> >> > I finally, after 3 days of additional very hard struggle, found
>> out
>> >> >> > why
>> >> >> > I
>> >> >> > have (while I am in the last stage of building CBFS) nonsense
>> while
>> >> >> > building APL-I Coreboot coreboot.rom?!
>> >> >> >
>> >> >> > Please, read carefully this announcement.
>> >> >> >
>> >> >> > For last three days I came to hard stop because of this failure:
>> >> >> >
>> >> >> > Just quick look into the final failure (all passed, but last
>> stage -
>> >> >> > IFD
>> >> >> > failed):
>> >> >> >
>> >> >> > Compile IFDTOOL
>> >> >> > HOSTCC util/ifdfake/ifdfake
>> >> >> > DD Adding Intel Firmware Descriptor
>> >> >> > IFDTOOLUnlocking Management Engine
>> >> >> > File build/coreboot.pre is 8388608 bytes
>> >> >> > 

Re: [E-devel] EFL Portability (need BSD, Solaris and Windows input!)

[Youness Alaoui]

Hi Gustavo,
I'd have to agree with you on how the includes should be done, the only
issue I see is that there are some things that you just can't do that way.
Without actually testing, I can't guarantee it will just work, but from
what I remember, we had to include Escape.h in some places because of some
missing defines.
In the case of the ps3, there is a unistd.h file but it doesn't have
everything, that's why we have escape_unistd.h. The #include_next trick
that Lucas suggested could fix that and it's a great idea.
Looking at Escape.h, what I see though is that there's a define for some of
the CLOCK_* macros, the _UNUSED_ macro and the EAPI macro. I'm guessing the
_UNUSED_ and EAPI are not defined maybe because the configure takes care of
that in the config.h and it doesn't recognize the system in order to
determine how it should be set, that's why I had to add them in Escape.h.
As for the CLOCK_* defines, I guess they could go in their own .h and
another #include_next would do the trick in this case. The problem remains
that you still need to have a Escape.h file in order to do the
#include_next call.. and honestly, I don't see how a diff of :
-#include escape_unistd.h
+#include_next unistd.h
would make any real difference in the end...

There are however some things that might need to react differently whether
or not the platform supports it. For example, on the ps3, there is no
multiprocess support, so execv, signals, and all that don't exist. It makes
more sense to have #ifdefs in the EFL to handle such a case rather than
assume it works and do things as if it was working, and have the
compatibility layer just return errors or something. I know this
multi-process thing is an extreme case and it's probably best not to have
special code for it in the EFL (and I'd agree), but it's just the example
that I have off the top of my head. There might be other cases where it's
best to handle them differently rather than try to work around it.
Just my 2c.

KaKaRoTo

On Thu, Jan 3, 2013 at 1:40 PM, Lucas De Marchi 
lucas.demar...@profusion.mobi wrote:

 On Thu, Jan 3, 2013 at 12:34 PM, Gustavo Sverzut Barbieri
 barbi...@profusion.mobi wrote:
  Hi people,
 
  I'm reviewing the checks in efl/configure.ac and some are quite weird,
  which I want to remove if there is no valid reason for their existence.
 
  IMO the way Evil, Escape and Exotic are done are a bit cumbersome for the
  libraries to use. For instance, evil_libgen.h matches libgen.h, however
 the
  user code must have the following:
 
 #ifdef HAVE_LIBGEN_H
 #include libgen.h
 #endif
 ...
 #ifdef HAVE_EVIL
 #include Evil.h /* includes evil_libgen.h */
 #endif
 
  why not call evil_libgen.h just libgen.h and let the user include it
  normally? We just -I$(top_srcdir)/src/lib/evil if building for Evil, then
  it makes life simpler.
 
  In my mind Evil.h and Exotic. doesn't even need to exist... they could
  exist in some cases where the system file exists but lacks something.
  Say libgen.h in PS3 lacked basename, then we could have:
   * escape_libgen.h: basename() definition
   * Escape.h: includes escape_libgen.h to match complete libgen.h

 or you use #include_next libgen.h  inside Escape's libgen.h
 and don't bother with never ever creating Escape.h

 http://gcc.gnu.org/onlinedocs/cpp/Wrapper-Headers.html


 Not sure if other compilers support this, though

 Lucas De Marchi


 --
 Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
 MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
 with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
 MVPs and experts. ON SALE this month only -- learn more at:
 http://p.sf.net/sfu/learnmore_122712
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122712
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: kakaroto trunk/edje/src/bin

[Youness Alaoui]

Hello again,

So I looked at the 1.7 branch and the code there is very different so the
bug wasn't in it. The trunk uses a hash table with a free function that
frees the Part_Lookup structure, and the bug was that it was manually
freeing one item without removing it from the hash table. In 1.7, it's
actually using a list, and the hashtable is created with
eina_hash_string_superfast_new (so, no free func) and it actually removes
it from that hash table when it frees it.
Basically, the bug in trunk was a side-effect/remnant from the refactoring
of the code from the branch.. so there is no need to backport it.


On Wed, Nov 28, 2012 at 1:46 AM, Youness Alaoui 
kakar...@kakaroto.homelinux.net wrote:

 Oh cool, I'll backport it tomorrow! Thanks!
 I never realized there were branches, I thought new releases were always
 taken from the trunk!

 Thanks for the answers!

 On Tue, Nov 27, 2012 at 9:59 PM, Carsten Haitzler ras...@rasterman.comwrote:

 On Tue, 27 Nov 2012 11:45:20 -0500 Youness Alaoui
 kakar...@kakaroto.homelinux.net said:

  Backported? Sorry, what do you mean ? Are there different development
  branches now ? (I haven't paid much attention to E develpment lately)
  If yes, then yeah, it should be backported as it's a critical fix in my
  opinion.

 look in branches (not in trunk)... we have a branch per stable release of
 efl
 where we backport to.. thats how 1.7.1 and 1.7.2 come out.. from the
 stable
 branch. we've done this since 1.0 :) not new. :)

  On Mon, Nov 26, 2012 at 4:26 AM, Cedric BAIL cedric.b...@free.fr
 wrote:
 
   On Sat, Nov 24, 2012 at 8:15 AM, Enlightenment SVN
   no-re...@enlightenment.org wrote:
Log:
edje: Fix segfault when deleted part stays in the hash table
  
   Shouldn't that be backported ?
   --
   Cedric BAIL
  
  
  
 --
   Monitor your physical, virtual and cloud infrastructure from a single
   web console. Get in-depth insight into apps, servers, databases,
 vmware,
   SAP, cloud infrastructure, etc. Download 30-day Free Trial.
   Pricing starts from $795 for 25 servers or applications!
   http://p.sf.net/sfu/zoho_dev2dev_nov
   ___
   enlightenment-devel mailing list
   enlightenment-devel@lists.sourceforge.net
   https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
  
 
 --
  Monitor your physical, virtual and cloud infrastructure from a single
  web console. Get in-depth insight into apps, servers, databases, vmware,
  SAP, cloud infrastructure, etc. Download 30-day Free Trial.
  Pricing starts from $795 for 25 servers or applications!
  http://p.sf.net/sfu/zoho_dev2dev_nov
  ___
  enlightenment-devel mailing list
  enlightenment-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
 


 --
 - Codito, ergo sum - I code, therefore I am --
 The Rasterman (Carsten Haitzler)ras...@rasterman.com



--
Keep yourself connected to Go Parallel: 
INSIGHTS What's next for parallel hardware, programming and related areas?
Interviews and blogs by thought leaders keep you ahead of the curve.
http://goparallel.sourceforge.net
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: kakaroto trunk/edje/src/bin

[Youness Alaoui]

Backported? Sorry, what do you mean ? Are there different development
branches now ? (I haven't paid much attention to E develpment lately)
If yes, then yeah, it should be backported as it's a critical fix in my
opinion.

On Mon, Nov 26, 2012 at 4:26 AM, Cedric BAIL cedric.b...@free.fr wrote:

 On Sat, Nov 24, 2012 at 8:15 AM, Enlightenment SVN
 no-re...@enlightenment.org wrote:
  Log:
  edje: Fix segfault when deleted part stays in the hash table

 Shouldn't that be backported ?
 --
 Cedric BAIL


 --
 Monitor your physical, virtual and cloud infrastructure from a single
 web console. Get in-depth insight into apps, servers, databases, vmware,
 SAP, cloud infrastructure, etc. Download 30-day Free Trial.
 Pricing starts from $795 for 25 servers or applications!
 http://p.sf.net/sfu/zoho_dev2dev_nov
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: kakaroto trunk/edje/src/bin

[Youness Alaoui]

Oh cool, I'll backport it tomorrow! Thanks!
I never realized there were branches, I thought new releases were always
taken from the trunk!

Thanks for the answers!

On Tue, Nov 27, 2012 at 9:59 PM, Carsten Haitzler ras...@rasterman.comwrote:

 On Tue, 27 Nov 2012 11:45:20 -0500 Youness Alaoui
 kakar...@kakaroto.homelinux.net said:

  Backported? Sorry, what do you mean ? Are there different development
  branches now ? (I haven't paid much attention to E develpment lately)
  If yes, then yeah, it should be backported as it's a critical fix in my
  opinion.

 look in branches (not in trunk)... we have a branch per stable release of
 efl
 where we backport to.. thats how 1.7.1 and 1.7.2 come out.. from the stable
 branch. we've done this since 1.0 :) not new. :)

  On Mon, Nov 26, 2012 at 4:26 AM, Cedric BAIL cedric.b...@free.fr
 wrote:
 
   On Sat, Nov 24, 2012 at 8:15 AM, Enlightenment SVN
   no-re...@enlightenment.org wrote:
Log:
edje: Fix segfault when deleted part stays in the hash table
  
   Shouldn't that be backported ?
   --
   Cedric BAIL
  
  
  
 --
   Monitor your physical, virtual and cloud infrastructure from a single
   web console. Get in-depth insight into apps, servers, databases,
 vmware,
   SAP, cloud infrastructure, etc. Download 30-day Free Trial.
   Pricing starts from $795 for 25 servers or applications!
   http://p.sf.net/sfu/zoho_dev2dev_nov
   ___
   enlightenment-devel mailing list
   enlightenment-devel@lists.sourceforge.net
   https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
  
 
 --
  Monitor your physical, virtual and cloud infrastructure from a single
  web console. Get in-depth insight into apps, servers, databases, vmware,
  SAP, cloud infrastructure, etc. Download 30-day Free Trial.
  Pricing starts from $795 for 25 servers or applications!
  http://p.sf.net/sfu/zoho_dev2dev_nov
  ___
  enlightenment-devel mailing list
  enlightenment-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
 


 --
 - Codito, ergo sum - I code, therefore I am --
 The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
Keep yourself connected to Go Parallel: 
INSIGHTS What's next for parallel hardware, programming and related areas?
Interviews and blogs by thought leaders keep you ahead of the curve.
http://goparallel.sourceforge.net
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: kakaroto trunk/GAMES/eskiss/data/edje

[Youness Alaoui]

Ah ok, thanks for the clarification. Issue was that edje_cc complains now
with an error, so eskiss wasn't compiling anymore.

On Sat, Jul 21, 2012 at 4:28 PM, Gustavo Sverzut Barbieri 
barbi...@profusion.mobi wrote:

 On Sat, Jul 21, 2012 at 1:50 PM, Enlightenment SVN
 no-re...@enlightenment.org wrote:
  Log:
  Eskiss: default part type is not RECT anymore so we need to explicitely
 specify it

 actually it was never rect, but image. But images were handled exactly
 like rects in the clipper case. We expect to have special case to clip
 to images some day, so the warning right now.


 --
 Gustavo Sverzut Barbieri
 http://profusion.mobi embedded systems
 --
 MSN: barbi...@gmail.com
 Skype: gsbarbieri
 Mobile: +55 (19) 9225-2202


 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [e-users] Exquisite bootsplash release

[Youness Alaoui]

Resuscitating this old thread...
It's now done and committed to SVN. If there are any issues with it, or
ideas of things to potentially add, now might be a good time.
As discussed previously, I've taken the opportunity to also modify the tags
used by the theme, using success and failure tags instead of the enum's
0 and 1 tags. I think it makes it much clearer this way. However, I
found a bug in edje's style handling and I filed a new ticket about it here
: http://trac.enlightenment.org/e/ticket/1198

I also fixed a small 'bug' with usage of snprintf which was :
snprintf(s, strlen(t-status_text)+5, %sbr/, t-status_text);
Making it safer this way :
snprintf(s, sizeof(buf2)-strlen(buf2), %sbr/, t-status_text);

(since 's' is a pointer to somwhere within buf2)

I think I'll blog about it if that's fine with everyone..

That's it, enjoy :)
KaKaRoTo

On Mon, Feb 20, 2012 at 5:09 AM, Carsten Haitzler ras...@rasterman.comwrote:

 On Mon, 20 Feb 2012 04:00:16 -0500 Youness Alaoui
 kakar...@kakaroto.homelinux.net said:

  On Sun, Feb 19, 2012 at 11:44 PM, Carsten Haitzler
  ras...@rasterman.comwrote:
 
   On Fri, 17 Feb 2012 01:16:12 -0500 Youness Alaoui
   kakar...@kakaroto.homelinux.net said:
  
(FYI: for those who didn't read from IRC, when Carsten realized I
 meant
   to
transform exquisite into a library+tools, and not add a new library
 to
   the
set, he agreed to it).
  
   yeah. yet-another-lib was something we really dont need atm - and it's
   better
   rolled into an existing one, but since it'd just be a lib provided by
   exquisite
   - moving its own functions into that lib and thus providing it for
 others
   to
   use too - that's not bad.
  
So I've done it, just finished, but I have a couple of questions :
- what should I use for creating an object? exquisite_object_add, or
exquisite_object_new ? I think _add makes more sense and follows
 with the
edje API.
  
   _add.
  
- What version should I give it ? Should I keep it to 1.0.0 (or
 1.0.99 to
be more exact), or bump it to match the core efl libs versions
 (1.1.99)?
  
   same version as exquisite. so 1.0.0 - we'll have to bump that for a
   release tho.
  
- Do you have any documentation written for exquisite that I could
 reuse?
Especially with regards to the format to follow for creating themes
 for
   it?
  
   nup. as it was all internal to exquisite (the api anyway), and for
 themes -
   well none other than here's an example. follow and repeat
  
  Ok, well, I'll try to write documentation for how to write themes while
 I'm
  doing it for the API.
 
 
  
- Why is the tag 1 for success and 0 for failure in the edc, why
 not
success failure ? Would make it more logical, and I can use an
 enum
   for
the status without hardcoding the values of the enum.
  
   if you want to change it, now's the time. but 0 or 1 is just a simpler
 more
   compact way of handling the enums as all enums boil down to numbers
 anyway
   :)
  
  Ok, I think I'd rather change it if you're ok with it. Would also like to
  allow for normal tag rather than assume it doesn't have any style
  modifiers.
  Are there any themes out there for exquisite (other than default) that
  might be affected?

 none i know of.

 
  
- There seems to be a bug in the default theme, where the last line
 of
   text
appears cropped after you add a text, I just tried with
 ./run-demo.sh and
part of the last text is cropped after adding one line, then a bigger
   part
after adding another line, then the last lines don't even show up. I
tracked it to the shift_text embryo script in the edj, which does y
 = y -
8; however, the font size is not fixed to 8 pixels height, I changed
 it
   to
y - 13 and it worked. A better solution must be used to make sure the
   text
always shows independently of your default font size or whatever
 might
affect it.
  
   yeah. that's a theme bug there - it should do text scrolling another
 way.
  
  If you find a better way, let me know so it gets fixed at the same time.
 
 
  
Thanks,
KaKaRoTo
   
On Tue, Feb 14, 2012 at 12:25 AM, Carsten Haitzler
ras...@rasterman.comwrote:
   
 On Tue, 14 Feb 2012 00:07:38 -0500 Youness Alaoui
 kakar...@kakaroto.homelinux.net said:

 well it's more because it really has very little additional beyond
 a
 progressbar and it functions for the same purpose - it just can
 have a
 large
 fill my window style. :)

  Humm... it may go as a widget in elementary, although it seems
 more
   like
 a
  megawidget than a simple generic widget, so I'm not sure its
 place is
  inside elementary. But you know best what should go in there.
  I however do not use elementary for the ps3 (because it hasn't
 been
   fully
  ported yet) so I prefer to stay with pure edje. And since
 exquisite
   is
  already written.. it's not much trouble to expose its functions

Re: [Amsn-devel] 0.99 TODO

[Youness Alaoui]

 0.99 TODO
 

 1) Close the vulnerability bug, explain that it really is no
 vulnerability, get back to all distros... then possibly close the
 tracker and redirect to forum/ML/IRC

Was fixed, vivia did the tests, 0.98.4 was indeed vulnerable

2) MSNP2Pv2 (me, possibly with help from Youness)

half done, I'll try to finalize it


 3) libpng bug (Boris)

Done by boris


 4) Moving .so files out of /usr/share (Phil)

done by phil


 5) webcam libng bug (Phil)

Done by phil (I believe)
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Amsn-devel mailing list
Amsn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amsn-devel

Re: [Amsn-devel] 0.99 TODO

[Youness Alaoui]

Ok good, so we are ready for a 0.99 release.
If we release 0.99 sometime in the next few days, it could get added into
debian wheezy, since their freeze is really soon. We found a sponsor so
once the release is done, it should get reviewed and re-added.
As much as I'd like 0.99 out with p2pv2 and msnp18 enabled, I don't believe
it should get released until p2pv2 has been properly tested on the long
term, so I'm thinking of keeping 0.99 with msnp15, with maybe a checkbox in
the login screen to decide if the user wants to use Experimental MSNP18
protocol support (with a clickable '?' or whatever to tell people it
enables mpop and stuff).
We could later release 0.99.1 after long term testing of p2pv2 and
bugfixes, and remove the option and force everyone on p18.
The option could also be in the preferences instead... for those who are
old enough, remember we did the exact same thing with the jump from msnp6
to msnp9, with a checkbox in the login screen.
What do you think ?

KaKaRoTo


On Fri, May 18, 2012 at 7:18 PM, Philippe Valembois - Phil 
lephilouso...@users.sourceforge.net wrote:



 Le 18/05/2012 23:47, Youness Alaoui a écrit :
 
  0.99 TODO
  
 
  1) Close the vulnerability bug, explain that it really is no
  vulnerability, get back to all distros... then possibly close the
  tracker and redirect to forum/ML/IRC
 
  Was fixed, vivia did the tests, 0.98.4 was indeed vulnerable
 
  2) MSNP2Pv2 (me, possibly with help from Youness)
 
  half done, I'll try to finalize it
 
 
  3) libpng bug (Boris)
 
  Done by boris
 
 
  4) Moving .so files out of /usr/share (Phil)
 
  done by phil
 
 
  5) webcam libng bug (Phil)
 
  Done by phil (I believe)
 I confirm : it's done
 
 
 
 
 --
  Live Security Virtual Conference
  Exclusive live event will cover all the ways today's security and
  threat landscape has changed and how IT managers can respond. Discussions
  will include endpoint security, mobile security and the latest in malware
  threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 
 
 
  ___
  Amsn-devel mailing list
  Amsn-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/amsn-devel


 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 Amsn-devel mailing list
 Amsn-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/amsn-devel

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Amsn-devel mailing list
Amsn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amsn-devel

Re: [Patch] Fix ftdi.h for async write API change

[Youness Alaoui]

On Mon, Mar 26, 2012 at 11:28 AM, Thomas Jarosch 
thomas.jaro...@intra2net.com wrote:

 On Monday, 26. March 2012 00:26:45 Youness Alaoui wrote:
  I've been playing around withlibftdi and I noticed that the git master
  version has an API change, removing the ftdi_{read|write}_data_async and
  replacing it with ftdi_{read|write}_data_submit. But the ftdi.h file
  wasn't modified properly, only the read_async prototype was replaced,
  the write_async is still there (causing undefined symbol, etc..).
  Attached is a patch to fix this small issue.

 Applied, thanks!

 Guess nobody is using the async api right now with libftdi 1.x.
 Otherwise someone would have noticed earlier :)

Thanks!
It seems the read_data_submit was used but not write_data_async. Even in my
code, I only do the reads async, but as I was reviewing the library's code,
I noticed that small issue.
it seems the ftdi card's output buffer is 2048 bytes, and if it's full,
then you can't write anything to it in synchronized big bang mode. So if I
wanted to write buffers bigger than 2048 bytes,  I was forced to have an
async read while writing to the card, otherwise it would lock up until
timeout (and report only 2048 bytes were written).




 Thomas



--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscr...@developer.intra2net.com   

Re: [E-devel] [e-users] Exquisite bootsplash release

[Youness Alaoui]

On Sun, Feb 19, 2012 at 11:44 PM, Carsten Haitzler ras...@rasterman.comwrote:

 On Fri, 17 Feb 2012 01:16:12 -0500 Youness Alaoui
 kakar...@kakaroto.homelinux.net said:

  (FYI: for those who didn't read from IRC, when Carsten realized I meant
 to
  transform exquisite into a library+tools, and not add a new library to
 the
  set, he agreed to it).

 yeah. yet-another-lib was something we really dont need atm - and it's
 better
 rolled into an existing one, but since it'd just be a lib provided by
 exquisite
 - moving its own functions into that lib and thus providing it for others
 to
 use too - that's not bad.

  So I've done it, just finished, but I have a couple of questions :
  - what should I use for creating an object? exquisite_object_add, or
  exquisite_object_new ? I think _add makes more sense and follows with the
  edje API.

 _add.

  - What version should I give it ? Should I keep it to 1.0.0 (or 1.0.99 to
  be more exact), or bump it to match the core efl libs versions (1.1.99)?

 same version as exquisite. so 1.0.0 - we'll have to bump that for a
 release tho.

  - Do you have any documentation written for exquisite that I could reuse?
  Especially with regards to the format to follow for creating themes for
 it?

 nup. as it was all internal to exquisite (the api anyway), and for themes -
 well none other than here's an example. follow and repeat

Ok, well, I'll try to write documentation for how to write themes while I'm
doing it for the API.



  - Why is the tag 1 for success and 0 for failure in the edc, why not
  success failure ? Would make it more logical, and I can use an enum
 for
  the status without hardcoding the values of the enum.

 if you want to change it, now's the time. but 0 or 1 is just a simpler more
 compact way of handling the enums as all enums boil down to numbers anyway
 :)

Ok, I think I'd rather change it if you're ok with it. Would also like to
allow for normal tag rather than assume it doesn't have any style
modifiers.
Are there any themes out there for exquisite (other than default) that
might be affected?



  - There seems to be a bug in the default theme, where the last line of
 text
  appears cropped after you add a text, I just tried with ./run-demo.sh and
  part of the last text is cropped after adding one line, then a bigger
 part
  after adding another line, then the last lines don't even show up. I
  tracked it to the shift_text embryo script in the edj, which does y = y -
  8; however, the font size is not fixed to 8 pixels height, I changed it
 to
  y - 13 and it worked. A better solution must be used to make sure the
 text
  always shows independently of your default font size or whatever might
  affect it.

 yeah. that's a theme bug there - it should do text scrolling another way.

If you find a better way, let me know so it gets fixed at the same time.



  Thanks,
  KaKaRoTo
 
  On Tue, Feb 14, 2012 at 12:25 AM, Carsten Haitzler
  ras...@rasterman.comwrote:
 
   On Tue, 14 Feb 2012 00:07:38 -0500 Youness Alaoui
   kakar...@kakaroto.homelinux.net said:
  
   well it's more because it really has very little additional beyond a
   progressbar and it functions for the same purpose - it just can have a
   large
   fill my window style. :)
  
Humm... it may go as a widget in elementary, although it seems more
 like
   a
megawidget than a simple generic widget, so I'm not sure its place is
inside elementary. But you know best what should go in there.
I however do not use elementary for the ps3 (because it hasn't been
 fully
ported yet) so I prefer to stay with pure edje. And since exquisite
 is
already written.. it's not much trouble to expose its functions into
 a
header. So if you don't need/want it in elementary yourself, then
 don't
bother since I probably won't be using it anyways.
Thanks
   
On Mon, Feb 13, 2012 at 4:07 AM, Carsten Haitzler 
 ras...@rasterman.com
   wrote:
   
 On Mon, 13 Feb 2012 03:46:22 -0500 Youness Alaoui
 kakar...@kakaroto.homelinux.net said:

 hmm well if mainloop is alive... making an elementary widget would
 be
   the
 way
 to go... :) call it the splash widget - u can fill a window with
 it,
   just
 put
 it on the left/bottom half of your screen/window or whatever.  :)
 it's
 really
 more of a progressbar PLUS a few more text fields that pb doesnt
   have... in
 fact u can do all of it with progressbars and setting text
 elements in
   the
 progressbar if we added another 1. you can do the end anim with
 signal
 emits -
 in fact u'd want the callback when done and an api for this...

 i'd actually suggest adding some more features to progressbar as
 above
   and
 adding this as a style for it. only thing then is the text log
 scroll -
 should
 this be in progressbar or not - do you want/need it?

  Yes, I've read the code, I know how small and easy it is,
 however, if
  there's a library

Re: [E-devel] EFL documentation

[Youness Alaoui]

Good stuff! :)

Any chance this will cover internals too (maybe as a secondary objective) ?
While the public API is generally well documented, internal APIs aren't.
I'm referring anyways to the difficulty to understand how to write a new
evas engine for example.

On Fri, Feb 17, 2012 at 3:22 PM, Michael Blumenkrantz 
michael.blumenkra...@gmail.com wrote:

 On Fri, 17 Feb 2012 11:40:38 -0200
 Jonas M. Gastal jgas...@profusion.mobi wrote:

  Hello all,
 
  ProFUSION, sponsored by Samsung, is starting a documentation project(yes,
  another one =). This means we'll be going over any pieces of
 documentation we
  fell are incomplete or that could use some improvement and give it some
 work.
 
  The EFL though is huge and we could use everyone's help. In this spirit
 I'd
  like to kindly ask everyone who commits new code to document it and, even
  more importantly, whenever you cause a behaviour change remember to
 change
  the documentation!
 
  Happy coding,
  Gastal
 
 any chance this will cover ecore-x? there's zero documentation there.


 --
 Virtualization  Cloud Management Using Capacity Planning
 Cloud computing makes use of virtualization - but cloud computing
 also focuses on allowing computing to be delivered as a service.
 http://www.accelacomm.com/jaw/sfnl/114/51521223/
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
Virtualization  Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [e-users] Exquisite bootsplash release

[Youness Alaoui]

(FYI: for those who didn't read from IRC, when Carsten realized I meant to
transform exquisite into a library+tools, and not add a new library to the
set, he agreed to it).

So I've done it, just finished, but I have a couple of questions :
- what should I use for creating an object? exquisite_object_add, or
exquisite_object_new ? I think _add makes more sense and follows with the
edje API.
- What version should I give it ? Should I keep it to 1.0.0 (or 1.0.99 to
be more exact), or bump it to match the core efl libs versions (1.1.99)?
- Do you have any documentation written for exquisite that I could reuse?
Especially with regards to the format to follow for creating themes for it?
- Why is the tag 1 for success and 0 for failure in the edc, why not
success failure ? Would make it more logical, and I can use an enum for
the status without hardcoding the values of the enum.
- There seems to be a bug in the default theme, where the last line of text
appears cropped after you add a text, I just tried with ./run-demo.sh and
part of the last text is cropped after adding one line, then a bigger part
after adding another line, then the last lines don't even show up. I
tracked it to the shift_text embryo script in the edj, which does y = y -
8; however, the font size is not fixed to 8 pixels height, I changed it to
y - 13 and it worked. A better solution must be used to make sure the text
always shows independently of your default font size or whatever might
affect it.

Thanks,
KaKaRoTo

On Tue, Feb 14, 2012 at 12:25 AM, Carsten Haitzler ras...@rasterman.comwrote:

 On Tue, 14 Feb 2012 00:07:38 -0500 Youness Alaoui
 kakar...@kakaroto.homelinux.net said:

 well it's more because it really has very little additional beyond a
 progressbar and it functions for the same purpose - it just can have a
 large
 fill my window style. :)

  Humm... it may go as a widget in elementary, although it seems more like
 a
  megawidget than a simple generic widget, so I'm not sure its place is
  inside elementary. But you know best what should go in there.
  I however do not use elementary for the ps3 (because it hasn't been fully
  ported yet) so I prefer to stay with pure edje. And since exquisite is
  already written.. it's not much trouble to expose its functions into a
  header. So if you don't need/want it in elementary yourself, then don't
  bother since I probably won't be using it anyways.
  Thanks
 
  On Mon, Feb 13, 2012 at 4:07 AM, Carsten Haitzler ras...@rasterman.com
 wrote:
 
   On Mon, 13 Feb 2012 03:46:22 -0500 Youness Alaoui
   kakar...@kakaroto.homelinux.net said:
  
   hmm well if mainloop is alive... making an elementary widget would be
 the
   way
   to go... :) call it the splash widget - u can fill a window with it,
 just
   put
   it on the left/bottom half of your screen/window or whatever.  :) it's
   really
   more of a progressbar PLUS a few more text fields that pb doesnt
 have... in
   fact u can do all of it with progressbars and setting text elements in
 the
   progressbar if we added another 1. you can do the end anim with signal
   emits -
   in fact u'd want the callback when done and an api for this...
  
   i'd actually suggest adding some more features to progressbar as above
 and
   adding this as a style for it. only thing then is the text log scroll -
   should
   this be in progressbar or not - do you want/need it?
  
Yes, I've read the code, I know how small and easy it is, however, if
there's a library for it, then apps could reuse the same .edc from
 other
apps, it would give a sort of 'standard' way of doing this kind of
 splash
screens, with a standard set of features, and a set of themes for it
 that
people can reuse..  and obviously, if someone wants it a bit
 different,
they can always just do their own edc instead.
I just saw exquisite (release announcement on planet E) and thought
 it
   was
cool, wanted to look at the API then realized it was an app, and I
   thought
it would be better as a lib.
As for uses, I do have a use for it, there are many tools for the PS3
   that
take a while and do many things but have no output on the screen and
 I
thought they could benefit from that, like the messages dumping ram,
patching kernel, flashing NAND, formatting flash, etc.. as well as
   having
a progress bar.. Telling someone (who has no idea what the EFL even
 is)
   to
write an EDC and set up his canvas and send signals, etc.. just for a
progress bar or for printing a message on screen is a big turn off.
   Also, I
think games may benefit from it, it's not always about boot time,
 but it
would be for loading game levels for example, you often see a
 Loading
screen in games, and this could be used for example.
And for my immediate use, I have a tool that unzips largs packages
 into
   the
PS3 HDD and I'd like to use it as a progress bar for when I unzip
 files,
   it
could be used for the progress

Re: [E-devel] [e-users] Exquisite bootsplash release

[Youness Alaoui]

Yes, I've read the code, I know how small and easy it is, however, if
there's a library for it, then apps could reuse the same .edc from other
apps, it would give a sort of 'standard' way of doing this kind of splash
screens, with a standard set of features, and a set of themes for it that
people can reuse..  and obviously, if someone wants it a bit different,
they can always just do their own edc instead.
I just saw exquisite (release announcement on planet E) and thought it was
cool, wanted to look at the API then realized it was an app, and I thought
it would be better as a lib.
As for uses, I do have a use for it, there are many tools for the PS3 that
take a while and do many things but have no output on the screen and I
thought they could benefit from that, like the messages dumping ram,
patching kernel, flashing NAND, formatting flash, etc.. as well as having
a progress bar.. Telling someone (who has no idea what the EFL even is) to
write an EDC and set up his canvas and send signals, etc.. just for a
progress bar or for printing a message on screen is a big turn off. Also, I
think games may benefit from it, it's not always about boot time, but it
would be for loading game levels for example, you often see a Loading
screen in games, and this could be used for example.
And for my immediate use, I have a tool that unzips largs packages into the
PS3 HDD and I'd like to use it as a progress bar for when I unzip files, it
could be used for the progress bar as well as for listing the files being
unpacked. And yeah, the app is alive and running the mainloop in those use
cases, and unzipping 1GB takes time I was going to implement a progress
bar+messages system in my code, and write the edc and write a spec for
people to retheme it, etc... but since I've seen exquisite, I don't think
it's worth it to rewrite the same thing when I could just reuse existing
code.
Any suggestions on how you'd like me to proceed ? or should I just go and
do it (I'll probably do it tomorrow).

Thanks,
KaKaRoTo

On Mon, Feb 13, 2012 at 2:03 AM, Carsten Haitzler ras...@rasterman.comwrote:

 On Sun, 12 Feb 2012 07:13:39 -0500 Youness Alaoui
 kakar...@kakaroto.homelinux.net said:

 ummm... if an app wants to do this its as easy as loading an edje obj and
 sending signals/setting text and dragables. that's a VERY thin library
 there.
 you want this for app splashes while apps start up? are the apps that start
 actually alive and running the mainloop for a long period before they are
 usable?

  This looks pretty good!
  I've been thinking that this could be used for applications as well, not
  just for the init scripts. So I'm thinking of modifying exquisite into a
  libexquisite (which the exquisite tool itself would use). It's basically
  just about having a way of creating an exquisite (edje) object and
  translating those IPC commands into API functions. I think it could be
 used
  by apps for doing progress bars (with a sort of 'standard' edje specs)
 and
  generic splash screens (for games loading levels and stuff like that).
  What do you think ? Any suggestions before I start ?
 
  KaKaRoTo
 
  On Fri, Feb 10, 2012 at 4:37 AM, P Purkayastha ppu...@gmail.com wrote:
 
  
   On Friday, February 10, 2012 4:40:33 PM UTC+8, The Rasterman Carsten
   Haitzler wrote:
   
On Thu, 9 Feb 2012 23:04:00 -0800 (PST) P Purkayastha 
 ppu...@gmail.com
said:
   
 Is there some guide on how to set this up? I know that Exquisite
 has
 existed for many years but I could never set it up due to the lack
 of a
 noobie-friendly guide.
   
read README? look at the run-demo.sh
   
as such you only want to be integrating this into a boot if you know
 your
boot
stuff (systemd/systvinit/whatever) and you need to put the status
 writes
into
your startup scripts or modify systemd to do it for you. (write to
 fifo
   or
scoket directly). other than that u need to hack up all your init
 setup
   to
start exquisite before everything else (and make sure efl libs are
available to
it at that time) and then send status and done messages from your
 init
scripts
or whatever.
   
--
- Codito, ergo sum - I code, therefore I am
 --
The Rasterman (Carsten Haitzler)ras...@rasterman.com
   
  
   Ah yeah. Now I remember why I didn't pursue it further. I wasn't
   comfortable with hacking init scripts. :)
  
  
  
  
 --
   Virtualization  Cloud Management Using Capacity Planning
   Cloud computing makes use of virtualization - but cloud computing
   also focuses on allowing computing to be delivered as a service.
   http://www.accelacomm.com/jaw/sfnl/114/51521223/
   ___
   enlightenment-devel mailing list
   enlightenment-devel@lists.sourceforge.net
   https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [e-users] Exquisite bootsplash release

[Youness Alaoui]

Humm... it may go as a widget in elementary, although it seems more like a
megawidget than a simple generic widget, so I'm not sure its place is
inside elementary. But you know best what should go in there.
I however do not use elementary for the ps3 (because it hasn't been fully
ported yet) so I prefer to stay with pure edje. And since exquisite is
already written.. it's not much trouble to expose its functions into a
header. So if you don't need/want it in elementary yourself, then don't
bother since I probably won't be using it anyways.
Thanks

On Mon, Feb 13, 2012 at 4:07 AM, Carsten Haitzler ras...@rasterman.comwrote:

 On Mon, 13 Feb 2012 03:46:22 -0500 Youness Alaoui
 kakar...@kakaroto.homelinux.net said:

 hmm well if mainloop is alive... making an elementary widget would be the
 way
 to go... :) call it the splash widget - u can fill a window with it, just
 put
 it on the left/bottom half of your screen/window or whatever.  :) it's
 really
 more of a progressbar PLUS a few more text fields that pb doesnt have... in
 fact u can do all of it with progressbars and setting text elements in the
 progressbar if we added another 1. you can do the end anim with signal
 emits -
 in fact u'd want the callback when done and an api for this...

 i'd actually suggest adding some more features to progressbar as above and
 adding this as a style for it. only thing then is the text log scroll -
 should
 this be in progressbar or not - do you want/need it?

  Yes, I've read the code, I know how small and easy it is, however, if
  there's a library for it, then apps could reuse the same .edc from other
  apps, it would give a sort of 'standard' way of doing this kind of splash
  screens, with a standard set of features, and a set of themes for it that
  people can reuse..  and obviously, if someone wants it a bit different,
  they can always just do their own edc instead.
  I just saw exquisite (release announcement on planet E) and thought it
 was
  cool, wanted to look at the API then realized it was an app, and I
 thought
  it would be better as a lib.
  As for uses, I do have a use for it, there are many tools for the PS3
 that
  take a while and do many things but have no output on the screen and I
  thought they could benefit from that, like the messages dumping ram,
  patching kernel, flashing NAND, formatting flash, etc.. as well as
 having
  a progress bar.. Telling someone (who has no idea what the EFL even is)
 to
  write an EDC and set up his canvas and send signals, etc.. just for a
  progress bar or for printing a message on screen is a big turn off.
 Also, I
  think games may benefit from it, it's not always about boot time, but it
  would be for loading game levels for example, you often see a Loading
  screen in games, and this could be used for example.
  And for my immediate use, I have a tool that unzips largs packages into
 the
  PS3 HDD and I'd like to use it as a progress bar for when I unzip files,
 it
  could be used for the progress bar as well as for listing the files being
  unpacked. And yeah, the app is alive and running the mainloop in those
 use
  cases, and unzipping 1GB takes time I was going to implement a
 progress
  bar+messages system in my code, and write the edc and write a spec for
  people to retheme it, etc... but since I've seen exquisite, I don't think
  it's worth it to rewrite the same thing when I could just reuse existing
  code.
  Any suggestions on how you'd like me to proceed ? or should I just go and
  do it (I'll probably do it tomorrow).
 
  Thanks,
  KaKaRoTo
 
  On Mon, Feb 13, 2012 at 2:03 AM, Carsten Haitzler ras...@rasterman.com
 wrote:
 
   On Sun, 12 Feb 2012 07:13:39 -0500 Youness Alaoui
   kakar...@kakaroto.homelinux.net said:
  
   ummm... if an app wants to do this its as easy as loading an edje obj
 and
   sending signals/setting text and dragables. that's a VERY thin library
   there.
   you want this for app splashes while apps start up? are the apps that
 start
   actually alive and running the mainloop for a long period before they
 are
   usable?
  
This looks pretty good!
I've been thinking that this could be used for applications as well,
 not
just for the init scripts. So I'm thinking of modifying exquisite
 into a
libexquisite (which the exquisite tool itself would use). It's
 basically
just about having a way of creating an exquisite (edje) object and
translating those IPC commands into API functions. I think it could
 be
   used
by apps for doing progress bars (with a sort of 'standard' edje
 specs)
   and
generic splash screens (for games loading levels and stuff like
 that).
What do you think ? Any suggestions before I start ?
   
KaKaRoTo
   
On Fri, Feb 10, 2012 at 4:37 AM, P Purkayastha ppu...@gmail.com
 wrote:
   

 On Friday, February 10, 2012 4:40:33 PM UTC+8, The Rasterman
 Carsten
 Haitzler wrote:
 
  On Thu, 9 Feb 2012 23:04:00 -0800 (PST) P Purkayastha

Re: [E-devel] [e-users] Exquisite bootsplash release

[Youness Alaoui]

This looks pretty good!
I've been thinking that this could be used for applications as well, not
just for the init scripts. So I'm thinking of modifying exquisite into a
libexquisite (which the exquisite tool itself would use). It's basically
just about having a way of creating an exquisite (edje) object and
translating those IPC commands into API functions. I think it could be used
by apps for doing progress bars (with a sort of 'standard' edje specs) and
generic splash screens (for games loading levels and stuff like that).
What do you think ? Any suggestions before I start ?

KaKaRoTo

On Fri, Feb 10, 2012 at 4:37 AM, P Purkayastha ppu...@gmail.com wrote:


 On Friday, February 10, 2012 4:40:33 PM UTC+8, The Rasterman Carsten
 Haitzler wrote:
 
  On Thu, 9 Feb 2012 23:04:00 -0800 (PST) P Purkayastha ppu...@gmail.com
  said:
 
   Is there some guide on how to set this up? I know that Exquisite has
   existed for many years but I could never set it up due to the lack of a
   noobie-friendly guide.
 
  read README? look at the run-demo.sh
 
  as such you only want to be integrating this into a boot if you know your
  boot
  stuff (systemd/systvinit/whatever) and you need to put the status writes
  into
  your startup scripts or modify systemd to do it for you. (write to fifo
 or
  scoket directly). other than that u need to hack up all your init setup
 to
  start exquisite before everything else (and make sure efl libs are
  available to
  it at that time) and then send status and done messages from your init
  scripts
  or whatever.
 
  --
  - Codito, ergo sum - I code, therefore I am --
  The Rasterman (Carsten Haitzler)ras...@rasterman.com
 

 Ah yeah. Now I remember why I didn't pursue it further. I wasn't
 comfortable with hacking init scripts. :)



 --
 Virtualization  Cloud Management Using Capacity Planning
 Cloud computing makes use of virtualization - but cloud computing
 also focuses on allowing computing to be delivered as a service.
 http://www.accelacomm.com/jaw/sfnl/114/51521223/
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


--
Virtualization  Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Edje aspect.preference big-endian issue

[Youness Alaoui]

No, I hadn't cause I got quite busy with something else, and I still needed
to take the time to check if there were any other enums affected by the
same kind of bug. I committed it yesterday though.

On Wed, Jan 18, 2012 at 3:04 AM, Carsten Haitzler ras...@rasterman.comwrote:

 On Wed, 18 Jan 2012 01:01:45 -0500 Youness Alaoui
 kakar...@kakaroto.homelinux.net said:

 i expected you would have already... ? commit! :)

  hehe,
  well, I just looked over edje_private.h and I didn't see any enum being
  used like aspect_preference was.Although maybe it's best if someone else
  had a quick look. I'm going to commit the patch I had as is.
 
  On Tue, Jan 17, 2012 at 11:06 PM, Carsten Haitzler
  ras...@rasterman.comwrote:
 
   On Fri, 13 Jan 2012 22:47:38 +0100 Cedric BAIL cedric.b...@free.fr
 said:
  
On Fri, Jan 13, 2012 at 8:30 PM, Youness Alaoui
kakar...@kakaroto.homelinux.net wrote:
 On Fri, Jan 13, 2012 at 10:32 AM, Cedric BAIL cedric.b...@free.fr
 
   wrote:
 On Fri, Jan 13, 2012 at 8:12 AM, Youness Alaoui
 kakar...@kakaroto.homelinux.net wrote:
  I've had an issue recently when I tried to run my app (using
 edje)
   on the
  PS3, the aspect ratio of all the images were wrong, and it
 looked
   really
  bad. I investigated the issue and found out that the
   aspect_preference
 was
  the cause and that when it's set to  'BOTH' for example, the
  desc-aspect.prefer value is 50331648 which is.. 0x300 .. so
   it's a
 big
  endian vs. little endian issue since the EDJE_ASPECT_PREFER_BOTH
   value in
  the enum is '3'.
  So I figured the reading of the .edj is wrong, so I looked and
 it
   seems
 to
  read it as a 'EET_T_CHAR', but the structure contains the enum
 as
   type,
  which makes it an int.. so what happens is that it stores 1 byte
   (the
 char)
  in the 32bit variable.. on little endian, it's fine, it works,
 but
   on big
  endian, it makes the value huge. So I fixed it by changing the
 declaration
  of he 'aspect.prefer' structure to a char instead of the enum it
  represents. I tested and it seems to work and not break anything
   (and
 fixes
  the bug). However, since this seems a bit sensitive, I thought
 it's
   best
 to
  send the patch here to make sure I'm not doing something wrong.
  Thanks for reviewing this simple one liner patch :
 http://pastie.org/3176835
  I have noticed other structures do the same thing, 'fill mode'
 for
 example
  is defined as EET_T_UCHAR in the eet data description and as
   'unsigned
  char' in the structure, that's why I fixed it this way. Note
 also
   that
 this
  shouldn't break the .edj file's compatibility or anything.

 Good, you figured out why it was broken. The fix sounds fine for
 me.
 Did you check that the only enum, we are using directly in one of
 our
 saved structure or should I check ?

 Ok cool, I will commit it then. I checked and didn't see any other
 enum
 being used, but I didn't do an extensive check. I will make sure it
   was the
 only one and fix any other I might see.
   
Cool, thanks !
  
   awesome. all handled before i got to it! eexcellent! :)
  
   --
   - Codito, ergo sum - I code, therefore I am
 --
   The Rasterman (Carsten Haitzler)ras...@rasterman.com
  
  
  
  
 --
   Keep Your Developer Skills Current with LearnDevNow!
   The most comprehensive online learning library for Microsoft developers
   is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3,
 MVC3,
   Metro Style Apps, more. Free future releases when you subscribe now!
   http://p.sf.net/sfu/learndevnow-d2d
   ___
   enlightenment-devel mailing list
   enlightenment-devel@lists.sourceforge.net
   https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
  
 
 --
  Keep Your Developer Skills Current with LearnDevNow!
  The most comprehensive online learning library for Microsoft developers
  is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
  Metro Style Apps, more. Free future releases when you subscribe now!
  http://p.sf.net/sfu/learndevnow-d2d
  ___
  enlightenment-devel mailing list
  enlightenment-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
 


 --
 - Codito, ergo sum - I code, therefore I am --
 The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio

Re: [E-devel] Windows installer

[Youness Alaoui]

On Thu, Jan 19, 2012 at 12:15 AM, Sanjeev as290...@samsung.com wrote:

 Hi Vincent,
 I tested the windows installer, it installed without any issues. (Windows 7
 Enterprise Edition)
 I think the following can be made better.

 1. Picks up the default install folder as C:\Program Files\Efl. We could
 set it to c:\Efl by default, instead of %WINDIR% or some default path.

I agree, that's a good idea, I personally didn't even notice the enter a
destination directory screen, so it installed in program files, and when I
tried to run edje_cc, it failed. Forced me to uninstall, reinstall.. so
having C:\Efl as default is a good idea, and many apps do that already
(python, tcl/tk, mingw, etc..)

2. After installation, there is only one menu item under EFL - Uninstall. It
 would help to port elementary_test as an example and put it as a menu item.

Good point, it could also have a edje examples submenu with the examples
running in edje_player for example.. there are a few things that can be
done, not sure though if it's necessary.. as an optional checkbox maybe.



 The installation seems to have a collection of libraries and some binaries.
 Do you need some test apps written using these libraries ?

 I have never written embryo scripts before. Kindly let me know some more
 details about the testing. I can help.

 Regards,
 Sanjeev

 -Original Message-
 From: Vincent Torri [mailto:vincent.to...@gmail.com]
 Sent: Thursday, January 19, 2012 2:06 AM
 To: Enlightenment developer list
 Subject: [E-devel] Windows installer

 Hey,

 I've fixed a lot of bugs with the installer and the tarballs. The
 installer is here:

 http://dev.enlightenment.fr/~doursse/NSIS/Efl-1.1.0.exe

 it is better to install the EFL in a path without spaces (like c:\Efl).

 If some people could test it, especially with themes using embryo
 scripts, that would help me a lot

 thank you

 Vincent Torri


 
 --
 Keep Your Developer Skills Current with LearnDevNow!
 The most comprehensive online learning library for Microsoft developers
 is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
 Metro Style Apps, more. Free future releases when you subscribe now!
 http://p.sf.net/sfu/learndevnow-d2d
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

 --
 Keep Your Developer Skills Current with LearnDevNow!
 The most comprehensive online learning library for Microsoft developers
 is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
 Metro Style Apps, more. Free future releases when you subscribe now!
 http://p.sf.net/sfu/learndevnow-d2d
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Windows installer

[Youness Alaoui]

On Thu, Jan 19, 2012 at 1:15 AM, Vincent Torri vincent.to...@gmail.comwrote:

 hey

 On Thu, Jan 19, 2012 at 6:32 AM, Youness Alaoui
 kakar...@kakaroto.homelinux.net wrote:
  On Thu, Jan 19, 2012 at 12:15 AM, Sanjeev as290...@samsung.com wrote:
 
  Hi Vincent,
  I tested the windows installer, it installed without any issues.
 (Windows 7
  Enterprise Edition)
  I think the following can be made better.
 
  1. Picks up the default install folder as C:\Program Files\Efl. We
 could
  set it to c:\Efl by default, instead of %WINDIR% or some default path.
 
  I agree, that's a good idea, I personally didn't even notice the enter a
  destination directory screen, so it installed in program files, and
 when I
  tried to run edje_cc, it failed. Forced me to uninstall, reinstall.. so
  having C:\Efl as default is a good idea, and many apps do that already
  (python, tcl/tk, mingw, etc..)

 I can use c:\Efl by default, it's trivial to do.

 Note that is you run the installer while a previous installation has
 been done, the previous installation will be uninstalled first.

yeah, that's how it gets uninstalled :p



  2. After installation, there is only one menu item under EFL -
 Uninstall. It
  would help to port elementary_test as an example and put it as a menu
 item.
 
  Good point, it could also have a edje examples submenu with the
 examples
  running in edje_player for example.. there are a few things that can be
  done, not sure though if it's necessary.. as an optional checkbox maybe.

 If I'm not mistaken, edje_player requires an edje file at least. So
 it's useless to add it. But I can try to look if I can associate .edj
 files with edje_player.

Oh that's a great idea to associate .edj files to edje_player! But what I
meant was to have in programs-Efl-edje examples - pong.lnk with the
command in pong.lnk being edje_player.exe c:\efl\examples\edje\pong.edj
for example.



 Well, the installer is for EFL 1.1.0. That's why I didn't add
 Elementary. But I can add Expedite. I don't know if Expedite should be
 installed with the same installer, or with another installer.

Good point about elementary. Yes, expedite could be disabled by default but
added as a checkbox for example/test suite/expedite or something like that



  The installation seems to have a collection of libraries and some
 binaries.
  Do you need some test apps written using these libraries ?
 
  I have never written embryo scripts before. Kindly let me know some more
  details about the testing. I can help

 I think that Elementary theme has some embryo scripts.

 thank you for testing.

 Vincent


 --
 Keep Your Developer Skills Current with LearnDevNow!
 The most comprehensive online learning library for Microsoft developers
 is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
 Metro Style Apps, more. Free future releases when you subscribe now!
 http://p.sf.net/sfu/learndevnow-d2d
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Windows installer

[Youness Alaoui]

On Thu, Jan 19, 2012 at 1:50 AM, Vincent Torri vincent.to...@gmail.comwrote:

 On Thu, Jan 19, 2012 at 7:41 AM, Youness Alaoui
 kakar...@kakaroto.homelinux.net wrote:
  On Thu, Jan 19, 2012 at 1:15 AM, Vincent Torri vincent.to...@gmail.com
 wrote:
 
  hey
 
  On Thu, Jan 19, 2012 at 6:32 AM, Youness Alaoui
 
  Oh that's a great idea to associate .edj files to edje_player! But what I
  meant was to have in programs-Efl-edje examples - pong.lnk with the
  command in pong.lnk being edje_player.exe c:\efl\examples\edje\pong.edj
  for example.

 haa, ok. I'll try to do it. Maybe it will mean to fix the compilation
 of the examples :/ I've never tried to compile them on Windows.

 In that case, maybe it will also a good idea to install .edc files.

Yeah good idea. But since my edc compiles now on windows, I bet those
example edc will aso compile without problem.



  Well, the installer is for EFL 1.1.0. That's why I didn't add
  Elementary. But I can add Expedite. I don't know if Expedite should be
  installed with the same installer, or with another installer.
 
  Good point about elementary. Yes, expedite could be disabled by default
 but
  added as a checkbox for example/test suite/expedite or something like
 that

 Just an 'Expedite' submenu will be sufficient, I think

Yeah, I meant in the installer, you have checkboxes for each library, you
could add another checkbox that says Examples or Test suite or
Expedite or something like that.. I didn't mean for that to sound like
subdirectories in the programs menu :)



 Vincent


 --
 Keep Your Developer Skills Current with LearnDevNow!
 The most comprehensive online learning library for Microsoft developers
 is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
 Metro Style Apps, more. Free future releases when you subscribe now!
 http://p.sf.net/sfu/learndevnow-d2d
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina_lock_void issue

[Youness Alaoui]

On Tue, Jan 17, 2012 at 11:26 PM, Carsten Haitzler ras...@rasterman.comwrote:

 On Sat, 14 Jan 2012 23:19:59 -0500 Michael Blumenkrantz
 michael.blumenkra...@gmail.com said:

  On Sat, 14 Jan 2012 23:15:37 -0500
  Youness Alaoui kakar...@kakaroto.homelinux.net wrote:
 
   Hi,
  
   I've just updated my EFL build for the PS3 and it was broken. eina_init
   isn't working anymore because eina_value doesn't init itself
 correctly. The
   issue is that if it's unable to iitialize a lock, it will fail the init
   which fails eina_init (and ecore_init, etc..)
   The problem is that on the PS3, there is no pthread library so threads
 are
   disabled on eina and eina_lock uses eina_inline_lock_void.x which just
   returns FALSE/FAIL for every API call. This also causes another issue
 with
   evas which slows it down because it tries a eina_lock_take_try (which
   fails) and forces it to wait a bit before doing anything then it spams
 my
   terminal with warnings about not being able to get a lock.
   I would suggest to change the behavior of eina_lock (on 'void'
 platforms,
   which do not support locks) to always return TRUE/SUCCEED so it doesn't
   break everything below it.
  
   What do you think ?
  
   Thanks,
   KaKaRoTo
  unfortunately this would be an api break since eina_lock was present in
 the
  1.1 release...

 actually the void impl really should just work as if there were no
 threads at
 all so i'd say this is a bug in return value. i.e. its a platform on which
 threads cannot exist thus locking is pointless. though my position on this
 is... it will be not long when we simply will not work without threads. it
 is
 my intention to move us to having more internal threads and reduce the
 maintenance cost of having non-threaded modes/paths as then its a vector
 for
 bugs and problems. so reality is the void thread impl will basically be
 like an
 appendix - useless legacy stuff :)

Yeah, I know your plan, in the meantime, I'm happy playing the lazy card
until it becomes mandatory. Either way I don't think it was working before
I came in, as I found many bugs on the no-threads part of the code as it
was never tested by anyone.
But I do agree, it's a bug in my opinion as it should just work as if locks
were successful (no threads means no race conditions).. on the other hand
some might see it as you try to create a mutex but it failed because it's
not supported as being the expected behavior.
it's a though call to be honest.. but all I know, is that without that
patch, it just won't work for me right now.


 --
 - Codito, ergo sum - I code, therefore I am --
 The Rasterman (Carsten Haitzler)ras...@rasterman.com



 --
 Keep Your Developer Skills Current with LearnDevNow!
 The most comprehensive online learning library for Microsoft developers
 is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
 Metro Style Apps, more. Free future releases when you subscribe now!
 http://p.sf.net/sfu/learndevnow-d2d
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Edje aspect.preference big-endian issue

[Youness Alaoui]

hehe,
well, I just looked over edje_private.h and I didn't see any enum being
used like aspect_preference was.Although maybe it's best if someone else
had a quick look. I'm going to commit the patch I had as is.

On Tue, Jan 17, 2012 at 11:06 PM, Carsten Haitzler ras...@rasterman.comwrote:

 On Fri, 13 Jan 2012 22:47:38 +0100 Cedric BAIL cedric.b...@free.fr said:

  On Fri, Jan 13, 2012 at 8:30 PM, Youness Alaoui
  kakar...@kakaroto.homelinux.net wrote:
   On Fri, Jan 13, 2012 at 10:32 AM, Cedric BAIL cedric.b...@free.fr
 wrote:
   On Fri, Jan 13, 2012 at 8:12 AM, Youness Alaoui
   kakar...@kakaroto.homelinux.net wrote:
I've had an issue recently when I tried to run my app (using edje)
 on the
PS3, the aspect ratio of all the images were wrong, and it looked
 really
bad. I investigated the issue and found out that the
 aspect_preference
   was
the cause and that when it's set to  'BOTH' for example, the
desc-aspect.prefer value is 50331648 which is.. 0x300 .. so
 it's a
   big
endian vs. little endian issue since the EDJE_ASPECT_PREFER_BOTH
 value in
the enum is '3'.
So I figured the reading of the .edj is wrong, so I looked and it
 seems
   to
read it as a 'EET_T_CHAR', but the structure contains the enum as
 type,
which makes it an int.. so what happens is that it stores 1 byte
 (the
   char)
in the 32bit variable.. on little endian, it's fine, it works, but
 on big
endian, it makes the value huge. So I fixed it by changing the
   declaration
of he 'aspect.prefer' structure to a char instead of the enum it
represents. I tested and it seems to work and not break anything
 (and
   fixes
the bug). However, since this seems a bit sensitive, I thought it's
 best
   to
send the patch here to make sure I'm not doing something wrong.
Thanks for reviewing this simple one liner patch :
   http://pastie.org/3176835
I have noticed other structures do the same thing, 'fill mode' for
   example
is defined as EET_T_UCHAR in the eet data description and as
 'unsigned
char' in the structure, that's why I fixed it this way. Note also
 that
   this
shouldn't break the .edj file's compatibility or anything.
  
   Good, you figured out why it was broken. The fix sounds fine for me.
   Did you check that the only enum, we are using directly in one of our
   saved structure or should I check ?
  
   Ok cool, I will commit it then. I checked and didn't see any other enum
   being used, but I didn't do an extensive check. I will make sure it
 was the
   only one and fix any other I might see.
 
  Cool, thanks !

 awesome. all handled before i got to it! eexcellent! :)

 --
 - Codito, ergo sum - I code, therefore I am --
 The Rasterman (Carsten Haitzler)ras...@rasterman.com



 --
 Keep Your Developer Skills Current with LearnDevNow!
 The most comprehensive online learning library for Microsoft developers
 is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
 Metro Style Apps, more. Free future releases when you subscribe now!
 http://p.sf.net/sfu/learndevnow-d2d
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina_lock_void issue

[Youness Alaoui]

Oh, I just did a rebase on svn and you already committed a patch that did
this. I thought it needed more discussion before a decision is made.
Thanks! :)

On Wed, Jan 18, 2012 at 12:32 AM, Youness Alaoui 
kakar...@kakaroto.homelinux.net wrote:



 On Tue, Jan 17, 2012 at 11:26 PM, Carsten Haitzler 
 ras...@rasterman.comwrote:

 On Sat, 14 Jan 2012 23:19:59 -0500 Michael Blumenkrantz
 michael.blumenkra...@gmail.com said:

  On Sat, 14 Jan 2012 23:15:37 -0500
  Youness Alaoui kakar...@kakaroto.homelinux.net wrote:
 
   Hi,
  
   I've just updated my EFL build for the PS3 and it was broken.
 eina_init
   isn't working anymore because eina_value doesn't init itself
 correctly. The
   issue is that if it's unable to iitialize a lock, it will fail the
 init
   which fails eina_init (and ecore_init, etc..)
   The problem is that on the PS3, there is no pthread library so
 threads are
   disabled on eina and eina_lock uses eina_inline_lock_void.x which just
   returns FALSE/FAIL for every API call. This also causes another issue
 with
   evas which slows it down because it tries a eina_lock_take_try (which
   fails) and forces it to wait a bit before doing anything then it
 spams my
   terminal with warnings about not being able to get a lock.
   I would suggest to change the behavior of eina_lock (on 'void'
 platforms,
   which do not support locks) to always return TRUE/SUCCEED so it
 doesn't
   break everything below it.
  
   What do you think ?
  
   Thanks,
   KaKaRoTo
  unfortunately this would be an api break since eina_lock was present in
 the
  1.1 release...

 actually the void impl really should just work as if there were no
 threads at
 all so i'd say this is a bug in return value. i.e. its a platform on
 which
 threads cannot exist thus locking is pointless. though my position on this
 is... it will be not long when we simply will not work without threads.
 it is
 my intention to move us to having more internal threads and reduce the
 maintenance cost of having non-threaded modes/paths as then its a vector
 for
 bugs and problems. so reality is the void thread impl will basically be
 like an
 appendix - useless legacy stuff :)

 Yeah, I know your plan, in the meantime, I'm happy playing the lazy card
 until it becomes mandatory. Either way I don't think it was working before
 I came in, as I found many bugs on the no-threads part of the code as it
 was never tested by anyone.
 But I do agree, it's a bug in my opinion as it should just work as if
 locks were successful (no threads means no race conditions).. on the other
 hand some might see it as you try to create a mutex but it failed because
 it's not supported as being the expected behavior.
 it's a though call to be honest.. but all I know, is that without that
 patch, it just won't work for me right now.


 --
 - Codito, ergo sum - I code, therefore I am --
 The Rasterman (Carsten Haitzler)ras...@rasterman.com



 --
 Keep Your Developer Skills Current with LearnDevNow!
 The most comprehensive online learning library for Microsoft developers
 is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
 Metro Style Apps, more. Free future releases when you subscribe now!
 http://p.sf.net/sfu/learndevnow-d2d
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel



--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [Telepathy] Telepathy and EFL

[Youness Alaoui]

On 01/15/2012 06:51 PM, Danielle Madeley wrote:
 20:38 kuuko Hello, I'm looking into rewriting a python app that's using 
 the 
   low level telepathy functionality. I understand that 
   telepathy-python has been deprecated in favor of 
 telepathy-glib 
   python bindings. The thing is that the app is not using GTK+ 
 for 
   it's ui, instead it's EFL-based, so I am wondering if and how 
 I 
   can make use of telepathy-glib in such a client.
 
 Your problem with using the telepathy-glib bindings will be integrating
 with the GLib mainloop to receive events and callbacks. I don't
 specifically know about EFL, but nowadays Qt and GLib share a mainloop.
 
 Possibly this blog post is useful to you:
 http://blog.gustavobarbieri.com.br/2009/10/01/ecore-glib-main-loop-integration/
 
 If you can't integrate the mainloops, you may have to stick with the
 low-level telepathy-python bindings,
 

Yes, ecore integrates with the mainloop from glib so that shouldn't be a 
problem.
It would be great to have an EFL based client for Telepathy. If you're
interested, we (the aMSN team) already started (a few years ago) working on a
python based client and you could easily port it to use telepathy instead of
directly using papyon. I've wanted to do that for a while but haven't had time.
We have an EFL front end for aMSN2 although I'm not sure of its current status.
Interested ?

Youness.



signature.asc
Description: OpenPGP digital signature
___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [E-devel] edje and epp

[Youness Alaoui]

Good point about the authors.. There are 22 total who contributed to
edje_cc* files and only 6 to edje_cc.c specifically.
git log edje_cc* | grep Author | awk '{print $2}' | sort | uniq | wc
22

I definitely agree that it would be stupid to change the other libs or even
edje itself to GPL, and I would definitely disagree with that myself. I
also don't like how GPL is a kind of viral like license, but the way I
usually do it (personally) is : GPL for apps, LGPL for libraries.
That being said, releasing *only* the edje_cc binary in GPL (keeping edje
library and edje_decc, etc.. as BSD-like) would be a good solution to this
epp problem.
In order to avoid having to get approval from all 22 authors on the edje_cc
files, how about a compromise, write a new edje_cc, which would use the
BSD-like code from the existing code base (edje_cc_handlers.c,
edje_cc_parse.c, etc..) but just write the 'main' function in a GPL-ed file
which includes and calls those BSD-like functions/files. That is of course,
assuming that a GPL .o can be 'legally' linked with a BSD .o (I think it
is, but I'm not sure about it) to provide the final binary.
edje_cc.c is only 250 lines of code, so it should be quite easy to rewrite
it, or we could just ask permission from the 6 authors of edje_cc.c :
barbieri
caro
cedric
lucas
mike_m
raster

We could also have a edje_cc_gpl alongside edje_cc which would not depend
on epp and integrates it... This is particularly useful for windows where
it's a bit tricky to get edje_cc.exe to find epp.exe (although that works
fine and is not too hard, it's a bit of a hassle).
Anyways, I'm just throwing ideas, doesn't mean any makes sense :)


On Sun, Jan 15, 2012 at 3:51 AM, Michael Blumenkrantz 
michael.blumenkra...@gmail.com wrote:

 On Sun, 15 Jan 2012 09:48:34 +0100
 Vincent Torri vincent.to...@gmail.com wrote:

  On Sun, Jan 15, 2012 at 9:33 AM, David Seikel onef...@gmail.com wrote:
 
Only two are listed as an author
   for epp, might be easier to get epp license changed?  Though this might
   make things hard (from epp) -
  
* Copyright (C) 1995 Free Software Foundation, Inc.
* Written by Per Bothner, 1994-95.
* Copyright (C) 2003-2011 Kim Woelders
 
  that's something to try, indeed, though some changes has been done to
  epp by other devs :
 
  http://trac.enlightenment.org/e/log/trunk/edje/src/bin/epp
 
  Vincent
 
 I don't consider anything I've done there worth attribution.


 --
 RSA(R) Conference 2012
 Mar 27 - Feb 2
 Save $400 by Jan. 27
 Register now!
 http://p.sf.net/sfu/rsa-sfdev2dev2
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] eina_lock_void issue

[Youness Alaoui]

Hi,

I've just updated my EFL build for the PS3 and it was broken. eina_init
isn't working anymore because eina_value doesn't init itself correctly. The
issue is that if it's unable to iitialize a lock, it will fail the init
which fails eina_init (and ecore_init, etc..)
The problem is that on the PS3, there is no pthread library so threads are
disabled on eina and eina_lock uses eina_inline_lock_void.x which just
returns FALSE/FAIL for every API call. This also causes another issue with
evas which slows it down because it tries a eina_lock_take_try (which
fails) and forces it to wait a bit before doing anything then it spams my
terminal with warnings about not being able to get a lock.
I would suggest to change the behavior of eina_lock (on 'void' platforms,
which do not support locks) to always return TRUE/SUCCEED so it doesn't
break everything below it.

What do you think ?

Thanks,
KaKaRoTo
--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina_lock_void issue

[Youness Alaoui]

On Sat, Jan 14, 2012 at 11:38 PM, Gustavo Sverzut Barbieri 
barbi...@profusion.mobi wrote:

 On Sun, Jan 15, 2012 at 2:19 AM, Michael Blumenkrantz
 michael.blumenkra...@gmail.com wrote:
  On Sat, 14 Jan 2012 23:15:37 -0500
  Youness Alaoui kakar...@kakaroto.homelinux.net wrote:
 
  Hi,
 
  I've just updated my EFL build for the PS3 and it was broken. eina_init
  isn't working anymore because eina_value doesn't init itself correctly.
 The
  issue is that if it's unable to iitialize a lock, it will fail the init
  which fails eina_init (and ecore_init, etc..)
  The problem is that on the PS3, there is no pthread library so threads
 are
  disabled on eina and eina_lock uses eina_inline_lock_void.x which just
  returns FALSE/FAIL for every API call. This also causes another issue
 with
  evas which slows it down because it tries a eina_lock_take_try (which
  fails) and forces it to wait a bit before doing anything then it spams
 my
  terminal with warnings about not being able to get a lock.
  I would suggest to change the behavior of eina_lock (on 'void'
 platforms,
  which do not support locks) to always return TRUE/SUCCEED so it doesn't
  break everything below it.
 
  What do you think ?
 
  Thanks,
  KaKaRoTo
  unfortunately this would be an api break since eina_lock was present in
 the 1.1
  release...

 actually a bug, then it must be fixed.


@Michael
That's true, it was in 1.1 release, but it wouldn't be an API break, rather
a behavior change (does that count as api break?)
But yes, it should be thought of careful, that's why I wrote the mail.
The thing is that a eina_lock on a system that does not support threads is
basically an undefined behavior (and as far as I know, it is not documented
how it would react in such a case).
How many systems do you have/support which make use of the eina_lock_void
(compiled without threads support) ?
Also, I'd actually think that this is the right behavior.. if you do
eina_lock_take on a system without threads, then it shouldn't fail as if
the other thread is still holding the lock.. it should tell you yes, you
can continue safely, so it should return TRUE.

@Gustavo:
yes it's a bug because right now, this configuration will not be able to
initialize anything. What did you mean by #ifdef if ? you mean only do the
lock init if threads are enabled ? That might fix the current bug of
eina_init failing, but it wouldn't fix the eina_lock_take_try issues I
discussed.
For now, locally, I made eina_lock return TRUE on the ps3, so I'm not
stuck, but I'd like to have this properly fixed, hopefully without any
hacks.

Thanks



 --
 Gustavo Sverzut Barbieri
 http://profusion.mobi embedded systems
 --
 MSN: barbi...@gmail.com
 Skype: gsbarbieri
 Mobile: +55 (19) 9225-2202


 --
 RSA(R) Conference 2012
 Mar 27 - Feb 2
 Save $400 by Jan. 27
 Register now!
 http://p.sf.net/sfu/rsa-sfdev2dev2
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina_lock_void issue

[Youness Alaoui]

On Sun, Jan 15, 2012 at 1:52 AM, David Seikel onef...@gmail.com wrote:

 On Sat, 14 Jan 2012 23:15:37 -0500 Youness Alaoui
 kakar...@kakaroto.homelinux.net wrote:

  Hi,
 
  I've just updated my EFL build for the PS3 and it was broken.
  eina_init isn't working anymore because eina_value doesn't init
  itself correctly. The issue is that if it's unable to iitialize a
  lock, it will fail the init which fails eina_init (and ecore_init,
  etc..) The problem is that on the PS3, there is no pthread library so
  threads are disabled on eina and eina_lock uses
  eina_inline_lock_void.x which just returns FALSE/FAIL for every API
  call. This also causes another issue with evas which slows it down
  because it tries a eina_lock_take_try (which fails) and forces it to
  wait a bit before doing anything then it spams my terminal with
  warnings about not being able to get a lock. I would suggest to
  change the behavior of eina_lock (on 'void' platforms, which do not
  support locks) to always return TRUE/SUCCEED so it doesn't break
  everything below it.

 I'm wondering how come a hyperthreaded CPU with a dozen extra
 specialized cores has no thread support?  It might not have pthread,
 but it might have some other sort of thread support that could be used
 instead?

Yes it has threads support, and the official SDK (Which we can't legally
use) has pthread, but we don't have an open source port of pthread to their
own system calls. So for now I'm working with it without threading support.
I will eventually (some day) port pthread to it then all of this will go
away, in the meantime, I prefer to concentrate on other things (it also
helped me find a few bugs in the EFL for when it gets compiled without
threads)


 --
 A big old stinking pile of genius that no one wants
 coz there are too many silver coated monkeys in the world.


 --
 RSA(R) Conference 2012
 Mar 27 - Feb 2
 Save $400 by Jan. 27
 Register now!
 http://p.sf.net/sfu/rsa-sfdev2dev2
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina_lock_void issue

[Youness Alaoui]

Yes I could, but I don't really see the point to be honest, I think porting
pthreads would be much more convenient rather than porting every library
that uses pthread into using the ps3 specific API. I just lack
time/motivation to do it, but it should be pretty straighforward...

On Sun, Jan 15, 2012 at 2:27 AM, Vincent Torri vincent.to...@gmail.comwrote:

 On Sun, Jan 15, 2012 at 8:06 AM, Youness Alaoui
 kakar...@kakaroto.homelinux.net wrote:
  On Sun, Jan 15, 2012 at 1:52 AM, David Seikel onef...@gmail.com wrote:
 
  On Sat, 14 Jan 2012 23:15:37 -0500 Youness Alaoui
  kakar...@kakaroto.homelinux.net wrote:
 
   Hi,
  
   I've just updated my EFL build for the PS3 and it was broken.
   eina_init isn't working anymore because eina_value doesn't init
   itself correctly. The issue is that if it's unable to iitialize a
   lock, it will fail the init which fails eina_init (and ecore_init,
   etc..) The problem is that on the PS3, there is no pthread library so
   threads are disabled on eina and eina_lock uses
   eina_inline_lock_void.x which just returns FALSE/FAIL for every API
   call. This also causes another issue with evas which slows it down
   because it tries a eina_lock_take_try (which fails) and forces it to
   wait a bit before doing anything then it spams my terminal with
   warnings about not being able to get a lock. I would suggest to
   change the behavior of eina_lock (on 'void' platforms, which do not
   support locks) to always return TRUE/SUCCEED so it doesn't break
   everything below it.
 
  I'm wondering how come a hyperthreaded CPU with a dozen extra
  specialized cores has no thread support?  It might not have pthread,
  but it might have some other sort of thread support that could be used
  instead?
 
  Yes it has threads support, and the official SDK (Which we can't legally
  use) has pthread, but we don't have an open source port of pthread to
 their
  own system calls. So for now I'm working with it without threading
 support.
  I will eventually (some day) port pthread to it then all of this will go
  away, in the meantime, I prefer to concentrate on other things (it also
  helped me find a few bugs in the EFL for when it gets compiled without
  threads)

 if there's thread support, you can try to use the native one, like i
 did for Windows, right ?

 Vincent


 --
 RSA(R) Conference 2012
 Mar 27 - Feb 2
 Save $400 by Jan. 27
 Register now!
 http://p.sf.net/sfu/rsa-sfdev2dev2
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eina_lock_void issue

[Youness Alaoui]

The PS3 OS's system call for threads/mutex/cond/sem is almost the same as
pthread, so it shouldn't be very compilcated.. I already ported
pthread-embeded to the ps3 but I don't like their implementation (and it
causes some issues with the newlib headers used by the toolchain.
I will think about it though, it might be easier to just write ps3 specific
code for it in eina. But it wouldn't help porting efforts of other non-efl
applications to the PS3 that depend on pthread.

On Sun, Jan 15, 2012 at 2:47 AM, Vincent Torri vincent.to...@gmail.comwrote:

 On Sun, Jan 15, 2012 at 8:40 AM, Youness Alaoui
 kakar...@kakaroto.homelinux.net wrote:
  Yes I could, but I don't really see the point to be honest, I think
 porting
  pthreads would be much more convenient rather than porting every library
  that uses pthread into using the ps3 specific API. I just lack
  time/motivation to do it, but it should be pretty straighforward...

 well, porting pthread to a system == being POSIX compliant (wrt
 threads) so it's not so simple. I saw the code of pthread-win32 and
 it's an horror (because of that). Just locking a mutex is complicated
 and in fine uses the win32 API. So i decided to use native win32 API.
 One call and that's all, it's faster than pthread-win32 and it
 consumes less memory.

 Vincent

 
  On Sun, Jan 15, 2012 at 2:27 AM, Vincent Torri vincent.to...@gmail.com
 wrote:
 
  On Sun, Jan 15, 2012 at 8:06 AM, Youness Alaoui
  kakar...@kakaroto.homelinux.net wrote:
   On Sun, Jan 15, 2012 at 1:52 AM, David Seikel onef...@gmail.com
 wrote:
  
   On Sat, 14 Jan 2012 23:15:37 -0500 Youness Alaoui
   kakar...@kakaroto.homelinux.net wrote:
  
Hi,
   
I've just updated my EFL build for the PS3 and it was broken.
eina_init isn't working anymore because eina_value doesn't init
itself correctly. The issue is that if it's unable to iitialize a
lock, it will fail the init which fails eina_init (and ecore_init,
etc..) The problem is that on the PS3, there is no pthread library
 so
threads are disabled on eina and eina_lock uses
eina_inline_lock_void.x which just returns FALSE/FAIL for every API
call. This also causes another issue with evas which slows it down
because it tries a eina_lock_take_try (which fails) and forces it
 to
wait a bit before doing anything then it spams my terminal with
warnings about not being able to get a lock. I would suggest to
change the behavior of eina_lock (on 'void' platforms, which do not
support locks) to always return TRUE/SUCCEED so it doesn't break
everything below it.
  
   I'm wondering how come a hyperthreaded CPU with a dozen extra
   specialized cores has no thread support?  It might not have pthread,
   but it might have some other sort of thread support that could be
 used
   instead?
  
   Yes it has threads support, and the official SDK (Which we can't
 legally
   use) has pthread, but we don't have an open source port of pthread to
  their
   own system calls. So for now I'm working with it without threading
  support.
   I will eventually (some day) port pthread to it then all of this will
 go
   away, in the meantime, I prefer to concentrate on other things (it
 also
   helped me find a few bugs in the EFL for when it gets compiled without
   threads)
 
  if there's thread support, you can try to use the native one, like i
  did for Windows, right ?
 
  Vincent
 
 
 
 --
  RSA(R) Conference 2012
  Mar 27 - Feb 2
  Save $400 by Jan. 27
  Register now!
  http://p.sf.net/sfu/rsa-sfdev2dev2
  ___
  enlightenment-devel mailing list
  enlightenment-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
 
 
 --
  RSA(R) Conference 2012
  Mar 27 - Feb 2
  Save $400 by Jan. 27
  Register now!
  http://p.sf.net/sfu/rsa-sfdev2dev2
  ___
  enlightenment-devel mailing list
  enlightenment-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


 --
 RSA(R) Conference 2012
 Mar 27 - Feb 2
 Save $400 by Jan. 27
 Register now!
 http://p.sf.net/sfu/rsa-sfdev2dev2
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] edje and epp

[Youness Alaoui]

On Sun, Jan 15, 2012 at 2:36 AM, Michael Blumenkrantz 
michael.blumenkra...@gmail.com wrote:

 On Sun, 15 Jan 2012 08:26:17 +0100
 Vincent Torri vincent.to...@gmail.com wrote:

  On Sun, Jan 15, 2012 at 8:06 AM, David Seikel onef...@gmail.com wrote:
   On Sun, 15 Jan 2012 08:00:06 +0100 Vincent Torri
   vincent.to...@gmail.com wrote:
  
   as we have epp source code, why creating a program and trying to
   execute it, instead of having a function that takes a buffer as input
   and create a preprocessed buffer as ouput ? Imho, it would be cleaner.
  
   I suspect the epp licence is the reason.
 
  aaaggg. You're right :(
 
  Vincent
 confirmed.

Humm.. edje is LGPL (afaik) and epp is GPL.. how about making edje_cc
(only) a GPLv2 app and keep the rest of the lib to its current license..
that could be a solution.



 --
 RSA(R) Conference 2012
 Mar 27 - Feb 2
 Save $400 by Jan. 27
 Register now!
 http://p.sf.net/sfu/rsa-sfdev2dev2
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] devilhorms: elementary broken

[Youness Alaoui]

Hi,
According to a user on #edevelop, the latest SVN version of elementary is
broken since SVN r67129, the following chang eintroduced by devilhorns
broke it :
http://trac.enlightenment.org/e/changeset/67129
This removes an API from ecore_evas which causes an undefined symbol in
libelementary : undefined symbol: ecore_evas_wayland_shm_resize
The changeset removes a function from the API without removing it from
Ecore_Evas.h and without removing its uses from libelementary
 (changelog/NEWS change is also missing, unless it was added in a later
commit)
Please fix it correctly, thank you,

KaKaRoTo
--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Edje aspect.preference big-endian issue

[Youness Alaoui]

On Fri, Jan 13, 2012 at 10:32 AM, Cedric BAIL cedric.b...@free.fr wrote:

 Hi,

 On Fri, Jan 13, 2012 at 8:12 AM, Youness Alaoui
 kakar...@kakaroto.homelinux.net wrote:
  I've had an issue recently when I tried to run my app (using edje) on the
  PS3, the aspect ratio of all the images were wrong, and it looked really
  bad. I investigated the issue and found out that the aspect_preference
 was
  the cause and that when it's set to  'BOTH' for example, the
  desc-aspect.prefer value is 50331648 which is.. 0x300 .. so it's a
 big
  endian vs. little endian issue since the EDJE_ASPECT_PREFER_BOTH value in
  the enum is '3'.
  So I figured the reading of the .edj is wrong, so I looked and it seems
 to
  read it as a 'EET_T_CHAR', but the structure contains the enum as type,
  which makes it an int.. so what happens is that it stores 1 byte (the
 char)
  in the 32bit variable.. on little endian, it's fine, it works, but on big
  endian, it makes the value huge. So I fixed it by changing the
 declaration
  of he 'aspect.prefer' structure to a char instead of the enum it
  represents. I tested and it seems to work and not break anything (and
 fixes
  the bug). However, since this seems a bit sensitive, I thought it's best
 to
  send the patch here to make sure I'm not doing something wrong.
  Thanks for reviewing this simple one liner patch :
 http://pastie.org/3176835
  I have noticed other structures do the same thing, 'fill mode' for
 example
  is defined as EET_T_UCHAR in the eet data description and as 'unsigned
  char' in the structure, that's why I fixed it this way. Note also that
 this
  shouldn't break the .edj file's compatibility or anything.

 Good, you figured out why it was broken. The fix sounds fine for me.
 Did you check that the only enum, we are using directly in one of our
 saved structure or should I check ?

Ok cool, I will commit it then. I checked and didn't see any other enum
being used, but I didn't do an extensive check. I will make sure it was the
only one and fix any other I might see.

Thanks,
KaKaRoTo



 Regards,
 --
 Cedric BAIL


 --
 RSA(R) Conference 2012
 Mar 27 - Feb 2
 Save $400 by Jan. 27
 Register now!
 http://p.sf.net/sfu/rsa-sfdev2dev2
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: barbieri IN trunk/eina/src: include lib tests

[Youness Alaoui]

You use 'timercmp' which is not POSIX and you're not checking for it in the
configure... you should use something else instead or provide a replacement
if it's not found.
After the include of sys/time.h, I added a simple :
#ifndef timercmp
#define ... /* copy/pasted from /usr/include/sys/time.h */
#endif

Should I commit that or wait until it's properly fixed ?

On Wed, Jan 11, 2012 at 9:26 PM, Michael Blumenkrantz 
michael.blumenkra...@gmail.com wrote:

 On Wed, 11 Jan 2012 17:31:21 -0800
 Enlightenment SVN no-re...@enlightenment.org wrote:

  Log:
  eina_value: add struct timeval.
 
may be useful for esskyuehl.
 
 
 
  Author:   barbieri
  Date: 2012-01-11 17:31:21 -0800 (Wed, 11 Jan 2012)
  New Revision: 67106
  Trac: http://trac.enlightenment.org/e/changeset/67106
 
  Modified:
trunk/eina/src/include/eina_value.h trunk/eina/src/lib/eina_value.c
  trunk/eina/src/tests/eina_test_value.c
 
 o


 --
 RSA(R) Conference 2012
 Mar 27 - Feb 2
 Save $400 by Jan. 27
 Register now!
 http://p.sf.net/sfu/rsa-sfdev2dev2
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: barbieri IN trunk/eina/src: include lib tests

[Youness Alaoui]

ok, that's another possible solution :)
Thanks, I'll revert my local changes then.

On Thu, Jan 12, 2012 at 11:45 AM, Gustavo Sverzut Barbieri 
barbi...@profusion.mobi wrote:

 On Thu, Jan 12, 2012 at 6:16 AM, Youness Alaoui
 kakar...@kakaroto.homelinux.net wrote:
  You use 'timercmp' which is not POSIX and you're not checking for it in
 the
  configure... you should use something else instead or provide a
 replacement
  if it's not found.
  After the include of sys/time.h, I added a simple :
  #ifndef timercmp
  #define ... /* copy/pasted from /usr/include/sys/time.h */
  #endif
 
  Should I commit that or wait until it's properly fixed ?

 nah, too much work... I'll do the manual comparison, it's trivial.


 --
 Gustavo Sverzut Barbieri
 http://profusion.mobi embedded systems
 --
 MSN: barbi...@gmail.com
 Skype: gsbarbieri
 Mobile: +55 (19) 9225-2202


 --
 RSA(R) Conference 2012
 Mar 27 - Feb 2
 Save $400 by Jan. 27
 Register now!
 http://p.sf.net/sfu/rsa-sfdev2dev2
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] Edje aspect.preference big-endian issue

[Youness Alaoui]

Hi,

I've had an issue recently when I tried to run my app (using edje) on the
PS3, the aspect ratio of all the images were wrong, and it looked really
bad. I investigated the issue and found out that the aspect_preference was
the cause and that when it's set to  'BOTH' for example, the
desc-aspect.prefer value is 50331648 which is.. 0x300 .. so it's a big
endian vs. little endian issue since the EDJE_ASPECT_PREFER_BOTH value in
the enum is '3'.
So I figured the reading of the .edj is wrong, so I looked and it seems to
read it as a 'EET_T_CHAR', but the structure contains the enum as type,
which makes it an int.. so what happens is that it stores 1 byte (the char)
in the 32bit variable.. on little endian, it's fine, it works, but on big
endian, it makes the value huge. So I fixed it by changing the declaration
of he 'aspect.prefer' structure to a char instead of the enum it
represents. I tested and it seems to work and not break anything (and fixes
the bug). However, since this seems a bit sensitive, I thought it's best to
send the patch here to make sure I'm not doing something wrong.
Thanks for reviewing this simple one liner patch : http://pastie.org/3176835
I have noticed other structures do the same thing, 'fill mode' for example
is defined as EET_T_UCHAR in the eet data description and as 'unsigned
char' in the structure, that's why I fixed it this way. Note also that this
shouldn't break the .edj file's compatibility or anything.

Thanks,
KaKaRoTo
--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: kakaroto trunk/edje/src/lib

[Youness Alaoui]

Alright, we reached the deadline (actually it was yesterday but I was busy)
and there's still no real agreement about this, however it seems most of
you want the patch reverted, so I will remove it and document it properly.

Thanks for your input.

On Mon, Jan 9, 2012 at 5:14 PM, Youness Alaoui 
kakar...@kakaroto.homelinux.net wrote:

 Bruno, while your example is valid, it's not how it will usually be. Most
 of the time people will use animations, which are bound to keyboard/mouse
 events.
 In my code for example, I can scroll a list using the arrow keys, but if
 you press the arrow twice, then two signals are sent, thus canceling the
 first animation.so the state of the swalowed object is undefined as it all
 depends on the elapsed milliseconds between the first and second press of
 the arrow key. I consider this a race condition.
 I also doubt that anyone is using edje, then suddenly unswallows the
 object and decides to keep it there and start to handle it manually in C.If
 he wanted to handle it in C directly, it wouldn't have been a swallowed
 part in the first place.
 i don't disagree though that this might chance the behavior of some really
 rare apps.
 As for trusting the .edj, you'd trust it to have specific groups/parts and
 handle/send specific signals, but you can't trust it to have an object as a
 specific position. The whole purpose of the edj is to allow the UI dev to
 decide where to position everything, what sizes to give them and what
 states.

 On Mon, Jan 9, 2012 at 11:19 AM, Bruno Dilly bdi...@profusion.mobiwrote:

 On Mon, Jan 9, 2012 at 2:13 PM, Cedric BAIL cedric.b...@free.fr wrote:
  On Mon, Jan 9, 2012 at 5:07 PM, Bruno Dilly bdi...@profusion.mobi
 wrote:
  On Mon, Jan 9, 2012 at 12:56 PM, Cedric BAIL cedric.b...@free.fr
 wrote:
  On Mon, Jan 9, 2012 at 3:46 PM, Bruno Dilly bdi...@profusion.mobi
 wrote:
  On Mon, Jan 9, 2012 at 11:26 AM, Cedric BAIL cedric.b...@free.fr
 wrote:
  On Mon, Jan 9, 2012 at 2:06 PM, Bruno Dilly bdi...@profusion.mobi
 wrote:
  On Sun, Jan 8, 2012 at 2:32 PM, Cedric BAIL cedric.b...@free.fr
 wrote:
  On Sun, Jan 8, 2012 at 3:47 PM, ChunEon Park her...@naver.com
 wrote:
  I think both are no problems if it has a documentation.
  But your patch may break applications already released.
  It will be better to apply your patch when major version is
 changed.
 
  As I say, current behaviour is undefined. If you go out of an
  animation (defined in the edj itself) in any state (hidden, moved,
  resized, whatever), it will stay in that state. But this is
 completly
  random and not defined (as in, depend on an external file). Now I
 do
  like the raster proposal with an orphaned flag as it is the only
 sane
  way to detect any leak. Relying on an undefined visual artefact
 would
  not help at all.
 
  It isn't documented. But it's defined, IMHO, since you can predict
 it.
  As you said, in an animation it will keep the state, if it was
  visible, it will stay visible.
  So applications can be considering a unswallowed object will be
  visible, since it was visible, and now it will be hidden.
 
  No, as it is defined in the theme, it doesn't depend on the
  application. If you change the theme, the animation, anything in the
  .edj, it will change the behaviour in the application itself. It's
  full of race condition. There is no sane way to expect any kind of
  behaviour in the app. It is definitivly an undefined behaviour, as
  their is no way you could know the state of the object without
  requesting it after the unswallow.
 
  OK, my concept of application is code and theme.
  Anyway, a simple case is to add an rectangle to a swallow in a
 layout.
  I've attached a quick example. As you can see, no luck required.
 After
  3 seconds the rectangle is unswallowed and displayed at 0,0.
 
  Ok, I see the difference. From my point of view, the application
  should never trust an edj file. So if I can break your consistent
  behaviour by just touching the edc file, then their is a bug in the
  application from my point of view. In your example. I just need to set
  visible: 0, or rel1.relative: 0 0; and rel2.relative: 0 0; to break
  your app. So you are just lucky that no one touched your edc file.
 
  Ok, but don't you trust the edj file will have a swallow with name X
 ?
  It's easy to break an application changing the edj if you want to do
 so.
 
  You know that edje_object_part_swallow return an EINA_BOOL, do you ?

 I do, you can print something in your terminal and quit the
 application. What doesn't mean it is not working as intended.

 Anyway, there are signals that should be emitted to code and you don't
 emit that on your theme. So it will break your application and you
 can't detect.
 Going further, you can make every part invisible, and you application
 will be completely useless.

 So, yeah, I believe you need to trust your edj someway, and they need
 to be considered part of the application.

  --
  Cedric BAIL

Re: [E-devel] E SVN: kakaroto trunk/edje/src/lib

[Youness Alaoui]

Bruno, while your example is valid, it's not how it will usually be. Most
of the time people will use animations, which are bound to keyboard/mouse
events.
In my code for example, I can scroll a list using the arrow keys, but if
you press the arrow twice, then two signals are sent, thus canceling the
first animation.so the state of the swalowed object is undefined as it all
depends on the elapsed milliseconds between the first and second press of
the arrow key. I consider this a race condition.
I also doubt that anyone is using edje, then suddenly unswallows the object
and decides to keep it there and start to handle it manually in C.If he
wanted to handle it in C directly, it wouldn't have been a swallowed part
in the first place.
i don't disagree though that this might chance the behavior of some really
rare apps.
As for trusting the .edj, you'd trust it to have specific groups/parts and
handle/send specific signals, but you can't trust it to have an object as a
specific position. The whole purpose of the edj is to allow the UI dev to
decide where to position everything, what sizes to give them and what
states.

On Mon, Jan 9, 2012 at 11:19 AM, Bruno Dilly bdi...@profusion.mobi wrote:

 On Mon, Jan 9, 2012 at 2:13 PM, Cedric BAIL cedric.b...@free.fr wrote:
  On Mon, Jan 9, 2012 at 5:07 PM, Bruno Dilly bdi...@profusion.mobi
 wrote:
  On Mon, Jan 9, 2012 at 12:56 PM, Cedric BAIL cedric.b...@free.fr
 wrote:
  On Mon, Jan 9, 2012 at 3:46 PM, Bruno Dilly bdi...@profusion.mobi
 wrote:
  On Mon, Jan 9, 2012 at 11:26 AM, Cedric BAIL cedric.b...@free.fr
 wrote:
  On Mon, Jan 9, 2012 at 2:06 PM, Bruno Dilly bdi...@profusion.mobi
 wrote:
  On Sun, Jan 8, 2012 at 2:32 PM, Cedric BAIL cedric.b...@free.fr
 wrote:
  On Sun, Jan 8, 2012 at 3:47 PM, ChunEon Park her...@naver.com
 wrote:
  I think both are no problems if it has a documentation.
  But your patch may break applications already released.
  It will be better to apply your patch when major version is
 changed.
 
  As I say, current behaviour is undefined. If you go out of an
  animation (defined in the edj itself) in any state (hidden, moved,
  resized, whatever), it will stay in that state. But this is
 completly
  random and not defined (as in, depend on an external file). Now I
 do
  like the raster proposal with an orphaned flag as it is the only
 sane
  way to detect any leak. Relying on an undefined visual artefact
 would
  not help at all.
 
  It isn't documented. But it's defined, IMHO, since you can predict
 it.
  As you said, in an animation it will keep the state, if it was
  visible, it will stay visible.
  So applications can be considering a unswallowed object will be
  visible, since it was visible, and now it will be hidden.
 
  No, as it is defined in the theme, it doesn't depend on the
  application. If you change the theme, the animation, anything in the
  .edj, it will change the behaviour in the application itself. It's
  full of race condition. There is no sane way to expect any kind of
  behaviour in the app. It is definitivly an undefined behaviour, as
  their is no way you could know the state of the object without
  requesting it after the unswallow.
 
  OK, my concept of application is code and theme.
  Anyway, a simple case is to add an rectangle to a swallow in a layout.
  I've attached a quick example. As you can see, no luck required. After
  3 seconds the rectangle is unswallowed and displayed at 0,0.
 
  Ok, I see the difference. From my point of view, the application
  should never trust an edj file. So if I can break your consistent
  behaviour by just touching the edc file, then their is a bug in the
  application from my point of view. In your example. I just need to set
  visible: 0, or rel1.relative: 0 0; and rel2.relative: 0 0; to break
  your app. So you are just lucky that no one touched your edc file.
 
  Ok, but don't you trust the edj file will have a swallow with name X ?
  It's easy to break an application changing the edj if you want to do so.
 
  You know that edje_object_part_swallow return an EINA_BOOL, do you ?

 I do, you can print something in your terminal and quit the
 application. What doesn't mean it is not working as intended.

 Anyway, there are signals that should be emitted to code and you don't
 emit that on your theme. So it will break your application and you
 can't detect.
 Going further, you can make every part invisible, and you application
 will be completely useless.

 So, yeah, I believe you need to trust your edj someway, and they need
 to be considered part of the application.

  --
  Cedric BAIL
 
 
 --
  Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
  infrastructure or vast IT resources to deliver seamless, secure access to
  virtual desktops. With this all-in-one solution, easily deploy virtual
  desktops for less than the cost of PCs and save 60% on VDI infrastructure
  costs. Try 

Re: [E-devel] E SVN: kakaroto trunk/edje/src/lib

[Youness Alaoui]

@Gustavo: I understand your point about leaks but I'd expect a developer to
not need a visual aid for him to write proper code. Not leaking is standard
programing knowledge, so it's not about being novice in using the EFL.
My issue is that I don't want to destroy the objects, just hide them
(scrolling a list, I unswallow non visible objects and swallow the new
ones). I've had this bug for a while and I didn't understand that I had to
hide the objects, for me, the unswallow means it does not appear anymore. I
use an edje object, I swallow/unswallow objects to it, that's it, I don't
need to know that after I unswallow it will suddenly pop and look like an
artifact on screen or whatever.
Also, I never did a evas_object_show() on it, so there's no reason for me
to do the evas_object_hide(). One could argue that during the swallow, edje
should check what was the previous state (shown/hidden) and restore to that
state when you unswallow.
also, in my case, it would only be visible if I cancel the
animation/state change and that leaves the object in a weird state
(wherever it was left in the animation), but if I don't scroll too fast or
whatever, the part goes to a state of visible:0 (with 0x0 geometry) before
the unswallow happens, so it really wasn't an aid unless some weird race
condition happens then I get a weird artifact on screen. Talking as a
novice, this was clearly not an indication to hide the object but rather a
wtf moment getting me to hunt down the bug in edje.

@Ivan, @Michael. I discussed this with Cedric before doing the commit, I
wanted to make sure whether or not I should do the hide in my code or in
edje directly. We discussed it and the conclusion was that it was not
documented, so it's unexpected behavior. It shouldn't affect anyone
because I doubt someone unswallows an object then expects it to stay shown
on evas. There is a change in behavior, but it goes from unexpected to
expected so it's not a major change.
You are right though, I will document it and put it in the changelog/news.

@all: I don't mind reverting the change either way. I already hide it in my
code (since I'd like to stay compatible with the 1.1 release), so let's
discuss it, should the behavior be expected to hide the object, to leave it
in whatever state it was before the unswallow (which could be weird if it
happens during an animation), to restore the state to what it was before
the swallow was called ? any other suggestions?

Thanks,
KaKaRoTo

On Sat, Jan 7, 2012 at 4:35 PM, Cedric BAIL cedric.b...@free.fr wrote:

 On Sat, Jan 7, 2012 at 7:21 PM, Michael Blumenkrantz
 michael.blumenkra...@gmail.com wrote:
  On Sat, 7 Jan 2012 18:16:04 +
  Iván Briano (Sachiel) sachi...@gmail.com wrote:
 
  2012/1/7 Gustavo Sverzut Barbieri barbi...@profusion.mobi:
   On Sat, Jan 7, 2012 at 9:39 AM, Enlightenment SVN
   no-re...@enlightenment.org wrote:
   Log:
   Edje: hide an object after unswallow
Simply doing an unswallow would leave the object where it was in the
evas, visible, but edje would not be handling it anymore.
  
   nah, you're supposed to do this in the application or edje user. Very
   likely you'll delete the object, sometimes hide it.
  
   If you hide by default, novice will not see the object and will
   leak... it's like a warning.
  
 
  And if for some reason the change stays in, it's one of those
  very special things that deserve big bold letters in Changelog
  and NEWS files.
 
  I'm pretty sure it's wrong to implement things that completely change
 expected
  behavior like this in a non-major version...

 It's not changing any expected behaviour. When edje unswallow an
 object, you are not supposed to expect it in any particular state. Now
 you can expect it to be hidden. That's just what it does. It defines
 the output state, something that wasn't before.

 The point that make sense is the one that Gustavo raise. With previous
 behaviour, in some case you will notice that an object was not handle
 by edje anymore, because it was visibly lying around. I may be wrong,
 but if the part was not visible, unswallow would have issued an hidden
 object, like this patch does. So I don't know now, if the best is to
 force its visibility or to hide.
 --
 Cedric BAIL


 --
 Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
 infrastructure or vast IT resources to deliver seamless, secure access to
 virtual desktops. With this all-in-one solution, easily deploy virtual
 desktops for less than the cost of PCs and save 60% on VDI infrastructure
 costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
Ridiculously easy VDI. With Citrix 

Re: [E-devel] E SVN: kakaroto trunk/ecore/src/lib/ecore_con

[Youness Alaoui]

No, on the ps3 :)

On Sat, Jan 7, 2012 at 9:10 AM, Michael Blumenkrantz 
michael.blumenkra...@gmail.com wrote:

 On Sat,  7 Jan 2012 03:39:23 -0800
 Enlightenment SVN no-re...@enlightenment.org wrote:

  Log:
  Ecore-con: Let's not break compilation if net/if.h is not found (or old
  system)
 
  Author:   kakaroto
  Date: 2012-01-07 03:39:23 -0800 (Sat, 07 Jan 2012)
  New Revision: 66956
  Trac: http://trac.enlightenment.org/e/changeset/66956
 
  Modified:
trunk/ecore/src/lib/ecore_con/ecore_con_socks.c

 compiling on debian sarge again, eh?


 --
 Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
 infrastructure or vast IT resources to deliver seamless, secure access to
 virtual desktops. With this all-in-one solution, easily deploy virtual
 desktops for less than the cost of PCs and save 60% on VDI infrastructure
 costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel