Tiny Core Linux
Tiny Core Base => Raspberry Pi => piCore Test Releases => Topic started by: bmarkus on November 04, 2015, 01:23:50 AM
-
Team Tiny Core is pleased to announce the availability of piCore-7.0alpha8, the Raspberry Pi port of Tiny Core Linux (TC) for RPi2 (armv7) and armv6 boards. Changes in this release:
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.
-
Thanks Bela,
Micropython and i2c-tools in busybox are what I use the most :D
Having some issues with putty and filezilla/sftp.
Getting network errors, suspect openssh?
Could also be my work network, will test some more over the weekend on my home network.
Regards
Gavin
-
I'm using RPi's remotely 98% of time accessing with PUTTY and WINSCP from WINDOWS or mc from othe LINUX machine (CentOS) without seeing any network error. Must be a local issue.
-
Yep, I suspect it maybe a local network issue.
But is is strange, I have a box running 7alpha3 that is on the same network that runs fine.
More testing on the weekend.
Could be websocktd server on the alpha3 box is hammering the network?
Will drag out some network tools
-
Switched off the alpha3 box, now the Alpha8 is working fine.
hmm it might explain some raspbian/internet update issues as well.
Maybe websocketd is not too stable?
Time to really understand websocket stuff and fix it.
Before the network guys find me :o
-
Hi Bela.
I have been testing both RPi and RPI2 versions. Both are working fine.
Audio is working
Wifi is working
copy2fs is working
The only issue (change) I have seen is that showapps in cmdline.txt have no effect. I can't see the loading of the modules during the boot process:
This is my cmdline.txt:
tz=CET-1CEST,M3.5.0,M10.5.0/3 dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=/dev/ram0 elevator=deadline rootwait nortc loglevel=3 noembed smsc95xx.turbo_mode=N noswap showapps cron
Steen
-
Just noticed that you have this in config.txt which is not needed and should be deleted:
#device_tree_overlay=hifyberry-dac
#device_tree_overlay=hifiberry-dacplus
#device_tree_overlay=hifyberry-digi
#device_tree_overlay=hifiberry-amp
#device_tree_overlay=iqaudio-dac
device_tree_overlay=iqaudio-dacplus
Actually the command for loading a device tree driver has changed.
Loading a audio_dac is now done like this:
dtoverlay=iqaudio-dacplus
Steen
-
Hi Steen
Translate for feedback. I will review config.txt
showapps is not yet implemented.
-
piCore 7.0 alpha 8 :
1. window which shows progress during install of tcz is blank. Font color probably same as background.??
2. After reboot openssl seems to be broken.
here are the messages:
tc@box:~$ ssh tc@localhost
OpenSSL version mismatch. Built against 1000204f, you have 1000109f
tc@box:~$ ssh tc@192.168.178.35
OpenSSL version mismatch. Built against 1000204f, you have 1000109f
tc@box:~$ /usr/local/etc/init.d/openssh start
must be root
tc@box:~$ sudo /usr/local/etc/init.d/openssh start
OpenSSL version mismatch. Built against 1000204f, you have 1000109f
tc@box:~$
-
may I suggest to bring a small editor such as leafpad or mousepad to the repo.
I am also missing a simple image viewer such as mtpaint or gpicview or flpicview
Other than that - this version works great.
Question: How to include older repos into the Apps tool?
-
I am also missing a simple image viewer such as mtpaint or gpicview or flpicview
Did you try viewnior ? It is in the repo.
-
No - i will install it and see.
On the other item I found the problem. It was my fault. I did not reboot after resizing and tried to install TC.tcz
So it stopped. After resizing there was a corrupt openssh left. I deinstalled openssh completely and reinstalled it and now it works great.
thanx
-
I couldn't help but notice that the "s" command in busybox vi is still "broke as hell" in this release. Since it doesn't appear that this is going to change, can we get vim?
-
I couldn't help but notice that the "s" command in busybox vi is still "broke as hell" in this release. Since it doesn't appear that this is going to change, can we get vim?
What do you mean 'broke as hell'? I'm using vi randomly to edit config files but never used s command.
Anyhow install nano.tcz if you don't like BusyBox vi.
-
Try something simple like s/$/some text/ to append to a range of lines in a file and it will corrupt your file so bad you'll have to quit and start over. The same command works in sed just fine. I could learn to use yet another editor, but why if I already know vi. It's available for x86.
-
Reported the bug to busybox?
-
Upon further research it may be because that option that wasn't compiled in. Where can I find the compile options that have been used for busybox VI? It still seems like it would be easier to port the vim extension.
-
Upon further research it may be because that option that wasn't compiled in. Where can I find the compile options that have been used for busybox VI? It still seems like it would be easier to port the vim extension.
Which option are you referring to?
Regarding vim, user contribution welcome adding tcz's to repo :)
-
These (http://git.busybox.net/busybox/tree/editors/vi.c) options. A user submission for vim will be forthcoming.
-
ftp://ftp.nluug.nl/pub/ibiblio/distributions/tinycorelinux/6.x/armv6/release/src/busybox/busybox-1.23.2-nosuid.config
-
BusyBox config for piCore-7.0alpha8 is here:
http://tinycorelinux.net/7.x/armv7/releases/RPi2/src/busybox/
@andyj
Which vi releted config changes do you propose for next BusyBox build to fix your issue?
-
Looking at the options that are apparently enabled along with the source code that produces the list given by "vi -H" I can't be sure that the regex substitute command is in fact enabled because it sure doesn't look like it's working. I'll have to do some testing to see where the problem is. If all the configuration options are on and it doesn't work then it would sure look like a bug.
-
I've installed squeezelite using my tutorial on this version, and everything seems to work (haven't tested wifi yet).
One thing was a bit different compared to earlier versions, I had to manually load snd-bcm2835 to make the onboard sound device work.
In the end I've used this command to make "stick" after a reboot:
echo "/sbin/modprobe snd-bcm2835" >> /opt/bootlocal.sh
sudo filetool.sh -b
I am not saying this is a problem or bug, I understand it if you left it out on purpose. It's just something I noticed.
-
I've installed squeezelite using my tutorial on this version, and everything seems to work (haven't tested wifi yet).
One thing was a bit different compared to earlier versions, I had to manually load snd-bcm2835 to make the onboard sound device work.
In the end I've used this command to make "stick" after a reboot:
echo "/sbin/modprobe snd-bcm2835" >> /opt/bootlocal.sh
sudo filetool.sh -b
I am not saying this is a problem or bug, I understand it if you left it out on purpose. It's just something I noticed.
Hi Gerrelt.
The onboard audio card is now enabled by:
audio=on
in the config.txt
Steen
-
Hi Gerrelt.
The onboard audio card is now enabled by:
audio=on
in the config.txt
Steen@, do you advice to add
audio=on
to the default config.txt?
@Gerrelt
In the beginning alsa-modules-KERNEL.tcz had a startup script to modprobe built-in audio but it caused issues users with external USB sound devices, so it was removed in 5.x sometime. In details built-in audio become the default #0 sound device instead of the external #1 and it required extra steps from the user.
-
Hi Gerrelt,
Here is the Device Tree documentation for the Raspberry Pi.
https://github.com/raspberrypi/documentation/blob/master/configuration/device-tree.md
I think you need to add:
dtparam=audio
or
dtparam=audio=on
to config.txt
regards
Greg
-
What I don't see in that doc is: Here's a list of the available overlays, here's what they do/enable, and here's why you would care or not.
-
What I don't see in that doc is: Here's a list of the available overlays, here's what they do/enable, and here's why you would care or not.
Hi andyj,
It is fully documented here: /mnt/mmcblk0p1/overlays/README on every piCore image. On Raspbian its /boot/overlays/README I think??
regards
Greg
-
I typically do an in place upgrade, so my onboot.lst file contains references to KERNEL, rather than specific kernel versions. Extensions with a reference to KERNEL do not load from within onboot.lst
tce-bootload just reports that it is not available. it appears KERNEL is not expanded properly. The odd thing is that it does properly expand references to KERNEL when in the .dep files.
-
I typically do an in place upgrade, so my onboot.lst file contains references to KERNEL, rather than specific kernel versions. Extensions with a reference to KERNEL do not load from within onboot.lst
tce-bootload just reports that it is not available. it appears KERNEL is not expanded properly. The odd thing is that it does properly expand references to KERNEL when in the .dep files.
I have observed the same - I don't know if this Is different from previous versions.
If possible it would be handy to use KERNEL in the onboot lst
-
OK. Now that you put my nose in it I see it. Still not 100% clear on what's soldered on the the board and which are the add-ons but I might yet figure it out.
On a slightly different piCore alpha topic, it occured to me that the bulk of the boot process time is spent loading extensions. It also occured to me that there are "groups" of extensions that don't depend on each other, like X doesn't need networking (if you're not listening for remote connections) and sound to start. Anymore than networking needs X and sound or sound needs X or networking. Given that the PI2 is a quad-core, it occured to me that maybe some of these could be loaded in parallel. I realize this would be a big change from the current serial process, but it could be a big help in the long run. I can say from experience that make -j4 when compiling the kernel helps a lot on the pi2. The boot process would need to be able to call tce-load with different lists and start the networking tasks while the X libraries are still loading. The trick would be knowing when the last list was done (and didn't die for some reason). For a few extensions it probably doesn't matter, but for 100+ it would be nice.
-
Hi andyj
If most of the time is spent reading the storage device, you won't see much improvement in loading extensions
since while one core is reading it blocks the others from accessing the storage device.
-
Which is faster to set up? Copy2fs clearly reads the whole file into RAM. What about mounting via loop and linking? Does that read through the whole file too or is it clever enough to just read the file system structure from the file and then create the links? How much actual RAM does a loop mounted device use? We would need some really granular timing data.
-
And back to the vim extension, how do I get it to replace the vi link in /usr/bin when it loads?
-
And back to the vim extension, how do I get it to replace the vi link in /usr/bin when it loads?
Put it to /usr/local
-
I typically do an in place upgrade, so my onboot.lst file contains references to KERNEL, rather than specific kernel versions. Extensions with a reference to KERNEL do not load from within onboot.lst
tce-bootload just reports that it is not available. it appears KERNEL is not expanded properly. The odd thing is that it does properly expand references to KERNEL when in the .dep files.
Confirmed, it is a bug, thanks for reporting. Will fix in next release.
-
Which is faster to set up? Copy2fs clearly reads the whole file into RAM. What about mounting via loop and linking? Does that read through the whole file too or is it clever enough to just read the file system structure from the file and then create the links? How much actual RAM does a loop mounted device use? We would need some really granular timing data.
Loading extensions during the boot process is handled with a micropython script tce-bootload. This is already much faster than the old method of loading extensions. Take a look at the file /var/log/tce-bootload
Creating the symbolic links still takes the bulk of the time. If you use copy2fs, it still mounts the extensions, but it copies the files rather than making symlinks.....then it un-mounts the extension. This would definitely take longer.
Deplist creation for 20 extensions ready: 0s
Mounting 48 extensions ready: 2s
ldconfig return value: 0
depmod return value: 0
Symlinking ready: 6s
Script finished: 6s
-
Upon further research it may be because that option that wasn't compiled in. Where can I find the compile options that have been used for busybox VI? It still seems like it would be easier to port the vim extension.
vim.tcz added to 7.x repo.
-
Which is faster to set up? Copy2fs clearly reads the whole file into RAM. What about mounting via loop and linking? Does that read through the whole file too or is it clever enough to just read the file system structure from the file and then create the links? How much actual RAM does a loop mounted device use? We would need some really granular timing data.
Read up on squashfs internal structure to find how the data is placed. Symlinking does not read the whole file, but just the directory info (file names, etc.). A single loop mount at our default 4kb blocksize used some tens of kb of RAM.
-
The onboard audio card is now enabled by:
audio=on
in the config.txt
Hi Steen,
Yes, that worked! This is wat I did, first mount partition 1, and then open the config.txt :
sudo mount /dev/mmcblk0p1
sudo nano /mnt/mmcblk0p1/config.txt
And I then added ",audio=on" to the end of the "dtparam" line. It now looks like this:
dtparam=i2c=on,spi=on,i2s=on,audio=on
Thanks.
Greetings,
Gerrelt.
-
Was playing wtih a Rpi B+, and I'm having a problem where the kernel module for the wifi card is not loading on boot. The USB bus is registering the stick, but just not loading the driver.
If I plug in the USB stick after the pi is booted, then the kernel module loads just fine. Also loading the driver manually in bootlocal works fine too.
-
I've had a problem like this too, but not perticularly with this piCore version. In the end it appeared to be that a reboot doesn't always work with some USB wifi adapters.
The USB wifi adapter didn't really reboot properly when the Pi was rebooted.
Unplugging the power to the Pi (and with it the USB wifi adapter), and waiting until the lights (on power adapter and Pi) are really off, and then plug the power back in "solved" it.
I think the reboot via the command line happens to fast for the USB wifi adapter to react, leaving it in a corrupt state.
Unplugging it for every reboot is a bit off a nuisance though...
-
I've not been using wifi alot on the picore lately. So I don't know when this started. But was definitely not an issue with picore 6.1 I don't think there is a corruption, as there are no errors and if I load the kernel driver manually, it works just fine.
This is acting like the USB is starting faster than we are mounting the kernel drivers in the extensions.