<KotCzarny>
first i would need booting linux, which isnt (legacy panics on papyrus and my own build doesnt even start
<plaes>
vendor linux one doesn't have serial console?
[7] has quit [Ping timeout: 256 seconds]
<KotCzarny>
see 'panics'
TheSeven has joined #linux-sunxi
<KotCzarny>
it doesnt get to userland
<plaes>
o_O
<KotCzarny>
mainline uboot should detect both busses or they have to be enabled in board config?
<plaes>
dunno :)
<plaes>
there's CONFIG_SPL_I2C_SUPPORT=y
<plaes>
I guess create a simple a13 device tree that enables all i2c buses
<KotCzarny>
its already enabled
<KotCzarny>
(the i2c_support option)
chomwitt has quit [Ping timeout: 252 seconds]
<KotCzarny>
hmm, sub5i.dtsi defines same twi[012] as fex file
<KotCzarny>
so theoretically it should be enabled
<terra854>
So 4.11 can fully run a headless server (no HDMI/LCD) on A64 devices?
<KotCzarny>
oh, status = "disabled"
<KotCzarny>
but it's also disabled for i2c0 and somehow it comes up
<MoeIcenowy>
terra854: you will need to apply sun8i-emac or sun8i-stmmac patch
<terra854>
For ethernet?
<KotCzarny>
hmm, sun5i-a13.dtsi defines lcd_rgb666_pins pd18/19 which in fex are used for tps65185_wakeup/vcom, could it be that fried the eink controller?
<MoeIcenowy>
if it's not enabled, maybe it won't
<MoeIcenowy>
terra854: yes
<KotCzarny>
i think it was..
<MoeIcenowy>
KotCzarny: if you do not enable LCD, the pinctrl node won't be used
<KotCzarny>
i've copied jernej's h3 display enabled tree
<terra854>
MoeIcenowy: So that is the ethernet driver for the A64 that goes to the mainline?
muvlon has quit [Ping timeout: 245 seconds]
reinforce has quit [Quit: Leaving.]
<MoeIcenowy>
terra854: it's still pending
<MoeIcenowy>
montjoie is WIP on making it better
<MoeIcenowy>
but it's usable now
reinforce has joined #linux-sunxi
<terra854>
MoeIcenowy: Do i need to manually run a diff between that tree and the mainline 4.10-rc2 tree?
<terra854>
MoeIcenowy: Cause I don't see a patch floating around for it
<MoeIcenowy>
maybe after 4.11-rc is out a merged tree will be ready ;-)
<terra854>
Including the mmc and usb support wens was talking about?
muvlon has joined #linux-sunxi
IgorPec has quit [Ping timeout: 260 seconds]
<montjoie>
even dwmac-sun8i is very usable now
<MoeIcenowy>
terra854: mmc and usb is in mainline 4.11
<MoeIcenowy>
but dwmac-sun8i is still out-of-tree
<MoeIcenowy>
montjoie: can you send out dwmac-sun8i in 4.12 merging window?
<montjoie>
I need to finish some todo but I will try
f0xx has joined #linux-sunxi
<KotCzarny>
to enable i2c1 its enough to add &i2c1 { status = "okay"; };
<KotCzarny>
right?
<beeble>
if the dtsi ist written correctly, yes. a13 does not have multiple pinmux options for twi1
<KotCzarny>
yes, it's including default a13 config
<KotCzarny>
ssvb, nitehawk: to boot uboot via fel i have to run: sunxi-fel uboot u-boot-sunxi-with-spl.bin right?
<KotCzarny>
or do i have to provide more files? (that bin file is booting fine from sdcard, and it's mainline one
<KotCzarny>
(2016.11-rc2)
<KotCzarny>
beeble: if i2c1 isnt showing in i2c bus, it means its fried?
<beeble>
are you takling linux or uboot?
<terra854>
so ethernet is not ready for 4.11?
<beeble>
if uboot then enabling it in the dts is not sufficient. the i2c driver is not yet devicetree enabled. so you have to set the correct I2C config options in .config
<beeble>
KotCzarny: and you should look into the ifdef jungle if the pinmus is setup correctly
<KotCzarny>
to do anything with i2c i would need to see it on the bus
<KotCzarny>
and setting wakup/pwrup pins doesnt make it available
<beeble>
montjoie: tested your stmmac-sun8i-wip-next-20170210 with a micrel phy. plain iperf3 without any additional settings/tuning 936 in both directions
<KotCzarny>
maybe i should cut battery connector, hum
fdcx has quit [Remote host closed the connection]
<KotCzarny>
or is there a way to make axp209 cut the power to the whole board?
<beeble>
pin 25 :)
<beeble>
reset will do a power cycle on axps
<KotCzarny>
so, simply shorting it to the ground cuts WHOLE power? gotta try it
<montjoie>
thanks beeble
<KotCzarny>
is it a trigger or i can held it in hopes of draining all voltages?
<beeble>
it's triggered on a falling edge and will do a shutdown followed with a power up. and keep doing it if you keep it low. so no benefit in keeping it low as it will cycle through the power up
fdcx has joined #linux-sunxi
<beeble>
montjoie: is this roughly the same as with the realtek on your pine/h3?
<montjoie>
on my pine64 I got less Tx 500 RX 700 at max
<montjoie>
my h3 board (bpim2+) is worst 100/150
<beeble>
ah forgot to mentions. a64 here
<beeble>
*mention
<wens>
KotCzarny: iirc it doesn't cut RTC power
<KotCzarny>
wens, i want to try resetting i2c device in hopes its not fried just stuck
<leon-anavi>
I need help with A20 OLinuXino MICRO :)
<leon-anavi>
What should I do to enable the 7" Olimex touch screen on mainline kernel for A20-OLinuXino-MICRO?
IgorPec has joined #linux-sunxi
<leon-anavi>
Following the instructions from linux-sunxi wiki I have already modified the mainline u-boot and I am able to see the video output on the 7" screen but the touch screen does not work out of the box. I guess I should change something in the kernel defconfig, shouldn't I?
popolon has joined #linux-sunxi
dave0x6d has quit [Quit: Connection closed for inactivity]
IgorPec5 has joined #linux-sunxi
fkluknav has joined #linux-sunxi
Laibsch has joined #linux-sunxi
<Laibsch>
Hi guys, one of the questions I have is how you would rate GPL-compliance of Rockchip vs Allwinner vs Amlogic? Or are they all equally bad?
<KotCzarny>
but i think device is still available, 1f3a:efe8
<NiteHawk>
hmm... you get the L2 cache and stack output, but it seems that the next step aw_backup_and_disable_mmu() might cause trouble
<KotCzarny>
if you want me to test anything just shout
fkluknav has quit [Ping timeout: 255 seconds]
muvlon has joined #linux-sunxi
<NiteHawk>
I have currently no good idea of what is going on there :/
<KotCzarny>
plainly something hangs
<KotCzarny>
either fel stack or soc
<KotCzarny>
does sunxi-fel do some checksumming if data transferred was ok?
<KotCzarny>
or its not possible?
<NiteHawk>
not at that particular stage
<NiteHawk>
the thing is that you get stack even before it tries to load/execute the SPL, which is rather unusual
<NiteHawk>
s/stack/stuck/
Laibsch has quit [Read error: Connection reset by peer]
wzyy2 has quit [Read error: Connection reset by peer]
<BenG83>
morning
Mr__Anderson has joined #linux-sunxi
<BenG83>
does anyone know if using the SDIO3.0 bus on SDC1 for the A64 allows for 433Mbit wifi modules? Theoretical bandwith should be around 600Mbit if I read the datasheet correctly...
huawei has joined #linux-sunxi
vinimac has joined #linux-sunxi
<ssvb>
KotCzarny: just add debug prints everywhere and identify where it gets stuck
<KotCzarny>
i might try using opipc instead to run uboot on that ereader
<ssvb>
yes, please try that
foxx has joined #linux-sunxi
<ssvb>
if opipc also fails to FEL boot, then it would indicate that there might be something wrong with your virtualbox USB thingie
<NiteHawk>
i don't think the USB emulation helps - the FEL protocol may be sensitive to timing issues, and your bulk size experiments to me point a bit in that same direction. better verify it on "real" hardware first
<KotCzarny>
i should get bigger desk, getting crowded here
KotC has quit [Quit: brb]
foxx has quit [Ping timeout: 240 seconds]
<BenG83>
I had all sorts of problems running FEL or u-boot ums through Virtualbox
<BenG83>
didn't work at all with USB3.0 emulation
<BenG83>
and USB2.0 was unstable
<KotCzarny>
apparently running from opipc worked
<NiteHawk>
\o/
<ssvb>
do you mean that you successfully FEL booted your bookreader by running sunxi-fel on opipc?
<ssvb>
basically, if you have already started the main u-boot part, then it does not talk FEL protocol anymore
<ssvb>
that's why you need to run "sunxi-fel spl u-boot-sunxi-with-spl.bin" (the "spl" command instead of "uboot") in order to be able to read/write DRAM
Keziolio has joined #linux-sunxi
Keziolio has joined #linux-sunxi
Keziolio has quit [Changing host]
<KotCzarny>
yup, that's it, thx again
<KotCzarny>
570kB/s
<KotCzarny>
and 944kB/s when ran from opipc
<KotCzarny>
target was the same a13 ereader
flygoat has quit [Quit: Connection closed for inactivity]
<ssvb>
hmm, that's very interesting
<ssvb>
is the 944kB/s speed reproducible when transferring large data blocks?
<KotCzarny>
yes, it was 8MB block
<KotCzarny>
want me to try something bigger?
<ssvb>
well, as you can see in the speed results table, we got a lot of various numbers there
<KotCzarny>
yup, just added a note about that
<ssvb>
it is not quite clear what causes this particular difference (between ~500KB/s and ~900KB/s)
<KotCzarny>
i bet it's the os adding some overhead
<KotCzarny>
and i bet those 900+ results were all ran from linux
<KotCzarny>
and those ~500-600 from windoze
<ssvb>
just try to check if the high transfer speed is really reproducible for you after a few reboots
<KotCzarny>
reboots of a13 or hosts?
<KotCzarny>
all i did was reconnecting cable between opipc and laptop
<KotCzarny>
when reconnected to laptop it was 570 again
<KotCzarny>
so it's reproducible
<ssvb>
preferably reboot both
<ssvb>
the host system in your case is the opipc, right?
<KotCzarny>
yes, i'm using a13 as a target in both cases
<ssvb>
BTW, most of the speed test results are from my Intel Core i7 computer running Linux
<NiteHawk>
i've noticed a distinct difference in FEL write speeds on my a20 (bpi-m1) depending on whether uart is connected, or not
<KotCzarny>
maybe you should redo them and mark system/os used?
<ssvb>
I doubt that anyone used Windows for these benchmarks before :-)
<KotCzarny>
nitehawk: uart was connected in both cases
<ssvb>
NiteHawk: yes, it would be great to identify what exactly affects the transfer speed
<KotCzarny>
latency? overhead? noise?
<NiteHawk>
KotCzarny: did you build the cygwin sunxi-fel yourself, or is that the precompiled binary from appveyor?
<KotCzarny>
though noise shouldnt, as you dont do retransmits
<KotCzarny>
used the binary
<NiteHawk>
ok, fine
<KotCzarny>
hmm
<KotCzarny>
i'll try disconnecting uart from laptop
<NiteHawk>
error -7 might even be misleading in this particular (VM) case. the usual cause is that the FEL handler crashed, often due to attempts to access ununitialized memory (DRAM)
<KotCzarny>
add '*might*' then
<NiteHawk>
but agreed, we could be a bit more verbose on that -7
<NiteHawk>
you too didn't tell us you're using a VM right away - and thus sent us chasing phantoms ;)
DullTube has quit [Quit: Leaving]
<KotCzarny>
too many variables affecting same error code
lemonzest has quit [Ping timeout: 240 seconds]
<KotCzarny>
fun, mkimage doesnt work on network drive
Nemo_bis_ is now known as Nemo_bis
Nemo_bis has quit [Changing host]
Nemo_bis has joined #linux-sunxi
lemonzest has joined #linux-sunxi
fkluknav has joined #linux-sunxi
chomwitt has joined #linux-sunxi
<KotCzarny>
is there some 'wait for device' switch in sunxi-fel ?
<NiteHawk>
currently not. iirc, ssvb was working on some sort of "fel deamon" for a while
<NiteHawk>
"./sunxi-fel --list" sets its exit code depending on whether devices were found or not. you could use that (with "sleep") in a while loop from a shell script
<KotCzarny>
will do that probably
<KotCzarny>
though such switch should be simple, or maybe it might even be a command looping over ver till it gets something
<NiteHawk>
how about this additional info?
<NiteHawk>
usb_bulk_send() ERROR -7: Operation timed out
<NiteHawk>
that wasn't properly initialized (by running boot0/SPL).
<NiteHawk>
SoC has crashed. One possible cause could be a attempt to access DRAM memory
<NiteHawk>
The FEL handler seems no longer responsive. This error might indicate that the
<NiteHawk>
You probably need to reset / power-cycle the device now.
<KotCzarny>
'has crashed or booted.'
Laibsch has joined #linux-sunxi
<KotCzarny>
running uboot or linux or anything exits fel mode too
<NiteHawk>
right, good point. "has crashed or exited FEL mode"
<KotCzarny>
can i combine u-boot-spl.bin from mainline with u-boot.bin from legacy and have a working u-boot-with-spl.bin ?
<ssvb>
KotCzarny: why would you want this?
<NiteHawk>
could be, though I'm not sure. try it with running the SPL alone (sunxi-fel spl spl/sunxi-spl.bin), and the "write" and "exec" the legacy U-Boot manually. but that might fails as you seemed to have a very old legacy version
<KotCzarny>
ssvb, to boot legacy uboot.bin?
<NiteHawk>
yes, but what's the point when you have mainline working?
<ssvb>
KotCzarny: again, why would you want this? are you missing some features?
<KotCzarny>
(via fel, for testing and not swapping card, rewriting it etc)
<KotCzarny>
ssvb, right now i'm trying to unbrick my device
<NiteHawk>
NAND support?
<KotCzarny>
that too
<ssvb>
KotCzarny: which device? the bookreader?
<ssvb>
BTW, one of the reasons why I bought https://linux-sunxi.org/MSI_Primo81 was that the vendor provided a flashable image of the OS among other things
<KotCzarny>
yup
<KotCzarny>
ssvb, my dream is to have eink based linux device
<ssvb>
does the vendor provide any images for this bookreader?
<KotCzarny>
hackable linux device
mfa298_ is now known as mfa298
<KotCzarny>
ssvb, nope, just 'updates', kernel and uboot trees
<ssvb>
this sucks, it's a good reason to avoid this hardware
<KotCzarny>
of course no documentation how to build
<MoeIcenowy>
NiteHawk: for -7 I think you should do so:
<MoeIcenowy>
first verify whether the address is in DRAM
<MoeIcenowy>
if in, show an notice "If you're trying to access DRAM, please first execute a SPL to initialize DRAM"
<KotCzarny>
ssvb, know any other cheap/eink based/hackable linux device?
<MoeIcenowy>
next try sunxi-fel ver
<MoeIcenowy>
if failed also, show "The FEL stack cannot respond -- maybe it died. Please try to reset the board"
<ssvb>
KotCzarny: no idea, and I have no time to invest into investigating this
<ssvb>
KotCzarny: please provide detailed instructions about how you got it working (the opipc board, the linux kernel version and the type of linux distro running on it, etc.) and maybe submit an issue at github
<ssvb>
basically, we know that there is some final bottleneck which is not allowing to get 900 KB/s transfer speeds on some boards, but nobody was able to debug this yet
<ssvb>
we have already eliminated a number of other performance bottlenecks and this seems to be the last one
<KotCzarny>
ssvb: armbian, kernel, hum, gotta boot it
<ssvb>
just post this information as a github issue filed against sunxi-tools, providing as much details as possible
<ssvb>
you can label it as "900 KB/s FEL transfer speed on A13"
<ssvb>
and we want to know if it is possible to ensure that we can reach it in a reliable way
<KotCzarny>
kernel 3.4.112+ (from armbian, but compiled my own config)
<KotCzarny>
issue posted, let me know if you need any other data
<NiteHawk>
ssvb: i notice that code uses PLL5_CFG_REG (aka PLL_DDR_CFG_REG) instead of DRAM_CLK_REG / DRAM_CLK_GATING_REG (0x100) - is there a particular reason for that? can we be sure that it's always the same PLL for each SoC, or it that possibly up to the board (hw) designer?
<NiteHawk>
ah, after some more reading DRAM_CLK (related to CSI?) is misleading - it needs to be some dedicated "DDR" clock
<ssvb>
NiteHawk: the DRAM PLL HW register (and the "enabled" bit) is SoC specific, that's why we need to add a new field to soc_info
<ssvb>
KotCzarny: thanks, maybe I'll try to reproduce it if I manage to find a spare SD card for armbian
<KotCzarny>
you can just compile kernel and dualboot
<KotCzarny>
should i attach my .config ?
<ssvb>
nah, that's too much hassle, also I want to have the step by step reproduction instructions as simple as possible
<KotCzarny>
then it's required as i believe it's up to kernel, not the os
<ssvb>
your config will be needed if the stock armbian image does not exhibit this behavior
<KotCzarny>
and i'm not using default armbian kernel, but compiled my own from their sources
<KotCzarny>
k
<ssvb>
well, that's why I wanted the *exact* step by step instructions
<ssvb>
if we can reproduce this with the default armbian config, then it would be the best
<KotCzarny>
maybe i'll reboot this thinkpad to linux later and check there too
<ssvb>
thanks, it would be nice
<NiteHawk>
ssvb: that's okay - but a board designed cannot deliberately decide to use a different PLL, it's bound to the specific SOC. right?
<NiteHawk>
..designer
<ssvb>
yes
<rellla>
how can display output support be implemented in the status matrix in a good way? different drm-hdmi, drm-lvds ... rows?
msevwork has quit [Quit: Leaving]
IgorPec2 has quit [Ping timeout: 255 seconds]
<KotCzarny>
ssvb: 570kB/s from linux
vishnup has joined #linux-sunxi
<MoeIcenowy>
rellla: sub matrix?
<KotCzarny>
ssvb: when adding some very cheap usb1 hub between it jumped to 574kB/s
IgorPec has joined #linux-sunxi
<KotCzarny>
linux kernel 4.5.2 on this linux
vinimac has joined #linux-sunxi
<KotCzarny>
i suspect it's specific to usb host chipset
<ssvb>
we just need to verify if anything can be done via the available libusb configuration knobs to improve the situation
<KotCzarny>
similarly to some ethernet hubs acting weird with specific ethernet cards
<ssvb>
as I mentioned in the github issue, it's good that you confirmed that there does not seem to be a FEL transfer bottleneck on the A13 device side (it can go up to 900kB/s depending on the host system)
<ssvb>
either way, the USB stack implemented by the BROM on the device side is completely out of our control
<ssvb>
but if we can nudge something on the host side, then it would be great
<KotCzarny>
would be nice to test it with usb host that has chipset other than intel
<ssvb>
yeah, mine is obviously Intel too
<KotCzarny>
and maybe good usb hub, who knows
reinforce has joined #linux-sunxi
<rellla>
MoeIcenowy: to be filled ...
IgorPec has quit [Ping timeout: 255 seconds]
kaspter has quit [Ping timeout: 256 seconds]
leon-anavi has quit [Quit: Leaving]
<KotCzarny>
funny that compiled binaries show ver 1.4.2 and git compiled one 1.4.1
<NiteHawk>
huh? you mean "git describe --tags --always" doesn't produce something based on 1.4.2 for you?
fkluknav has quit [Ping timeout: 258 seconds]
<KotCzarny>
nope, i mean running sunxi-fel
<KotCzarny>
it's in the first line
<KotCzarny>
this is for the binary compiled just now: sunxi-fel v1.4.1-25-g93a26d5
<KotCzarny>
and this is in windows binary: sunxi-fel v1.4.2 632925d
<KotCzarny>
maybe i've git cloned weirdly
<KotCzarny>
though it includes your -h change at least, so should be latest
<NiteHawk>
93a26d5 dates back to November 2016
<NiteHawk>
did you limit the clone depth?
<KotCzarny>
maybe, i have this directory laying around and just git pull'ing sometimes
wzyy2 has joined #linux-sunxi
<vinimac>
mripard: The Mark Brown's recommendation seems very much complex than a simple dts property, am I right?
<KotCzarny>
nitehawk: cloned it again, sunxi-fel v1.4.2-45-g7128c73
fkluknav has joined #linux-sunxi
<KotCzarny>
sources compile same sizes in both cases, only version differs, funky
<NiteHawk>
i just recalled that an existing version.h might now get overwritten on every compile - might explain it. the auto-versioning is mainly thought for automated builds, e.g. the CI ones
<NiteHawk>
s/might now/might not/
<NiteHawk>
(it will work correctly if you force a full rebuild with "make -B")
vinimac has quit [Quit: Saindo]
vinimac has joined #linux-sunxi
IgorPec has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
<KotCzarny>
oh wow, someone transposed status matrix
jernej has joined #linux-sunxi
<KotCzarny>
on the plus side now it fits horizontally ;)
terra854 has quit [Quit: Connection closed for inactivity]
Mr__Anderson has quit [Remote host closed the connection]
<MoeIcenowy>
ssvb: usually for tablets it's not really suspended
<BenG83>
and the BSP source drop that came with it
<MoeIcenowy>
they only enters a mode that many peripherals is temporarily disabled
<ssvb>
MoeIcenowy: are you sure about this?
<MoeIcenowy>
ssvb: at least when it's connected to PC, it's true
<jernej>
does anybody know what SDM bit in PLL registers do?
<MoeIcenowy>
jernej: which PLL?
<ssvb>
MoeIcenowy: A20 implements suspend without OpenRISC, but the whole SoC gets powered down and the wake up is handled as a new boot
<jelle>
ohh interesting
<jernej>
I think every H3 PLL register has this bit
<jernej>
MoeIcenowy: PLL_DE, for example
<ssvb>
MoeIcenowy: only a few HW registers are battery backed and retain state, they are used to store the "super-suspend flag" which tells the bootloader to bring DRAM back from self-refresh rather than doing full init
<MoeIcenowy>
jernej: oh I found it, but I really do not know it...
<ssvb>
MoeIcenowy: after my A20 tablet suspends in Android, I can insert an SD card with the mainline U-Boot, and when Android is supposed to "wake up" the mainline U-Boot gets booted instead :-)
<rellla>
Ixnus: thanks. N/A for H3 display is really right? wasn't aware of that...
<MoeIcenowy>
ssvb: oh...
<jernej>
MoeIcenowy: BTW, I didn't have any troubles with enabling DE2 on A83T
<ssvb>
MoeIcenowy: that's how the stuff works without a dedicated OpenRISC core
<KotCzarny>
ssvb: that's becauyse its implemented in uboot
<KotCzarny>
(resume)
<jernej>
rellla: H3 has only cvbs and hdmi
<rellla>
oh :)
<jernej>
rellla: as H5, because they are set top box series
<jelle>
ssvb: so then you only have to fiddle in u-boot to get a h3 to suspend
<jernej>
rellla: A series doesn't have CVBS for example
<MoeIcenowy>
for H3 one can never re-power up the SoC if it's halted withoue AR100 enabled
<ssvb>
jelle: H3 has an OpenRISC core, and this core is supposed to be awake during suspend
<KotCzarny>
also, h3 doesnt have battery backup ;)
<jelle>
oh yeah lol ;-)
<MoeIcenowy>
I think first we should implement ARISC to listen to IR & some r_gpio_keys ;-)
<ssvb>
jelle: when the wake up button is pressed (that's just an ordinary GPIO button on the port L), the OpenRISC core is supposed to start the ARM cores again
<MoeIcenowy>
ssvb: y
<jelle>
MoeIcenowy: that would be neat. I want to have that for when I poweroff
<rellla>
plaes: for the alignment i thought we have at least more features than socs :)
<MoeIcenowy>
but I cannot do OpenRISC assembly...
<jelle>
MoeIcenowy: I looked into making the h3 poweroff completely too since now it still draws power
<jelle>
MoeIcenowy: your smart enough though :)
<beeble>
MoeIcenowy: there is a compiler :)
<MoeIcenowy>
beeble: it's difficult to port a or1k-gcc to a specified machine
<beeble>
MoeIcenowy: on a31 we had or1k stuff running. with a shell and all the fancy stuff
<ssvb>
it does not make any sense to use glibc for OpenRISC without MMU
<KotCzarny>
beeble: legacy kernel panics on papyrus powerup, it's all about missing device on i2c
<MoeIcenowy>
P.S. for A64 apritzel choose to let ATF occupy the space of ARISC firmware in mainline solution
florianH has quit [Quit: Connection closed for inactivity]
<KotCzarny>
MoeIcenowy: that's not nice
<KotCzarny>
;)
<ssvb>
MoeIcenowy: this is not set in stone
<ssvb>
also there might be enough space for both ATF and ARISC firmware in SRAM A2
<ssvb>
apritzel also considered an option of loading the ATF into SRAM A1 some time ago
<MoeIcenowy>
A2 is the best choice when there's no arisc
<ssvb>
or the ATF can be moved back to the DRAM, just like it is done by Allwinner
<MoeIcenowy>
and for A64 arisc is not so critical
<ssvb>
yeah, assuming that you can implement a decent suspend support without it
<KotCzarny>
ssvb, powering down whole soc is a nice feature
<KotCzarny>
well, almost whole soc
<MoeIcenowy>
jernej: so A64 is the only SoC that mysteriously cannot have DE2 to work?
<jernej>
MoeIcenowy: yes, from what I can tell
<beeble>
KotCzarny: so from the software point of view i can't think of anythign anymore. i would use a scope for more :)
<MoeIcenowy>
P.S. I also easily got V3s DE2 to work
Mr__Anderson has joined #linux-sunxi
<ssvb>
jernej: but you can get DE2 to work on A64 if you boot with boot0, or I misunderstood something?
<MoeIcenowy>
so we got A83T, V3s, H3, H5 to work, only not working SoC is A64
<KotCzarny>
beeble: thanks for the help though, i still havent tried cutting battery wires
<KotCzarny>
pin25 trick didnt help
<jernej>
MoeIcenowy: DE2 works with BSP U-Boot, I have to try uboot0 + mainline combination
<MoeIcenowy>
or maybe there's some hidden code in arisc?
<ssvb>
jernej: well, this means that it *can* work in principle, there are just some missing configuration knobs
<jernej>
MoeIcenowy: I considered that too, but it is tedious to go through assembly
<jernej>
ssvb: I know, but I tried almost everything I can think of
<KotCzarny>
jernej: have you tried asking aw?
<beeble>
KotCzarny: maybe you connected not correctly. qfn packages can be hard to connect due the only very small exposed pin. and if you didn't get through the oxidlayer of the solder joint nothing would happen
<jernej>
KotCzarny: I just put that question on MoeIcenowy list of questions for Allwinner
<KotCzarny>
beeble: device was working initially, update failed, then it wasnt booting anymore (due to papyrus panic)
jstein_ has joined #linux-sunxi
jstein_ has quit [Remote host closed the connection]
<beeble>
KotCzarny: i was talking about pin 25
<MoeIcenowy>
jernej: you clocked up DE2 with PLL_DE on A83T, right?
<jernej>
MoeIcenowy: yes
<MoeIcenowy>
maybe I should have a deadline for the wiki page, then pack the problems up and send them...
<KotCzarny>
beeble: not that hard because its one of the side pins
<jernej>
MoeIcenowy: there is no CCU DE register (0x104)
<MoeIcenowy>
ah-oh
<jernej>
it is not needed aparently
<jernej>
it is funny how much variations could be there for basically same functionality
<MoeIcenowy>
oh there's really CCU DE register...
<MoeIcenowy>
but in CCU_SCLK chapter
<MoeIcenowy>
oh... I opened the file of A80
* MoeIcenowy
get too silly
<MoeIcenowy>
yes there's really no CCU_DE register
<KotCzarny>
could you guys sniff what bsp is doing?
<KotCzarny>
(and girls)
<jernej>
we're trying but the secret is heavily protected :)
<MoeIcenowy>
I didn't find any code with suspicion in lowlevel_sun50iw1/ of DE2 code
<KotCzarny>
i mean, is it possible to see what clocks are used and where?
<KotCzarny>
on a running system
<jernej>
KotCzarny: I copied clock values from working image, but it didn't work
<MoeIcenowy>
so did I
gk-1wm-su has joined #linux-sunxi
f0xx has quit [Ping timeout: 240 seconds]
<KotCzarny>
magic initializations ahoy!
komunista has quit [Quit: Leaving.]
gk-1wm-su has quit [Client Quit]
IgorPec5 has joined #linux-sunxi
quinward has joined #linux-sunxi
IgorPec5 has quit [Ping timeout: 245 seconds]
cobra_koral has quit [Ping timeout: 255 seconds]
cobra_koral has joined #linux-sunxi
cobra_koral has quit [Ping timeout: 255 seconds]
wzyy2 has quit [Remote host closed the connection]
Ixnus has quit [Quit: Page closed]
quinward has quit [Quit: WeeChat 1.5]
chomwitt has joined #linux-sunxi
Ntemis has quit [Remote host closed the connection]
<plaes>
KotCzarny: got it working?
<KotCzarny>
nah, just commenting on moeicenowy and jernej's adventures
apritzel has joined #linux-sunxi
<apritzel>
re A64 ATF load address> SRAM A2 seems like an easy choice, because it's secure(*) by default and not used atm
mossroy has quit [Quit: Leaving]
utente has joined #linux-sunxi
<apritzel>
but as ssvb said: nothing is set in stone, it's just load addresses in some config file
<apritzel>
and I indeed I was playing with the idea of moving it into SRAM A1
lemonzest has quit [Quit: Leaving]
<apritzel>
MoeIcenowy: and having a bare metal tool chain to compile some low level code for OR1K is easy, I think I had a hello world running already some months ago
|Jeroen| has quit [Quit: dada]
<beeble>
apritzel: we also did some clocking and power stuff already. just to see how low we can get in terms of consumption
<apritzel>
beeble: running the arisc from LOSC (32KHz)?
<beeble>
yes
<KotCzarny>
isnt kilo shorthand lowercase k ?
<beeble>
but since all the wakeup code was not done (yet) it wasn't that useful
<beeble>
KotCzarny: yes
<beeble>
running at 32khz is pretty painful btw :)
<beeble>
keystroke to echo takes seconds
<KotCzarny>
o.O
<beeble>
funny sidesnote btw. rockchip has two cortex m0 instead of a arisc. even naming one dedicated pmumcu but the only code running on it is about 3 lines of c code as a workaround for a siliconbug at warm reset
<apritzel>
lol
<apritzel>
beeble: in the 3399?
<beeble>
apritzel: should tell that you bosses as a way to sell more core licenses :)
<apritzel>
beeble: do you think that's an accident? ;-)
<beeble>
apritzel: yes. can look the source up if you are interested when i'm off mobile again
<apritzel>
the M class outsells A class by a large margin anyway ...
<beeble>
understandable
<beeble>
dirt cheap nowdays, great toolchains and versatilebas hell
<apritzel>
beeble: do you use GCC or the ARM compiler?
<beeble>
did a lot of m3 projects in the past and even nowdays we just put one ore more m0/3 as compananions next to a cortex-a
<beeble>
gcc
<beeble>
we only use keil if we have legacy code that we can't touch (or are not paid) to make it compile with gcc
<apritzel>
thought so ...
<BenG83>
most new projects I do use gcc now
<BenG83>
but we used Keil4/5 for almost 10 years
<beeble>
and we only see it from the big companies and source drops fron the cpu vendors
<beeble>
bcm seems still like to stick with keil for whatever reason
<BenG83>
just started a new project using Freescale/NXP Kinetis K81
vinimac has quit [Quit: Leaving]
<beeble>
BenG83: any special reason for chosing kinetis?
<BenG83>
and probabl i.MX6
<BenG83>
yes security features
<BenG83>
it's for an applications involving smartcards
<BenG83>
tamper pins
<BenG83>
and other things
<beeble>
hmm doing that with st
<BenG83>
i.MX6UL has also DryICE
<BenG83>
we are doing one low end design with K81 and one with the i.MX6
<BenG83>
running Linux
<beeble>
does kinetis has finaly usarts?
<BenG83>
no
<KotCzarny>
maybe those running pure asm are those ran by old timers?
<BenG83>
at least not the K81
<beeble>
thats ine if the reasons we always stick to stm32
<BenG83>
I personally prefer LPCxxx
<BenG83>
I worked for Atmel a couple years then went back to research
<BenG83>
now working on industrial projects
<beeble>
there you get up to 3 usarts and we build smartcard readers for three cards with it
<BenG83>
we heavily used LPC2148/2368 with ARM7
<BenG83>
then the compatible CortexM when they came out
<BenG83>
now we use whatever the customer wants :)
<apritzel>
usart as in one peripheral can do I2C, SPI and UART?
<beeble>
apritzel: no, uart with clock
<beeble>
needed if you want to talk iso7816 directly
vinimac has joined #linux-sunxi
<BenG83>
the K81 has dedicated smartcard interfaces
<beeble>
"needed" you could always bitbang :)
<beeble>
ah, ic. should lookup the datasheet how flexible that block is
<BenG83>
we bitbang smartcard sometimes
<BenG83>
but mostly for applications that have soldered internal ones
<BenG83>
where you can tune stuff for the certification
reinforce has quit [Quit: Leaving.]
<beeble>
our allwinner modules do have jcop cards solderd on
<BenG83>
I have one prototyping project where we maybe use SOPine :)
cptG_ has joined #linux-sunxi
<beeble>
makes me sad :)
<beeble>
no, whatever fits your application
<BenG83>
we do mostly automotive or medical applications
<beeble>
we do have automotive components options if you can overlook the allwinner issue :)
<beeble>
but yeah. for that kindnof stuff i use imx6 as well
<beeble>
mostly
* apritzel
shivers when thinking off an A64 in a medical application ;-)
<BenG83>
so far we used mostl i.MX6
<BenG83>
medical applications is mostly Cortex-M stuff
<BenG83>
:)
* apritzel
decides to not get sick
<BenG83>
one project uses Xilinx Zynq
<BenG83>
for a tracking system
cptG has quit [Ping timeout: 255 seconds]
<beeble>
apritzel: the only difference is that you get the errata sheet from freescale/nxp the content doesn't look better :)
<BenG83>
^
victhor has joined #linux-sunxi
<beeble>
i will always remember the ine where freescale mixed up the endiness in ther emac block
<beeble>
therefore you had to reverse every received byte in the alu
<apritzel>
beeble: that's why it's called network byte order ;-)
<beeble>
another funny thing was the imx6 manual that told you to change a setting you should change a variable in the source
<beeble>
abd below was vhdl printed
<beeble>
of the soc
freemangordon has quit [Read error: No route to host]
IgorPec has quit [Ping timeout: 276 seconds]
Mr__Anderson has quit [Remote host closed the connection]