| [06:50:54] |
*** |
g1powermac_PB has joined #zipit |
| [06:54:19] |
*** |
marex has joined #zipit |
| [07:21:02] |
*** |
g1powermac has joined #zipit |
| [07:38:45] |
*** |
GPSFan has joined #zipit |
| [07:45:55] |
<marex> |
I've got one more idea about armboot |
| [07:46:08] |
<marex> |
I dunno, but the contents of RAM it jumps to might be damaged |
| [07:46:42] |
<marex> |
I'd try reserving a bootmem node in arch/arm/mm/mmu.c and putting some small code to that place and modding armboot to jump there |
| [07:46:46] |
<marex> |
I think I'll give it a go |
| [07:54:28] |
<GPSFan> |
marex: howdy, I've been real busy lately, sorry I haven't had time to work on armboot stuff. I also had disconnected my jtag interface about the time I stopped working on blob (june 2008) |
| [07:56:17] |
<marex> |
hm ... ok |
| [07:56:30] |
<marex> |
I'll look into it once I have time, but exams are comming |
| [07:56:41] |
<marex> |
I have two tests and one exam (from assembly language) next week |
| [07:57:39] |
<GPSFan> |
cul, gotta run... |
| [08:00:12] |
<marex> |
ok |
| [08:02:33] |
*** |
g1powermac_PB has quit IRC |
| [08:17:52] |
*** |
rkdavis has joined #zipit |
| [08:51:36] |
<GPSFan> |
marex: back for a bit. in the armboot code I saw, in the asm section just before it jumped to the kernel. there was some code that printed out "BOOT:" since your kernel didn't do that I assume that either you took the code out or didn't change the uart reg's to refer to STUART. |
| [08:57:43] |
<marex> |
GPSFan, I probably removed it as it was not necessary |
| [08:58:30] |
<marex> |
GPSFan, give that kernel a go in qemu and you'll see |
| [08:59:20] |
<GPSFan> |
k, maybe that code could be grafted to the kernel startup. |
| [09:24:37] |
<marex> |
I think it's not booting what it should |
| [09:24:46] |
<marex> |
ie. it jumps to some other location |
| [09:25:21] |
<marex> |
but I dunno why it works in qemu, something funny's going on there |
| [09:44:18] |
<GPSFan> |
marex: does it matter that there is no physical memory at 0xe0000000 which is where it wants to put the initrd? I didn't specify one when I tried armboot, but it printed out: ARMBoot: kernel PA: a2852000 |
| [09:44:18] |
<GPSFan> |
initrd PA:e0000000 |
| [09:44:58] |
<GPSFan> |
I can read & write memory on my z2 at 0xa2852000, but not at 0xe0000000 |
| [09:45:42] |
<marex> |
that shouldn't matter |
| [09:46:04] |
<marex> |
in qemu, it booted even without initrd |
| [09:47:49] |
<GPSFan> |
marex: what changes did you make to armboot for the z2 kernel you built, and where did you put the code? I'd like to poke at this a bit today, it's raining, and not much is going on that I have to deal with (yet). |
| [09:48:30] |
<marex> |
there's no need to change anything for Z2 basically |
| [09:48:52] |
<marex> |
I just made some local changes when trying to make it work, but without success |
| [09:49:13] |
<GPSFan> |
k, so where does it go in the kernel tree? |
| [10:10:52] |
*** |
rkdavis has quit IRC |
| [10:16:28] |
<GPSFan> |
marex: well here's another interesting thing, there is only 32Mbytes of system ram and that starts at 0xa0000000 and goes to 0xa1ffffff, so being able to read & write at 0xa2852000 must be some sort of wrap around. |
| [10:22:34] |
<marex> |
GPSFan, arch/arm/{armboot, Kconfig, Makefile} |
| [10:22:50] |
<marex> |
GPSFan, that's indeed weird, I need to investigate that |
| [10:35:24] |
*** |
rkdavis has joined #zipit |
| [12:07:04] |
<GPSFan> |
marex: I got an armboot enabled kernel compiling, it boots normally. I left in the "BOOT:" in the asm code and when I sent the commands to /proc/armboot I got the same stuff printed out as your kernel, with the addition of the BOOT: at the end. I then stuffed that code into head.S at in __INIT right after ENTRY(stext). when I booted that kernel I got a boot: as the first print out of the kernel. I then tried to boot that kernel from armboot. I got the BOOT: f |
| [12:07:04] |
<GPSFan> |
rom armboot, but no boot: from the kernel. |
| [12:07:45] |
<marex> |
yes, I see |
| [12:08:39] |
<marex> |
you can try http://marex.hackndev.com/kern.S |
| [12:09:40] |
*** |
g1powermac_PB has joined #zipit |
| [12:10:26] |
<marex> |
GPSFan, compile with arm-...-as -o kern.o kern.S ; arm-...-objcopy -O binary kern.o kern.bin |
| [12:10:39] |
<marex> |
kern.bin should be a few bytes ... 24 or so |
| [12:11:57] |
<GPSFan> |
yes sure, give me a few min's |
| [13:34:38] |
<GPSFan> |
marex: ok, this is what I did, I compiled the kern.S and just booted it from blob, and it shut off the led. I booted my armboot kernel then armbooted kern.bin and it shut off the led. I then took those few lines of code and put them into head.S at __INIT right after ENTRY(stext). I then armbooted that kernel and it did NOT shut off the led. |
| [13:35:01] |
<GPSFan> |
marex: ok, this is what I did, I compiled the kern.S and just booted it from blob, and it shut off the led. I booted my armboot kernel then armbooted kern.bin and it shut off the led. I then took those few lines of code and put them into head.S at __INIT right after ENTRY(stext). I then armbooted that kernel and it did NOT shut off the led. |
| [13:36:47] |
<marex> |
it armbooted that ? |
| [13:37:01] |
<marex> |
that kern.bin ? |
| [13:37:09] |
<marex> |
it didn't work on my side |
| [13:37:10] |
<marex> |
damn |
| [13:38:05] |
<GPSFan> |
well, it didn't boot because of the loop. |
| [13:38:15] |
<marex> |
well it locked up, didn't it ? |
| [13:38:20] |
<marex> |
but the led was switched |
| [13:39:11] |
<GPSFan> |
yes, when armbooted by itself, just those 24 bytes of kern.bin --> echo "k /mnt/kern.bin" > /proc/armboot |
| [13:40:21] |
<GPSFan> |
then echo "b" > /proc/armboot... it then printed out all the messages from armboot then the led went off. |
| [13:41:16] |
<GPSFan> |
so it looks to me that armboot wants to jump to the begining of the kernel. as in very first byte. |
| [13:44:31] |
<GPSFan> |
which works for kern.bin when loaded by blob or by armboot. but doesn't when armboot loads a real kernel (with or without test code at the __INIT) |
| [13:46:47] |
<marex> |
that's not true |
| [13:47:13] |
<marex> |
there has to be some issue with either the loading algorithm (which is assembling the kernel in memory) or with the kernel itself |
| [13:47:47] |
<marex> |
you see, the kernel has a decompressor sticked before itself which does the relocation, decompression etc. |
| [13:47:59] |
<marex> |
GPSFan, was the kernel PA the same with kern.bin ? |
| [14:01:31] |
<GPSFan> |
yes the PA was the same. |
| [14:04:22] |
<marex> |
hrm |
| [14:05:31] |
<GPSFan> |
marex: you of course are correct. I forgot that head.S is executed after the decompression step. I should have put the test code in front of the decompressor. |
| [14:08:48] |
<GPSFan> |
which is in head.S.... just a different head.S ;>) |
| [14:09:45] |
*** |
rkdavis has quit IRC |
| [14:10:09] |
<marex> |
GPSFan, so ... does it work now ? |
| [14:14:19] |
<GPSFan> |
marex: sorry it takes me so long to try stuff, I'm multitasking several things at once, as well as the fact that I am not a programmer and have to figure out many things that come naturally to other folks. ;>) |
| [14:14:54] |
<marex> |
GPSFan, no problem ;) |
| [14:33:16] |
<GPSFan> |
with the test code ahead of the decompressor in head.S, the light does go out upon armbooting it. |
| [15:04:21] |
<GPSFan> |
marex: with the test code after the decompressor in head.S, the light does not go out upon armbooting it. |
| [15:04:51] |
<marex> |
so you have serial console ? |
| [15:05:11] |
<marex> |
maybe the kernel is damaged ... darn :T |
| [15:06:02] |
<GPSFan> |
I'll try putting something in the decompressor in misc.c and see what happens. |
| [15:06:17] |
<GPSFan> |
yes I have a serial console |
| [15:06:24] |
<marex> |
rather than that, if you have serial console, add "c console=ttyS0" |
| [15:06:41] |
<GPSFan> |
ttyS2 |
| [15:06:45] |
<GPSFan> |
STUART |
| [15:06:46] |
<marex> |
you should be able to see the decomp running |
| [15:06:56] |
<marex> |
errr ... ok |
| [15:07:10] |
<marex> |
qemu uses ttyS0 ... hmm |
| [15:07:28] |
<marex> |
and I think the kernel does use it too |
| [15:09:22] |
<marex> |
ok, it doesn't have anything like that there ... you were right then |
| [15:09:59] |
<marex> |
right ... console=ttyS2,115200 |
| [15:12:48] |
<GPSFan> |
that is what my CONFIG_CMDLINE is set to in .config. and I don't see the "Uncompressing kernel message that's done by the putstr macro in misc.c |
| [15:13:40] |
<GPSFan> |
even on a good kernel booted from blob. |
| [15:19:58] |
<marex> |
you dont? hmm |
| [15:20:37] |
<marex> |
actually, it might be redirected to FFUART |
| [15:22:51] |
<marex> |
though FFUART is generally used for FIR |
| [15:23:25] |
<marex> |
the serial port should be inited by blob too ... hm hm hm ... |
| [15:29:20] |
<GPSFan> |
blob prints out "Next step is to start the kernel" then on the next line the kernel prints: "Linux version 2.6.21.1 (kenm@kenm-desktop) (gcc version 4.1.2) #7 Sat May 2 09:50:06 MDT 2009" |
| [15:30:42] |
<marex> |
the decomp should write to the serial port |
| [15:30:54] |
<marex> |
lemme check |
| [15:31:09] |
<marex> |
(btw. sorry, Im multitasking between boring stuff to learn and this) |
| [15:32:29] |
<marex> |
actually ... it might not write anything |
| [15:32:50] |
<marex> |
I was pretty confident it did ... hmm :) |
| [15:33:38] |
<marex> |
I probably mistaken it with ll_char_wr.S |
| [15:44:42] |
*** |
lukev has joined #zipit |
| [15:49:20] |
*** |
lukev has quit IRC |
| [15:49:46] |
<GPSFan> |
marex: ah, debug-macro.S is sending the serial stuff out FFUART. I'll tweak it for STUART and see what I get... |
| [15:50:08] |
<marex> |
:-) |
| [16:08:24] |
<marex> |
GPSFan, how's it going ? |
| [16:11:34] |
<GPSFan> |
well, that didn't produce any output either, but I did try booting the kernel with the "fixed" debug-macro.S from blob. it didn' t produce any output either. but... it also had the test code after the decompressor, and the led went out. ie. it returned from decmpressing the kernel, whereas booted from armboot it didn;t return from decompressing the kernel. |
| [16:13:52] |
<marex> |
well if it was booted from armboot, the RAM would only contain terrible mess |
| [16:13:59] |
<marex> |
there won't be anywhere to return to ;-) |
| [16:14:27] |
<marex> |
it'd return to blob because of machine restart I assume |
| [16:20:44] |
<GPSFan> |
in head.S there is a "bl decompress_kernel" which branches to the decompression code in misc.c when that code returns it should go back to head.S at about line 249. |
| [16:21:27] |
<marex> |
GPSFan, bl = branch with link |
| [16:21:53] |
<marex> |
bl something @ executes code at label "something" |
| [16:22:11] |
<GPSFan> |
I have the ledoff test code right after that bl decompress_kernel line. it gets executed when booted from blob and not when booted from armboot. |
| [16:22:18] |
<marex> |
something: code code code and at the end is most likely mov pc, lr |
| [16:22:26] |
<marex> |
which returns you exactly PAST THE BL instruction |
| [16:22:51] |
<marex> |
GPSFan, ok, does it get executed if you put it before that "bl" ? |
| [16:22:57] |
<GPSFan> |
yes |
| [16:23:07] |
<marex> |
then decomp is borken for you |
| [16:23:19] |
<marex> |
(OR the kernel is not consistent - you get CRC error) |
| [16:24:30] |
<GPSFan> |
the identical binary runs from blob. |
| [16:24:52] |
<GPSFan> |
or the kernel as copied into RAM is corrupted. |
| [16:24:59] |
<marex> |
that's what I mean |
| [16:25:06] |
<GPSFan> |
;>) |
| [16:25:06] |
<marex> |
armboot probably corrupts the kernel |
| [16:25:15] |
<GPSFan> |
bad armboot..... |
| [16:25:22] |
<marex> |
I have one idea |
| [16:25:37] |
<marex> |
reserve 2 megs at the end of the RAM and make armboot just copy the kernel image there |
| [16:26:06] |
<marex> |
reserve 2 megs in arch/arm/mm/mmu.c |
| [16:26:28] |
<marex> |
about line 640 |
| [16:26:48] |
<marex> |
(use the same reserve_bootmem_node() call ) |
| [16:27:44] |
<marex> |
reserve_bootmem_node(pgdat, 0xa2000000 - "2 megs", 0x"2 megs") ; |
| [16:29:18] |
<marex> |
ok, then stick at armboot.c line 84 something like |
| [16:30:41] |
<GPSFan> |
there is still the issue of 0xa2000000 not having any real memory. |
| [16:30:59] |
<marex> |
for (i = 0; i < size; i++) *(char *)virt_to_phys(0xa2000000 - "2 megs" + i) = kerneladdr[i]; asm volatile("ldr r0, =0xa2000000 - "2 megs" ; mov pc, r0"); |
| [16:31:25] |
<marex> |
GPSFan, yea, replace all 0xa2000000 - "2 megs" with the real value |
| [16:31:41] |
<marex> |
0xa1e00000 if Im right |
| [16:32:57] |
<GPSFan> |
yes, for this I understand (to my surprise) but in the more general case of armboot reporting that it put the kernel at 0xa2852000 |
| [16:33:55] |
<marex> |
that's indeed weird |
| [16:34:33] |
<marex> |
no it's not |
| [16:34:36] |
<marex> |
ewww |
| [16:34:45] |
<marex> |
see lines 146 - 149 |
| [16:34:51] |
<marex> |
and then line 32 |
| [16:34:58] |
<marex> |
I guess you got the idea |
| [16:35:02] |
<GPSFan> |
of mmu.c |
| [16:35:08] |
<marex> |
it should be phys_to_virt () |
| [16:35:10] |
<marex> |
no, armboot.c |
| [16:35:38] |
<GPSFan> |
ah, |
| [16:36:35] |
<marex> |
it's working properly looking further at the code |
| [16:41:34] |
*** |
g1powermac_PB has quit IRC |
| [17:10:56] |
*** |
rkdavis has joined #zipit |
| [17:54:02] |
<marex> |
f*, I'm depressed again |
| [17:54:47] |
*** |
rkdavis has quit IRC |
| [18:21:01] |
*** |
rkdavis has joined #zipit |
| [18:21:11] |
<marex> |
ok Houston, we have a problem here |
| [18:22:23] |
<marex> |
GPSFan, ok, armboot is broken on palmtx too |
| [18:24:40] |
*** |
rkdavis1 has joined #zipit |
| [18:24:40] |
*** |
rkdavis has quit IRC |
| [18:24:56] |
*** |
rkdavis1 has quit IRC |
| [18:45:49] |
<GPSFan> |
marex: oh really, that's interesting. what platforms does it work on? |
| [18:46:00] |
<marex> |
Farcaller said it worked on T3 |
| [18:46:03] |
<marex> |
palmt3 |
| [18:46:18] |
<GPSFan> |
pxa270? |
| [18:46:33] |
<marex> |
260 |
| [18:46:52] |
<marex> |
the arm core is the same so that's not the issue I think |
| [18:46:56] |
<GPSFan> |
and you said it worked on qemu |
| [18:47:01] |
<marex> |
yes |
| [18:55:17] |
<marex> |
GPSFan, ok, I have armboot working on real HW |
| [18:55:33] |
<marex> |
GPSFan, patch will arrive shortly, ok ? |
| [18:56:31] |
<GPSFan> |
well that was quick, what was your insight? |
| [18:56:44] |
<marex> |
reserve_bootmem_node() helped ;-) |
| [18:57:02] |
<marex> |
I reserved 2 megs of ram, copied kernel there and booted from there |
| [18:57:24] |
<marex> |
so it's time to charge Z and give it a go there |
| [18:57:25] |
<GPSFan> |
where did armboot say it put the kernel? |
| [18:57:35] |
<marex> |
I made it put it into that place |
| [18:57:43] |
<marex> |
into the reserved memory |
| [18:57:59] |
<GPSFan> |
which was where? just under 0xa2000000? |
| [18:58:23] |
<marex> |
you can make whatever holes you want in the memory |
| [18:58:39] |
<marex> |
well ... nearly whatever |
| [19:06:16] |
<marex> |
GPSFan, are you still around ? |
| [19:06:24] |
<GPSFan> |
yep |
| [19:06:36] |
<marex> |
GPSFan, ok, I'm just about to load it into my Z2 |
| [19:07:10] |
<marex> |
GPSFan, btw. can we deploy a new kernel with this as an added feature but without any other changes ? |
| [19:07:38] |
<marex> |
(so I can replace the current kernel in my Z2) |
| [19:09:53] |
<GPSFan> |
we should be able to flash this kernel and it will be compatible with all the modules that come with the z2 from the factory. then it will allow us to load a new kernel from the sd card (or mtd) at will |
| [19:09:55] |
<marex> |
GPSFan, exactly what I want |
| [19:10:22] |
<marex> |
GPSFan, can I leave that to you ? |
| [19:10:37] |
<marex> |
I guess your initramfs won't be as crappy as mine |
| [19:11:25] |
<GPSFan> |
no problem, if I could have your patch to do the memory reservation etc. |
| [19:11:36] |
<marex> |
sure, hang on |
| [19:11:43] |
<marex> |
I'm working on .21 version |
| [19:12:35] |
<GPSFan> |
that's what I've been using today. that will be the target for the re-flash kernel, so it can operate with all the z2 apps etc. |
| [19:14:07] |
<GPSFan> |
I might add a bit to armboot to allow it to pass the correct machine id to the new kernel which should help with pushing things upstream. |
| [19:14:33] |
<marex> |
yea, that'd be simple |
| [19:15:27] |
<GPSFan> |
probably something like echo "i <proper z2 machind id>" > /proc/armboot |
| [19:15:42] |
<marex> |
yea |
| [19:16:34] |
<GPSFan> |
hmm should the default be the proper id or the mainstone id that's used now? |
| [19:16:56] |
<marex> |
the one of running kernel I'd say |
| [19:17:00] |
<marex> |
it doesn't matter anyway |
| [19:17:07] |
<marex> |
armboot won't hit mainline |
| [19:17:49] |
<GPSFan> |
no, but the z2 kernel patches might and kenels built from that should accept the proper id. |
| [19:18:38] |
<GPSFan> |
since those kernels could be flashed to the z2 if someday we get blob to use the correct id. |
| [19:18:39] |
<marex> |
that's indeed very true |
| [19:26:00] |
<marex> |
GPSFan, ok then ... I'll send you the changes |
| [19:26:11] |
<marex> |
I guess you have the stock armboot in your kernel |
| [19:26:17] |
<GPSFan> |
great, thanks for all the work... |
| [19:26:21] |
<GPSFan> |
yes |
| [19:26:36] |
<marex> |
GPSFan, firstly ... I'm doing it for myself ;-) |
| [19:27:22] |
<marex> |
ok ... http://marex.hackndev.com/armboot.c |
| [19:27:36] |
<marex> |
ok ... http://marex.hackndev.com/armboot-asm.S |
| [19:28:00] |
<marex> |
ok ... http://marex.hackndev.com/mmu.c |
| [19:28:10] |
<marex> |
first two go to armboot |
| [19:28:19] |
<marex> |
mmu.c goes to arch/arm/mm/mmu.c |
| [19:29:29] |
<marex> |
GPSFan, give it a go ... I still don't have the flashing card |
| [19:30:38] |
<GPSFan> |
cool, I'll stuff it in and let you know what happens. it's almost dinner, so it may take till your tomorrow. |
| [19:30:50] |
<marex> |
1.30 am here anyway |
| [19:37:16] |
<marex> |
1.30 am here anyway |
| [19:37:21] |
<marex> |
oops |
| [19:40:06] |
<GPSFan> |
probably 1:39 by now |
| [19:44:21] |
*** |
rkdavis has joined #zipit |
| [19:45:33] |
<marex> |
f*! |
| [19:45:39] |
<marex> |
I still cant make it work on the Z2 |
| [19:46:01] |
<marex> |
GPSFan, do you have all the files downloaded already ? |
| [19:46:28] |
<GPSFan> |
when I loaded the kernel, there was no /proc/armboot. I must have hoseed up something. |
| [19:46:51] |
<GPSFan> |
yes, loaded and compiled. |
| [19:47:17] |
<marex> |
ok, I uploaded those working ones from .30-rc3 |
| [19:47:21] |
<marex> |
location is the same |
| [19:48:12] |
<GPSFan> |
ah, that may explain a bit.... |
| [19:48:34] |
<marex> |
GPSFan, no, I uploaded them just now |
| [19:55:28] |
<GPSFan> |
I gotta run off to dinner, I got the files again. I'll try compiling them in a while, good night... |
| [19:55:39] |
<marex> |
hm, gnight |
| [19:55:50] |
<marex> |
I'm going to work on it a little longer |
| [20:02:31] |
<marex> |
GPSFan, I have it running on .21 in QEMU |
| [20:05:03] |
<marex> |
darn really |
| [20:05:03] |
<marex> |
GPSFan, it does work with mainline kernel on PalmTX for me |
| [20:05:03] |
<marex> |
(armboot) |
| [20:05:03] |
<GPSFan> |
just got back, you mean the latest files you posted? I have those, I'll try them. |
| [20:05:03] |
<marex> |
http://marex.hackndev.com/0001-ARMboot.patch |
| [20:05:03] |
<marex> |
it's against .30-rc3 |
| [20:05:03] |
<marex> |
it does work on palmtx (pxa270c5 / 32MB ram) |
| [20:05:03] |
<GPSFan> |
z2 is a pxa270C5 @312Mhz |
| [20:05:03] |
<marex> |
TX too iirc |
| [20:05:03] |
<marex> |
maybe 416, but the silicon is the same anyway |
| [20:05:03] |
<marex> |
GPSFan, please try with the patch and latest kernel |
| [20:05:03] |
<GPSFan> |
the patch & latest kernel will have to wait a bit, my latest kernel git tree is hosed at the moment, and untill I get it building again, the armboot stuff will be on .21 ( hopefully not for long) |
| [20:05:03] |
<marex> |
I cant get it working on .21 :-/ |
| [20:05:03] |
<marex> |
it's either because it's ancient (and/or I missed something there) |
| [20:05:03] |
<marex> |
or dunno why ... it again does work in qemu |
| [20:05:03] |
<GPSFan> |
I know sweetlilmre has got a 2.6.29 kernel with an earlier version of armboot. maybe when he comes back off leave he'll be able to try it out,, then again, maybe I'll get my 2.6.30-rc?? tree unhosed. |
| [20:05:03] |
<marex> |
GPSFan, is he asleep by now or what ? |
| [20:05:03] |
<GPSFan> |
he's been involved at a big project at work lately, and has just was off work last week. I sorta thought we'd see him this weekend. he is in durban SA which is GMT+2 iirc. |
| [20:05:03] |
<GPSFan> |
he also has a band that he plays in, so at times disappears for several days at a time. |
| [20:05:03] |
<marex> |
hehe, I see :-) |
| [20:05:03] |
<marex> |
how old are you guys ? I don't even work yet :-T |
| [20:05:03] |
<GPSFan> |
hahaha, some of us are older than others, and some are outright fossils. |
| [20:05:03] |
<GPSFan> |
I think sweet's the youngest and rkdavis next |
| [20:05:03] |
* |
marex is 21 :-T |
| [20:05:03] |
<marex> |
I might be the youngest then ;-) |
| [20:05:03] |
<GPSFan> |
you are certainly the most recent addition to the channel that has made a real contribution. |
| [20:05:03] |
<marex> |
GPSFan, I'm just going around, fixing thing ;-) |
| [20:05:03] |
<marex> |
generally, all my devices are getting supported in mainline, soon I'll be out of work |
| [20:05:03] |
<marex> |
so I need to get some new device |
| [20:05:03] |
<marex> |
also, just recently I met some guy so I might, but only might get quite nice ARM based SBC to hack on :-) |
| [20:05:03] |
<marex> |
well ... since I have no better things to do during summer break, I'll hack on this stuff |
| [20:05:03] |
<GPSFan> |
I just tried to armboot a kernel from your latest files. (not patch) 2.6.21, I see you added some prints for each block mooved. It did not boot, but the framebuffer went all white. which is different than before, |
| [20:05:03] |
<marex> |
I think I'm missing something on .21 |
| [20:05:03] |
<GPSFan> |
34 blocks moved. |
| [20:05:03] |
<marex> |
well you can comment that out altogether anyway |
| [20:05:03] |
<marex> |
I copy the kernel image into the reserved ram and then boot it |
