Kernel 4.1.9 overlays not working

[bremenpl]

Hello there,

I have installed latest console version of Debian from eLinux.org. Its uses kernel version 4.1.9:

Linux beaglebone 4.1.9-ti-r20 #1 SMP PREEMPT Fri Oct 2 05:35:56 UTC 2015 armv7l GNU/Linux

I was trying to load BB-UART5 overlay but I failed. I also dont see any overlays loaded I thought I would, like eMMC:

root@beaglebone:/sys/devices/platform/bone_capemgr# cat slots
 0: PF----  -1
 1: PF----  -1
 2: PF----  -1
 3: PF----  -1

When I tried to load the tree i got:

[ 3013.532495] bone_capemgr bone_capemgr: part_number 'BB-UART5', version 'N/A'
[ 3013.532543] bone_capemgr bone_capemgr: slot #4: override
[ 3013.532561] bone_capemgr bone_capemgr: Using override eeprom data at slot 4
[ 3013.532579] bone_capemgr bone_capemgr: slot #4: 'Override Board Name,00A0,Override Manuf,BB-UART5'
[ 3013.533110] __of_adjust_tree_phandle_references: Could not find target property 'fixup' @/__local_fixups__
[ 3013.548518] bone_capemgr bone_capemgr: slot #4: Failed to resolve tree

And I have compiled the tds before and put the dtbo in /lib/firmware/

Has anything changed in the new kernel regarding dts loading and general usage?

I would apreciate all help regarding this topic!

[Andreas Müller]

> --
Am not sure: Did you compile dts with the patched version of dtc?

Andreas

[Bremenpl]

I used dtc in version 1.4.0 i believe.

[Andreas Müller]

On Mon, Oct 12, 2015 at 11:51 AM, Bremenpl <brem...@gmail.com> wrote:
> I used dtc in version 1.4.0 i believe.
>
>

> --
> For more options, visit http://beagleboard.org/discuss
> --- You received this message because you are subscribed to the Google
> Groups "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
To make overlays build properly, you need a special version of dtc
found at [1] further details see [2]

[1] https://github.com/pantoniou/dtc
[2] https://github.com/beagleboard/bb.org-overlays

Andreas

[Bremenpl]

I will try this out, thank you.

W dniu 2015-10-12 o 11:58, 'Andreas Müller' via BeagleBoard pisze:

--
Bremenpl

[Bremenpl]

Im sorry but I cant find any source on how to install the dtc compiller
after I have downloaed it from http://devicetree.org/Device_Tree_Compiler

W dniu 2015-10-12 o 11:58, 'Andreas Müller' via BeagleBoard pisze:

--
Bremenpl

[Bremenpl]

I think I managed to do everything, thank you.
There is still one thing that differs from version 3.8 kernel- I dont
see either hdmi/emmc was disabled or not by looking at the slots. How
can I check that?

W dniu 2015-10-12 o 11:58, 'Andreas Müller' via BeagleBoard pisze:

--
Bremenpl

[l...@pinkfroot.com]

I am also getting the same error with 4.1.9-ti-r20, what exactly did you do to fix it?

[Bremenpl]

Hi, I have followed this link: https://github.com/beagleboard/bb.org-overlays
It doesnt say it in there, but after the steps with update_kernel.sh, you have to clone the directory https://github.com/beagleboard/bb.org-overlays.git and go into it for the next steps.

W dniu 2015-10-13 o 16:36, l...@pinkfroot.com pisze:

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/TxDp4lq_BXs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

-- 
Bremenpl

[Robert Nelson]

On Tue, Oct 13, 2015 at 9:36 AM, <l...@pinkfroot.com> wrote:
> I am also getting the same error with 4.1.9-ti-r20, what exactly did you do
> to fix it?
>
> On Monday, October 12, 2015 at 11:50:57 AM UTC+1, bremenpl wrote:
>>
>> I think I managed to do everything, thank you.
>> There is still one thing that differs from version 3.8 kernel- I dont
>> see either hdmi/emmc was disabled or not by looking at the slots. How
>> can I check that?

Guys, please read the readme.md and /boot/uEnv.txt for examples on how
to disable the "hdmi/emmc"..

https://github.com/beagleboard/bb.org-overlays/blob/master/readme.md

under: "BBB compatibility issues"

There are also other combinations listed in /boot/uEnv.txt

Regards,

--
Robert Nelson
https://rcn-ee.com/

[Robert Nelson]

On Tue, Oct 13, 2015 at 10:01 AM, Lee Armstrong <l...@pinkfroot.com> wrote:
> Thanks Robert,
>
> I am simply trying to enable UART4 which I didn’t think needed anything
> disabling though?

in /boot/uEnv.txt

cape_enable=bone_capemgr.enable_partno=BB-UART4

and reboot. ;)

(this is assuming /lib/firmware/BB-UART4-00A0.dtbo is installed)

[Robert Nelson]

On Tue, Oct 13, 2015 at 10:09 AM, Lee Armstrong <l...@pinkfroot.com> wrote:
> Thanks Robert,
>

> BB-UART4-00A0.dtbo is present in /lib/firmware. I’ve not had an issue
> before but this is a freshly flashed Jessie BBB.
>
> dmesg shows the following which is the same error as per the first post when
> echoing into the slots.
>
> [ 4.968908] __of_adjust_tree_phandle_references: Could not find target
> property 'fixup' @/__local_f
> ixups__
> [ 4.979738] bone_capemgr bone_capemgr: slot #4: Failed to resolve tree
> [ 4.987236] bone_capemgr bone_capemgr: loader: failed to load slot-4
> BB-UART4:00A0 (prio 0)

That means you have the wrong dtc compiler..

You need to re-do step 2 & 3:

https://github.com/beagleboard/bb.org-overlays/blob/master/readme.md

(i just updated the readme.md to make it more useful... (i think..))

[Robert Nelson]

On Tue, Oct 13, 2015 at 10:20 AM, Lee Armstrong <l...@pinkfroot.com> wrote:
> Thanks Robert,
>

> I’ve just reflashed it again with the latest Jessie image and will run
> through those steps.
>
> One thing not 100% clear in the steps is the best location to get the latest
> (patched) DTC, there are many differing sources it seems!

I moved the "./dtc-overlay.sh" script right after the "check dtc" in
step 2... I'm hoping it should be more obvious to run it..

[Lee Armstrong]

Thanks Robert,

BB-UART4-00A0.dtbo is present in /lib/firmware.  I’ve not had an issue before but this is a freshly flashed Jessie BBB.

dmesg shows the following which is the same error as per the first post when echoing into the slots.

[    4.968908] __of_adjust_tree_phandle_references: Could not find target property 'fixup' @/__local_f

ixups__

[    4.979738] bone_capemgr bone_capemgr: slot #4: Failed to resolve tree

[    4.987236] bone_capemgr bone_capemgr: loader: failed to load slot-4 BB-UART4:00A0 (prio 0)

[Lee Armstrong]

Thanks Robert, 

I am simply trying to enable UART4 which I didn’t think needed anything disabling though?

Lee

[Lee Armstrong]

Thanks Robert, 

I’ve just reflashed it again with the latest Jessie image and will run through those steps.

One thing not 100% clear in the steps is the best location to get the latest (patched) DTC, there are many differing sources it seems!

Lee

[Lee Armstrong]

Robert,

Yes that is much better thank you.  Working well now :-)

Thank you very much,

Lee

[codemonkey]

Robert, I have the same question about the source of DTC 1.4.1-gXYZXYZXYZ - I installed the device-tree-overlay package into a new build (Linux beaglebone 4.1.10-bone-rt-r16 #1 Sun Oct 4 09:05:14 UTC 2015 armv7l GNU/Linux) and checked the version of dtc. It was v1.4.0. I tried running ./dtc_overlay.sh, but the version didn't change. So, I cloned the git repository of the source at devicetree.org, did a make and make install. The version is still 1.4.0. The only reference Google has to the string in your readme (DTC 1.4.1-gXYZXYZXYZ) points to your readme. 

Thank you

Tim

[Robert Nelson]

On Sun, Oct 18, 2015 at 8:42 PM, codemonkey <tea...@burfl.com> wrote:
> Robert, I have the same question about the source of DTC 1.4.1-gXYZXYZXYZ -
> I installed the device-tree-overlay package into a new build (Linux
> beaglebone 4.1.10-bone-rt-r16 #1 Sun Oct 4 09:05:14 UTC 2015 armv7l
> GNU/Linux) and checked the version of dtc. It was v1.4.0. I tried running
> ./dtc_overlay.sh, but the version didn't change. So, I cloned the git
> repository of the source at devicetree.org, did a make and make install. The
> version is still 1.4.0. The only reference Google has to the string in your
> readme (DTC 1.4.1-gXYZXYZXYZ) points to your readme.

It's installed too:

/usr/local/bin/

https://github.com/beagleboard/bb.org-overlays/blob/master/dtc-overlay.sh#L56

If it doesn't work, your PATH is mangled..

[William Hermans]

http://www.embeddedhobbyist.com/2015/09/beaglebone-black-updating-device-tree-files/

[Rick Mann]

> On Oct 18, 2015, at 20:38 , William Hermans <yyr...@gmail.com> wrote:
>
> http://www.embeddedhobbyist.com/2015/09/beaglebone-black-updating-device-tree-files/

apt-get update: "This step is important every reboot. As the /etc/apt/sources.list file is not kept on “disk”. This is meant to help keep writes to flash media at a minimum – In case you were wondering."

Wait, what? Why would this make sense? I write the flash all the time, what's wrong with writing it on the rare occasions I issue "apt-get update?"

I'd much rather write to flash than risk forgetting to update apt and screwing something up by installing the wrong package.

--
Rick Mann
rm...@latencyzero.com

[Taceant Omnes]

On 19 October 2015 at 08:33, Rick Mann <rm...@latencyzero.com> wrote:
>
>> On Oct 18, 2015, at 20:38 , William Hermans <yyr...@gmail.com> wrote:
>>
>> http://www.embeddedhobbyist.com/2015/09/beaglebone-black-updating-device-tree-files/
>
> apt-get update: "This step is important every reboot. As the /etc/apt/sources.list file is not kept on “disk”. This is meant to help keep writes to flash media at a minimum – In case you were wondering."
>
> Wait, what? Why would this make sense? I write the flash all the time, what's wrong with writing it on the rare occasions I issue "apt-get update?"

+1

[Bremenpl]

Dziekuje bardzo.

W dniu 2015-10-19 o 11:39, Taceant Omnes pisze:

--
Bremenpl

[William Hermans]

Wait, what? Why would this make sense? I write the flash all the time, what's wrong with writing it on the rare occasions I issue "apt-get update?"

So, don't bother with apt-get update the next time you reboot. Do you think that will prevent the error you get while running apt, without updating ?

[William Hermans]

By the way Rick, how much did I charge you for the information I give out on my blog ?

[Rick Mann]

I'm not attacking you, William, I'm asking for clarification. It doesn't make any sense to me that apt-get update wouldn't write its results to disk.

You don't need to apt-get update all the time, if it writes its results to disk. But if it doesn't, and you forget to next time you apt-get install, you run the risk of downgrading something you have installed (or otherwise corrupting it), don't you?

--
Rick Mann
rm...@latencyzero.com

[Robert Nelson]

On Mon, Oct 19, 2015 at 4:10 PM, Rick Mann <rm...@latencyzero.com> wrote:
> I'm not attacking you, William, I'm asking for clarification. It doesn't make any sense to me that apt-get update wouldn't write its results to disk.
>
> You don't need to apt-get update all the time, if it writes its results to disk. But if it doesn't, and you forget to next time you apt-get install, you run the risk of downgrading something you have installed (or otherwise corrupting it), don't you?

It's really hard to down-grade in debian, and any cache corruption
should stop dpkg from installing a *.deb package..

[William Hermans]

I'm not attacking you, William, I'm asking for clarification. It doesn't make any sense to me that apt-get update wouldn't write its results to disk.

You don't need to apt-get update all the time, if it writes its results to disk. But if it doesn't, and you forget to next time you apt-get install, you run the risk of downgrading something you have installed (or otherwise corrupting it), don't you?

Not attacking you either Rick, but here is the point. The official images come with this enabled. So whether you, I, or anyone else cares, it's already in there. The apt sources cache is either completely in RAM, with a default cache set at build time, or it is a minimal gzipped archive. Technically, no you do not *have* to run apt-get update _every_single_time_ you go to use APT, but generally it is a good idea. All it takes is an update in one repo or another( depending ), and apt-get install, apt-get upgrade, etc will fail, barfing out some message similar to E: could not locate x.y.z.

Either way, the blog was meant for people who are new to Beaglebone, or Linux development in general. If you're good with Debian(Linux), you probably do not need my guides.

Passed that, many people are worried about writing to flash too much, and I'm one of them. I've been using an A5A for gaining on 3 years now, with no flash problems, and that includes the Sony class 10 SDHC card that we bought for it back then. As it is, I make enough mistakes of writing to flash, accidentally, to worry about all the compiling, apt-get installing, etc. This is also why one of my first blog posts was on how to setup NFS shares, and NFS root for the Beaglebone. Not to mention I compile often, and a lot. Granted, compiling over an NFS share *is* slower, but I can live with that. But it's also why I have a cross system for the larger projects, or is why I wrote another blog on how to setup a USB rootfs . . .

I was also a bit "quick" this morning . . . which is how I normally am for the first few hours after waking up. Still, if I write something in my blog posts, and you do not get it. Don't worry so much about it. It was probably not meant for you, or other advanced users. It was meant to keep people, who are new out of "trouble", with minimal explanation required from me.

[Rick Mann]

My problem is that I don't understand how putting the apt cache in RAM is beneficial if what you're trying to do is avoid flash writes. If you're updating the cache, then you're also intending to install or upgrade software, which will write to flash. If it's in RAM and not persisted, forcing you to do an update each time you do an install or upgrade, how does this prevent writing to flash?

So, either I'm not understanding the intent, or I'm not understanding how apt works.

If instead it's best practice to always update before installing, then why not have apt-get install just update the cache each time?

All I see is no benefit but the potential for error (e.g., not getting the version of the package you thought you were getting, or in the best case, confusing errors due to conflicts). I don't see how putting the cache in RAM helps anyone, novice or expert.

Now, if the intent is just to speed up accesses, rather than reduce flash writes, then loading the cache at boot from a store on disk, and accessing the cache in ram, makes sense. However, it seems that in this case, apt-get update should update both the cache and the on-disk store.

In all this, I'm questioning the wisdom of the apt authors, not you or Robert or anyone else on this list.

--
Rick Mann
rm...@latencyzero.com

[Robert Nelson]

On Mon, Oct 19, 2015 at 6:08 PM, Rick Mann <rm...@latencyzero.com> wrote:
> My problem is that I don't understand how putting the apt cache in RAM is beneficial if what you're trying to do is avoid flash writes. If you're updating the cache, then you're also intending to install or upgrade software, which will write to flash. If it's in RAM and not persisted, forcing you to do an update each time you do an install or upgrade, how does this prevent writing to flash?

It's not in local ram, it's on disk...

When you run "apt-get update" a local cache database is created, this
database can become out of date.. Especially if your running
testing/unstable. For stable (wheezy) it's not really an issue,
unless you have someone like me pushing kernel and bb.org package
updates to the repo.

For official images, i "clear" out this local apt cache, to 1: save
space, 2: it can be months out of date.. ;)

[William Hermans]

So, we're working with an embedded device. This device, depending can use a tiny rootfs depending. In effect, the apt cache "problem" is two fold.

First, writing to media, which in the case of our board here is flash. Sure, maybe if you're using apt you're installing something, which does write to flash. But why compound that by also writing the cache to flash too ?

Second, is size. the apt cache can eat up a lot of space, if you let it. Sometimes, this is not so important, other times it is. I'll let you use your imagination here.

It has been a long, long time since I've seen really bad "apt errors" - e.g. corrupting the rootfs somehow, or broken packages etc. But it did used to happen, which is why we can read about, or talk to people who swear by aptitude. Now days, I'd go so far to say that this is a non issue. However . . . what you will run into is APT complaining about your repo(s) not being in sync, and the error message given is not always obvious. I can not give you the exact text of the errors I've seen in the past, but they typicaly go something like "E: unable to lock . . ." or "E: unable to find . . .". Sometimes these error might even confuse a user into believing that a given package does not exist . . . which is the main reason why I suggest just to use apt-get update *always*. It's less pain for them, and others when trying to help with various problems.

[William Hermans]

It's not in local ram, it's on disk...

Ok, so looks like I have my "facts" confused with perhaps something else. As far as the cache goes. Still, run apt-get update before you use apt to install something. Especially if you use it very seldom.

[Robert Nelson]

On Mon, Oct 19, 2015 at 6:36 PM, William Hermans <yyr...@gmail.com> wrote:
>> It's not in local ram, it's on disk...
>
>
> Ok, so looks like I have my "facts" confused with perhaps something else. As
> far as the cache goes. Still, run apt-get update before you use apt to
> install something. Especially if you use it very seldom.

You could put them in a tmpfs to cut down on writes ;)

/var/cache/apt/

voodoo@hestia:/var/cache$ sudo apt-get clean
voodoo@hestia:/var/cache$ du -sh apt
60K apt
voodoo@hestia:/var/cache$ sudo apt-get update
<>
voodoo@hestia:/var/cache$ du -sh apt
76M apt

[William Hermans]

<p>Updating your APT cache may be necessary, especially if it's been a while since doing so. If you're getting errors relating to using APT. This may very well be why.</p>

Better ? ;)

[Robert Nelson]

the 60k is:

voodoo@hestia:/var/cache/apt$ ls -lh ./*
total 4.0K
-rw-r----- 1 root root 0 Dec 29 2013 lock
drwxr-xr-x 2 root root 4.0K Oct 18 20:28 partial
voodoo@hestia:/var/cache/apt$ ls -lh ./*/*
-rw-r----- 1 root root 0 Dec 29 2013 ./archives/lock

./archives/partial:
total 0

so on tmpfs mount it would be easy to create..

[William Hermans]

You could put them in a tmpfs to cut down on writes ;)

/var/cache/apt/

voodoo@hestia:/var/cache$ sudo apt-get clean
voodoo@hestia:/var/cache$ du -sh apt
60K apt
voodoo@hestia:/var/cache$ sudo apt-get update
<>
voodoo@hestia:/var/cache$ du -sh apt
76M apt

I thought that was what you were doing already. Hence my confusion. But to be honest I never really looked too deep into it. So the discussion you and I had months ago, I guess I just took that for granted( caches to ram cache . . )

[William Hermans]

Meanwhile . . . I'm destroying this SD card trying to get PRU C compiler working without CCS, and without losing my sanity . . .

[Robert Nelson]

On Mon, Oct 19, 2015 at 6:44 PM, William Hermans <yyr...@gmail.com> wrote:
>> You could put them in a tmpfs to cut down on writes ;)
>>
>> /var/cache/apt/
>>
>> voodoo@hestia:/var/cache$ sudo apt-get clean
>> voodoo@hestia:/var/cache$ du -sh apt
>> 60K apt
>> voodoo@hestia:/var/cache$ sudo apt-get update
>> <>
>> voodoo@hestia:/var/cache$ du -sh apt
>> 76M apt
>
>
> I thought that was what you were doing already. Hence my confusion. But to
> be honest I never really looked too deep into it. So the discussion you and
> I had months ago, I guess I just took that for granted( caches to ram cache
> . . )

Nah doing 'other' funky things so that optional features of the apt
'cache' never reach the disk. ;)

dropped translations, uncompressed, etc..

and when you do:

sudo apt-get update ; sudo apt-get install xzy

it's actually doing:

sudo apt-get update ; sudo apt-get install xzy ; sudo apt-get clean