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"
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..
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:
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?
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?
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..
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?
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…
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?
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.
Oh. That's it. By all the recent traffic related to DT I thought we
had already ported everything to DT
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.
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
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..
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.
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.
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..
