From: Mark Glines <hidden> Date: 2006-12-25 19:46:01
Mark Glines wrote:
Hmm. I'm trying to build 2.6.20-rc2 on a little powerpc box with
arch/powerpc/configs/linkstation_defconfig, and I get:
...
MODPOST vmlinux
ln: accessing `arch/powerpc/boot/zImage': No such file or directory
make[1]: *** [arch/powerpc/boot/zImage] Error 1
make: *** [zImage] Error 2
So, uh, are we forgetting to go into the right subdirectory to make the
actual zImage, or what? If I'm just doing something wrong, I'd love to
know what it is.
I'll follow up here on lkml if I diagnose this further. Thanks,
Followup: Yeah, it looks like it just doesn't know which format of
zImage to produce for linkstation.
I'm not sure what image should be used by default. I guess it depends
on the bootloader. Maybe default to uImage, as uBoot seems to be fairly
common on these devices?
Mark
Hmm. I'm trying to build 2.6.20-rc2 on a little powerpc box with
arch/powerpc/configs/linkstation_defconfig, and I get:
...
quoted
MODPOST vmlinux
ln: accessing `arch/powerpc/boot/zImage': No such file or directory
make[1]: *** [arch/powerpc/boot/zImage] Error 1
make: *** [zImage] Error 2
So, uh, are we forgetting to go into the right subdirectory to make the
actual zImage, or what? If I'm just doing something wrong, I'd love to know
what it is.
I'll follow up here on lkml if I diagnose this further. Thanks,
Followup: Yeah, it looks like it just doesn't know which format of zImage to
produce for linkstation.
I'm not sure what image should be used by default. I guess it depends on the
bootloader. Maybe default to uImage, as uBoot seems to be fairly common on
these devices?
Yes, uImage is the format used on linkstation. Is there a way to cleanly
specify this in the kernel sources apart from a comment in Kconfig?
Thanks
Guennadi
---
Guennadi Liakhovetski
From: Mark Glines <hidden> Date: 2006-12-25 21:47:52
Guennadi Liakhovetski wrote:
On Mon, 25 Dec 2006, Mark Glines wrote:
quoted
Followup: Yeah, it looks like it just doesn't know which format of zImage to
produce for linkstation.
I'm not sure what image should be used by default. I guess it depends on the
bootloader. Maybe default to uImage, as uBoot seems to be fairly common on
these devices?
Yes, uImage is the format used on linkstation. Is there a way to cleanly
specify this in the kernel sources apart from a comment in Kconfig?
Yep. Kconfig just needs to select DEFAULT_UIMAGE, and then the system
tries to build a uImage.
Once I tracked down and installed a "mkimage" command (dependency needed
by the WRAP line), my "make zImage" succeeded. So, I hope you guys
apply this.
...
GEN .version
LD .tmp_vmlinux1
KSYM .tmp_kallsyms1.S
AS .tmp_kallsyms1.o
LD .tmp_vmlinux2
KSYM .tmp_kallsyms2.S
AS .tmp_kallsyms2.o
LD vmlinux
SYSMAP System.map
SYSMAP .tmp_System.map
MODPOST vmlinux
WRAP arch/powerpc/boot/uImage
Image Name: Linux-2.6.20-rc2-kuroboxHG
Created: Sun Dec 24 19:24:12 2006
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1673973 Bytes = 1634.74 kB = 1.60 MB
Load Address: 0x00000000
Entry Point: 0x00000000
paranoid@kuro-2 /usr/src/linux $
Signed-off-by: Mark Glines <redacted>
Mark
Thanks for the patch. Are you actually going to test this kernel on a real
hardware or just testing builds? If it is going to be a real life test,
I'd be interested to know what exactly hardware, U-boot version, dts, and
what results.
BTW, ack-ing your patch would be a bit easier if you sent it inline.
On Mon, 25 Dec 2006, Mark Glines wrote:
Once I tracked down and installed a "mkimage" command (dependency needed by
the WRAP line), my "make zImage" succeeded. So, I hope you guys apply this.
From: Mark Glines <hidden> Date: 2006-12-25 23:07:10
Guennadi Liakhovetski wrote:
Mark
Thanks for the patch. Are you actually going to test this kernel on a real
hardware or just testing builds? If it is going to be a real life test,
I'd be interested to know what exactly hardware, U-boot version, dts, and
what results.
Yes, I do very much intend to test it on real hardware. I have a couple
of Kurobox HGs which desperately need a 21st century kernel. I still
need to install U-boot on it, but first I'm just going to test the
vmlinux with the loader.o kernel module. (And my rs232 voltage
converters haven't gotten here yet, so I'm being a little conservative
about all of this.)
BTW, ack-ing your patch would be a bit easier if you sent it inline.
Yeah, thunderbird sucks for this stuff. Keep nagging me and I'll set up
mutt again. :) Thanks!
Mark
Guennadi Liakhovetski wrote:
Yes, I do very much intend to test it on real hardware. I have a couple of
Kurobox HGs which desperately need a 21st century kernel. I still need to
Ah, what a pity:-) I mean, it is good, but it's exactly the same hardware
I developed this port for and tested on. So, it should be easy. If you
have any problems with your setup, look in linkstation / kurobox mailing
list archives, I posted some instructions there for setting up a suitable
u-boot version. Or just ask me. Or I could even just send you binaries to
start with. Do you have JTag?...
Thanks
Guennadi
---
Guennadi Liakhovetski
From: Mark Glines <hidden> Date: 2006-12-26 20:14:38
Guennadi Liakhovetski wrote:
On Mon, 25 Dec 2006, Mark Glines wrote:
quoted
Guennadi Liakhovetski wrote:
Yes, I do very much intend to test it on real hardware. I have a couple of
Kurobox HGs which desperately need a 21st century kernel. I still need to
Ah, what a pity:-) I mean, it is good, but it's exactly the same hardware
I developed this port for and tested on. So, it should be easy. If you
have any problems with your setup, look in linkstation / kurobox mailing
list archives, I posted some instructions there for setting up a suitable
u-boot version. Or just ask me. Or I could even just send you binaries to
start with. Do you have JTag?...
No, I haven't made any hardware mods yet.
Thanks for the offer. Kernel binaries might actually help, just to make
sure the hardware and bootloader are working properly.
The instructions on
http://www.linuxnotincluded.pwp.blueyonder.co.uk/linkstation/u-bootinstall.html
were a little broken in a few places, but still very helpful. I've got
U-boot 1.1.4 up and running. It's just booting the old 2.4.17_mvl21
from flash right now... 2.6.20-rc2 fails to boot.
I have ordered some serial port voltage converters, which I hope to use
to get some diagnostics from the 2.6.20-rc2 kernel. I don't hear any
disk activity, and I wasn't able to get netconsole working, so I think
it is dying fairly early in the boot process. (At least, before PCI and
network are up.)
Mark
u-boot version. Or just ask me. Or I could even just send you binaries to
start with. Do you have JTag?...
No, I haven't made any hardware mods yet.
I asked about JTag because the U-boot you'll have to flash to boot an
arch/powerpc based kernel has only been so far tested on one (mine)
KuroboxHG. It is (hopefully) the same hardware as yours, but you never
know...
Thanks for the offer. Kernel binaries might actually help, just to make
sure the hardware and bootloader are working properly.
Yes, I can send you the kernel, but I think, it is the u-boot that's most
critical and difficult to build, since what I am running is some checkout
from a git tree with a modified kurobox patch applied, and you might want
to start with a precompiled u-boot. The fdt blob and the kernel are no
longer as critical and much easier to build - just kernel.org kernel with
the default defconfig, but I can send you those too, if you want.
No, those won't help you directly. That U-boot will not be able to boot an
arch/powerpc based kernel. You have to know: there are currently 2 ways to
boot a 2.6 kernel on a linkstation/kurobox. 1: which most (everybody
except me) use - U-boot like what you've built or loader.o + an arch/ppc
based kernel, 2: U-boot based on a version, capable of booting kernels
with an fdt blob (i.e., per "mboot <kernel-addr> [<initrd-addr>]
<fdt-addr>"). If you want the vanilla kernel you need the second method,
hence a newer version of U-boot.
Look here: http://www.kurobox.com/revolution/downloads/contest/patchREADME
for a somewhat rough README and here
http://www.kurobox.com/revolution/downloads/contest/patches.zip are the
patches (sorry about the zip - that was revolution's format of choice...)
But even if I send you an image of U-boot that works for me, I'd have to
warn you if you don't have the jtag port enabled / are not ready to use it
to recover a possible bricked kurobox. You've been warned...
I have ordered some serial port voltage converters, which I hope to use
to get some diagnostics from the 2.6.20-rc2 kernel. I don't hear any
disk activity, and I wasn't able to get netconsole working, so I think
it is dying fairly early in the boot process. (At least, before PCI and
network are up.)
Now you know why your kernel doesn't boot...
Thanks
Guennadi
---
Guennadi Liakhovetski
Thanks a bunch. A RAM build of uBoot boots the old kernel fine, so I'll
replace my older uBoot with it. The only trouble I had was stripping
carriage returns out of the patches in that zipfile; after that,
everything went pretty smoothly.
I noticed uBoot is looking for a *.dtb file, as well as the kernel
image. The patchREADME refers to a "dtc" tool, but the URL it gives
(http://ozlabs.org/~dgibson/dtc/dtc.tar.gz) does not exist. So I
googled and found git://ozlabs.org/srv/projects/dtc/dtc.git, and tried
to compile kuroboxHG.dts, with the command line specified within that file:
$ dtc -f -I dts -O dtb -o kuroboxHG.dtb -V 16 kuroboxHG.dts
DTC: dts->dtb on file "kuroboxHG.dts"
ERROR: Missing /chosen node
Input tree has errors
So, uh... is the *.dts file in 2.6.20-rc2 bad, or am I compiling it
wrongly? (And is this normally done by hand, or as part of the kernel
build process?)
Thanks,
mark
From: Scott Wood <hidden> Date: 2006-12-28 21:02:39
Mark Glines wrote:
$ dtc -f -I dts -O dtb -o kuroboxHG.dtb -V 16 kuroboxHG.dts
DTC: dts->dtb on file "kuroboxHG.dts"
ERROR: Missing /chosen node
Input tree has errors
So, uh... is the *.dts file in 2.6.20-rc2 bad, or am I compiling it
wrongly? (And is this normally done by hand, or as part of the kernel
build process?)
You need to pass the -f option to dtc. Hopefully, dtc will be fixed to
not complain about this at some point.
-Scott
$ dtc -f -I dts -O dtb -o kuroboxHG.dtb -V 16 kuroboxHG.dts
DTC: dts->dtb on file "kuroboxHG.dts"
ERROR: Missing /chosen node
Input tree has errors
the warning is fine. the "chosen" node is filled out by u-boot(instead
of the generated dtb file) for the time being. you can do a quick
reverse dtc to check your dtb binary:
$dtc -f -I dtb -O dts -V 0x10 kuroboxHG.dtb > kuroboxHG.dts.check
quoted
So, uh... is the *.dts file in 2.6.20-rc2 bad, or am I compiling it
wrongly? (And is this normally done by hand, or as part of the kernel
build process?)
You need to pass the -f option to dtc. Hopefully, dtc will be fixed to
not complain about this at some point.
-Scott
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Thanks a bunch. A RAM build of uBoot boots the old kernel fine, so I'll
replace my older uBoot with it. The only trouble I had was stripping carriage
returns out of the patches in that zipfile; after that, everything went pretty
smoothly.
Wow! You are the first who followed my instructions and to that
successfully! Thanks!
Urrrggggh, those carriage returns - I don't have any *DOS* here AT ALL...
It's the Revo guys...
I noticed uBoot is looking for a *.dtb file, as well as the kernel image. The
patchREADME refers to a "dtc" tool, but the URL it gives
(http://ozlabs.org/~dgibson/dtc/dtc.tar.gz) does not exist. So I googled and
found git://ozlabs.org/srv/projects/dtc/dtc.git, and tried to compile
kuroboxHG.dts, with the command line specified within that file:
$ dtc -f -I dts -O dtb -o kuroboxHG.dtb -V 16 kuroboxHG.dts
DTC: dts->dtb on file "kuroboxHG.dts"
ERROR: Missing /chosen node
Input tree has errors
So, uh... is the *.dts file in 2.6.20-rc2 bad, or am I compiling it wrongly?
(And is this normally done by hand, or as part of the kernel build process?)
That's ok. You DO have the "-f" which does produce an output. The error is
because the "chosen" is not there, but this is how we need it for U-boot.
It's done by hand.
So, you've done everything right! Congrats:-)
Thanks
Guennadi
---
Guennadi Liakhovetski
From: Mark Glines <hidden> Date: 2006-12-28 23:28:39
Guennadi Liakhovetski wrote:
quoted
So, uh... is the *.dts file in 2.6.20-rc2 bad, or am I compiling it wrongly?
(And is this normally done by hand, or as part of the kernel build process?)
That's ok. You DO have the "-f" which does produce an output. The error is
because the "chosen" is not there, but this is how we need it for U-boot.
It's done by hand.
So, you've done everything right! Congrats:-)
Great. Any chance you can send me your kernel config? My IDE support
isn't working, and I'd like to figure out why.
Usually I get:
NET: Registered protocol family 1
NET: Registered protocol family 17
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
linkstation: disarming the AVR watchdog:
Root-NFS: No NFS server available, giving up.
VFS: Unable to mount root fs via NFS, trying floppy.
VFS: Cannot open root device "hda1" or unknown-block(2,0)
Please append a correct "root=" boot option
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(2,0)
<0>Rebooting in 180 seconds..
But once, just once, when booting from a RAM build of uBoot, I got:
hda: WDC WD3200JB-00KFA0, ATA DISK drive
ide0 at 0xc9006e80-0xc9006e87,0xc9006e8a on irq 20
hda: max request size: 64KiB
hda: 625142448 sectors (320072 MB) w/8192KiB Cache, CHS=38913/255/63,
UDMA(100)
hda: cache flushes supported
hda:<4>hda: dma_timer_expiry: dma status == 0x20
hda: DMA timeout retry
hda: timeout waiting for DMA
hda: status error: status=0x7f { DriveReady DeviceFault SeekComplete
DataRequest CorrectedError Index Error }
hda: status error: error=0x7f { DriveStatusError UncorrectableError
SectorIdNotFound TrackZeroNotFound AddrMarkNotFound },
LBAsect=140185576636287, high=8355711, low=8355711, sector=0
ide: failed opcode was: unknown
hda: drive not ready for command
ide0: reset: success
hda: lost interrupt
hda: lost interrupt
Thank goodness for netconsole. I think it's especially interesting that
it thinks IDE0 is on irq 20, when the old 2.4.17 kernel says:
hda: WDC WD3200JB-00KFA0, ATA DISK drive
ide0 at 0xbffef8-0xbffeff,0xbffef6 on irq 17
Hmm... 2.6.20, irq20. 2.4.17, irq17. Interesting coincidence. Anyway,
it is either detected wrongly, or specified wrongly. But your kernel
config would help me to make sure I'm at least using the right driver. :)
Think it might be something I could work around by fiddling with the
interrupt-map in that kuroboxHG.dts file? The IDE IRQ seems wrong, even
if the network port obviously works (though I bet netconsole transmits
even if the IRQ is wrong). Are they allocated dynamically on this
architecture, or should I expect the IRQ numbers to be the same between
2.4 and 2.6?
Thanks,
Mark
So, uh... is the *.dts file in 2.6.20-rc2 bad, or am I compiling it wrongly?
(And is this normally done by hand, or as part of the kernel build process?)
That's ok. You DO have the "-f" which does produce an output. The error is
because the "chosen" is not there, but this is how we need it for U-boot.
It's done by hand.
So, you've done everything right! Congrats:-)
Great. Any chance you can send me your kernel config? My IDE support
isn't working, and I'd like to figure out why.
My config is in the kernel - arch/powerpc/configs/linkstation_defconfig.
And I don't use IDE, I use PATA, and it works good, I also had problems
with IDE, although, not as bad as you describe. Also, you, certainly, need
root=/dev/sda1, not hda1, change it in your U-boot environment. As for
interrupt numbers - they are correct, and they are (pretty) arbitrary,
allocated dynamically. I have:
lyakh@KURO-BOX:~$ cat /proc/interrupts
CPU0
16: 0 EPIC Level serial
17: 230 EPIC Edge serial
18: 1747 EPIC Level i2c-mpc
19: 142193 EPIC Level eth0
20: 1764 EPIC Level libata
21: 1309856 EPIC Level ehci_hcd:usb1, ohci_hcd:usb2, ohci_hcd:usb3
BAD: 15
Thanks
Guennadi
---
Guennadi Liakhovetski
From: Mark Glines <hidden> Date: 2006-12-29 02:52:15
Guennadi Liakhovetski wrote:
My config is in the kernel - arch/powerpc/configs/linkstation_defconfig.
Note that it's already pretty far out of date, if you do a "make
oldconfig" on it... I guess linux is a pretty fast-moving target. :)
And I don't use IDE, I use PATA, and it works good, I also had problems
with IDE, although, not as bad as you describe. Also, you, certainly, need
root=/dev/sda1, not hda1, change it in your U-boot environment. As for
Hmm. I have both PATA and IDE enabled... that's probably why its
breaking so badly. Thanks for the tip, I'll give it a try tomorrow morning.
Mark
From: Mark Glines <hidden> Date: 2006-12-29 17:59:18
Guennadi Liakhovetski wrote:
My config is in the kernel - arch/powerpc/configs/linkstation_defconfig.
And I don't use IDE, I use PATA, and it works good, I also had problems
with IDE, although, not as bad as you describe. Also, you, certainly, need
root=/dev/sda1, not hda1, change it in your U-boot environment. As for
interrupt numbers - they are correct, and they are (pretty) arbitrary,
allocated dynamically. I have:
lyakh@KURO-BOX:~$ cat /proc/interrupts
CPU0
16: 0 EPIC Level serial
17: 230 EPIC Edge serial
18: 1747 EPIC Level i2c-mpc
19: 142193 EPIC Level eth0
20: 1764 EPIC Level libata
21: 1309856 EPIC Level ehci_hcd:usb1, ohci_hcd:usb2, ohci_hcd:usb3
BAD: 15
Thanks
Guennadi
---
Guennadi Liakhovetski
Thanks, disabling IDE worked. It took a couple tries due to a Makefile
issue (or misunderstanding on my part)... see below. Now I get to
figure out why my Gentoo userspace won't boot, which I think is beyond
the scope of this list :)
NET: Registered protocol family 1
NET: Registered protocol family 17
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
linkstation: disarming the AVR watchdog:
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 140k init
Synchronizing SCSI cache for disk sda:
Restarting system.
One issue I ran into is that "make zImage" does not rebuild an existing
image, but "make uImage" does... I think the Makefile is missing a
dependency. I'll send a patch if I debug this further. I know the
"zImage" rule is just there for convenience, but apparently zImage is a
deeply ingrained habit for me.
paranoid@kuro-2 /usr/src/linux $ make zImage
CHK include/linux/version.h
CHK include/linux/compile.h
UPD include/linux/compile.h
CHK include/linux/utsrelease.h
CC init/main.o
CC init/version.o
LD init/built-in.o
CC fs/proc/proc_misc.o
LD fs/proc/proc.o
LD fs/proc/built-in.o
LD fs/built-in.o
GEN .version
LD .tmp_vmlinux1
KSYM .tmp_kallsyms1.S
AS .tmp_kallsyms1.o
LD .tmp_vmlinux2
KSYM .tmp_kallsyms2.S
AS .tmp_kallsyms2.o
LD vmlinux
SYSMAP System.map
SYSMAP .tmp_System.map
MODPOST vmlinux
make[1]: `arch/powerpc/boot/zImage' is up to date.
paranoid@kuro-2 /usr/src/linux $ make uImage
CHK include/linux/version.h
CHK include/linux/compile.h
UPD include/linux/compile.h
CHK include/linux/utsrelease.h
CC init/main.o
CC init/version.o
LD init/built-in.o
CC fs/proc/proc_misc.o
LD fs/proc/proc.o
LD fs/proc/built-in.o
LD fs/built-in.o
GEN .version
LD .tmp_vmlinux1
KSYM .tmp_kallsyms1.S
AS .tmp_kallsyms1.o
LD .tmp_vmlinux2
KSYM .tmp_kallsyms2.S
AS .tmp_kallsyms2.o
LD vmlinux
SYSMAP System.map
SYSMAP .tmp_System.map
MODPOST vmlinux
WRAP arch/powerpc/boot/uImage
Image Name: Linux-2.6.20-rc2-kuroboxHG
Created: Fri Dec 29 09:43:09 2006
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1624545 Bytes = 1586.47 kB = 1.55 MB
Load Address: 0x00000000
Entry Point: 0x00000000
Mark
It took a couple tries due to a Makefile issue
(or misunderstanding on my part)... see below. Now I get to figure out why my
Gentoo userspace won't boot, which I think is beyond the scope of this list :)
Well, you're welcome to (subscribe and) continue discussing any kurobox /
linkstation non kernel-related issues on the respective yahoo-groups list.
No, I am not specifically happy about the choice of the list hosting, but
- it wasn't mine. As a guess - mostly you have to modify /etc/fstab,
sometimes S.M.A.R.T. related configuration, usually not much more than
that. But I don't use gentoo - there are guys there that do, they'll be
able to help, if they read those lists... Most discussions take place on
online forums, which I like even less. (Sorry for the OT.)
Thanks
Guennadi
---
Guennadi Liakhovetski