yashsingh1/xdaforums huggingface dataset:
[HD Mini Android Development] cardsharing:
Yes, maybe kernel works, but not shown on lcd. Maybe is way to add some vibrators signals or led signals to kernel code hmmm???:confused:

Also we need to add to arch-msm.cpp:

MachineMSM7xxx::MachineMSM7xxx()
{
name = "Generic MSM7xxx";
flushCache = cpuFlushCache_arm6;
arm6mmu = 1;
archname = "MSM7xxx";
CPUInfo[0] = L"MSM7500";
CPUInfo[1] = L"MSM7200";
}

CPUInfo[2] = L"MSM7227";

instead of:

MachineMSM7xxxA::MachineMSM7xxxA()
{
name = "Generic MSM7xxxA";
flushCache = cpuFlushCache_arm6;
arm6mmu = 1;
archname = "MSM7xxxA";
CPUInfo[0] = L"MSM7201A";
CPUInfo[1] = L"MSM7227";
}

Now im fixed that, i will compile haret without msm 7225 patch and with msm7225 patch and i will post 2 haret here when done/

Edit: Here is haret without msm7225 patch

Edit: Here is haret with msm7225 patch

Edit: Here is haretlog without msm7225 patch

Edit: Here is haretlog with msm7225 patch
[HD Mini Android Development] -r0bin-:
ok guys, i think i have an idea about the haret bug.

actually, since we added the MSM7225 patch, we modified the function trampoline.

and, as surprising it might sounds, in the trampoline function there is a call to the next mapped section with a memory offset hardcoded:

When we add the 5 lines of code of the patch, we must impact the jump address offset, otherwise we will jump on the lines before.

Here is the modified source with the correct offset.

(Note: 1f is not in hexa, in fact in the binary it is equal to 0x4C. 5 lines = 0x4*5=0x14. 0x4C+0x14=0x60)

Thus, the correct jump address is:

I am not quite sure about the correct settings, because right now i didnt noticed a big change.

But the logic is here, it has to be modified.

I attached my source code of Haret, with the patchs of Schlund and MSM7225 plus the asm patch, feel free to look.

I attached the new binary, please try it on your devices and tell me if there is a difference now :-)

thanks
[HD Mini Android Development] schlund:
@ cardsharing: no! when you compare sources you will see that msm7227 is the same like harets msm7xxxa settings!
[HD Mini Android Development] cardsharing:
yes mate but i see init is diferent:

MachineMSM7xxx::init()
{
runMemScript(
"set ramaddr 0x10000000\n"
"addlist irqs p2v([color=green]0xc0000000[/color]) 0x100 32 0\n"
"addlist irqs p2v([color=green]0xc0000004[/color]) 0 32 0\n"
);
defineMsmGpios();
}

and

MachineMSM7xxxA::init()
{
runMemScript(
"set ramaddr 0x10000000\n"
"addlist irqs p2v([color=red]0xc0000080[/color]) 0x100 32 0\n"
"addlist irqs p2v([color=red]0xc0000084[/color]) 0 32 0\n"
);
defineMsmGpios();
}
[HD Mini Android Development] schlund:
yes, but first is wrong and second is correct! look at differences in kernel source!
[HD Mini Android Development] _Madmatt:
Okay, in attachment you can find the PDF file I was talking about to disable MMU. If someone can tell me if this is done correctly in HaRET source? If not, please edit so the correct bit is set.

If you want to look in the PDF yourself, look in Section 6.4.

This is what it says:

Hope you can do something with it!

PS: Had to ZIP it because of filesize limit...
[HD Mini Android Development] cardsharing:
ok .
[HD Mini Android Development] _Madmatt:
Can you look at HaRET source?
[HD Mini Android Development] cardsharing:
no mate .
[HD Mini Android Development] _Madmatt:
Someone else who knows how we can set that bits?
[HD Mini Android Development] NetRipper:
No. On the PC it might be easy to use the command line, but there is no such thing on mobile devices. You need to write your own console driver that accepts character input from the kernel and outputs it to the screen. Luckily a very basic "to get started" console is probably not that hard to make. However, fixing HaRET is what needs to be done first.

HaRET already does this. Look here:

http://git.linuxtogo.org/?p=groups/...c6aeba51262b23a30801ce2189ef7e16a2c5c;hb=HEAD

175 1: @ Code is running at a vm address that is the same as its
176 @ physical address. Now disable the MMU.
177 mrc p15, 0, r0, c1, c0, 0
178 bic r0, r0, #5 @ MMU & Dcache off
179 bic r0, r0, #0x1000 @ Icache off
180 mcr p15, 0, r0, c1, c0, 0 @ disable the MMU & caches

line 177 = read the control register

line 178 = clear bits #5 = 5 = b101 = bits 0 and 2 = mmu and dcache)

line 179 = clear bit #0x1000 = 4096 = b1000000000000 = bit 12 = icache)

line 180 = write new value to control register

My guess is that there's nothing wrong with this code. I believe r0bin is on the right track.

Source is here:

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

The 7227 is more like 7201A than the 7200 and 7500. I think it's correct to use 7201A as inspiration.
[HD Mini Android Development] _Madmatt:
Okay, nice! Thanks!

Yeah, I know, but I meant can someone look at the code to see if HaRET does that. You did already, so OK :)

Btw, here is my HaRET log.txt, strange is that it doesn't log a exception..
[HD Mini Android Development] cardsharing:
ok, our kernel we use is configured with defconfig 7227, but ok
[HD Mini Android Development] NetRipper:
Yes, for linux you use the 7227 arch and defconfig. But HaRET doesn't have 7227 support. You suggested using the 7200/7500 init, but the 7201A in HaRET comes closer to the 7227 (gpio banks etc). I've not confirmed the gpio banks though, but as I have seen some GPIO traces in this thread already, I assume they are good :-)
[HD Mini Android Development] -r0bin-:
i think I found the GPIO of vibrator.

I got this when I touch the screen to select "vibrator mode"

001.198 GPIOS out3: out3-24(120)=1

001.198 GPIOS in3: in3-24(312)=1

001.513 GPIOS out3: out3-24(120)=0

001.513 GPIOS in3: in3-24(312)=0

There are two GPIOS: 120 and 312.

Based on the events, it shall be a "out pin" GPIO, thus number "120".

On aria linux, it is show as "LIBERTY_GPIO_TP_RST" and it is triggered at startup.

(or is it reset screen???)

The led could be "LIBERTY_TP_5V_EN" based on the source code.

Now need to match the GPIO number to addresses...

Thanks to NetRipper we have examples here:

http://htc-linux.org/wiki/index.php?title=Leo/FlashlightTest
[HD Mini Android Development] schlund:
@cardsharing:

look at kernel source here:

arch/arm/mach-msm/gpio_hw.h

this line and following show that they have same GPIO
[HD Mini Android Development] cardsharing:
ok thanks. What about mov	r0, #0x00000030 @ ARM6 control reg
[HD Mini Android Development] schlund:
ok i checked this out,

INIT of MSM7XXXA is absolutely the right choice!
[HD Mini Android Development] schlund:
@robin:

i think you are on right way,

i tested your fix, phone freezes after gogogo
[HD Mini Android Development] cardsharing:
Hi Schlund, please specify why this not to be

"addlist irqs p2v(0xc0000000) 0x100 32 0\n"

"addlist irqs p2v(0xc00000a0) 0 32 0\n"

sorry if i am........
[HD Mini Android Development] cardsharing:
Anyone know how to replace hd mini spl with hboot, this will be good start to boot linux
[HD Mini Android Development] tzacapaca:
as i can see spl is required to boot Android also(someone correct me if i am wrong)

p.s.is the haRET porting development cancelled,so you are trying other way?:eek:

So what is an SPL anyway? What does it do?

The SPL, or Second Program Loader, is essentially the Android bootloader. It's job is more than just loading the Android OS - it also offers several other boot options, including Recovery mode, Fastboot, and HBOOT modes, and ultimately it's the SPL that allows manipulation of the flash nand on your device. Part of the SPL's job is to ensure that the data flashed to the device is correct. Most of the current shipping SPLs (apart from the "Perfect SPL's) let us flash a complete ROM image, but don't let us flash a recovery rom or boot image as it checks the verification signature. Haykuro has modified the SPL's available to remove this check and this is what the Engineering SPL's available offer. As the SPL is so crucial to the handset though, you have to be very careful when flashing it as if it's updated incorrectly then you may be incapable of restoring it without specialised hardware and knowledge. You essentially have a very expensive brick
[HD Mini Android Development] johnsk:
what?

porting haret is haRET porting is cancelled?

i think this is the only way to start android on mini.

or is it a mistake from me?
[HD Mini Android Development] tzacapaca:
it was a question!

android can run from nand too :),but we need devs who knows how to do this..:(
[HD Mini Android Development] cardsharing:
No, it is not canceled :) hehe im trying some stuf but have not knownledge how to do it. I see sspl on screen in boot mode from cotula and want in this way to try something, but have not any spl source to be able to look in it and to find from it how to edit original spl. Hboot is in htc legend and will be good to make this in hd mini, but how huhh?

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000 12 00 00 EA 30 2E 34 33 2E 30 30 30 31 00 00 00 ...ę0.43.0001...
00000010 37 32 32 37 20 53 50 4C 00 00 00 00 00 00 A0 E1 7227 SPL......*á
00000020 53 48 49 50 00 00 00 00 00 00 A0 E1 00 00 A0 E1 SHIP......*á..*á
00000030 48 42 4F 4F 54 2D 37 32 32 37 00 00 00 00 A0 E1 HBOOT-7227....*á
00000040 64 69 72 74 79 2D 37 31 35 66 64 30 36 31 00 00 dirty-715fd061..
[HD Mini Android Development] schlund:
hey come on guys,

they are always the same questions we've already discussed about lot of times before.. its just a few pages ago, where it was explained what SPL does.

how do you come to the conclusion that working on haret is cancelled ? because no one answered this thread for 12hours ?

as you see, we are no skilled developers, we will only go on the "safe" way to get android run, and this will be haret and NOT hspl!
[HD Mini Android Development] cardsharing:
http://xdaforums.com/showpost.php?p=10806498&postcount=542 thanks
[HD Mini Android Development] tzacapaca:
sorry if that bothered you
[HD Mini Android Development] johnsk:
I apologize for my mistake, I got that wrong.

okay but now again btt.

I understand this correctly?

you try to take the android from the htc legend?

i thought the best is this one from the aria?

and is it risky for the device to boot android with haret?

i thought haret don't touch the spl,

when the spl keep untouched i think there is no risk or?

this are just a couple of ideas in the hopes are to bring bissl new wind in the matter:)

sry for my english :)

greets
[HD Mini Android Development] schlund:
sorry for my aggression. It is very disappointing to read those things instead of useful posts to the main problems.

But back to topic now:

i found a very useful document about Android Board BringUp on MSM7627, which should be almost the same.

Finally on site "37" theres a Memory Map of Virtual (of Android!!!) and Physical Memory, which should be very interesting!

http://wenku.baidu.com/view/fd7cf929647d27284b7351f3.html
[HD Mini Android Development] _Madmatt:
Okay, but do we already know that HaRET works well?? First I'd like an answer to my question about the HaRET log. I have no exception, does this mean my HaRET (wich is actually Robins one that I use) works? :)
[HD Mini Android Development] cardsharing:
@Schlund thanks and sorry if i disapoint you! Please, why you do not answer me
[HD Mini Android Development] NetRipper:
No exceptions are no guarantee for HaRET to work or not. It just means it gets to a certain spot; just before the trampoline when the interrupts are disabled. Once the interrupts are disabled it's not possible to continue logging. Logging requires writing to the disk, writing to the disk requires interrupts to be working. Attempting to write to disk after interrupts are disabled, might cause Windows CE to re-enable interrupts which would mess up bootloading whatever HaRET loads (i.e. a kernel). This is why you need something like a led or vibrator on GPIO that you can enable. GPIO's don't need interrupts, which makes it easy to debug after interrupts are disabled.

In short, the GO GO GO is the last message by HaRET. After that it's fingers crossed.

By the way, what is the >>> STEP 1 <<< 2/3/4 there? Is that custom logging that has been added? If that happens after interrupts are disabled, it should be removed (as explained above).
[HD Mini Android Development] _Madmatt:
Well, I don't know where the >> STEP x << comes from. On my screen when HaRET starts, I can see it going till >> STEP 5 << but it is only logged to >> STEP 4 <<. But if what you say is right, then indeed that STEP-thing should be removed, but how? Here is my default.txt with commands to HaRET. Can you find what's the problem? :D

set ramsize 0x14000000
set ramaddr 0x10000000
set mtype 3299
set cmdline ""
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] -r0bin-:
guys, the "step x" are debug messages I put to track the haret crash.

you'd better use the one I attached on my last post (based on MSM7xxxA init + all the other patch so far)

I aslo have to test the code to trigger the vibrator, will let you know once i validate it.

if you find it too let me know ;)
[HD Mini Android Development] _Madmatt:
Oops, I'm sorry, I tought I had newest version. If you managed to trigger Vibrator or LED, I'll take a look again.:D
[HD Mini Android Development] -r0bin-:
great schlund!

you will find the document in clear here:

http://avs234.net/docs/cpu/qualcomm/

edit: unfortunatelly its not specific to MSM7227, but it gives an idea how it works
[HD Mini Android Development] NetRipper:
I checked with someone that has some more arm asm knowledge and learned that "1f" means "1 label forward". So it is actually dynamic, instead of a hardcoded memory offset. This is also used in f.e. 'cpuFlushCache'.

Also please remove the extra Output(..) or Screen(..) lines you added from your code. It will make HaRET fail to boot Linux, if it the kernel would work in the first place.

By the way. If you guys use the zImage of the HTC Legend, but set the "mtype" (in default.txt) to that of hdmini, it will not boot. You need to set the mtype of legend as well to have any chance (or add hdmini mtype support to the kernel). The very first thing the kernel does, is validate the mtype it receives from HaRET. When the mtype does not much the mtype that the kernel was built for, the kernel "exits". The Legend mtype seems to be 2242.
[HD Mini Android Development] -r0bin-:
really? ok so there is no bug in the patch.

yep, need to get the vibrator thing in place :)

we use the mtype of MACH_LIBERTY. We use the kernel source from HTC Aria.

The mtype we have is coherent with the mytpe we got from the kernel. it shall be ok on this point.

The issue we got here is, sometimes we have unexpected exception, sometimes device hangs, sometimes it goes back to winCE immediately.

this probably sounds like we did not reached the MMU disabling code part.
[HD Mini Android Development] -r0bin-:
regarding the GPIO of the vibrator, the spy i have is this:

HaRET(28)# watch GPIOS 3
Beginning memory tracing.
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)
000.000 GPIOS out0=00000000:
000.000 GPIOS out1=00008202: out1-1=1 out1-9=1 out1-15=1
000.000 GPIOS out2=00060000: out2-17=1 out2-18=1
000.000 GPIOS out3=00100100: out3-8=1 out3-20=1
000.000 GPIOS out4=00000000:
000.000 GPIOS 92f00850=7804
000.000 GPIOS in0=00000000:
000.000 GPIOS in1=07b09a3e: in1-1=1 in1-2=1 in1-3=1 in1-4=1 in1-5=1 in1-9=1 in1-11=1 in1-12=1 in1-15=1 in1-20=1 in1-21=1 in1-23=1 in1-24=1in1-25=1 in1-26=1
000.000 GPIOS in2=01f61f46: in2-1=1 in2-2=1 in2-6=1 in2-8=1 in2-9=1 in2-10=1 in2-11=1 in2-12=1 in2-17=1 in2-18=1 in2-20=1 in2-21=1 in2-22=1in2-23=1 in2-24=1
000.000 GPIOS in3=041c8102: in3-1=1 in3-8=1 in3-15=1 in3-18=1 in3-19=1 in3-20=1 in3-26=1
000.000 GPIOS in4=00000000:
000.000 GPIOS 92f00844=7824
000.000 GPIOS out0_en=00008000: out0-15=1
000.000 GPIOS out1_en=000fc282: out1_en-1=1 out1_en-7=1 out1_en-9=1 out1_en-14=1 out1_en-15=1 out1_en-16=1 out1_en-17=1 out1_en-18=1 out1_en-19=1
000.000 GPIOS out2_en=01fe2009: out2_en-0=1 out2_en-3=1 out2_en-13=1 out2_en-17=1 out2_en-18=1 out2_en-19=1 out2_en-20=1 out2_en-21=1 out2_en-22=1 out2_en-23=1 out2_en-24=1
000.000 GPIOS out3_en=03fa410d: out3_en-0=1 out3_en-2=1 out3_en-3=1 out3_en-8=1 out3_en-14=1 out3_en-17=1 out3_en-19=1 out3_en-20=1 out3_en-21=1out3_en-22=1 out3_en-23=1 out3_en-24=1 out3_en-25=1
000.000 GPIOS out4_en=000001f8: out4_en-3=1 out4_en-4=1 out4_en-5=1 out4_en-6=1 out4_en-7=1 out4_en-8=1
000.000 GPIOS 92f00854=3ffffd7
002.118 GPIOS in2: in2-21(277)=0 in2-22(278)=0
002.125 GPIOS in2: in2-21(277)=1 in2-22(278)=1
002.418 GPIOS out3: out3-24(120)=1
002.418 GPIOS in3: in3-24(312)=1
002.733 GPIOS out3: out3-24(120)=0
002.733 GPIOS in3: in3-24(312)=0

thus it seems to be the GPIO banks 3, in and out, at bit 24 (=0x800000)

I grab the virtual address from the log above.

the code i have is this:

@ enable vibro
ldr r8, =0x92f0083c @ bank3_in (virtual) (v@92f0083c(p@a920083c))
ldr r9, =0x92f00808 @ bank3_out (virtual) (v@92f00808(p@a9200808))
bic r10, r8, #0x800000 @ clear bit 24 if set
str r10, [r9, #0] @ store with cleared bit (bright reset)
orr r10, r8, #0x800000 @ bit 24 for vibro
str r10, [r9, #0] @ store in out

it doesnt work :( am i doing something wrong?
[HD Mini Android Development] schlund:
i think it should be like this

@ enable vibro
ldr r8, =0x92f0083c @ bank3_in (virtual) (v@92f0083c(p@a920083c))
ldr r9, =0x92f00808 @ bank3_out (virtual) (v@92f00808(p@a9200808))
bic r10, r8, #0x1000000 @ clear bit 24 if set
str r10, [r9, #0] @ store with cleared bit (bright reset)
orr r10, r8, #0x1000000 @ bit 24 for vibro
str r10, [r9, #0] @ store in out

EDIT:

OK tested, this works on virtual Adress! (and doesnt turn off hehe)

i think you see your mistake:

Bit 24 -> Dez: 2^24 -> Hex 0x1000000

theres also mistake in "leo" samples: 0x200000 is Bit 21 not 22, you see that in GPIO-Map :)

Great research! could you also get LED? :)
[HD Mini Android Development] cardsharing:
Thanks, it work.

v92f00000-93000000 -> pa9200000-a9300000 100000
[HD Mini Android Development] derefas:
so , haret 100% work?
[HD Mini Android Development] johnsk:
no i don't think so,

it was a step4step succes,

i think there are any more step's...

but i think this guys here know what they do...
[HD Mini Android Development] schlund:
i added Photon page to htc-linux.org wiki.

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

i also added some content to prevent users from asking the same questions again and again.

please feel free to add/change.

maybe we could add this to first post of this thread
[HD Mini Android Development] _Madmatt:
Looks good! But I read that we use a "recommended" kernel for Linux, so in fact we don't know sure if it works well? If it doesn't could that be the problem that HaRET throws an unhandled exception? (Sorry if this is a stupid question)
[HD Mini Android Development] schlund:
just as said, first target is to be sure that HaRET works! THEN we can do research on the kernel!
[HD Mini Android Development] _Madmatt:
Yeah, I know, but how can we know sure that HaRET works? Maybe it just stops now because of the kernel? I'm a beginner so maybe this hypothese is wrong.

I of course understand that the steps are in this order :)

- Get HaRET working

- Make kernel working

- Port Android
[HD Mini Android Development] schlund:
this is why we discover the GPIOS to debug HaRET !
[HD Mini Android Development] _Madmatt:
Yeah, I knew, but how can we know for sure that everything WORKS, but that it just arrives to that point of the code? ;) Okay, in most cases, if you arrive to the point of code, everything above it has been executed, true. But what about try-catch clauses? Or don't we use this in HaRET?
[HD Mini Android Development] schlund:
for example: if we try to vibrate via virtual address after disabling mmu and we succeed, we know mmu isnt disabled !
[HD Mini Android Development] _Madmatt:
Yeah, I know how GPIO works, but if you try something with a virtual adress when MMU is disabled, won't it enable itself? Maybe we should use physical adresses for GPIO ;)
[HD Mini Android Development] schlund:
no! and no
[HD Mini Android Development] cardsharing:
Maybe we buy gratia hehehe
[HD Mini Android Development] schlund:
So, did some debugging:

HaRET is not working :)

The problem must be here:

@ Code is running at a vm address that is the same as its
@ physical address. Now disable the MMU.
mrc	p15, 0, r0, c1, c0, 0
bic	r0, r0, #5	@ MMU & Dcache off
bic	r0, r0, #0x1000 @ Icache off
mcr	p15, 0, r0, c1, c0, 0	@ disable the MMU & caches

Putting Vibro in front of this code WORKS,

after this code nothing works (v and p address) means it crashes here.

OK, compared changed bits etc as show on http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0211h/Babgdhif.html

And my result is: this code is OK.

Problem is, as shown on Table 3.46 in the link above, we earn an unhandled exception by accessing the Control Register in "user read or write mode"

WE DO NOT HAVE PRIVILEGED RIGHTS !!

EDIT: I don't understand.. HaRET says everythings ok.

KMode ist set from 0 to 1.

"CPU is ARM ARM arch 6 stepping 5 running in system mode", system mode is maximum privileged mode...
[HD Mini Android Development] -r0bin-:
good job schlund for the vibro code :)

warning: if you put the vibro code before the asm label "1:" then it will never vibrate:

the jump call will go to the next label, as mentionned by NetRipper.

There is a simple check we can do for that:

retrieve the PSR register to check the user mode.

see the function below (in haret src, asm code also available)

uint mode = cpuGetPSR() & 0x1f;
if (mode != 0x1f)
Output(C_ERROR "Haret is not running in 'system' mode. Major"
" functionality will not be present.");

CPR registers explained here

we want to be sure we're in "system" mode (11111 = 0x1f)

maybe it could be a good idea to run this code just before the call of the trampoline, in linboot.cpp ?

PS: sorry I cannot test this right now, I'm travelling out of my country for one week and dont have access to my linux :-(
[HD Mini Android Development] Ailir:
Hi all. I read last pages and... I can't understand nothing there, but as I can see, we have an progress with launching android.

I have a lot of free time durring working day and can help with testing... If you explain what and how I should do :).