LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware > Slackware - ARM
User Name
Password
Slackware - ARM This forum is for the discussion of Slackware ARM.

Notices


Reply
  Search this Thread
Old 01-25-2017, 01:10 AM   #31
SCerovec
Senior Member
 
Registered: Oct 2006
Location: Cp6uja
Distribution: Slackware on x86 and arm
Posts: 1,080
Blog Entries: 2

Original Poster
Rep: Reputation: 130Reputation: 130

I have no doubt!
Ramifications:

kernels of the 3.x branch require the old u_boot (fex one)

This is a deal breaker for me: I like all supported boards to be bootable via the same u_boot?

further, how does the 3.4.x kernel (non dtb) fare with the Slackware system?

Any caveats there?

Last edited by SCerovec; 01-25-2017 at 01:16 AM. Reason: looked up the kernel...
 
Old 01-25-2017, 02:36 PM   #32
Hannes Worst
Member
 
Registered: Jul 2008
Location: Tilburg, The Netherlands
Distribution: OpenBSD, Slackware, NetBSD
Posts: 116

Rep: Reputation: 48
Most linux operatingsystems (debian, ubuntu, Arch) on H3-boards make use of script.bin that must be patched to adjust kernelsettings. Armbian developers made several scripts to achieve this, like h3disp: https://forum.armbian.com/index.php/...on-h3-devices/, to change resolution and fix-thermal.sh https://forum.armbian.com/index.php/...lity-problems/ to prevent overheating on some boards. Linux-sunxi developed some sunxi-tools like bin2fex and fex2bin to patch script.bin. I don know if it is usable within slackware though, I never tried it.
 
1 members found this post helpful.
Old 01-26-2017, 07:32 AM   #33
drmozes
Slackware Contributor
 
Registered: Apr 2008
Location: Surrey, England
Distribution: Slackware
Posts: 521

Rep: Reputation: 392Reputation: 392Reputation: 392Reputation: 392
Regarding using a vendor kernel in Slackware ARM: no.

Raspbian et al all exist in support *of* a particular device, where as Slackware ARM exists because I want it to- independently from any device. Slackware ARM has support *for* a piece of hardware if it makes it in to the upstream kernel (and mostly) X.org support (but I mainly care only about Kernel support), not "this product is brought to market with an OS we've hacked up just so people can switch it on and use it for <something>"

Using an old vendor kernel:
1. Security? where do the patches come from
2. Support for hardware: e.g. the current sun8i emac driver (network on H3 plus a couple others) is no longer developed. The support is being merged into the stmmac driver. I'm not going to invest my time in something that's already legacy, just to support a particular device. If the support is upstream in an main stream release candidate or "linux next", then that's progressive not regressive.
3. Supporting an older kernel causes problems for long term maintenance and even maintenance of "-current". it'd need special support just to avoid applying the handful of patches currently required for 4.x, for example.

Anyway, I already have 4.10rc5 out in -current now which supports H3. The only problem is that the sun8i emac driver crashes under load (e.g. when installing Slackware) - where as it did not with rc2; so I've contacted the developer of it who replied today with some help.
Once I have it working I'll make the notice in the change log.
 
Old 01-27-2017, 04:20 AM   #34
SCerovec
Senior Member
 
Registered: Oct 2006
Location: Cp6uja
Distribution: Slackware on x86 and arm
Posts: 1,080
Blog Entries: 2

Original Poster
Rep: Reputation: 130Reputation: 130
Thumbs up

So, there is no mainline kernel in the 3.4.x series?

And the various *bian-s are patchworks for particular devices (no same kernel across the various devices)?

Then it makes no sense whatsoever to go back

OTOH, our good host drmozes already brew us an upcoming 4.x kernel supporting the H3.

Dear chef, when can we try the stew too ?
(I know,I know, but I had to ask ?)

Meanwhile the updated (yet to be tested) stript for U-boot (one script that does it all (hopefully)) with the ISC license ('this okay?)

file boot.cmd
Code:
###
#
#  v0.4-beta (C) ISC cest73@ya.ru 2016 and onwards for Slackware ARM and U-BOOT
#
#  filename: boot.cmd
#
#  Generic (hopefully) Uboot script with templates for many scenarios
#  typical on-disk layout:
#  /boot/          for kernel and initrd
#  /boot/dtb/      for device tree files
#  /boot.scr       configuration for u_boot
#                  the last one generated from 
#  /boot.cmd       by
#
#  /usr/sbin/bootedit
#
###

###
#
# declaring the system layout for boot...
#
###

# uncomment only one of the two
#setenv mode 'setup'
setenv mode 'regular'

# set the appropriate boot target(CASE sensitive!):
# 'tftp' for booting over LAN, please refer to HOWTOS on install media
# 'usb' for booting from a USB storage (stick or disk)
# 'sata' to harness the speedy SATA interface for boot
# 'fel' if You deliver this file and the boot items by means of an OTG micro USB cable
# 'mmc' for the most usual setup - the files residing on a SD or MMC card
setenv media 'mmc'

#'serial' for the UART0
#'hdmi' for the HDMI port
#TODO 'composite'
#TODO 'ssh'
setenv interface 'hdmi'

#'auto' dhcp
#'172.32.16.0' our local address, then also set host below
#'none' no net during boot
setenv net 'none'
#setenv net '192.168.168.128'
# the IP of the tftp serving host
#setenv host '192.168.168.102'

# One has to read and search for the correct value here
# look in /boot/dtb/ for Yours
# for Banana PI:sun7i-a20-bananapi.dtb
setenv dtbfile 'sun7i-a20-bananapi.dtb'

# the custom commandline parameters go here 
# (4 for X on boot, 3 for default, etc)
# plus board specific hacks and tweaks
setenv bootcmd_generic ' debug earlyprintk sunxi_g2d_mem_reserve=0 sunxi_ve_mem_reserve=0 TERM=screen-256color 3'


# below this line WHERE THERE BE DRAGONS! (dont go!)

echo '-->SlackwareARM U-boot helper script V0.4...'

###
#
# defining the host specific parameters
#
###

# One has to read and search for the correct value here
# for Banana PI:
setenv fdtfile "/boot/dtb/${dtbfile}"

# kernel is (mostly) always te same
setenv kernelfile '/boot/zImage-armv7'
if test $mode = 'setup'; then
   # for setup
   setenv setupfs '/boot/initrd-armv7.img'
else
   # for everyday
   setenv initrdfile '/boot/initrd-armv7'
fi

if test $media = 'tftp'; then
  # here again, read thorougly the correct DTB file for the
  # actual comupter booting:
  setenv tftpfdtfile "slackwarearm-current/dtb/${dtbfile}"

  setenv tftpkernelfile 'slackwarearm-current/zImage-armv7'

  if test $mode = 'setup'; then
     # for setup
     setenv tftpsetupfs 'slackwarearm-current/initrd-armv7.img'
  else
     # for everyday
     setenv tftpinitrdfile 'slackwarearm-current/initrd-armv7'
  fi
fi

###
#
# defining the load addresses
#
###

# we change only for fel, otherwise we falback to tftp address
if test $media = 'fel' ; then
   # derived from UBOOT-FEL load address
   setenv fdt_addr_r 0x43000000
   setenv kernel_addr_r 0x42000000
   setenv ramdisk_addr_r 0x43300000
else
   # use this for tftfp setup
   setenv fdt_addr_r 0x43000000
   setenv kernel_addr_r 0x46000000
   setenv ramdisk_addr_r 0x47000000
fi

###
#
# crafting the file source commands
#
###

if test $media = 'tftp'; then
   echo "-->TFTP init:"
   # by tftpboot ..........refer how to setup in the install on Banana PI HOWTO
   # adjust to own TFTP server/host
   if test $net != 'auto'; then
      setenv serverip ${host}
      setenv ipaddr ${net}
   else
      # this is rather an parachute option ;)
      dhcpcd
   fi
   echo "-->Loading FDT"
   tftp ${fdt_addr} ${tftpfdtfile}
   echo "-->Loading kernel"
   tftp ${kernel_addr_r} $tftpkernelfile
   if test $mode = 'setup'; then
      echo "-->Loading setup ramdisk"
      # for setup
      tftp ${ramdisk_addr_r} $tftpsetupfs
   else
      echo "-->Loading initial ramdisk"
      # for everyday
      tftp ${ramdisk_addr_r} $tftpinitrdfile
   fi
else
   if test $media = 'fel'; then
      #for FEL we load via the cable O.o
      echo "-->FEL initiating"
   else
      if test $media = 'sata'; then
         echo "-->SATA/SCSI initiating"
         scsi reset
         scsi scan
      elif test $media = 'usb'; then
         echo "-->USB initiating"
         usb reset
         usb scan
      fi
      # except for fel, we load for mmc, usb and scsi/sata
      echo "-->Loading files from ${media} 0:1"
      load ${media} 0:1 ${fdt_addr_r} ${fdtfile}
      load ${media} 0:1 ${kernel_addr_r} ${kernelfile}
      if test $mode = 'setup'; then
         echo "-->Loading setup ramdisk"
         # for setup
         load ${media} 0:1 ${ramdisk_addr_r} ${setupfs}
      else
         echo "-->Loading initial ramdisk"
         # for every day
         load ${media} 0:1 ${ramdisk_addr_r} ${initrdfile}
      fi
   fi
   fdt addr ${fdt_addr_r} 0x40000
fi
###
#
# crafting the boot arguments
#
###

### initial output for OS

if test $interface = 'serial'; then
   # for serial console
   setenv slkconsole ' console=ttyS0,115200'
else
   # we asumeotherwise always or for HDMI
   setenv slkconsole ' console=tty1 disp.screen0_output_mode=EDID:1680x105060 hdmi.audio=EDID:0'
fi

### OS related parameters

if test $mode = 'setup'; then
   if test $net = 'auto'; then
      # setup with automatic network parameters
      setenv osargs " nic=auto:eth0:dhcp root=/dev/ram rw"
   else
      # setup with manual or special network setup
      setenv osargs " nodhcp root=/dev/ram rw"
   fi
else
   if test $media = 'mmc' ; then
      # everyday parameters for MMC/SD card
      setenv osargs " resumedev=/dev/mmcblk0p2 root=/dev/mmcblk0p1 rootfstype=ext4 ro"
   else
      if test $media = 'scsi' ; then 
        # everyday parameters for SCSI with the 2 second delay
        setenv osargs " resumedev=/dev/sda2 root=/dev/sda1 waitforroot=2 rootfstype=ext4 ro"
      else
        # everyday parameters for USB
        setenv osargs " resumedev=/dev/sda2 root=/dev/sda1 rootfstype=ext4 ro"
      fi
   fi
fi

### finally, gluing it all together

# kernel command line
echo "--> kernel commandline:"
echo "--> ${slkconsole} ${bootcmd_generic} ${osargs} ${usrargs} <--"
setenv bootargs ${slkconsole} ${bootcmd_generic} ${osargs}

# passing control to kernel
echo "--> Passing controll to kernel:"
bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}

# here from You should be with Slackware setup or system
and the a bit more current & updated
bootedit:
Code:
#!/bin/sh

#wrapper for editing /boot.src
# ISC apply - support on Linuxquestions.org for Slackware ARM
# author: cest73@ya.ru
# version V1.1
# file /usr/sbin/bootedit
#

Editor='/usr/bin/mcedit'
Converter='/usr/bin/mkimage'
pars='-C none -A arm -T script'
tgt='/boot.scr'
src='/boot.cmd'


if [[ -x ${Editor} ]] ; then
if [[ -x ${Converter} ]] ; then
$Editor ${src} && $Converter ${pars} -d ${src} ${tgt}
else
echo "converter [${Converter}] not found! aborting."
exit 2
fi
else
echo "editor [${Editor}] not found! aborting."
exit 2
fi
echo "done."
 
Old 01-27-2017, 05:39 AM   #35
drmozes
Slackware Contributor
 
Registered: Apr 2008
Location: Surrey, England
Distribution: Slackware
Posts: 521

Rep: Reputation: 392Reputation: 392Reputation: 392Reputation: 392
Quote:
Originally Posted by SCerovec View Post
So, there is no mainline kernel in the 3.4.x series?
That's not how it works. The vendor kernels are usually a fork of a particular mainline version with tonnes of patches against it.
You take the entire kernel, not a small patch set. You could probably extricate the patches and apply them against a similar major version number, but it's not something I'd ever consider.
This sort of thing is something an individual would do, not something you'd include in the forward looking OS.

Quote:
And the various *bian-s are patchworks for particular devices (no same kernel across the various devices)?
Yep. Everyone's got their own fork on git hub and eventually they might get their changes mainlined.
 
Old 02-11-2017, 09:00 AM   #36
SCerovec
Senior Member
 
Registered: Oct 2006
Location: Cp6uja
Distribution: Slackware on x86 and arm
Posts: 1,080
Blog Entries: 2

Original Poster
Rep: Reputation: 130Reputation: 130
Arrow

Last time on H3 install series (short recap):
1. we primed the MMC/TF/SD card with SPL (i used a Class10 8GB) and a single partition
2. we prepared the USB volume (flash, thumb, 2.5" vith USB converter...) with Slackware-arm install media
3. we connected via the UART to the OPi-PC
4. plugged the MMC
5. Plugged the USB
6. Powered on and got to boot right into the Slackware setup - the same one used on x86.
7. I selected all but KDE/KDEi and after it begun i left for an hour (or so...)

TODO:
HDMI
quirks

P.S.
feedback: The ETH0 seems to register fine with OPi_PC v1.3 here
 
Old 02-11-2017, 10:49 AM   #37
SCerovec
Senior Member
 
Registered: Oct 2006
Location: Cp6uja
Distribution: Slackware on x86 and arm
Posts: 1,080
Blog Entries: 2

Original Poster
Rep: Reputation: 130Reputation: 130
Talking

The actual tested file that worked the boot for me:

file:/boot/boot.cmd
Code:
###
#
#  v0.5-beta (C) ISC cest73@ya.ru 2016 and onwards for Slackware ARM and U-BOOT
#
#  filename: boot.cmd
#
#  Generic (hopefully) Uboot script with templates for many scenarios
#  typical on-disk layout:
#  /boot/          for kernel and initrd
#  /boot/dtb/      for device tree files
#  /boot.scr       configuration for u_boot
#                  the last one generated from 
#  /boot.cmd       by
#
#  /usr/sbin/bootedit
#
###

echo '-->SlackwareARM U-boot helper script V0.5...'

###
#
# declaring the system layout for boot...
#
###

# uncomment only one of the two
#setenv mode 'setup'
setenv mode 'regular'

# enter for media :
# 'tftp'
# 'usb'
# 'sata'
# 'fel'
# 'mmc'
setenv media 'mmc'

#'serial' for the UART0
#'hdmi' for the HDMI port
#TODO 'composite'
#TODO 'ssh'
setenv interface 'serial'

#'auto' dhcp
#'172.32.16.0' our local address, then also set host below
#'none' no net during boot
setenv net 'none'
#setenv net '192.168.168.128'
# the IP of the tftp serving host
#setenv host '192.168.168.102'

# look in /boot/dtb/ for Yours
# for Banana PI:sun7i-a20-bananapi.dtb
# for Orange PI:sun8i-h3-orangepi-pc.dtb
setenv dtbfile 'sun8i-h3-orangepi-pc.dtb'

# for Banana PI add "sunxi_g2d_mem_reserve=0 sunxi_ve_mem_reserve=0"
setenv bootcmd_generic ' debug earlyprintk TERM=screen-256color 3'

# below this line WHERE THERE BE DRAGONS! (dont go!)

###
#
# defining the host specific parameters
#
###

setenv fdtfile "/boot/dtb/${dtbfile}"

# kernel is (mostly) always te same
setenv kernelfile '/boot/zImage-armv7'
if test $mode = 'setup'; then
   # for setup
   setenv setupfs '/boot/initrd-armv7.img'
else
   # for everyday
   setenv initrdfile '/boot/initrd-armv7'
fi

if test $media = 'tftp'; then
  setenv tftpfdtfile "slackwarearm-current/dtb/${dtbfile}"

  setenv tftpkernelfile 'slackwarearm-current/zImage-armv7'

  if test $mode = 'setup'; then
     # for setup
     setenv tftpsetupfs 'slackwarearm-current/initrd-armv7.img'
  else
     # for everyday
     setenv tftpinitrdfile 'slackwarearm-current/initrd-armv7'
  fi
fi

###
#
# defining the load addresses
#
###

# we change only for fel, otherwise we falback to tftp address
if test $media = 'fel' ; then
   # derived from UBOOT-FEL load address
   setenv fdt_addr_r 0x43000000
   setenv kernel_addr_r 0x42000000
   setenv ramdisk_addr_r 0x43300000
else
   # use this for tftfp setup
   setenv fdt_addr_r 0x43000000
   setenv kernel_addr_r 0x46000000
   setenv ramdisk_addr_r 0x47000000
fi

###
#
# crafting the file source commands
#
###

if test $media = 'tftp'; then
   echo "-->TFTP init:"
   # by tftpboot ..........refer how to setup in the install on Banana PI HOWTO
   # adjust to own TFTP server/host
   if test $net != 'auto'; then
      setenv serverip ${host}
      setenv ipaddr ${net}
   else
      # this is rather an parachute option ;)
      dhcpcd
   fi
   echo "-->Loading FDT"
   tftp ${fdt_addr} ${tftpfdtfile}
   echo "-->Loading kernel"
   tftp ${kernel_addr_r} $tftpkernelfile
   if test $mode = 'setup'; then
      echo "-->Loading setup ramdisk"
      # for setup
      tftp ${ramdisk_addr_r} $tftpsetupfs
   else
      echo "-->Loading initial ramdisk"
      # for everyday
      tftp ${ramdisk_addr_r} $tftpinitrdfile
   fi
else
   if test $media = 'fel'; then
      #for FEL we load via the cable O.o
      echo "-->FEL initiating"
   else
      if test $media = 'sata'; then
         echo "-->SATA/SCSI initiating"
         scsi reset
         scsi scan
      elif test $media = 'usb'; then
         echo "-->USB initiating"
         usb reset
         usb scan
      fi
      # except for fel, we load for mmc, usb and scsi/sata
      echo "-->Loading files from ${media} 0:1"
      load ${media} 0:1 ${fdt_addr_r} ${fdtfile}
      load ${media} 0:1 ${kernel_addr_r} ${kernelfile}
      if test $mode = 'setup'; then
         echo "-->Loading setup ramdisk"
         # for setup
         load ${media} 0:1 ${ramdisk_addr_r} ${setupfs}
      else
         echo "-->Loading initial ramdisk"
         # for every day
         load ${media} 0:1 ${ramdisk_addr_r} ${initrdfile}
      fi
   fi
   fdt addr ${fdt_addr_r} 0x40000
fi
###
#
# crafting the boot arguments
#
###

### initial output for OS

if test $interface = 'serial'; then
   # for serial console
   setenv slkconsole ' console=ttyS0,115200'
else
   # we asumeotherwise always or for HDMI
   setenv slkconsole ' console=tty1 disp.screen0_output_mode=EDID:1680x105060 hdmi.audio=EDID:0'
fi

### OS related parameters

if test $mode = 'setup'; then
   if test $net = 'auto'; then
      # setup with automatic network parameters
      setenv osargs " nic=auto:eth0:dhcp root=/dev/ram rw"
   else
      # setup with manual or special network setup
      setenv osargs " nodhcp root=/dev/ram rw"
   fi
else
   if test $media = 'mmc' ; then
      # everyday parameters for MMC/SD card
      setenv osargs " resumedev=/dev/mmcblk0p2 root=/dev/mmcblk0p1 rootfstype=ext4 ro"
   else
      if test $media = 'scsi' ; then 
        # everyday parameters for SCSI with the 2 second delay
        setenv osargs " resumedev=/dev/sda2 root=/dev/sda1 waitforroot=2 rootfstype=ext4 ro"
      else
        # everyday parameters for USB
        setenv osargs " resumedev=/dev/sda2 root=/dev/sda1 rootfstype=ext4 ro"
      fi
   fi
fi

### finally, gluing it all together

# kernel command line
echo "--> kernel commandline:"
echo "-->${slkconsole} ${bootcmd_generic} ${osargs} ${usrargs}<--"
setenv bootargs "${slkconsole} ${bootcmd_generic} ${osargs}"

# passing control to kernel
echo "--> Passing controll to kernel:"
bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}

# here from You should be with Slackware setup or system
I can try it with OPi_PC and Bpi (as i did).

@drmozes:
could we craft one general SPL+u_boot for all (or at least many) SBC to boot?

Last edited by SCerovec; 02-11-2017 at 01:14 PM. Reason: typo :S and random corruption?
 
Old 02-11-2017, 04:03 PM   #38
SCerovec
Senior Member
 
Registered: Oct 2006
Location: Cp6uja
Distribution: Slackware on x86 and arm
Posts: 1,080
Blog Entries: 2

Original Poster
Rep: Reputation: 130Reputation: 130
Heads-up:
I'm testing a boot-install script this weekend, will report back after few more tries.
 
Old 02-12-2017, 04:30 AM   #39
SCerovec
Senior Member
 
Registered: Oct 2006
Location: Cp6uja
Distribution: Slackware on x86 and arm
Posts: 1,080
Blog Entries: 2

Original Poster
Rep: Reputation: 130Reputation: 130
Lightbulb

I know the initrd is "bloaty" at ~45MB already, but couldn't we squeeze screen or tmux too?

Last evening i had installed the system (nth time in a row) and I really wanted to be able to "zap" back and forth, but being connected over an UART, i was not able to.

But had the installer's initrd included the screen/tmux ...

no?

Last edited by SCerovec; 02-12-2017 at 04:31 AM.
 
Old 02-12-2017, 11:27 AM   #40
drmozes
Slackware Contributor
 
Registered: Apr 2008
Location: Surrey, England
Distribution: Slackware
Posts: 521

Rep: Reputation: 392Reputation: 392Reputation: 392Reputation: 392
Quote:
Originally Posted by SCerovec View Post
I know the initrd is "bloaty" at ~45MB already, but couldn't we squeeze screen or tmux too?

Last evening i had installed the system (nth time in a row) and I really wanted to be able to "zap" back and forth, but being connected over an UART, i was not able to.

But had the installer's initrd included the screen/tmux ...

no?
I don't see the point. If you follow the documents I have written, you'll see that you use screen on the x86 connecting to the UART which is presented via a USB adapter: so you run screen on there instead.

ftp://ftp.arm.slackware.com/slackwar...L_ORANGEPI.TXT is mostly complete - I just want to make a USB version of the installer for all armv7 devices, rather than have to set up an environment with a tftp server.
The only problems are that the sun8i emac (NIC) driver is unstable and causes kernel panics under load. I've contacted the developer of the driver though.

Last edited by drmozes; 02-12-2017 at 11:31 AM.
 
Old 02-13-2017, 09:30 AM   #41
SCerovec
Senior Member
 
Registered: Oct 2006
Location: Cp6uja
Distribution: Slackware on x86 and arm
Posts: 1,080
Blog Entries: 2

Original Poster
Rep: Reputation: 130Reputation: 130
I'm glad there will be an unified USB way , could I help anyhow?

The point of having screen/tmux on board the install:

while letting install chew away it's ~5-6GB of /, one could fire up a new session and let top run for performance feedback?
Or, in case of network based install media, let netwatch if iftop track performance?

But since we running through the UART, the only way to "zap" terminals back and forth, is to have screen or tmux on the installer.

No matter what I have on the x86 (or whatever) the only way to have more than a single session on the installing machine, if using the UART method, is a multiplexer, screen being the older and better known, tmux being the newer, looking forward one?

Just a matter of performance tracking, I happen to miss?

On regular desktop ("KVM" type) installs I "zap" quite often and track performance or check logs etc...
 
Old 02-16-2017, 10:01 AM   #42
SCerovec
Senior Member
 
Registered: Oct 2006
Location: Cp6uja
Distribution: Slackware on x86 and arm
Posts: 1,080
Blog Entries: 2

Original Poster
Rep: Reputation: 130Reputation: 130
regarding the HDMI frame-buffer, /dev/fb0 and the desktop role of out H3 devices:
mailinglists

anyone familiar how to get that patch?
EDIT: got it! Now to test it...
see the 23k FAUX LOG attachment.

download, prune the .log and untar it for testing.

Warning: keep backups!
Attached Files
File Type: log H3-HDMI-fbdev-patchset.tar.gz.log (22.4 KB, 2 views)

Last edited by SCerovec; 02-16-2017 at 10:19 AM.
 
  


Reply

Tags
allwinner, kernel, mainline, slackware -current, uboot


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: Step By Step Ubuntu 13.04 (Raring Ringtail) LAMP Server Setup LXer Syndicated Linux News 0 09-12-2013 04:34 PM
Step by step configuration documents of FTP/DNS/MAIL/Appache/SAMBA sidharthasankar.raja Linux - Server 2 04-15-2010 06:31 AM
Step-By-Step Instruction to install Linksys WPC11 Ver.4 Wireless Card Zypher Linux - Hardware 8 08-12-2009 10:43 AM
LXer: Atticware Revisited: Step-By-Step Instructions For Installing A Current Linux Distro On A Very Small, Very Old Laptop LXer Syndicated Linux News 0 07-04-2006 09:54 AM
Step-by-Step: Making integrated Broadcome wireless adapter work with Mandrake 9.2 jmp875 Linux - Wireless Networking 16 06-30-2004 12:50 AM


All times are GMT -5. The time now is 01:17 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration