NAND Testing - 05-25 Update: New LK, Recovery.img, Kernel Updates through Recovery

[Lmiller1708]

Originally Posted by [ACL]

Cant boot. Moving the imgfs to tinboot put a size restriction on us. Vogue had the same issue so they had to implement lzma compression on the kernel (which we dont have). I can port it over tonight, for now i just need to know if we can shrink down the initrd.gz to around 1.1mb. Harder than i thought. I erased the sbin , modem stuff and logo and still to big. May need to wipe a few symlinks too?

This line is the one causing issues when trying to make the xip with the gz file.

.org XIP_END-0x20000,0xff

The only good news here is that i didnt brick myself with the partition table.

About the symlinks did you see my post above? Not sure we are packing the lmza file correctly... Look at the Vogue's structure. But I'm not sure what we could be doing different?? If you get a min, try to just add the Vogue's lmza and see if that boots, we should have that already.

Originally Posted by [ACL]

This is what im using

cp $DIRECTORY/tools/rhod_payload os.nb.payload
echo Inserting tinboot into payload
cat xip/$1 >> os.nb.payload
echo Creating os.nb portion of nbh
tools/nbmerge < os.nb.payload > OS-new.nb
echo Creating NBH
wine tools/yang.exe -F ruu_signed.NBH -f OS-new.nb -t 0x400 -s 64 -d RHOD****0 -c 11111111 -v Tinboot -l WWE >> $DIRECTORY/tools/log

rm os.nb.payload
rm OS-new.nb

in tinboot change these lines

-.equ XIP_END, 0x0100000
+.equ XIP_END, 0x2ff000

and add to the bottom (i think you alreayd had that)
+ .org XIP_END-0x20000,0xff
+ .incbin "tools/emptyimgfs"

Thanks I will give it a try in a bit... Need to get to work for a bit.

[[ACL]]

Originally Posted by Lmiller1708

About the symlinks did you see my post above? Not sure we are packing the lmza file correctly... Look at the Vogue's structure. But I'm not sure what we could be doing different?? If you get a min, try to just add the Vogue's lmza and see if that boots, we should have that already.


Thanks I will give it a try in a bit... Need to get to work for a bit.

We are packing it just fine its just that our kernel has no code to actually unpack it. Its just missing and needs to be written. Very few kernels have this actually cuz i looked into it. I'll handle this part so dont worry about it. I'm just wondering if we can strip down the gz more just to test until then.

[Lmiller1708]

Originally Posted by [ACL]

We are packing it just fine its just that our kernel has no code to actually unpack it. Its just missing and needs to be written. Very few kernels have this actually cuz i looked into it. I'll handle this part so dont worry about it. I'm just wondering if we can strip down the gz more just to test until then.

Ok sounds good.

What if we change the size of this:
.equ XIP_END, 0x2ff000 = 3.14 MB
.equ XIP_END, 0xXXXXX = xxx MB Or the size of our kernel.

Not too sure what that would do Allow for a larger file?

[[ACL]]

Originally Posted by odz

For testing purposes why don't u remove everything and just leave the kernel with a few modules and instead of booting into a shell.... why don't you just have it print "Success" or something along those lines...

but we can already do that? what will that accomplish ? Whole goal is to make sure android doesnt get erased from nand.

edit: sorry i guess i misunderstood your post.. i mean is that i tried that test already

[[ACL]]

Originally Posted by odz

Ok, so what about making a simple kernel module that will write random stuff to a file and check see if the file(s) are still there after a reboot? At least this way you wont be limited by size and there would be alot less variables when it doesn't work.

you arent making any sense. sorry .. this has nothing to do with the kernel .. or modules .. or anything related to that.

[natemcnutty]

ACL, I was looking into busybox, and I think the version we are using is not only out-dated, it is much larger than the newer versions. There are several arm flavors, and I'm not sure which one we need.

They have armv4eb, armv4l, armv4tl, armv5l, and armv6l. The mips versions are around the same size as the one we are using, but all the arm versions are 1 MB or less

[arrrghhh]

Originally Posted by natemcnutty

ACL, I was looking into busybox, and I think the version we are using is not only out-dated, it is much larger than the newer versions. There are several arm flavors, and I'm not sure which one we need.

They have armv4eb, armv4l, armv4tl, armv5l, and armv6l. The mips versions are around the same size as the one we are using, but all the arm versions are 1 MB or less

I would assume armv6 as that is what our arch supports...

[[ACL]]

Originally Posted by natemcnutty

ACL, I was looking into busybox, and I think the version we are using is not only out-dated, it is much larger than the newer versions. There are several arm flavors, and I'm not sure which one we need.

They have armv4eb, armv4l, armv4tl, armv5l, and armv6l. The mips versions are around the same size as the one we are using, but all the arm versions are 1 MB or less

hmm.. well i know dzo made changes to the source to deploy to his boot env. So that would explain why its larger. Not sure of the specifics tho..

Only thing we really need is the ability to flash_erase to format the partition. aside from that i think any old busybox will work. I would have left the original busybox but how else can we format?

[[ACL]]

Originally Posted by Lmiller1708

Ok sounds good.

What if we change the size of this:
.equ XIP_END, 0x2ff000 = 3.14 MB
.equ XIP_END, 0xXXXXX = xxx MB Or the size of our kernel.

Not too sure what that would do Allow for a larger file?

in theory i guess. I'm just unsure of how much more we can allocate. test it?

[Lmiller1708]

Originally Posted by [ACL]

in theory i guess. I'm just unsure of how much more we can allocate. test it?

Yup I did test it.... but it was still a no go. I haven't been able to make aa good bootable build all day.

I wasn't able to get ahold of JooJoBee666 today so hopefully tomorrow he willbe able to help.