<apritzel>
KotCzarny: I'd try an upstream U-Boot, A13 with DDR3 DRAM and eMMC sounds like easy porting
<KotCzarny>
so its not upported in mainline yet?
<apritzel>
why do you ask me?
<KotCzarny>
just in case you know, if you dont, assume there was no question
<ssvb>
what kind of model variant is that? how does it compare to kindle?
<KotCzarny>
ssvb: um, it's based on a13, has 256M of ram, 4G of internal storage (i have yet to confirm if its nand or emmc) and eink pearl
<KotCzarny>
800x600
<KotCzarny>
also has multitouch touchscreen
<KotCzarny>
and wifi
<KotCzarny>
it's also old and cheap
arnd has quit [Changing host]
arnd has joined #linux-sunxi
bamvor has quit [Changing host]
bamvor has joined #linux-sunxi
<ssvb>
kindle is also old, just the specs seem to be very much comparable
<ssvb>
so I wonder which of these is "better" :-)
<KotCzarny>
well, this one is theoretically capable of being unlocked and able to run your own linux
<KotCzarny>
dont know how hackable kindle is
<ssvb>
I have no idea, I just use kindle for reading books
<ssvb>
but a more "open" alternative might be nice
<KotCzarny>
i want to piece together my own reader, because i havent found one that does everything i want from ereader right (ie. my way)
<KotCzarny>
hmm, should i see some output via uart when booting to fel via sd card?
<NiteHawk>
if you're referring to fel-sdboot.sunxi then: no. it just enters FEL mode silently, but you can verify that a new USB device shows up on the host side ("lsusb", "./sunxi-fel --list --verbose")
<KotCzarny>
nitehawk: fel mode works, right now i'm just hacking ghetto uart connection without soldering
<KotCzarny>
and i'm wondering how to make sure it works
<NiteHawk>
maybe use uart0-helloworld.sunxi from sd card?
<KotCzarny>
cool, is it in sunxi tools?
<NiteHawk>
yup
<KotCzarny>
thx
<KotCzarny>
btw. is it possible to add some uart output to fel-sdboot too?
<apritzel>
KotCzarny: I guess this is beyond fel-sdboot as it is
<apritzel>
KotCzarny: because FEL boot itself is pretty easy: branch to some address
<NiteHawk>
not really. it might be, but we'd potentially have to be cafeful to avoid any ill side effects. if you look at the source for uart0-helloworld, you'll see that it involves some initialization, e.g. setting up of clocks. contrary to that, the fel-sdboot is essentially nothing else but a jump instruction to the BROM (FEL) entry point
<apritzel>
KotCzarny: and there are just two addresses, which all Allwinner SoCs use
<KotCzarny>
uhum
<apritzel>
KotCzarny: I have a small hacker tool I am working on, looks like an SPL, but has a simple command line interface
<plaes>
hacker tool for what?
<apritzel>
there you can do reset, switch to FEL, check the CPU, read memory, check SID efuses
<plaes>
can't we just add these commands to u-boot?
<KotCzarny>
apritzel: nice
<apritzel>
check and read SPI flash, ...
<NiteHawk>
it think its preferable to keep the tools separate, as their success is simple enough to validate/verify. if you want UART output after you've entered FEL mode, you can still run uart0-helloword via sunxi-fel ;)
<apritzel>
eventually I want to add MMC read/write support, so you can flash images from SD card to SPI flash
<plaes>
btw, swabbles just sent sunxi SPI driver for u-boot
<KotCzarny>
nitehawk: nice idea
<beeble>
apritzel: your goal is to run from sram? otherwise most of the stuff is already available in u-boot?
<apritzel>
beeble: yes, SRAM only and also all SoCs supported automatically
<apritzel>
beeble: it's based on uart0-helloworld, then adding stuff on top of that
<apritzel>
beeble: do this for three months and you get the idea ;-)
<plaes>
:D
<apritzel>
beeble: so yes, there is quite some overlap with U-Boot, but the main difference is being board and SoC agnostic
<beeble>
will not try to keep you from doing it. it just sounds like a lot of duplicated work that could go into having proper devicetree driver in uboot
<beeble>
instead of the ifdef hell we are now
<apritzel>
beeble: if you think about it being a procrastination vehicle, you are spot on :-D
chomwitt has joined #linux-sunxi
<apritzel>
beeble: and yes for killing ifdef hell
* apritzel
returns now to preparing the FIT support patches ...
<beeble>
sorry, didn't want to make you feel guilty :)
<apritzel>
beeble: no worries, I mostly agree to your arguments, it's just so much fun hacking this ;-)
<beeble>
that's the most important thing while doing all that stuff. so keep going and have fun
<KotCzarny>
is anyone producing clamp-on-pads connectors?
<KotCzarny>
hrm, either my uart adapter is dead, boot0-helloworld doesnt print anything or those pads arent enabled
FiveBroDeepBook has joined #linux-sunxi
<Wizzup>
The driver you linked has DT patches, doesn't it?
FiveBroDeepBook has left #linux-sunxi [#linux-sunxi]
<apritzel>
Wizzup: well, yes, the basic stuff that the DM mandates, but for instance the pins are still hardcoded
<Wizzup>
Right, I think that's mentioned :)
<Wizzup>
I'm going to test the driver on the a64 olinuxino when it arrives on monday
zunway has joined #linux-sunxi
huawei has quit [Ping timeout: 245 seconds]
<apritzel>
Wizzup: I know that's what sunxi does all over U-Boot, but it would be worth to get away from this
<apritzel>
Wizzup: and this driver could be a first example
<Wizzup>
apritzel: agreed, sounds like a good idea
<apritzel>
Wizzup: I contributed a hack in the sun8i-emac driver to cover at least the pins
<Wizzup>
btw, with that driver we were able to boot from linux+initramfs from nothing but flash, with fit image in u-boot instead of in spl :)
<apritzel>
but the guys from Theobroma (beeble) have quite some patches to fix this properly
<apritzel>
Wizzup: yeah, that's probably the way to go, but since I had SPI and needed FIT in SPL anyway, I just went with this, more as a proof of concept
<apritzel>
Wizzup: and we still need FIT in SPL to cater for the ATF image
<Wizzup>
ATF?
<apritzel>
ARM Trusted Firmware
<Wizzup>
mmmh
<apritzel>
but that doesn't hurt
Mr__Anderson has joined #linux-sunxi
<apritzel>
you have a FIT image with U-Boot proper, ATF and various DTs to start U-Boot
<apritzel>
and a FIT image with the kernel and initrd for Linux
<apritzel>
you _can_ stuff this all into one loaded by the SPL, but having this separate is much cleaner
<Wizzup>
apritzel: got a link to the sun8i-emac-driver hack so we can look at what you're suggesting wrt the dt/pins?
<apritzel>
I believe this has proper DM pinctrl support
<apritzel>
and there is also a SPI driver in this branch ;-)
<apritzel>
swabbles: converting the clocks over to be fully DT controlled sounds like a lot of work
<apritzel>
swabbles: especially as the new sunxi-ng binding is of no special help here, since we still need to have a per-SoC clock driver hardcoded
<swabbles>
that SPI driver needs a lot of refactoring and is sun6i-only though.
<swabbles>
converting the clocks over could be done in smaller steps, maybe.
BenG83 has quit [Quit: Leaving]
<apritzel>
swabbles: so I just checked my pinctrl patches: they move the code out of sun8i-emac.c into sunxi generic paths, so it can be easily reused from your driver
cnxsoft has quit [Remote host closed the connection]
<swabbles>
that would be nice.
<apritzel>
you basically just need to call one function and pass it the DT node
<apritzel>
it doesn't cover the mux value, though, since this is not in the DT :-(
<swabbles>
in which branch is this?
<apritzel>
swabbles: on my box only atm, but I can push it somewhere
Tyen has joined #linux-sunxi
<swabbles>
if you can push it somewhere or have some patches that I can apply, then that would be greatly appreciated :).
Gerwin_J has quit [Quit: Gerwin_J]
<apritzel>
the mux value (3) seems to be the same for all SoCs?
Tyen has quit [Client Quit]
<apritzel>
swabbles: Dutch is really the best language in Europe ;-)
<jelle>
I agree
<swabbles>
mowię po polsku tez ;-)
<swabbles>
or well a little bit because of my gf.
<apritzel>
swabbles: I don't speak Polish, it's just the name ;-P
<swabbles>
Ah :).
fkluknav has joined #linux-sunxi
<swabbles>
I wish the other countries would do a better job at impersonifying Trump :').
<apritzel>
swabbles: have you seen the other videos?
xmajedz has joined #linux-sunxi
<swabbles>
Yep, most of them.
<apritzel>
swabbles: the German guy was mad because the Dutch did such a good job: "and we can't make it any better, really" ;-)
<swabbles>
The Dutch one was basically spoken in by this comedian who has been doing presidential voices for a long time.
<buZz>
dutch \o
<apritzel>
I like the word "huisarts"
<buZz>
lets replace all kernel comments in linux-sunxi with dutch
<buZz>
;)
<swabbles>
lol, I wouldn't even know how to translate half of the jargon.
BenG83 has joined #linux-sunxi
<Wizzup>
swabbles: simple; use the english words, that's what the dutch do
<swabbles>
or we could start calling "drivers" "bestuurders."
<MoeIcenowy>
apritzel: do you have a SoPine now? ;-)
<apritzel>
MoeIcenowy: I have had an early prototype for months now, but didn't use it yet
<MoeIcenowy>
SoPine uses LPDDR3...
<apritzel>
MoeIcenowy: but I was planning on adding LPDDR3 support on top of your patches
<apritzel>
I know ...
jernej has joined #linux-sunxi
<MoeIcenowy>
maybe it will lead to ATF change
<MoeIcenowy>
your sunxi_power.c dumbly changed DRAM power to 1.5V
<apritzel>
for the DDR power supply?
<MoeIcenowy>
yes
<MoeIcenowy>
to be honest usually the default value is good
<apritzel>
I have fixed this already
<apritzel>
indeed
<apritzel>
it's just that the Pine64 is broken in this respect
<MoeIcenowy>
what...
<apritzel>
the default value is 1.24V, whereas we need 1.35V for the DDR3L
<swabbles>
That is what I added for the A20 OLinuXino LIME 2.
Keziolio has quit [Changing host]
Keziolio has joined #linux-sunxi
<beeble>
apritzel: no, haven't checked. but phil has one that is devicetree enabled and i had tested. told me last week he want to sumbmit them till friday. but haven't seen it on any list yet
<apritzel>
MoeIcenowy: I though that every OPiZero now comes with SPI flash?
<apritzel>
thought*
<MoeIcenowy>
as OPi guys told me
<MoeIcenowy>
only 512 ver come with spi flash presoldered
<apritzel>
MoeIcenowy: ah
<apritzel>
swabbles: plus you need the config symbol in the defconfig
<apritzel>
swabbles: that's why I was pointing this out: you should provide a template for other boards how to enable it
<swabbles>
thanks :).
<swabbles>
It probably makes the most sense to enable this by default for the Orange Pi Zero 512MB then.
<apritzel>
swabbles: currently we don't differentiate between the two versions, I believe
<MoeIcenowy>
and there's no need to differentiate
<apritzel>
and I guess we don't need to
<swabbles>
that board is pretty cheap btw.
<swabbles>
$8.99
<apritzel>
MoeIcenowy: exactly ;-)
<MoeIcenowy>
$8.99 is 256MiB ver, right? ;-)
Putti has quit [Ping timeout: 240 seconds]
<swabbles>
no, 512 MiB.
<swabbles>
The 256 MiB is like $6.99.
<MoeIcenowy>
wow
<apritzel>
I think we can always detect a SPI flash, and the 256MB version probably still has the footprint, right?
<MoeIcenowy>
yes.
<MoeIcenowy>
one with soldering skill can easily attach one ;-)
<beeble>
i2c would benefit from devicetree too. i tried to patch something last week and had to give up because there are only sunXXi ifdefs and without introducing soc specfic ifdefs it was to much of a hassle
<beeble>
*too
<beeble>
sunxi/board.c gets more and more hard to maintain imho
Putti has joined #linux-sunxi
<beeble>
but that may be only my opinion since i'm not much of a sbc user
dave0x6d has joined #linux-sunxi
<apritzel>
beeble: yes, there's a lot of stuff to do .. ;-)
<beeble>
at least with mmc and gpio there should be some patches soon
<KotCzarny>
jelle: soo, how do i connect it to that non-booting ereader? ;)
<jelle>
ohh e-reader
<KotCzarny>
now i have to find something to keep it in place when i turn it upside down
<BenG83>
I took some time yesterday to add a FEL button breakout to my PB prototype after I almost killed it with the loose setup I hade before.... https://imgur.com/a/4fHMO
<BenG83>
hotglue ftw
<KotCzarny>
hotglue doesnt conduct electricity?
<jelle>
it shouldn't
<KotCzarny>
but it also shouldnt be used in areas that can get hot
<BenG83>
:)
<BenG83>
the new PB pcbs seem to have a proper fel button and UART0 pins multiplexed on a USB connector
<muvlon>
looks like you could fit a cable tie around the entire board and the "connector"
<MoeIcenowy>
BenG83: Pinebook?
<BenG83>
yes
<BenG83>
I got this from Tl during the FOSDEM meeting
Xal1us_Ph has joined #linux-sunxi
Xalius_Ph has quit [Read error: Connection reset by peer]
Xal1us_Ph has quit [Client Quit]
<MoeIcenowy>
how is its display connected?
<swabbles>
KotCzarny: lol
<MoeIcenowy>
DSI or RGB?
<BenG83>
RGB output but via a display port bridge
<BenG83>
ayufan alread has the LCD up and running with his Android images and we were able to boot Linux with the LCD as well
<BenG83>
using BSP kernel
<jelle>
hmm nanopi neo wifi seems slow
<BenG83>
schematics are on the PB shop page
mossroy has joined #linux-sunxi
<BenG83>
how far away would the mainline driver for RGB output be?
<MoeIcenowy>
oh it's like Olimex TERES I
<BenG83>
yes
<BenG83>
more or less the same reference design
<BenG83>
the eDP bridge is the same
<MoeIcenowy>
I doubt Allwinner did a “A64 Laptop Reference Design"
<MoeIcenowy>
as Allwinner really shown some Laptops
<BenG83>
it's the A114 tablet reference design
<MoeIcenowy>
so I may apply a Pinebook as a reference to TERES I ? ;-)
<MoeIcenowy>
What WLAN card is Pinebook using?
<MoeIcenowy>
Does it use a internal USB Hub? (I think this answer must be YES)
<BenG83>
rtl8723cs
<BenG83>
yes there is a hub to connect the camera and the 8051 based HID device that does keyboard and touchpad
<jelle>
TERES I uses a realtek too
<MoeIcenowy>
TERES uses BS
<jelle>
BS?
<BenG83>
yeah Teres uses BS
<BenG83>
like the Pine boards
<BenG83>
PB uses CS where BT works differently
<BenG83>
but all the A64 laptops are based more or less on the same reference design
<BenG83>
at least what I have seen so far
<BenG83>
Azpen Hybrx and others
<BenG83>
we can boot from sdcard or eMMC on the PB atm
<MoeIcenowy>
CS and DS have different BT?
<BenG83>
SPI flash would have been nice to have too
<BenG83>
I haven't seen the PCM interface on the CS
<BenG83>
for BT audio
<BenG83>
and I think it doesnt have the BT uart
<MoeIcenowy>
maybe it's a good thing ;-)
<MoeIcenowy>
oh no BT uart... how can that be
<MoeIcenowy>
P.S. NextThingCo people said that the RTL8723DS on CHIP Pro have currently no supported bluetooth
<BenG83>
BT seems to work at least for Android with the cs kernel module
wens has quit [Ping timeout: 240 seconds]
<BenG83>
MoeIcenowy, did Tl contact you, I think he's coming to China at end of february
<MoeIcenowy>
yes
<MoeIcenowy>
I may meet him the week after next week
souther has joined #linux-sunxi
<MoeIcenowy>
maybe I should ask him for a Pinebook sample? ;-)
<KotCzarny>
ask before he starts the trip
<jernej>
MoeIcenowy: I will update your DE2 page
<MoeIcenowy>
jernej: thx ;-)
<BenG83>
you should MoeIcenowy :)
<jernej>
MoeIcenowy: But I'd like to test few things first, just to be sure
<MoeIcenowy>
after filling enough info, please remove its Icenowy/
<BenG83>
not sure how many he has left
<BenG83>
he wanted to check on production of the release units now after the Chinese New Year
<BenG83>
I think that is one of the reasons why he is in China
<jernej>
for example, mux0 usually coresponds to tcon0 and mux1 to tcon1, but DE2_CCU_SEL can switch that
<jernej>
at least that my experiments show
<MoeIcenowy>
you are breaking my dream to implement DE2 as several dedicated blocks ;-)
<jernej>
well, mux0 is always more capable than mux1 and it seems pretty clear from HW design what Allwinner has in mind
<jernej>
A series of SoCs has HDMI on tcon1 which means that it is secondary in nature
<jernej>
Unfortunatelly, A64 doesn't cooperate for now to test this further :)
<jernej>
hm, maybe A83T will
<MoeIcenowy>
hm I think A83T may face the same problem.
<MoeIcenowy>
P.S. on A64 the reset of Mixer1 is at bit 1, not bit 2
<MoeIcenowy>
that verified by BSP source
<jernej>
MoeIcenowy: I find a way to instantiate DM driver in U-Boot without DT, but comments said that such way is highly discouraged in favor of DT
<MoeIcenowy>
ignore the comments ;-)
<MoeIcenowy>
without a proper DT is a better way
<MoeIcenowy>
s/is/it's
<jernej>
I concur, but anyway, I can also add dummy DT nodes
<jernej>
MoeIcenowy: do you plan to make DE2 Linux driver?
<jernej>
or at least adapt jf moines one?
<MoeIcenowy>
jernej: I may make one from dummy...
<jernej>
dummy?
<MoeIcenowy>
from scratch...
<jernej>
ah, ok
<MoeIcenowy>
maybe I didn't choose the good word
<jernej>
why wouldn't you reuse jfm work?
<jelle>
is there progress in the u-boot h3 hdmi output?
<jernej>
jelle: I had to rewrite driver to support DM video framework
<MoeIcenowy>
although after I know about your mux found, I think adopting his work is also acceptable ;-)
<jelle>
jernej: ahhh I see why that can take some time :)
<MoeIcenowy>
I used to dream to reuse sun4i-drm
<MoeIcenowy>
but this dream brekas
<MoeIcenowy>
breaks
<jelle>
jernej: if you need testing, I have multiple h3 devices
<jernej>
jelle: but if you don't mind to reuse v1 series, it works pretty good
<jelle>
cool!
<MoeIcenowy>
v1 is working stable enough -- it's not merged only because it's not DM based
<jernej>
I even managed to make cloned display on HDMI and TV out
<jelle>
woah
<jernej>
and separate is possible too
<jelle>
that's interesting for all kinds of projects :D
<jernej>
Ok, so I can add this functionality to v1 driver if anyone is interested
<jernej>
at least it is easy to use this through simplefb
<jernej>
MoeIcenowy: please say to tllim that A64 GPL package is not entirely GPL (apart from blobs)
<MoeIcenowy>
for A64 the problem is that we cannot even get DE2 to work...
<jernej>
MoeIcenowy: For example, DE2 code doesn't have much of GPL headers
<jernej>
MoeIcenowy: It would help us a lot, if they were
<MoeIcenowy>
I remembered when we started to make H3 HDMI mainline...
<MoeIcenowy>
it's that in R16 BSP that the sources are GPLed
<MoeIcenowy>
(I mean the HDMI guys
<jernej>
MoeIcenowy: Yes, HDMI is there with GPL2, but not DE2 code, at least not entirely