[ Jeffrey Lee Li @ universe ] $ man life

SD Card Boot Mode is one of my favourite features about RPi, which means by inserting a card with an complete bootable os image, it just runs from there, and in the meanwhile any modification you make when interacting with it is written back into the kernel in the card.

This is much unlike other boards for development loaded with NAND or NOR flash, where SD Card is only for rescue for bare-board. This is the key that makes it extremely easy for us to:

1. Try different os images: just dd it and you're done
2. Carry your unique distribution around anywhere you go
3. Backup your sophisitated configurations

A late tip: When you can not interface it, consider adapter.

For example, if you utilize the Micro SDCard from cell phone just as I do with RPi, you can grab a card adapter instead of buying a new real SDCard.

My little bro helped me obtaining power cable with MicroUSB port and HDMI connection line, so that I can see with my eyes how my RPi short for Raspberry Pi operates.

It just works.

Amazing!

Both USB keyboard bought from our administrator and mouse from my notebook work out of box, supporting hot PnP.

Viewing from three seperate means including serial, cli and gui simutaneously gives me a deeper impression of software, firmware and baremetal. It's like seeing the same thing from at different levels or angles.

Oh, I love my Pi.

Connection is half piece. The other one is enabling login console via serial connection, which is disabled by default in earlier image versions for reasonable considerations.

Edit /etc/inittab in SD card's root system and uncomment the T0:23... line.

Raspbian wheezy image has already enabled login console via serial connection. Instead, you should comment the respawn line if you want to serial connection into other usage.

But the reason why I can't log in via serial is another story:

1. There's something wrong in my card hardware which cause it took quite a few miniutes to get into login prompt
2. There's a little difference between win32diskimager and dd that I've got no idea about

When booting I was prompted with:

Debian GNU/Linux wheezy/sid (none) ttyAMA0

(none) login:

It seems that pi is not recognized or detected.

I solved this by changing another card, re-writing the image and things went well, as expected.

I saw in Raspberry Pi's guide manual that it supports communication via serial port.

But there's no standard COM interface on the board.

The answer is UART standing for Universal Asynchronous Receiver/Transmitter, provided via a group of GPIO pins, from which TTL signals can be converted into USB via a small circuit like CP210x, FTDI232 or PL2303.

I choose CP210x that's said to be faster as well as more reliable.

Remarks

1. Pi's RXD pin connects to converter's TXD pin and vice versa, or else nothing happens
2. Appropriate driver is needed for the converter, perhaps manually

I'm exited on receiving my Raspberry Pi bought on Taobao.

Model B ver2.0 with 512M memory.

I found a word appeared in my reading list more and more frequent last year: Raspberry Pi. Recently someone has managed to compile and run golang programs on it.

I was not concerned at first. Then one of my roommates in graduate institute told me that it's yet another development board based on ARM, and I got start to learn about it.

It's supposed to be a educational tool to re-stimulate the students' insterest in system at lower-level but things go a little differently: many geeks love it and have built dozens of fun machines with it.

The more materials I read about it, the more I wanna it.

It's sold out for now. And I can't wait over thirsty.

Fortunately, a colleage of mine brought her board to me for a hand-on test: Mini2440 from FriendlyARM based on S3C2440A with ARM9 processor.

She showed me how to setup, connect and interact with it, patiently, quite a nice girl. Thanks for that.

In the following advantures in the embeded world, I will use Mini2440 unless explicitly stated. Yet the things are not necessarily limited to this model. The criterion is wet your own hands.

I will have to go beyond software and dive into firmware in future. One part out of requirement of the project I'm busy with, yet a larger part, out of my curiousity, not interest here, just curiousity.

I've been thinking about the answer to the question I came up the first time I had the chance to get my hands on the computer: How did it happen?

I mean: it's only a bunch of metals and stones, how can it do what we ask it to? That's in senior high.

Then I went to college, learning about circuits, electronics and programming. I knew a little more than I was before, but far from enough to make a clear explanation.

What's worse? More questions came up. Take this for example:

If source codes are compiled into exectuables with the compiler, what makes the compiler?

Like the chicken-egg-chicken question, I have not got much clue.

Maybe I will have a different view if I dive deep enough.

Anyway, things might appear on my way:

1. Kernel
2. Cross-compiling
3. Driver

Stay tuned.