Re: Linux kernel startup (s3c24xx)

Hi All,

I am using buildroot to create a cpio image. Following is the output.

Starting kernel ...

Uncompressing Linux............................................................................................
Linux version 2.6.24.4-default (tiju <at> tiju) (gcc version 4.2.1) #57 Tue Apr 15 08:58:38 IST 2008
CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=00007177
Machine: DPB2440
Warning: bad configuration page, trying to continue
Memory policy: ECC disabled, Data cache writeback
CPU S3C2440A (id 0x32440001)
S3C244X: core 405.000 MHz, memory 101.250 MHz, peripheral 50.625 MHz
S3C24XX Clocks, (c) 2004 Simtec Electronics
CLOCK: Slow mode (1.500 MHz), fast, MPLL on, UPLL on
CPU0: D VIVT write-back cache
CPU0: I cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets
CPU0: D cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets
Built 1 zonelists in Zone order, mobility grouping off.  Total pages: 4064
Kernel command line: root=/dev/ram0 rw console=ttySAC0,115200
irq: clearing pending ext status 00000b00
irq: clearing subpending status 00000003
irq: clearing subpending status 00000002
PID hash table entries: 64 (order: 6, 256 bytes)
timer tcon=00500000, tcnt a4ca, tcfg 00000200,00000000, usec 00001e57
Console: colour dummy device 80x30
console [ttySAC0] enabled
Dentry cache hash table entries: 2048 (order: 1, 8192 bytes)
Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)

Linux kernel startup

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Register now and save $200. Hurry, offer ends at 11:59 p.m., 
Monday, April 7! Use priority code J8TLD2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

_______________________________________________
U-Boot-Users mailing list
U-Boot-Users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Linux kernel startup

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Register now and save $200. Hurry, offer ends at 11:59 p.m., 
Monday, April 7! Use priority code J8TLD2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

_______________________________________________
U-Boot-Users mailing list
U-Boot-Users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

s3c2440 -- serial_init

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

_______________________________________________
U-Boot-Users mailing list
U-Boot-Users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

How to patch u-boot?

Hi

Could 
someone 
help 
me 
out 
with 
patching 
the 
u-boot.
I 
downloaded 
the 
source 
code 
of 
u-boot-1.1.6 
and 
untared 
it. 
Then 
I 
do 
a 
$cd 
u-boot-1.1.6
$svn 
co 
http://svn.openmoko.org/trunk/src/target/u-boot/patches/
$patch 
<patches/boot-menu.patch
patching 
file 
bootmenu.c
can't 
find 
file 
to 
patch 
at 
input 
line 
154
Perhaps 
you 
should 
have 
used 
the 
-p 
or 
--strip 
option?
The 
text 
leading 
up 
to 
this 
was:
--------------------------
|Index: 
u-boot/board/neo1973/gta01/gta01.c
|===================================================================
|--- 
u-boot.orig/board/neo1973/gta01/gta01.c
|+++ 
u-boot/board/neo1973/gta01/gta01.c
--------------------------
File 
to 
patch:

This 
is 
what 
comes....
Is 
this 
the 
way 
to 
do 
it? 
If 
not 
please 
help 
me 
with 
the 
steps 
to 
be 
followed.

Thankyou
Tiju 
Jacob

      Forgot the famous last words? Access your message archive online at http://in.messenger.yahoo.com/webmessengerpromo.php

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

How to patch u-boot?

Hi

Could someone help me out with patching the u-boot.
I downloaded the source code of u-boot-1.1.6 and untared it. Then I do a 
$cd u-boot-1.1.6
$svn co http://svn.openmoko.org/trunk/src/target/u-boot/patches/
$patch <patches/boot-menu.patch
patching file bootmenu.c
can't find file to patch at input line 154
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|Index: u-boot/board/neo1973/gta01/gta01.c
|===================================================================
|--- u-boot.orig/board/neo1973/gta01/gta01.c
|+++ u-boot/board/neo1973/gta01/gta01.c
--------------------------
File to patch:

This is what comes....
Is this the way to do it? If not please help me with the steps to be followed.

Thankyou
Tiju Jacob

      Now you can chat without downloading messenger. Go to http://in.messenger.yahoo.com/webmessengerpromo.php

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

booting from NOR (GTA02)

As of r3819, this works now. I still need to make it ignore the
environment (which it fetches from NAND, and which may contain nasty
surprises), but that's less urgent.

However, there's one subtle detail that's quite interesting: we can
check the boot mode (i.e., whether NOR or NAND) by reading the OM[1:0]
bits through the BWSCON register.

As it turns out, BWSCON reflects the _current_ status of OM[1:0],
i.e., after doing a "reset halt" in OpenOCD while holding down AUX,
and then releasing AUX (after all, it's kinda inconvenient to type
when one hand it busy with the GTA02), BWSCON will happily read all
zero.

Even better, this also changes whether we see Steppingstone (followed
by zeroes) or NOR at address 0. u-boot copies itself away quickly
enough (and, in fact, we could just jump to the permanently visible
copy of the NOR at 0x18000000 if we're in a great hurry), so this
doesn't cause any real issues.

But it surely made debugging this little feature a lot more exciting
than I expected ... :)

- Werner

Reminder: phasing out the openmoko-uboot mailing list

Dear subscribers of "openmoko-uboot",

this is a reminder that the openmoko-uboot list is about to disappear
this weekend.

If you haven't done so yet, please subscribe to
openmoko-kernel@..., which will host future discussion
about kernel and u-boot.

The u-boot mailing list archive will remain accessible also after
the removal of the list, and it stays at its current place, i.e.,
http://lists.openmoko.org/pipermail/openmoko-uboot/

There's no need to unsubscribe from openmoko-uboot - all
subscriptions will be dropped without further notice.

- Werner

kernel and u-boot build scripts

One of OpenMoko's arcane rituals most veiled by obscurity is certainly
the building of the kernel and u-boot. Our "official" procedure involves
a hefty amount of OpenEmbedded, and some people even use OE as their
main mechanism for building kernels or u-boot.

For those who need quicker turn-around times, also an ancient toolchain
(OABI) is making the rounds. This toolchain has served us well for over
a year, but it's hopelessly out of sync with the rest of our environment.

A little while ago, John Lee has released an experimental EABI toolchain,
complete with a little build environment for applications:
http://wiki.openmoko.org/wiki/Toolchain

This toolchain is built by our current OpenEmbedded process, so we have
a reasonably good idea what's in there 

I've now written a few shell scripts that use this toolchain to build
u-boot and the kernel. They're in
http://svn.openmoko.org/trunk/src/target/u-boot/scripts/ and
http://svn.openmoko.org/trunk/src/target/kernel/scripts/ respectively.

They're mainly intended as examples for one's own customized build
scripts or copy & paste templates, but they also work if used "as is".
One thing to bear in mind is that, instead of using the setup-env
script from the toolchain, these script only expect the PATH to be
updated, as described in u-boot/scripts/README.

I've used these scripts in the past few days, and they seem to work
well enough.

One item that I'm a bit uncertain about, and where I'd appreciate the
help of git experts, is how to pin the upstream u-boot revision in git.
The idea is that one can set GIT_HEAD to the version one likes to use,
and things will roll back or forward as desired, similar to "svn update
-r REVISION".

What I'm doing is "git pull" to update the repository, and then
"git reset --hard $GIT_HEAD" to bring the checked-out tree to the
desired revision.

The use of "git checkout" has been suggested to me, but after I do
this, it seems impossible to "git pull" afterwards. So I'm not sure
this is the right direction. (For simplicity, we can assume that there
are no local changes at all in the tree, i.e., that we've done a
"quilt pop -a".)

- Werner

copy and paste vs. u-boot's usbtty

By the way, I'm not sure if this is common knowledge yet: u-boot's
usbtty has the well-known properly that it gets confused if data
arrives too rapidly. This means that the use of copy and paste is
quite limited. (To a lesser extent, the same problem also exists
for the serial port.)

Since fixing this seems to be tricky, I've implemented a different
solution a while ago: my "neocon" serial console utility supports
rate limiting of the data sent to the device.

Example:

% neocon -t 30 /dev/ttyACM{0,1}

Communicates over whichever device usbtty gets assigned to, limiting
input to about 300 bps, like in the good old days 

"neocon" lives in http://svn.openmoko.org/developers/werner/neocon/

- Werner

unexpected boot parameter line truncation

A little "heads up": with mtdparts growing considerably for GTA02,
we may run into truncation of the boot parameter line. This is a
silent failure. One quick measure to reduce the size of the boot
parameter line is to remove "regular_boot", which we don't use
anyway.

(Background: "regular_boot" was meant to indicate that the system
was not booted from the "factory reset" boot menu option. We never
implemented any logic that did anything special for the factory
reset, such as erase the touch screen calibration data, so this
can be safely removed.)

- Werner