U-Boot Questions / Ideas

Hi,

I've looked at the u-boot.bin defaults (nested if statements with
$mmcargs, etc). I'm not expert or knowledgeable enough to know if
these ideas are of value. But I wanted to put them out there for
those who do understand it. I had posted this on another thread, but
I think it's really a separate discussion. So I'm reposting here
separately.

1) I think we need one more level of "if" in the bootcmd default.
But I'm not
sure if it can be done. If the uImage is a DSS uImage, then you need
'video=...mode:1024x768@60' (or something similar). But if the
uImage
is a DSS2 uImage, then you need
'omap.video_mode=1024x768MR-16@60' (or
something similar). Can you think of a way to automagically check
for
DSS vs. DSS2 and produce the appropriate video args?

2) With DSS, you need the 'video=omapfb:vram:2M,vram:4M'. I'm not
at
all sure if that's needed (or not) with DSS2. So some clarity there
would be good. I'm not even sure what this really does.

3) I'm not sure if it's generally understood (it wasn't by me until
recently) that if you do a 'NAND ERASE 260000 20000' then power off
and back on, that it will wipe out your env variables and give you
all
the default ones. It's a very nice trick. Only caveat is that you
then get an error message about CRC upon bootup -- that you can
ignore.

4) I also think (after a brief review of the code) that if you
didn't
specify some of the args that u-boot would default to the correct
settings. Does it make sense to ever just leave it blank?

Thanks very much.

Geof

Hi,

I've looked at the u-boot.bin defaults (nested if statements with
$mmcargs, etc). I'm not expert or knowledgeable enough to know if
these ideas are of value. But I wanted to put them out there for
those who do understand it. I had posted this on another thread, but
I think it's really a separate discussion. So I'm reposting here
separately.

1) I think we need one more level of "if" in the bootcmd default.
But I'm not
sure if it can be done. If the uImage is a DSS uImage, then you need
'video=...mode:1024x768@60' (or something similar). But if the
uImage
is a DSS2 uImage, then you need
'omap.video_mode=1024x768MR-16@60' (or
something similar). Can you think of a way to automagically check
for
DSS vs. DSS2 and produce the appropriate video args?

Why not just compile the kernel with the default video mode that you
want? If you really want to switch freely back and forth, have you
tried putting both of them in?

2) With DSS, you need the 'video=omapfb:vram:2M,vram:4M'. I'm not
at
all sure if that's needed (or not) with DSS2. So some clarity there
would be good. I'm not even sure what this really does.

It allocated a second framebuffer of 4MB, in addition to the primary
framebuffer of 2MB. I don't know if it is needed with DSS2, but if it
is or isn't really just depends on the compiled-in defaults. I'd
guess that the defaults for DSS2 has it allocate more framebuffers of
sufficient size.

3) I'm not sure if it's generally understood (it wasn't by me until
recently) that if you do a 'NAND ERASE 260000 20000' then power off
and back on, that it will wipe out your env variables and give you
all
the default ones. It's a very nice trick. Only caveat is that you
then get an error message about CRC upon bootup -- that you can
ignore.

Is there a question here?

4) I also think (after a brief review of the code) that if you
didn't
specify some of the args that u-boot would default to the correct
settings. Does it make sense to ever just leave it blank?

Can you give an example?

I think we should be using/supporting only DSS2. We should start
getting DSS2 patches on mainline / linux-omap.

Again V4L2 for OMAP should/will be based on DSS2. Giving room for DSS1
will make things more complicated and drives others in multiple
directions.

Thanks for suggestions.

Regards,
Khasim

Ok. Then if that's the case, I think all that I am suggesting is that
you folks who understand this should coordinate the move between the l-
o group and the u-boot group so that we get a u-boot that has good
defaults for the uImage that we build.

Thanks very much.

Geof