Guest mode in HVM
Quoted 5 lines · On Tue, Mar 5, 2013 at 11:45 AM, <[email protected]> wrote:
I have a question:
Did I understand right that "HVM Guest mode" is actually native hexagon user mode?
And native hexagon super mode is only used inside HVM during trap1 and exception handlers?
On certain versions of the architecture, yes, it effectively is pushed into user mode.
Quoted 5 lines
It's not possible to specify access mode for user/super mode in TLB.
...
We are going to emulate separate memory access attributes (RWX) for linux kernel and linux user modes by using two different ASIDs for user and kernel mode per hw thread.
Right, the supervisor isn't subject to RWX bits, but it is still subject to ASIDs. I think there was some other nuance to the fault handling, but that was the gist of it.
This brings us to hypervisors which we've sort of skirted in other emails.
There will be changes in the Hexagon architecture from one version to
another, some of which will affect the guest operation and compatibility. Long term, "we" would like to have Linux just deal with the hypervisor interface.
Of course, that isn't useful to anybody without the actual hypervisor. We recognize this and are working hard to try to release some version of a functioning hypervisor for the community to continue tinkering with. If we get that out, perhaps that will be more preferable for you to work on...
That said, I think it's great that you all are motivated enough to go for a bare metal port in the first place (and it looks like you've made great progress). I see no reason to reject bare metal patches, but we would need to keep things clean with ifdefs/config switches...
Thanks,
Richard Kuo
--
Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation
Quoted 36 lines · On 03/05/2013 05:53:09 PM, [email protected] wrote:
Quoted 2 lines · On Tue, Mar 5, 2013 at 11:45 AM, <[email protected]> wrote:
I have a question:
Did I understand right that "HVM Guest mode" is actually nativehexagon
Quoted 2 lines
user mode?
And native hexagon super mode is only used inside HVM during trap1and
Quoted 1 line
exception handlers?
On certain versions of the architecture, yes, it effectively is pushed into user mode.
Quoted 3 lines
It's not possible to specify access mode for user/super mode in TLB.
...
We are going to emulate separate memory access attributes (RWX) forlinux
Quoted 1 line
kernel and linux user modes by using two different ASIDs for user
and
Quoted 1 line
kernel mode per hw thread.
Right, the supervisor isn't subject to RWX bits, but it is still subject to ASIDs. I think there was some other nuance to the fault handling, but that was the gist of it.
This brings us to hypervisors which we've sort of skirted in other emails.
There will be changes in the Hexagon architecture from one version to
another, some of which will affect the guest operation and compatibility. Long term, "we" would like to have Linux just deal with the hypervisor interface.Of course, that isn't useful to anybody without the actual hypervisor. We recognize this and are working hard to try to release some version of a functioning hypervisor for the community to continue tinkering with. If we get that out, perhaps that will be more preferable for you to work on...
Quoted 7 lines
That said, I think it's great that you all are motivated enough to go for a bare metal port in the first place (and it looks like you've made great progress). I see no reason to reject bare metal patches, but we would need to keep things clean with ifdefs/config switches...
Thanks,
Richard Kuo
I would very much like to test this once you can boot a shell prompt on it. Is there some kind of README about what hardware to try to snag off ebay or prospects for getting support in qemu? (If there's a prebuilt toolchain an actual URL to that would be great too.)
Rob
Quoted 6 lines
I would very much like to test this once you can boot a shell prompt on it. Is there some kind of README about what hardware to try to snag off ebay or prospects for getting support in qemu? (If there's a prebuilt toolchain an actual URL to that would be great too.)
Rob
In theory we can run a shell prompt now. However the only console driver is a ram console type thing, so output only. Cotulla also has some kind of screen driver working which has the same problem. The big issue with these devices is getting access to the registers required to cause the processor to boot. This is not only dependent on the processor model, but the specific version of the baseband software installed. Really more so on the latter since any processor could at least in theory provide access. My HP touchpad just happens to use unsigned firmware for the Hexagon. Not many people have tried, so there is no data on other devices with support. At this moment. the touchpad is the only device known to have unlocked access to the DSP boot registers.
If your really inspired it is possible to figure out if a given android device can run unsigned firmware by examining the /lib/firmware/Q6.mdt file on the device. Location kind of varies, but it's somewhere. That file is an ELF header, and if you open it up in a hex editor it will either have a couple thousand bytes of certificate stuff at the end or not. The NSA would be proud to see how well these Hexagons are protected from their owners.
There may be some devices that have firmware signatures but still allow access to the registers. Some modification to the arm side kernel is probably required to prevent it from trying to use the DSP for audio stuff. I have patches for doing that on the touchpad.
There is a toolchain here:
https://www.codeaurora.org/patches/quic/hexagon/4.0/
That toolchain is horrible, and it can't compile anything except the kernel. However it is the only one that can compile the kernel for >V2
Mentor graphics makes one that can actually build programs, what a concept. LD is kind of messed up for greater than > V2 so whatever your building must use gcc to do the linking.
https://sourcery.mentor.com/GNUToolchain/release2194
I used that for making userland stuff like busybox.
Cheers,
Jon
Hello,
Quoted 3 lines
šRight, the supervisor isn't subject to RWX bits, but it is still subject što ASIDs. šI think there was some other nuance to the fault handling, but šthat was the gist of it.
That's sadly :(
Quoted 10 lines
šThis brings us to hypervisors which we've sort of skirted in other emails. ššThere will be changes in the Hexagon architecture from one version to šanother, some of which will affect the guest operation and compatibility. šLong term, "we" would like to have Linux just deal with the hypervisor šinterface.
šOf course, that isn't useful to anybody without the actual hypervisor. šWe šrecognize this and are working hard to try to release some version of a šfunctioning hypervisor for the community to continue tinkering with. š
Will it be releases as binary or as source code?
Quoted 2 lines
If šwe get that out, perhaps that will be more preferable for you to work šon...
Well, we already [i]somehow[/i] almost got full working ;-) But can be useful for another hobby developers.
Quoted 5 lines
šThat said, I think it's great that you all are motivated enough to go for ša bare metal port in the first place (and it looks like you've made great šprogress). šI see no reason to reject bare metal patches, but we would šneed to keep things clean with ifdefs/config switches...
Yes, we got busybox to run rather good as well. Most tests are passed.
Under "we" I mean me and Jonpry. I am working with QDSP6v2 (QSD8250B) and he is working with QDSP6v3 (APQ8060).
Another question which I want to know - QDSP6 has PIPT cache or VIPT?
Best regards,
-Cotulla