Re: Future of the s390 port
> > Thanks a lot Bastian. > I received basically the same info in a private mail from Adam (private > probably because he forwarded it from a contact at SuSE). So thanks to > them too. > > And with the help of google to fill in the missing bits I now have it > working in Hercules again. > Well, I'm sorry I couldn't be of much help on this one. I'm afraid I'm spoiled by z/VM. Since I have access to z/VM, I don't mess with LPARs much. Perhaps my main contribution this time was to demonstrate that there are people out there in the user community who care passionately about the continued viability of the Debian s390 port. And perhaps that motivated others who had the requisite knowledge to come forth. My next suggestion was going to be "look at the install CD for another distribution and see how they do it". But unfortunately I don't have access to such a CD myself. And apparently neither did you. Fortunately, someone out there did. :soapbox. Documentation for IBM hardware really stinks these days. In the "old days", when they were still operating under the consent decree, you could get documentation for just about anything. But since the consent decree has been canceled, they have been really tight with everything. For example, I can't get documentation on the channel commands or sense bytes for 3590 tape control units. I can't get documentation on the SERVC interface to the processor controller (for things like I/O to the integrated system console, integrated 3270 console, obtaining the LOADPARM, etc.). And I'd be willing to bet that you can't get documentation on the internals of "LOAD from a CD ROM or FTP Server" either. All of that came out after the consent decree was canceled. How ironic that the world's best server consolidation platform for open source servers is so tight with its own documentation! :esoapbox. I might suggest that you modify the s390 install script to put in a plug for this mailing list. I have been using Debian on s390 for years but only joined this list last week. Perhaps there are others out there like me who could be of service in some way if they were connected. As I mentioned in an earlier post, I am working on a "how to" document for getting the high-performance DASD DIAG driver to work for Debian on s390. Perhaps that will be useful to someone. If I can be useful in some other way, please let me know. Regards, Steve -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Future of the s390 port
On Sun, Oct 11, 2009 at 04:20:28PM +0200, Frans Pop wrote: > diff --git a/data/squeeze/s390/d390oco.ins b/data/squeeze/s390/d390oco.ins This file can be removed. If I can find the repo, I will do some cleanup in a few days. Bastian -- Warp 7 -- It's a law we can live with. -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Future of the s390 port
Bastian Blank wrote:
> On Sat, Oct 10, 2009 at 08:00:13PM +0200, Frans Pop wrote:
>> Right, so who has a *recent* SuSE CD he/she can disect? I personally
>> don't feel like registering with Novell just for this.
>
> Well, I have an account and got an image.
Thanks a lot Bastian.
I received basically the same info in a private mail from Adam (private
probably because he forwarded it from a contact at SuSE). So thanks to
them too.
And with the help of google to fill in the missing bits I now have it
working in Hercules again.
Attached the patch for debian-cd (for squeeze). I've tested it for both
Lenny and Squeeze (the latter using current daily D-I images), so the same
changes work for both 31-bit and 64-bit kernels.
>> Main questions are:
>> - what does the .ins file they use look like?
>
> | * SuSE Linux for zSeries Installation/Rescue System
> | boot/s390x/vmrdr.ikr 0x
> | boot/s390x/initrd.off 0x0001040c
> | boot/s390x/initrd.siz 0x00010414
> | boot/s390x/initrd 0x0080
> | boot/s390x/parmfile 0x00010480
We did not yet specify initrd offset and size.
>> - what kind of initrd do they use: initramfs or "oldfashioned" initrd?
>> - if oldfashioned, then what filesystem do they use?
>> - if initramfs, then how do they manage to boot it?
>
> This are just memory loads, so this should work regardless of the type.
> The kernel handles both types in the same way.
Well, it worked without the size and offset for ext2 initrds. And at least
that defines block you quoted has been unchanged since the start of git
(2.6.12). Maybe there has been a change in the kernel, or maybe the
autodetection differs between initramfs and a "real" file system.
>> - what is the kernel config they use in their installer?
>
> The VM reader kernel.
Same as us then.
So with this weekly built CDs should work again very soon if you boot using
d390.ins. And Lenny CDs should work again with the next point release.
Note that I have not modified d390.tdf, which I assume is tape emulation.
I have no idea if that is supposed to be possible from CD. If someone knows
and wants to test that, please do.
Cheers,
FJP
diff --git a/data/squeeze/s390/d390.ins b/data/squeeze/s390/d390.ins
index 5e82599..78c5f11 100644
--- a/data/squeeze/s390/d390.ins
+++ b/data/squeeze/s390/d390.ins
@@ -1,4 +1,6 @@
* Debian GNU/Linux for S/390 (boot from CD-ROM or FTP-Server)
linux_vm 0x
+root.off 0x0001040c
+root.siz 0x00010414
parmfile 0x00010480
root.bin 0x0080
diff --git a/data/squeeze/s390/d390oco.ins b/data/squeeze/s390/d390oco.ins
index 03da8f6..b3f11dd 100644
--- a/data/squeeze/s390/d390oco.ins
+++ b/data/squeeze/s390/d390oco.ins
@@ -1,5 +1,7 @@
* Debian GNU/Linux for S/390 (boot from CD-ROM or FTP-Server with
OCO-Modules)
linux_vm 0x
+root.off 0x0001040c
+root.siz 0x00010414
parmfile 0x00010480
root.bin 0x0080
oco.bin 0x00c0
diff --git a/tools/boot/squeeze/boot-s390 b/tools/boot/squeeze/boot-s390
index 6b3796f..34b8351 100755
--- a/tools/boot/squeeze/boot-s390
+++ b/tools/boot/squeeze/boot-s390
@@ -87,6 +87,10 @@ done
# - d390oco.tdf : same, using object-code-only-modules-ramdisk (example)
cp $BASEDIR/data/$CODENAME/s390/d390* "$imagedir/"
+# Create the files specifying offset and size of the initrd
+perl -e "print pack('N', 0x80)" >"$imagedir/root.off"
+perl -e "print pack('N', -s '$imagedir/root.bin')" >"$imagedir/root.siz"
+
# Copy the README file
cp $BASEDIR/data/$CODENAME/s390/README.boot "boot$N/"
--
To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Future of the s390 port
On Sun, Oct 11, 2009 at 02:24:50PM +0200, Bastian Blank wrote: > The addresses are specified this way: > | #ifndef __s390x__ > | #define IPL_DEVICE(*(unsigned long *) (0x10404)) > | #define INITRD_START (*(unsigned long *) (0x1040C)) > | #define INITRD_SIZE (*(unsigned long *) (0x10414)) > | #else /* __s390x__ */ > | #define IPL_DEVICE(*(unsigned long *) (0x10400)) > | #define INITRD_START (*(unsigned long *) (0x10408)) > | #define INITRD_SIZE (*(unsigned long *) (0x10410)) > | #endif /* __s390x__ */ > | #define COMMAND_LINE ((char *)(0x10480)) > > So the addresses for the initrd differs between the 31 and 64bit kernel. Flawed observation. This way you can load the 32bit long addresses always at the same location, regardless of the type. Bastian -- Only a fool fights in a burning house. -- Kank the Klingon, "Day of the Dove", stardate unknown -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Future of the s390 port
On Sat, Oct 10, 2009 at 08:00:13PM +0200, Frans Pop wrote:
> Right, so who has a *recent* SuSE CD he/she can disect? I personally don't
> feel like registering with Novell just for this.
Well, I have an account and got an image.
> Main questions are:
> - what does the .ins file they use look like?
| * SuSE Linux for zSeries Installation/Rescue System
| boot/s390x/vmrdr.ikr 0x
| boot/s390x/initrd.off 0x0001040c
| boot/s390x/initrd.siz 0x00010414
| boot/s390x/initrd 0x0080
| boot/s390x/parmfile 0x00010480
This looks like absolute addresses, so the contents of the initrd.off,
initrd.siz and parmfile files are written into the kernel image.
> - what kind of initrd do they use: initramfs or "oldfashioned" initrd?
> - if oldfashioned, then what filesystem do they use?
> - if initramfs, then how do they manage to boot it?
This are just memory loads, so this should work regardless of the type.
The kernel handles both types in the same way.
> - what is the kernel config they use in their installer?
The VM reader kernel.
More informations:
| $ l boot/s390x/{vmrdr.ikr,initrd*,parmfile*}
| -r--r--r-- 1 root root 12897335 8. Mär 2009 boot/s390x/initrd
| -r--r--r-- 1 root root4 8. Mär 2009 boot/s390x/initrd.off
| -r--r--r-- 1 root root4 8. Mär 2009 boot/s390x/initrd.siz
| -r--r--r-- 1 root root 71 8. Mär 2009 boot/s390x/parmfile
| -r--r--r-- 1 root root 102 8. Mär 2009 boot/s390x/parmfile.cd
| -r--r--r-- 1 root root 6761472 8. Mär 2009 boot/s390x/vmrdr.ikr
| $ hexdump -C boot/s390x/initrd.off
| 00 80 00 00 ||
| 0004
| $ hexdump -C boot/s390x/initrd.siz
| 00 c4 cc 37 |...7|
| 0004
| $ cat boot/s390x/parmfile
| ramdisk_size=65536 root=/dev/ram1 ro init=/linuxrc TERM=dumb
| manual=1
|
| $ cat suse.ins
| * SuSE Linux for zSeries Installation/Rescue System
| boot/s390x/vmrdr.ikr 0x
| boot/s390x/initrd.off 0x0001040c
| boot/s390x/initrd.siz 0x00010414
| boot/s390x/initrd 0x0080
| boot/s390x/parmfile 0x00010480
| $ cat boot/s390x/suse.ins
| * SuSE Linux for zSeries Installation/Rescue System
| vmrdr.ikr 0x
| initrd.off 0x0001040c
| initrd.siz 0x00010414
| initrd 0x0080
| parmfile 0x00010480
The addresses are specified this way:
| #ifndef __s390x__
| #define IPL_DEVICE(*(unsigned long *) (0x10404))
| #define INITRD_START (*(unsigned long *) (0x1040C))
| #define INITRD_SIZE (*(unsigned long *) (0x10414))
| #else /* __s390x__ */
| #define IPL_DEVICE(*(unsigned long *) (0x10400))
| #define INITRD_START (*(unsigned long *) (0x10408))
| #define INITRD_SIZE (*(unsigned long *) (0x10410))
| #endif /* __s390x__ */
| #define COMMAND_LINE ((char *)(0x10480))
So the addresses for the initrd differs between the 31 and 64bit kernel.
Bastian
--
Murder is contrary to the laws of man and God.
-- M-5 Computer, "The Ultimate Computer", stardate 4731.3
signature.asc
Description: Digital signature
