LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware > Slackware - ARM
User Name
Password
Slackware - ARM This forum is for the discussion of Slackware ARM.

Notices


Reply
  Search this Thread
Old 03-13-2019, 02:07 PM   #16
SCerovec
Senior Member
 
Registered: Oct 2006
Location: Cp6uja
Distribution: Slackware on x86 and arm
Posts: 1,495
Blog Entries: 2

Rep: Reputation: 335Reputation: 335Reputation: 335Reputation: 335

Quote:
Originally Posted by abga View Post
Tried it and it didn't work, see the be beginning of my last post.


Do you happen to know a different way to enable the ACT (green) LED in firmware, before running the kernel and keep it persistent during the kernel LED drivers load? Because it's the kernel that seems to break the LED functionality.
I am totally here off the top of my head - I so far didn't try nothing too exotic with my Raspberries...

But when i played with my Oragne PI zero, i found that by tweaking the dtb file in /boot/ i could enable and disable stuff that otherwise has to wait the boot to end first.

2nd file "dtedit" was used when tweaking said stuff

HTH
 
Old 03-13-2019, 04:20 PM   #17
Dunc.
LQ Newbie
 
Registered: Jul 2012
Location: Cumbria UK
Distribution: Slackware
Posts: 14

Rep: Reputation: Disabled
I did note that the wifi was not working due to the lack firmware but as I live in a house with thick walls, wifi has a tough time. I have put ethernet in most of the rooms.
The led is defined in the device tree overlay to be a heartbeat. You can re-assign it using the sysfs. I am re-compiling the kernel with
CONFIG_LEDS_TRIGGER_DISK=y
CONFIG_LEDS_TRIGGER_MTD=y
I will test the disk activity one. I think the MTD one only applies to NAND type storage and not the SD card but I will test that too.
 
Old 03-13-2019, 07:04 PM   #18
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 945

Original Poster
Rep: Reputation: 493Reputation: 493Reputation: 493Reputation: 493Reputation: 493
Quote:
Originally Posted by drmozes View Post
The last config option comes from a patch I assume ? (going by the comment!)
I will look at adding the others, but I won't be adding any patches for the RPi.
Yes, +CONFIG_CLK_RASPBERRYPI_CPU=y is for activating the patch you are already applying:
ftp.arm.slackware.com/slackwarearm/slackwarearm-current/source/k/sources/patches/bcm2835-cpufreq-add-CPU-frequency-control-driver.patch.xz
So, don't say you won't apply any patches
This CPU frequency control driver (patch) is also the last (and outstanding issue) point I got stuck with, described in my post #6 -> "Not working:" section, second item (the first one was the green LED - resolved meanwhile). There must be some additional step or something extra that is needed to be added to the Makefile from the kernel source subfolder linux/drivers/clk/bcm/ , in order to create those modules, they're built (.o files present) but no .ko files are generated & installed.
I was about to ask you where you got that bcm2835-cpufreq-add-CPU-frequency-control-driver.patch.xz patch from and if you are able to recall on which kernel version you first applied it and if it's still up to date.
But I found out on my own that it's apparently coming from here (and it's the Upstream - OPP version):
https://github.com/lategoodbye/rpi-zero/issues/32
- it works well, doesn't know intermediate frequencies, just low&high (which is OK with me)
- and there's another extra patch in that github thread for the Pi3B & Pi3B+ boards - apparently to cool them down:
https://github.com/lategoodbye/rpi-z...e-3B.patch.txt

Now, enabling only those kernel options you quoted, without any patching, won't be of any good. The patches I presented are only for the kernel Makefiles, to integrate & build the RPi specific device tree overlays and there are some device tree source files patches, again, affecting only the Rpi ones. There's no kernel source code patching.
The only kernel option I'm a little concerned about is: CONFIG_RASPBERRYPI_FIRMWARE=y. I was asking myself in the other post, what happens if you boot a kernel with this option enabled, on a non-RPi platform without the RPi firmware available. I can't test this as I don't own any non-Rpi ARM boards.

Maybe you missed this section related to the already patched files in my post #6:
Quote:
I don't know how to paste the patches here on LQ without breaking the indentation (tabs), therefore I collected and archived all the properly patched files + the last kernel .config file I used:
- file patched-files-kernel-config.tgz
https://www52.zippyshare.com/v/aiJyDcwI/file.html
Code:
sha256sum patched-files-kernel-config.tgz
fdfeac425ca8afd29c7764193cf307928e7c58dd64188e8ea1646d2cb1817f77  patched-files-kernel-config.tgz
- the paths, relative to the kernel source top tree, for the patched files are embedded in the file names, "-" represents the "/" for the sub folders
- if you like (and know how), you can create one (correct format) patch for all of them
- for the kernel .config file - I disabled pretty much all the other SoCs & platforms, disabled PCI support, enabled all the DVB stuff for my needs (never sure about the i2c/tuners/frontends I need) and enabled a lot of stuff in the Networking section. Compilation time on Raspberry Pi2B 2:30 to 3 hours.

Last edited by abga; 03-13-2019 at 07:41 PM. Reason: rewording-clarifications
 
Old 03-13-2019, 07:35 PM   #19
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 945

Original Poster
Rep: Reputation: 493Reputation: 493Reputation: 493Reputation: 493Reputation: 493
@Dunc.

This is from the Raspberry official "live" kernel (the one extracted from Raspbian):
Code:
#
# MMC/SD/SDIO Host Controller Drivers
#
#...
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y
#...
#and then the only one option enabled in:
## LED drivers
# is:
CONFIG_LEDS_GPIO=y
#...
# LED driver for blink(1) USB RGB LED is under Special HID drivers (HID_THINGM)
#
# CONFIG_LEDS_BLINKM is not set
# CONFIG_LEDS_SYSCON is not set
#
# LED Triggers
#
CONFIG_LEDS_TRIGGERS=y
CONFIG_LEDS_TRIGGER_TIMER=y
CONFIG_LEDS_TRIGGER_ONESHOT=y
CONFIG_LEDS_TRIGGER_HEARTBEAT=y
CONFIG_LEDS_TRIGGER_BACKLIGHT=y
CONFIG_LEDS_TRIGGER_CPU=y
CONFIG_LEDS_TRIGGER_GPIO=y
CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
As you can see, they have CONFIG_LEDS_TRIGGER_HEARTBEAT=y enabled. I used exactly the same options as presented above, just disabled CONFIG_LEDS_TRIGGER_HEARTBEAT and I got rid of the constant heartbeat blinking, but the SDCard activity didn't show up until I enabled it in /sys/class/leds/ACT/trigger
I guess, you can keep the CONFIG_LEDS_TRIGGER_HEARTBEAT=y and just enable the mmc0 in /sys/class/leds/ACT/trigger - see my post #12 for the details.



@SCerovec

I tried to tell the device tree to enable the SDcard activity with my two lines in /boot/config.txt:
Code:
dtparam=act_led_trigger=mmc
dtparam=act_led_activelow=off
That didn't work and as far as I understood it, that should be the default setup anyways - my two lines were useless/just reconfirming the defaults.

Then, when I booted and ran:
Code:
cat /sys/class/leds/ACT/trigger
I noticed (in that long line output) the "[mmc0]" as the only one in brackets - as if it was already enabled. I had to enable it (re-enable I guess) to make it work with:
Code:
echo mmc0 | tee /sys/class/leds/ACT/trigger
I believe that the kernel overrides whatever the device tree sets up in HW. Frankly, I'm OK with this /sys/class/leds/ACT/trigger workaround, not sure I need the LED blinking while loading the kernel.
- see (again) my post #12 for the details
I'm not against modding the device tree files, but I'm also not very experienced with the Raspberries & device tree files, TBH, not sure it's worth the effort.
 
Old 03-13-2019, 08:13 PM   #20
SCerovec
Senior Member
 
Registered: Oct 2006
Location: Cp6uja
Distribution: Slackware on x86 and arm
Posts: 1,495
Blog Entries: 2

Rep: Reputation: 335Reputation: 335Reputation: 335Reputation: 335
@abga
Same here
 
Old 03-14-2019, 02:11 AM   #21
Dunc.
LQ Newbie
 
Registered: Jul 2012
Location: Cumbria UK
Distribution: Slackware
Posts: 14

Rep: Reputation: Disabled
Quote:
Are the resulting device tree files residing in your /boot/dtbs/ folder now? And then in your /boot/config.txt you pointed at them by using device_tree=dtbs/whatever-RPI-model.dtb ?
As you say the dtbs files are in /boot/dtbs/. I mount the first FAT partition on /boot. The config.txt bit looks like this.
Code:
kernel=vmlinuz-5.0.0
device_tree=dtbs/5.0.0/bcm2837-rpi-3-b.dtb
avoid_warnings=2
I changed nothing in the /boot directory so I just comment out the 3 lines and I am back to a standard so of setup.
 
Old 03-14-2019, 06:50 AM   #22
drmozes
Slackware Contributor
 
Registered: Apr 2008
Location: Surrey, England
Distribution: Slackware
Posts: 790

Rep: Reputation: 596Reputation: 596Reputation: 596Reputation: 596Reputation: 596Reputation: 596
Quote:
Originally Posted by abga View Post
Yes, +CONFIG_CLK_RASPBERRYPI_CPU=y is for activating the patch you are already applying:
ftp.arm.slackware.com/slackwarearm/slackwarearm-current/source/k/sources/patches/bcm2835-cpufreq-add-CPU-frequency-control-driver.patch.xz
So, don't say you won't apply any patches
I took that from Fedora when I was looking for patches for H3 to fix some stability issues. I wasn't particularly in a judicious mood at that point, so I took other patches which weren't related to the problem in hand. If I'd have actually given a little more time scrutinizing that patch, I'd never have included it! :-)
It looks like the same version of the patch is still applied in Fedora.

Quote:
This CPU frequency control driver (patch) is also the last (and outstanding issue) point I got stuck with, described in my post #6 -> "Not working:" section, second item (the first one was the green LED - resolved meanwhile). There must be some additional step or something extra that is needed to be added to the Makefile from the kernel source subfolder linux/drivers/clk/bcm/ , in order to create those modules, they're built (.o files present) but no .ko files are generated & installed.
I was about to ask you where you got that bcm2835-cpufreq-add-CPU-frequency-control-driver.patch.xz patch from and if you are able to recall on which kernel version you first applied it and if it's still up to date.
I don't know when I applied it (before Xmas last year, I imagine).

The 4.19 Kernel is stable for me, so I don't want to add anything to it that complicates anything for systems that aren't supported or testable by me.

Quote:
Now, enabling only those kernel options you quoted, without any patching, won't be of any good. The patches I presented are only for the kernel Makefiles, to integrate & build the RPi specific device tree overlays and there are some device tree source files patches, again, affecting only the Rpi ones. There's no kernel source code patching.
I pushed out the latest update with most of them enabled (and some were already present, but were as modules, or compiled-in already). If further patching is required to make use of them, it just means that eventually the Kernel will have the options set ready for when the support is merged into later Kernel releases.
I cannot get CONFIG_CLK_RASPBERRYPI_CPU to become exposed in 'menuconfig', so I've skipped it.

Quote:
The only kernel option I'm a little concerned about is: CONFIG_RASPBERRYPI_FIRMWARE=y. I was asking myself in the other post, what happens if you boot a kernel with this option enabled, on a non-RPi platform without the RPi firmware available. I can't test this as I don't own any non-Rpi ARM boards.
I'm not sure any more. I used to compile the RTL firmware in to the Kernel for the Tegra20, but I stopped that and bundle it in with a/kernel-firmware package.
There's also brcm80211 included within a/kernel-firmware.
I think it just means that the Kernel is _able_ to load the firmware if the Kernel detects that it's running on suitable hardware.
Either way, it's ok because I added the config option the latest batch and it's fine :-)
 
Old 03-14-2019, 04:13 PM   #23
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 945

Original Poster
Rep: Reputation: 493Reputation: 493Reputation: 493Reputation: 493Reputation: 493
Quote:
Originally Posted by Dunc. View Post
As you say the dtbs files are in /boot/dtbs/. I mount the first FAT partition on /boot. The config.txt bit looks like this.
Code:
kernel=vmlinuz-5.0.0
device_tree=dtbs/5.0.0/bcm2837-rpi-3-b.dtb
avoid_warnings=2
I changed nothing in the /boot directory so I just comment out the 3 lines and I am back to a standard so of setup.
@Dunc.

In my post #11 I just wanted to understand the steps you took for building the 5.0 kernel. You said previously that you have followed the Gentoo WiKi HowTo:
https://wiki.gentoo.org/wiki/Raspber...ainline_Kernel
And I was wondering if you needed to manually grab the overlays, apply the patches I was describing in my posts 5# & 6#, to integrate these overlays, and to patch the bcm283x.dtsi for loading the audio driver bcm2835-audio

Without the overlays integration patches under 4.19.25, the following:
Code:
make dtbs
make dtbs_install
won't build the overlays and it won't install them.

Furthermore, even if I documented the scripts/Makefile.dtbinst patch in my post #5, that's for installing the overlays, I haven't actually used it - I didn't call it with: make dtbs_install
Instead, I just used the manual approach.
Code:
cp -f arch/arm/boot/dts/bcm283*.dtb /boot/
mkdir -p /boot/overlays/
cp -f arch/arm/boot/dts/overlays/*.dtb* /boot/overlays/
cp -f arch/arm/boot/dts/overlays/README /boot/overlays/
I'm planning to switch to 5.0 / 5.1 myself over the weekend and I might answer these questions on my own, but considered your feedback useful.

Quote:
I changed nothing in the /boot directory
Well, I notice that you are using the /boot/dtbs/ folder for you dtb files. Was this folder created automatically by make dtbs_install ?
If so, where is your overlays folder located? Or do you actually have one? /boot/overlays - or /boot/dtbs/overlays?
 
Old 03-14-2019, 04:51 PM   #24
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 945

Original Poster
Rep: Reputation: 493Reputation: 493Reputation: 493Reputation: 493Reputation: 493
Quote:
Originally Posted by drmozes View Post
I took that from Fedora when I was looking for patches for H3 to fix some stability issues. I wasn't particularly in a judicious mood at that point, so I took other patches which weren't related to the problem in hand. If I'd have actually given a little more time scrutinizing that patch, I'd never have included it! :-)
It looks like the same version of the patch is still applied in Fedora.
Thanks! That's a 5.1 kernel and I'll take a look at it during the weekend, curious on how it integrates the bcm2835-cpufreq-add-CPU-frequency-control-driver.patch
Maybe CONFIG_CLK_RASPBERRYPI_CPU is not supposed to show up in menuconfig at all, I'm just looking after the compilation&installation of the drivers in linux/drivers/clk/bcm/ , that's what counts.

Quote:
Originally Posted by drmozes View Post
The 4.19 Kernel is stable for me, so I don't want to add anything to it that complicates anything for systems that aren't supported or testable by me.
Again, without the overlays files, the kernel only RPi integration, that's only enabling some modules, is just wasted time&effort.
These device tree overlays are open source:
https://github.com/raspberrypi/linux.../dts/overlays/
Only RPi specific and actually inert files, can't break anything, will just reside there in in /boot/dtb/overlays and wait to be called by the RPi specific device tree files, that you're already building & providing, for enabling & configuring RPi onboard hardware&functionalities.
The RPi source overlays files need to be present in the kernel source tree and built together with the RPi device tree binaries. Well, you might be able to rebuild them afterwards, but that makes again the already compiled and distributed kernel pointless to use in the first place.
I doubt that the Raspberry Foundation will ever change this device tree binaries - device tree overlays structure in the future and the support for RPi will always imply to integrate the overlays. I also doubt that the mainstream kernel is interested in this integration.

Still not sure why you don't own a RPi board, but now I cannot recommend the ones available because I wouldn't buy a Pi3B for myself...
Pi2B v1.1 is not available anymore (I'm only left with 2 boards on which I "depend" on) and in the Pi2B v1.2 they already soldered the "reliable" BCM2837 SoC
https://uk.farnell.com/raspberrypi-b...k-pi-2-model-b
I could donate a Pi Zero board (I own 3 already) if that would help you, still, armv6 - so, no use for armv7 kernel builds.
Quote:
Originally Posted by drmozes View Post
I'm not sure any more. I used to compile the RTL firmware in to the Kernel for the Tegra20, but I stopped that and bundle it in with a/kernel-firmware package.
There's also brcm80211 included within a/kernel-firmware.
I think it just means that the Kernel is _able_ to load the firmware if the Kernel detects that it's running on suitable hardware.
Either way, it's ok because I added the config option the latest batch and it's fine :-)
Thanks for testing the kernel with CONFIG_RASPBERRYPI_FIRMWARE=y on another non RPi ARM platform. I wasn't sure either and was about to have a look in the source code

Will play with the 5.x kernel over the weekend, maybe the overlays integration patches are not required anymore (unlikely). Wondering if some not yet released longterm 5.x will be the kernel for Slackware 15, since Linus ran out of fingers and toes to count the 4.x subversions & 4.19 will be EOL already next year.

Last edited by abga; 03-14-2019 at 05:06 PM. Reason: typo - extra [/QUOTE]
 
Old 03-15-2019, 06:26 AM   #25
drmozes
Slackware Contributor
 
Registered: Apr 2008
Location: Surrey, England
Distribution: Slackware
Posts: 790

Rep: Reputation: 596Reputation: 596Reputation: 596Reputation: 596Reputation: 596Reputation: 596
Quote:
Originally Posted by abga View Post

Again, without the overlays files, the kernel only RPi integration, that's only enabling some modules, is just wasted time&effort.
It's already done so I'm relaxed about it all, and I added some more stuff that might be useful at the same time.

Quote:
Originally Posted by abga View Post
These device tree overlays are open source:
https://github.com/raspberrypi/linux.../dts/overlays/
Only RPi specific and actually inert files, can't break anything, will just reside there in in /booI don't know much about the RPi upstreamt/dtb/overlays and wait to be called by the RPi specific device tree files, that you're already building & providing, for enabling & configuring RPi onboard hardware&functionalities.
The RPi source overlays files need to be present in the kernel source tree and built together with the RPi device tree binaries. Well, you might be able to rebuild them afterwards, but that makes again the already compiled and distributed kernel pointless to use in the first place.

I doubt that the Raspberry Foundation will ever change this device tree binaries - device tree overlays structure in the future and the support for RPi will always imply to integrate the overlays. I also doubt that the mainstream kernel is interested in this integration.

Still not sure why you don't own a RPi board
You said one of the reasons above. The RPi foundation is great at marketing, but the first RPi was already 'old tech' when it was released. I simply have no interest in the hardware, and the software ecosystem isn't standard. I maintained three Kernels at one point, and it's time consuming to maintain, build then test.
Then when the patches fail to apply, I'm either locked in to an old Kernel (which isn't an option) or I cut loose all the invested time.
The RPi is a total non-starter as it stands.

Even if the patches don't modify the Kernel source, if they mess up anything else that I'm using (that happens, believe me) then that'd be incredibly irritating for me.
I don't know much about the RPi upstream, but from what I have seen so far and from my almost twenty years experience of this thing is that I won't spend time on something that I have no personal interest in, that could break the stuff I use myself. However, if the relevant support appears in the mainline Kernel and enabling it doesn't break anything, I'm fine with that because there's the indication that it's going to be tested/maintained upstream. This is still an assumption that can bite you in the ass because some developers just ensure that the code _compiles_ -- that doesn't mean it _works_. I've been through that one before with device drivers for old Acorn hardware. This is unlikely with the RPi though due to the size of the user base.

I'm not sure I like the idea of overlay files polluting the Kernel package either, but I'd need to look at that to see how much work it is.

Quote:
Originally Posted by abga View Post
.
Wondering if some not yet released longterm 5.x will be the kernel for Slackware 15, since Linus ran out of fingers and toes to count the 4.x subversions & 4.19 will be EOL already next year.
There perhaps are some major changes coming to Slackware but I don't know if they'll make it into 15.0. Without any timings, I have no idea about the Kernel version that will be provided for 15.0 yet.

Last edited by drmozes; 03-15-2019 at 06:32 AM.
 
Old 03-15-2019, 03:40 PM   #26
Exaga
Member
 
Registered: Nov 2012
Posts: 128

Rep: Reputation: Disabled
Quote:
Originally Posted by drmozes View Post
You said one of the reasons above. The RPi foundation is great at marketing, but the first RPi was already 'old tech' when it was released. I simply have no interest in the hardware, and the software ecosystem isn't standard. I maintained three Kernels at one point, and it's time consuming to maintain, build then test.
I disagree with you on the RPi Foundation's marketing acumen because they're not bad, but they're certainly not great. Couldn't agree with you more on the 'old tech' shizzle. The popularity of the RPi device on its initial release crashed the website(s) where it was being sold, in a frenzy that has never been seen before or since in ARM circles. With that amount of interest in an unremarkable device that was already out of date [technology-wise], underpowered with only 256MB RAM, and not endowed with any outstanding features, you could pretty much market anything and expect your loyal minions to spend their money on it. Prime example, look at how many RPi Zero users there are!

For me the RPi devices are toys to play around and test with. I wouldn't use them for any serious applications. I found that they are extremely good when used as educational tools on which to learn the ins and outs of Slackware ARM. Obviously for you that's superfluous.

"The software ecosystem isn't standard." is a VERY diplomatic way of putting it. HAHAHA!
 
Old 03-15-2019, 08:18 PM   #27
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 945

Original Poster
Rep: Reputation: 493Reputation: 493Reputation: 493Reputation: 493Reputation: 493
Quote:
Originally Posted by drmozes View Post
It's already done so I'm relaxed about it all, and I added some more stuff that might be useful at the same time.
Yes you did and with these things you added you started supporting all the basic functions of the RPi boards Pi2B&Pi3B(+), all except the GPIO stuff and the OpenGL support.
Whatever is configured at boot with the use of:
dtparam=
is calling the functions defined in the device tree binaries bcm283*.dtb that are already built and installed in the mainstream (your) kernel.

Any other configuration that requires:
dtoverlay=
will not work, because the overlays aren't there, some examples:
OpenGL driver
dtoverlay=vc4-kms-v3d
GPIO IR (I'm personally using this)
dtoverlay=gpio-ir,gpio_pin=17,rc-map-name=rc-empty
And many other GPIO extensions and HATs.

You said in one of you previous posts:
Quote:
so I don't want to add anything to it that complicates anything for systems that aren't supported or testable by me
And that's what made me wonder about why are you not owning a Rpi board, at least one to test on, since these RPi devices are apparently still the most common among the Slackware ARM users (community) here in this forum. Offered to help you with what I can - a Pi Zero. Ironically, maybe you remember, as I first got a Pi Zero, I didn't know what to do with it and now I own 3 already. A perfect toy to tinker with, dirt cheap, stable, reliable and powerful enough to handle whatever traffic goes through the GPIO, not to mention - it runs Kodi very well.
I'm part-time freelancing and I used the Pi2B in businesses for small applications, basically: VPN gateways, point of access, command & control hosts for automated jobs and scripting, substituting what OpenWRT is unable to offer and those constantly vulnerable SOHO routers (like CISCO) and finally some small web servers and analytical databases (Postgresql). Rpi2B is perfect for these, not that much the Rpi3, which due to the overheating & throttling is totally unreliable, I cannot make any performance commitments to my customers. What can I commit to? Tell the customer, it'll handle 5 concurrent VPN connections at 20Mbps ... well, for the first 3 minutes, unless you put a 3 time its size aluminum cooler over that crappy SoC, or a tiny mechanical fan that you need to clean/exchange every month or so. Useless.

Quote:
Originally Posted by drmozes View Post
I'm not sure I like the idea of overlay files polluting the Kernel package either, but I'd need to look at that to see how much work it is.
If you consider "polluting" it, I did already provide all the info in the post #5 & #6 from this thread and I'm still here to help.

Without quoting the whole block, I agree with you on all the points you described related to the kernel patches and yes the things at Raspberry are pretty messy (their kernel & firmware development on github), scary at times too. It's better to be cautious.
There are efforts to put all their specific stuff in the mainstream:
https://www.raspberrypi.org/forums/v...c.php?t=224931
Not sure about the overlays, maybe they'll ditch them and use only the device tree binaries instead.

Will load & play with your updated kernel_armv7-4.19.28 and also try a 5.x compilation - looking to understand and integrate that bcm2835-cpufreq-add-CPU-frequency-control-driver.patch during this weekend and will report back.


P.S. An anecdote - As I ordered my last few Pi2B boards, back in 2017, the company I placed the order with told me that they ran out of these boards because a big slot machine manufacturer bought all the Rpi2B they had on stock. I just thought, well, this Raspberry stuff is really educational ... in slot machines The younglings will learn about risk aversion while playing Poker on Raspberry Pi2B
 
Old 03-16-2019, 07:23 AM   #28
SCerovec
Senior Member
 
Registered: Oct 2006
Location: Cp6uja
Distribution: Slackware on x86 and arm
Posts: 1,495
Blog Entries: 2

Rep: Reputation: 335Reputation: 335Reputation: 335Reputation: 335
ever considered the mainstream capable Orange PI zero?
 
Old 03-16-2019, 02:20 PM   #29
drmozes
Slackware Contributor
 
Registered: Apr 2008
Location: Surrey, England
Distribution: Slackware
Posts: 790

Rep: Reputation: 596Reputation: 596Reputation: 596Reputation: 596Reputation: 596Reputation: 596
Quote:
Originally Posted by abga View Post
And that's what made me wonder about why are you not owning a Rpi board, at least one to test on, since these RPi devices are apparently still the most common among the Slackware ARM users (community) here in this forum.
For the same reason that if someone kindly offered me tickets to a football game, I'd politely decline because someone else would enjoy them more than I.
I created Slackware ARM for myself, and choose to make it available. Even if nobody but me used it (which was the case for sure, for the first few years) I'd still develop it because I like it. It's not a commercial venture so there's no incentive to spend time on anything I don't like.
If there's anything interesting feedback that arrives that piques my interests and fits within my available time, I hack on it.
 
Old 03-16-2019, 03:58 PM   #30
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 945

Original Poster
Rep: Reputation: 493Reputation: 493Reputation: 493Reputation: 493Reputation: 493
@SCerovec
https://www.linuxquestions.org/quest...5/#post5959522

@drmozes
I didn't know too much about the history of the Slackware ARM port, but only what you told me in another thread about AlienBob's initial approach.
Personally, I'm thankful for your efforts and for sharing your work with the Slackware community, compiling, patching and maintaining the main x86 Slackware distro into ARM, hope you enjoy doing it, for now & in the future.
I'm also sharing the knowledge I gain from my personal projects here in the Slack ARM forum, kind of following the idea -> take a little - give back a little. Not sure for how long I'll still be able to do that, mainly because the ARM stuff (latest HW developments) started to become uninteresting for me. Will keep on hacking on my available RPi toys until they're supported.

Busy with the 5.0 kernel compilation for RPi right now, hope tomorrow I'll have some more info.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] KODI Leia - 18.x MediaPlayer - Optimized for Raspberry Pi1/Zero/Pi2B/Pi3B(+) on Slackware ARM 14.2 SF & Slackware ARM - current HF abga Slackware - ARM 7 02-17-2019 01:54 PM
[SOLVED] KODI Krypton - 17.x MediaPlayer - Optimized for Raspberry Pi1/Pi2/Pi3 on Slackware ARM 14.2 SF & Slackware ARM - current HF abga Slackware - ARM 40 08-28-2018 08:50 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware > Slackware - ARM

All times are GMT -5. The time now is 11:55 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration