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

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.

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:

@Dunc.

This is from the Raspberry official "live" kernel (the one extracted from Raspbian):
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:
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:
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:
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.

@abga
Same here

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.
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.

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.

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.

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.

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 :-)

@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:
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.
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.

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?

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.

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.
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.

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.

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.

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.

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!

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:
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.

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

ever considered the mainstream capable Orange PI zero?

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.

@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.