Historical kernels and kernel-headers?

[moonman]

Setup distcc if you are going tp be trying to build all those kernels. Of you run arch on your desktop/laptop it is even easier as WarheadsSE already has PKGBUILD for x86 side of things.

[larrybaker]

Moonman,

Sorry, I run Arch on only one other system, another Kirkwood PlugPC. It's our DECnet-to-NFS gateway that I built a year ago. I'm trying to update it and use it in a lab as both a DECnet-to-NFS gateway and an SMB2-to-NFS gateway. Which is why I care about fixing the Linux decnet driver (again).

My desktop is a Mac. I really don't like Linux as a desktop system. Servers, yes. I do Linux data acquisition systems and one-off projects like this one, and I have a 32-node Linux x86_64 cluster we use for HPC. I like Arch as an O/S platform better than Debian or Ubuntu, which seem to be the common choices for ARM SoCs. I like the Arch online support info. But, I don't particularly care for rolling updates. It's making much more work for me to build all the kernels between what I have that works and the current release so I can figure out when decnet broke. Only then do I get to start figuring out why. I have no other Arch systems to farm out all these compiles to, so this is going to take a long time.

Thanks for your very useful information. People like you are the real value of Arch.

Larry baker
US Geological Survey

[pepedog]

Another alternative, you have a utilite pro, you could have arch on a card, expand an armv5 rootfs to a folder on ssd, and arch-chroot to it. Change j value in makepkg.conf and it's a v5 on steroids, kernel pkg in about an hour or less

[larrybaker]

Very interesting suggestion pepedog. I may take you up on that. How did you know I have a utilite? I don't have a pro, only a standard -- 2 cores, no SSD. I also have a utilite value -- 1 core -- still in the box. They both run off SD cards. I assumed I had to run the CompuLab rootfs for the correct kernel. I never looked at Arch for it.

Thanks,

Larry Baker
US Geological Survey

[pepedog]

There is 2 ways of doing this, both getting files from http://archlinuxarm.org/platforms

1/ make card as if its for utilite, but put whichever rootfs you want. Grab utilite kernel and extract kernel and modules, put them in place. Note you either change in uboot kernel=uImage OR rename uImage to what uboot expects. It's a v5 system
Get kernel from http://os.archlinuxarm.org/armv7h/core/

2/ Make a proper utilite card, install arch-install-scripts, extract v5 rootfs to a folder, arch-chroot to it

Don't forget to alter j value in makepkg.conf to take advantage of cores

[WarheadsSE]

See https://wiki.archlinux.org/index.php/De ... ean_Chroot

[larrybaker]

So, I flashed the 3.4.5-0 kernel and it does not boot.
$this->bbcode_second_pass_code('', 'Reading data from 0x4ff800 -- 100% complete.
4194304 bytes read: OK
## Booting image at 00800000 ...
Image Name: Linux-3.4.5-0-ARCH
Created: 2014-08-06 0:18:52 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3028792 Bytes = 2.9 MB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
')
This must be the uBoot issue moonman talked about. (I updated uBoot to U-Boot 1.1.4 (Dec 27 2009 - 22:03:21) Marvell version: 3.4.27. That's the latest one I know about.) However, the latest Kirkwood rootfs and kernel do boot on my SheevaPlug.

The warning message
$this->bbcode_second_pass_code('', ' echo "**********************************************************************"
echo "WARNING! This kernel requires a newer U-Boot than many devices such as"
echo " the Dockstar and Pogoplug v2 originally came with. If you do"
echo " not have an updated version, your system WILL NOT BOOT."
echo "**********************************************************************"
')
was removed from linux-kirkwood.install by Kevin Mihelich on January 20, 2014 (commit ea22e679eed45b9708263d00c26e73287aeb0c6f). Can anyone tell me why?

My strategy to track down the Linux decnet driver problems has been to use the generic ARMV5TE 3.1.10-34 rootfs. DECnet works on that version. I figured I would work my way forward from that. I chose the first Kirkwood Arch Linux ARM to try. I installed the linux-kirkwood-3.4.5 I built on top of the generic ARMV5TE 3.1.10-34 rootfs. I don't think the rootfs is the problem. I think whatever the uBoot issue was is the problem. Would you recommend I instead start with the latest Kirkwood rootfs and work backwards? Does anyone know which is the oldest kernel that no longer has the uBoot issue?

Thanks,

Larry Baker
US Geological Survey

[moonman]

If 3.15 boots it is not uboot. I also mentioned memset patch in one of the earlier posts. It is incompatibility caused by new gcc 4.8 optimizations and older kernels. It was fixed in the later kernels. This is the patch: https://raw.githubusercontent.com/archl ... mset.patch

[larrybaker]

Thanks. I'll give that a try tomorrow. I am compiling from the last Arch ARMV5TE linux package, 3.1.10-34-ARCH. I don't know what gcc it has.

[moonman]

since gcc doesn't come with rootfs and is a part of base-davel group that I assume you installed just recently then gcc is 4.8.2. One thing I don't know is when this was fixed. You will have to toss this patch at a certain kernel version.