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.