Zbr's days.
August
Sun Mon Tue Wed Thu Fri Sat
         
30
31            
2008
Months
AugSep
Oct Nov Dec

About TODO Blog RSS Old blog Projects Gallery Notes

Wed, 06 Jun 2007

Locking in SuperH.


Shame on me, I did not mention tas.b instruction, which does exactly what is needed for spinlock implementation - it reads a byte, specified in register, then sets a bit in the returned value, and writes it back. If value read is zero, special bit is set. All operations are performed with locked bus, so it is atomic.
I read description for that instruction many times, but failed to translate or understand. But, whatever it was, spilocks are pefectly valid on SH-4 family, so it would be possible to create SMP system, since I even found multiprocessor serial communication in 7750R, which allows to transfer data between multiple CPUs, where each receiver is addressed via unique ID.

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


Tue, 05 Jun 2007

SuperH 7751 (sh-4) limitations.


Main one is full absence of locking instructions (or instructions, which automatically locks memory region access like ppc lwarx/stwcx or lock prefix for x86), which means that any atomic operation must contain irq disable/enable code. Furthermore, it is impossible to create a spinlock, which can serialize parallel execution on several CPUs.
It is possible to workaround the problem using locked PIO access, but that is very slow.
Likely SuperH SMP will only support newer CPU family. SuperH SMP support is scheduled for 2.6.23 timeframe.

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


Sun, 03 Jun 2007

Boot loader source code.


Interested reader can find bootloader code, which resides in MBR and reads kernel from offset of 1 segment using standard SuperH IPL (aka BIOS), in archive.
Size of the image it reads should be less than 1179648 bytes, otherwise you will need to increase that parameter (see comments). One can also change offset from where to read a kernel image. There is also compilation and CF writing script, which is easily understandible.
To write kernel image (with default parameters in bootlaoder) you just need to run following command:

dd if=arch/sh/boot/zImage of=/dev/sdb obs=512 seek=1
where /dev/sdb should be replaced with device node for the compact flash attached to your host system.

Remember, that it does not support anything besides booting (i.e. no partition tables, no command line).

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


I've just booted 2.6.22-rc2 Linux kernel on SuperH 7751R CPU (LANDISK board).


Dmesg:

SH IPL+g version 0.9, Copyright (C) 2000 Free Software Foundation, Inc.

This software comes with ABSOLUTELY NO WARRANTY; for details type `w'.
This is free software, and you are welcome to redistribute it under
certain conditions; type `l' for details.

2002/09/09 Making.  2004/09/08 I-O DATA NSU Update.
266:133:33 on base clock 22.22MHz and SDRAM 4 burst. CF boot.

PCIC initialization done.
MASTER:48bit LBA mode non support
Disk drive detected: LEXAR ATA FLASH V1.00 11014102039199095066 
LBA: 001EBF10
DiskSize: 1031675904Byte
PIO MODE1
Set Transfer Mode result: 50 
> b
Set Transfer Mode result: 50 
Initialize Device Parameters result: 50 
IDLE result: 50 
Starting from MBR
Error
00000000
Jumping to second stage
checksum: 0x4f222fe6 
input_len: 0x0010baf4 
input_data: 0x8c80300c 
Uncompressing Linux... 

insize: 0x00000000 
inptr: 0x00000000 

insize: 0x0010baf4 
inptr: 0x00000001 Ok, booting the kernel.
cၲͥrrjj:ͪͪj"Bjɕ
B:ͥrrJсRչҚҒ
ISHV$&'H.]X_pfn = 0xc000, low = 0xe000
Zone PFN ranges:
  Normal      49152 ->    57344
early_node_map[1] active PFN ranges
    0:    49152 ->    57344
Node 0: mem_map starts at 8c1eb000
I-O DATA DEVICE, INC. "LANDISK Series" support.
Built 1 zonelists.  Total pages: 8128
Kernel command line: console=ttySC1,9600 console=tty0 mem=32M
Setting GDB trap vector to 0x80000100
PID hash table entries: 128 (order: 7, 512 bytes)
Using tmu for system timer
Using 8.333 MHz high precision timer.
Console: colour dummy device 80x25
Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
Memory: 30520k/30520k available (1345k kernel code, 2248k reserved, 438k data, 72k init)
PVR=04050005 CVR=20480000 PRR=00000113
I-cache : n_ways=2 n_sets=256 way_incr=8192
I-cache : entry_mask=0x00001fe0 alias_mask=0x00001000 n_aliases=2
D-cache : n_ways=2 n_sets=512 way_incr=16384
D-cache : entry_mask=0x00003fe0 alias_mask=0x00003000 n_aliases=4
Mount-cache hash table entries: 512
CPU: SH7751R
NET: Registered protocol family 16
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Autoconfig PCI channel 0x8c1bacc0
Scanning bus 00, I/O 0xfe240000:0xfe280000, Mem 0xfd000000:0xfe000000
00:00.0 Class 0200: 10ec:8139 (rev 20)
        I/O at 0xfe240000 [size=0x100]
        Mem at 0xfd000000 [size=0x100]
00:02.0 Class 0c03: 1033:0035 (rev 43)
        Mem at 0xfd001000 [size=0x1000]
00:02.1 Class 0c03: 1033:0035 (rev 43)
        Mem at 0xfd002000 [size=0x1000]
00:02.2 Class 0c03: 1033:00e0 (rev 04)
        Mem at 0xfd003000 [size=0x100]
PCI: Using configuration type 1
Time: SuperH clocksource has been installed.
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 1024 (order: 1, 8192 bytes)
TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
TCP: Hash tables configured (established 1024 bind 1024)
TCP reno registered
gio: driver initialized
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
SuperH SCI(F) driver initialized
sh-sci: ttySC0 at MMIO 0xffe00000 (irq = 25) is a sci
sh-sci: ttySC1 at MMIO 0xffe80000 (irq = 43) is a scif
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: module loaded
8139too Fast Ethernet driver 0.9.28
8139too 0000:00:00.0: This (id 10ec:8139 rev 20) is an enhanced 8139C+ chip
8139too 0000:00:00.0: Use the "8139cp" driver for improved performance and stability.
eth0: RealTek RTL8139 at 0xfd000000, 00:a0:b0:6c:d0:eb, IRQ 5
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ehci_hcd 0000:00:02.2: EHCI Host Controller
ehci_hcd 0000:00:02.2: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:02.2: irq 5, io mem 0xfd003000
ehci_hcd 0000:00:02.2: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 5 ports detected
ohci_hcd 0000:00:02.0: OHCI Host Controller
ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 2
ohci_hcd 0000:00:02.0: irq 7, io mem 0xfd001000
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 3 ports detected
ohci_hcd 0000:00:02.1: OHCI Host Controller
ohci_hcd 0000:00:02.1: new USB bus registered, assigned bus number 3
ohci_hcd 0000:00:02.1: irq 8, io mem 0xfd002000
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
usbcore: registered new interface driver libusual
heartbeat: version 0.1.0 loaded
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
VFS: Cannot open root device "" or unknown-block(0,0)
Please append a correct "root=" boot option; here are the available partitions:
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
I'm now accepting congratulations.

Although Linux is well supported on that board, and actually it was preinstalled there (until OpenBSD developer's hands murdered it on/from compact flash), this is a serious step for me.
It is second non-x86 CPU I managed to start Linux on. First one was ppc32 (AMCC 405 GPr), I ported Linux to our company's own board about two years ago (although initial loader was not written by me too).
So, I only wrote an initial loader in SuperH asm, which resides in CF's MBR, it reads linux image from predefined offset from CF into RAM and jumps there. It does not initialize caches, MMU and other parameters, since it was done by IPL (Initial Program Loader), which resides on NAND flash, and actually board boots from that flash, and only later that code jumps into CF's MBR.
Loader does not even initialize command line, but can perform a checksum of the image, which can be tested against checksum written to the compact flash.

I will play a bit with this board until Grange returns from OpenBSD hackathon. I will try to setup a partition table and filesystem, so that userspace could be started there.
Actually when he will return, I will ask for Xscale board theirs company develop. They run Linux there without serious problems (it is based on ixp425(?)), but Linux in general sucks on that CPU, since it does not have support for scheduling domains (upto 16), which allows to greatly improve rescheduling latency (or they are not turned on, or whatever, I was quite surprised about that news actually). OpenBSD has such support, and there is a patch for Linux 2.6, but it is quite broken (for example shared memory does not work).

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


Sat, 02 Jun 2007

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)


Fri, 01 Jun 2007

Hardcore Linux Kernel debugging.


In this image (500kb) I see a linux kernel, a broken loader and a blonde in a red dress.
So far it is the only way to determine what I put into the RAM and where inflating code fails.

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


Thu, 31 May 2007

I've gotten a first Linux dmesg on SuperH board.


What do you expect? Maybe this one:

Starting from MBR
Jumping to second stage
START
input_len: 0x00 10 ba f6
Uncompressing Linux... 

ran out of input data

 -- System halted
Not that much as you might expect, but it is something.
Above dmesg says that gzipped image provided has size of 0x10baf6 bytes, which is a bit more than a size of a zImage, and it was failed to get all input data. Precise meaning of that error message is hidden in the magic of gzip decompressor lib/inflate.c, which is a next task to solve, likely because of my broken sector reading code (I seriously doubt it is correct) not everything is in the RAM, so validation logic in the compressor fails and above error happens, I will determine that tomorrow, and now I need to run quickly or I will miss the latest bus home.

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


My first SuperH patch has been applied.


It fixed most of the warnings/errors I found during custom config, and is pretty trivial. Patch includes spinlock fixes, read/write lock fixes, SMP build fixes and include mess. Well, word 'fixes' likely is not good enough, but it allows to compile the tree.

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


Tue, 29 May 2007

My small SuperH bootloader.


SH IPL+g version 0.9, Copyright (C) 2000 Free Software Foundation, Inc.

This software comes with ABSOLUTELY NO WARRANTY; for details type `w'.
This is free software, and you are welcome to redistribute it under
certain conditions; type `l' for details.

2002/09/09 Making.  2004/09/08 I-O DATA NSU Update.
266:133:33 on base clock 22.22MHz and SDRAM 4 burst. CF boot.

PCIC initialization done.
MASTER:48bit LBA mode non support
Disk drive detected: LEXAR ATA FLASH V1.00 11014102039199095066 
LBA: 001EBF10
DiskSize: 1031675904Byte
PIO MODE1
Set Transfer Mode result: 50 
> b
Set Transfer Mode result: 50 
Initialize Device Parameters result: 50 
IDLE result: 50 
Starting from MBR
SECOND LOADER
Bootloader code is pretty simple - it reads predefined number of sectors (currently only one) from predefined sector number into memory and jumps there for execution.
In the example above, first bootloader resides in MBR and is limited to be 512 bytes only, so it reads into memory data from flash using IPL calls via traps from second sector and jumps to that memory. Second application just prints a string into serial console using IPL calls.

here is exerpt of the reading code for example:
read_sector:
	mov	#2, r0			! READ SECTORS
	mov	r13, r6			! destination address
	mov	#1, r5			! looks like source address (source sector number)
	mov	#0, r4			! device number (?)
	mov	#1, r7			! number of sectors
	trapa	#0x3f

	tst	r0, r0
	bt	second_loader

	! Error
	mova	message_err, r0
	mov	r0, r4
	mov	#6, r5
	mov	#0, r0			! Serial Output
	trapa	#0x3f

second_loader:
	mov	#6, r0			! Cache "on"
	mov	#0, r4
	trapa	#0x3f

	mov	r13, r0
	jmp	@r0
	nop
So, code it pretty simple, but it does work.
Next task is to read the whole kernel into mem and jump there. Stay tuned.

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


Mon, 28 May 2007

Sector reading code.


Ok, I've written a code which resides in MBR and reads a sector into the RAM and jumps there, but it only works if I read the same zero sector - I get recursive call of the same .start routine, which prints "Starting from MBR" to the serial console, but if I change source address, system freezes. Likely this is because of wrong sector->LBA translation (I need second or third sector, but I must provide an LBA address), at least if I blindly use 2 for the third sector, it reads something different than third sector. SuperH LILO source I have use some tricky asm to convert from one system to another, which I do not yet understand, and it also uses some strange constants (likely hardcoded address of the second stage loader), so it is not very useful source of information.
Thinking...

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


I know kung-fu or how to write your own bootlaoder.


I never did that before, so it is completely new task for me.
My testing system is SuperH board, which already has initial bootloader, which jumps into MBR of the compact flash for execution. I found LILO port for SuperH CPU, but it does not work (and all documentation is in japanese, and google can not translate that page), which required very old LILO versions, since recent ones (22 and higher) just write x86 boot sector into MBR no matter what you ask it to do (i.e. what boot.b is being used). So obvious step from my point of view is to write own bootloader.
"How is it supposed to work?" - I asked myself and found an answer - it will be pretty small stuff without several stages like in LILO or GRUB, my bootloader will just read fixed size Linux kernel image from fixed offset into memory and jump into it, it is quite simple task since the whole initialization and helper code is already written and stored on the NAND flash in IPL (Initial Program Loader).
My code, which starts from MBR and prints greeting message into serial port for that board is very simple (not including initialization of the base registers):

	mova	message, r0
	mov	r0, r4
	mov	#17, r5
	mov	#0, r0
	trapa	#0x3f
SuperH asm is a bit fun sometimes compared to x86 and ppc (small) bits I know.
It is so simple because of IPL-SH code running from the NAND flash (Initial Program Loader), which handles exceptions (trapa traps an execption). Read sector calls (very similar to x86 BIOS ones) are handled exacltly the same way in LILO port.
I will start with reading and running simple code from Compact Flash, and then will move tothe real kernel.

Because of this hacks I have not moved to climbing area today, which is quite a bit of crap, but I could not resist...

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


My first boot on SuperH CPU.


Serial console output:

SH IPL+g version 0.9, Copyright (C) 2000 Free Software Foundation, Inc.

This software comes with ABSOLUTELY NO WARRANTY; for details type `w'.
This is free software, and you are welcome to redistribute it under
certain conditions; type `l' for details.

2002/09/09 Making.  2004/09/08 I-O DATA NSU Update.
266:133:33 on base clock 22.22MHz and SDRAM 4 burst. CF boot.

PCIC initialization done.
MASTER:48bit LBA mode non support
Disk drive detected: LEXAR ATA FLASH V1.00 11014102039199095066 
LBA: 001EBF10
DiskSize: 1031675904Byte
PIO MODE1
Set Transfer Mode result: 50 
> b
Set Transfer Mode result: 50 
Initialize Device Parameters result: 50 
IDLE result: 50 
I'm booting from MBR!
Check the last line.
Actually it is not a Linux kernel, it is not LILO, it just a code from first stage of the LILO loader slightly hacked and moved into MBR sector of the Compact flash. Initial loader (everything above the last line) is something from NAND flash soldered to the board and likely flashed on the factory.
I'm currently studing why LILO does not work (actually it does not even write MBR record, so I needed to flash it by hand using dd) and how it is supposed to work (bootloaders were always some kind of a magic for me).

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


Sun, 27 May 2007

Linux SuperH SMP support.


I do not know how it can ever be compiled:

...
arch/sh/kernel/smp.c:182: undefined reference to `__smp_call_function'
...

$ grep __smp_call_function -r include/asm-sh* arch/sh* | egrep -v "Binary|~"
grep: warning: include/asm-sh/mach: recursive directory loop

arch/sh/kernel/smp.c:void __smp_call_function(unsigned int cpu);
arch/sh/kernel/smp.c:                   __smp_call_function(i);
Argh, I've found it - every platform includes CONFIG_BROKEN_ON_SMP=y config option.
SuperH 64 does not support SMP too. It just does not compile, and old broken code was added before 2.6.12. So, if I would have SMP board, I would try to add support, otherwise no. I can not even test it.

I've also dropped power management support from my build, since although sh-4 7751R supports it, code for generic power management only works with hp6xx boards, since it uses private register definitions for that board. 7751R does not have some bits in registers and others are named differently, so, no power management so far.

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


Thu, 24 May 2007

A very small progress of SuperH booting today.


I've compiled RedBoot and about to compile SuperH Linux kernel, but since I do not have Compact Flash reader I can not reflash an image, so I've stopped for now.
Tomorrow I will get a flash reader and continue, likely (unfortunately) it will not be that hard to start a linux kernel on that board, since it is well supported.

Update: SuperH kernel for Hitachi SuperH SH7751R CPU can not be compiled with SMP support. This CPU can not be put into SMP system, but it is not a reason to fail building, isn't it? There is a default config for landisk board in Linux kernel, but it is not interesting to use it, so I'm playing with own set of options.
Update2: SuperH really lacks SMP support. Check this atomic increment instruction:

static inline void atomic_add(int i, atomic_t *v)
{
	unsigned long flags;

	local_irq_save(flags);
	*(long *)v += i;
	local_irq_restore(flags);
}
And never ever use read/write locks, on SuperH it ends up with following:
static inline void __raw_read_lock(raw_rwlock_t *rw)
{
	__raw_spin_lock(&rw->lock);
	atomic_inc(&rw->counter);
	__raw_spin_unlock(&rw->lock);
}
But nevertheless I continue to try to build SMP kernel, let's see where this will end up.

Update3: SMP/locks somehow compile, but there is a problem with power management compilation - all modern SuperH CPUs support power management and there are even header files for each CPU family, but power management code uses private constants which are only defined for SuperH-3 family, while 7751 is SH-4 system, so I need to read CPU power management datasheet and probably change some bits to continue... Default config for landisk does not turn power management on.

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


OpenBSD firmware on landisk SuperH board.


SH IPL+g version 0.9, Copyright (C) 2000 Free Software Foundation, Inc.

This software comes with ABSOLUTELY NO WARRANTY; for details type `w'.
This is free software, and you are welcome to redistribute it under
certain conditions; type `l' for details.

2002/09/09 Making.  2004/09/08 I-O DATA NSU Update.
266:133:33 on base clock 22.22MHz and SDRAM 4 burst. CF boot.

PCIC initialization done.
MASTER:48bit LBA mode non support
Disk drive detected: LEXAR ATA FLASH V1.00 11014102039199095066 
LBA: 001EBF10
DiskSize: 1031675904Byte
PIO MODE1
Set Transfer Mode result: 50 
> b
Set Transfer Mode result: 50 
Initialize Device Parameters result: 50 
IDLE result: 50 

OpenBSD MBR

OpenBSD/landisk Primary Bootstrap
>> OpenBSD/landisk BOOT 0.99
boot> 
booting cf:/bsd: 2690340+264524 [72+128848+115558]=0x30d35c
[ using 244972 bytes of bsd ELF symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
        The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2006 OpenBSD. All rights reserved.  http://www.OpenBSD.org

OpenBSD 4.0-current (GENERIC) #9: Thu Nov  9 14:49:28 MST 2006
    root@landisk.openbsd.org:/sys/arch/landisk/compile/GENERIC
I-O DATA USL-5P
real mem = 67108864 (65536K)
avail mem = 58761216 (57384K)
using 844 buffers containing 3457024 bytes (3376K) of memory
mainbus0 (root)
cpu0 at mainbus0: HITACHI SH4 266.666 MHz PCLOCK 33.333 MHz
cpu0: 8KB/32B direct-mapped Instruction cache.
cpu0: 16KB/32B direct-mapped Data cache.
cpu0: P0, U0, P3 write-through; P1 write-through
cpu0: full-associative 4 ITLB, 64 UTLB entries
cpu0: multiple virtual storage mode, SQ access: kernel, wired 61
shb0 at mainbus0
scif0 at shb0
scif0: console
rsclock0 at shb0: RS5C313 real time clock
shpcic0 at mainbus0: HITACHI SH7751R
pci0 at shpcic0
re0 at pci0 dev 0 function 0 "Realtek 8139" rev 0x20: irq 5, address 00:a0:b0:6c:d0:eb
rlphy0 at re0 phy 0: RTL internal PHY
ohci0 at pci0 dev 2 function 0 "NEC USB" rev 0x43: irq 7, version 1.0
usb0 at ohci0: USB revision 1.0
uhub0 at usb0
uhub0: NEC OHCI root hub, rev 1.00/1.00, addr 1
uhub0: 3 ports with 3 removable, self powered
ohci1 at pci0 dev 2 function 1 "NEC USB" rev 0x43: irq 8, version 1.0
usb1 at ohci1: USB revision 1.0
uhub1 at usb1
uhub1: NEC OHCI root hub, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
ehci0 at pci0 dev 2 function 2 "NEC USB" rev 0x04: irq 5
usb2 at ehci0: USB revision 2.0
uhub2 at usb2
uhub2: NEC EHCI root hub, rev 2.00/1.00, addr 1
uhub2: 5 ports with 5 removable, self powered
obio0 at mainbus0
wdc0 at obio0 port 0x14000000-0x1400000f irq 10
wd0 at wdc0 channel 0 drive 0: 
wd0: 16-sector PIO, LBA, 983MB, 2014992 sectors
wd0(wdc0:0:0): using BIOS timings
boot device: 
rootdev=0x1000 rrootdev=0x1000 rawdev=0x1002
WARNING: / was not properly unmounted
Automatic boot in progress: starting file system checks.
/dev/rwd0a: 7631 files, 139253 used, 355342 free (54 frags, 44411 blocks, 0.0% fragmentation)
/dev/rwd0a: MARKING FILE SYSTEM CLEAN
setting tty flags
starting network
DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 1
DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 1
DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 2
DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 2
DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 2
DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 2
DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 2
DHCPOFFER from 192.168.0.1
DHCPOFFER from 192.168.0.1
DHCPOFFER already seen.
DHCPREQUEST on re0 to 255.255.255.255 port 67
DHCPREQUEST on re0 to 255.255.255.255 port 67
DHCPREQUEST on re0 to 255.255.255.255 port 67
DHCPREQUEST on re0 to 255.255.255.255 port 67
DHCPREQUEST on re0 to 255.255.255.255 port 67
DHCPACK from 192.168.0.1
duplicate IP address 192.168.0.205 sent from ethernet address 00:11:2f:d3:ed:6a
bound to 192.168.0.205 -- renewal in 3600 seconds.
starting system logger
starting initial daemons: ntpd.
savecore: /bsd: kvm_read: version misread
checking quotas: done.
building ps databases: kvm dev.
clearing /tmp
starting pre-securelevel daemons:.
setting kernel security level: kern.securelevel: 0 -> 1
preserving editor files
/etc/rc[515]: /usr/libexec/vi.recover: No such file or directory
starting network daemons: sendmail inetd sshd.
starting local daemons:.
standard daemons: cron.
Thu May 24 12:00:53 EDT 2007

OpenBSD/landisk (landshark.westerback.to) (console)

login: 
There is only one problem - that is not what I want, so in a couple of moments it will be killed.

Hmm, it looks like it is self hosted on machine landisk.openbsd.org.

Mwa-ha-ha, openbsd.org has banned my IP address after I tried to establish a connection with landisk.openbsd.org machine over 22 port to check is this machine really opened to internet. Is it famous OpenBSD security? Because of that stupid fear of the world I can not read theirs FAQ to determine known bootloader commands and features (mainly is it possible to load other kernel except OpenBSD), so it looks like I need just to erase openbsd and install u-bot bootloader instead.

Or maybe not, I tried from another IP address and failed to connect too.

C2K7 OpenBSD hackathon has started!

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


Wed, 23 May 2007

I am about to become a SuperH hacker.


While Grange moved to OpenBSD Drink^WHackathon I got his Landisk SuperH board with Hitachi/Renesas SH-4 CPU based IO-DATA USL-5P board.
Hitachi SH4 SH7751R processor is well supported in Linux (at least according to linux-sh page), but I want to install it myself. This board has RedBoot preloaded, which should be enough to boot Linux kernel.
There are interesting features not being used in kernel so far, so I have some bits to play with.

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