yashsingh1/xdaforums huggingface dataset:
[HD Mini Android Development] -r0bin-:
yes, this line:

mrc	p15, 0, r0, c1, c0, 0

based on the excellent ARM datasheet you provided, this is the command that LOAD the MMU register into register R0 (see registers p.163)

it is not even writting the new value!

whatever I do in the ASM code, (add or remove commands), I always get crash at the same instruction (read MMU register).

I tried to reset the FCSE PID before calling this instruction:

But still got crash at the same command.

I wonder if we have the access right to modify this register?

the issue is, we dont know what exception is raised, this is a blind search :-)
[HD Mini Android Development] cardsharing:
i am contacted arm.c o m and asked him for help (Hallo , please help me to edit one source code. I have no knownledge how to correct this code,

my aplication always crash at the same place. I coud not find way how to fix this assembler

stuff, becayse always crash at specific location...etc), and he replied me with this message::)

...and im asked for a new help and im waiting reply...i will report here:D
[HD Mini Android Development] -r0bin-:
great!

can you ask him how to access in "privilege mode"?

what instructions to execute for that?
[HD Mini Android Development] cardsharing:
I will ask for it if he not ignore me in next reply because i not have company:(
[HD Mini Android Development] -r0bin-:
just pretend you work for HTC :-)
[HD Mini Android Development] tzacapaca:
hi guys,

here is some info about arm modes

http://www.botskool.com/user-pages/tutorials/electronics/arm-7-tutorial-part-2

its about arm 7 but maybe is the same..hope it helps:)

edit: and here http://www.keil.com/support/man/docs/rlarm/rlarm_ar_cfgrunpriv.htm

and here for ARM V6 http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0471b/BABDCIEH.html

In ARMv6, new instructions have been added to the ISA to improve the implementation

of interrupts and exceptions. These provide the ability to efficiently nest exception

handling onto a different privileged mode.

New instructions support fast mode changes in privileged modes. Instructions cannot be

used in user mode for security reasons.

• CPSID #Mode (and disable interrupts)

• CPSIE #Mode (and enable interrupts)

The CPS instructions allow software to move efficiently to a different mode while

enabling or disabling interrupts
[HD Mini Android Development] schlund:
hmm i know what this line does, but i feared that it really is reason ..

why should a load crash ?

- less privileges...

- wrong synthax

- wrong registers ?

if you take a look at kernel source you will see there is a different way to load mmu register you will never find this line, that crashes our code

as i read the manual, the procedure should be following (what is absolutely needed to boot):

- turning off DCache

- turning off ICache

- turning off MMU

- invalidating caches

-> boot

(in this order)

EDIT @tzacapaca: arm v7 is VERY different to v6 !!
[HD Mini Android Development] tzacapaca:
@schlund,sorry my bad i was hurry and didnt compare

but i think i found the way how to change,check it please ;)

You can change from Privileged Thread to User Thread mode by clearing CONTROL[0] using an MSR instruction. However, you cannot directly change to privileged mode from user mode without going through an exception,

CPS <effect> <iflags>, #<mode>	2	Mode changing

source: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0471b/BABDCIEH.html
[HD Mini Android Development] -r0bin-:
Unfortunately i dont know how to execute code by raising an exception

Well I did this:

@ Force MMU update and invalidate I cache
mov	r0, #0
mcr	p15, 0, r0, c7, c10, 4	@ Drain write buffer
mcr	p15, 0, r0, c8, c7, 0	@ Invalidate I+D TLB
mcr	p15, 0, r0, c7, c5, 0	@ Invalidate I cache & BTB
CPWAIT r0

@ Jump to code with shared virtual/physical mapping
add pc, r4, #(1f - mmu_trampoline)

1: @ Code is running at a vm address that is the same as its
@ physical address. Now disable the MMU.
nop
mrc	p15, 0, r0, c13, c0, 0
nop
bic	r0, r0, #0xFE000000 @ clear PID
nop
mcr	p15, 0, r0, c13, c0, 0
nop
mrc	p15, 0, r0, c1, c0, 0
nop
bic	r0, r0, #0x4	@ Dcache off
nop
mcr	p15, 0, r0, c1, c0, 0	@ write
nop
mrc	p15, 0, r0, c1, c0, 0
nop
bic	r0, r0, #0x1	@ MMU off
nop
mcr	p15, 0, r0, c1, c0, 0	@ write
nop
mrc	p15, 0, r0, c1, c0, 0
nop
bic	r0, r0, #0x1000	@ MMU & Dcache off
nop
mcr	p15, 0, r0, c1, c0, 0	@ write
CPWAIT r0

But still, I get crash at the same fuc*** line:

mrc	p15, 0, r0, c1, c0, 0

I can access any other registers of P15 (all the other mcr and mcr calls above)

But it seems that, when I try to access the c1 register (Control Register), it crashs.

damn!
[HD Mini Android Development] schlund:
i read through tzacapaca's link ..this sounds to be our problem !
[HD Mini Android Development] tzacapaca:
http://www.embeddedrelated.com/usenet/embedded/show/98970-1.php

there is a guy trying to switch to privilege mode too..i pass this to you guys,sorry i dont understand much
[HD Mini Android Development] cardsharing:
Hey mates hey r0bin, please look at msm7227 kernel source "/root/htc-kernel-msm7227/arch/arm/boot/compressed/head.S" i think this is way to port it to haret ;). Code located in haret have not provilegies to turn off mmu and we always get exceprions, but in head.S is all about turning off mmu
[HD Mini Android Development] RoSo:
I found this on a Chinese forum.

maybe it helps. I don't know !
[HD Mini Android Development] schlund:
this is what i said before:

theres a different way of reading control register
[HD Mini Android Development] tzacapaca:
http://www.inetintel.com/embeddeddo... Designing and Optimizing System Software.pdf
[HD Mini Android Development] Olivados:
Hi Guys

It's been a long time I read this post : I understand nothing among the 20 last pages, but it seems encouraging to see Android one day in my HD mini !

Congratulations to you all, I'm ready to donate 10€... just advise me when and how
[HD Mini Android Development] -r0bin-:
Guys, I might have another explanation:

Could it be that the Program Counter (=PC, address you got when excpetion is raised) is wrong and points to the latest virtual address he has when the program crashes?

If this is true, it might be that the MMU is successfuly disabled, then program crash AFTER and the latest virtual address of the Program Counter we got is... the line where MMU is disabled.

This sounds so true, because we can access the p15 registers and modify them:

we already are executing code in kernel mode with priviledges.

What do you think?
[HD Mini Android Development] cardsharing:
hmmmm :( i dont know :( Here is sspl.exe (i tried it to run directly from phone and its go phone to bootloader with cotula sspl :D). Waiting disasembling hehe
[HD Mini Android Development] NetRipper:
(r0bin and I have been talking via PM today, but we'll continue here)

Hi,

I'm not sure how you debug HaRET and where the crash "ends up", but when the MMU is really disabled, it's impossible for Windows CE to resume functionality. So if HaRET crashes and you can use the device (i.e. your telnet/haretconsole) connection to HaRET, then the MMU was not disabled. The PC will point at the current address being executed. When the MRC instruction to read the control register is read, the code should be running on a memory area that has the same physical/virtual address. The PC will be valid. The PC would be invalid when HaRET wouldn't use the trampoline (or fails).

To properly debug, you should try to find a GPIO you can enable/disable for something that has a visual or audible effect. Most devices have like a flashlight led, notification led, vibrator motor, keypad lights, lcd light or even soft-reset accessible via a GPIO bit. GPIO's are the easiest way to test if "code is reached". If you find the GPIO for, for example, flashlight, you could insert that code just before the MRC instruction. When the light turns on, you know it reached that code. Next you place the same code below the MRC instruction. If it reaches it, you know that it worked. Etcetera. After the MMU is disabled, you obviously need to use the physical address of the GPIO bank instead of the virtual (wince) address.

Example for accessing flashlight on the HTC HD2/Leo: http://htc-linux.org/wiki/index.php?title=Leo/FlashlightTest

Regards,

NetRipper
[HD Mini Android Development] tzacapaca:
Finally we have a dev here :D

Thank you NetRipper for coming here and helping us!
[HD Mini Android Development] _Madmatt:
We're on the good way! If someone can tell me how I can find GPIO adress for LED, I'll try to add it in HaRET (if you can tell me were to add and how to compile.)

Can I get the source of the best working HaRET we have so far?

New to Linux, installed it yesterday, so please be patient with me and give help :)
[HD Mini Android Development] NetRipper:
You can find the latest compiled version of HaRET here:

http://netripper.com/leo/haret-pre-0.5.3-20101122_234613.exe

Based on these sources:

http://git.linuxtogo.org/?p=groups/haret/haret.git;a=summary

Documentation on HaRET:

http://htc-linux.org/wiki/index.php?title=HaRET

You can get an easy-to-use-haretconsole for windows here:

http://netripper.com/raphael/HaretconsolePackageForWin.zip

But be sure to update it with the latest haretconsole files:

http://netripper.com/leo/haretconsole-pre-0.5.3-20101214_194802.tar.gz

Note that this HaRET is not specially prepared for MSM7227. Nor that this HaRET has specific support for the HD Mini. There may be developers present that have added the HD Mini so that it is properly detected and the correct architecture is used for it (but that code is not in the official HaRET yet then). If GPIO bank locations differ from the existing MSM7201A code, they need to be added as well. They also need to be added in haretconsole python files for easier debugging. Developers can look at the existing code for inspiration on how to do that :)

How to go about finding a GPIO...

First you need a HaRET that is prepared to work for your device. The above .exe probably won't be of much use. The "watch gpios" command must be working. Basically, you watch gpios for like 30 seconds and within that time, you enable the flashlight of your camera (if you have one on the HD mini). Then try to find any related GPIO changes. Try changing the GPIO's 1 by 1 manually (hoping you won't damage your device, very very small chance though) and if you find the GPIO that turns on/off your led, save that one. There's your debugging bit!

It doesn't neccesarily have to be a led. Anything that causes some sort of reaction on the outside of your device can be useful. Even if it's a soft-reset or LCD turning off.

[edit]This is the trial/error method obviously. The very best way is to reverse engineer the dll's and trying to find stuff that way. I'm more the trial/error kinda guy though. ;)[/edit]
[HD Mini Android Development] cardsharing:
Anyone have link for full pdf spec guide for msm7227
[HD Mini Android Development] NetRipper:
Unfortunately the Qualcomm MSM7227 documentation is under NDA, so it's not available for the public.

The MSM7227 is based on the ARM1136J(F)-S core though, that documentation is available. You can find links to it in the last few pages. You'll just be missing Qualcomm specific stuff (which is still a lot!).
[HD Mini Android Development] _Madmatt:
Thanks! So, someone who has a quite good working version of HaRET on our Mini?

A chance of bricking my device? :o This scares me... :s

However, I'll take a look :)

Edit: Can someone give me his/her .txt file that you use to get HaRET started on HD Mini? Thanks!
[HD Mini Android Development] schlund:
thank you so much NetRipper,

the idea of using led to debug is wonderful!

this should already work in haretconsole, i remeber using/testing this weeks ago!
[HD Mini Android Development] cardsharing:
Watching GPIOS(00): Addr 92f00800(@a9200800)
Watching GPIOS(01): Addr 92e00c00(@a9300c00)
Watching GPIOS(02): Addr 92f00804(@a9200804)
Watching GPIOS(03): Addr 92f00808(@a9200808)
Watching GPIOS(04): Addr 92f0080c(@a920080c)
Watching GPIOS(05): Addr 92f00850(@a9200850)
Watching GPIOS(06): Addr 92f00834(@a9200834)
Watching GPIOS(07): Addr 92e00c20(@a9300c20)
Watching GPIOS(08): Addr 92f00838(@a9200838)
Watching GPIOS(09): Addr 92f0083c(@a920083c)
Watching GPIOS(10): Addr 92f00840(@a9200840)
Watching GPIOS(11): Addr 92f00844(@a9200844)
Watching GPIOS(12): Addr 92f00810(@a9200810)
Watching GPIOS(13): Addr 92e00c08(@a9300c08)
Watching GPIOS(14): Addr 92f00814(@a9200814)
Watching GPIOS(15): Addr 92f00818(@a9200818)
Watching GPIOS(16): Addr 92f0081c(@a920081c)
Watching GPIOS(17): Addr 92f00854(@a9200854)
000000: mem GPIOS(0) 92f00800=00000000 (00000000)
000000: mem GPIOS(1) 92e00c00=00008202 (00000000)
000000: mem GPIOS(2) 92f00804=00060000 (00000000)
000000: mem GPIOS(3) 92f00808=00100100 (00000000)
000000: mem GPIOS(4) 92f0080c=00000000 (00000000)
000000: mem GPIOS(5) 92f00850=00007804 (00000000)
000000: mem GPIOS(6) 92f00834=0000115c (00000000)
000000: mem GPIOS(7) 92e00c20=07b09a3e (00000000)
000000: mem GPIOS(8) 92f00838=01f61f46 (00000000)
000000: mem GPIOS(9) 92f0083c=041c8102 (00000000)
000000: mem GPIOS(10) 92f00840=00000000 (00000000)
000000: mem GPIOS(11) 92f00844=00007824 (00000000)
000000: mem GPIOS(12) 92f00810=00008000 (00000000)
000000: mem GPIOS(13) 92e00c08=000fc282 (00000000)
000000: mem GPIOS(14) 92f00814=01fe2009 (00000000)
000000: mem GPIOS(15) 92f00818=03fa410d (00000000)
000000: mem GPIOS(16) 92f0081c=000001f8 (00000000)
000000: mem GPIOS(17) 92f00854=03ffffd7 (00000000)

Thanks mate. I use nledset 1 1 command for constant vibration and nledset 1 0 to turn off vibration, but not know what is gpio adresse, but you say only way to try this is to use one to one? Ok my question is: example for "000000: mem GPIOS(1) 92e00c00=00008202 (00000000)":

ldr r4, =0x92e00c00 @ bank6_in (phys)

ldr r5, =XXXX @ bank6_out (phys)

xxxx = 0x92e00c00+0x8202 if im right???
[HD Mini Android Development] _Madmatt:
When I start HaRET, I get this: "Failed to load file: <Path>\zimage". Anyone can help? :)

Edit: okay, I found a zimage here. My device is stuck at "Turning off MMU..." too, so everything works "fine"...
[HD Mini Android Development] numex:
ARM1136J(F)-S

This essambled time ago 2 years before what the mini´s came so...

Must to be an old processor , its maybe overclocked, i see the documentation and its seems omega processor

So we have to have knowloedge about this processor,i think the tricks is in this

mem GPIOS(0) 92f00800=this not have a value but its has a continuity 00000000 (00000000)

000000: mem GPIOS(1) 92e00c00=00008202 (00000000)<-----

000000: mem GPIOS(2) 92f00804=00060000 (00000000)

000000: mem GPIOS(3) 92f00808=00100100 (00000000)

000000: mem GPIOS(4) 92f0080c=00000000 (00000000)

000000: mem GPIOS(5) 92f00850=00007804 (00000000)

000000: mem GPIOS(6) 92f00834=0000115c (00000000)
[HD Mini Android Development] _Madmatt:
I now use this .txt file to say HaRET what it should do. However, It says "Unknown keyword: "HaRET"". Someone can help me? :)

HaRET(2)# set ramsize 0x14000000
HaRET(3)# set ramaddr 0x10000000
HaRET(4)# set mtype 3162
HaRET(5)# set cmdline ""
HaRET(6)# boot
boot KERNEL=zimage INITRD=
Opening file zimage
boot params: RAMADDR=10000000 RAMSIZE=14000000 MTYPE=3162 CMDLINE=''
Boot FB feedback: 1
Built virtual to physical page mapping
Allocated 613 pages (tags=0x5f100000/21a8a000 kernel=0x5f101000/21a89000 initrd=0x5f361000/21829000 index=0x5f361000/21829000)
Built kernel tags area
Built page index
Tags will be at offset 0x00000100 (0xf00)
Kernel will be at offset 0x00008000 (0x25ff14)
Initrd will be at offset 0x00508000 (0x0)
Video buffer at 0x4a55a000 sx=320 sy=480 mx=80 my=80
Video Phys FB=04f71000 Fonts=218270c0
preload=3152@0x5f364000/21826000 sj=0x5f364278 stack=0x5f362000/21828000 data=0x5f363000/21827000 exec=218263a0
Reading 2490132 bytes...
Read complete
Launching to physical address 21826288
Trampoline setup (tram=136@0x2ed50/2402ed50/02394d50)
MMU setup: mmu=0xa1910000/01a10000
Go Go Go...
[HD Mini Android Development] cardsharing:
Hallo Madmat please open onother post about starting haret, sorry and thanks
[HD Mini Android Development] _Madmatt:
Another thread you mean? Why? :o
[HD Mini Android Development] _Madmatt:
Possible solution to MMU.

Okay, yesterday Tzacapaca and me found how we should fix the MMU issue. In other words, how we can disable MMU. Tzacapaca asked me to Google something, don't remember what exactly, and then I found a PDF file. In that file, there is a description on what bit we should change to disable MMU.

As I'm now online with my phone (a HD Mini of course!), I can not post the file because it is saved on my computer. However, I'll post it later today (in the afternoon).

I don't know how to decompile HaRET, to edit the line where we disable MMU, but I hope that you guys can do that! :)

See you later today with an attachment!

MadMatt and Tzacapaca.
[HD Mini Android Development] tzacapaca:
MMU Enabling/Disabling

in the attached pic
[HD Mini Android Development] -r0bin-:
Hi guys,

Thanks for the info, but seems that it's exactly what Haret is doing already.

mrc/mcr p15,0,rx,c1,0

What could be good is, if someone can find the GPIO to enable/disable the vibrator, or the green led.

I didnt have the time to find the info yet, but this is very useful to debug, as NetRipper explained:

The trick to get the PC and find the line where the program crash might not be reliable at this point of execution, and i'm not sure the memory mapping stuff before the MMU disabling is effective.
[HD Mini Android Development] tzacapaca:
hi r0bin,

i found GPIO enable/disable for Raphael,i don't know if it depends on processor type or anything else,but maybe it helps or u can get even an idea

http://www.htc-linux.org/wiki/index.php?title=Raphael_GPIO
[HD Mini Android Development] NetRipper:
I agree. It's very much possible the MRC instruction is not at fault, but the trampoline code.

Did anyone try the changes as described on the mailing list here?

http://lists.linuxtogo.org/pipermail/haret-devel/2010-February/000013.html

Maybe I can add some basic support for the HD mini in HaRET. To detect your phone and possibly to include the change as described in the mailing list for you to test.

In order to do this, I need you guys to post your haretlog.txt. To get your haretlog, create an empty file in the same directory as haret.exe and call it "earlyharetlog.txt" (exactly like that). When this file is present, and you start haret.exe, it will create "haretlog.txt". Pastebin that file to http://hdmini.pastebin.com/ and/or post it here.

Btw, note that if HaRET does _not_ crash and the whole device hangs, that this is usually a good sign! There might be a kernel for 7227, but it is in no way compatible with your device so you can't expect it to boot! When HaRET is working and seems to be able to boot the kernel, there's not much I can do. Other developers with the HD mini will have to continue the work from there.
[HD Mini Android Development] NetRipper:
The way GPIOs work is generic per processor type, but the meaning of each individual GPIO is different per device. There are even sometimes GPIO differences between versions of the same device. For example, The first generation HTC Touch Pro has different GPIOs for the SD card compared to the US version of the HTC Touch Pro.

You need to reverse engineer and use HaRET on the HD mini to figure it out for the HD mini.
[HD Mini Android Development] -r0bin-:
Yeah. I'm trying to understand how the trampoline code works, specially the address mapping. asm is very tough to read!

yes, we did. still crashes though.

i cant understand why, since it is working well on MSM7225

I also need to understand the patch fix, since it seems that MSM722x uses MVA (modified virtual addresses) instead of regular VA (virtual addresses).

That causes the code "virtual to physical translation" not working.

NetRipper, do you have an explanation or documents on why we have to make virtual addresses equal physical addresses? (the memory mapping stuff and the jump, that occurs just before the MMU disabling command)

we did it too (Schlund patch). I can send you the source code.

I'm thinking to post all the source code we've done so far on a webpage, so we can share the latest progress on this.

yeah I have tons of haretlog.txt :-)

latest ones enclosed to this thread

You are right, I am wondering the same...

but we should at least be able to see the pre-loader and bootloader output on the framebuffer, isnt it?

in our case the traces stop at "Disabling MMU..."

or, maybe we need to re-initialize the frame buffer? (which I have no idea how to do right now haha :-P)

We have compiled the MSM7227 kernel version from HTC: The HTC Aria (aka Liberty) is almost similar to HTC HD Mini, but runs android.

Of course I don't expect the kernel to be 100% compatible (i also stopped believe in santa clauss ;)) but at least we should see something on the screen... isnt it?
[HD Mini Android Development] yakamoz:
Hello,

I don't know anything about Linux Kernel compilation, but afaik Android is based on the regular Linux Kernel 2.6 . Isn't it possible to create an minimal Linux Kernel without any graphical output but command line? Just to test wether our HaRET is working or not...?
[HD Mini Android Development] schlund:
these files should add basic support correctly (don't know which files robin is using, but my first changes were not right :) )
[HD Mini Android Development] NetRipper:
The reason why they have to be the same is pretty straightforward. When the MMU is enabled, all memory accesses are 'virtual'. When the MMU is disabled, all memory accesses are 'physical'.

Imagine you have one memory bank of 256MB ram at physical address 0x2000000 to 0x2fffffff. When the MMU is enabled, this virtual bank is mapped on (for example) 0x80000000 - 0x8fffffff. Suppose your code is running from address 0x80001000 when the MMU is enabled. You code disables the MMU and the PC (program counter) moves to the next instruction at 0x80001004. Now that the MMU is disabled, the virtual memory is gone. There is nothing at 0x80001004. Instead, your code is at 0x20001004. As nothing is there, it crashes and the device hangs or auto-soft resets in some cases. This is the reason why we must do it.

How exactly this is done, is also not fully understood by myself. The original author (Kevin O'Connor) built that. I'm not fully familiar with page tables and segments etc.

I'd appreciate that. By the way, if you register on www.htc-linux.org you can change the wiki pages there and create wiki pages for the HD mini. We've used that site for Raphael, Leo and other HTC devices. It has a ton of information.

Well if the MSM7227 is anything like the MSM7201A, MSM7200, MSM7500, MSM7500A, QSD8x50 (and any other recent (< 3 years) qualcomm processor), it probably needs a DMA to blit the framebuffer to the LCD. Without the DMA, the framebuffer is changed in memory, but the changes are never sent to the LCD screen. I have modified HaRET to do this for the Leo. With the information in the msm7227 kernel it might be possible to do this for HD mini too.

Probably it hangs well before it reaches any graphics code. The default android kernel does not have a framebuffer textconsole, so the graphics code doesn't initialize till pretty far into booting the kernel. Well before that time, the kernel probably hangs on various incompatibilities. Such as the memory map (pretty important), the GPIO differences, IRQ differences (although these are smaller) and many other things.

Let's start with HaRET and we'll go from there.