[Arm-netbook] Ubuntu 13.04 Desktop Linux now running on EOMA68-A20

[luke.leighton]

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 at gmail.com> wrote:
> On Mon, Sep 30, 2013 at 8:13 PM, joem <joem at 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.