ZipitForge - Trac

crazymonkeypants: the point in fooling around with blob is to understand what goes on in the early setup, then to port apex to the z2. blob is way past its' "use by date"

[16:39:36]

No kidding

[16:39:48]

There needs to be a toxic mold warning on it

[16:40:23]

working on it tends to rot the brain.

[16:40:50]

apex vs. das U-boot?

[16:41:43]

apex, ubloat is much too "feature-rich"

[16:42:48]

That's bad because?

[16:44:46]

blob fits in less than 64k, the smallest version of uboot I'e seen takes 256k, apex can be smaller than blob in most cases, it will depend on how much of the xlli stuff can be lifted from blob.

[16:46:47]

<g1powermac_PB>

GPSFan: is there a way to extract the initramfs from the zipits kernel?

[16:47:39]

it's still early in the porting work, so things may change. to use uboot, (assuming a 256k size) one would have to re-do the partitioning scheme on the z2. not impossible, though if the results were worth it.

[16:48:05]

I copy

[16:48:22]

g1: you can pull the binaries from it and re-create the rest by hand

[16:48:25]

What I just did

[16:48:37]

g1powermac: yeah use a version of the z2shell.sh and copy it to the sd card after bootup

[16:48:42]

<g1powermac_PB>

k

[16:48:49]

there are some discrepancies in the device nodes between what the debian MAKEDEV produced and what's on the device

[16:49:04]

but I'm hoping they're not fatal

[16:50:20]

GPS: I'd be happier if the pxa270 had some sort of rescue bootloader built in

[16:51:13]

crazymonkeypants: so would we all, that's why jtag is neccessary for those wanting to risk brickage.

[16:52:18]

I assume you're using the internal SRAM while you're playing with apex?

[16:54:23]

(I don't understand why blob doesn't use it...)

[16:56:34]

crazymonkeypants: will be when I get somore rount tuits. blob does use sdram, the flash code runs, sets up gpio's sdram, etc. copies the second stage from flash to sdram and jumps to it.

[16:58:20]

<g1powermac_PB>

GPSFan: have you ever tried to replace the kernel in flash using blob?

[16:59:08]

g1powermac: no

[17:00:32]

iirc tomw did and bricked his z2. I believe he didn't have an /rfs set up correctly and that was befor jtag was possible.

[17:01:00]

<g1powermac_PB>

no, he tried replacing the kernel from the sd card

[17:01:13]

<g1powermac_PB>

we didn't have the serial port at that time, so no blob access

[17:03:04]

SRAM, not SDRAM

[17:03:17]

The '270 has 256KiB of internal SRAM

[17:03:28]

crazymonkeypants: sorry, I didn't realize that.

[17:03:46]

The whole thing would be much simpler if the first thing it did was copy itself to SRAM

[17:03:52]

There wouldn't be this whole trampoline rubbish

[17:04:10]

One thing; I'm not seeing the vector remap anywhere in the intel docs

[17:04:28]

I'm not a big xscale guy; is this something the processor supports by default?

[17:04:56]

crazymonkeypants: I'll have to look at that in the pxa manual. that woulld really be a help, I wonder if the pxa270 apex port uses it.

[17:06:03]

It appears to have no config; there's just 256k at 0x5cxxxxxx

[17:20:55]

Or am I mis-understanding how vectors work on the arm? I assumed they all lived at a physical address

[17:21:16]

Are they fetched from 0+vector in the supervisor virtual space?

[17:29:06]

*sigh*

[17:29:12]

Apex lies

[17:29:20]

"Easy to build. It depends only on shell utilities and GCC."

[17:29:41]

Er, no. It depdends on the entire linux kernel config infrastructure, meaning it can only be built on Linux

[17:30:56]

<g1powermac_PB>

hmm

[17:41:13]

And Darwin's gcc -print-file-name does not work the way the check script expects

[17:43:19]

But there we go

[17:43:23]

Much less drama than blob

[18:10:32]

<g1powermac_apl>

so which mtdblock is the initramfs?

[18:12:36]

g1powermac: it's in with the kernel in mtd1

[18:12:49]

<g1powermac_apl>

k

[18:13:23]

<g1powermac_apl>

hmm, how do you mount it?

[18:13:37]

dev: size erasesize name

[18:13:37]

mtd0: 00010000 00002000 "Bootloader"

[18:13:37]

mtd1: 00230000 00010000 "Kernel"

[18:13:37]

mtd2: 005c0000 00010000 "Filesystem"

[18:13:51]

<g1powermac_apl>

ahh

[18:13:57]

you don't, it's mounted by the kernel during bootup

[18:14:01]

<g1powermac_apl>

doh, should've remembered that

[18:14:04]

<g1powermac_apl>

hmm

[18:14:10]

Kernel: arch/arm/boot/zImage is ready

[18:14:21]

<g1powermac_apl>

GPSFan, so how do you access it?

[18:17:50]

<g1powermac_apl>

is it the actual rootfs?

[18:18:43]

When you say "how do you access it", what do you mean?

[18:18:55]

blob puts it in physical memory at 0xa0500000

[18:19:07]

I've been trying to work out how it locates it inside the mtd

[18:19:42]

<g1powermac_apl>

I want to make a copy of the initramfs to stick it inside my new kernel

[18:19:55]

You need to make one yourself

[18:20:28]

Or work out where it is in mtd1

[18:20:32]

sec, let me poke at it

[18:20:36]

<g1powermac_apl>

thats the idea

[18:20:50]

<g1powermac_apl>

I made one myself, but I want to use the one that the zipit people made

[18:21:47]

Well, the head of partition 1 looks like the head of a regular zImage

[18:22:21]

<g1powermac_apl>

oops, umm, don't cat /dev/mtd1

[18:22:24]

<g1powermac_apl>

;-)

[18:23:20]

So, I think it's already inside the zImage

[18:24:17]

<g1powermac_apl>

it is

[18:24:29]

It's a compressed cpio archive, as best I can tell

[18:24:57]

g1powermac: I forget how I did it (if I ever did) I think you can bootup using the sd card and everyting that is ther that wasn't in the sd card is what's in /rfs

[18:25:59]

Yes; if you go to / with the SD card mounted, you get the initramfs with the card mounted on /mnt/sd0

[18:26:03]

That's how I built mine

[18:33:44]

Looks like the gzipped image starts 0x343c into the mtd

[18:33:55]

Look for 1f 8b (gzip signature)

[18:38:18]

cut that off with dd and then go looking again

[18:38:44]

(gzip signature actually 1f 8b 08 00)

[18:39:55]

And there we go

[18:40:18]

# file bar

[18:40:18]

bar: ASCII cpio archive (SVR4 with no CRC)

[18:40:56]

<g1powermac_apl>

how are you looking at it?

[18:41:09]

I use 'hexdump -C | less'

[18:43:51]

<g1powermac_apl>

i wonder if there is some script that will extract it

[18:44:35]

It's not hard 8)

[18:45:43]

dd if=partition_1 of=foo.gz bs=1 skip=13372

[18:45:56]

gunzip foo.gz

[18:46:11]

dd if=foo of=bar.gz bs=16 skip=5174

[18:46:22]

gunzip bar.gz

[18:46:32]

mv bar zipit_initramfs.cpio

[18:46:49]

That worked for me; if you have a different firmware version the magic numbers will be different

[18:46:53]

But you can find them easily

[18:47:03]

<g1powermac_apl>

cool, thanks

[18:47:16]

<g1powermac_apl>

heh, I used cat to get it off the flash and onto the sd card

[18:47:22]

You will know if the numbers are wrong; the gunzip phase will fail

[18:47:53]

There's dd on there as well; a little more trustworthy

[18:52:43]

Er

[18:52:49]

Be careful unpacking the archive

[18:53:15]

In particular, if you do it as root, make sure you specify --no-absolute-filenames

[18:53:23]

Otherwise you will toast your current system

[18:58:14]

<g1powermac_apl>

hmm, the final gunzip whines about trailing garbage

[19:10:33]

harmless

[19:11:21]

<g1powermac_apl>

whats your cpio command, btw?

[19:16:00]

<g1powermac_apl>

ahh, I got it

[19:16:52]

<g1powermac_apl>

lets see if this kernel boots with this initramfs

[19:17:22]

<g1powermac_apl>

interesting

[19:17:34]

<g1powermac_apl>

this zImage is smaller than what is on the z2

[19:24:19]

<g1powermac_apl>

bwahaha

[19:24:22]

<g1powermac_apl>

it booted

[19:24:25]

<g1powermac_apl>

interesting

[19:25:21]

<g1powermac_apl>

hmm, dmesg is missing though

[19:25:35]

Sadly, xdownload is borked for me

[19:25:50]

And I'm not sure I'm prepared to wait for my pokeloader to push over an image that big

[19:26:32]

It's not there on the default initrd

[19:26:43]

does busybox support it?

[19:26:49]

<g1powermac_apl>

ahh, I must have added it somehow

[19:27:28]

[, [[, ash, cat, chmod, cp, dd, df, dos2unix, du, echo, fuser, halt, head, ifconfig, init, insmod,

[19:27:28]

ln, ls, lsmod, md5sum, mkdir, mknod, modprobe, mount, mv, nslookup, ping, poweroff, ps, pwd, reboot,

[19:27:28]

rm, rmdir, rmmod, route, sh, sha1sum, sleep, sync, tail, tar, test, tftp, udhcpc, umount, uname, unix2dos,

[19:27:28]

vi

[19:27:39]

<g1powermac_apl>

oh, actually, I think its from GPSFan's initramfs

[19:28:55]

g1powermac: yeah, my busybox is chock full of goodies.

[19:30:35]

crazymonkeypants: my firmware must be a different version, I get a crc and length error when I try to unzip the trimmed mtd1. my 1f 8b 08 00 is at 0x343c

[19:31:13]

<g1powermac_apl>

GPSFan, so, this extracted initramfs from the zipit itself combined with my custom kernel does boot as if nothing changed except the kernel :-)

[19:31:32]

g1powermac: good deal...

[19:31:54]

gpsfan: I believe we'd already established that the other day with my unit and its "Zcovery" binary...

[19:32:20]

I was only suggesting it as an approach for g1 here who was having trouble finding the signatures

[19:33:10]

crazymonkeypants: yes we did, I found the gzip signature at 0x343c and thought that I could trim the binary from mtd1 and then gunzip it.

[19:33:22]

er, no, wait; the first one was at 0x343c here too

[19:33:37]

You should be able to; check the first four bytes of your trim result

[19:36:08]

<g1powermac_apl>

well, in any case, we now have a way to replace the kernel

[19:36:27]

<g1powermac_apl>

technically I should be able to replace the mtd1 with the zImage I created from the sd card

[19:36:32]

it is the gzip signature but gzip doesn't like it

[19:37:16]

very odd, but it really doesn't matter 'cause I can boot my kernel with it's own initramfs just fine.

[19:37:27]

Weird indeed

[19:38:14]

<g1powermac_apl>

GPSFan, have you updated your zipit by any chance?

[19:38:24]

<g1powermac_apl>

my zipit is running the stock software it came with

[19:38:30]

<g1powermac_apl>

I haven't let it update itself

[19:38:47]

it's at v1.1.3 but IIRC the mtd image I have may be from before the update.

[19:38:56]

<g1powermac_apl>

ahh

[19:39:08]

Oof. OE setup is nontrivial

[19:39:25]

hard to say, but I really don't care right now.

[19:39:56]

crazymonkeypants: beware OE has a very steep learning curve. I have never gotten a useable z2 userland build out of it.

[19:40:36]

I've given up on OE more times than I care to count.

[19:40:42]

8(

[19:40:46]

Any alternative suggestions?

[19:41:07]

<g1powermac_apl>

crazymonkeypants, buildroot

[19:41:23]

I use buildroot successfully for many things, but it doesn't have the package selection that OE does

[19:41:58]

tomw seems to have a good understanding of OE, but he is still wrestling with his new house.

[19:42:34]

bbl

[19:42:37]

Ok, thanks for the pointers as always

[19:42:51]

I'll probably keep tinkering with Apex, since I really need a usable bootloader.

[20:20:43]

<g1powermac_PB>

hmm

[20:20:55]

<g1powermac_PB>

I just thought of something

[20:21:19]

<g1powermac_PB>

my zImage is almost .2mb smaller than what is on the z2

[20:21:42]

<g1powermac_PB>

and the only thing changed is the addition of the usb gadget stuff, yet its smaller

[20:21:52]

crazymonkeypants: I think that's a good direction to go, have you seen the apex prot for the toshiba e740? here is a link; http://git.mnementh.co.uk/cgi-bin/gitweb.cgi?p=apex.git;a=summary

[20:22:07]

<g1powermac_PB>

makes me wonder if that zipit patch isn't containing everything that is in the z2 kernel now

[20:22:08]

s/prot/port

[20:22:31]

g1powermac: it could be compiler related, better optimization.

[20:22:38]

<g1powermac_PB>

oh thats true

[20:22:48]

<g1powermac_PB>

your buildroot is using a newer compiler

[20:23:51]

<g1powermac_PB>

still quite a bit of space though

[20:24:59]

gcc 4.1.2

[20:26:12]

<g1powermac_PB>

though the tools on my dev machine used for compressing the image could be newer and work better

[20:26:16]

<g1powermac_PB>

as well

[20:26:25]

maybe the .configure that's in the patch isn't really the one that matches your kernel. that's what happened with blob, what I built doesn't run and doesn't match their binary.

[20:26:55]

<g1powermac_PB>

yea

[20:27:10]

<g1powermac_PB>

wonder if there's a way we could tell

[20:27:18]

<g1powermac_PB>

obviously the kernel does boot

[20:27:34]

<g1powermac_PB>

I should try to boot to the z2app with the new kernel

[20:29:26]

I haven't looked at the e740

[20:29:37]

I'm working off the mx31 port, as I am somewhat familar with that board

[21:50:28]

<g1powermac_apl>

alright, the zipit app seems to start fine even under the new kernel

[21:51:05]

<g1powermac_apl>

have any of you played with the zipit app using the serial port?

[22:34:49]

I have

[22:34:57]

There's not a whole lot to see

[22:35:10]

It *is* watching what you type

[22:35:20]

But all I get back are the ascii codes for what I send it

[22:35:31]

<g1powermac_apl>

yea

[22:36:21]

btw, I don't know if anyone realised

[22:36:33]

but the audio input goes to the wolfson

[22:37:28]

I'm not sure if it's on one of the extra four pins of the headphone jack, but the expansion connector audio in is definitely routed over there

[22:37:45]

<g1powermac_apl>

crazymonkeypants, yes it is

[22:38:16]

Have you found a headset that has the appropriately funky connector?

[22:38:27]

<g1powermac_apl>

nope

[22:38:29]

<g1powermac_apl>

time for bed

[22:38:33]

<g1powermac_apl>

gnight all

[23:03:45]

crazymonkeypants: yes this Wolfson has a mic input, the one they used on the z1 didn't. If you look at the fcc docs for the z2, they shows a headset with microphone. Which never shipped with the z2.

[23:04:20]

the z1 had a similar funky earphone connector, but in that case the extra pins didn't go anywhere that made any sense.

[23:13:41]

<Foxx>

the nintendo DS has a similar headset hookup

[23:14:54]

I have the Apex port sketched out and sort of building

[23:15:32]

GPS: how do I fetch the git reference you pasted earlier?

[23:16:40]

<Foxx>

didnt the older iPods have a similar 'remote hookup'?

[23:16:59]

<Foxx>

it had a 4 pin 'blade' connector next to the heaphone jack

[23:18:24]

ERROR: src/arch-arm/lib/lib.a(div64.o) uses FPA instructions, whereas apex does not

[23:19:28]

Ah, that's a consequence of building xscale but no -msoft-float

[23:27:19]

Anyone speak Kconfig? How do I add compiler flags?

[23:31:26]

crazymonkeypants: somehow I got it, I might have uese git, but I have a tarball of the may14 version (which is the latest IIRC) I can dcc it to you to save you some agravation, being a MAC user git it probably as cryptic as linux stuf gets.

[23:32:42]

Thanks

[23:32:52]

np,

[23:32:59]

I can probably set git up; I'm just a bit tired of recursive depdencies

[23:34:09]

I haven't done anything much with that code, I did put together a couple of z2 specific files based on what was there for the e740, but never built anything.

[23:34:39]

real life has a way of adjusting priorities. ;>)

[23:34:39]

Right now if I can work out how to get -msoft-float into the global cflags I should have something that links

[23:34:55]

Then I can start poking at it with objdump to see what I've got

[23:36:36]

I remembered hot I got the code, go to this page: http://git.mnementh.co.uk/cgi-bin/gitweb.cgi?p=apex.git;a=shortlog;h=refs/heads/e740_irda

[23:36:53]

then click snapshot at the end of the first line.

[23:39:26]

Hmm, thanks

[23:39:36]

I can probably piggyback on the e740 stuff

[23:40:53]

Still no workaround for the float stuff

[23:41:43]

cul, gotta get some zzzz's

IRC Logs

03. 08 2008

2008 8
Mo	Tu	We	Th	Fr	Sa	So
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30	31
◀	◂				▸	▶

2008 8
Mo	Tu	We	Th	Fr	Sa	So
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30	31
◀	◂				▸	▶

2008 8
Mo	Tu	We	Th	Fr	Sa	So
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30	31
◀	◂				▸	▶