FatdogArm Beta1/2/3/4- 16 April 2016
Sorry for cross posting from "Quirky Xerus 8.1.4 for Raspberry Pi2 and 3"jamesbond wrote: As for 64-bit - well, with only 1GB RAM
I tried this during X-mas:
devuan_jessie_1.0.0-beta2_arm64_raspi3.img.xz as found in
https://files.devuan.org/devuan_jessie_beta/embedded/
Nice! Fun!
Could Devuan be a base for 64bit FatDogArm for Pi3?
Swap might help the low memormy.
Best wishes for 2017! Olle
Olle - unlikely. FatdogArm is compiled from scratch, I don't use existing distros as the base.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]
arm64
and you make a fine distro of it! Fatdog64 is happily running in my x86_64 boxes. Thanks for your work!jamesbond wrote:Olle - unlikely. FatdogArm is compiled from scratch, I don't use existing distros as the base.
Maybe useful to have devuan_jessie_1.0.0-beta2_arm64_raspi3 as a benchmark for the eventual future FatDogArm64?
Pi3 bluetooth
Hi,
Just found FatDogArm, and love the concept. I have installed Beta5 on a Pi2 with a RedBear IOT_phat that basicaly gives Pi3 chipset WLan and BlueTooth.
Was hoping (far fetched idea I know.... lol) to have had the Pi3 bluetooth available. Do you have any idea if you will have time to look into this soon, or any pointers as to what needs doing... Or where to look to attempt to add it myself.
I can confirm that the WLAN is working in this setup lovely, and so far it all works fine except the bluetooth I had hope for ;-(
Just found FatDogArm, and love the concept. I have installed Beta5 on a Pi2 with a RedBear IOT_phat that basicaly gives Pi3 chipset WLan and BlueTooth.
Was hoping (far fetched idea I know.... lol) to have had the Pi3 bluetooth available. Do you have any idea if you will have time to look into this soon, or any pointers as to what needs doing... Or where to look to attempt to add it myself.
I can confirm that the WLAN is working in this setup lovely, and so far it all works fine except the bluetooth I had hope for ;-(
To Inrong....
Try BarryK's Quirky Xerus version
http://murga-linux.com/puppy/viewtopic.php?t=108132
He was apparently able to get his bluetooth devices to work.
_________________________________________________________
Try BarryK's Quirky Xerus version
http://murga-linux.com/puppy/viewtopic.php?t=108132
He was apparently able to get his bluetooth devices to work.
_________________________________________________________
Pi3 bluetooth seems simple enough. I just need to build the correct version of hciattach (read: Broadcom's mangled version of that thing). Some other people have fished the info out of Raspi guy's hands (you need to be very very very very nice and patient to this guy or he won't play ball), so it's just a matter of (finding) the time to do so.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]
Would be excellent if you find the time.
I have tried the simple solution of building the latest blueZ5 with the patches and it does not quite work on mine. I am sure there will be other issues with using 5 not 4, but thought I would try 1 step at a time.
I tried to download the source package for blueZ-4.101 from your ibiblio archive but it kept failing -550 error, was it my end or theirs? I am sure the major parts of the patches can be hand inserted.
I will keep playing..
I have tried the simple solution of building the latest blueZ5 with the patches and it does not quite work on mine. I am sure there will be other issues with using 5 not 4, but thought I would try 1 step at a time.
I tried to download the source package for blueZ-4.101 from your ibiblio archive but it kept failing -550 error, was it my end or theirs? I am sure the major parts of the patches can be hand inserted.
I will keep playing..
I am getting 404 'not found error' as well
http://distro.ibiblio.org/fatdog/arm/so ... 62e.tar.gz
______________________________________
http://distro.ibiblio.org/fatdog/arm/so ... 62e.tar.gz
______________________________________
- Attachments
-
- bluez-tools-0.1.38-662e.tar.gz
- (153.61 KiB) Downloaded 261 times
bluez4 (and any other version of bluez) is available here: https://www.kernel.org/pub/linux/bluetooth/.
bluez-tools source - that was a mistake on my part, I have corrected the access, it should work now.
bluez-tools source - that was a mistake on my part, I have corrected the access, it should work now.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]
Not had much time, however....
I have managed to get somewhere.... Just not a full solution...
I have used the debian bluez-5 package, and made sure it is fully patched. This allows me to connect the bluetooth, however it is not loading the firmware
root:~# hciattach /dev/ttyAMA0 bcm43xx-3wire 921600 noflow -
bcm43xx_init
Set Controller UART speed to 921600 bit/s
Flash firmware /lib/firmware/brcm/BCM43430A1.hcd
Initialization timed out.
root:~# hciconfig
root:~# hciattach /dev/ttyAMA0 bcm43xx-3wire 921600 noflow -
bcm43xx_init
Patch not found, continue anyway
Set Controller UART speed to 921600 bit/s
Device setup complete
root:~# hciconfig
hci0: Type: Primary Bus: UART
BD Address: E0:76:D0:DE:EE:2B ACL MTU: 1021:8 SCO MTU: 64:1
UP RUNNING PSCAN
RX bytes:978 acl:0 sco:0 events:41 errors:0
TX bytes:1541 acl:0 sco:0 commands:41 errors:0
The second hciattach connects it, but it is not healthy. It will then connect through the default soundcard settings, and produces sounds in a stuttering fashion before stopping
Is this a case if nothing else supporting bluez5 properly? I suspect not at this point, and will keep trying to get the firmware upload working
I have managed to get somewhere.... Just not a full solution...
I have used the debian bluez-5 package, and made sure it is fully patched. This allows me to connect the bluetooth, however it is not loading the firmware
root:~# hciattach /dev/ttyAMA0 bcm43xx-3wire 921600 noflow -
bcm43xx_init
Set Controller UART speed to 921600 bit/s
Flash firmware /lib/firmware/brcm/BCM43430A1.hcd
Initialization timed out.
root:~# hciconfig
root:~# hciattach /dev/ttyAMA0 bcm43xx-3wire 921600 noflow -
bcm43xx_init
Patch not found, continue anyway
Set Controller UART speed to 921600 bit/s
Device setup complete
root:~# hciconfig
hci0: Type: Primary Bus: UART
BD Address: E0:76:D0:DE:EE:2B ACL MTU: 1021:8 SCO MTU: 64:1
UP RUNNING PSCAN
RX bytes:978 acl:0 sco:0 events:41 errors:0
TX bytes:1541 acl:0 sco:0 commands:41 errors:0
The second hciattach connects it, but it is not healthy. It will then connect through the default soundcard settings, and produces sounds in a stuttering fashion before stopping
Is this a case if nothing else supporting bluez5 properly? I suspect not at this point, and will keep trying to get the firmware upload working
I seem to have messed it all up somewhere, and now it totally fails on every attempt....
I will have to save off the useful bits and delete my save file. Am I correct in thinking that that will take me back mostly to a fresh install in effect?
That will also limit any confusion over what I did and didn't do..
I will have to save off the useful bits and delete my save file. Am I correct in thinking that that will take me back mostly to a fresh install in effect?
That will also limit any confusion over what I did and didn't do..
Re: arm64
Hi guys,Olle wrote:Maybe useful to have devuan_jessie_1.0.0-beta2_arm64_raspi3 as a benchmark for the eventual future FatDogArm64?
Found this https://github.com/bamarni/pi64/releases
Tried the first and second release but got no sound.
Happy linuxing! Olle
They seem to be making some good headway, The Official builders working with ARM have stated they only wish to maintain 32bit builds, but with the results of some effort in the communities around 64bitness and some very logical arguments, and now tested real world on the board results (30% increase raw speed), those same official guys unofficially cheering on the communities effort.
Looks like the real reason was 32bit internal GPU DMA-pipeline issues, that looked real ugly to those with advanced internal builder knowledge. But others have made good and not too drastic work-rounds and methods based on the hard 4G memory boundary. turned a hardware limitation into a bit fix solution that looks like a solid solution with very little code overhead/changes.
The 4G memory bounds is the end of 32bit space, all 64bit memory related pointers will naturally be only 32bit ignoring the top RAM address bit.
Can't follow exactly but best I can tell the top bit-set/cleared is used as a flag that the pointers are from 64bit space kernel, that any 32-64bit conversion needs to be done.
New thinking is with the Pi3 and newer v Pi2B based on the same chip move to 64bit , it would make a 32bit step backward to PiZero-Pi+ as one 32 bit kernel and PiB2v2, pi3 and future as 64bit kernel. It would press old first gen. PiB2+ back to lowest common 32bit kernel.
That seems like a real solution and keeps only two kernel versions supported which is already currently just two based on different ARM versions.
Next two to be based on 32/64 versions, if no other issues come as they are actively and with now some interest from the official group providing feedback, making forward looking patches to kernel to make GPU work seemlessly regardless of kernel bit size.
Take a look at popcornmixs' flurry of related posts and he has caught the 64bit bandwagon and GPU related 'fixes' needed to make it happen.
Looks like the real reason was 32bit internal GPU DMA-pipeline issues, that looked real ugly to those with advanced internal builder knowledge. But others have made good and not too drastic work-rounds and methods based on the hard 4G memory boundary. turned a hardware limitation into a bit fix solution that looks like a solid solution with very little code overhead/changes.
The 4G memory bounds is the end of 32bit space, all 64bit memory related pointers will naturally be only 32bit ignoring the top RAM address bit.
Can't follow exactly but best I can tell the top bit-set/cleared is used as a flag that the pointers are from 64bit space kernel, that any 32-64bit conversion needs to be done.
New thinking is with the Pi3 and newer v Pi2B based on the same chip move to 64bit , it would make a 32bit step backward to PiZero-Pi+ as one 32 bit kernel and PiB2v2, pi3 and future as 64bit kernel. It would press old first gen. PiB2+ back to lowest common 32bit kernel.
That seems like a real solution and keeps only two kernel versions supported which is already currently just two based on different ARM versions.
Next two to be based on 32/64 versions, if no other issues come as they are actively and with now some interest from the official group providing feedback, making forward looking patches to kernel to make GPU work seemlessly regardless of kernel bit size.
Take a look at popcornmixs' flurry of related posts and he has caught the 64bit bandwagon and GPU related 'fixes' needed to make it happen.