ACPI trouble (AC module, etc.) with Toshiba 1115-S103

ACPI trouble (AC module, etc.) with Toshiba 1115-S103

[NoZizzing OrDripping]

[-- Attachment #1: Type: text/plain, Size: 248 bytes --]

Sorry, I have to send to this list from my Yahoo
account. Mail body attached as file to prevent wrap.

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[-- Attachment #2: report1.txt --]
[-- Type: text/plain, Size: 2790 bytes --]


Status report for Toshiba Satellite 1115-S103 laptop....

Just tried 2.4.20 + acpi-20021205-2.4.20.diff with a Toshiba Satellite
1115-s103 laptop (new model, BIOS is "first production release", dated
11/01/2002, street price is between $650 and $1000, depending on
rebates).  Built it all-modular and with debug messages.

	$ ls /lib/modules/*20/kernel/drivers/acpi
	ac.o  battery.o  button.o  fan.o  processor.o  thermal.o  toshiba_acpi.o

	$ root modprobe battery; dmesg
	ACPI: Battery Slot [BAT1] (battery present)

The module loaded and the Gnome battery monitor seems to work.  Pulled
AC power and watched battery drain down to 8%, then plugged AC back
in and watched it recharge.

	$ root modprobe ac; dmesg

	exfldio-0122 [31] Ex_setup_region       : Field [ACPW] Base+Offset+Width 38+0+4 is beyond end of region [GPIO] (length 3B)
	psparse-1103: *** Error: Method execution failed [\_SB_.PCI0.LPCB.ACAD._PSR] (Node c1671948), AE_AML_REGION_LIMIT
	acpi_ac-0083 [15] acpi_ac_get_state     : Error reading AC Adapter state

The AC module gives the above error message.  No files appear under
/proc/acpi/ac_adapter.  The Gnome battery status monitor always
indicates the laptop is on battery power.

Interestingly enough, my only previous ACPI experience was with the
stock Redhat 2.4.18 kernel recompiled with non-modular ACPI turned on.
In that case, the AC status worked, but the battery status was flaky.

	$ root modprobe processor; dmesg

	ACPI: Processor [CPU0] (supports C1 C2, 8 throttling states)

	$ root modprobe button; dmesg

	ACPI: Power Button (FF) [PWRF]
	ACPI: Lid Switch [LID]

	$ root modprobe fan; dmesg

	[ no output]

	$ root modprobe thermal; dmesg

	[ no output]

Dunno if any of the above stuff works.

	$ root modprobe toshiba_acpi

	/lib/modules/2.4.20/kernel/drivers/acpi/toshiba_acpi.o: init_module: No such device
	Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters.
	      You may find more information in syslog or the output from dmesg
	/lib/modules/2.4.20/kernel/drivers/acpi/toshiba_acpi.o: insmod /lib/modules/2.4.20/kernel/drivers/acpi/toshiba_acpi.o failed
	/lib/modules/2.4.20/kernel/drivers/acpi/toshiba_acpi.o: insmod toshiba_acpi failed

Dunno if this was supposed to work or not.  The laptop has an extremely
limited BIOS, you cannot change very much at all with it.


Fooled around abit, unloaded battery.o and tried to reload it,
but system locked up.

BTW, I am willing to try additional patches, etc, to help get ACPI
solid in general and specifically on this laptop.

-Rick


-- 
Rick Richardson  rickr-EySxSuIQeMUAvxtiuMwx3w@public.gmane.org        http://home.mn.rr.com/richardsons/
Stock information at your fingertips:   http://linuxtrade.0catch.com/

"@%#$^@&" - Ozzy Osbourne

Re: ACPI trouble (AC module, etc.) with Toshiba 1115-S103

[Ducrot Bruno]

On Mon, Dec 09, 2002 at 10:59:22PM -0800, NoZizzing OrDripping wrote:
> 
> Status report for Toshiba Satellite 1115-S103 laptop....
> 
> Just tried 2.4.20 + acpi-20021205-2.4.20.diff with a Toshiba Satellite
> 1115-s103 laptop (new model, BIOS is "first production release", dated
> 11/01/2002, street price is between $650 and $1000, depending on
> rebates).  Built it all-modular and with debug messages.
> 
> 	$ ls /lib/modules/*20/kernel/drivers/acpi
> 	ac.o  battery.o  button.o  fan.o  processor.o  thermal.o  toshiba_acpi.o
> 
> 	$ root modprobe battery; dmesg
> 	ACPI: Battery Slot [BAT1] (battery present)
> 
> The module loaded and the Gnome battery monitor seems to work.  Pulled
> AC power and watched battery drain down to 8%, then plugged AC back
> in and watched it recharge.
> 
> 	$ root modprobe ac; dmesg
> 
> 	exfldio-0122 [31] Ex_setup_region       : Field [ACPW] Base+Offset+Width 38+0+4 is beyond end of region [GPIO] (length 3B)
> 	psparse-1103: *** Error: Method execution failed [\_SB_.PCI0.LPCB.ACAD._PSR] (Node c1671948), AE_AML_REGION_LIMIT
> 	acpi_ac-0083 [15] acpi_ac_get_state     : Error reading AC Adapter state
> 

Known issue with most of the Toshiba Satellite series with a Phoenix
BIOS.  I guess that Toshiba (or in fact Compal) still don't
know how to debug correctly their ASLs.

You need a patched DSDT for this model.  Please send me your DSDT.
BTW, I think that my tosh3k kernel module at
ftp://ftp.poupinou.org/tosh_3000/
will work for you.  I am in process of rewrite it a little, then I think
that I can probably add your model if you agree.


[...]

> 	$ root modprobe toshiba_acpi
> 
> 	/lib/modules/2.4.20/kernel/drivers/acpi/toshiba_acpi.o: init_module: No such device
> 	Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters.
> 	      You may find more information in syslog or the output from dmesg
> 	/lib/modules/2.4.20/kernel/drivers/acpi/toshiba_acpi.o: insmod /lib/modules/2.4.20/kernel/drivers/acpi/toshiba_acpi.o failed
> 	/lib/modules/2.4.20/kernel/drivers/acpi/toshiba_acpi.o: insmod toshiba_acpi failed

The toshiba acpi support would probably not work for you, because your BIOS is
a Phoenix one, not a Toshiba one.

> 
> Dunno if this was supposed to work or not.  The laptop has an extremely
> limited BIOS, you cannot change very much at all with it.

This is a 'legacy-free' bios...

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: ACPI trouble (AC module, etc.) with Toshiba 1115-S103

[NoZizzing OrDripping]

[-- Attachment #1: Type: text/plain, Size: 2065 bytes --]

--- Ducrot Bruno <ducrot-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org> wrote:
> On Mon, Dec 09, 2002 at 10:59:22PM -0800, NoZizzing
> OrDripping wrote:
> > 
> > Status report for Toshiba Satellite 1115-S103
> laptop....
> > 
> > 	$ root modprobe ac; dmesg
> > 
> > 	exfldio-0122 [31] Ex_setup_region       : Field
> [ACPW] Base+Offset+Width 38+0+4 is beyond end of
> region [GPIO] (length 3B)
> > 	psparse-1103: *** Error: Method execution failed
> [\_SB_.PCI0.LPCB.ACAD._PSR] (Node c1671948),
> AE_AML_REGION_LIMIT
> > 	acpi_ac-0083 [15] acpi_ac_get_state     : Error
> reading AC Adapter state
> > 
> 
> Known issue with most of the Toshiba Satellite
> series with a Phoenix
> BIOS.  I guess that Toshiba (or in fact Compal)
> still don't
> know how to debug correctly their ASLs.
> 
> You need a patched DSDT for this model.  Please send
> me your DSDT.

OK, I went thru the process of creating a modified
ASL (diffs from the original attached) for this
laptop.
Basically, I cleaned up the original so that the
errors
from "iasl" went away.

I now have a working AC module.

This is a stopgap measure though, correct?  The goal
should be for the Linux kernel to support the existing
AML in flash (the AML apparently comes from Microsoft)
on these laptops.  The BIOS on these machines is about
as fresh as it gets (Nov, 2002).  It seems to me that
the Intel ASL compiler and interpreter needs to be
changed/relaxed to accomodate what has become a
defacto
(de-gates-o) standard here.

As a practical matter, I can't imagine non-programmer
types having to modify their ASL code to make Linux
work on their laptops, and I can't imagine that Ducrot
wants to be the single, worldwide point, for modified
ASL code.

Would the ACPI developers be receptive if I made the
changes necessary to allow the kernel ACPI code to
accept the existing AML in my laptop as-is?

-Rick Richardson
rickr-EySxSuIQeMUAvxtiuMwx3w@public.gmane.org

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[-- Attachment #2: tosh1115-s103.asl.diff --]
[-- Type: application/octet-stream, Size: 6139 bytes --]

--- tosh1115-s103-orig.asl	2002-12-11 00:27:03.000000000 -0600
+++ tosh1115-s103-linux.asl	2002-12-11 00:27:41.000000000 -0600
@@ -1,4 +1,4 @@
-
+/*
 
 AD - ACPI Dump. Version 0.91. Jan 09 2002
 Copyright (C) 2001 by Phoenix Technologies, Ltd. All Rights Reserved.
@@ -13,7 +13,7 @@
 Creator ID:       'MSFT'
 Creator Revision: 0x0100000D
 
-
+*/
 DefinitionBlock("DSDT.AML","DSDT",1,"TOSCPL","BTK20   ",0x6040000)
 {
     OperationRegion(PORT,SystemIo,0x80,0x01)
@@ -408,6 +408,7 @@
                 \_SB.PCI0.LPCB.PHSS(0x0F)
             }
         }
+	Return(Package(2) {0, 0})
     }
     Scope(_GPE)
     {
@@ -624,7 +625,7 @@
                 FTT,1
             }
             OperationRegion(ECR,EmbeddedControl,0x00,0xFF)
-            Field(ECR /* \_SB.EPWR.ECR */,AnyAcc,Lock,Preserve)
+            Field(ECR /* \_SB.EPWR.ECR */,/*RER AnyAcc*/ByteAcc,Lock,Preserve)
             {
                 Offset(0x9E),
                 ,4,
@@ -684,14 +685,14 @@
             }
             Method(BATC,1,NotSerialized)
             {
-                Divide(0x0FA0,0x64,,Local1)
+                Divide(0x0FA0,0x64,Local1)
                 If(LEqual(Arg0,0x00))
                 {
-                    Divide(\_SB.PCI0.LPCB.EC0.BRC0,Local1,,Local2)
+                    Divide(\_SB.PCI0.LPCB.EC0.BRC0,Local1,Local2)
                 }
                 Else
                 {
-                    Divide(\_SB.PCI0.LPCB.EC0.BRC1,Local1,,Local2)
+                    Divide(\_SB.PCI0.LPCB.EC0.BRC1,Local1,Local2)
                 }
                 Return(Local2)
             }
@@ -770,14 +771,14 @@
             }
             Method(BAT0,0,NotSerialized)
             {
-                Divide(0x0FA0,0x64,,Local1)
-                Divide(\_SB.PCI0.LPCB.EC0.BRC0,Local1,,Local2)
+                Divide(0x0FA0,0x64,Local1)
+                Divide(\_SB.PCI0.LPCB.EC0.BRC0,Local1,Local2)
                 Return(Local2)
             }
             Method(BAT1,0,NotSerialized)
             {
                 Multiply(\_SB.PCI0.LPCB.EC0.BRC1,0x64,Local1)
-                Divide(Local1,0x1194,,Local2)
+                Divide(Local1,0x1194,Local2)
                 Return(Local2)
             }
             Method(ISTA,1,NotSerialized)
@@ -1733,7 +1734,7 @@
                         //                          properly
                         //                   [4]    1 = Device is attached
                         //                          
-[31:5]	Reserved.
+//[31:5]	Reserved.
                         //
                         {
                             \_SB.PCI0.LPCB.PHSS(0x0C)
@@ -1877,7 +1878,7 @@
                         //                          properly
                         //                   [4]    1 = Device is attached
                         //                          
-[31:5]	Reserved.
+//[31:5]	Reserved.
                         //
                         {
                             Store("LCD --_DCS",Debug)
@@ -2011,7 +2012,7 @@
                         //                          properly
                         //                   [4]    1 = Device is attached
                         //                          
-[31:5]	Reserved.
+//[31:5]	Reserved.
                         //
                         {
                             \_SB.PCI0.LPCB.PHSS(0x0C)
@@ -2218,7 +2219,7 @@
                             Store(One,TVAA /* \_SB.PCI0.AGPB.VGA.TVAA */)
                         }
                         // Notify 0x80 - 
- **** unknown object notifiation value 
+// **** unknown object notifiation value 
                         Notify(\_SB.PCI0.AGPB.VGA,0x80)
                     }
                 }
@@ -2736,7 +2737,7 @@
                     PMEE,1,
                     US3E,1
                 }
-                OperationRegion(GPIO,SystemIo,0x1180,0x3B)
+                OperationRegion(GPIO,SystemIo,0x1180,/*RER 0x3B*/ 0x3C)
                 Field(GPIO /* \_SB.PCI0.LPCB.GPIO */,WordAcc,Lock,Preserve)
                 {
                     AccessAs(DWordAcc,0x00),
@@ -7267,7 +7268,7 @@
                         }
                     }
                     OperationRegion(ERAM,EmbeddedControl,0x00,0xFF)
-                    Field(ERAM /* \_SB.PCI0.LPCB.EC0.ERAM */,AnyAcc,Lock,Preserve)
+                    Field(ERAM /* \_SB.PCI0.LPCB.EC0.ERAM */,/*RER AnyAcc*/ByteAcc,Lock,Preserve)
                     {
                         Offset(0x2E),
                         RSMT,16,
@@ -7379,7 +7380,7 @@
                             PHSS /* \_SB.PCI0.LPCB.PHSS */(0x08)
                             Store(0x00,\_SB.PCI0.LPCB.EC0.BRGT)
                             // Notify 0x81 - 
- **** unknown object notifiation value 
+// **** unknown object notifiation value 
                             Notify(EPWR /* \_SB.EPWR */,0x81)
                         }
                     }
@@ -7423,7 +7424,7 @@
                             }
                             Store(0x00,\_SB.PCI0.LPCB.EC0.SKEY)
                             // Notify 0x82 - 
- **** unknown object notifiation value 
+// **** unknown object notifiation value 
                             Notify(EPWR /* \_SB.EPWR */,0x82)
                         }
                     }
@@ -7474,7 +7475,7 @@
                         TSTS,1
                     }
                     OperationRegion(ECRM,EmbeddedControl,0x00,0xFF)
-                    Field(ECRM /* \_SB.PCI0.LPCB.EC0.ECRM */,AnyAcc,Lock,Preserve)
+                    Field(ECRM /* \_SB.PCI0.LPCB.EC0.ECRM */,/*RER AnyAcc*/ByteAcc,Lock,Preserve)
                     {
                         Offset(0xAE),
                         PTVL,3,
@@ -8317,6 +8318,7 @@
                         Return(Buffer(0x14){0x78,0x00,0x00,0x00,0x08,0x00,0x00,0x00,
                                 0x78,0x00,0x00,0x00,0x08,0x00,0x00,0x00,
                                 0x1F,0x00,0x00,0x00})
+			/* RER: Warning here is OK */
                         Name(PBUF,Buffer(0x14){0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
                                 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
                                 0x00,0x00,0x00,0x00})

Re: ACPI trouble (AC module, etc.) with Toshiba 1115-S103

[Derek Broughton]

From: "NoZizzing OrDripping" <nozizzingordripping-/E1597aS9LQAvxtiuMwx3w@public.gmane.org>
>
> OK, I went thru the process of creating a modified
> ASL (diffs from the original attached) for this
> laptop.
> Basically, I cleaned up the original so that the
> errors
> from "iasl" went away.
>
> I now have a working AC module.
>
> This is a stopgap measure though, correct?  The goal
> should be for the Linux kernel to support the existing
> AML in flash (the AML apparently comes from Microsoft)

Not if it doesn't conform to the ACPI spec. I wouldn't have a clue if this
does - but MS is well known for going their own way.  If that was the case, then
the goal would be to get your PC vendor to get a correct DSDT - we shouldn't be
trying to make ACPI work with every possible broken BIOS.



-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: ACPI trouble (AC module, etc.) with Toshiba 1115-S103

[Ducrot Bruno]

On Tue, Dec 10, 2002 at 10:58:26PM -0800, NoZizzing OrDripping wrote:
> --- Ducrot Bruno <ducrot-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org> wrote:


...

> 
> OK, I went thru the process of creating a modified
> ASL (diffs from the original attached) for this
> laptop.
> Basically, I cleaned up the original so that the
> errors
> from "iasl" went away.
> 
> I now have a working AC module.
> 
> This is a stopgap measure though, correct?  The goal
> should be for the Linux kernel to support the existing
> AML in flash (the AML apparently comes from Microsoft)

No, it come from your BIOS.  Microsoft make only a
interpreter for it, as for ACPI-CA.

> on these laptops.  The BIOS on these machines is about
> as fresh as it gets (Nov, 2002).  It seems to me that
> the Intel ASL compiler and interpreter needs to be
> changed/relaxed to accomodate what has become a
> defacto
> (de-gates-o) standard here.
> 
> As a practical matter, I can't imagine non-programmer
> types having to modify their ASL code to make Linux
> work on their laptops, and I can't imagine that Ducrot
> wants to be the single, worldwide point, for modified

No, I don't want to.  FreeBSD acpi team is good also for
this stuff as well.

> Would the ACPI developers be receptive if I made the
> changes necessary to allow the kernel ACPI code to
> accept the existing AML in my laptop as-is?

It's up to Intel ACPI guy to decide, but if I were them,
I will _not_ allow to do the same kind of bug as MS.

Imagine if they have to program as a MS developper...

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: ACPI trouble (AC module, etc.) with Toshiba 1115-S103

[NoZizzing OrDripping]

--- Ducrot Bruno <ducrot-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org> wrote:
> On Mon, Dec 09, 2002 at 10:59:22PM -0800, NoZizzing
> OrDripping wrote:
> > 
> > Status report for Toshiba Satellite 1115-S103
> laptop....
> > 
> > Just tried 2.4.20 + acpi-20021205-2.4.20.diff with
> a Toshiba Satellite
> > 1115-s103 laptop (new model, BIOS is "first
> production release", dated
> > 11/01/2002, street price is between $650 and
> $1000, depending on
> > rebates).  Built it all-modular and with debug
> messages.
> > 	$ root modprobe ac; dmesg
> > 
> > 	exfldio-0122 [31] Ex_setup_region       : Field
> [ACPW] Base+Offset+Width 38+0+4 is beyond end of
> region [GPIO] (length 3B)

> Known issue with most of the Toshiba Satellite
> series with a Phoenix
> BIOS.  I guess that Toshiba (or in fact Compal)
> still don't
> know how to debug correctly their ASLs.
> 
> You need a patched DSDT for this model.

I don't believe that Toshiba/Microsoft will ever
change their ways.  This is a brand new model.
However, it looks to me like I could easily make
a kernel patch to add a CONFIG_ACPI_RELAXED
configuration option that will allow these ASL
mistakes, such as off-by-one on region size, to
be accepted.  That would allow people to use many
broken DSDT's without having to go thru all of the
trouble of the current method of DSDT overriding.

> BTW, I think that my tosh3k kernel module at
> ftp://ftp.poupinou.org/tosh_3000/
> will work for you.  I am in process of rewrite it a
> little, then I think that I can probably add your
> model if you agree.

Yes, it works with the simple addition of this model
to the list...
{ "TOSHIBA", "Satellite 1115", "" },


> the output from dmesg
> > 
>
/lib/modules/2.4.20/kernel/drivers/acpi/toshiba_acpi.o:
> insmod
>
/lib/modules/2.4.20/kernel/drivers/acpi/toshiba_acpi.o
> failed
> > 
>
/lib/modules/2.4.20/kernel/drivers/acpi/toshiba_acpi.o:
> insmod toshiba_acpi failed
> 
> The toshiba acpi support would probably not work for
> you, because your BIOS is
> a Phoenix one, not a Toshiba one.
> 
> > 
> > Dunno if this was supposed to work or not.  The
> laptop has an extremely
> > limited BIOS, you cannot change very much at all
> with it.
> 
> This is a 'legacy-free' bios...
> 
> -- 
> Ducrot Bruno
> 
> --  Which is worse:  ignorance or apathy?
> --  Don't know.  Don't care.


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com


-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: ACPI trouble (AC module, etc.) with Toshiba 1115-S103

[Ducrot Bruno]

On Thu, Dec 12, 2002 at 04:43:16PM -0800, NoZizzing OrDripping wrote:
> 
> --- Ducrot Bruno <ducrot-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org> wrote:
> > On Mon, Dec 09, 2002 at 10:59:22PM -0800, NoZizzing
> > OrDripping wrote:
> > > 
> > > Status report for Toshiba Satellite 1115-S103
> > laptop....
> > > 
> > > Just tried 2.4.20 + acpi-20021205-2.4.20.diff with
> > a Toshiba Satellite
> > > 1115-s103 laptop (new model, BIOS is "first
> > production release", dated
> > > 11/01/2002, street price is between $650 and
> > $1000, depending on
> > > rebates).  Built it all-modular and with debug
> > messages.
> > > 	$ root modprobe ac; dmesg
> > > 
> > > 	exfldio-0122 [31] Ex_setup_region       : Field
> > [ACPW] Base+Offset+Width 38+0+4 is beyond end of
> > region [GPIO] (length 3B)
> 
> > Known issue with most of the Toshiba Satellite
> > series with a Phoenix
> > BIOS.  I guess that Toshiba (or in fact Compal)
> > still don't
> > know how to debug correctly their ASLs.
> > 
> > You need a patched DSDT for this model.
> 
> I don't believe that Toshiba/Microsoft will ever
> change their ways.  This is a brand new model.
> However, it looks to me like I could easily make
> a kernel patch to add a CONFIG_ACPI_RELAXED
> configuration option that will allow these ASL
> mistakes, such as off-by-one on region size, to
> be accepted.  That would allow people to use many
> broken DSDT's without having to go thru all of the
> trouble of the current method of DSDT overriding.

MS miss the check bounding in their AML interpreter, _but_
not in MS XP.  Though, your new brand model could potentially
have the exact same problem with this OS as well.  Really,
this up to Toshiba to debug their DSDT for their Satellites.
Actually, they have to cry to the real ODM, the real manufacturer
of allmost of their Satellite models, that is Compal.
(http://www.compal.com).

A 'real' Toshiba shipping a toshiba bios do not have this bug.
(it has others, but it was fixed by the help of FreeBSD team and
Intel)

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/