Zbr's days.
←June→
Sun Mon Tue Wed Thu Fri Sat
          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
←2007→
Months
Jan Feb Mar
Apr May Jun
Jul Aug Sep
Oct Nov Dec

About :: TODO :: Blog :: RSS :: Old blog :: Projects :: GIT :: Gallery :: Notes

Sat, 02 Jun 2007

I've declined to work in Google again.

And now thinking if I'm stupid or not?
And also thinking about how to bribe my budget to get some money to buy a camera and to travel to Cambridge this September to Kernel Summit.

I want to get DSLR camera, although I'm far from being a good photographer, but I like a process of getting shots using DSLR/SLR cameras much more, than with automatic digital cameras. Likely I would start with something simple like Nikon D40 with lens from the kit, later I would add a long-focus lens (like to photo remote objects, mostly industrial buildings).

/devel/other :: Link / Comments (0)

I do not know why, but I do like SuperH asm.

Although I know it only about a week, I like it.

Btw, code below can be optimized a bit, but it was not a main goal.

/devel/sh :: Link / Comments (0)

Problem with broken linux image has been found.

As I posted recently I managed to start kernel booting, but image can not be decrompressed and thus does not bood beyond initial code. I expected problem to be in the code which reads data from compact flash into memory - it uses IPL (BIOS) code to copy data, which is undocumented and likely broken.
Today I started to play with data in RAM and decided to perform a simple checksum of the image I copy and compare it with on-flash image checksum. I got pretty simple checksum - 4-byte xor over whole image using following SuperH asm code:

checksum:
	mov	#18, r1		! number of iterations
	shll16	r1

	mov	r13, r2		! initial address
	mov	#4, r6		! step
	xor	r5, r5		! checksum
l:
	mov.l	@r2+, r4
	xor	r4, r5

	sub	r6, r1

	tst	r1, r1
	bf	l
Then checksum (which resides in r5) was printed into serial console via IPL (BIOS) call:
print_32:
	mov	#8, r6		! max
	mov	#1, r2		! step
	mov	r5, r3		! checksum
	mov	#-4, r10	! bits to shift
pl:
	mov	r3, r0

	and	#0xf, r0
	mov	r0, r11
	
	mova	hex, r0
	mov	r0, r4
	add	r11, r4
	mov	#0, r0
	mov	#1, r5
	trapa	#0x3f

	shad	r10, r3
	sub	r2, r6
	
	tst	r6, r6
	bf	pl
	...
hex:
	.string "0123456789abcdef"
Although it prints reversed hex number, it was enough to find, that after 1^17 bytes read checksum stopped to be changed (because of xor property it means that data was not changed after that limit), and 2^17 was the boundary where checksum was equal to the one, calculated over compact flash image on the host system.
So, my idea about wrong code, which reads data from compact flash into the RAM, is correct, now I need to think (or decipher sh-lilo second stage loader's code) about how to correctly read about one megabyte of data from flash. Main problem is of course LBA/CHS addressing and some unknown feature called 'device number' in comment to the reading code in sh-lilo.
Back to drawing board...

/devel/sh :: Link / Comments (0)