piCore-7.0rc2

[bmarkus]

Team Tiny Core is pleased to announce the availability of piCore-7.0rc2, the second release candidate of the Raspberry Pi port of Tiny Core Linux (TC). Changes in this release:

piCore-7.0rc2

* udev rule (98-tc.rules) to handle USB storage devices added back


piCore-7.0rc1

* MicroPython updated to 1.5.1-162
* firmware updated to 19-dec-2015


piCore-7.0beta1

* kernel updated to 4.1.13
* GCC updated to 5.3.0
* MicroPython updated to 1.5.1-72
* SHOWAPPS boot code works now
* copy2fs.flg works now
* KERNEL substitution in onboot.lst works now
* USB device recognition is enhanced
* unified armv6/armv7 SD card image

The most important change is that the same SD card image now works with armv6 (RPi1) and armv7 (RPi2) boards. It comes with SSH server and mc (Midnight Commander) preinstalled. From now only one image is available per version.


piCore-7.0alpha8

* kernel updated to 4.1.12
* MicroPython updated
* RPi firmware updated
* BusyBox updated to 1.24.1
* cliorx synced to common TC base
* copy2fs.flg implemented


piCore-7.0alpha7

* kernel updated to 4.1.8
* MicroPython updated to 1.4.6
* fixed tce-load loop mounting bug on armv6


piCore-7.0alpha6:

* bug fixes
* BusyBox pstree added to base


piCore-7.0alpha5:

* kernel updated to 4.1.7
* new USB sound cards enabled

From now openssl-1.0.1.tcz replaced with openssl.tcz which is the latest 1.0.2d upstream with SSLv2/SSLv3 disabled. Packages using openssl are partly rebuilt remaining will be rebuilt.

python3.tcz renamed to python3.4.tcz and python3.5.tcz added to repo.


piCore-7.0alpha4:

* util-linux updated to 2.7
* BusyBox mount/umount replaced with util-linux
* new, faster startup tcz loader (copy to RAM is not yet supported)


piCore-7.0alpha3:

* kernel updated to 4.1.6
* must have kernel modules moved to kernel
* HDMI audio patched to support 192kbs audio
* ext4 file system encryption enabled
* Mediatek WiFi adapters supported
* New audio DAC added
* default CPU speed governor changed to performance
* Core scripts updated to TC 6.4 level


piCore-7.0alpha2:

* Core scripts updated to latest common script base
* significantly reduced startup time
* new motd/penguin
* MicroPython updated, heap size increased to 1M from 128k


piCore-7.0alpha1:

* kernel 4.1.4
* glibc 2.22
* BusyBox 1.23.2
* gcc 5.2.0
* e2fsprog 1.42.13
* util-linux 2.26.2

This version supports the RPi CM (Compute Module).

As a new feature Micro Python added to base. It is a small footprint version of Python 3.4 developed for embedded systems, ideal for scripting tools replacing shell.


Download links:

http://tinycorelinux.net/7.x/armv7/test_releases/ - for RPi2
http://tinycorelinux.net/7.x/armv6/test_releases/ - for all other boards

Only the SSH version is offered. If you want GUI, install TC.tcz from the repo. To get the base system with cloud mode, no persistent storage just delete the second partition, /dev/mmcblk0p2 on the SD card.


Notes:

To enable special devices and interfaces check config.txt file and read https://github.com/raspberrypi/firmware/blob/master/boot/overlays/README

The final notice, don't forget to expand /dev/mmcblk0p2 before adding extensions, as described in README.

[Paul_123]

On a rpi2, when doing a warm boot, about half of the time, the reboot process finishes with out mounting the tce partition.  (which is the only partition that I have on this box) 

Other observation, I upgraded from 7.0b1 to 7.0rc2   doing an inplace upgrade.  This sd card had the old openssh-1.0.1.tcz still laying around on it.    this extension was getting loaded rather than the proper openssh.tcz, so opensshd was not starting.

once I removed the old extension from the disk, the proper extension is now being loaded. 

[bmarkus]

On a rpi2, when doing a warm boot, about half of the time, the reboot process finishes with out mounting the tce partition.  (which is the only partition that I have on this box) 

When it is not mounted, do you see something interesting in dmesg?

[Paul_123]

Nope,

Both Boot processes are identical, up to the point where the disk actually gets mounted.   both good and bad boots recognize card and both partitions at about 1.45 seconds.   At the end of the bad boot cycle, /etc/fstab has all of the partitions listed, just nothing mounted.    syslog had nothing extra to say.

where in the boot process does it actually mount the tce partition?

I can break it every time by adding the boot param "nofstab"   yet when that boot code is active, the fstab is still properly populated with the partitions.

[Paul_123]

I had some time to play with this.    I remade the initrd making a change to tc-config.

(Note I removed the extra commented out lines)

/sbin/udevd --daemon 2>&1 >/dev/null
/sbin/udevadm trigger --action=add 2>&1 >/dev/null &
/sbin/udevadm settle

Adding the settle command fixed the problem.....   we could probably remove the "&" from the trigger action to let it finish before going on........ not sure which way is faster.  Adding the settle did add about 0.1 sec to the boot time.

[bmarkus]

Paul,

thanks. It looks OK, I will add settle in next release.

Béla

[Paul_123]

Paul,

thanks. It looks OK, I will add settle in next release.

Béla

I tested removing the "&" from the trigger line....works just the same.  but does appear to be slightly slower. 

While your in there, take a look at the nofstab command line option.....note the location of 98-tc.rules   The last update broke the intention of the nofstab command line switch.

[bmarkus]

Thanks, fixed in rc3

[Paul_123]

These rpi2's execute commands so fast, I've ran into another problem.

The hostname is set in bootsync.sh,  the hostname is not getting set before udhcpc runs on the eth0 interface.  So the device is just showing up on my router as "box" instead of its proper name.

This is the end of tc-config

Code: [Select]

# After restore items
if [ -n "$NODHCP" ]; then
        echo "${GREEN}Skipping DHCP broadcast/network detection as requested on boot commandline.${NORMAL}"
else
        [ -z "$DHCP_RAN" ] && /etc/init.d/dhcp.sh &
        [ -z "$NORTC" ] || /etc/init.d/settime.sh &
fi

[ -n "$CRON" ] && /etc/init.d/services/crond start

/sbin/loadcpufreq 2>/dev/null &

/opt/bootsync.sh

Since the restore is already done, do we move bootsync to happen first.   Or do we just put a small trap in dhcp.sh to make sure it waits for bootsync to run before running udhcpc......

[jgrulich]

It's enough to execute the hostname set before the udhcp, not need to run whole bootsync.sh. Otherwise the bootsync.sh need to be run separately from bootlocal.sh to be sure that bootlocal.sh is run after udhcp is executed when whole boot process is finished. In my case i make a lot of different operations with the network in the bootlocal.sh.

[Paul_123]

It's enough to execute the hostname set before the udhcp, not need to run whole bootsync.sh. Otherwise the bootsync.sh need to be run separately from bootlocal.sh to be sure that bootlocal.sh is run after udhcp is executed when whole boot process is finished. In my case i make a lot of different operations with the network in the bootlocal.sh.

Definitely a race track.   The question is where you edit and save the host name, right now we edit bootsync.sh. 

[bmarkus]

Set host name in cmdline

[Paul_123]

Set host name in cmdline

I suppose, it's just much easier to use the setting in bootsync.sh

Setting the hostname in bootsync makes upgrading multiple pi's easier.    The boot partition is the same on all of my pi's, all of the data is in the backup.

[Rich]

Hi Paul_123
This is from the X86 version under TC4 so I don't know if it's valid under PI. In tc-config:

Code: [Select]

# Here we check all the boot parameters using the fastest way known to men, case & loop
echo -n "${BLUE}Checking boot options...${NORMAL}"
for i in `cat /proc/cmdline`; do
case $i in
*=*)
case $i in
waitusb*) WAITUSB=${i#*=} ;;
lang*) LANGUAGE=${i#*=} ;;
kmap*) KEYMAP=${i#*=} ;;
tz*) TZ=${i#*=} ;;
desktop*) DESKTOP=${i#*=} ;;
icons*) ICONS=${i#*=} ;;
user*) USER=${i#*=} ;;
home*) MYHOME=${i#*=} ;;
tcvd*) TCVD=${i#*=} ;;
opt*) MYOPT=${i#*=} ;;
swapfile*) SWAPFILE=${i#*=} ;;
resume*) RESUME=${i#*=} ;;
host*) HOST=1 ;;
---------------- Snip ------------------It appears to check if the  host  boot code exists. Then further down:

Code: [Select]

if [ -n "$HOST" ]; then
sethostname
else
/bin/hostname -F /etc/hostname
fiIt looks like if you set the hostname in  /etc/hostname  and back it up, it will be used if the  host  boot code exists.

[Greg Erskine]

The hostname is set in bootsync.sh,  the hostname is not getting set before udhcpc runs on the eth0 interface.  So the device is just showing up on my router as "box" instead of its proper name./quote]

Hi Paul_123,

I can confirm this behaviour but it's been around for quite a while. The solution was to add hostname to cmdline.txt.

I don't like the way $HOST was also used in get_app routine.

regard
Greg