mikeh49 Wrote:

> I don't know if this is the best place to do this,
> but it works.

I think this is better:

fw_setenv bootcmd_stock 'setenv mainlineLinux no; echo Booting stock ...; run bootcmd_ide'

Also, set_bootargs_stock as is produces an error when executed (e.g. while in uboot, type "run set_bootargs_stock" and you will see it). As far as I can tell, it should look like this to avoid the error:

setenv set_bootargs_stock 'setenv bootargs console=ttyS0,115200 mtdparts=spi_flash:0x7f000@0(uboot),0x1000@0x7f000(u-boot-env) root=/dev/sda1 rw'

It doesn't really matter though because when bootcmd_ide gets called later it changes bootargs again to bootargs_console. :)

Also, I've noticed that after I run "protect off all" once, it seems to remain off and I don't have to run it every time to change the environment from Debian.

Neal

> Also, I've noticed that after I run "protect off
> all" once, it seems to remain off and I don't have
> to run it every time to change the environment
> from Debian.

Right! that's the intent in the Intstallation post above (it appears only once in the steps and not at all in Post-Installation).

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

@Neal - that's a much better place, makes good sense. I'll wait until the community coalesces on a location before tackling the pleasure of long u-boot command lines on Putty with a serial connection.

@Bohdi - so the protect off is "forever"? Or does it revert to on at the next boot? Hence the need to immediately set them permanently in Debian.

Mike,

Quote

Right! that's the intent in the Intstallation post above (it appears only once in the steps and not at all in Post-Installation).

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

OK let's try this.

In serial console:

setenv set_bootargs_stock 'setenv mainlineLinux no; setenv bootargs_console console=ttyS0,115200 mtdparts=spi_flash:0x7f000@0(uboot),0x1000@0x7f000(u-boot-env) root=LABEL=root rw'

In Debian:

fw_setenv set_bootargs_stock 'setenv mainlineLinux no; setenv bootargs_console console=ttyS0,115200 mtdparts=spi_flash:0x7f000@0(uboot),0x1000@0x7f000(u-boot-env) root=LABEL=root rw'

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

@bodhi,

That got it!

BTW now that I've disabled preview generation in Nextcloud, performance is quite good! I need to go through a clean installation now to document all the steps. I consulted various pages getting it installed and working and I'd like to pull all the pieces together to document the process thoroughly.

With this much RAM there's plenty of headroom for running other services as well if desired.

Neal

Some pictures on replacing the 16GB SSD to a normal 2.5" hard drive.

Remove two screws only...

Pull the SSD out.

...Continued...

SSD now removed...

Put the 2.5" HD in.

The Hard Drive was not in perfect horizontal position because of the two screw holders... Next step will cut some of these screw holders to make it shorter until the hard drive is in horizontal position, then put some double sided sticky pads on the cover of the M300 which will contact the hard drive to secure the hard drive.



Edited 1 time(s). Last edit at 09/09/2019 10:05AM by daviddyer.

About SATA boot

1 Copy the USB file system to the SATA hard drive. (Name it rootfs, ext3, one partition, MBR only. NO GPT. IF the hard drive was GPT, install gdisk in Bodhi's root file system and convert it to MBR).
2 Change the USB file system to something like roootfs. (We don't want two rootfs)
3 With serial cable on, power on, interrupt auto boot, then

run kernel_config
run set_bootargs
ide reset
ext2load ide 0:1 $(load_uimage_addr) /boot/uImage
ext2load ide 0:1 $(load_initrd_addr) /boot/uInitrd
bootm $(load_uimage_addr) $(load_initrd_addr)

System should boot from the new SATA hard drive.


In debian, run

fw_setenv bootcmd_ide2 'ide reset; ext2load ide 0:1 $(load_uimage_addr) /boot/uImage; ext2load ide 0:1 $(load_initrd_addr) /boot/uInitrd; bootm $(load_uimage_addr) $(load_initrd_addr)'

fw_setenv bootcmd 'run kernel_config; run set_bootargs; run bootcmd_ide2; run bootcmd_exec'

Now undefine set_bootargs_stock and bootcmd_stock, etc. Since we don't have it anyway...

sync, shut down, remove the USB, power on again to test boot from SATA.



Edited 1 time(s). Last edit at 09/09/2019 09:53AM by daviddyer.

Samba performance is not so bad... Anyway, M300 has a faster CPU and SATA...

Single 4GB file.

W for write
R for read



Edited 1 time(s). Last edit at 09/09/2019 10:00AM by daviddyer.

David,

Very well done :) I'll add it to the Wiki hardware mod.

What about the bottom side the SATA drive? ie. do we need some pad on that side so the drive is more securely stay fixed when moving the unit or standing it on the edge (I would keep it this way to get more air flow).

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Well, we don't need to remove the two screw holders completely. Actually, most of them should still be kept to make the new hard drive rest in horizontal position. So there should be enough air flow for the hard drive.



Edited 1 time(s). Last edit at 09/09/2019 06:43PM by daviddyer.

Here's an SSD in the M300. I think you would definitely need a pad on the bottom cover to hold the drive in position; when the enclosure is right side up, the drive hangs down from the connector. There might be another way to secure it; duct tape? It sits pretty level on the 2 screw posts. Or, if you could get adapter/extender cables the drive could be located and secured differently.

Mike,

> when the enclosure is right
> side up, the drive hangs down from the connector.
> There might be another way to secure it; duct
> tape? It sits pretty level on the 2 screw posts.

Not duct tape! I think you could use three 1-or-2-inch-thick pieces of dark gray foam cushion, not sure what's called :). The type that is used in some some computer retail boxes. That way each can be pulled out easily, but each is snuggly fit in between the SDD/HDD and the case (3 pieces for 3 sides).

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 2 time(s). Last edit at 09/09/2019 11:47PM by bodhi.

One last topic on this box. It is not important, but would be nice to find out where the LED(s) is, and which GPIO controls that LED.

In stock OS

root@dellkaceM300:~# ll /sys/class/leds/
total 0
lrwxrwxrwx 1 root root 0 Sep 11 08:59 orange -> ../../devices/platform/leds-gpio/leds/orange
lrwxrwxrwx 1 root root 0 Sep 11 08:59 white -> ../../devices/platform/leds-gpio/leds/white

The above means there is at least one controllable LED light, and it could be turned on as White or Orange.

Update:

Ah. There is a Status LED on the rear side of this box. Such an odd location, I guess it is good to hide it in a home theater :)

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 2 time(s). Last edit at 09/11/2019 05:32AM by bodhi.

It would be nice if we could have this on when successfully booted. Now it blinks very rapidly. Tape is a solution, of course, but would be nice to know at a glance that it is indeed running. I have a 120G SSD on the way for use as a music server, replacing a Pogo E02 and a USB hard drive.

bodhi Wrote:
-------------------------------------------------------
> One last topic on this box. It is not important,
> but would be nice to find out where the LED(s) is,
> and which GPIO controls that LED.

How do we go about figuring this out? In Debian I see:

root@Gilrain:/sys/firmware/devicetree/base/gpio-leds# ls -l
total 0
drwxr-xr-x  3 root root  0 Sep 11 11:19 .
drwxr-xr-x 10 root root  0 Sep 11 11:19 ..
-r--r--r--  1 root root 10 Sep 11 11:19 compatible
-r--r--r--  1 root root 10 Sep 11 11:19 name
-r--r--r--  1 root root  4 Sep 11 11:19 pinctrl-0
-r--r--r--  1 root root  8 Sep 11 11:19 pinctrl-names
drwxr-xr-x  2 root root  0 Sep 11 11:19 white-sys
root@Gilrain:/sys/firmware/devicetree/base/gpio-leds# cd white-sys/
root@Gilrain:/sys/firmware/devicetree/base/gpio-leds/white-sys# ls -l
total 0
drwxr-xr-x 2 root root  0 Sep 11 11:19 .
drwxr-xr-x 3 root root  0 Sep 11 11:19 ..
-r--r--r-- 1 root root 12 Sep 11 11:19 gpios
-r--r--r-- 1 root root 15 Sep 11 11:19 label
-r--r--r-- 1 root root 11 Sep 11 11:19 linux,default-trigger
-r--r--r-- 1 root root 10 Sep 11 11:19 name
root@Gilrain:/sys/firmware/devicetree/base/gpio-leds/white-sys#

Not sure if that's even relevant to anything though. Any tutorials available to figure this out? Something along the lines of this maybe?

Neal



Edited 2 time(s). Last edit at 09/11/2019 12:52PM by nwestfal.

Neal,

> Not sure if that's even relevant to anything
> though. Any tutorials available to figure this
> out? Something along the lines of
> this
> maybe?
>

I had this in the Wiki:

Quote

How to control GPIO in Linux userspace for GPIO-enable fan

https://forum.doozan.com/read.php?2,12096,35663#msg-35663

That OpenWrt script is close. But it's needed to be modified.

Try the procedure, but don't set GPIO 41 (it is the power off GPIO!)

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 09/11/2019 02:10PM by bodhi.

Warning:

When brute force GPIO like this, Unplug your SSD/HDD if it has anything important on it.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bodhi Wrote:

> That OpenWrt script is close. But it's needed to
> be modified.
>
> Try the procedure, but don't set GPIO 41 (it is
> the power off GPIO!)

Oops had already run the script before I saw your post!

GPIO41 gave this error as did GPIO6:

/scripts/test_gpio: 8: echo: echo: I/O error

It doesn't seem to have hurt anything!

Anyway, it looks like GPIO37 turns the LED orange and GPIO38 turns it white. Not sure how to make it blink.

root@Gilrain:/sys/class/gpio# echo 0 > gpio37/value # turn orange led on
root@Gilrain:/sys/class/gpio# echo 1 > gpio37/value # turn orange led off
root@Gilrain:/sys/class/gpio# echo 0 > gpio38/value # turn white led on
root@Gilrain:/sys/class/gpio# echo 1 > gpio38/value # turn white led off

Neal



Edited 1 time(s). Last edit at 09/11/2019 02:38PM by nwestfal.

> root@Gilrain:/sys/class/gpio# echo 0 >
> gpio37/value # turn orange led on
> root@Gilrain:/sys/class/gpio# echo 1 >
> gpio37/value # turn orange led off
> root@Gilrain:/sys/class/gpio# echo 0 >
> gpio38/value # turn white led on
> root@Gilrain:/sys/class/gpio# echo 1 >
> gpio38/value # turn white led off
>
> Neal

Cool! I'll be back. Wiill explain the blinking.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 09/11/2019 02:47PM by bodhi.

The blinking you saw was set by stock uboot.

In Debian, the blinking is controlled by one of the triggers. You can hack it, but it is best waiting for me to upload a new DTB. After that the LED can be controlled by its trigger name. Ie, white or orange.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hold on. I'll post the test later.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 3 time(s). Last edit at 09/12/2019 04:24AM by bodhi.

Here is the new DTB. This DTB has the default White LED turned on when the kernel has booted successfully.


Recreate your new uImage in /boot with this new DTB. Reboot the system.

Log in Debian

Turn on/off white LED

echo default-on  > /sys/class/leds/m300\:white\:sys/trigger
echo none > /sys/class/leds/m300\:white\:sys/trigger

Turn on/off orange LED

echo default-on  > /sys/class/leds/m300\:orange\:sys/trigger
echo none  > /sys/class/leds/m300\:orange\:sys/trigger

Blinking heartbeat

echo heartbeat  > /sys/class/leds/m300\:orange\:sys/trigger 
echo heartbeat  > /sys/class/leds/m300\:white\:sys/trigger

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

@bodhi,

Very nice! Tested fine.

Neal

Take a couple of days and nights off, bohdi. I have the M300 booting from the internal flash drive with a solid white light and no serial intervention. i think we're ready to put this thing to work. Thanks also to Neal and David.

I saw a random blog post suggesting the SOC of this device might support sata port multiplication through it's single connector. I don't have current access to my 4 disk port multiplication compatible external box. Anybody have the means to try this? Was thinking this could be turned into the brains of a half decent NAS with the speed it seems to have. You would need to cut a hole is the box to provide an ESATA feed and also have a 2 or 4 disk port multiplication compatible box (available for less than $125 US IIRC). Kinda cool if it works.



Edited 2 time(s). Last edit at 09/13/2019 02:50PM by LeggoMyEggo.

LeggoMyEggo,

Check your PM.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Now that we have the M300 running well, I'd like to install the Logitech Media Server. But, there seems to be no meaningfull instructions for Debian Buster; the best I can find is the wiki here for Jessie. So, can we run this new M300 kernel with a Jessie or Stretch filesystem? I'll search the Kirwood filesystem thread for Jessie, but perhaps someone knows which version it is. Also, what is the drawback/concern with running an older version? My Pogo players are on Wheezy and Jessie.

Mike,

The release thread:
https://forum.doozan.com/read.php?2,12096

Scroll down to:

Quote

Updated 24 Jul 2017:

Basic Debian stretch Kirkwood rootfs for most Kirwood plugs:

- tarball size: 188M
- install size: 488M
- The init system used in this rootfs is sysvinit . To boot with systemd, see note 2 below.
- Installed packages: nano, avahi, ntp, busybox-syslogd (log to RAM), htop, isc-dhcp-client, dialog, bzip2, nfs server/client, iperf, ethtool, sysvinit-core, sysvinit, and sysvinit-utils.
- see LED controls in /etc/rc.local, and /etc/init.d/halt
- see some useful aliases in /root/.profile
- root password: root

Download at Dropbox:

Debian-4.12.1-kirkwood-tld-1-rootfs-bodhi.tar.bz2

The thread got too long, so I had to remove the stretch release note. Here reposted:

Quote

Updated 20 Feb 2016:

This Debian-4.4.0-kirkwood-tld-1-rootfs-bodhi.tar.bz2 is to keep in sync with kernel Linux-4.4.0-kirkwood-tld-1.

Basic minimal Debian Kirkwood rootfs for most Kirwood plugs:

- tarball size: 137M
- install size: 398M
- a basic jessie rootfs.
- The init system used in this rootfs is sysvinit . To boot with systemd, see note 2 below.
- Installed packages: nano, avahi, ntp, busybox-syslogd (log to RAM), htop, isc-dhcp-client, dialog, bzip2, nfs server/client, iperf, ethtool, sysvinit-core, sysvinit, and sysvinit-utils.
- see LED controls in /etc/rc.local, and /etc/init.d/halt
- see some useful aliases in /root/.profile
- root password: root

Download at Dropbox:

Debian-4.4.0-kirkwood-tld-1-rootfs-bodhi.tar.bz2
md5:
9f957e1dc5a36f90a285ab4615cb02fd
sha256:
d33349118e34bd078ca635cd2d6776f3e312accfc77d29da5870b9980add5c36

And remember to check the hash of what you download, as always.

Just copy the latest M300 DTB to the jessie ot stretch rootfs /boot/dts and it will work.

===

Later, I will repost the older kernel notes in the next post in that release thread.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 2 time(s). Last edit at 09/13/2019 06:53PM by bodhi.