jelly has quit [Read error: Connection reset by peer]
jelly-home has joined #linux-amlogic
aballier has quit [Ping timeout: 245 seconds]
aballier has joined #linux-amlogic
ldevulder_ has joined #linux-amlogic
ldevulder has quit [Ping timeout: 250 seconds]
jelly-home is now known as jelly
skoperst has joined #linux-amlogic
Darkmatter66_ has joined #linux-amlogic
Darkmatter66_ has left #linux-amlogic [#linux-amlogic]
sputnik__ has joined #linux-amlogic
sputnik_ has quit [Ping timeout: 246 seconds]
ldevulder_ is now known as ldevulder
Darkmatter66 has joined #linux-amlogic
Darkmatter66 has quit [Client Quit]
Darkmatter66 has joined #linux-amlogic
<Darkmatter66>
narmstrong, chewit do you have any idea what's the policy on brcm nvram files mainlineing ?
<Darkmatter66>
When loading the brcmfmac I get these errors
<Darkmatter66>
brcmfmac mmc2:0001:1: Direct firmware load for brcm/brcmfmac4335-sdio.amlogic,p201.txt failed with error brcmfmac mmc2:0001:1: Direct firmware load for brcm/brcmfmac4335-sdio.txt failed with error -2
<Darkmatter66>
so the module is trying to load the nvram based on the board name
<Darkmatter66>
If I download put the nvram txt file that comes with the vendor kernel and name it correctly then the module loads succussfully
<Darkmatter66>
Do we need to mainline these files ? or should they be provided by the distro ?
<narmstrong>
It should be provided by the distro
afaerber has joined #linux-amlogic
<Darkmatter66>
narmstrong, ok understood
<Darkmatter66>
narmstrong, another thing, if i rmmod and then modprobe I get errors and the wifi is not probed, seems like when removing the module the chip is not turned of completely
<Darkmatter66>
so when loding the module again it can't probe for it
<Darkmatter66>
is this problem in the bus or should i report it the brcmfmac maintainers
<Darkmatter66>
?
[TheBug] has quit [Ping timeout: 250 seconds]
<narmstrong>
Yes nothing to do with the SoC or the bus
nsaenz has quit [Read error: Connection reset by peer]
nsaenz has joined #linux-amlogic
<Darkmatter66>
narmstrong, ok thanks I will report it to brcm80211-dev-list@cypress.com
sputnik__ has quit [Ping timeout: 245 seconds]
<Darkmatter66>
xdarklight, will the nand driver something similar to /dev/env from vendor kernel ? this was really useful to write to the uboot environment since it didn't require that you ship /etc/fw_env.config with correct addresses for each board
<Darkmatter66>
will the nand driver have*
<Darkmatter66>
for example LibreELEC uses it for the "reboot to Android" function
<xdarklight>
Darkmatter66: assuming that u-boot env can be defined using a partition (easiest case: offset and size from the start of the NAND flash) then yes
<Darkmatter66>
xdarklight, do you mean access it from userspace by address or define it as a partition in dts ?in the vendor kernel there used to be an `env` partition but I don't think i was able to get uboot-tools to work with it(it was a long time ago so I'm not sure)
<xdarklight>
Darkmatter66: I've only used this on OpenWrt (with non-Amlogic SoCs) yet, but there it works like this: u-boot has a fixed location where it stores it's environment. Linux board.dts has a partition which covers the area where u-boot stores the env data. then I used u-boot envtools to read/write data from/to that partition from within Linux, u-boot will then see the written data as well (after a reboot)
vagrantc has joined #linux-amlogic
<Darkmatter66>
xdarklight, yes I'm aware how the u-boot tools work, I use them daily, and I really liked the /dev/env driver in amlogic kernel because i can make a distribution and I'm sure it will work on every devices, right now on mainline with no nand driver I have to know the offset and size of the u-boot environment on the emmc and use the addresses in /etc/fw_env.config but that's not ideal since each board have a different offsets
<ccaione>
Darkmatter66: in the past I have used the `boot0` partition to hold the u-boot env
<Darkmatter66>
ccaione, you mean you partitioned it yourself ? that won't be very usefull if you want to ship a distro to users with an already partitioned emmc by the OEM
<ccaione>
`boot0` is an hw partition on the eMMC
<Darkmatter66>
ccaione, did you use a specific offset and size that you calculated?
<ccaione>
`boot0` is usually empty so you can just use offset 0
<Darkmatter66>
ccaione, I also was able to read the env from that device (/dev/mmcblk0boot0) but I had to calculate the offset and size which I assumed to be different for other boards
<ccaione>
didn't follow the discussion from beginning. What was in `boot0` besides the env?
<Darkmatter66>
ccaione, I'm not sure what it contains but it not only the env
<Darkmatter66>
ccaione, and just for more confusion there is also /dev/mmcblk0boot1
<Darkmatter66>
which i think works as a backup partition of sort
<ccaione>
not really. Having 2 `bootX` partitions and one user partition on the eMMC is normal
<ccaione>
nope, not backup. You can read the JEDEC spec
<ccaione>
gotta go. back later
The_Coolest has quit [Remote host closed the connection]
The_Coolest has joined #linux-amlogic
chewitt has joined #linux-amlogic
<chewitt>
Darkmatter66: brcm firmware .bin files should come from the kernel-firmware repo as these are generic
<chewitt>
the nvram .txt files control radio properties so are theoretically board specific
<chewitt>
in recent kernels the driver was modified to look for nvram files in /usr/lib/firmware/brcm/ using the name of the chip and then the board 'compatible'
<chewitt>
or if not available a generic "brcm/brcmfmac4335-sdio.txt"
<Darkmatter66>
chewitt, yes my question as whether these nvram file should be sent to the linux-firmware repo
<Darkmatter66>
chewitt, the firmware .bin files are already there, the only problem is with the nvram files
<chewitt>
they should be sent upstream
<chewitt>
*but*
<chewitt>
first you need to upstream a dts for your box so it's not using the p201 generic dts
<chewitt>
then you have a unique compatible to submit the nvram file against
CarlFK has joined #linux-amlogic
<chewitt>
(and remote control keymap, etc.)
<chewitt>
the whole situation with firmware/nvram is a bit unclear .. even to some of the folks who work for cypress and have access to non-public documenation
<chewitt>
but the more that's collected in the kernel-firmware repo, the more that's learned, and over time usability is improving
<Darkmatter66>
chewitt, ok understood
<chewitt>
as is often the case with kernel things, you have to crawl before walking, before running :)
<ndufresne>
CarlFK, maybe you could ping here about your audio captures issues
<CarlFK>
ndufresne: sure. um.. I have audio captures issues :p
<ndufresne>
narmstrong, chewitt: Any idea what's the state of this, CarlFK is on the ODroid C2
<CarlFK>
2 different usb audio devices, one has an analog tone generator hooked up. I hear the 1k tone, but noise too:
<ndufresne>
it's an external device, ok, then might not be really the place to find more help
<CarlFK>
I was wondering bout that
<CarlFK>
"usb does dma? huh. ok."
<ndufresne>
to be honest, audio is that domain I know the less people working on
<ndufresne>
maybe there is so few people working on it after all
<ndufresne>
right, usb should do dma
<ndufresne>
but I know nothing myself about the usbaudio driver and it's internal
<ndufresne>
it could be USB driver issue too, who knows
<Darkmatter66>
chewitt, Is there any rule by device tree maintainers that prohibit including .dts files inside other .dts files ? so instead of rewriting meson-gxbb-p201.dts content for my board i can just include it
<narmstrong>
@Darkmatter66: you can
<Darkmatter66>
There where multiple files in the vendor kernel that include other .dts files but I don't see anyone in mainline uses the same
<narmstrong>
CarlFK: well, can we more details ? The kernel version ?
<CarlFK>
Linux odroid3 3.16.63-38 #1 SMP PREEMPT Wed Mar 13 14:36:39 -03 2019 aarch64 aarch64 aarch64 GNU/Linux
<narmstrong>
Darkmatter66: the phicomm n1 does that
<Darkmatter66>
narmstrong, oh understood
<vagrantc>
narmstrong: updated u-boot packages in debian with the new platforms, if you could test to make sure they work, i'll need to get a freeze exception to get them into the next release
<narmstrong>
CarlFK: ouch, sorry, we only support mainline Linux here... the 3.14/3.16 amlogic audio driver is a real mess
<CarlFK>
I'm up for reimaging this if we want a known starting point
<narmstrong>
And on mainline we don’t have capture implement yet... on the out of tree audio driver
<chewitt>
CarlFK: what's the project you're trying to achieve with the C2?
<narmstrong>
vagrantc: ok I’ll have a try
<CarlFK>
chewitt: very high level: use a usb mic to record audio from PyTexas this Sat because "oh, we can't give you a propper audio feed"