Wrong colors on TV Headend (Composite Video Out)

[dom]

Any suggestions which version is straight before the one causing that problem?

I don't believe it is a firmware problem. I think someone else would have mentioned it if it was. But feel free to try.
I'd also like you to connect to a different display, which seems most likely to me.

i would be with you, as there wasnt the working xbian..... unfortunately i dont have another display by the hand for now.
as you dont think its a firmware thing i guess there is no chance to get that one fixed for me.... thats kind of .... sad... its a pain for me to plug out the hdmi cable all the time.... the abrasion of the contacts will force me to buy another pi soon.... that might be a marketing thing, isnt it?^^

ill try older firmware and tell about the results here.

I don't believe it is a firmware problem. I think someone else would have mentioned it if it was. But feel free to try.
I'd also like you to connect to a different display, which seems most likely to me.

Well just for the case, there is nothing to laugh at.

It is definitively the firmware! as the firmware of Jan 1st 2013 did not work i went back straight to Nov 26, 2012, whereas my tv headend is showing the CORRECT COLOURS.
Its the firmware, its the firmware!!!!!

so the change must have been between Nov26 and Jan 1st,. actually did not check any update between these dates, because life is calling me, im tired as hell. ill check the lineup to find out which update exactly causes the mess.

it must be end of december because i remember my openelec did the same colourscrewing as my wheezy installation now. after some reboot there were wrong colours using composite and nothing i could do about it, so i went to xbian, which works until now. (but as long not so good as openelec did, but thats for another thread.

pls keep investigating the thing. There WILL be more in the future, but there seem not to be so much people using both dvi monitor and tv headend at the same pi. or they dont care about pluging out the hdmi cable. im sure there will be more.

unfortunately the reason for me to switch to tv headend, an xbmc installation does not work with the firmware of november, so there isnt anything to be happy about.

ill report which firmware update causes the change. tomorrow.

[dom]

so the change must have been between Nov26 and Jan 1st,. actually did not check any update between these dates, because life is calling me, im tired as hell. ill check the lineup to find out which update exactly causes the mess.
..
ill report which firmware update causes the change. tomorrow.

If you pinpoint the firmware that caused it, then it should be fixable.

It might be worth checking if it is this commit first:
https://github.com/Hexxeh/rpi-firmware/ ... 914c91c0ab

as that is when we switched the "master" tree to the "next" tree (and a lot changed).

If it is that one, then you can test the "next" tree:
https://github.com/Hexxeh/rpi-firmware/commits/next

to find which commit broke it. Again, most likely is that it is the first commit on "next" tree, as that has the most changes.

But, identify the commit first, and then I'll work out the next step.

It was only one version away.

i testet the firmware of 27.Dec12 and: The colour-screw effect is back again.
Last working version for correct functionality of hdmi_ignore_hotplug=1 is 26.Nov12.

Dear Dom, pls tell me if I can do anything more than wait for a fixed update and plugging out the cable all the time meanwhile^^.

Thx in advance.

[dom]

It was only one version away.

i testet the firmware of 27.Dec12 and: The colour-screw effect is back again.
Last working version for correct functionality of hdmi_ignore_hotplug=1 is 26.Nov12.

Dear Dom, pls tell me if I can do anything more than wait for a fixed update and plugging out the cable all the time meanwhile^^.

Thx in advance.

Yes, "that is when we switched the "master" tree to the "next" tree (and a lot changed)."

Can you confirm it is the first commit in next tree is the one that broke it:
https://github.com/Hexxeh/rpi-firmware/commits/next

Damn, im sorry.

Ive found another way to mess anything up. I testet the version of 28Nov as i realised, there is no image on the screen of tv headend, ssh connection fails actually and ive no chance to edit config.txt right now.
It wasnt a real good idea to update upgrade just today, there have been much changes, even in ssh. I need to edit sd card from another machine, to manage anything further on.
Unfortunately ive overwritten my 2nd wheezy with a mediacenter, so ill need to do it in the office tomorrow.
Im not sure if the blank desktop is a result of the updates today, or from the firmware of nov 28 or even a mix of both.
But i once again learned something. Douh!
My investigations must wait till tomorrow again, im sorry about that.

Greetz from the most worse betatester ever.

pi@raspberrypi ~ $ sudo rpi-update d77ec8c482df21ac8eba5e2906bdb5ca8fdf892d
sudo: rpi-update: command not found

oh man.
I did a complete new install of wheezy today, as the sd card i used broke (mechanicaly) in i returned it to the dealer and got a new one.
I used the *.img from this page and updated/upgraded.

I dont know why rpi-update does not exist anymore. Is there another way to work me through the firmware updates? ( it was clear, today i thought about getting ssh ready and so on and i felt ready to patch my ass of, but now im down at reality again. )

[dom]

:?
pi@raspberrypi ~ $ sudo rpi-update d77ec8c482df21ac8eba5e2906bdb5ca8fdf892d
sudo: rpi-update: command not found

oh man.
I did a complete new install of wheezy today, as the sd card i used broke (mechanicaly) in i returned it to the dealer and got a new one.
I used the *.img from this page and updated/upgraded.

I dont know why rpi-update does not exist anymore. Is there another way to work me through the firmware updates? ( it was clear, today i thought about getting ssh ready and so on and i felt ready to patch my ass of, but now im down at reality again. )

You need to install rpi-update. See here:
https://github.com/Hexxeh/rpi-update

Ah, okay....

As i see this webpage i remember i've once installed it. Until now i was believing rpi-update is a part of the distribution.

I'll have another try today then.

well, just mo make sure im doing it the right way:

i started with nov 28 from commit tree, but there is already the "blue" raspberry logo on bootscreen.
there after i checked nov 26 and nov 25, but im wondering because the berry keeps showing up "blue".

am i doing correct to walk down until ive found the version which is showing the correct colour?

im wondering because the the former version which was working correct for me was of nov 26.

[dom]

My prediction is that this firmware is good: (the most recent one before "next")
https://github.com/Hexxeh/rpi-firmware/ ... e899c63090

and that this one is bad (the oldest "next" firmware):
https://github.com/Hexxeh/rpi-firmware/ ... a3226ae401

Can you confirm that first?

ääähm no. cant confirm that.

ive installed both versions, and in all cases my berry looks quite red.
but there are other issues now, as i have problems with a ocasionally freezing system now, thats why it took me some time to check.

ill switch to dvi now and back to tv headend thereafter, maybe then ....

[dom]

ääähm no. cant confirm that.

ive installed both versions, and in all cases my berry looks quite red.
but there are other issues now, as i have problems with a ocasionally freezing system now, thats why it took me some time to check.

ill switch to dvi now and back to tv headend thereafter, maybe then ....

Okay, if:
https://github.com/Hexxeh/rpi-firmware/ ... a3226ae401
is good, can you look along this tree:
https://github.com/Hexxeh/rpi-firmware/commits/next

I'm sure the newest one will be bad:
https://github.com/Hexxeh/rpi-firmware/ ... 1f6754872b

Can you point out the breaking commit?

Okay, if:
https://github.com/Hexxeh/rpi-firmware/ ... a3226ae401

Yes, looks good.

can you look along this tree:
https://github.com/Hexxeh/rpi-firmware/commits/next

Ok, im working out that one

NOW iam confused.......

i started with the first link of dec27 from
https://github.com/Hexxeh/rpi-firmware/commits/next

and.....: "red"-berry.
i dont understand that one. is it possible the issue only appears after switching to dvi and back to composite?

ive done a fresh installation of the actual openelec for my boss today. the system did never run. ill set that one to ignore_hdmi_hotplug=1 and see whats happening. In my theory it MUST show the wrong colours. if not i need to think about consulting a doctor.

I dont need the doctor!

The openelec had the behavior i expected.
Should i go on testing down the tree or do you have another idea, dom.
For me i dont understand the organization of your development trees right now, so pls tell me how to do further testings..... as you dint already gave up on that.

[dom]

So dec 27 of next tree has correct colours?

Indeed.

[dom]

Indeed.

Well
https://github.com/Hexxeh/rpi-firmware/ ... 914c91c0ab

should be the same (and on master branch). Assuming it is then you should be able to find the first build that breaks it on master branch:
https://github.com/Hexxeh/rpi-firmware/commits

Oh man. Why is nothing i get on simple, just once?

1st: No i dont take drugs.

2nd: ill describe what i did as exactly as possible.
Everything went as i replied.

Yesterday evening then i re-updated to actual firmware by using sudo rpi-update.
as far as i remember i did not install any packages or updates then.

Today i went back for this thread an did as dom suggested:
Installed https://github.com/Hexxeh/rpi-firmware/ ... 914c91c0ab

Checking TV headend: Colours screwed

I was wondering about the result and went back to dec27, installed:
https://github.com/Hexxeh/rpi-firmware/ ... 1f6754872b

Rechecking TV headend: Colours screwed.

Thereafter i went back to nov 26, which as i remember worked correctly while investigating:
https://github.com/Hexxeh/rpi-firmware/ ... 644f0acacc

Checking TV Headend again: Colours screwed.

Im quite unsure if we can identify the break as there seems to be at least a 2nd trigger causing the issue.

For now im going backwards from now26 to see if there is anything changing when installing former versions. I dont know if this post cotains any usable information for dom but i hope so.

... read you later, im going to install former versions and will post the results here soon.

now i tried nov26 from master-tree again. TV shows correct colours.
tested next tree down to nov 17(1st link) which left me down, could not boot anymore until i replaced files on boot partition.
All tested versions from next tree were faulty with respect to the composite colour-issue.

i dont now how to test on. any sense to test more versions down the tree?

[dom]

So dec 27 of next tree has correct colours?

Indeed.

All tested versions from next tree were faulty with respect to the composite colour-issue.
i dont now how to test on. any sense to test more versions down the tree?

You seem to be giving me inconsistent answers which makes diagnosing the problem impossible. You've told me:
dec 27 of next tree has correct colours.
All versions of next tree have faulty colours

So I've been playing around, with the RISC OS image from 31/10/2012 and the Raspbian image of 9/2/2013 (which I just happen to have)
I removed the extraneous un-needed stuff, such as kernel.img (RISCOS.IMG in the RISC OS image) and stripped CONFIG.TXT down to the one line

Code: Select all

hdmi_ignore_hotplug=1


and then tried various combinations of start.elf, fixup.dat and bootcode.bin

With the older start.elf, and any combination of old and new fixup.dat and bootcode.bin, the splash screen is correct - red top left, yellow top right, blue bottom left, cyan bottom right, just like the picture on the wiki-troubleshooting page

With the newer start.elf and any fixup.dat and bootcode.bin, the splash screen is wrong - blue and red swapped (also cyan and yellow)

Removing config.txt or commenting out that line restores sanity

I haven't gone further to find a date when it goes wrong - my git-hub foo is lacking, or is it my caffeine level?

Another slight anomaly - the later start.elf won't flash the act led. The earlier one flashes 7 times to complain about not finding kernel.img but the newer one doesn't