Re: Support for Marvell 88F5xx81 based routers

maddes.b wrote:

c) Crypto hardware (What config is needed for what device or for Orion in general?)

kmod-crypto-mv-cesa Cryptographic Engines and Security Accelerator for Marvell Orion and Kirkwood SoCs
r23383
Found via Seagate Dockstar Wiki

Netgear WNR854T (ARM Marvell Orion CPU 500MHz, Marvell 88W8361P mini-PCI STA only, 8/32MB) - trunk r17427 since 09/09/09 to 06-06-12 GLOD
TP-LINK TL-WR741ND v1.9 (Atheros AR7240 CPU 350MHz, Atheros AR9285 Chipset, 4/32MB) - trunk r23281 since 10/10/10
TP-LINK TL-MR3420 v1.1, TL-MR3220 v1.2 - trunk r25302 since 11/11/11
TP-LINK TL-WR842ND v1.0, TL-WR1043ND v1.8 - 12.09-rc1 since 12/12/12

Re: Support for Marvell 88F5xx81 based routers

The kmod-crypto-mv-cesa package was added by LarsC, and enabled for Orion on my request.
I worked this weekend on a Makefile cleanup for the Orion platform and included the crypto package.
See ticket #8154.

Re: Support for Marvell 88F5xx81 based routers

I added support for the leds and reset button on wnr854t. Ticket 8160.
I also began writing diag.sh scripts for all orions. Not final yet though.

I also did profiles in the buildsystem this weekend but I guess maddes.b beat me to it. Will try your patch.

929 (edited by maddes.b 2010-11-01 20:02:33)

Re: Support for Marvell 88F5xx81 based routers

I have done profiles too, but not included them into ticket #8154.
It's better to keep the change volume low, to get a faster commit to trunk and/or Backfire.
Also my profile change was not polished yet, I still have to create the correct Profile image rules (like used for the "adm5120" platform).

@Erik:
First it is always done for yourself to learn and get experience (my point of view).
And when several people try to solve the same the problem, then it is interesting to see where the solutions differ and to get new ideas.
Thanks for working on the LEDs.
Every addition to the Orion platform makes it more complete.

930 (edited by erik___ 2010-11-01 21:47:33)

Re: Support for Marvell 88F5xx81 based routers

I made a diag.sh for orions. Could someone with other HW then the wnr854t test it / comment on it before I commit.
If you wanna try it on wnr854t you will need the patch from ticket 8160.

#!/bin/sh
# Copyright (C) 2010 OpenWrt.org

#
# WNR854T have four states
#
# Solid Green :     Bootloader running, or kernel hung (timer task stalled)
# Solid Orange:     Normal operation
# Green blinkint:   Failsafe
# Orange blinking:  Preinit
#

#
# WRT350N v2 have two states
#
# Solid Green :     Bootloader running, kernel hung (timer task stalled), failsafe, preinit
# Solid Orange:     Normal operation
#

set_state() {

local wnr854t_blink="/sys/class/leds/wnr854t:blink:power/brightness"
local wnr854t_green="/sys/class/leds/wnr854t:green:power/brightness"
local wrt350nv2_orange="/sys/class/leds/wrt350nv2:orange:power/brightness"
local hardware=`sed -n /Hardware/s/.*:.//p /proc/cpuinfo`

    case "$1" in
        preinit)
            case "${hardware}" in
                'Netgear WNR854T')
                    [ -e $wnr854t_green ] && [ -e $wnr854t_blink ] && {
                        echo 0 > $wnr854t_green
                        echo 255 > $wnr854t_blink
                    }
                    ;;
                'Linksys WRT350N v2')
                    [ -e $wrt350nv2_orange ] && {
                        echo 0 > $wrt350nv2_orange
                            }
                    ;;
            esac
        ;;
        failsafe)
            case "${hardware}" in
                'Netgear WNR854T')
                    [ -e $wnr854t_green ] && [ -e $wnr854t_blink ] && {
                        echo 255 > $wnr854t_green
                        echo 255 > $wnr854t_blink
                    }
                    ;;
                'Linksys WRT350N v2')
                    [ -e $wrt350nv2_orange ] && {
                        echo 0 > $wrt350nv2_orange
                            }
                    ;;
            esac
        ;;
        done)
            case "${hardware}" in
                'Netgear WNR854T')
                    [ -e $wnr854t_green ] && [ -e $wnr854t_blink ] && {
                        echo 0 > $wnr854t_green
                        echo 0 > $wnr854t_blink
                    }
                    ;;
                'Linksys WRT350N v2')
                    [ -e $wrt350nv2_orange ] && {
                        echo 255 > $wrt350nv2_orange
                            }
                    ;;
            esac
        ;;
    esac
}

@maddes
I agree that that you do it for yourself.
The profiles that I made was only additions to the existing system. The cleanup looks better and good.

Re: Support for Marvell 88F5xx81 based routers

There is a official snapshot of kmod-crypto-mv-cesa for kirkwood, but not for Orion. Where should I push?

WRT350Nv2 doesn't allow LEDs to blink?

Netgear WNR854T (ARM Marvell Orion CPU 500MHz, Marvell 88W8361P mini-PCI STA only, 8/32MB) - trunk r17427 since 09/09/09 to 06-06-12 GLOD
TP-LINK TL-WR741ND v1.9 (Atheros AR7240 CPU 350MHz, Atheros AR9285 Chipset, 4/32MB) - trunk r23281 since 10/10/10
TP-LINK TL-MR3420 v1.1, TL-MR3220 v1.2 - trunk r25302 since 11/11/11
TP-LINK TL-WR842ND v1.0, TL-WR1043ND v1.8 - 12.09-rc1 since 12/12/12

932 (edited by maddes.b 2010-11-03 09:25:36)

Re: Support for Marvell 88F5xx81 based routers

kmod-crypto-mv-cesa was enabled for Orion with r23229 (back then with a wrong underscore).
Unfortunately sometimes Makefile changes require a `make distclean` or at least a clean-up of the tmp folder, so that the new settings are recognized by make.
Just create a defect ticket or send a notice to the developer mailing list.

Will do my own trunk build next weekend, so will look after this too.

Re: Support for Marvell 88F5xx81 based routers

#8167 sent.

Netgear WNR854T (ARM Marvell Orion CPU 500MHz, Marvell 88W8361P mini-PCI STA only, 8/32MB) - trunk r17427 since 09/09/09 to 06-06-12 GLOD
TP-LINK TL-WR741ND v1.9 (Atheros AR7240 CPU 350MHz, Atheros AR9285 Chipset, 4/32MB) - trunk r23281 since 10/10/10
TP-LINK TL-MR3420 v1.1, TL-MR3220 v1.2 - trunk r25302 since 11/11/11
TP-LINK TL-WR842ND v1.0, TL-WR1043ND v1.8 - 12.09-rc1 since 12/12/12

Re: Support for Marvell 88F5xx81 based routers

After several build-error rounds with "all packages" I updated my build recipe in Ubuntu as follow:
First time:

sudo apt-get -y install subversion g++ ncurses-term gawk flex patch openssh-server
sudo apt-get -y install minicom tftp tftpd gettext zlib1g-dev libssl-dev fastjar sdcc
cd ~
mkdir openwrt
cd openwrt
svn co svn://svn.openwrt.org/openwrt/trunk/

First time and subsequent updates:

cd ~/openwrt/trunk
svn up
./scripts/feeds update -a
./scripts/feeds install -a
make menuconfig
make -j8 download
make -j2 world
ls -la ~/openwrt/trunk/bin/orion/

But some packages unselected to accelerate process:

Requires jikes not available in newer Ubuntu repositories:
Languajes:Java:sablevm

Doesn't compile for whatever reason:
IPv6:send
Network:wireless:appweb
Network:vpn:strongswan4
Network:dsniff
Utilities:bemusedlinuxserver
Sound:mpd
Sound:mpdas

So unselect them after select "all packages"

What this does exactly?:

make package/symlinks
Netgear WNR854T (ARM Marvell Orion CPU 500MHz, Marvell 88W8361P mini-PCI STA only, 8/32MB) - trunk r17427 since 09/09/09 to 06-06-12 GLOD
TP-LINK TL-WR741ND v1.9 (Atheros AR7240 CPU 350MHz, Atheros AR9285 Chipset, 4/32MB) - trunk r23281 since 10/10/10
TP-LINK TL-MR3420 v1.1, TL-MR3220 v1.2 - trunk r25302 since 11/11/11
TP-LINK TL-WR842ND v1.0, TL-WR1043ND v1.8 - 12.09-rc1 since 12/12/12

935 (edited by erik___ 2010-11-11 01:43:09)

Re: Support for Marvell 88F5xx81 based routers

2.6.36 is out in master for orion.

It boots fine on wnr854t courtesy of the 8b22* commit. Second reboot generates a BUG though.

kernelroot@OpenWrt:/# kernel BUG at fs/inode.c:1244!
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c109c000
[00000000] *pgd=01091031, *pte=00000000, *ppte=00000000
Internal error: Oops: 817 [#1]

Have not looked in to it that much but http://linux.derkeiler.com/Mailing-Lists/Kernel/2008-03/msg01581.html seems to give some clues.
I would have looked in to it more if Angry birds would not have been adictive.

The RTC still seems be broken.

drivers/rtc/hctosys.c: unable to open rtc device (rtc0)

@Nilfred. No the leds on the wrt350tn2 does not blink to my knowledge.

936

Re: Support for Marvell 88F5xx81 based routers

you can give a try to this.

Re: Support for Marvell 88F5xx81 based routers

it is great to see that development for this platform hasn't stopped and that it seems that maddes.b
is back and pushing this project forward big_smile

Re: Support for Marvell 88F5xx81 based routers

As I said I will look into the project when time allows.
For the current process other people have to be credited, like Acoul, Kaloz, Nilfred and others.
Just trying to help out when time permits.

939 (edited by mrk 2010-11-15 22:57:48)

Re: Support for Marvell 88F5xx81 based routers

As baxter104 in Post #870 mentioned, we have two buttons at the wrt350nv2.
DirkNL added them in wrt350nv2-setup.c.

What I wanted to do, is to activate these buttons and integrate them into the OpenWrt package tools.

When You roam through "menuconfig", You will find these packages
* Kernel Modules -> other modules -> kmod-hotplug-button and
* Utilities -> wifitoggle
and many other kmods regarding GPIO and buttons.

Lets take a look at wifitoggle. It is a script for hotplug and toggles the wifi device.
You find it at /etc/hotplug.d/button/30-wifitoggle.
It also sets some uci - variables, starting with wifitoggle.

wifitoggle.@wifitoggle[0].button=wps

points at the button wps

So exactly want I want to use. Wifitoggle needs an adequate system message for button handling.
This delivers the package kmod-hotplug-button. It's an custom kernelmodule in OpenWrt.
It bases on diag.c for broadcom-routers, so I thought it's only for bcm and exactly; it doesn't work for the first try (and some much more).

So I started my journey into the linux platform- and driver model. I'm not a linux-pro, so it was not easy for me to understand all theses mechanism. And when You google around, You will find many solutions with custom GPIO driver for polling and so on.

In post #872 DirkNL explains, that the buttons can be found at /proc/interrups.
But Backfire r23797 only shows me:

          CPU0
  0:      16962   orion_irq  orion_tick
  3:         16   orion_irq  serial
 17:          0   orion_irq  ehci_hcd:usb1
 21:       1700   orion_irq  eth0
 22:       1135   orion_irq  mv643xx_eth
 28:          0   orion_irq  mv_crypto
 36:      15804  orion_gpio_irq  ath9k
Err:          0

no buttons at all in standard backfire.

Then I turned to trunk r23965, because there are some newer programs and some more improvements.

Digging deeper into the newest kernel 2.6.34, I found the kernel driver gpio-keys.
In theory this handles the declared gpio-buttons from wrt350nv2-setup.c.
But in reality, nothing happens.

I found out, that You can give the GPIO keys a key-type, so I added the .type = EV_SW,
because the buttons are in fact switches.

Heureka, first goal. Looking at /proc/interrups shows:

           CPU0
  0:       3450   orion_irq  orion_tick
  3:         14   orion_irq  serial
 17:          0   orion_irq  ehci_hcd:usb1
 21:        105   orion_irq  eth0
 22:        467   orion_irq  mv643xx_eth
 28:          0   orion_irq  mv_crypto
 34:          0  orion_gpio_irq  WPS Button
 35:          0  orion_gpio_irq  Reset Button
 36:          0  orion_gpio_irq  ath9k
Err:          0

So ups, gpio-keys bind the buttons to interrups.

Then I tried to integrate it into kmod-hotplug-buttons, but nothing happens. Maybe the broadcom restriction?
But I also could'nt find anything at cat /sys/devices/platform/gpio-keys/keys or switches.

Turning the WPS Button to type EV_KEY, lets them arrive at gpio-keys.
Second goal!

Finally, the hotplug mechanism fires and let the wifi led switch off.
Match won!!


My cookbook for trunk r23965:

patch the setup and add the key-type EV_KEY:

--- a/arch/arm/mach-orion5x/wrt350n-v2-setup.c
+++ b/arch/arm/mach-orion5x/wrt350n-v2-setup.c
@@ -74,11 +74,13 @@
     {
         .code        = KEY_RESTART,
         .gpio        = 3,
+        .type        = EV_KEY,
         .desc        = "Reset Button",
         .active_low    = 1,
     }, {
         .code        = KEY_WPS_BUTTON,
         .gpio        = 2,
+        .type        = EV_KEY,
         .desc        = "WPS Button",
         .active_low    = 1,
     },

Integrate the kernel module gpio-keys.
I decided to integrate it into the konfig-default at target orion, so patch:

--- target/linux/orion/config-default    (Revision 23967)
+++ target/linux/orion/config-default    (Arbeitskopie)
@@ -98,6 +98,10 @@
 CONFIG_I2C=y
 # CONFIG_IDE is not set
 CONFIG_INITRAMFS_SOURCE=""
+CONFIG_INPUT=y
+# CONFIG_INPUT_GPIO_BUTTONS=y
+CONFIG_INPUT_KEYBOARD=y
+# CONFIG_INPUT_MISC=y
 # CONFIG_IP6_NF_MANGLE is not set
 # CONFIG_IP6_NF_MATCH_EUI64 is not set
 # CONFIG_IP6_NF_MATCH_FRAG is not set
@@ -126,6 +130,15 @@
 # CONFIG_IWLWIFI_LEDS is not set
 # CONFIG_LANMEDIA is not set
 # CONFIG_LATENCYTOP is not set
+# CONFIG_KEYBOARD_ATKBD is not set
+# CONFIG_KEYBOARD_LKKBD is not set
+# CONFIG_KEYBOARD_MATRIX is not set
+# CONFIG_KEYBOARD_MCS is not set
+# CONFIG_KEYBOARD_NEWTON is not set
+# CONFIG_KEYBOARD_STOWAWAY is not set
+# CONFIG_KEYBOARD_SUNKBD is not set
+# CONFIG_KEYBOARD_XTKBD is not set
+CONFIG_KEYBOARD_GPIO=y
 CONFIG_LEDS_GPIO=y
 CONFIG_LEGACY_PTY_COUNT=256
 CONFIG_LEGACY_PTYS=y

Note, that kconfig needs the "is not set" lines, otherwise the build needs a userinput and can not run without "V=99".

Then choose Kernel Modules -> other modules -> kmod-hotplug-button in make menuconfig.
This package doesn't deliver a load_module script, so we have to add:

/etc/modules.d/65-hotplug-button

button-hotplug

or insmod button-hotplug.ko at comandline.


Please check it and comment, if we should realize this feature in this way.
Next step would be an adequate function to the reset button, maybe a firstboot function.

So, that's all ... for now.
Greetz mrk

@maddes.b nice to see you again, after this long time

Updates:
15.11.10 new patch for kernel 2.6.36

Re: Support for Marvell 88F5xx81 based routers

Nice to have buttons on wnr854t, too.
Standard behavior is to enter failsafe, not firstboot directly.

Netgear WNR854T (ARM Marvell Orion CPU 500MHz, Marvell 88W8361P mini-PCI STA only, 8/32MB) - trunk r17427 since 09/09/09 to 06-06-12 GLOD
TP-LINK TL-WR741ND v1.9 (Atheros AR7240 CPU 350MHz, Atheros AR9285 Chipset, 4/32MB) - trunk r23281 since 10/10/10
TP-LINK TL-MR3420 v1.1, TL-MR3220 v1.2 - trunk r25302 since 11/11/11
TP-LINK TL-WR842ND v1.0, TL-WR1043ND v1.8 - 12.09-rc1 since 12/12/12

941 (edited by maddes.b 2010-11-14 00:23:41)

Re: Support for Marvell 88F5xx81 based routers

@mrk:
Have a look at OpenWrt's makefiles if some packages already set these config settings. Quicker search possible with this script.
That web folder has some more scripts which I use to speed up my OpenWrt development and searches.

Re: Support for Marvell 88F5xx81 based routers

Btw put some work into the Wiki page for WRT350N v2, especially for the different flashing/recovery methods.
Please have a look and review/correct the text.

943 (edited by mrk 2010-11-25 09:46:13)

Re: Support for Marvell 88F5xx81 based routers

I just sent my wrt350nv2 to hell.

Yesterday I had some problems with "sysupgrade".
Don't know why, but my lan connection broke down and flashing fails.

After updating trunk this evening, I found a new patch for upslug2 with wrt350nv2.
My serial connection shows me a checksum error with kernel, so I thought just use upslug2 with --kernel option will bring it back.

I tried:
sudo ./upslug2 -d eth1 -t 00:1d:xx:xx:xx:42 --kernel=openwrt-wrt350nv2-uImage -e l

Upslug2 reboots the machine after flashing. And then I got not have eRcOmM .... enter download mode and flashing power-light on the wrt.
Fortunately we have the recovery-image, mentioned in the wiki.

I used

sudo ./upslug2 -d eth1 -t 00:1d:xx:xx:xx:42 --image=openwrt-wrt350nv2-squashfs-recovery.bin

and succeeded.


So maddes, I can confirm that using upslug2 with option --image recovers the wrt350nv2 safely.
[s]And never, never, never use option -e l. even if upslug2 will mention this.[/s]

Update:
25.11.2010 The cause of failure was not option "-e l", but option "--kernel" at all. Only use "--image" and recovery image.

See also post #953

944 (edited by maddes.b 2010-11-14 09:45:13)

Re: Support for Marvell 88F5xx81 based routers

Wiki for WRT350N v2 page updated accordingly.

945

Re: Support for Marvell 88F5xx81 based routers

Description for wrt350nv2 Ver 2.1.

The router reaches download mode:
   a) if eRcOmM is broken
   b) activating via reset button

Variant a) could usually not happen, if you use present OpenWrt and sysupgrade; but can happen if You use upslug2 in a wrong way. (see my last post)

In the net are many tutorials activating download mode for various router, but they all don't fit for my V2.1.

So the right way is:
   1. Unplug power-cable from the router
   2. Press the reset button at the backside
   3. Hold down reset button an power on the router
   4. wait about 1 second - but not longer than three second - and release the button
   5. Observe the power led. If it's blinking green/yellow, You are in download mode. If not - start again with no. 1.

When entering download mode, the router uses the mac address from U-Boot.
This is the one given by linksys and written on the label at the bottom of the router.

So the right mac usually starts with 00:1d...... which is the linksys id.
U-Boot does not use mac 00:00:00:00:51:81.

946 (edited by maddes.b 2010-11-14 12:42:47)

Re: Support for Marvell 88F5xx81 based routers

mrk wrote:

In the net are many tutorials activating download mode for various router, but they all don't fit for my V2.1.

What about the guideline from DaBigMac in this thread, linked as second post in the wiki. Was there anything wrong with it for 2.1?


mrk wrote:

When entering download mode, the router uses the mac address from U-Boot.
This is the one given by linksys and written on the label at the bottom of the router.

So the right mac usually starts with 00:1d...... which is the linksys id.
U-Boot does not use mac 00:00:00:00:51:81.

Correct. Tested with my testing device. Fixed on Wiki page.
The "ethaddr" setting in U-Boot only matters for OpenWrt/Linux not U-Boot (modified build by Linksys).

Maddes

947 (edited by mrk 2010-11-14 17:54:00)

Re: Support for Marvell 88F5xx81 based routers

maddes.b wrote:

What about the guideline from DaBigMac in this thread, linked as second post in the wiki. Was there anything wrong with it for 2.1?

I think, that waiting for the lan led, could be to late.
U-Boot recognizes, if You power on with reset button pressed. -> Shows You at serial output.
Than it counts down the three seconds.

In this time period (3, 2, 1, ...), You have to release the reset button to enter the download mode.
Releasing later, U-Boot boots the kernel and doesn't take care of the reset button anymore.

DaBigMac wrote about the two seconds, too, but he is waiting for the lan led.
I would say, when You see the power led, just release the reset button.

He, who releases too late, will be punished by power led.
little joke, with a good known cite wink


Btw, maddes, You really know ever corner in this thread, don't you!
As is explained it in the last post, I just read the wrong way on the upslug2 page.

Regarding the different flashing and recovering methods,
I would say, that writing an squash image in U-Boot to flash is an historic path. (Yes I know, I myself explained it last year!)
And should not be recommended, because of the many pitfalls.

Nowadays, I would prefer using upslug2, because You don't need the serial connection.
Or a ramdisk image tftp and bootm it and then use sysupgrade with squash image.

And what about a section with settings for make menuconfig ?
For instance, I ran into a kernel boot error deselecting libgcc.

The other system components needed by wrt350nv2 should be explainted, too.
kmods for led, buttons, crypt, wlan(ath), etc.

Maybe we can discuss a perfect plattform-config for wrt350nv2/orion.

mrk

948 (edited by maddes.b 2010-11-14 21:18:49)

Re: Support for Marvell 88F5xx81 based routers

First: when looking for WRT350N v2 related, read the wiki page and this thread, not some obscure upslug2 page smile

Booting a ramdisk build via TFP and then do a sysupgrade implies the same requirements as flashing directly in U-Boot. No big difference to me.
But this way could be added to the wiki page too.

Upslug2 with WRT350N v2 support is not available for Windows (like my desktop and the one of most end users), so maybe not the preferred way for the majority of users. Definitely a nice way for developers (remember you have to build it yourself).
Another question when can you use Upslug2 to flash? Always? Or only in Download mode and/or U-Boot and/or OpenWrt/Linux?

The perfect platform config should go to trunk and not to a wiki page. Also this may change from kernel release to kernel release.
Of course the Orion config should be discussed here (e.g. what about CONFIG_OPTIMIZE_FOR_SIZE for the subtarget "generic" (=WRT350Nv2 & WNR854T)).

949

Re: Support for Marvell 88F5xx81 based routers

I opened Ticket #8271 for gpio-button patch.
Hope it will be accepted.

@maddes
Upslug2 is only for download mode.
I inspected stock sources from linksys/cisco and found out, that there is a binary from linksys in u-boot to add on this functionality. So it is no origin u-boot feature.

You will find the wrt350nv2 with upslug2 when adding patch

--- a/nslu2_upgrade.cc
+++ b/nslu2_upgrade.cc
@@ -10,6 +13,7 @@
 namespace NSLU2Upgrade {
     /* Hardware ID field, add others as required. */
     static const unsigned char NSLU2ID0[][32] = {
+        {0x59, 0x42, 0x50, 0x00, 0x01, 0x10}, /* WRT350N V2.1 */
         {4, 112, 49, 149, 88, 16}, /* remainder 0 */
         {0x44, 0x47, 0x38, 0x33, 0x34, 0x56, 0x33},  /* remainder 0 */
         0

Just start upslug2 without parameters or with -d - param an You will see the router.
Well it is still named as NSLU, because I didn't changed this.

In wiki I overwrote "getting in download mode", because it's in the section for windows wink
Would be better to shift it at the headline download mode.
There is no need to port upslug2 to windows, I think Upgrage_207_XP is the equivalent.


Today, again I ran into the "kernel exceeds mtd bounds" error.
Kernel was too big and rootfs could not be created.
Maybe it would be a nice idea to add a "touch KERNEL_IS_TO_BIG" warning in bin-dir.
Well, I try a new config.

950 (edited by maddes.b 2010-11-18 23:56:43)

Re: Support for Marvell 88F5xx81 based routers

#1 big kernel
I only get a too big kernel when I compile with symbols enabled.
For a fix see #8183 and its patch trunk_orion_flexible_kernel_mtd_support.patch.


#2 download mode
Yes, download mode is a LinkSys modification, as are the SERCOM marker checks.


#3 upslug2 wrt350n v2.x support
Can you also add name support to it? This would be worth to commit to trunk.


#4 Upgrage_207_XP
Does not work on my Win7 x64 sad
And setting up a virtual machine with bridged network may not be an easy task for the average user.
Maybe a x86 Linux binary for download may work on a Knoppix/Ubuntu/Debian/etc. Live CD.


#5 Wiki
Do not see any change on the Wiki page.
But the move of them points up for fit better, additionally some typos should be fixed.
Update: Wiki page updated accordingly. Please review/edit.