Why is everything working presumably for others but not for me?

General Discussion
, ,
1

Whining maybe but…

I have been a user of beagleboard.org boards for about a good swath of time.

Outside of that swath of time, I have never been more lost. I lie. The lie being that when I first started to learn about Linux, beagleboard.org, what the .org has to offer, and various tasks to complete when furthering my education of Linux, TI chips, and computing in general, I was overwhelmed with how much was offered.

Now…

I am not saying more is offered now or less is offered now. I am saying that I am at a loss.

This loss pertains to how one, like myself and since I am describing me here, would program some of the boards like:

  • Pocket Beagle 2
  • BeagleY-AI
  • BBAI-64
  • BBB and variations with the am335x onboard
  • etc

I feel like I fell off somehow when getting overwhelmed and missed out or turned oblivious to further education in this realm of learning. Mind you, I am still learning about the PRUSS and trying to make motors move in general. So, this is a way of learning that has sort of got in the way for now with the other boards in mind.

So, can I use libgpiod-dev and gpiod to program boards from beagleboard.org? Can I use pathlib to program boards from beagleboard.org?

I feel like even though the offering is there and around, I cannot find the correct data to handle specifics in programming regular Linux with peripherals, some of the coprocessors, and so on…

Whine, whine, whine. I know…but in hindsight, pay attention is part of the “battle.” Learning while paying attention is also difficult, fun, but very troublesome at times.

I am not trying to pull someone's shorts on the field here but I am looking for ways to further my understanding of how to stay onboard and keep afloat while learning.

For instance, I saw a new book was made dedicated to the Beagle Play. And yes, I collect boards but for utilizing them and for learning.

I passed on the Beagle Play OF COURSE and the older model Pocket Beagle.

Seth

P.S. Um, I saw some BBB related peripheral access at /dev/bone/* and since then, I have been unable to make it work. No issue. The BBB is an older model board. With the newer model boards and their POWER of quickly booting Linux and new-to-me coprocessors, I would like to learn again how to build around TI chips and alongside your and you guys/gals philosophies in Open Source. I mean…I may never be something in this field. I am okay with it. I may make a cool apparatus and go Stellar! Who knows really? But least and mostly here, I want to learn more about Open Source ideas, computing, and how to manage a board fully with its access to the outer world via sensors and so on…

2

i may have missed your issue/point in that long winded post.
what is the problem ??

3

Problem…well:

  1. I cannot use the peripherals on the board(s).

That is one issue I am having. For instance, I go to what used to work:

/sys/class/gpio/ on various boards…no go.

GPIO is now a character device. I made it to that point in time. Then, the /dev/bone/* spec. happened within the .org and things got backlogged it seemed. When I say backlogged, new boards came out and the spec. was, I am guessing here, put on hold.

Since it was put on hold, still guessing, I have been unable to find exactly where I would go within the fs to find my access to the hardware.

I am not too lingual in DTS so far. Sort of and sort of not really. I can read the given DTS files and other files given, like the .dtsi(o) files, and perform calculated directives towards what I would think could entail a working order (peripheral access).

Outside of that idea and those notions of problems, I am finding less time to learn since I am steadily playing catch up duty over here.

I know what was said about things moving quickly. No issue. I understand that things happen, changes take place, and specifics need to happen for everyone to understand what it is we are actually ahold of currently. With this said and typed out, my problem is basically:

hardware to DTS to peripheral access to programming basically sums up the gist of all things being involved here. Since things have been moving at a high pace, basics have been left to whither in the cold so-to-say.

I know this is technical. And computing is technical. So, I am not upset or bewildered or in a non-complacent state now. I am just wondering:

  1. Is it okay to use peripherals on these boards with access to PWM, GPIO, UART, I2C, SPI, and/or coprocessors in full?
  2. Would I need to write a DTS set of files to handle such a task, i.e. the task of building around these technologies?
  3. Once the DTS is built, would I be able to program in C/C++ without a kernel module being built into the kernel?
  4. And so, would I be able to use gpiod.h as one of my preprocessor directives and have it work with C/C++ for an available GPIO pin and on which board would this entail access?
  5. Also, what board allows what to be ported to which headers?
    a. For instance, the BBB had all sorts of peripheral access allowed to the headers (especially once things started to change a bit).
    b. And, I have been unable to make some of the boards peripheral access available when programming.
    c. This has put a damper in my learning. Problem 98% +/- 1. I am like a slew of data and when I want to access data I cannot remember or view simply for remembering, something changed and my data is worthless at that point.
    d. I can get with the times and understand that things change. I am by far a person calling Mr. Dumass (pronounced Du-mauss), Mr. Dumbass.
    e. I am not understanding in the light that the hardware is here but the access seems limited is all.

Now, I know, I know, I know. Beagleboard.org is allowing people to have full access to what they have accomplished with current times and what they have done. It is freely available to sift and learn from currently.

I love that part but really. What about the dirt, the grime, and filth. People do not necessarily work daily behind luxury and in corner, well-lit offices. People sometimes need to work in filth to learn a bit of what is available.

Then, through perseverance and accomplishment, sometimes people are allowed to build their reputation on the dirt work they have succeeded in doing to only build further. Sometimes, like in the technical world, people need background. Another concern I was having…

0.5% +/- 0.5 of my problem is that my background work has vanished. Immensely. I wanted to be able to wear a nice pair of khakis one day and a nice shirt that I actually tuck in fully. Now, you @amf99 has bumped me in life to the point of no return.

All jokes aside…and to the point here:

I can give back more. I actually am willing to try to give back more. I will apply myself and learn stuff.

But, you @amf99 are not going to act like there is some problem that needs immediate attention. Calm down man… It is hard enough getting peripherals to work with a preprocessor directive outside of our kosher banter.

update

I probably went left. Sorry. I will try to be as technical as possible without all these words/problems. Gosh. Am I allowed to say these things on the forum(s)? Gosh-Gosh-Gosh.

4

on BBB things seem to be the same, gpio, dts and all. just added a display via spi and some gpio, irq. all went ok
on PB2 the gpio has changed. doing gpioinfo and grep for P9_xx you can find the gpio # to use with /sys/class/gpio/export, will post more tomorrow when i’m on my devel machine.
my understanding is the the newer boards i.e. processor do not follow the old ways of BBB gpio access or should i say numbering.

my findings on PocketBeagle 2

ls /sys/class/gpio/
gpiochip512 gpiochip515 gpiochip539 gpiochip631
these cooresponds to gpiochip0 to gpiochip3 from gpioinfo
gpioinfo | grep P1.04
line 89: “P1.04(Y18)” unused output active-high
the 89 is the offset in the above gpiochipxxx

gpiochip539 + 89 == 628 (verified)
echo 628 > /sys/class/gpio/export
produces:
/sys/class/gpio/gpio628

1 Like
5

Figure out whose pond you’ve been pissing in. That line is straight from the docs.

I need to read more documentation.

It seems sysfs and devfs and char dev are all related now in the GPIO world. So, does this have something to do with me. Not really.

Do I want my hand in it. Yes! So, should I start with a fresh kernel or should I start with a beagleboard.org kernel?

I mean…from what I remember in some of the past kernels, the .org put their DTS files in it and made it available to the world.

Lost in translation as usual…

Seth

P.S. Slacking on reading documentation has been my error so far. I will go back to reading documentation and performing once more with driver builds. There was a nice section I read where to get a char dev to work, it first needs to be through sysfs.

6

It seems sysfs and devfs and char dev are all related now in the GPIO world. So, does this have something to do with me. Not really.

The situation with GPIO is messy right now. But well, I am not sure if BeagleBoard.org can do much to fix it. We are just following upstream.

The upstream kernel has for all intents and purposes deprecated sysfs for GPIO. Instead, they want everyone to use libgpiod. But it’s more of a soft deprecation, so people are still using it.

Do I want my hand in it. Yes! So, should I start with a fresh kernel or should I start with a beagleboard.org kernel?

I personally use mainline on the boards all the time, and it works pretty well. BeagleBoard.org is pretty good at upstreaming everything than can be upstreamed.

I mean…from what I remember in some of the past kernels, the .org put their DTS files in it and made it available to the world.

DTS file now go in BeagleBoard-Devicetrees. They are still present in the kernel trees, but this is kind of where everything is consolidated.

I have been trying to make at least using the header pins easier in upstream kernel. But well, upstream moves slow, especially for new things. So it has mostly just involved writing big emails on mailing lists on why I want to connect an LED on my PocketBealge 2 without going and changing my devicetree.

2 Likes
7

@ayush1325 ,

Thank you for making me understand.

Seth

P.S. So, I guess the kernel is not just ready for the chips so far. Maybe this will change will some attempts. I will pay attention. Also…what about the mm instead of rc or the kernels that are upstream?