Tiny Core Linux
Tiny Core Base => Raspberry Pi => Topic started by: uekawi on May 20, 2020, 09:28:44 AM
-
Hi guys,
i want to create a sort of thin client out of my raspberry pi (like the thin clients from HP, the T530 for example).
The Thin Clients from HP can be set to only connect to a specific rdp session, and nothing else.
I want to do something like that with my raspberry pi.
The Raspberry-"Thin Client" should only be able to do the following things:
- use wifi
- straight rdp connection at start up to a windows server 2012 with a "execute-command"
- touch screen support
I thought tiny core (or rather piCore) would be much better to use, than the bloated raspbian operating system.
My questions now are:
- Which minimal graphical interface do i have to install to connect to a rdp session and have a flawless graphical experience, like, for example, on raspbian?
- Which rdp app can i use to connect with a "execute-command" and a hostname to execute a specific program on the rdp server (like: "C:\app\program.exe") which then reads the provided hostname to connect to a rdp session? I tried freerdp and rdesktop, but as soon as i provided a "execute-command" (for example: xfreerdp /u: ... /app:"C:\app\program.exe") it failed
I hope you guys can help me.
Thanks in advance and have nice day
-
You should be do it with piCore-9.x or piCore-11.x using x11/flwm or wayland/weston and freerdp.
I was testing in the reverse sense this morning with a piCore rdp server and a CorePure64 rdp client:
http://forum.tinycorelinux.net/index.php/topic,23269.msg150229.html
-
Hi Juanito,
thank you for your quick response. Sadly, i can't get piCore to boot on my Raspberry Pi 4gb.
- I tried to install piCore-(7.0,9.0,9.1,9.2,9.3) on my sd card with Balenaetcher, Win32DiskImager and Rufus.
- tried the armv6 and armv7 versions
- tried to find piCore-11.x but i can't find it in http://tinycorelinux.net/11.x/ (http://tinycorelinux.net/11.x/)
It's always the same when i put in the sd card and boot. Green LED blinks for like 2 seconds, then the green LED turns off and only the red LED remains lit.
I have three SD cards, two with 32gb and one with 128gb and three Raspberry Pis (4gb, all the same). piCore did not boot on any of them.
Raspbian Buster with Desktop, Raspbian Buster Lite, Ubuntu Mate and Windows 10 IOT did work perfectly on each device, with each sd card.
Can you help me with this problem?
Also, can you please give me the link to piCore-11.x?
-
If I understand correctly, the only RPi with 4gb ram is the RPi4, which will not work with piCore-9.x.
You can get piCore-11.x from here:
http://tinycorelinux.net/11.x/armv7l/test_releases/RPi/piCore-11.0beta1a.zip
Note that, once booted on an RPi4, piCore-11.x looks for extensions in the armv7 repo, so you will need to download any additional kernel module extensions you might need manually from the armv7l repo.
-
Hi Juanito
Thats because getBuild doesn't distinguish between 7 and 7l:
getBuild() {
BUILD=`uname -m`
case ${BUILD} in
armv6l) echo "armv6" ;;
armv7l) echo "armv7" ;;
i686) echo "x86" ;;
x86_64) [ -f /lib/ld-linux-x86-64.so.2 ] && echo "x86_64" || echo "x86" ;;
*) echo "x86" ;;
esac
}
-
Yes, but "uname -m" returns "armv7l" for both RPi3 and RPi4 even though they don't use the same kernel modules ???
-
Hi Juanito
This may be of some interest:
The upstream Linux kernel developers had decided that all models of Raspberry Pi return bcm2835 as the SoC name. At Raspberry Pi we like to use as much upstream kernel code as possible, as it makes software maintenance much easier, so we use this code. Unfortunately it means that cat /proc/cpuinfo is inaccurate for the Raspberry Pi 2, Raspberry Pi 3 and Raspberry Pi 4, which use the bcm2836/bcm2837, bcm2837 and bcm2711 respectively. You can use cat /proc/device-tree/model to get an accurate description of the SoC on your Raspberry Pi model.
Found here:
https://www.raspberrypi.org/documentation/faqs/#pi-software
I don't have any Pi boards so I don't know what is in /proc/device-tree/model. It may or may not make sense to alter how getBuild
tests for ARM.
If /proc/device-tree/model contains something like v8 as an identifier for pi4 and v7 for pi3 that would probably be usable.
-
Hi Juanito
I came across this:
https://www.raspberrypi.org/documentation/hardware/raspberrypi/revision-codes/README.md
A couple of questions:
1. Under the "Old-style" revision codes, are those all armv6?
2. Under the "New-style" revision codes, is the processor all that is required to determine whether you want armv6, armv7, or armv7l ?
3. Under the "New-style" revision codes, does the "Type" field matter ?
I'm thinking maybe first test for arm* and then determine type, something like:
getBuild() {
BUILD=`uname -m`
case ${BUILD} in
armv*) fetch revision code
extract processor field from revision code
case ${processor} in
0) echo "armv6" ;;
1) echo "armv6" ;;
2) echo "armv7" ;;
3) echo "armv7l" ;;
;;
i686) echo "x86" ;;
x86_64) [ -f /lib/ld-linux-x86-64.so.2 ] && echo "x86_64" || echo "x86" ;;
*) echo "x86" ;;
esac
}
I layed down a little groundwork in determining processor model in the attached file.
-
Thanks for the info Rich - btw I'm very much a user when it comes to piCore, @bmarkus is the lead.
I have the following hardware:
Rpi4 4gb
RPi3 1gb
$ cat /proc/device-tree/model
Raspberry Pi 4 Model B Rev 1.2
Raspberry Pi 3 Model B Rev 1.2
$ cat /sys/firmware/devicetree/base/model
Raspberry Pi 4 Model B Rev 1.2
Raspberry Pi 3 Model B Rev 1.2
..and: $ cat /proc/cpuinfo
...
Hardware : BCM2835
Revision : c03112
Serial : 100000002f7ed527
Model : Raspberry Pi 4 Model B Rev 1.2
...
Hardware : BCM2835
Revision : a02082
Serial : 00000000c521e83a
Model : Raspberry Pi 3 Model B Rev 1.2
..where as per the table:
Revision NOQu uuWu FMMM CCCC PPPP TTTT TTTT RRRR
0 3 1 1 2
c03112 4B 1.2 4GB Sony UK
Revision NOQu uuWu FMMM CCCC PPPP TTTT TTTT RRRR
0 2 0 8 2
a02082 3B 1.2 1GB Sony UK
So it seems that selecting the 4th from last digit will correctly identify the cpu :)
-
..forgot to mention - your attached getBuild.sh seems to work fine :)
btw, from: In general, you need to look to see whether the program you want can be compiled for the Armv6 (Raspberry Pi 1/Zero/Zero W/CM), Armv7 (Raspberry Pi 2) or Armv8 (Raspberry Pi 3) architecture on Linux
..I guess the code above should be: case ${processor} in
0) echo "armv6" ;;
1) echo "armv7" ;;
2) echo "armv7" ;;
3) echo "armv7l" ;;
;;
-
Hi Juanito
... So it seems that selecting the 4th from last digit will correctly identify the cpu :)
Good, the "New-style" revision codes make things easy.
What about the "Old-style" revision codes:
The first set of Raspberry Pi models were given sequential hex revision codes from 0002 to 0015
Are these all armv6:
Code Model Revision RAM Manufacturer
0002 B 1.0 256MB Egoman
0003 B 1.0 256MB Egoman
0004 B 2.0 256MB Sony UK
0005 B 2.0 256MB Qisda
0006 B 2.0 256MB Egoman
0007 A 2.0 256MB Egoman
0008 A 2.0 256MB Sony UK
0009 A 2.0 256MB Qisda
000d B 2.0 512MB Egoman
000e B 2.0 512MB Sony UK
000f B 2.0 512MB Egoman
0010 B+ 1.2 512MB Sony UK
0011 CM1 1.0 512MB Sony UK
0012 A+ 1.1 256MB Sony UK
0013 B+ 1.2 512MB Embest
0014 CM1 1.0 512MB Embest
0015 A+ 1.1 256MB/512MB Embest
If these are all armv6 then with a little cleanup the code I attached could be turned into a patch for tc-config.
-
Hi Juanito
... ..I guess the code above should be: case ${processor} in
0) echo "armv6" ;;
1) echo "armv7" ;;
2) echo "armv7" ;;
3) echo "armv7l" ;;
;;
Oh, I see you edited your post since I last read it. I will defer to you as to what the correct strings to use are.
... If these are all armv6 then with a little cleanup the code I attached could be turned into a patch for tc-config.
Well, I looked over here:
https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2835/README.md
and I found this:
This is the Broadcom chip used in the Raspberry Pi Model A, B, B+, the Compute Module, and the Raspberry Pi Zero.
I don't see the A+ mentioned in that list but I'm guessing that's just a documentation error.
So assuming all those "Old-style" revision codes are for armv6, the detection logic can be simplified even further.
This is what I came up with:
getBuild() {
BUILD=`uname -m`
case ${BUILD} in
armv*) # Fetch the Pi revision and add a leading 0x to make it a legal hex value.
PiRevision="$(printf "%s%s\n" "0x" `grep Revision /proc/cpuinfo | cut -d ':' -f2`)"
# Isolate the CPU type and save as hex value.
Processor=`printf "%x" "$((($PiRevision >> 12) & 0xf))"`
case ${Processor} in
0) echo "armv6" ;;
1) echo "armv7" ;;
2) echo "armv7" ;;
3) echo "armv7l" ;;
*) echo "?" ;;
esac
i686) echo "x86" ;;
x86_64) [ -f /lib/ld-linux-x86-64.so.2 ] && echo "x86_64" || echo "x86" ;;
*) echo "x86" ;;
esac
}
Do you want a default case in the event that $Processor doesn't match any of the choices?
If you think this looks acceptable, do you want me to create a patch file?
I set $Processor value to hex because the table format used at:
https://www.raspberrypi.org/documentation/hardware/raspberrypi/revision-codes/README.md
for the Type field is hex and I would expect they will do the same for the Processor field.
-
Hey guys,
I guess Paul is not following this thread but have you thought of asking him about this stuff.
He gets piCorePlayer working on the latest Raspberry Pi hardware a few days after its release. We have had RPi4's working since 27 June 2019.
regards
Greg
-
Hi Greg Erskine
Anyone who has any insight to offer is more than welcome to comment.
... I guess Paul is not following this thread but have you thought of asking him about this stuff. ...
Paul hasn't logged in for about a week so he's probably not aware of this thread.
-
It's a mess. The problem is that board type (revision number) is not relevant to the kernel......I realize this is a pCP kernel but as you can see, a rpi4 can run 64bit.
tc@Pi4-4G-devel:~$ cat /proc/cpuinfo
...............
Hardware : BCM2835
Revision : c03111
Serial : 100000002715a25a
Model : Raspberry Pi 4 Model B Rev 1.1
tc@Pi4-4G-devel:~$ uname -a
Linux Pi4-4G-devel 4.19.105-pcpCore_v8 #1 SMP PREEMPT Sat Feb 22 00:42:52 EST 2020 aarch64 GNU/Linux
I think using revision codes is just over complicating it, anmdI don't see any value in keeping many arch's in the repo, as currently pretty much everything is compiled for armv6 32bit.
I know I don't control the repo, but I would just keep 3 repos
armv6*) echo "armv6" (Would contain one set of v6 kernel extensions)
armv7*) echo "armv7" (Would contain kernel extensions for pi2/3 in 32 bit mode, and a pi4 in 32bit mode)
aarch64) echo "aarch64" (Future for piCore, 64bit kernels.......it may never com to pass)
Then just make sure the appropriate kernel extensions fall in the right spot.
-
Hi Paul_123
It's a mess. The problem is that board type (revision number) is not relevant to the kernel...... ...
The revision code contains much more information than just the board type. It also contains the CPU type which is what we were after.
... Then just make sure the appropriate kernel extensions fall in the right spot.
Those are dependent on the CPU type, aren't they?
I think one of the goals here is to maintain a common infrastructure between x86, x86_64, and ARM. That means scripts like
tc-functions, tc-config, tce-load, etc. are identical for all of the supported architectures.
know I don't control the repo, but I would just keep 3 repos
armv6*) echo "armv6" (Would contain one set of v6 kernel extensions)
armv7*) echo "armv7" (Would contain kernel extensions for pi2/3 in 32 bit mode, and a pi4 in 32bit mode)
aarch64) echo "aarch64" (Future for piCore, 64bit kernels.......it may never com to pass)
I think a change like that might require changes to tce-load to handle ARM differently from the other architectures. You would
have separate repos for the kernel modules and a common repo for the remaining extensions. Since multiple architectures
are supported by the same scripts I don't think think it's a good idea to create special code to handle corner cases for
one particular architecture if you don't have to.
[EDIT]: Crossed out my incorrect statement. See reply #18. Rich
-
At the moment, it seems to me that we can use the existing scripts with all versions of RPi if we copy the kernel module extensions from the piCore-11.x armv7l repo to the armv7 repo (since my RPi3 and RPi4 are using the same tce/optional folder without problems).
-
Yes, since we are only doing 32bit stuff right now, knowing the cpu is fine. But forward thinking that same processor can run in 32 or 64 bit, in which case you need more than the processor type.
For now, Yes, just moving the rpi4 kernel modules to the armv7 directory will work just fine. Outside of the kernel module extensions, all the tcz binaries are compatible with all boards, compiler is set to give code for an armv6. I've never seen any real improvement in applications where I tried to enable optimizations for the rpi4.
-
Hi Paul_123
You're right. I forgot that while tce-load uses getBuild to select which repo to use, it uses uname -r to select which modules to use.
... For now, Yes, just moving the rpi4 kernel modules to the armv7 directory will work just fine. Outside of the kernel module extensions, all the tcz binaries are compatible with all boards, compiler is set to give code for an armv6. ...
If that's the case, it sounds like all of the kernel modules could be placed in the armv6 repo. Then the armv7 and armv7l repos
could just be links back to the armv6 repo. Or am I missing something?
-
That's what I do on the pCP repo..... as long as the web server and mirror servers handle the symlinks. Saves alot of disk space, and forgetting to update an extension in one of the armxx repos.
-
For the moment, the path of least resistance has been taken and the RPi4 kernel module extensions have been copied to the piCore-11.x armv7 repo.