<silviop>
plaes: My HP 5328A confirm that clock when bit 30 is set is halfed and present in two channels pin(dual lvds signal) , my panel won't switch ON but i think there is other aspect in interface to consider (levels? protocol?) and my 200Mhz scope is not sufficent to understand
|Jeroen| has joined #linux-sunxi
<plaes>
o/
<plaes>
are you turning backlight on?
<plaes>
silviop: ^^
petr has quit [Remote host closed the connection]
petr has joined #linux-sunxi
bonbons has quit [Ping timeout: 256 seconds]
paulk-collins has quit [Quit: Leaving]
paulk-collins has joined #linux-sunxi
bonbons has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
reinforce has joined #linux-sunxi
reinforce has quit [Client Quit]
reinforce has joined #linux-sunxi
jernej_ has joined #linux-sunxi
jernej has quit [Ping timeout: 256 seconds]
cnxsoft has quit [Ping timeout: 240 seconds]
cnxsoft has joined #linux-sunxi
jernej_ has quit [Read error: Connection reset by peer]
jernej has joined #linux-sunxi
yann-kaelig has joined #linux-sunxi
jernej_ has joined #linux-sunxi
jernej has quit [Ping timeout: 240 seconds]
LargePrime has quit [Ping timeout: 240 seconds]
xes has quit [Ping timeout: 264 seconds]
xes has joined #linux-sunxi
xes has quit [Client Quit]
LargePrime has joined #linux-sunxi
lkcl has quit [Ping timeout: 240 seconds]
The_Loko has joined #linux-sunxi
xes has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
LargePrime has quit [Ping timeout: 258 seconds]
Andy-D_ has joined #linux-sunxi
lkcl has joined #linux-sunxi
LargePrime has joined #linux-sunxi
victhor has joined #linux-sunxi
komunista has joined #linux-sunxi
|Jeroen| has quit [Quit: dada]
perr has joined #linux-sunxi
perr has joined #linux-sunxi
perr has quit [Changing host]
cnxsoft has quit [Quit: cnxsoft]
lurchi__ has joined #linux-sunxi
quard has joined #linux-sunxi
hp197 has quit [Ping timeout: 260 seconds]
jernej_ is now known as jernej
perr has quit [Remote host closed the connection]
<jernej>
MoeIcenowy: I ordered same monitor as you have. Lets merge the driver as it is and fix it later. It should already work with most monitors.
<MoeIcenowy>
why do you order it...
<jernej>
Because it has very low pixel clock (32 MHz) and such interesting for tests
<jernej>
and of course non standard resolution
<MoeIcenowy>
P.S. it's not a very good everyday display
<MoeIcenowy>
although I usually use it with development boards -- as it's quite small, and my desktop is size-limited
<jernej>
I don't intent to use it every day :) just for developing purposes and maybe some day in some permanent installation
lurchi__ is now known as lurchi_
<plaes>
fun.. debugging ccu-ng for A10
<plaes>
how can I see which simplefb node is enabled?
<plaes>
ah.. RST_LVDS :)
Mr__Anderson has joined #linux-sunxi
IgorPec has joined #linux-sunxi
hp197 has joined #linux-sunxi
sgteem has quit [Quit: leaving]
lurchi_ is now known as lurchi__
Andy-D_ has quit [Remote host closed the connection]
cptG_ has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 260 seconds]
cptG has quit [Ping timeout: 260 seconds]
|Jeroen| has joined #linux-sunxi
maik_ has joined #linux-sunxi
lurchi__ has joined #linux-sunxi
<silviop>
plaes: backlight is powered by a led strip , it substitute ccfl controller and is not controlled by chip (directly to 12V source). panel work ok with original controller
Mr__Anderson has quit [Remote host closed the connection]
lurchi__ has quit [Ping timeout: 258 seconds]
multi_io has quit [Ping timeout: 240 seconds]
The_Loko has quit [Quit: Leaving]
multi_io has joined #linux-sunxi
Keziolio has quit [Read error: Connection reset by peer]
Keziolio has joined #linux-sunxi
lkcl has quit [Ping timeout: 260 seconds]
Mr__Anderson has joined #linux-sunxi
maik_ has quit [Quit: Page closed]
maik_ has joined #linux-sunxi
<maik_>
For having audio on the nanopi NEO "Line Out", shall I enable CONFIG_SND_SUN8I_CODEC+CONFIG_SND_SUN8I_CODEC_ANALOG or CONFIG_SND_SUN4I_CODEC?
<ElBarto>
plaes: thanks for the dual licence :)
<plaes>
you're welcome
<plaes>
I hope all the files actually have it.. :S
terra854 has quit [Quit: Connection closed for inactivity]
<MoeIcenowy>
I have told you the problem of FreeBSD's USB PHY binding breaking the dt binding
<MoeIcenowy>
and after the PHY patches of this patchset are applied, the automatically controller switch function will be enabled for A64 in latter patch
<MoeIcenowy>
(Although the current Linux 4.11-rc device tree have already shown device tree binding difference between Linux and FreeBSD
<dave0x6d>
MoeIcenowy: None, blank SD card right now.
<MoeIcenowy>
dave0x6d: I strongly suggest you use mainline kernel ;-)
<dave0x6d>
MoeIcenowy: suggested image to flash?
<MoeIcenowy>
what more hardware functions do you need?
<MoeIcenowy>
BenG83: I think standard EHCI controller doesn't support it.
<dave0x6d>
uh, gigabit ethernet and USB gadgets
<dave0x6d>
bout it.
<MoeIcenowy>
oh you will need a patched version of mainline kernel for GbE
<dave0x6d>
MoeIcenowy: should I just use my orange pi instead?
<MoeIcenowy>
for opi you also need patches for GbE
<BenG83>
I made some hardware last year that had an OTG2.0 embedded host (OTG controller with USB-A port) and it could use HNP to switch roles without ID pin or arbitrate roles upon connection
<dave0x6d>
that has GbE?
my123 has joined #linux-sunxi
my123 has joined #linux-sunxi
my123 has quit [Changing host]
<MoeIcenowy>
oh not only GbE but also USB gadgets need patches
<dave0x6d>
lol
<MoeIcenowy>
montjoie is WIP on Ethernet for OPi, and I'm WIP on USB OTG
<dave0x6d>
well, what about non-mainline?
<MoeIcenowy>
3.10 kernel is a disaster
<MoeIcenowy>
you will need mountains of hacks to get a Pine64 with 3.10 kernel to work in gadget mode
<BenG83>
^ usb gadget is a pain on older kernels
<MoeIcenowy>
I will have a kernel branch that have working GbE and gadget out-of-box for Orange Pi PC2, and with a small hack for Pine64
<MoeIcenowy>
the hack is to manually change USB mode
<BenG83>
isn't the ID pin on some header, let me check
<MoeIcenowy>
BenG83: any GPIO can be used for ID pin.
<MoeIcenowy>
on Allwinner SoCs the MUSB's ID pin is not routed outside of the chip -- instead the driver deal with a GPIO as ID, then use the force ID mode in MUSB
<BenG83>
ah ok
<BenG83>
speaking of disaster, trying to debug axp8xx driver on the 3.10 kernel :/
<MoeIcenowy>
best wishes for you.
<BenG83>
fuel gauge seems to be not initializing properly :)
<BenG83>
regardless what I set in the dts
<BenG83>
it's always reading as 4800mAh
<BenG83>
which screws up the percentage output
<BenG83>
I'd rather write one for mainline :)
<BenG83>
but I think that is a bit out of my league
<BenG83>
I could write one for bare metal :P
<MoeIcenowy>
the R_CCU (CCU of PRCM) stays as a problem...
<MoeIcenowy>
no documents are available
<BenG83>
there seems also a problem in the BSP driver where the AXP doesnt do UVLO when the battery runs dry in suspend
fl_0 has quit [Quit: STRG + Q]
<BenG83>
or the ARISC rather
LargePrime has quit [Ping timeout: 246 seconds]
<MoeIcenowy>
if it's ARISC driver you will have no chance to fix it.
fl_0 has joined #linux-sunxi
<BenG83>
I know
<BenG83>
I am more interested in learning more how the AXP803 can be used really
<BenG83>
it's a bit sad that undervoltage lockout is more or less a software thing
<BenG83>
someone has to actually read the battery state and turn it off...
goldpank has joined #linux-sunxi
goldpank has left #linux-sunxi [#linux-sunxi]
<BenG83>
nvm me
<BenG83>
I found it, but it's not listed as undervoltage lockout
<BenG83>
REG31H: Powerup & Wakeup control
_hramrach has quit [Ping timeout: 260 seconds]
f0xx has joined #linux-sunxi
LargePrime has joined #linux-sunxi
Ntemis has joined #linux-sunxi
fl_0 has quit [Ping timeout: 264 seconds]
maik_ has quit [Ping timeout: 260 seconds]
fl_0 has joined #linux-sunxi
lkcl has quit [Ping timeout: 240 seconds]
<dave0x6d>
MoeIcenowy: is there any easy cheap USB gadget setup? =(
yann-kaelig has quit [Quit: Leaving]
komunista has quit [Quit: Leaving.]
lemonzest has quit [Quit: Leaving]
Mr__Anderson has quit [Remote host closed the connection]
<jelle>
which bluetooth driver is used for a uart bluetooth?
<jelle>
AP2122
<jelle>
*212
netlynx has quit [Quit: Ex-Chat]
|Jeroen| has quit [Quit: dada]
quard has quit [Quit: Leaving]
hp197 has quit [Ping timeout: 260 seconds]
lurchi__ has joined #linux-sunxi
hp197 has joined #linux-sunxi
iamfrankenstein has quit [Quit: iamfrankenstein]
silviop has quit [Remote host closed the connection]
Mr__Anderson has joined #linux-sunxi
f0xx has quit [Ping timeout: 240 seconds]
corecode has quit [Ping timeout: 252 seconds]
<MoeIcenowy>
dave0x6d: with mainline kernels usually it's easy
<MoeIcenowy>
you may get some source git branch and run it ;-)
<MoeIcenowy>
(although for Pine64 you will need to change one line in arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts )
<apritzel>
you need to compile ATF and copy or link it into U-Boot's source tree
<apritzel>
(the bl31.bin file)
<apritzel>
then the build process will package it automatically
<apritzel>
kloczek: this branch mimics how it should finally look like
<kloczek>
I have atf paces from Icenowy .. so there is no at the moment solution which is working without atf code?
<apritzel>
kloczek: no, and I don't see why there should be, really
<kloczek>
so atf will be integrated into u-boot?
<apritzel>
ATF is a proper open source project, living on Github and it's build in seconds
<apritzel>
kloczek: integrated into the U-Boot image file which is loaded by the SPL
<kloczek>
it is not about how long it builds
<kloczek>
simple separating atf makes build procedure complicated ..
<apritzel>
kloczek: that's the only downside, really
<apritzel>
but I still don't get it why everyone needs to build the firmware
<apritzel>
or if he really wants to build it, is complaining about complexity
<kloczek>
so it is any reason why atf is maintained in separated tree?
<apritzel>
kloczek: because it is a separate project?
<kloczek>
so why u-boot cannot load atf on boot stage?
<apritzel>
kloczek: what do you mean by that??
<kloczek>
seems uboot is fully working on pine64 without atf code
<apritzel>
U-Boot itself: yet
<apritzel>
but the SPL can only load _one_ binary at the moment
<apritzel>
which is what my SPL FIT series fixes
<apritzel>
the boot ROM loads the SPL (which can at most be 32 KB)
<apritzel>
SPL loads the rest of U-Boot and the ATF (and the right device tree)
<apritzel>
(this is with the SPL FIT patches)
<kloczek>
uboot i quite low lever code .. like C compiler for Elf binaries. IMO maintaining atf out of u-boot is like maintaining part of gcc code out of gcc tree :)
<kloczek>
other question
<kloczek>
from u-boot env
<kloczek>
boot_targets=fel mmc0 usb0 pxe dhcp
<kloczek>
Q: why fel is as first target?
<apritzel>
kloczek: I think this only is used if you actually boot via FEL
<apritzel>
to make sure that stuff that you loaded via FEL is really used
<kloczek>
so is it correct that it is on default list of targets? or maybe it should be as last one?
<apritzel>
does it make trouble?
<apritzel>
kloczek: I think it should bail out if you don't boot via FEL
<kloczek>
Occam razor ..
<apritzel>
but you would loose FEL booting without this
<kloczek>
so this is why I've asked is it correct to have it as first target :)
<apritzel>
yes, it looks like
<apritzel>
if you boot via FEL, it needs to be the first to be checked
<apritzel>
if you don't, it doesn't hurt
<kloczek>
ok
<apritzel>
kloczek: actually, have you tried booting via UEFI?
<apritzel>
we would like to make this work out of the box, but it needs more testing and probably some fixes
<kloczek>
seems to try it (to start setting up EFI) frst yu need to boot from kernel supporting EFI
<kloczek>
3.10.105 has missig sysfs tree related to efi :)
<apritzel>
3.10.105??
<apritzel>
I thought you were talking about mainline here
* apritzel
will walk away is asked any question about BSP kernels ;-)
<apritzel>
*if* asked
<kloczek>
with this kernel is only avalaible image working (somehow) based on fedora resources :)
<kloczek>
it bases on f24
<apritzel>
oh dear ...
<kloczek>
I've managed to upgrade, clean and add all missing bits using fedora rawhide
<apritzel>
can you try to use the official Fedora arm64 installer
<kloczek>
and now only missing bits are kernel and uboot :)
<apritzel>
if that comes with a 4.11-rc3 kernel
<kloczek>
it will be not working as I've already identified that sunxi-spl.bin is not packaged
<kloczek>
as well on aarch64 only used kerne is vmlinuz
<apritzel>
kloczek: the idea is: you put the firmware on an SD card, and the installer EFI app somewhere
<kloczek>
so this is in my pastebin is on top converting vmlinux to uImage format because u-boot cannot boot from vmlinuz
<apritzel>
(on an USB key, on a TFTP server, on an EFI system partition of that very same SD card)
<apritzel>
kloczek: how did you try that?
<apritzel>
bootz?
<apritzel>
bootz is only for arm32 kernels
<apritzel>
booti is the arm64 equivalent
<kloczek>
bootz is not nabled in default uboot pine64 board
<kloczek>
and it does not help here
<kloczek>
I've tested it yesterday
<apritzel>
as I said: bootz is pointless for arm64
<apritzel>
just use booti, same parameters as bootz
<kloczek>
IMO on aarch64 uboot should be able to use straight vmlinuz
<apritzel>
again, what is vmlinuz, exactly?
<kloczek>
my plan is to boot from 4.11 -> do efi setup -> boot u-boot->grub wth efi -> vmlinuz
<kloczek>
it is standard kernel format used on other CPU platforms like x86/x86_64
<apritzel>
every architecture has a different format, really
<kloczek>
grub seems will not have problems with booting from vmlinuz
<kloczek>
and this is why grub may be helpful ..
<apritzel>
make vmlinuz -> No rule to make target `vmlinuz'. Stop.
<apritzel>
There is no vmlinuz for arm64
<kloczek>
it is
<apritzel>
it may just be a name used by Fedora because people are used to it from x86
<kloczek>
I heard that OpenSuse already is using on arch64 u-boot-> uefi grub -> vmlinuz
<apritzel>
sure, and you should try the same with Fedora
<apritzel>
so how did you get the "vmlinuz" file?
<BenG83>
-rw-rw-r--. 1 benjamin benjamin 9537544 Feb 26 17:53 vmlinuz-4.10.0-next-20170224-pbtest1+
<BenG83>
if I do make install
<BenG83>
I get vmlinuz
<BenG83>
but I also get
<BenG83>
-rwxrwxr-x. 1 benjamin benjamin 9537544 Feb 26 17:54 Image
<kloczek>
and as you see my plan with pine64 and fedora goes over the same path
<BenG83>
Image and vmlinuz-xxxx are identical for me
<apritzel>
ah
<kloczek>
I'm using standard kernel fedora package
<apritzel>
so it's just a different name for the arm64 kernel image
<apritzel>
which you can boot fine with booti, if you like
<kloczek>
gain .. I'm trying to stick as much as possible with fedora binary resurces
<apritzel>
or feed it to grub
<kloczek>
no .. booti does not recgoise vmlinuz
<BenG83>
for whatever reason kloczek's vmlinuz seems not to be the same as Image
<kloczek>
so this is why I've been asking here about grub as well :)
<apritzel>
kloczek: so why do you need boot Linux directly from U-Boot if you want to use EFI and grub anyway
williamfligor has joined #linux-sunxi
<kloczek>
it is not the same format
<kloczek>
my inderstanding is that Linux efi support is part tof grub
<apritzel>
kloczek: so is it just gzip'ed, by any chance
<kloczek>
no it s not
<williamfligor>
I'm trying to get the linux-sunxi (3.4 kernel) to work with uboot 2016.11, I have it building but when I try and boot I get "Error: unrecognized/unsupported machine ID (r1 = 0x00000000).". If I reboot and use "setenv machid 0x00001029" it will boot. Anyone know how to get the machid set correctly?
<kloczek>
sorry but I'm really not interested Linux archeology :)
<kloczek>
only latest kernel 4.11 rc :)
<apritzel>
kloczek: U-Boot provides the required EFI bits to start EFI apps
<apritzel>
which could be either grub
<apritzel>
or the (EFI stubbed) Linux kernel directly
<kloczek>
I dob'yt want to spend few weeks on on integrate tons of patches to have working any 3.x.x kernels
<kloczek>
and this is why I'm trying to stick as much as possible to every day updated devel distro like fedora rawhide
mzki has quit [Ping timeout: 260 seconds]
<williamfligor>
Nevermind, I just needed to prepend "setenv machid 1029" to the boot.cmd.
mzki has joined #linux-sunxi
<kloczek>
so seems like not to many people here been playing with efi (?)
<apritzel>
kloczek: not really, unfortunately
<apritzel>
kloczek: that's why I was hoping you could explore this a bit more
<apritzel>
kloczek: you should not need to use U-Boot command to get this working
<apritzel>
as U-Boot with the new EFI features should be able to find everything
<kloczek>
and as I wrote here I'm not sure about vmlinuz->uImage conversion procedure which is using ubootAddress=0x00008000
<kloczek>
so this is why one of my questions was that one about is this addres correct or not (I've copied it from RPi 3 vmlinux->uImage conversion procedure)
<kloczek>
as you see generated uImage and uInitrd have been correctly recognized by uboot
<kloczek>
the same is with dtb
<apritzel>
well, it's not, it's 0x40080000
<kloczek>
only thing which I've so fare corrected to gain this point was marking 3rd partition as bootable to allow uboot correctly recognize my rootfs with /boot on single volume
<kloczek>
however look on uboot log
<kloczek>
## Booting kernel from Legacy Image at 40080000 ...