<ziga_>
@rburton "dmesg" doesn't show/list my device at all - it is only seen form the command "i2cdetect -y 1" (it is on i2c-1 address 0x55). So what am I missing in order for kernel to see my device aas an input? Command "cat /sys/class/i2c-dev/i2c-1/device/1-0055/name" yields "st1232". This is how I defined the device in the devicetree: https://pastebin.com/HTz4v6uf
<mckoan>
ziga_: you have to enable TOUCHSCREEN_ST1232 in kernel config too
<ziga_>
@ckoan I will double check if it is enabled.
<ziga_>
@mckoan Thanks for the tip.
zpfvo has quit [Ping timeout: 272 seconds]
zpfvo has joined #yocto
zeddii has quit [Ping timeout: 250 seconds]
kroon has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
GillesM has joined #yocto
zeddii has joined #yocto
GillesPP has joined #yocto
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
kroon_ has joined #yocto
kroon has quit [Ping timeout: 272 seconds]
osama has quit [Read error: Connection reset by peer]
zpfvo has quit [Ping timeout: 252 seconds]
osama has joined #yocto
zpfvo has joined #yocto
<agherzan>
Morning all!
<agherzan>
ziga_: sounds like a missing driver yes.
xmn has quit [Quit: ZZZzzz…]
<ziga_>
@mckoan @agherzan I enabled TOUCHSCREEN_ST1232 in kernel config but nothing changes. Is there a way to check kerrnel config on an already running target? I would like to double verify if option is working.
<agherzan>
`zcat /proc/config.gz | grep FOO`
<ziga_>
Ty! TOUCHSCREEN_ST1232 is installed as a module. Is this not okay? Shoulld it be instaled as a part of kernel?
<qschulz>
ziga_: check the module is loaded with lsmod, or modprobe it
<qschulz>
pretty sure you'd need a device tree node for your device in the i2c bus it is attached to too
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
GillesPP has quit [Quit: Leaving]
GillesPP has joined #yocto
GillesPP has quit [Remote host closed the connection]
<ziga_>
lsmod does not shows anything related to "st1232". I tried also "modprobe st1232" but it says that this module couldn't be found. @qschulz device is defined in my devicetree like this https://pastebin.com/HTz4v6uf and "i2cdetect -y 1" onfirms that it is found on the address 0x55.
<landgraf>
ziga_: is there module under /lib/modules ?
<ziga_>
It is weird, because config option CONFIG_TOUCHSCREEN_ST1232=m can be found in an extracted /proc/config.gz ://
<qschulz>
ziga_: you need to install it in your rootfs, the kernel-modules package will add ALL kernel modules built by the kernel recipe
zpfvo has joined #yocto
<qschulz>
ziga_: modules aren't installed by default in Yocto
<ziga_>
Ah!
<qschulz>
ziga_: what is returned by i2cdetect does not care AT ALL about what's in your device tree (well.. ok, it does for the i2c bus, otherwise you can't use i2cdetect on the bus since it's not probed)
<ziga_>
This is a really good tip! I haven't got this package yet! :DDDD
<qschulz>
ziga_: oe-pkgdata-util find-path '*st1232*' shall return the exact name of the kernel module
<qschulz>
if you want to finetune which kernel modules make it to your image instead of just adding them all
<ziga_>
Ah so I can use this command to pinpoint the kernel module and only install this one (and not all)?
<qschulz>
jclsn[m]: otherwise, ${env:PWD} should probably work
<jclsn[m]>
It complains that it is not a valid option
<jclsn[m]>
No, both don't work
<jclsn[m]>
BUILDDIR is also in the environment variables and it doesn't work
GillesM has joined #yocto
camus has quit [Ping timeout: 256 seconds]
camus has joined #yocto
Schlumpf has quit [Quit: Client closed]
camus has quit [Quit: camus]
camus1 has joined #yocto
camus has joined #yocto
camus1 has quit [Ping timeout: 252 seconds]
manuel1985 has joined #yocto
<manuel1985>
Hello all. What do I do if my recipe installs a shell script, but I want it to RDEPEND not specifically on bash but just on any kind of shell interpretor?
<qschulz>
manuel1985: I think it's pretty safe to assume that at least ONE shell should be on your system, so just add nothing to RDEPENDS?
<manuel1985>
qschulz: I'm afraid some checker would complain then. At least when installing a file containing a bash shebang it does.
<qschulz>
manuel1985: if you have a bash shebang, you're effectively requesting this script to be run by bash, which means you should have bash on your device. If youb have the /bin/sh shebang, I don't think anything will happen
<ziga_>
Ah! So .cfg suffix is used automatically! :D
<ziga_>
This will help me a lot!
<mckoan>
I answered in stackoverflow
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
chep has quit [Ping timeout: 256 seconds]
osama has joined #yocto
<LetoThe2nd>
yo dudX
<qschulz>
o/
<JPEW>
jclns: you have to explicitly state which environment variables get imported
<LetoThe2nd>
qschulz: \o
<ziga_>
@mckoan It failed.
<JPEW>
jclns: the variables you want to use in the config have to be in the envimport section
chep has joined #yocto
behanw has quit [Quit: Connection closed for inactivity]
rsalveti has joined #yocto
lucaceresoli has quit [Quit: Leaving]
sakoman has joined #yocto
manuel1985 has quit [Quit: Leaving]
xmn has joined #yocto
lucaceresoli has joined #yocto
pgowda_ has quit [Quit: Connection closed for inactivity]
zpfvo has quit [Ping timeout: 272 seconds]
zpfvo has joined #yocto
Etheryon has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
<Etheryon>
Hello, could anyone help me understand how to write a recipe to copy over some files? Is it possible to copy files that are not in your custom layer?
<qschulz>
Etheryon: yes it's possible, the question is where are your files and how are they "shared" with the recipe (git repo, tarball, etc...)
ecdhe has quit [Remote host closed the connection]
<Etheryon>
so there's a folder of media I need to copy over
<Etheryon>
SRC_URI <- this is relative to what ? current location of the .bb file?
sakoman has quit [Read error: Connection reset by peer]
sakoman has joined #yocto
<Etheryon>
And I guess I'll need an empty do_compile, and them as part of do_install copy the files over?
sakoman has quit [Read error: Connection reset by peer]
<qschulz>
Etheryon: meh, the basic do_compile checks if there's a makefile and it there's none does nothing
Minvera has joined #yocto
<qschulz>
I used to inherit the bin_package bbclass instead
<Etheryon>
thanks!
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
kroon_ has quit [Remote host closed the connection]
<Etheryon>
can I specify for bin_package where to put the files, or is it an extra step to move them afterwards ?
kroon_ has joined #yocto
<Etheryon>
if I understood correctly it putes them in ${D}
kroon_ has quit [Client Quit]
<qschulz>
Etheryon: pretty sure you'll still need a proper do_install
<Etheryon>
also is there any way to check why my image is so large? I have excluded x11 and wayland, I would expect it to not be 1,8GB (maybe my expectations are wrong?)
<qschulz>
well, use buildhistory to find out what is so big
zpfvo has quit [Ping timeout: 272 seconds]
sakoman has joined #yocto
zpfvo has joined #yocto
<Etheryon>
thanks for that as well
codavi has joined #yocto
camus has quit [Ping timeout: 252 seconds]
<vd>
Are core images (core-image-minimal and core-image-base) purely meant as examples, or should one preferred to use these images to design they distros, given that machine / distro / images are orthogonal?
camus has joined #yocto
<vd>
I'm asking because it feels like one is always tempted to write custom image recipes right away while it shouldn't be necessary with a correctly configured distro, thanks to DISTRO_EXTRA_RDEPENDS, INITRAMFS_SCRIPTS, etc.
akiCA has quit [Ping timeout: 272 seconds]
<qschulz>
vd: Distros are only for "policies"
<qschulz>
the biggest ones being: "systemd vs sysv", "x11/wayland", etc...
<qschulz>
One of the first things people should do is to create their recipes, that includes an image recipe
<vd>
qschulz: indeed. So it doesn't feel right that a distro ships with image recipes (unless they are some sort of examples) don't you think?
<qschulz>
vd: you usually have a BSP layer (kernel, bootloader, atf, optee, machine configuration file, binary blobs/firmware, you name it.), then a distro layer
<qschulz>
and then something else
<qschulz>
we do have a poky distro in.. poky because there's a need for a distro for testing purposes
<qschulz>
if that was your next question
<vd>
qschulz: yes, then a "software" layer adding recipes for your custom packages if any, with image recipes bundling them
<qschulz>
typically, it's highly recommened to have a separate layer for your BSP components, after that, it's a bit more up to the devs
<RP>
JPEW: are you ok with those binutils mingw patches?
ecdhe has joined #yocto
<JPEW>
RP: The 2 from khem?
<JPEW>
RP: Ya master-next of meta-mingw LGTM
<vd>
qschulz: I think you answered my question, custom images are usually written in software layers and core-image-* aren't just example, they must work with any bsp/distro layers, if well written.
manuel1985 has joined #yocto
<qschulz>
vd: core-image-* are sometimes used as bases for other custom image recipes
m4ho has quit [Quit: WeeChat 3.3]
m4ho has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
<RP>
JPEW: yes, those, thanks. Once we sort qemuppc we can then likely merge everything
manuel1985 has quit [Remote host closed the connection]
manuel1985 has joined #yocto
osama1 has joined #yocto
Etheryon has quit [Quit: Client closed]
osama has quit [Ping timeout: 252 seconds]
klockwood has joined #yocto
klockwood has quit [Ping timeout: 240 seconds]
klockwood has joined #yocto
klockwood has quit [Client Quit]
Tucupitano has joined #yocto
<Tucupitano>
hello there
davidinux has quit [Ping timeout: 256 seconds]
goliath has quit [Quit: SIGSEGV]
frieder has quit [Remote host closed the connection]
davidinux has joined #yocto
<RP>
JPEW: FWIW disabling parallel make in binutils is making the test builds take houyrs
<JPEW>
RP: Hmm, that's not good
<JPEW>
It might be time to drop 32-bit MinGW
<JPEW>
(assuming it's just a problem there, which is perhaps unlikely)
<JPEW>
It might be possible to drop the Direct3D support... since I highly doubt we need that
<RP>
JPEW: we saw the failure with 64 bit too. I agree that disabling d3d support might be a better option though
Tucupitano has quit [Ping timeout: 252 seconds]
zpfvo has quit [Ping timeout: 252 seconds]
<RP>
jonmason: any thoughts on what to do with this hanging ltp build?
zpfvo has joined #yocto
<RP>
FWIW it is hanging in the proc01 test again
<RP>
it was trying to read proc/kmsg and attaching/detaching gdb unblocked it
<RP>
0x0000007f99886374 in __read_chk () from /lib/libc.so.6
<vd>
qschulz: in other words, would you write your own base images for your distro or would you simply rely on core-image-*
<qschulz>
vd: i would include one of the core-image-minimal except if I really need something really really specific
<JPEW>
RP: Ok, let me see if I can reproduce it locally
<JPEW>
Doesn't look like there is an option to remove direct3d
<RP>
JPEW: shame, it sounded promising :/
rfuentess has quit [Remote host closed the connection]
<jonmason>
RP: I'll try to replicate on my local arm64 system (which might be whimpy enough to race like this one)
<RP>
jonmason: you may want to just trim it down to that test and loop it
<RP>
jonmason: we've been here before with this test and did disable it in the past. I'm tempted to add that disabling back
<jonmason>
If we ran LTP, we might catch this kind of thing more internally too
<RP>
jonmason: it does suggest there is a genuine bug in procfs for arm though
<jonmason>
RP: If I can replicate locally, I can trim it down and punt to an internal team to figure it out
<jonmason>
esp for procfs, which I've never messed with
<jonmason>
Let me ask around who this could be punted to
<RP>
jonmason: quick summary is that proc01 is a test in ltp which goes through the files in procfs and tries to read them. it is basically doing a cat /proc/kmsg from what I remember
<RP>
jonmason: so there is a some race where a read from /proc/kmsg hangs on arm
<jonmason>
internal slack channel being poked, while I try to get this to reproduce
<RP>
jonmason: thanks.
<RP>
JPEW: I'm not sure if these build times are a parallel make issue or not, I'm starting to wonder if my first "guess" was right or not :/
<JPEW>
OK, let me know. The error that the parallel make is trying to fix looks weird, but I'll dig into it if the build time is abysmal
<RP>
I'm trying to do too many things at once, badly :(
Tokamak has quit [Read error: Connection reset by peer]
Tokamak has joined #yocto
gsalazar has joined #yocto
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
GillesM has quit [Quit: Leaving]
vladest has quit [Remote host closed the connection]
vladest has joined #yocto
fitzsim has quit [Remote host closed the connection]
fitzsim has joined #yocto
prabhakarlad has quit [Quit: Client closed]
florian_kc has quit [Ping timeout: 272 seconds]
<smurray>
RP: I was poking at some of the stuff on the inclusive list yesterday, is this prototype of checking for variables in bitbake in roughly the right place?: https://paste.debian.net/1230890
zpfvo has quit [Ping timeout: 252 seconds]
<ziga_>
@mckoan I edited the Stackoverflow question.
zpfvo has joined #yocto
Schlumpf has quit [Quit: Client closed]
Tucupitano has joined #yocto
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
zpfvo has quit [Quit: Leaving.]
superdupond has joined #yocto
florian has quit [Quit: Ex-Chat]
<mckoan>
ziga_: but what is your MACHINE?
Tucupitano has quit [Ping timeout: 272 seconds]
dtometzki has quit [Ping timeout: 272 seconds]
osama1 has quit [Quit: WeeChat 3.4]
goliath has joined #yocto
mckoan is now known as mckoan|away
<RP>
smurray: I was just talking to sgw about this, I think it may make sense as a RecipeParsed() event handler?
<smurray>
RP: is sgw working on coding something up? If so, I'll shelve continuing. If not, I have rework for all the variables that snippet was checking for in hand here
<RP>
smurray: I think you're ahead of him
<RP>
smurray: I'm actually torn on event handler vs making this dedicated bitbake code :/
<RP>
smurray: I did wonder about a BB_RENAMED_VARIABLES[BB_HASHTASK_WHITELIST] = "Variable new name" type flags list
<RP>
so that it could then say "X was used and it has been replaced with Y"
* RP
needs to step afk so I'll let you negotiate with sgw
<smurray>
RP: yes, I was thinking about whether that'd be what's wanted or not. I can try coding up whatever so long as there's some definition of the reqts
<sgw>
smurray: I was just starting, you seem to be further along, so please continue
<RP>
that is the point bitbake considers the parsing "done"
<smurray>
RP: that's per-recipe as opposed to overall? So whether to rig up warn once or not would come into play?
<RP>
smurray: it is overall, yes. I think we have to catch things in the recipes
<RP>
er, it is per-recipe
<RP>
smurray: we'd still want warnonce in there since we'd not want to show it for every recipe
<smurray>
RP: heh, okay, that's definitely not what I thought was wanted from the previous discussions
<RP>
or more likely erroronce
<RP>
well, part of this work is to figure out what makes sense and get a decent user experience
dtometzki has joined #yocto
<smurray>
okay, I can likely put a couple more hours into this this evening
<RP>
I'm nearly of the opinion that it is far too late to be trying to rush this into an LTS at this point :(
<smurray>
RP: I'd prefer we just break everyone and give them a conversion script a la overrides as opposed to not doing it
<smurray>
RP: which I know not everyone agrees with, but it's been 2 years
<smurray>
RP: if I'd known no one was going to do anything after the discussion last month, I'd not have waited to start myself
Minvera has quit [Remote host closed the connection]
Minvera has joined #yocto
<smurray>
sgw: I'll update the wiki page with what I've got in hand here. Issue is it's hard to see how it's useful to post patches until the variable checking in bitbake is hashed out
<sgw>
smurray: thanks for handling that and agreed, I guess I forced the issue with the initial patch set!
<sgw>
Someone had to get the ball rolling somehow.
Minvera has quit [Remote host closed the connection]
<smurray>
sgw: did you post something?
Minvera has joined #yocto
leon-anavi has quit [Remote host closed the connection]
GillesM has quit [Remote host closed the connection]
florian_kc has joined #yocto
dev1990 has joined #yocto
florian_kc has quit [Ping timeout: 252 seconds]
alimon has quit [Ping timeout: 240 seconds]
<vd>
qschulz: if you need to produce images for different medium of the same machine (e.g. sd card for recovery/factory, emmc for production, etc.), would you create machine variants (machinefoo-sdcard and machinefoo-emmc) and build a generic image, or would you create machine-specific image recipes and specify different WKS_FILE (e.g. foo-image-sdcard containing WKS_FILE=machinefoo-sdcard.wks)?
Tucupitano has quit [Ping timeout: 240 seconds]
<kanavin>
vd, I would try really really hard to avoid adding more machine definitions
<kanavin>
it's much easier to 'bitbake image1 image2'
<kanavin>
better yet, figure out how you can make a universal image
<vd>
kanavin: it's why I thought. I'm struggling designing such image for factory, to e.g. format/install an eMMC from an SD card image.
<kanavin>
vd, as chance would have it, I'm going to have exactly the same task in the next few days
<kanavin>
vd, I'm currently stalled by having a device that's hardcoded to boot from emmc (literally - by resistor settings on the board)
alimon has joined #yocto
<kanavin>
vd, we asked the vendor to sort this out, or explain how are we supposed to bootstrap
<kanavin>
vd, I guess what you can do is boot from sd card, then run a script that pulls the same image off the net as a file
<vd>
kanavin: looks like you won't be able to bootstrap the installation from the machine itself
<kanavin>
the dd if=file of=emmc
<vd>
kanavin: that's currently what I'm doing, adding a prod.wic image either in IMAGE_ROOTFS or in IMAGE_BOOT_FILES, but this means having a specific image, e.g. myproduct-image-factory with embedded binaries
<vd>
(for offline factory installation)
<kanavin>
vd, I wonder if u-boot has this feature, 'copy sd-card verbatim to emmc'
<vd>
kanavin: you could do it in an initramfs otherwise, but dd will take a lot time to copy even 4Go and will fail if the SD card is larger
<vd>
so you can use bmaptool, which doesn't fit in the initramfs, so back to a factory image..
<vd>
or adding a machine specific script in the initramfs to do sfdisk -d ${sdcard} | sfdisk ${emmc}, then format/populate the partitions manually
amitk has quit [Ping timeout: 250 seconds]
<vd>
kanavin: you may add a "factory" package to you distro (initramfs or packagegroup-machine-base) with SRC_URI += "file://format.sh" and place it in files/<machine>/format.sh. It's not easy to make this clean
florian_kc has joined #yocto
Thorn has quit [Ping timeout: 256 seconds]
Thorn has joined #yocto
florian_kc has quit [Ping timeout: 252 seconds]
bluelightning has quit [Remote host closed the connection]
Tucupitano has joined #yocto
GNUmoon has quit [Remote host closed the connection]