For sure, this is for extended mode only.
1 Like
BTW I’m really not sure yet if my original goal is even feasible. I think the display always works at 60 hz. So there should be some kind of conversion going on from 30 hz input to 60 hz to the LCD. I think this might be really hard to add to the code via a FW mod without having any source code, but who knows, I’ll look into it. Basically what we’d need, the easy way, would be to send the same frame twice to the LCD. Better would of course be to have the headset interpolate the images but the easiest way would be to just duplicate each image to end up with 60 hz.
But this would also mean to first detect the frame rate and then convert if it’s 30 hz is detected. This seems quite an ambitious goal for a simple FW mod without any source code, but who knows …
1 Like
Anyway, some more info: those addresses starting with 0xE000 seem to be ARM specific registers, called “The System control block”:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0552a/CIHFDJCA.html
And then we have those 0x2000XXXX addresses. These seem to be specific registers to store info regarding the state of several things, like if the system is in Pimax mode or not. So this seems to be regular RAM.
1 Like
BTW, this is the exact CPU version that’s inside our Pimax:
http://www.st.com/content/st_com/en/products/microcontrollers/stm32-32-bit-arm-cortex-mcus/stm32f4-series/stm32f401/stm32f401ve.html
On that page tons of useful info.
For example: http://www.st.com/content/ccc/resource/technical/document/datasheet/30/91/86/2d/db/94/4a/d6/DM00102166.pdf/files/DM00102166.pdf/jcr:content/translations/en.DM00102166.pdf
page 51 contains a memory map
0x2000 000 - 0x2001 7FFF is indeed the 96 KB System SRAM
1 Like
Ure like ninja o.o
Awesome work !
2 Likes
The first bytes of the binary (after having removed the DFU info like explainded before), are the ‘vector table’. The layout is described here on page 39 of the Programming Manual:
1 Like
I’ve also found this thread on XDA, they’re reverse engineering another STM32 target and the thread contains a lot of very helpful info: LiveView reverse-engineering effort | Page 14 | XDA Forums
1 Like
Anyway, a small update on my project to get 4k@30 hz going: So as I’ve posted in the other hacker thread (wish I had created just one), the bulk of the LCD data that’s getting send to the LCD starts at 0x200008AC. Now I’ve been facing a huge mystery: the data gets read from that table and then written to the LCD over the I2C bus, but where is this data coming from ? This is a RAM location so it must be stored somewhere else and then copied to this location but I could not find a copy routine in the FW ! So I did some research on the internet and what I THINK is happening is that this part is part of the initialized ‘data’ section in the FW. This data is copied to RAM, maybe either by the bootloader or a linker created routine in the FW. The guy in that XDA thread, that I’ve just posted, did a simulation of his ARM binary and found the initialization data that way, with “Crossworks for ARM”, I’ve just downloaded it and am now waiting to receive my evaluation license.
Anyway if my theory is correct, I hope to find the init values at 0x200008AC via this simulation. Once I have those, I have the LCD data that’s being sent to the display to configure it. Hopefully this is somewhat standardized data and/or can be deduced easily. Next step would then be to modify it for 4k @ 30 hz, flash, run and PROFIT 
But who knows, it’s still a rocky road from here …
4 Likes
Its great work. Thank you. We hope that you will find needed solution to initialize 4k resolution
1 Like
Awesome Bro !!! I have a Champagne ready when your done LOL 
1 Like
Thanks guys. Well I have some good news today, I’ve successfully taken the next step ! I received my CrossStudio demo license yesterday and started messing around it. I loaded the FW but it kept crashing once I tried executing it. Then I figured, maybe I need the bootloader too ! But wait, we don’t have the bootloader, it’s in our headset’s ROM area Luckily I had already found some tools on the internet that can both read and write STM32 ROM & EEPROM, however the tool that looked most promising kept crashing after 49% of downloading the firmware region, it seemed it thought our FW was twice as big which made it crash once it broke the limits. So, I had to adapt that tool (luckily there was source code) and then I managed to dump the bootloader + our FW from ROM and EEPROM.
So, I then loaded that whole memory region into Cross studio and I could execute the bootloader and it didn’t crash anymore ! Then I did it again, changed the SP to the first initial vector value of our FW and set execution point to the entry point of our FW and it started executing ! Then I quickly found the routine that set the ‘initialized data’ region and I was right in my previous post: the whole region where the LCD data lies in RAM, is ‘initialized data’, that’s get set by some bootstrap routine, probably created by the linker !
In other words, I now have all the LCD commands that our FW sends to the LCD panel to configure it ! Yihaaa
Now the next part might be the hardest part and also might be where I strand because this is all manufacturer specific data and it might simply be too hard do deduce/analyse. But I’m going to try and see if I can make sense out of the LCD data in the coming few days. This probably entails some internet research too, hopefully the LCD commands are pretty standardized, which would make it so much easier. If not, this might turn out a very hard nut to crack without getting data from the manufacturer…
We’ll see Anyway, really happy with all the progress I’ve made so far !
4 Likes
woah great job!
whst’s your end goal after all this reverse engineering?
1 Like
Currently trying to get 4k natively going, at 30 hz, good for movie watching for example.
1 Like
What about 90hz 1080?
It would put this on par with current iteration of oculus and vive.
I’d still take 2k 60Hz over 1080 90Hz but having the option would be nice anyway
1 Like
Once I have it working I can try all kinds of stuff, as long as the panel supports it.
Anyway as I was afraid, the LCD commands aren’t really easy to deduce. We need a datasheet for the LCD panel. I opened a thread for it: http://community.openmr.ai/t/lcd-panel-type/1697
EDIT So I’ve found the LCD type (which doesn’t support 90 hz btw). Now all we need is the datasheet !
1 Like
This stuff is way over my head now. But if you can get 4k 30hz, You’d have turned my paperweight into something useful! Thanks for doing this guys!
sjefdeklerk did you find the datasheet? I might try and see if I can find one for you. So which LCD are you looking for?
Nope, never gotten the datasheet. It’s a Sharp LS055D1SX05. I did find the datasheet for the LS055D1SX04 though.
LS055D1SX05 & LS055D1SX04 though 4k seems to be different. Also in pin configuration
1 Like
May be you can mail Dave
1 Like