What am i doing wrong when accessing and using a framebuffer


30 posts   Page 2 of 2   1, 2
by LdB » Fri Jun 09, 2017 2:09 am
Now I went back thru my own personal notes on stuff I had found with the PI and answering the question about the HYP MODE and the need to bring the FPU online.

The newlib C base library uses the FPU regardless of whether you have a single FLOAT or DOUBLE in your code. If you use the printf, vsprintf and a number of the string functions in the standard lib there is some sort of setup which calls the FPU even if they only ever deal with int's. It will also make at least one S_BRK call to allocate an internal buffer for many of those same functions.

It is in the C base library (newlib from redhat), so I was wrong the problem is true on all versions of Pi when using C.

After you do the FPU if you want to put it back to HYP_MODE it should be just the OP code command
msr CPSR_c, #0xDA
I haven't checked but I can't remember any reason you can't just goto HYP from SRV mode. Coming the other way you use that function I have provided and used in the first place (it is setup to be linked to C just make a extern C function).

So if you don't deal with the FPU and S_BRK you will need to be very careful with what C library functions you use.

Anecdotally I have notes on not setting the FPU up leading to strange bus behaviour and crashes but in all the code exhibiting the problems I had interrupt code. I have a note to one rainy day, get around to see if the link is real.

So that is all the detail I have in my personal notes and errata file on the Pi. Like knowing that the two fields you gave me were reversed this detail is from the school of hard knocks and not something documented anywhere.
Posts: 308
Joined: Wed Dec 07, 2016 2:29 pm
by Makogan » Fri Jun 09, 2017 2:37 am
IT WORKS!

Many things:

First and most important thank you LDB for your help, the changes to boot.S saved my sorry butt.

Second I am incredibly confused, we got it to work yet it seems we still are not doing the same thing. I'll be more specific. After I added your fpu initialization code I found that I still couldn't get any results. At least not to my satisfaction, so I tested things and ended up going back to the documentation format so first fb_ptr and then fb_size.

In other words, this is what my code looks like now:

Code: Select all
volatile temp t __attribute__ ((aligned (16)))=
{
  .size = sizeof(temp),
  .request = 0,

  .tag1 = SET_PHYSICAL_WIDTH_HEIGHT,
  .buff_size1 = 8,
  .val_length1 = 8,
  .widthP = 1024,
  .heightP = 768,

  .tag2 = SET_VIRTUAL_WIDTH_HEIGHT,
  .buff_size2 = 8,
  .val_length2 = 8,
  .widthV = 1024,
  .heightV = 768,

  .tag3 = SET_DEPTH,
  .buff_size3 = 4,
  .val_length3 = 4,
  .depth = 32,

  .tag4 = ALLOCATE,
  .buff_size4 = 8,
  .val_length4 = 4,
  .fb_ptr = 16,
  .fb_size = 0,

  .end = END,
};

void init_display()
{
  write_to_mailbox((uint32_t) &t | 0xC0000000, (Channel)(PTAG_ARM_TO_VC));
  read_from_mailbox(PTAG_ARM_TO_VC);

  while(t.request == 0x80000001)
  {
   // blink();
  }

  for(uint32_t i=0; i < t.fb_size; i+=t.depth/8)
  {
    *(volatile uint32_t *)((t.fb_ptr & ~0xC0000000) + i) = 0xFF00FFFF;
  }
}


And it works, exactly as intended (screen becomes giant cyan rectangle). I swear I am not trolling nor trying to confuse anyone. This is what worked for me, I am not sure why it also worked when you flipped them.

But on any case, it works!!!!
Posts: 67
Joined: Tue May 16, 2017 9:17 pm
by LdB » Fri Jun 09, 2017 4:22 am
Hmm you got me intrigued, I don't doubt you .. so is that a Pi2 or Pi3?

Mine is on a Pi3 and I wonder if they had a bug in firmware I am working to and now fixed. My boards using the firmware I have is definitely backwards. Time to make sure my firmware is up todate and go check the linux driver :-)

That sort of thing can happen I have seen earlier examples things like the order of red and blue suddenly changed in 32 bit mode one revision of firmware. The whole mailbox is running on the VC code and they do change and update things from time to time.

I would not panic about it that is what it will most likely mean and your code matches your firmware.
Posts: 308
Joined: Wed Dec 07, 2016 2:29 pm
by Ultibo » Fri Jun 09, 2017 10:34 am
LdB wrote:Mine is on a Pi3 and I wonder if they had a bug in firmware I am working to and now fixed. My boards using the firmware I have is definitely backwards. Time to make sure my firmware is up todate and go check the linux driver :-)

Odd, the Linux driver seems to have always done it the way the documentation says ;)
Ultibo.org | Make the future
https://ultibo.org
User avatar
Posts: 83
Joined: Wed Sep 30, 2015 10:29 am
Location: Australia
by LdB » Sun Jun 11, 2017 8:43 am
Definitely corrected on new firmware I just downloaded new firmware and none of my old Pi3 code works because they fixed it.

My Pi3 firmware dates back to when they were fixing up the startup on the Pi3 which was really really iffy and they patched. I hadn't found any problems and had been using since.

However that function on the firmware as per the strange code I have to use and my screenshots is clearly dorked.

As I stated I should not have been surprised because they got the colour wrong on the prior version of firmware.
A number of other people and linux users noticed that problem :-)

I had already seen people like RTEMS had trouble with the framebuffer allocation
So when it didn't work it did not freaked me out I just methodically worked thru the firmware response.

I should have revisited the problem but to be honest until this thread I wasn't aware of the change and he had bigger issues than the framebuffer stopping his code working.

It was easy enough to solve the problem as he found once you made dam sure everything else was coded correctly :-)

Long and short of it fixed on new firmware but definitely dorked on some older versions of firmware. Another to add to my stories with the Pi.
Posts: 308
Joined: Wed Dec 07, 2016 2:29 pm