Re: [beagleboard] uEnv.txt - editing, comments & guide?

[Robert Nelson]

On Tue, Mar 19, 2013 at 5:05 AM, Leo738 <oo.h...@gmail.com> wrote:
> Hello All,
>
> I've got a XM board, rev B, running ubuntu 12.04.
>
> I've been trying to upgrade to the kernel to 3.7 but ran into display
> problems with the HDMI.
>
> My uEnv.txt is a bit of a mess for some reason, here it is:
>
> vram=12MB
> defaultdisplay=dvi
> dvimode=1280x1024MR-16@60
> kernel_file=zImage
> initrd_file=initrd.img
> boot=bootz
> dtb_file=
>
> console=ttyO2,115200n8
>
> mmcroot=/dev/mmcblk0p2 ro
> mmcrootfstype=ext4 rootwait fixrtc
>
> // Is this a comment?
> # or is this a comment?
>
> xyz_load_image=fatload mmc 0:1 0x80300000 ${kernel_file}
> xyz_load_initrd=fatload mmc 0:1 0x81600000 ${initrd_file}; setenv
> initrd_size ${filesize}
> xyz_load_dtb=fatload mmc 0:1 0x815f0000 ${dtb_file}
>
> mmcargs=setenv bootargs console=${console} ${optargs} vram=${vram}
> omapfb.mode=${defaultdisplay}:${dvimode} omapdss.def_disp=${defaultdisplay}
> root=${mmcroot} rootfstype=${mmcrootfstype} ${device_args}
> xyz_mmcboot=run xyz_load_image; run xyz_load_initrd; echo Booting from mmc
> ...
>
> optargs=console=tty0
> deviceargs=setenv device_args buddy=${buddy} buddy2=${buddy2}
> loaduimage=run xyz_mmcboot; run deviceargs; run mmcargs; ${boot} 0x80300000
> 0x81600000:${initrd_size}
> .
>
> I've tried to search for a guide on this type of file & the various meaning
> but no success. So my questions:
>
> How do you add a comment to this type of file?

"#"

> Any guide to this file or the arguments?

It's just a variable list.. the ONLY variable that really matters is:

"loaduimage"

http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/omap3_beagle.h;hb=HEAD#l296

as "if run loadbootenv; then "

loads the environment from uEnv.txt..

and "if run loaduimage; then "

Then our variables in uEnv.txt take over..

> Was there significant changes to the HDMI from kernel 3.3 to 3.7 that might
> effect the display?

Yeap, the optional "use high-speed pll" was ripped out of omapdss (no
one was using it in mainline, we never pushed our patch that used
it)... So displays that need the exact frequency (and can't work with
"close" values) now no longer work..

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/video/omap2?id=b6e695abe710ee1ae248463d325169efac487e17


Regards,

--
Robert Nelson
http://www.rcn-ee.com/

[Leo738]

Robert,

Thanks for the info.

Looks like C style comments can be used, as opposed to bash style.

Apologies but what is the difference between loading the 'environment' v's the variable from the uEnv.txt?


I've taken a look at my TV manual & the specs allowed are:




I've tried:

dvimode=1024x768MR-32@60
dvimode=1280x1024MR-32@60
dvimode=1920x1080MR-32@60

Without success. Any idea what might work?

Thanks,

Leo

[Leo738]

Sorry,

Picture didn't paste, here it is:

[Robert Nelson]

On Tue, Mar 19, 2013 at 9:23 AM, Leo738 <oo.h...@gmail.com> wrote:

Robert,

Thanks for the info.

Looks like C style comments can be used, as opposed to bash style.

Apologies but what is the difference between loading the 'environment' v's the variable from the uEnv.txt?

Confused by your actually question, So... We 'overwrite' the initial variables in the environment, with the variables defined in the uEnv.txt file..  Why? I'm lazzy and didn't care to patch u-boot with all the variable changes... Specially since "uEnv.txt" 's work so well..

I've taken a look at my TV manual & the specs allowed are:

I've tried:

dvimode=1024x768MR-32@60
dvimode=1280x1024MR-32@60
dvimode=1920x1080MR-32@60

dvimode=800x600MR-16@60

Regards,

[Tom Rini]

Well, uenvcmd also matters as you can set that to a different command and boot that way, such as:
localboot=run loaduimage;run ramboot

Or what have you.

--
Tom

[Leo738]

Robert,

Thanks for the quick reply.

I've tried:

dvimode=800x600MR-16@60

But no success, (I ssh'ed into the BM to make sure it was running). I assume the last number (60) refers to mains Hz? I tried 50 (I'm in Ireland), no success either.

Thanks for the explanation of uEnv.txt, I haven't seen it's use before so a bit confused. Does it mean that most of the stuff in my file is ignored?

Thanks again,

Leo

[Robert Nelson]

Yeah, that's also an option for the beagle's..

Bikeshed/Pipedream: wouldn't it be nice to unify all the u-boot boot
scripts/variables/etc... ;)

[Robert Nelson]

On Tue, Mar 19, 2013 at 10:13 AM, Leo738 <oo.h...@gmail.com> wrote:
> Robert,
>

> Thanks for the quick reply.
>
> I've tried:
>
> dvimode=800x600MR-16@60
>
> But no success, (I ssh'ed into the BM to make sure it was running). I assume
> the last number (60) refers to mains Hz? I tried 50 (I'm in Ireland), no
> success either.

Oh darn.. Do you have the model number?

I'm playing with reverting:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/video/omap2?id=b6e695abe710ee1ae248463d325169efac487e17

So i might have something in a bit for testing...

> Thanks for the explanation of uEnv.txt, I haven't seen it's use before so a
> bit confused. Does it mean that most of the stuff in my file is ignored?

No, most of the file is being used... But in the process of making one
"uEnv.txt" for a lot of different targets, i just went overkill on
redefining everything..

[Leo738]

On Tuesday, March 19, 2013 3:17:47 PM UTC, RobertCNelson wrote:

On Tue, Mar 19, 2013 at 10:13 AM, Leo738 <oo.h...@gmail.com> wrote:
> Robert,
>
> Thanks for the quick reply.
>
> I've tried:
>
> dvimode=800x600MR-16@60
>
> But no success, (I ssh'ed into the BM to make sure it was running). I assume
> the last number (60) refers to mains Hz? I tried 50 (I'm in Ireland), no
> success either.

Oh darn..  Do you have the model number?

Model number of the TV or Beagleboard?

TV - LG42LV550T
BB - xM 500-5010-001 rev B

I'm playing with reverting:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/video/omap2?id=b6e695abe710ee1ae248463d325169efac487e17

So i might have something in a bit for testing...


> Thanks for the explanation of uEnv.txt, I haven't seen it's use before so a
> bit confused. Does it mean that most of the stuff in my file is ignored?

No, most of the file is being used... But in the process of making one
"uEnv.txt" for a lot of different targets, i just went overkill on
redefining everything..

OK, thanks
 

[R. Lemos]

Without this hi-speed clock I can't use hd720 output mode, which needs
74.25 Mhz (and my TV is picky about pixel clock and won't work with 72
Mhz).

Can it be undone on the 3.9 series? Or targeted for 3.10? Perhaps with
a config option (so it would not mess with OMAP versions where those
bits are indeed reserved)?

I could try it myself. But I'm afraid that almost 1 year commits on
top of that had changed it so much (even conceptually) that the task
reveals itself a tremendous amount of work. On top of your experience,
what do you think?

--
[]'s
Rodrigo

[Robert Nelson]

Talking with Tomi (author/maintainer of omapdss) this functionality
was moved elsewhere..

My lcd/dvi monitor that needs this is at home, so I'll be testing this
tonight on v3.9-rc3..

diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 4af136a..c4a3f09 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -58,10 +58,6 @@ static struct platform_device *dpi_get_dsidev(enum
omap_channel channel)
*/
switch (omapdss_get_version()) {
case OMAPDSS_VER_OMAP24xx:
- case OMAPDSS_VER_OMAP34xx_ES1:
- case OMAPDSS_VER_OMAP34xx_ES3:
- case OMAPDSS_VER_OMAP3630:
- case OMAPDSS_VER_AM35xx:
return NULL;
default:
break;

[Robert Nelson]

btw: you can test this via:

http://rcn-ee.homeip.net:81/testing/beagleboard/v3.9-pixel-clock/

Just grab the zImage and modules, and copy/untar them to your sd card..

[R. Lemos]

Failure. Doesn't even boot: http://pastebin.com/rBvedNSz

[]'s
Rodrigo

[Robert Nelson]

>> btw: you can test this via:
>>
>> http://rcn-ee.homeip.net:81/testing/beagleboard/v3.9-pixel-clock/
>>
>> Just grab the zImage and modules, and copy/untar them to your sd card..
>
> Failure. Doesn't even boot: http://pastebin.com/rBvedNSz

reading /dtbs/omap3-beagle-xm.dtb
8647 bytes read in 14 ms (602.5 KiB/s)
/dtbs/omap3-beagle-xm.dtb loaded at 0x80000000
Booting from mmc ...
## Error: "expansion_args" not defined
bootz 0x80008000 - 0x80000000
## Flattened Device Tree blob at 80000000
Booting using the fdt blob at 0x80000000
Loading Device Tree to 8fffa000, end 8ffff1c6 ... OK

Yeah, how about just using the old "board" file zImage method. ;)

I didn't test device tree on my xM...

[R. Lemos]

On Tue, Mar 19, 2013 at 10:40 PM, Robert Nelson <robert...@gmail.com> wrote:
> reading /dtbs/omap3-beagle-xm.dtb
> 8647 bytes read in 14 ms (602.5 KiB/s)
> /dtbs/omap3-beagle-xm.dtb loaded at 0x80000000
> Booting from mmc ...
> ## Error: "expansion_args" not defined
> bootz 0x80008000 - 0x80000000
> ## Flattened Device Tree blob at 80000000
> Booting using the fdt blob at 0x80000000
> Loading Device Tree to 8fffa000, end 8ffff1c6 ... OK
>
> Yeah, how about just using the old "board" file zImage method. ;)
>
> I didn't test device tree on my xM...
>

Oh. That's it. By all the recent traffic related to DT I thought we
had already ported everything to DT ;-P

Mistake corrected and.... fine; the image boots fine and I got
74.25MHz clock. And some minor oopses perhaps not related to omap at
all (something about reentrant locks on VFS when listing
/sys/kernel/debug, with debugfs mounted there).

You nailed it.

Hi speed clock issue resolved, I'm now facing another problem I
already had in 2.6.x and 3.2:

[ 70.686798] omapdss OVERLAY error: overlay 0 horizontally not
inside the display area (0 + 1280 >= 720)
[ 70.696685] omapdss APPLY error: failed to enable manager 1:
check_settings failed
[ 118.646362] omapdss OVERLAY error: overlay 0 horizontally not
inside the display area (0 + 1280 >= 720)
[ 118.656249] omapdss APPLY error: failed to enable manager 1:
check_settings failed

(text console works ok)

They seem to be somewhat related to X omapfb driver trying to bring up
every output (that is DVI, LCD and TV Out). Since I only need DVI I
corrected this (back then) by not compiling LCD and TV Out outputs.
Tomorrow I'll try compiling 3.9-rc3 with your patch.

Thanks for everything. Good job.
[]'s
Rodrigo

[Robert Nelson]

On Tue, Mar 19, 2013 at 9:12 PM, R. Lemos <rsl...@gmail.com> wrote:
> On Tue, Mar 19, 2013 at 10:40 PM, Robert Nelson <robert...@gmail.com> wrote:
>> reading /dtbs/omap3-beagle-xm.dtb
>> 8647 bytes read in 14 ms (602.5 KiB/s)
>> /dtbs/omap3-beagle-xm.dtb loaded at 0x80000000
>> Booting from mmc ...
>> ## Error: "expansion_args" not defined
>> bootz 0x80008000 - 0x80000000
>> ## Flattened Device Tree blob at 80000000
>> Booting using the fdt blob at 0x80000000
>> Loading Device Tree to 8fffa000, end 8ffff1c6 ... OK
>>
>> Yeah, how about just using the old "board" file zImage method. ;)
>>
>> I didn't test device tree on my xM...
>>
>
> Oh. That's it. By all the recent traffic related to DT I thought we
> had already ported everything to DT ;-P

I'm really surprised it booted as far as it did thou.. In the back of
mind i've been thinking v3.10.x switch to dt for panda's, maybe
v3.11.x for the beagle's, but maybe we can do that sooner now..

>
> Mistake corrected and.... fine; the image boots fine and I got
> 74.25MHz clock. And some minor oopses perhaps not related to omap at
> all (something about reentrant locks on VFS when listing
> /sys/kernel/debug, with debugfs mounted there).
>
> You nailed it.
>
> Hi speed clock issue resolved, I'm now facing another problem I
> already had in 2.6.x and 3.2:
>
> [ 70.686798] omapdss OVERLAY error: overlay 0 horizontally not
> inside the display area (0 + 1280 >= 720)
> [ 70.696685] omapdss APPLY error: failed to enable manager 1:
> check_settings failed
> [ 118.646362] omapdss OVERLAY error: overlay 0 horizontally not
> inside the display area (0 + 1280 >= 720)
> [ 118.656249] omapdss APPLY error: failed to enable manager 1:
> check_settings failed
>
> (text console works ok)
>
> They seem to be somewhat related to X omapfb driver trying to bring up
> every output (that is DVI, LCD and TV Out). Since I only need DVI I
> corrected this (back then) by not compiling LCD and TV Out outputs.
> Tomorrow I'll try compiling 3.9-rc3 with your patch.
>
> Thanks for everything. Good job.
> []'s
> Rodrigo
>

> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Tom Rini]

Long been on my list, patches happily reviewed (and it should be named generically enough for other SoCs to opt into, there's a few similar constructs out there.

--
Tom

[Leo738]

Robert,

Thanks for looking at this.

What was the last kernel that you issued with the 'old' setup? I think 3.3 was working ok for me, anything later? I'll switch to that kernel for the moment.

Leo

[Robert Nelson]

Well, it was ripped out in v3.5-rc's.. v3.4.x was kind of okay, due
to beagle classic bugs i ignored it for mass push out. (later fixed
the bug but was on v3.5.x by then).. I skipped v3.3.x completely... So
really v3.2.x was the last "old" setup.. ;)

Regards,

[Leo738]

Ok, many thanks.

Leo