Ark_42
Posts: 28
Joined: Tue Sep 04, 2012 5:09 pm

Baking Pi screen01

Wed Sep 05, 2012 9:30 am

Hi,
In the 4th section of mailboxRead you have

Code: Select all

tst status,#0x40000000
.unreq status
bne wait2$
with the comment
This code checks that the top bit of the status field is 0, and loops back to 3. if it is not.
surely one of these is wrong, should the code test 0x80000000 or are we suposed to test one bit down from the top of the status ?

Ark_42

User avatar
Chadderz
Posts: 64
Joined: Thu Aug 30, 2012 12:50 pm
Location: Cambridge, UK

Re: Baking Pi screen01

Wed Sep 05, 2012 10:00 am

Quite right, there is a mistake; the code is correct. We're actually testing the 30th bit.

Ark_42
Posts: 28
Joined: Tue Sep 04, 2012 5:09 pm

Re: Baking Pi screen01

Wed Sep 05, 2012 10:03 am

Thanks for clarifing that.

Ark_42

Z3r0
Posts: 23
Joined: Wed Sep 05, 2012 7:42 pm

Re: Baking Pi screen01

Wed Sep 05, 2012 7:49 pm

I also have a question regarding this lesson. Everything is fine but, the problem is that i as well need to unplug and plug back hdmi connector to get the buffer address from vcore.

So maybe there are some one who actually can help on this problem (i am afraid that in multiple reconnects hdmi port can tear down). Maybe there is a special message for vcore to reset, or maybe some initialization needed before requesting buffer address? Maybe someone disassembled some original kernel files. (as i understand only vcore binaries are closed source, not the linux kernel). If some one has any info on this problem would be nice if you would share it ;)

As well as some different question, does this chip have any text mode display controller? Like 8086 via int 10 :D

User avatar
Chadderz
Posts: 64
Joined: Thu Aug 30, 2012 12:50 pm
Location: Cambridge, UK

Re: Baking Pi screen01

Wed Sep 05, 2012 8:01 pm

Ah, intersting that problem hasn't bothered me for a while. Can I just double check, in framebuffer.s, before FrameBufferInfo do you have .align 4 or .align 12? I used to use 4, but then siwtched to 12 and the problem went away. Unfortunately I still mention 4 by accident in the tutorial. I've never seen the problem occur with 12, so this may be the first evidence, or may be yet more evidence that 4 was the problem.

No text mode; that would be too easy!

Z3r0
Posts: 23
Joined: Wed Sep 05, 2012 7:42 pm

Re: Baking Pi screen01

Wed Sep 05, 2012 8:12 pm

In your text it says 4 but code uses 12 :) the funny thing is i just tried (after writing the question) Piscreen04 from downloads and it worked without need of replug. Need to check the diference. Maybe i wrote 4 but thinking about 12. By the way, thx for the tut its awesome! :)

Z3r0
Posts: 23
Joined: Wed Sep 05, 2012 7:42 pm

Re: Baking Pi screen01

Wed Sep 05, 2012 8:50 pm

Seems can't edit posts, so sorry for double post.

In any case i made some test, and saw that i add drawing.s from any later examples to my project, it then works without replug, even if i don;t use anything from drawing.s. So i tried to rename drawing.s to some zdrawing.s (that linker would join it last) and it needed replug again. So it could only mean data section. So i combined framebuffer.s data section like that

.section .data
.align 1
test:
.int 0b1
.align 12
.globl FrameBufferInfo

And it works.... i don't know why or what have changed. But its definitely something with data aliment in the binary. (anything needs to be before framebuffer info data). So maybe someone smarter than me :D can explain what's happening here :) (well i know now how to overcome the replug problem, but would like to know why any value BEFORE framebuffer data helps :) )

p.s. Entries from map files:

with junk aligned 1 before buffer (works, no replug needed)
.data 0x00009000 0x2000 build/frameBuffer.o
0x0000a000 FrameBufferInfo

without junk (needs replug)
.data 0x00009000 0x1000 build/frameBuffer.o
0x00009000 FrameBufferInfo
Last edited by Z3r0 on Wed Sep 05, 2012 8:57 pm, edited 1 time in total.

User avatar
Chadderz
Posts: 64
Joined: Thu Aug 30, 2012 12:50 pm
Location: Cambridge, UK

Re: Baking Pi screen01

Wed Sep 05, 2012 8:57 pm

That sounds all too familiar. I've spent many an hour trying to deduce what alignment it requires. Linux uses page alignment, hence I started using 12, but that clearly isn't the whole story. I heard somewhere it may be a caching issue, so I shall investigate further.

Ark_42
Posts: 28
Joined: Tue Sep 04, 2012 5:09 pm

Re: Baking Pi screen01

Fri Sep 07, 2012 10:18 am

I've been playing with this and discovered that if I have a 5 second delay before starting to get the framebuffer the shade pattern normally seen when loading a unix apears after about 3 of the 5 seconds. My program ( basically screen02 ) then works normally. Without the 5 second wait the first screens of output from my program do not appear, but it suddenly starts showing output after a few seconds.
I wonder if this is clue ( the GPU/HDMI need time to start up ? )

Ark_42

User avatar
DexOS
Posts: 876
Joined: Wed May 16, 2012 6:32 pm
Contact: Website

Re: Baking Pi screen01

Fri Sep 07, 2012 11:51 am

Ark_42 wrote:I wonder if this is clue ( the GPU/HDMI need time to start up ? )
Ark_42
Its does need time, to switch to HDMI channel, which depends on the make.
Quick test add this to your config.txt
test_mode=1

And plug ear phones into the audio jack socket of the pi.
When you switch on you will hear a beep and should see a colored image on screen.
In a lot of case you will not see the image if using HDMI, you always see it using composite video.

When i first started implementing the framebuffer, i use to get a problem with no image being showed on first startup and if you turn it off and on it worked the second time.
This was down to a shadow address, when i used 0x40000000 everthing worked fine, until they changed the boot loader and then there was no need to add anything.

Theres was a difference, if you used
addresses disable_l2cache=1
In the config.txt file too.
Last edited by DexOS on Fri Sep 07, 2012 12:06 pm, edited 2 times in total.
Batteries not included, Some assembly required.

Ark_42
Posts: 28
Joined: Tue Sep 04, 2012 5:09 pm

Re: Baking Pi screen01

Fri Sep 07, 2012 12:02 pm

I tried that, the shades image didn't appear for some time after the beep ( 4 or 5 seconds )

Ark_42

User avatar
DexOS
Posts: 876
Joined: Wed May 16, 2012 6:32 pm
Contact: Website

Re: Baking Pi screen01

Fri Sep 07, 2012 12:09 pm

Ark_42 wrote:I tried that, the shades image didn't appear for some time after the beep ( 4 or 5 seconds )

Ark_42
Did you also have your kernel.img on the sd card ?, if not try it with your test kernel.img also on the sd card.
And you will see no shades.
Batteries not included, Some assembly required.

stampatore
Posts: 7
Joined: Tue Jul 31, 2012 11:32 pm

Re: Baking Pi screen01

Mon Sep 10, 2012 12:24 pm

I'm rather envious of those who are getting this to work!

I managed OK01 to OK05, the latter only after adding the line kernel_old=1 to config.txt

Screen01, however, I can't get to work - not even the downloaded solution. I've added some code to flash different sequences at different parts of the program and it seems to be hanging in this loop inside framebuffer.s

Code: Select all

	pointerWait$:
		ldr result,[fbInfoAddr,#32]
		teq result,#0
		beq pointerWait$
I've tried unplugging and replugging the HDMI cable many times but it doesn't make any difference. I just end up with a uniformly grey screen.

Any pointers gratefully received!

User avatar
Chadderz
Posts: 64
Joined: Thu Aug 30, 2012 12:50 pm
Location: Cambridge, UK

Re: Baking Pi screen01

Mon Sep 10, 2012 12:37 pm

Have you tried:

Code: Select all

hdmi_safe=1
Alex

stampatore
Posts: 7
Joined: Tue Jul 31, 2012 11:32 pm

Re: Baking Pi screen01

Mon Sep 10, 2012 4:46 pm

Chadderz wrote:Have you tried:

Code: Select all

hdmi_safe=1
Alex
Yes. Currently I have the following lines uncommented in config.txt

Code: Select all

kernel_old=1
hdmi_safe=1
config_hdmi_boost=4
Nick

User avatar
DexOS
Posts: 876
Joined: Wed May 16, 2012 6:32 pm
Contact: Website

Re: Baking Pi screen01

Mon Sep 10, 2012 5:31 pm

stampatore wrote:
Chadderz wrote:Have you tried:

Code: Select all

hdmi_safe=1
Alex
Yes. Currently I have the following lines uncommented in config.txt

Code: Select all

kernel_old=1
hdmi_safe=1
config_hdmi_boost=4
Nick
You could try my OS because it uses a different frame buffer code
http://www.raspberrypi.org/phpBB3/viewt ... 93#p169593

If it works OK, we can see what the difference is.
Note: if you do test, use the boot loaders and config.txt in the zip
Batteries not included, Some assembly required.

stampatore
Posts: 7
Joined: Tue Jul 31, 2012 11:32 pm

Re: Baking Pi screen01

Tue Sep 11, 2012 9:14 am

I've loaded DexOS and it boots ok and displays the initial screen. (I've posted separate feedback on keyboards on your Raspberry Pi OS thread).

Not sure where this leaves me though. Does it mean I need to switch to using your frame buffer code?

Nick

CroydonClown
Posts: 3
Joined: Tue Sep 11, 2012 12:23 pm

Re: Baking Pi screen01

Tue Sep 11, 2012 12:37 pm

I've had a fair bit of trouble getting this to work. I got over having to replug the hdmi cable by setting the alignment of the framebuffer request to 4 (rather than 12) and explicitly writing zeroes into the unused locations, though I'm not sure which of those made the difference. Additionally, whatever I put in config.txt, the only thing that makes it work is test_mode=1. If I do that then the screen kicks into life and I get a pattern. It's not a test pattern because I can control what it looks like but if I don't have test_mode=1, then there is never a signal to the screen.

So it all seems reliable now but it doesn't feel right to have test_mode=1 in there.

User avatar
DexOS
Posts: 876
Joined: Wed May 16, 2012 6:32 pm
Contact: Website

Re: Baking Pi screen01

Tue Sep 11, 2012 1:25 pm

stampatore wrote:I've loaded DexOS and it boots ok and displays the initial screen. (I've posted separate feedback on keyboards on your Raspberry Pi OS thread).

Not sure where this leaves me though. Does it mean I need to switch to using your frame buffer code?

Nick
The framebuffer structure address need to be a multiple of 16
The address of the frame buffer must be at least a multiple of 16 (in
order to be accurately transmitted in the 28 bits available in the
mailbox)
So thats a starting point, i will take a look at the difference's and get back to you
Batteries not included, Some assembly required.

User avatar
mister_wavey
Posts: 98
Joined: Sun Sep 02, 2012 8:23 am
Location: Abergavenny, Wales, UK
Contact: Website

Re: Baking Pi screen01

Tue Sep 11, 2012 3:09 pm

for those trying to get the model answer to work, I had to replace .align 12 with .align 4 in frameBuffer.s

put sunglasses on first. You have been warned.

stampatore
Posts: 7
Joined: Tue Jul 31, 2012 11:32 pm

Re: Baking Pi screen01

Tue Sep 11, 2012 6:38 pm

I'm delighted to say that after many hours trying every possible combination of all suggestions, I've finally got to the same point as most other people - it will now work but only if I unplug and replug the HDMI (which I don't like doing either, it feels as if it might have a limited life).

My solution was to stop using my Toshiba 19BV501B TV (bought especially for the RPi and working perfectly ok with Raspbian) and to try using my main TV a Sony KDL-32EX301.

Why it makes a difference I don't know but I've tried several times with both, with different set ups and configs and the Sony generally works eventually but the Toshiba never.

User avatar
Chadderz
Posts: 64
Joined: Thu Aug 30, 2012 12:50 pm
Location: Cambridge, UK

Re: Baking Pi screen01

Tue Sep 11, 2012 6:45 pm

I really do find this whole thing baffling, I see no reason why everyone seems to require some random arbitrary combination of fixes. I'd be really interested to know if any of the other bare metaler's have anything on this issue.
Does adding 0x40000000 to the address before sending it to the mailbox make any difference? I've heard that somewhere but never tested it on a broken one.

User avatar
DexOS
Posts: 876
Joined: Wed May 16, 2012 6:32 pm
Contact: Website

Re: Baking Pi screen01

Tue Sep 11, 2012 9:11 pm

Chadderz wrote:I really do find this whole thing baffling, I see no reason why everyone seems to require some random arbitrary combination of fixes. I'd be really interested to know if any of the other bare metaler's have anything on this issue.
Does adding 0x40000000 to the address before sending it to the mailbox make any difference? I've heard that somewhere but never tested it on a broken one.
The problem your getting is down in my opinion to the change that have been made to boot loaders, we know they changed boot offset, but they also changed the add on to struct address, you use to have too add 0x40000000 to that address, then it stoped working if you add that :x .
So the latest once you add nothing.

So the best advice i can give you, is to include the boot files that you know work with your tuts and tell people to use them.
Its what most of us pi OS Dev's have to do now.
If not, some people have old boot loaders and some have new, so you get different problems, which are not down to your code.
Batteries not included, Some assembly required.

stampatore
Posts: 7
Joined: Tue Jul 31, 2012 11:32 pm

Re: Baking Pi screen01

Tue Sep 11, 2012 9:54 pm

CroydonClown wrote:I got over having to replug the hdmi cable by setting the alignment of the framebuffer request to 4 (rather than 12) and explicitly writing zeroes into the unused locations, though I'm not sure which of those made the difference.
I'd like to try this. Probably a silly question, but can you post your code to show exactly how and where you are "writing zeroes in the unused locations"?
Thanks

CroydonClown
Posts: 3
Joined: Tue Sep 11, 2012 12:23 pm

Re: Baking Pi screen01

Wed Sep 12, 2012 5:37 pm

stampatore wrote:I'd like to try this. Probably a silly question, but can you post your code to show exactly how and where you are "writing zeroes in the unused locations"?
Thanks
Sure, I just added the bit between the comments below. This is in InitialiseFrameBuffer in framebuffer.s - my guess was that some of the locations were not initialised to zero. I'm pretty sure it made a difference for me but I have been randomly hacking about a bit so I may be mistaken.

Code: Select all

	ldr fbInfoAddr,=FrameBufferInfo
	str width,[r4,#0]
	str height,[r4,#4]
	str width,[r4,#8]
	str height,[r4,#12]
	str bitDepth,[r4,#20]

/* Start */
	mov r0,#0
	str r0,[r4,#16]
	str r0,[r4,#24]
	str r0,[r4,#28]
	str r0,[r4,#32]
	str r0,[r4,#36]
/* End */

	.unreq width
	.unreq height
	.unreq bitDepth

Return to “Bare metal, Assembly language”