Ubuntu 13.04 now running on EOMA68-A20
Sata disk images and how to's here: http://www.gplsquared.com/eoma_boot/eoma_boot.html#Ubuntu_13_04
(The same image can work on Cubieboard2 as well with some minor tweeks.)
The EOMA now functions like a powerful arm-netbook desktop computer and as powerful as any netbooks that first came out.
Probably under $50 BOM costs for a netbook like ARM PC box with say an upgradeable 16GB sata SSD built into the box.
This release has Gambas3 compiled and working. Gambas allows rapid GUI application development. So - now very easy to customize EOMA to become IoT gadget with a GUI user interface, a web interface or both.
On Sun, Sep 29, 2013 at 11:07 PM, joem joem@martindale-electric.co.uk wrote:
Ubuntu 13.04 now running on EOMA68-A20
Sata disk images and how to's here: http://www.gplsquared.com/eoma_boot/eoma_boot.html#Ubuntu_13_04
(The same image can work on Cubieboard2 as well with some minor tweeks.)
The EOMA now functions like a powerful arm-netbook desktop computer and as powerful as any netbooks that first came out.
ahh fantastic.
Probably under $50 BOM costs for a netbook like ARM PC box with say an upgradeable 16GB sata SSD built into the box.
*have* to make that happen. this was the whole damn reason why this list was created in the first place, 3 and a half years ago. http://lists.phcomp.co.uk/pipermail/arm-netbook/2010-February/thread.html
with the flying squirrel PCB nearly there, adaptation to turn it into a laptop is really not that hard. the alternative is the USB-based solution (like the atrix lapdock that christopher's taking apart at the moment).
l.
On Mon, 2013-09-30 at 01:28 +0100, luke.leighton wrote:
On Sun, Sep 29, 2013 at 11:07 PM, joem joem@martindale-electric.co.uk wrote:
Ubuntu 13.04 now running on EOMA68-A20
Sata disk images and how to's here: http://www.gplsquared.com/eoma_boot/eoma_boot.html#Ubuntu_13_04
(The same image can work on Cubieboard2 as well with some minor tweeks.)
The EOMA now functions like a powerful arm-netbook desktop computer and as powerful as any netbooks that first came out.
ahh fantastic.
Probably under $50 BOM costs for a netbook like ARM PC box with say an upgradeable 16GB sata SSD built into the box.
*have* to make that happen. this was the whole damn reason why this list was created in the first place, 3 and a half years ago. http://lists.phcomp.co.uk/pipermail/arm-netbook/2010-February/thread.html
with the flying squirrel PCB nearly there, adaptation to turn it into a laptop is really not that hard. the alternative is the USB-based solution (like the atrix lapdock that christopher's taking apart at the moment).
I ordered up more ssds and other bits of kit to see what else can be made into reality. Just need one LCD to work now, and then i get go ahead probably for half dozen to try out and get working.
On Mon, Sep 30, 2013 at 9:55 AM, joem joem@martindale-electric.co.uk wrote:
I ordered up more ssds and other bits of kit to see what else can be made into reality. Just need one LCD to work now, and then i get go ahead probably for half dozen to try out and get working.
awesome. you got that 480x272 up and running, right?
On Mon, 2013-09-30 at 11:26 +0100, luke.leighton wrote:
On Mon, Sep 30, 2013 at 9:55 AM, joem joem@martindale-electric.co.uk wrote:
I ordered up more ssds and other bits of kit to see what else can be made into reality. Just need one LCD to work now, and then i get go ahead probably for half dozen to try out and get working.
awesome. you got that 480x272 up and running, right?
Nope - all the numbers I try from fex guide still keep getting LCD in danger messages. Its not configuring the LCD correctly. What i need is a known working LCD script.fex file that i can then check with error messages to find out what gives where. The idea being, if it can generate scope signals, then I can adjust the parameters until it suits the display I have.
On Mon, Sep 30, 2013 at 11:41 AM, joem joem@martindale-electric.co.uk wrote:
On Mon, 2013-09-30 at 11:26 +0100, luke.leighton wrote:
On Mon, Sep 30, 2013 at 9:55 AM, joem joem@martindale-electric.co.uk wrote:
I ordered up more ssds and other bits of kit to see what else can be made into reality. Just need one LCD to work now, and then i get go ahead probably for half dozen to try out and get working.
awesome. you got that 480x272 up and running, right?
Nope - all the numbers I try from fex guide still keep getting LCD in danger messages.
ignore them and/or correct them. the advice is actually correct. make the calculations recommended and put the values in that satisfy the equations.
l.
On Mon, 2013-09-30 at 11:45 +0100, luke.leighton wrote:
I ordered up more ssds and other bits of kit to see what else can be made into reality. Just need one LCD to work now, and then i get go ahead probably for half dozen to try out and get working.
awesome. you got that 480x272 up and running, right?
Nope - all the numbers I try from fex guide still keep getting LCD in danger messages.
ignore them and/or correct them. the advice is actually correct. make the calculations recommended and put the values in that satisfy the equations.
hm... the script.fex and the boot logs are here http://www.gplsquared.com/eoma_boot/eoma_boot.html#lcd_lashup
On Mon, Sep 30, 2013 at 12:06 PM, joem joem@martindale-electric.co.uk wrote:
On Mon, 2013-09-30 at 11:45 +0100, luke.leighton wrote:
I ordered up more ssds and other bits of kit to see what else can be made into reality. Just need one LCD to work now, and then i get go ahead probably for half dozen to try out and get working.
awesome. you got that 480x272 up and running, right?
Nope - all the numbers I try from fex guide still keep getting LCD in danger messages.
ignore them and/or correct them. the advice is actually correct. make the calculations recommended and put the values in that satisfy the equations.
hm... the script.fex and the boot logs are here http://www.gplsquared.com/eoma_boot/eoma_boot.html#lcd_lashup
the segfault - which clearly says it's a divide-by-zero error - will be what's stopping the lcd from even being initialised.
so normally where it would be making some checks / equations it's not getting to that point.
[<c02fd384>] (BSP_disp_lcd_open_after+0x10c/0x614) from [<c02e0af8>] (DRV_lcd_o) [<c02e0af8>] (DRV_lcd_open+0xb4/0xc8) from [<c02e6428>] (Fb_Init+0xadc/0xe50)
so, my advice: find that function, look at it, put some printk statements in and re-run it to see what's going on.
l.
hm... the script.fex and the boot logs are here http://www.gplsquared.com/eoma_boot/eoma_boot.html#lcd_lashup
the segfault - which clearly says it's a divide-by-zero error - will be what's stopping the lcd from even being initialised.
so normally where it would be making some checks / equations it's not getting to that point.
[<c02fd384>] (BSP_disp_lcd_open_after+0x10c/0x614) from [<c02e0af8>] (DRV_lcd_o) [<c02e0af8>] (DRV_lcd_open+0xb4/0xc8) from [<c02e6428>] (Fb_Init+0xadc/0xe50)
so, my advice: find that function, look at it, put some printk statements in and re-run it to see what's going on.
--
I grepped the code found the relevant bits a while ago and decided the registers were not taking the values in script.fex settings. The entire data structure is zero. Either something over write it, or it never got initialized. That is main reason I wanted a known good working script.fex for known lcd so that it generates the video (or not as the case may be) to then try to see what is different before delving deeper.
On Mon, Sep 30, 2013 at 8:13 PM, joem joem@martindale-electric.co.uk wrote:
hm... the script.fex and the boot logs are here http://www.gplsquared.com/eoma_boot/eoma_boot.html#lcd_lashup
the segfault - which clearly says it's a divide-by-zero error - will be what's stopping the lcd from even being initialised.
so normally where it would be making some checks / equations it's not getting to that point.
[<c02fd384>] (BSP_disp_lcd_open_after+0x10c/0x614) from [<c02e0af8>] (DRV_lcd_o) [<c02e0af8>] (DRV_lcd_open+0xb4/0xc8) from [<c02e6428>] (Fb_Init+0xadc/0xe50)
so, my advice: find that function, look at it, put some printk statements in and re-run it to see what's going on.
--
I grepped the code found the relevant bits a while ago and decided the registers were not taking the values in script.fex settings.
"deciding" is not enough. this is software engineering. you cannot just "decide". as in *you* cannot just "decide". you have to get the *machine* to print out the values [or use a kernel-level debugger to find out].
you've been given standard software engineering debugging advice. this standard software engineering debugging advice you will get no matter _where_ you ask the question.
follow the advice that i've given you else there is no further assistance that i nor anyone else can give you.
l.
joe. we've been through this already with the GPL compliance. it took you a hell of a long time to listen to advice from *three* separate people. for everyone's sake you need to shorten that time down.
so when i say "please put some printk statements in and re-run it to see what's going on", what should you do? completely ignore that - which makes it a complete waste of my time to even answer your questions - or should you do what has been suggested?
the most likely function where the divide-by-zero error is occurring is Lcd_Panel_Parameter_Check. there's a divide here: lcd_fclk_frq = (info->lcd_dclk_freq * 1000 * 1000) / ((info->lcd_vt / 2) * info->lcd_ht);
so, when i say "please put some printk statements in and re-run it to see what's going on", what should you do?
you should add a printk statement like "printk("lcd_vt: %d", info->lcd_vt);" shouldn't you?
if you haven't done that then please don't ask for further help with tracking down this LCD issue: you will only be wasting your own time as well as everyone else's, ok?
if you _have_ done that - and have run it - then you won't be "deciding", you'll *know* what's going on.
l.
On Mon, Sep 30, 2013 at 9:23 PM, luke.leighton luke.leighton@gmail.com wrote:
On Mon, Sep 30, 2013 at 8:13 PM, joem joem@martindale-electric.co.uk wrote:
hm... the script.fex and the boot logs are here http://www.gplsquared.com/eoma_boot/eoma_boot.html#lcd_lashup
the segfault - which clearly says it's a divide-by-zero error - will be what's stopping the lcd from even being initialised.
so normally where it would be making some checks / equations it's not getting to that point.
[<c02fd384>] (BSP_disp_lcd_open_after+0x10c/0x614) from [<c02e0af8>] (DRV_lcd_o) [<c02e0af8>] (DRV_lcd_open+0xb4/0xc8) from [<c02e6428>] (Fb_Init+0xadc/0xe50)
so, my advice: find that function, look at it, put some printk statements in and re-run it to see what's going on.
--
I grepped the code found the relevant bits a while ago and decided the registers were not taking the values in script.fex settings.
"deciding" is not enough. this is software engineering. you cannot just "decide". as in *you* cannot just "decide". you have to get the *machine* to print out the values [or use a kernel-level debugger to find out].
you've been given standard software engineering debugging advice. this standard software engineering debugging advice you will get no matter _where_ you ask the question.
follow the advice that i've given you else there is no further assistance that i nor anyone else can give you.
l.
printk
I found some boot logs through googling that suggest code is working for initiliasing lcd, and script.fex is at fault. Hence reason for getting hold of working script.fex as there is no bidirectional communications with LCD needed for code and script.fex to work.
printk - later - I find some time to slot in...
On Tue, Oct 1, 2013 at 9:13 AM, joem joem@martindale-electric.co.uk wrote:
printk
I found some boot logs through googling that suggest code is working for initiliasing lcd, and script.fex is at fault. Hence reason for getting hold of working script.fex as there is no bidirectional communications with LCD needed for code and script.fex to work.
that's correct! the hardware analogy is that the circuit won't talk back, therefore *you* need to move the multimeter around the circuit.
printk - later - I find some time to slot in...
and find time to move the printk around to different places, just like moving a multimeter around to different locations in the circuit, in order to trace back the fault.
l.
arm-netbook@lists.phcomp.co.uk
-
joem -
luke.leighton