Tiny Core Linux
Tiny Core Base => Raspberry Pi => piCore Test Releases => Topic started by: bmarkus on March 09, 2015, 06:53:43 PM
-
Team Tiny Core is pleased to announce the availability of piCore-6.1 alpha4 for RPi2:
Changelog for 6.1 alpha4:
* kernel updated to 3.18.9
http://www.tinycorelinux.net/6.x/armv7/test_releases/RPi2/
Functionally it is the same as the armv6 release.
-
Seems that the file piCore-6.1alpha4_v7-X.zip is corrupted. I've tried several times with the same error message.
-
Seems that the file piCore-6.1alpha4_v7-X.zip is corrupted. I've tried several times with the same error message.
I downloaded it from the main repo. zip file is ok, img file checked against the md5 file, it is also ok. It means that the file is not corrupted in the repo. Must be a local issue at your side.
-
Hi Bela
Thanks for this version, I'm currently testing but haven't found any problems yet :-)
The only issue I have (and that is not because of the kernel) is trouble using wget to download from https pages. I know that a newer version of BusyBox than the present one (v1.22.1) is supporting https download.
As far as I remember you mentioned a new version and I was wondering if it would be possible to make that available?
From the BusyBox webpage it seems like version 1.23 or newer supports https.
Regards
Steen
-
Hi Steen
thanks for the feedback. I had some issues with BusyBox 1.23.1 so I kept 1.22.1 during kernel tests in this version. Now kernel looks ok and it will be used as the final version, I will update BusyBox.
However https works fine. Try
busybox wget http://google.com
and
busybox wget https://google.com
They will return the index.html file just fine.
-
Thanks for this version, I'm currently testing but haven't found any problems yet :-)
Did you try the 192kbit/s HDMI audio?
-
Hi Steen
thanks for the feedback. I had some issues with BusyBox 1.23.1 so I kept 1.22.1 during kernel tests in this version. Now kernel looks ok and it will be used as the final version, I will update BusyBox.
However https works fine. Try
busybox wget http://google.com
and
busybox wget https://google.com
They will return the index.html file just fine.
Hi Bela it doesn't work for me.
busybox wget https://github.com/ralph-irving/tcz-jivelite/raw/master/jivelite.tcz
wget: not an http or ftp url: https://github.com/ralph-irving/tcz-jivelite/raw/master/jivelite.tcz
or
tc@piCorePlayer:~$ busybox wget https://google.com
wget: not an http or ftp url: https://google.com
Regards
Steen
-
Hi sbp
tc@piCorePlayer:~$ busybox wget https://google.com
wget: not an http or ftp url: https://google.com
I just tried that under the x86 version on TC4 and got the same results. Using GNU wget returns the following:
tc@box:~/findpcs/src/rollcall$ wget https://www.google.com
--2015-03-16 11:26:50-- https://www.google.com/
Resolving www.google.com... 64.233.177.147, 64.233.177.105, 64.233.177.103, ...
Connecting to www.google.com|64.233.177.147|:443... connected.
ERROR: cannot verify www.google.com's certificate, issued by `/C=US/O=Google Inc/CN=Google Internet Authority G2':
Unable to locally verify the issuer's authority.
To connect to www.google.com insecurely, use `--no-check-certificate'.
-
Hi Bela,
I'm trying to build some packages but am unable to find either a linux-3.18.y_api_headers or linux-3.18.y_v7_api_headers package anywhere, can you please create them or let me know how I can do so please.
I also noticed going through the available packages in both the armv6 & armv7 repos that 2 seem to be named incorrectly: filesystems-3.8.9_v7-piCore+.tcz & netfilter-3.8.9_v7-piCore+.tcz.
Cheers Jon
-
I also noticed going through the available packages in both the armv6 & armv7 repos that 2 seem to be named incorrectly: filesystems-3.8.9_v7-piCore+.tcz & netfilter-3.8.9_v7-piCore+.tcz.
Hi Jon
thanks fixed.
Béla
-
I'm trying to build some packages but am unable to find either a linux-3.18.y_api_headers or linux-3.18.y_v7_api_headers package anywhere, can you please create them or let me know how I can do so please.
linux-3.18.y_api_headers.tcz added to armv6/armv7 repo
-
Picked up a dozen 2B's Friday; just now setting up a dedicated switch and 30A power supply; will test TC6-Pi2 accordingly and note any anomalies if found.
A couple quick questions if you don't mind based on anyone's experiences with Pi:
1) Are there any known side-effects using Pin 2 (5vcc) instead of the uUSB connector for power? (fused, of course.)
2) Are there any known limitations to uSD card sizes and/or class/speed (I have a couple dozen 2GB Class4 chips I'd like to re-purpose for these.)
3) Do you have an online wiki page for remastering Pi images?
4) Is Python embedded into the image (assuming not) and/or a TCZ ready for it?
5) Is there any way to disable the rainbow (I tried booting piCore6 but never got past the rainbow screen to see any kernel messages, etc.)
6) Is the Pi2 kernel being set up as 64-bit or 32? What about the extensions?
Thanks, Béla, for keeping up with the trend (new hardware releases) and I truly hope TC flies with this new board... so, so many things become possible with a quad/1GB, we'll see how they perform!
~TJ~
-
1) Pin 2 of which connector?
2) Class 4 is ok for generic use aswell as 2GB. There are certion cards are not recognized by the RPi firmware. It has not related to size, vendor, ... I have seen issues with uSD card adapters also. Try your cards. If they are booting, use them.
3) Check the -SSH and -X images with a second mmcblk0p2 partion with preinstalled tcz's in /tce and a preconfigured backup file.
4) python.tcz is in the repo.
5) Do not understand. Are you saying that your Pi doesn't boot at all and you get only the coloured screen?
6) Pi2 CPU is 32-bit. Pi (armv6) extensions work fine with Pi2 (armv7).
-
Back again to piCore:
I have just downloaded and installed http://www.tinycorelinux.net/6.x/armv7/test_releases/RPi2/ on my new Pi2. Ok so far.
But I have forgotten many things in the meantime. So sorry for dumb questions.
As I like to compile I'm searching for compile-essentials.tcz and other stuff from repo
Obviously tce does not show me such packages.
How to get the system up and running for such tasks?
PS: I noted that ldd seems not to work correctly.
-
Sorry, I have found compile-essentials. It's there.
But ldd is not working correctly.
-
What do you mean ldd is not working correctly?
-
For example
ldd nano
--> ./nano: error while loading shared libraries: ./nano: cannnot open shared object file: no such file or directory
-
tc@box:~$ ldd /usr/local/bin/nano
/usr/lib/libarmmem.so (0xb6f3a000)
libncursesw.so.5 => /usr/local/lib/libncursesw.so.5 (0xb6ecf000)
libc.so.6 => /lib/libc.so.6 (0xb6d94000)
libdl.so.2 => /lib/libdl.so.2 (0xb6d81000)
/lib/ld-linux-armhf.so.3 (0xb6f46000)
or
tc@box:~$ cd /usr/local/bin
tc@box:/usr/local/bin$ ldd nano
/usr/lib/libarmmem.so (0xb6fd3000)
libncursesw.so.5 => /usr/local/lib/libncursesw.so.5 (0xb6f68000)
libc.so.6 => /lib/libc.so.6 (0xb6e2d000)
libdl.so.2 => /lib/libdl.so.2 (0xb6e1a000)
/lib/ld-linux-armhf.so.3 (0xb6fdf000)
-
Hi Mucke
Or:
ldd `which nano`Those are back ticks, not apostrophes.
-
Hi Bela
Thanks for this version, I'm currently testing but haven't found any problems yet :-)
The only issue I have (and that is not because of the kernel) is trouble using wget to download from https pages. I know that a newer version of BusyBox than the present one (v1.22.1) is supporting https download.
As far as I remember you mentioned a new version and I was wondering if it would be possible to make that available?
From the BusyBox webpage it seems like version 1.23 or newer supports https.
Regards
Steen
BusyBox wget 1.23.1 supports https download using openssl, so openssl.tcz must be installed.
-
@bmarkus:
1) Pin 2 of which connector? Pin 2 (Vcc) of the GPIO connector (In theory it should, but it bypasses the onboard regulator)
2) Class 4 is ok for generic use aswell as 2GB. There are certion cards are not recognized by the RPi firmware. It has not related to size, vendor, ... I have seen issues with uSD card adapters also. Try your cards. If they are booting, use them. Thanks for the head's up. I use as small as 128MB cards on x86 boards, but not familiar with Pi's prerequisites as I hear everywhere "8GB Class 10 is the only way to go"
3) Check the -SSH and -X images with a second mmcblk0p2 partion with preinstalled tcz's in /tce and a preconfigured backup file. I loaded the -X image, fdisk'ed the second partition (dropping the built in extensions) and reloaded. There's a few quirks to iron out, but nothing horrific/breaking noticed yet.
4) python.tcz is in the repo. Thanks, found it!
5) Do not understand. Are you saying that your Pi doesn't boot at all and you get only the coloured screen? Just for kicks I loaded an ARM6 image of TC6 and it just sat at the video test image. I remember reading somewhere that there was a way to disable the test image (rainbow) but God knows where I read that. With piCore-6 (arm6) image, you see the LED flicker a couple times while attempting to start the kernel and then it just hangs. I was considering picking up a B+ or two but considering the differences (hardware and the very little price difference) I went for all Pi2B models for the testing phase. If all works out I'll be clouding them together internally, but first I have to push them to see where their limitations stand.
6) Pi2 CPU is 32-bit. Pi (armv6) extensions work fine with Pi2 (armv7). 32-bit with multiple cores... this should prove interesting! :)
Little things I've noticed thus far:
*) Once video is reset (CLI), the 2B has a tendency to skip a few lines at the top when scrolling. (There are about 40 rows, 36 or so scroll while leaving the others where they are. A "clear" tends to this and it doesn't seem to happen again until rebooting... but nothing horrible.
*) I haven't looked into the arm6 repo, but web browsers and similar tools will eventually become a high demand request :)
*) No documentation regarding MPG and other licensing that I've found thus far (integration into TC for hardware based decoding.)
*) Video playback (XBMC, VLC, etc.) is staggered at high motion, but that's somewhat expected due to the speed of the unit.
*) Netflix use... well... would have been nice, but I haven't ironed out all of the DRM specs yet :)
**) Otherwise, things are looking terrific!!! The USB based network interface somewhat kills the concept of turning a Pi into a router/gateway (adding a second USB based NIC tends to bog the channel.) I still have to trace out the composite (none of my 4-pin A/V cables work on this unit, but it may be due to my configuration being less than perfect... we'll see.)
Thanks again and take care!
~TJ~
-
For those interested:
Raspberry Pi Power System
I took a quick look at the Pi spec sheet and my theory is correct... the Pi can be powered through the GPIO power leads; WITH PRECAUTIONS.
1) When feeding Vcc (5v) from the GPIO, use a solid power supply, preferably one listed as "regulated" (such as a computer PSU) and/or utilize a 5 volt, 2 amp 3 pin regulator and a filter capacitor rated approx. 1600uF at 6.3 volts or higher.
2) Add a 1, 1.5 or 2.0 amp 5 volt "fast blow" fuse to the circuit feeding the GPIO pin as we're bypassing the polymer fuse that normally protects the Pi with using the uUSB connection. (Shunting the onboard fuse can be a nightmare without the right soldering iron and a steady hand, so this also makes it more convenient for hardware designers in case something goes wrong, you don't have to modify the Pi board... just your PSU circuit.)
3) The Pi has a very small tolerance (up to ~0.,25 volt drop) before it runs on a threshold of becoming unstable. An external 5v regulation circuit can help prevent USB devices from draining the uUSB connector's normal way of feeding the device without the need for a powered USB hub (adding more cables to the mix and a bad power supply with a USB hub can blow the poly fuses on that circuit.)
4) Always add more amperage than you need as power supply devices themselves have a waste level. (A PSU rated at 5v 1A does not usually mean it can sustain 1A worth of draw, but allows an intermittent "peak" of 1A for short durations.)
5) For those wishing to use a computer PSU (ATX power supply) the task is very simple. First, it's most convenient to use a PSU with a "Vacation Switch" (on/off) on the back allowing you to disconnect power without disconnecting anything from the Pi. Secondly, to "turn on" an ATX power supply, find the one GREEN wire in the 20-pin side that normally goes to the computer's motherboard (or 24 pin if it's a solid connector) and run a wire between the GREEN lead and any of the black leads directly next to it. Grounding the green wire tells the PSU to engage. Finally, using one of the D-Sub (4 pin hard drive connectors) connect the 5v rail to Pin 2 (5Vcc) of the GPIO (image here: http://elinux.org/RPi_Low-level_peripherals) and one of the black leads to Pin 6 (Ground) or one of the other ground lines shown. This is UN-PROTECTED as most power supplies will allow more drain on a single 5v rail than the Pi can handle, thus the suggestion for filtering and a fuse noted above.
We're going to be creating an array (8x8) of headless Pi boards and one of the goals is to minimize wiring. The power supply feeding all these boards was the first step. The second step might also be useful for those wanting to limit wasted copper and space:
Network: Since the Pi has merely a BASE-100T network interface, and we'd prefer wired over wireless, you can literally cut your cables in HALF as you only need four wires (instead of the eight within a single CAT-5 cable.) If you have (or are willing to purchase) a crimper/stripper and some RJ-45 ends to crimp, generic flat telephone cable is all you need to create your own T-100 network cables. (Or you can use standard CAT wire and share one cable for two Pi.) To do this, you need to utilize only pins 1, 2, 3 and 6 on each end (leaving the other four pins empty.) If connecting to a hub or switch, you need only connect pin 1 on one side to pin 1 on the other, then repeat for the other three listed. If connecting a Pi to a Pi you need to create what's called a cross-over cable, which is pin 1 to 3, 2 to 6 in the following fashion:
STANDARD CROSS-OVER
==============================
Pin 1 -> Pin 1 Pin 1 -> Pin 3
Pin 2 -> Pin 2 Pin 2 -> Pin 6
Pin 3 -> Pin 3 Pin 3 -> Pin 1
Pin 6 -> Pin 6 Pin 6 -> Pin 2
WARNING: For anyone over-clocking the Pi, heat-sink modules on the processor is an almost-must, but if they're enclosed (poly cases that don't breathe) the heat-sink isn't likely going to do much as there's nowhere for the heat to "go." If you implement a cooling fan, be sure the fan is connected to a power supply NOT fed from USB or the micro-USB cable. The start-up current for a fan is quite a bit AND when powering off, the fan turns into a DC generator which could lead to data problems and the likes. A diode placed on the + lead of the fan will help prevent the fan from "feeding" the Pi electricity as it spins down and a 6-16v capacitor (~2700uF) across the leads will assist with the spin-up issues.
-
SD cards: 8GB Class 10 is the most widely available and reletively the cheapest category, thats all. Lower capacity cards are slow, but may work. If your apps are not using the card after boot, you van copy all tcz's to RAM. It slows down startup but system will run fast. Up to you.
Browsers: I will update NETSURF browser to the latest. It is fine for most tasks. Do not expect FIREFOX ot CHROMIUM on piCore, these are not for such hardware. I tried to build webkit many times but it always failed for same reason and still it is too heavy. User contribution welcome. On RPi2 compilation is faster :)
Video: If you are interested in video playback, you can contribute building omxplayer or the hardware accelerated gstreamer or SDL2 and find a player working with SDL2. It is at the bottom of my priority list of extensions.
But as I wrote, user contribution are highly welcome. Make and submit what is important for you and can be useful for others :)
-
@centralware
Typo: "D-sub". That means VGA, I guess you mean Molex.
-
@centralware
RPi network port is Auto-MDIX so crossover cable is not needed if connecting host to host.
-
Sorry for the late response; I have not been online for quite some time.
@Curaga: D-Sub in electronics is generally any "D" shaped sub (power) connector. However you're right, today many people refer to D-Sub in the computer industry as the VGA based connection. "Molex" based on the old definitions is nothing more than mulched (recycled) plastic, usually black in color (as raw black plastic shards are melted in with the mulch to give it a more uniform color) and have been used for virtually every kind of connector there's been in the past few decades (IDE, SCSI, ISA, etc.) and wouldn't surprise me if hard drive power connectors applies as well. The easiest way to tell is by the color; white is not usually an easy color to get from recycled plastics (when attempted it tends to be an off-white, "dingy" color.) As such, sorry for my old-school definitions. I'm not entirely sure whether or not Molex Inc. was the "founder" of the mulch in question, but the name has stuck for a long time, so it's quite possible.
@sodface: Thank you for the note! I'm not accustomed for many on-board NICs to be auto-detecting/switching so this is terrific news!
@bmarkus: The Pi2 has me thinking in different areas from embedded to end-user. I've ordered parts from across the globe, so we're just waiting for the ship to come in! :) Regarding contributions, consider it underway as soon as the rest of the parts come in. My test bench is 14 Pi2 boards (2 masters with 20x4 LCD, 12 slaves which are powered by a relay board, 3x 20A power supply modules, etc. I'll post pics once she's up and running completely.)
Web browser: Fox, Chrome, etc. are all a bit too "overweight" for my preferences as it is, even on x86/64 machines, so I'll be looking into a more practical approach focused mostly on HTML and possibly JS. I was considering building a "control panel" that was web based (bb-http as the foundation) so something that was able to handle base HTML and possibly JS would be a nice direction to take.
Does the kernel support I2C in slave mode by chance? (ie: having a Pi answer AS a slave device itself?) I was curious as to whether or not I could get better speeds for cross-talk between the master/slave units through GPIO as opposed to using the NICs.
Thanks again everyone!
-
@bmarkus: Béla, if you have a device handy, please plug in something I2C related (sensor, LCD, etc.) and tell me if your Pi2 is detecting the device(s)?
PiCore: Alpha4-X
Added: dtparam=i2c=on dtparam=i2c1=on to cmdline (thinking i2c=on is 1B or older)
Installed i2c-dev and tools
(modprobe shows OK with i2c-dev)
Rebooted.
/dev/i2* shows empty
i2cdetect -y 1 (and zero) show nothing found for /dev/i2c*
tried another unit (20x4 LCD with i2c interface from Sainsmart) with the same results.
Thoughts?
-
At the moment no I2C device in hand.
-
I'm using the RTC device on the I2C bus and I need to use
dtoverlay=i2c-rtc,pcf8563, or manually set the address echo pcf8563 0x51 > sys/class/i2c-adapter/i2c-1/new_device . Othervise the device is not identified.
-
Just tested:
dtparam=i2c=onadded into the config.txt, NOT to the cmdline.txt. Read carefully the README in the overlays folder of the SD card.
sudo modprobe i2c-devsudo i2cdetect -y 1and it works and detects the device on the address 0x51h.
-
Feeling sheepish :) Thanks for the correction regarding which text file, I must have read it incorrectly. Will test accordingly when time permits!