Re: New sparc64 netboot image available
Hi, On Thu, Apr 06, 2017 at 04:34:17PM +0100, Mark Cave-Ayland wrote: > Having a quick look at the tilo patches, it looks like they do the right > thing which is to take the compressed image obtained via TFTP at > load-base, use the PROM to allocate and map the relocated kernel/initrd > image memory (from the ELF headers maybe?), then decompress the binary > image into the allocated target memory and run it. > > Note that this means the compressed image is still subject to the 10MB > limit, but likely that should be less of a problem these days with > compressors such as xz. SILO/TILO currently has only gzip decompressor, so kernel has to be compressed with gzip. But for initramfs you can use xz, as the kernel does decompression. And with modular kernel most of the code goes into initramfs. 10MB shouldn't be an issue - I have made a simple (non-Debian) netinstall image for my Ultrasparcs and with 4.10 kernel, glibc 2.25, ssh and other tools and the size is less than 5 MB. A.
Re: New sparc64 netboot image available
Hi, On Mon, Apr 03, 2017 at 11:15:55PM +0200, John Paul Adrian Glaubitz wrote: > On 04/03/2017 11:13 PM, Frans van Berckel wrote: > > Are you able to look into a compressed kernel as well? As suggested by > > Aaro. Or do we need a TILO patch, handeling such an kernel? > > Hmm, not sure what you mean. The kernel that d-i uses for the cdrom and > netboot > images is already compressed: > > root@stadler:/srv/d-i/debian-installer/installer/build/tmp/netboot# file > vmlinuz-4.9.0-2-sparc64 > vmlinuz-4.9.0-2-sparc64: gzip compressed data, max compression, from Unix > root@stadler:/srv/d-i/debian-installer/installer/build/tmp/netboot# The image that is loaded by "boot net" is the boot.img file, and the kernel there is uncompressed. $ strings boot.img | grep Linux | head -5 Linux version 4.9.0-2-sparc64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 20170321 (Debian 6.3.0-11) ) #1 Debian 4.9.18-1 (2017-03-30) Linux panicing Linux rebooting Linux powering off Linux halting A.
Re: New sparc64 netboot image available
Hi, On Mon, Apr 03, 2017 at 02:41:01PM +0200, Frans van Berckel wrote: > On Mon, 2017-04-03 at 11:32 +0200, John Paul Adrian Glaubitz wrote: > > It contains both the kernel and the initrd. But that's true for sparc > > as well, so I am not sure why the sparc image is so much smaller. > > > > In debian-installer's build/util/tftpboot.sh: > > > > sparc | sparc64) > > elftoaout -o $tftpimage $tftpimage.tmp > > # Piggyback appends the ramdisk to the a.out image in-place > > piggyback64 $tftpimage $tmp $rootimage > > ;; > > > > So, I am currently out of ideas, to be honest. > > There a 10Mb limit, if i am well, allocated by Openboot for the > bootloader. We are acting within the same space? > > https://lists.debian.org/debian-sparc/2015/12/msg00115.html With TILO image you could use compressed kernel. A.
Re: [PATCH] silo: Add 64-bit support
Hi, On Thu, Nov 24, 2016 at 11:26:20PM +0100, John Paul Adrian Glaubitz wrote: > On 11/24/2016 11:05 PM, Aaro Koskinen wrote: > > The same issue as with silo. > > Don't you think your statements are a bit misleading then? I didn't break > anything, > I changed the default target to 64-bit which is somewhat reasonable in the > year > 2016, isn't it. You could write the Makefile so that build works even with 32-bit userspace. I don't think it's unreasonable or rude to demand. > Or are you going to tell me now that your 333 MHz, 128 MiB RAM Sun > Ultra 5 is your everyday production machine? Yes, I'm using Ultra 5 on daily basis. The CPU is 360 MHz and with 512 MiB RAM. A.
Re: [PATCH] silo: Add 64-bit support
Hi, On Thu, Nov 24, 2016 at 06:33:30PM +0100, John Paul Adrian Glaubitz wrote: > -# We want to force 32-bit builds > -CC=gcc -m32 > +# We want to force 64-bit builds > +CC=gcc > HOSTCC=gcc > -LD=ld -m elf32_sparc > +LD=ld -m elf64_sparc This breaks the native build on my Sun Ultra 5 with 32-bit userspace and GCC defaulting to ultrasparc: $ make [...] make[1]: Entering directory '/home/aaro/silo/first' gcc -Os -Wall -I. -I../include -fomit-frame-pointer -fno-strict-aliasing -DSMALL_RELOC=0x28 -DLARGE_RELOC=0x38 -fno-stack-protector -c first.S -o first.o ld -m elf64_sparc -N -Ttext 0x4000 -o first first.o ld: sparc architecture of input file `first.o' is incompatible with sparc:v9 output Makefile:39: recipe for target 'first' failed make[1]: *** [first] Error 1 make[1]: Leaving directory '/home/aaro/silo/first' Makefile:15: recipe for target 'all' failed make: *** [all] Error 1 Also you broke the tilo build... A.
Re: Please upgrade your machines to sparc64
Hi, On Wed, Jun 22, 2016 at 09:23:40PM +0200, John Paul Adrian Glaubitz wrote: > That won't change the fact that the majority of work is now happening on > sparc64. I don't think there is a realistic chance of getting most projects > spending much work on the 32-bit code since the focus is on new hardware. > > Either way, Debian sparc (32-bit) is completely unsupported these days > and no longer receiving any security updates. So, anyone should either > use Gentoo or switch over to Debian sparc64. Or compile and maintain your own 32-bit userspace (like I do). For the stuff I need, upstream projects have no issues with 32-bit. A.
Re: Need help debugging silo
On Wed, Dec 30, 2015 at 10:57:15PM +0100, John Paul Adrian Glaubitz wrote: > On 12/30/2015 10:48 PM, Aaro Koskinen wrote: > > Maybe the current (properly patched) version of elftoaout should be > > submitted to either to SILO or kernel upstream source tree, so that > > people wouldn't need to face such issues in the future... > > From what I can see, upstream seems long dead: > > ftp://sunsite.mff.cuni.cz/OS/Linux/Sparc/local/elftoaout/elftoaout-2.3.tgz > > And distributions seem already all carrying the necessary patch. > > I might create a new repository on github some time next week. I meant, since both SILO and kernel builds need that tool, it could be well added to corresponding repositories directly (especially since not maintained separately anymore). It's a very small piece of code anyway. A.
Re: Need help debugging silo
Hi, On Tue, Dec 29, 2015 at 12:22:17PM +0100, John Paul Adrian Glaubitz wrote: > On 12/29/2015 12:18 PM, Bryce wrote: > > Having just looked, it carries a small patch (elftoaout-include.patch) which > > modifies the Exec struct, though now that I look at it, as mentioned by > > Mark, > > those should probably be u_int32_t for portability between 32/64. > > We didn't make any changes to elftoaout so we never hit this particular > > problem. > > Yay, after applying the fix, elftoaout behaves properly ;-). Maybe the current (properly patched) version of elftoaout should be submitted to either to SILO or kernel upstream source tree, so that people wouldn't need to face such issues in the future... A.
Re: netboot failure with current kernels?
Hi,
On Wed, Jun 10, 2015 at 12:29:43AM +0300, Aaro Koskinen wrote:
On Tue, Jun 02, 2015 at 07:50:19PM +0300, Meelis Roos wrote:
I tried to install Debian on my E280R. Netboot is the most natural way
for remote install so I tried that. Current Debian installer fails to
load:
{0} ok boot net
Boot device: /pci@8,70/network@5,1: File and args:
Timeout waiting for ARP/RARP packet
4000 \
ERROR: /packages/obp-tftp: Last Trap: Fast Data Access MMU Miss
Boot load failed
Is this some known problem with TFTP booting that Debian needs to fix,
or something new? Size of the boot.img file is 12988928 bytes, OBP
version 4.16.4 2004/12/18.
Probably the image is too big. At least on older sparcs the limit
is 10 MB.
Based on quick look, Debian netboot image has 8 MB
uncompressed kernel and 4.5 MB compressed initramfs.
By using compressed kernel it would all fit under 10 MB.
Such image could be created using the latest TILO version from:
https://git.kernel.org/cgit/linux/kernel/git/davem/silo.git
A.
--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/20150615182757.ga1...@aspire-one.musicnaut.iki.fi
Re: Ultra-5 freezing
Hi, On Thu, Sep 11, 2014 at 09:41:09PM +0200, BERTRAND Joël wrote: BUT : for several months, Linux/Sparc64 is unfortunately not stable anymore (or completely broken). After 2.6.35 kernel, I can see random deadlock on all my sparc64 (sun4v _and_ sun4u). Now, I run NetBSD or Solaris 10. But FreeBSD and OpenBSD run fine also. I have Ultra 5 in active use. It used to suffer from random hard lockups/hangs, but those issues disappeared with recent Linux mainline kernels (I think after 3.12 or so). A. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140912000340.gc...@drone.musicnaut.iki.fi
