<montjoie>
hellow, how to now if an eMMC is working in sector or byte mode ? My question is needed for EMCE (usermanual page 517)
cmeerw has joined #linux-sunxi
cmeerw has quit [Ping timeout: 260 seconds]
lkcl has quit [Ping timeout: 256 seconds]
faruk_ has joined #linux-sunxi
lkcl has joined #linux-sunxi
faruk has quit [Ping timeout: 240 seconds]
apritzel has joined #linux-sunxi
techn has quit [Ping timeout: 256 seconds]
techn has joined #linux-sunxi
apritzel has quit [Ping timeout: 264 seconds]
tnovotny has joined #linux-sunxi
mripard has joined #linux-sunxi
daregap has joined #linux-sunxi
AneoX has joined #linux-sunxi
ldevulder__ has joined #linux-sunxi
ldevulder_ has quit [Ping timeout: 246 seconds]
camus has joined #linux-sunxi
kaspter has quit [Ping timeout: 264 seconds]
camus is now known as kaspter
iyzsong has quit [Ping timeout: 240 seconds]
iyzsong has joined #linux-sunxi
yann has quit [Ping timeout: 260 seconds]
yann has joined #linux-sunxi
apritzel has joined #linux-sunxi
<apritzel>
montjoie: old SD card use byte addresses, "newer" card (SDHC, SDXC) use sector addresses
<plaes>
apritzel: are `max-frequency = <150000000>;" and "mmc-hs200-1_8v";` supported in the u-boot?
<plaes>
I tried enabling it last night for u-boot, but the mmc info still showed the 52MHz frequency
<apritzel>
plaes: U-Boot support more advances modes, but maybe not for sunxi
<plaes>
ok, that explains..
<plaes>
I didn't manage to boot linux last night (after building rootfs / kernel) because `bootz` command was not enabled for a64-olinuxino...
<apritzel>
bootz? for arm64?
<apritzel>
plaes: so yeah, I checked: the sunxi-mmc driver in U-Boot does not care about DT MMC capabilities. It just enables the basic speed modes
<plaes>
yeah.. I have my workflow where I build kernel with `make bindeb-pkg -j $(nproc)` :P
<apritzel>
plaes: you mean it creates a compressed kernel image?
<plaes>
yeah, vmlinuz
<apritzel>
but that's not the bootz command, is it?
<apritzel>
I thought bootz is for 32-bit kernels?
<apritzel>
I always add CMD_UNZIP in those cases, then unzip manually
<plaes>
DTC_FLAGS=-@ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make defconfig
<plaes>
DTC_FLAGS=-@ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make -j$(nproc)
<karlp>
what's the DTC_FLAGS bit for?
<apritzel>
DT overlays?
<plaes>
yeah
<plaes>
and then I build the debian package (solves the issues with moving over the modules)
<plaes>
DTC_FLAGS=-@ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make bindeb-pkg
<plaes>
..and I end up with /boot/vmlinuz-XXX as kernel image
<karlp>
why is that -@ thing not turned on by a menuconfig option? that sounds like a really pointy sharp corner
<plaes>
I don't know
<apritzel>
plaes: I think grub handles gzip'ed kernels transparently, in U-Boot you need to do "ext4load mmc x $load_address /boot/vmlinuz; unzip $load_address $kernel_addr_r" manually
steev_ has joined #linux-sunxi
<apritzel>
then boot with booti
<apritzel>
or bootefi
<plaes>
do I need anything else on the efi partition?
narmstrong has joined #linux-sunxi
<plaes>
I'm using the 'fastboot oem format' and 'fastboot flash ...' to set up the device
<gediz0x539>
yeah, apparently it works. listed as "/dev/input/event0: 1c22800.lradc"
<gediz0x539>
btw, i'm trying to make multi-press using lradc. is it considered overkill?
<gediz0x539>
i could not see any example about this and feel like i may be doing something wrong
kaspter has joined #linux-sunxi
apritzel has quit [Ping timeout: 272 seconds]
faruk__ has quit [Quit: Leaving]
faruk has joined #linux-sunxi
faruk has quit [Client Quit]
ldevulder__ has quit [Quit: Leaving]
apritzel has joined #linux-sunxi
<swiftgeek>
gediz0x539: i guess detecting multiple keys would heavily depend on resistor values chosen on board
<swiftgeek>
but would be nice to see it in uboot for menu up/down :D
asdf28 has quit [Ping timeout: 260 seconds]
reinforce has quit [Quit: Leaving.]
andy25225 has quit [Quit: Leaving]
andy25225 has joined #linux-sunxi
andy25225 has quit [Client Quit]
andy25225 has joined #linux-sunxi
gaston1980 has joined #linux-sunxi
<jernej>
apritzel: I'm back on hacking H616
<jernej>
I just noticed that something is still not ok with clocks
<jernej>
for example, hdmi-cec reports 1.2 GHz even though it should be ~32 kHz
<jernej>
I'm using your h616-v2 branch
xeniter has joined #linux-sunxi
<jernej>
predivider doesn't seem to be considered
JohnDoe_71Rus has joined #linux-sunxi
<jernej>
apritzel: btw, you missed hdmi-cec bit 30 (pll_peri_gating)
<jernej>
I guess it can be folded in enable bits
<apritzel>
jernej: yeah, all those audio/video clocks were just copied from H6, then inspected by comparing to the H616 manual
<apritzel>
jernej: but one can only do so much Allwinner clock bits comparison before turning mad ...
<jernej>
:)
<jernej>
hdmi still doesn't work...
<jernej>
apritzel: I found the issue with prediv
<apritzel>
that was quick!'
<jernej>
flag suggest variable prediv, but fixed prediv is configured
<jernej>
so either of those must be changed to other
<jernej>
I guess flag must be changed to fixed prediv
<jernej>
well, that's also the bug in H6
<apritzel>
jernej: btw: I have some U-Boot patches (MMC & EMAC) to make it work with the DTs from Linux-v2
<apritzel>
I can push them, if you like
<jernej>
please do
<apritzel>
and I figured that the H6 can also load >32KB via eGON from MMC as well
<apritzel>
in fact 139KiB on the H6, and 212KiB on the H616
<psydruid>
I've seen some random reboots on A64 with 5.10.1 for the last week or so, so I was wondering if that is just my system or more people have been having those
<apritzel>
plaes: interesting, thanks for the test!
<apritzel>
plaes: it seems like you have the 4GB version, right?
<apritzel>
plaes: assuming it's the MTFC4GACAANA that the Olimex schematic show, it should be able to speak HS200, but that particular chip is limited to 75MB/s reading anyway
<karlp>
so, say I'm designing a new board, with a a wifi+bt module on it, is there any reason to use sdio when I can use usb? the wifibt modules seem to use sdio for wifi, and also a uart for bt, vs, just a single usb interface. I have the usb port available...
<karlp>
(I'm only after "wifi "4" geneirc connectivity speeds)
<apritzel>
karlp: I think SDIO is mostly used because it's available, and can't be used for much else
<apritzel>
also you should check the driver situation
<apritzel>
karlp: but other than that I'd say USB is actually easier and more compatible
<karlp>
that was wha tI _wanted_ to do, so I'll self select that as the best answer :)
<karlp>
I just wanted to make sure there was nothing I would miss on sdio
<karlp>
yeah, currently trying to troll menuconfig to check
<karlp>
all sounds horrible though, if you want wifi+bluetooth+cheap
<apritzel>
karlp: I know that some chips are available in both SDIO/UART and USB versions, and sometimes you only have the driver for one in the kernel
<apritzel>
thought it shouldn't be rocket science to cobble the required glue code together
<apritzel>
karlp: I think SDIO is now somewhat legacy, and is seriously bandwidth limited when it comes to recent WiFi speeds
<karlp>
yeah, that was my feeling too.
<apritzel>
it seems you can reach the same speeds as SD cards, so theoretically 100 MB/s with UHS-I (at 1.8V, switchable)
<karlp>
iff the sdio periph can handle it :)
<apritzel>
exactly
<apritzel>
and the board is wired correctly, and ...
<karlp>
usb is wayyyy more plug and play from wher eI'm sitting,
<apritzel>
if you have the port available, I'd use it
<apritzel>
I guess for most SBCs USB is too precious to "waste" it on WiFi, especically if you can use the otherwise unused SDIO for that
<karlp>
yeah, I definitelt hav ethe port available,
<karlp>
thanks for the advice
<apritzel>
karlp: just keep in mind that USB 2.0 also hits a performance wall, but it should be still good enough for 802.11n
<karlp>
yeah, only look for 802.11n level speeds
<karlp>
mostly just to be a config interface
<apritzel>
then it should be definitely good, and it would be really plug&play, just make sure to enable that USB port
<smaeul>
I would think the benefit of SDIO is power consumption: lower supply voltage, lower I/O voltage, out-of-band interrupt line, 32 kHz clock line, etc.
<apritzel>
smaeul: for on-board USB you can use HSIC, which would give you some of those advantages as well
<apritzel>
smaeul: but yeah, power saving and maybe more fine grained control (both a pro and a con) is a plus for SDIO
qschulz has quit [Read error: Connection reset by peer]
<smaeul>
apritzel: true. interestingly, it appears some modules support both SDIO and HSIC
<smaeul>
unless I'm misreading and they just offer the same chip in SDIO/HSIC/PCIe variants
<apritzel>
smaeul: I have seen both, I think
<apritzel>
smaeul: sometimes they want to cover the huge USB pen