Turl changed the topic of #linux-sunxi to: Allwinner/sunxi /development discussion - did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait! - https://github.com/linux-sunxi/ - Logs at http://irclog.whitequark.org/linux-sunxi
msev- has joined #linux-sunxi
<MoeIcenowy> jernej: I didn't consider cropping or scaling now.
Mr__Anderson has quit [Quit: Leaving.]
<apritzel> MoeIcenowy: BenG83_PB: btw: I see those kernel crashes on my Pine64 as well, so it's not PB related
mzki has quit [Ping timeout: 240 seconds]
<MoeIcenowy> apritzel: try to lower DRAM frequency
wzyy2 has joined #linux-sunxi
<MoeIcenowy> 672 is a very high value.
BenG83_PB has left #linux-sunxi ["Leaving"]
BenG83_PB has joined #linux-sunxi
<BenG83_PB> lowering the DRAM clock frequency fixed the issue on my PB
<MoeIcenowy> BenG83_PB: excuse me, what's the relation between you and Xalius at #Pine64?
<BenG83_PB> we are the same person ;)
<MoeIcenowy> oh sorry
<BenG83_PB> I just have this nick on freenode
<apritzel> MoeIcenowy: actually 672 is quite conservative, given that the chips can do 800 MHz
<apritzel> MoeIcenowy: but I guess the parameters copied from Allwinner are just broken
<apritzel> and also I run with this value (and the SPL code) for months now and have never had any issues
<apritzel> I updated the kernel to 4.10 plus MMC/USB support from -next, though
<MoeIcenowy> P.S. for me there's a oops when booting with -next
<MoeIcenowy> but it's not crash
<ssvb> apritzel: not really, reliability is not limited by the DRAM chips, but by the DRAM controller and the impedance/length matching of the PCB traces between the SoC and the DRAM chips
<ssvb> apritzel: you can find some details here - https://linux-sunxi.org/A10_DRAM_Controller_Calibration
<apritzel> ssvb: I know all this, but I guess it's the old story again: Allwinner's values are just weird
<MoeIcenowy> consider "\n\tdefault 312 if MACH_SUN6I || MACH_SUN8I\n\tdefault 360 if MACH_SUN4I || MACH_SUN5I || MACH_SUN7I"
<MoeIcenowy> 672 is a very high number
<apritzel> MoeIcenowy: no, it's a different DRAM controller
<MoeIcenowy> one time higher than the default value of sun8i
<MoeIcenowy> apritzel: from sun8i on the DRAM controller didn't change a lot
<apritzel> MoeIcenowy: the values you cited are from older SoCs
<MoeIcenowy> 360 is even higher than 312 ;-)
<ssvb> apritzel: it's not easy to find better parameters, and there is no guarantee that they will help
<apritzel> ssvb: the guys from Theobroma had quite some success with this, though
<ssvb> success with what?
<apritzel> but again: I saw this crash yesterday for the first time and run with this DRAM setup for months now
<apritzel> ssvb: running with sane JEDEC parameters and at 800 MHz
<ssvb> JEDEC parameters were never a reliability issue
<ssvb> you can optimize the performance by using tighter timings, but that's it
<apritzel> ssvb: but Allwinner's setup deviates from the JEDEC defaults for the given frequency / cache latency pair
<apritzel> I think this has been discussed in lengths before here
<lurchi_> apritzel: CAS latency?
<apritzel> urgh, of course
<ssvb> it does not deviate much, more like they are using DDR3-1333 timings but are actually clocking the DRAM much lower than that
<ssvb> or was there a case of clear timings violation?
<ssvb> apritzel: btw, please also check this - http://lists.denx.de/pipermail/u-boot/2016-April/250397.html
<lurchi_> its completely fine to "violate" timings in terms of cycles, as long as timings in terms of realtime are obeyed
interrobangd has joined #linux-sunxi
<MoeIcenowy> apritzel: is this bug able to reproduce?
vagrantc has quit [Quit: leaving]
<apritzel> MoeIcenowy: yes, easily. I can try to use my older kernel to narrow it down to the kernel
<MoeIcenowy> always at the same position?
<BenG83_PB> my crashes were pretty deterministic
<MoeIcenowy> BenG83: yes, I think it mysterious
<BenG83_PB> e.g. always triggered by the same command
<MoeIcenowy> but I must admit for PB I go beyond the stock DRAM settings too lot
<MoeIcenowy> It's not strange for your PB to have problem
<MoeIcenowy> it's strange for my PB not to have problem
<MoeIcenowy> P.S. I think the ISDT memory chips used on my PB is just some rename of Hynix
<BenG83_PB> yeah but then I am with apritzel that 552Mhz is a bit low for those chips
<BenG83_PB> not sure if I can find a spot to do some signal quality measurements
<MoeIcenowy> "ssvb: apritzel: not really, reliability is not limited by the DRAM chips, but by the DRAM controller and the impedance/length matching of the PCB traces between the SoC and the DRAM chips"
<BenG83_PB> yeah but I hope they didnt screw up the layout
<MoeIcenowy> P.S. I heard that the design of PB that uses DDR3 will never exist in really produced version of PBs
<BenG83_PB> yeah I was about to say
<MoeIcenowy> and for LPDDR3 we may have different story
<BenG83_PB> for the PB it is a bit moot to discuss because we get new DRAM
<BenG83_PB> but the PCBs usually get impedance tested before the first chips go on the board
<BenG83_PB> not all pairs of course
<MoeIcenowy> and I think even after chips are soldered the PCB still receives many tests
<MoeIcenowy> I have seen some early board of the new revision PB PCB in ChipHD company
<MoeIcenowy> but they said that some tests failed and reworks are needed
<BenG83_PB> I could unsolder the A64 and measure impedance
<BenG83_PB> we got a new network analyzer at work ;)
<BenG83_PB> but it
<BenG83_PB> is hard to measure because the dram input buffers have to be biased
<BenG83_PB> usually only done for dram modules
<ssvb> BenG83_PB: the trick is that the driver and termination impedance is configured by software, that's what the ZQ settings are for
<ssvb> the delays also can be compensated
<BenG83_PB> yeah for a certain range
<MoeIcenowy> apritzel: P.S. I think TL Lim mentioned for RTL8211E's Gbit failure problem he mentioned some fix, have you heard it?
<BenG83_PB> I hope at least the length are matched properly ;)
<apritzel> MoeIcenowy: yes, let me find a link
<BenG83_PB> GbE has been fixed quite some time ago, with some magic bits from Realtek
<ssvb> BenG83_PB: sure, the DRAM controller can't compensate really major problems in the PCB routing, but some fine tuning is still possible
tsuggs has quit [Ping timeout: 255 seconds]
<apritzel> BenG83_PB: you mean "fixed" as in some dodgy hacks in the even more dodgy BSP kernels?
<MoeIcenowy> apritzel: P.S. according to TL it's not the issue of Allwinner or A64
<MoeIcenowy> but the problem of a batch of Realtek PHY that have been bought by them
<apritzel> MoeIcenowy: no, it's an issue with the board design, if I got this correctly
<ssvb> BenG83_PB: the https://linux-sunxi.org/A10_DRAM_Controller_Calibration#Finding_optimal_DRAM_settings_for_your_board_or_device page explains how to find better settings via bruteforce (for the A10/A13/A20 DRAM controller)
<BenG83_PB> the Realtek engineer did some undocumented delay tuning
<MoeIcenowy> apritzel: it's a multiple source problem
<apritzel> MoeIcenowy: probably
<apritzel> but the proposed hack is of the usual "vendor code" quality
<MoeIcenowy> 1. A batch of chips have some problem 2. The problem have some workaround, which is used by the test env of RTL, but not used by product boards 3. There's also a software workaround for it
<apritzel> #ifdef CONFIG_ARCH_SUN50IW1P1 and stuff, you know ;-)
<apritzel> but it seems that only some Pine64 boards were affected
<MoeIcenowy> TL said he did an experiment with AW and RTL engineers: switch a RTL8211E from a broken Pine64 to some Banana Pi, and the Banana Pi then fails, and the Pine64 get recovered
<BenG83_PB> I first thought they maybe got a batch of fake PHYs
<BenG83_PB> that got into production
<MoeIcenowy> according to TL this problem may be because of an earthquake happened at Taiwan
<MoeIcenowy> which has reduced the product ability of RTL and made them loose the test standard
<apritzel> so is it a faulty PHY chip problem then? I was under the impression that it was a Pine64 board design issue
<MoeIcenowy> according to TL it's a faulty PHY problem
<BenG83_PB> the board layouts looked ok to me, I had the gerbers to look at at some point
<apritzel> MoeIcenowy: that's what I (as the board designer) would say as well ;-)
<MoeIcenowy> I think the reason the code is covered by #ifdef CONFIG_ARCH_SUN50IW1P1 is that the solution of the broken PHY, both hardware or software, is a hack rather than a normal solution
<MoeIcenowy> P.S. people who have abillity to re-solder PHY, and have a good board and a broken board both uses RTL8211E, can replay this PHY switch experiement ;-)
<BenG83_PB> my boards all worked before the fix
<BenG83_PB> I got one board that was supposedly not working from another user
<BenG83_PB> but that worked for me too
<BenG83_PB> probably because there were multiple different issues at once
r1mikey has joined #linux-sunxi
<apritzel> MoeIcenowy: if there is a need for an #ifdef, it should be FAULTY_REALTEK_PHY or the like, and not tied to some SoC
<MoeIcenowy> agree ;-)
<apritzel> MoeIcenowy: but actually it should be a DT property
<MoeIcenowy> can PHY get its device tree node in driver code?
<BenG83_PB> I was just about to ask if you could enable a workaround in the dts entry
<MoeIcenowy> but this will means that we should have a dt compatible for rtl8211e
<dan0_0> Hey, so does the integrated 100Mbps NIC on the H3 SOC require any non-free firmware?
chomwitt has quit [Ping timeout: 260 seconds]
r1mikey has quit [Ping timeout: 255 seconds]
<apritzel> MoeIcenowy: apparently they use PHY IDs in the code: drivers/net/phy/realtek.c, line 154
interrobangd has quit [Read error: Connection reset by peer]
<MoeIcenowy> dan0_0: no
<MoeIcenowy> usually ethernet PHYs do not use firmware ;-)
<MoeIcenowy> and MACs are also not complex enough to have firmware ;-)
<apritzel> so upon detecting one of those PHYs, we could walk up struct phy_device -> struct mdio_device -> struct device -> of_node to check for the property
<apritzel> since it's a PHY "bug", that should be done in realtek.c, possibly protected by a quirk ifdef
<dan0_0> Hmm, if I run a gigabit H3 board without the realtek firmware, will I lose ethernet?
<MoeIcenowy> dan0_0: won't
<MoeIcenowy> there's no suitable interface to upload any firmware to ethernet PHY ;-)
<apritzel> dan0_0: are you talking about wireless Realtek, by any chance?
<apritzel> dan0_0: as MoeIcenowy said: there is no firmware in those RT PHYs
<MoeIcenowy> for wireless rtl cards the only card that is known by me to be blobless is rtl8187l
<dan0_0> Yeah, but on a Orangepi+ 2e isn't the RTL8211E chip doing gigabit and wired to the ethernet port instead of the integrated PHY? And doesn't the RTL8211E need non-free firmware?
<MoeIcenowy> but it's only a B/G card
<MoeIcenowy> dan0_0: rtl8211e do not need firmware
<MoeIcenowy> I can promise
<dan0_0> Ah
jstein has quit [Remote host closed the connection]
popolon has quit [Quit: WeeChat 1.4]
<dan0_0> So just the RTL8189FTV requires non-free firmware and the Mali GPU requires a non-free driver & kernel mods to get meh OpenGL ES support, right?
<dan0_0> that is the extent of the non-free software needs to get an Orangepi+ 2e's hardware fully functional?
* dan0_0 doesn't need or use Mali
chlorine has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
egbert has quit [Ping timeout: 240 seconds]
chlorine has quit [Ping timeout: 240 seconds]
egbert has joined #linux-sunxi
apritzel has quit [Quit: Leaving.]
<juri_> Just purchased and verified an A33 in the Azpen A746G
<juri_> $30.
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 240 seconds]
sgteem_ has joined #linux-sunxi
sgteem has quit [Ping timeout: 240 seconds]
ninolein has joined #linux-sunxi
ninolein_ has quit [Ping timeout: 260 seconds]
<wens> plaes: the sunxi-ccu base code has various holes, or unimplemented features
Andy-D has quit [Ping timeout: 264 seconds]
<wens> plaes: if you're asking, then it's probably not implemented, in which case you can add it if you need it
<dan0_0> MoeIcenowy: prod
<wens> ask away
lurchi_ is now known as lurchi__
r1mikey has joined #linux-sunxi
<wens> MoeIcenowy: i updated my u-boot r40 branch in case you want to test, it has untested PSCI support
<wens> i will test it on wednesday
lkcl has joined #linux-sunxi
r1mikey has quit [Ping timeout: 255 seconds]
chlorine has joined #linux-sunxi
chlorine has quit [Ping timeout: 240 seconds]
lkcl has quit [Ping timeout: 240 seconds]
lkcl has joined #linux-sunxi
tlwoerner has joined #linux-sunxi
tlwoerner has quit [Changing host]
tlwoerner has joined #linux-sunxi
pg12 has quit [Ping timeout: 260 seconds]
pg12 has joined #linux-sunxi
noob has joined #linux-sunxi
<noob> please point me to an example in mainline support for I2C recording
noob has quit [Ping timeout: 260 seconds]
noob has joined #linux-sunxi
f0xx has joined #linux-sunxi
chlorine has joined #linux-sunxi
ErwinH has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
ErwinH has quit [Ping timeout: 240 seconds]
ErwinH has joined #linux-sunxi
IgorPec has joined #linux-sunxi
ErwinH has quit [Ping timeout: 255 seconds]
r1mikey has joined #linux-sunxi
ErwinH has joined #linux-sunxi
walkiry has quit [Quit: Goodbye]
r1mikey has quit [Ping timeout: 255 seconds]
ErwinH has quit [Ping timeout: 240 seconds]
TheSeven has quit [Ping timeout: 255 seconds]
TheSeven has joined #linux-sunxi
lurchi_ has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 260 seconds]
ErwinH has joined #linux-sunxi
vishnup has quit [Ping timeout: 260 seconds]
ErwinH has quit [Ping timeout: 268 seconds]
LargePrime has quit [Ping timeout: 255 seconds]
reinforce has joined #linux-sunxi
chlorine has quit [Remote host closed the connection]
<plaes> noob: could you i2c recording?
LargePrime has joined #linux-sunxi
IgorPec has quit [Ping timeout: 240 seconds]
leio has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
f0xx has quit [Ping timeout: 268 seconds]
<plaes> noob: could you explain what do you mean by i2c recording?
<noob> plaes: i want to use external codec for recording
<noob> through i2s
chlorine has joined #linux-sunxi
<KotCzarny> quote: It's quite astounding that all of these tools can search for patterns in the entire linux kernel (~640MB of data spread across ~55k files) in under a second!
leviathan_ has quit [Remote host closed the connection]
JohnDoe_71Rus has joined #linux-sunxi
<mripard> MoeIcenowy: no, this is a hack.
<KotCzarny> nitehawk, ssvb: how do i checkout that specific branch/change/
Gerwin_J has joined #linux-sunxi
IgorPec has joined #linux-sunxi
engideavr has joined #linux-sunxi
r1mikey has joined #linux-sunxi
r1mikey has quit [Remote host closed the connection]
r1mikey has joined #linux-sunxi
chlorine has quit [Remote host closed the connection]
Gerwin_J has quit [Quit: Gerwin_J]
ErwinH has joined #linux-sunxi
r1mikey has quit [Remote host closed the connection]
r1mikey has joined #linux-sunxi
<Putti> is something like https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/sun6i-a31s-primo81.dts required for simplefb to work on a33 with u-boot or should it work out of the box if simplefb has been enabled in .config?
r1mikey_ has joined #linux-sunxi
r1mikey has quit [Ping timeout: 240 seconds]
codekipper has joined #linux-sunxi
<codekipper> noob: http://lxr.free-electrons.com/source/arch/arm/boot/dts/sun5i-gr8-evb.dts#L79 is an example of a sunxi device using i2s for recording.
orly_owl_ has joined #linux-sunxi
noob has quit [Ping timeout: 260 seconds]
orly_owl has quit [Ping timeout: 260 seconds]
orly_owl_ is now known as orly_owl
orly_owl has quit [Changing host]
orly_owl has joined #linux-sunxi
<Putti> MoeIcenowy, hi, I searched through some old IRC logs (from 2016), and I saw you were having similar problems with Q8 a33 tablet: kernel's simplefb not working but display working on u-boot. Did you find solution to the problem? What was it?
<Putti> The tablet I use hangs in "Starting kernel ..." message, so simplefb not working could be one cause in my case.
massi has joined #linux-sunxi
paulk-blaze has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
f0xx has joined #linux-sunxi
orly_owl has quit [Ping timeout: 252 seconds]
Gerwin_J has joined #linux-sunxi
KotCzarny has quit [Ping timeout: 268 seconds]
Mr__Anderson has joined #linux-sunxi
chlorine has joined #linux-sunxi
Putti has quit [Ping timeout: 240 seconds]
Gerwin_J has quit [Quit: Gerwin_J]
KotCzarny has joined #linux-sunxi
chlorine has quit [Remote host closed the connection]
chlorine has joined #linux-sunxi
cnxsoft has quit [Read error: Connection reset by peer]
Leepty has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
yann has quit [Ping timeout: 255 seconds]
r1mikey_ has quit [Ping timeout: 255 seconds]
florianH has joined #linux-sunxi
Putti has joined #linux-sunxi
Andy-D has joined #linux-sunxi
Putti has quit [Remote host closed the connection]
LargePrime has quit [Ping timeout: 240 seconds]
leviathan has joined #linux-sunxi
chlorine has quit [Remote host closed the connection]
enrico__ has joined #linux-sunxi
chlorine has joined #linux-sunxi
Putti has joined #linux-sunxi
BenG83 has joined #linux-sunxi
LargePrime has joined #linux-sunxi
chlorine has quit [Remote host closed the connection]
chlorine has joined #linux-sunxi
chlorine has quit [Remote host closed the connection]
chlorine_ has joined #linux-sunxi
Andy-D has quit [Ping timeout: 240 seconds]
reinforce has quit [Quit: Leaving.]
reinforce has joined #linux-sunxi
chlorine_ has quit []
r1mikey has joined #linux-sunxi
reinforce has quit [Client Quit]
reinforce has joined #linux-sunxi
yann has joined #linux-sunxi
orly_owl has joined #linux-sunxi
lkcl has quit [Ping timeout: 240 seconds]
reinforce has quit [Quit: Leaving.]
<MoeIcenowy> Putti: have you enabled simplefb in kernel?
reinforce has joined #linux-sunxi
<MoeIcenowy> mripad: is there a non-hacky way to use mali on sun4i-drm?
<Putti> MoeIcenowy, yes, it comes with the sunxi_defconfig which I am using
<MoeIcenowy> Putti: when I met the problem I'm using 3.4 kernel ;-)
<MoeIcenowy> not simplefb.
<MoeIcenowy> please check whether your kernel is correctly booted
<Putti> ah ok.
<Putti> I can't check anyhow because I don't have serial console?
<MoeIcenowy> try to use zImage
<MoeIcenowy> for mainline zImage is more easy to use than uImage
<Putti> I use zImage
mzki has joined #linux-sunxi
<Putti> MoeIcenowy, this is my boot.cmd: http://paste2.org/3sXPbBAw. Looks ok?
<Putti> bootargs is the thing I'm bit unsure about
reinforce has quit [Client Quit]
<MoeIcenowy> looks ok...
paulk-blaze has quit [Remote host closed the connection]
reinforce has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
<Net147> MoeIcenowy: using mali on X11 or fbdev?
<MoeIcenowy> Net147: of course X11
<mripard> MoeIcenowy: with fbdev yes
<mripard> with X11, ION, probably
<mripard> but I haven't had time to look into this yet
<MoeIcenowy> ION?!
<MoeIcenowy> Does xf86-video-armsoc support ION?
<Putti> Any ideas on how to see if kernel has booted without serial console?
<MoeIcenowy> why cannot drm driver directly allocate GEM buf for mali?
<MoeIcenowy> even if it's a hack, we can make it at a dedicated header and standardize it as part of sun4i-drm driver
<MoeIcenowy> for example, make a include/drm/sun4i_drm.h which contains necessary ioctls for this hack
<mripard> because then you would allocate a GBM for the display engine
<mripard> and you have no guarantee that the GPU can access it
<mripard> => a hack
<Net147> wayland perhaps...?
<MoeIcenowy> why is there no guarantee that the GPU can access it?
<mripard> MoeIcenowy: because it was allocated for the display engine's device
<mripard> and not the GPU
<MoeIcenowy> P.S. mripard: will you care if I make a commit remove all underscores in node name of sunxi DTS's?
<mripard> I don't really mind, but why do you want to do that ?
<MoeIcenowy> According to some mails referred by Rask Ingemann Lambertsen, it's obsolute
chomwitt has joined #linux-sunxi
<MoeIcenowy> these two mails are from Rob Herring
dave0x6d has quit [Quit: Connection closed for inactivity]
<MoeIcenowy> and using GPIO_ACTIVE_HIGH for mmc's cd-gpio then use cd-inverted is also not suggested now
<MoeIcenowy> as the MMC specification do specify that card detect signal is active-low
orly_owl has quit [Ping timeout: 260 seconds]
robogoat has quit [Ping timeout: 260 seconds]
wzyy2 has quit [Ping timeout: 240 seconds]
lkcl has joined #linux-sunxi
r1mikey has quit [Remote host closed the connection]
IgorPec2 has joined #linux-sunxi
IgorPec has quit [Ping timeout: 260 seconds]
<MoeIcenowy> wens: some Chinese answers are pasted to http://linux-sunxi.org/User:Icenowy/Problems_to_Allwinner
r1mikey has joined #linux-sunxi
aballier has quit [Ping timeout: 260 seconds]
chlorine has joined #linux-sunxi
<MoeIcenowy> translated
fkluknav has joined #linux-sunxi
muvlon has joined #linux-sunxi
chlorine has quit [Remote host closed the connection]
chlorine has joined #linux-sunxi
orly_owl has joined #linux-sunxi
orly_owl has joined #linux-sunxi
orly_owl has quit [Changing host]
r1mikey has quit [Remote host closed the connection]
jkarlson has joined #linux-sunxi
BenG83 has quit [Ping timeout: 255 seconds]
lkcl has quit [Ping timeout: 268 seconds]
wzyy2 has joined #linux-sunxi
wzyy2 has quit [Read error: Connection reset by peer]
r1mikey has joined #linux-sunxi
chlorine has quit [Remote host closed the connection]
IgorPec has joined #linux-sunxi
IgorPec2 has quit [Ping timeout: 240 seconds]
chlorine has joined #linux-sunxi
Ke has quit [Quit: leaving]
jkarlson is now known as Ke
popolon has joined #linux-sunxi
BenG83 has joined #linux-sunxi
aballier has joined #linux-sunxi
wzyy2 has joined #linux-sunxi
walkiry has joined #linux-sunxi
IgorPec4 has joined #linux-sunxi
IgorPec5 has joined #linux-sunxi
IgorPec4 has quit [Ping timeout: 252 seconds]
muvlon has quit [Ping timeout: 240 seconds]
IgorPec6 has joined #linux-sunxi
IgorPec5 has quit [Ping timeout: 252 seconds]
swiftgeek has quit [Ping timeout: 240 seconds]
lemonzest has joined #linux-sunxi
chlorine has quit [Read error: Connection reset by peer]
chlorine has joined #linux-sunxi
f0xx has quit [Remote host closed the connection]
f0xx has joined #linux-sunxi
reinforce has quit [Ping timeout: 255 seconds]
chlorine has quit [Remote host closed the connection]
IgorPec7 has joined #linux-sunxi
chlorine has joined #linux-sunxi
IgorPec8 has joined #linux-sunxi
IgorPec6 has quit [Ping timeout: 260 seconds]
<plaes> oliv3r: btw, CHIP uses 4.7uF next to LDO3
<plaes> and 10uF for LDO3IN
wzyy2 has quit [Read error: Connection reset by peer]
wzyy2 has joined #linux-sunxi
wzyy2 has quit [Read error: Connection reset by peer]
IgorPec7 has quit [Ping timeout: 255 seconds]
IgorPec9 has joined #linux-sunxi
swiftgeek has joined #linux-sunxi
IgorPec8 has quit [Ping timeout: 264 seconds]
paulk-blaze has joined #linux-sunxi
reinforce has joined #linux-sunxi
BenG83 has quit [Quit: Leaving]
ErwinH has quit [Read error: No route to host]
ErwinH has joined #linux-sunxi
<mripard> MoeIcenowy: we have a significant number of DTC warnings already
<mripard> I'd rather have these tackled before the obsolete things
<MoeIcenowy> mripard: how to enable DTC to output all warnings?
<wens> make W=1
<MoeIcenowy> will check it ;-)
<oliv3r> plaes: yeah I think all other boards use 4.7
<oliv3r> i think olimex went overly protective safe with 10, just to not realize it may be too much
<oliv3r> but i'm going to measure current next, and that should give us the definitive answer
<oliv3r> sort of :)
Xalius_Ph has joined #linux-sunxi
paulk-blaze has quit [Quit: Leaving]
wzyy2 has joined #linux-sunxi
Reapster has quit [Ping timeout: 256 seconds]
Reapster has joined #linux-sunxi
wzyy2 has quit [Read error: Connection reset by peer]
terra854 has joined #linux-sunxi
r1mikey has quit [Remote host closed the connection]
Pepe has quit [Ping timeout: 260 seconds]
r1mikey has joined #linux-sunxi
chlorine has quit [Remote host closed the connection]
wzyy2 has joined #linux-sunxi
wzyy2 has quit [Read error: Connection reset by peer]
IgorPec10 has joined #linux-sunxi
komunista has joined #linux-sunxi
r1mikey has quit [Remote host closed the connection]
chlorine_ has joined #linux-sunxi
IgorPec9 has quit [Ping timeout: 260 seconds]
<Putti> MoeIcenowy, interestingly the problem was just that I should have used console=ttyS0,115200 instead of console=tty1, which I think is weird because ttyS0 was supposed to be for the serial console but whatever, it works – now I have debian sid running on the tablet :)
r1mikey has joined #linux-sunxi
wzyy2 has joined #linux-sunxi
wzyy2 has quit [Read error: Connection reset by peer]
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
paulk-blaze has joined #linux-sunxi
IgorPec10 has quit [Ping timeout: 252 seconds]
wzyy2 has joined #linux-sunxi
wzyy2 has quit [Read error: Connection reset by peer]
chlorine_ has quit [Remote host closed the connection]
cptG_ has joined #linux-sunxi
jstein_ has joined #linux-sunxi
IgorPec10 has joined #linux-sunxi
jstein_ has quit [Remote host closed the connection]
jstein__ has joined #linux-sunxi
cptG has quit [Ping timeout: 255 seconds]
codekipper has quit [Quit: Page closed]
<Putti> any idea why the mainline 4.10 kernel doesn't recognize any USB devices (like keyboard, or USB hub,...)? Does the sunxi_defconfig have USB support enabled by default? I have A33 SoC, and according to http://linux-sunxi.org/Mainlining_Effort it should support USB.
jstein__ is now known as jstein
chlorine has joined #linux-sunxi
IgorPec10 has quit [Ping timeout: 264 seconds]
lurchi_ is now known as lurchi__
<plaes> are the usb endpoints actually present in devicetree?
<Putti> Should I put the explicitly to this one? Aren't they in the higher abstraction levels (the includes)?
<Putti> I'm pretty noob with these thus a bit lost.
IgorPec10 has joined #linux-sunxi
<Putti> hmm, I wonder if I can check it from the compiled dtb
chlorine has quit [Remote host closed the connection]
<Putti> and also the usb works fine on u-boot, not sure if the dts were exactly the same
<Putti> (compared to the mainline kernel)
<plaes> dmesg |grep -i usb
<Putti> I can't because I have nothing to input with :/
wzyy2 has joined #linux-sunxi
<oliv3r> plaes: i sure have some nice scope traces now :)
<MoeIcenowy> Putti: What USB? OTG or Host port?
chlorine has joined #linux-sunxi
<oliv3r> 2.8v is causing spikes of 200 mA
<Putti> MoeIcenowy, I connected the keyboard with micro usb to female usb adapter to the tablet. Not sure about the term.
<MoeIcenowy> It's OTG.
IgorPec10 has quit [Ping timeout: 240 seconds]
<MoeIcenowy> Does it work under stock Android?
<MoeIcenowy> I think currently q8 dts should support OTG
<plaes> oliv3r: cool
<Putti> I don't know, I need to test. But with the u-boot it works
<Putti> ah, it works, now I remembered that I tested it a while ago.
<Putti> what would be the kernel config to tick in order to support USB OTG?
<MoeIcenowy> oh I think sunxi_defconfig should work...
<Putti> hmm, ok. So now I need to start figuring out ways to communicate with the tablet.
<Putti> maybe custom init program that outputs "dmesg |grep -i usb" :D
<MoeIcenowy> could you share your .config ?
engideavr has quit [Quit: Konversation terminated!]
chlorine has quit [Remote host closed the connection]
<Putti> yes, well I have used just sunxi_defconfig and it had the same problem, and now I did some changes to the .config but it still has the same problem. So basically all the info you need is sunxi_defconfig?
lurchi__ is now known as lurchi_
<MoeIcenowy> and your kernel version?
<Putti> 4.10
chlorine_ has joined #linux-sunxi
<MoeIcenowy> it shoud work
<Putti> but could the bootarg console=ttyS0,115200 have any role in this problem? Shouldn't the input then come via the serial connection? Though, there is no led light in my USB hub or USB flash drive when I connect them so maybe it is not relevant.
<Putti> well, I will try now 4.11 RC.
cnxsoft has quit [Quit: cnxsoft]
wzyy2 has quit [Ping timeout: 260 seconds]
lkcl has joined #linux-sunxi
<jelle> oh nice, pull request for the H5 stuff
<jelle> for u-bot
<jelle> *u-boot
<plaes> u-boot mailinglist ;)
<Putti> link?
<plaes> ohwait.. on github?
<Putti> cool, I will go check it out, I hope there is archives somewhere
mzki has quit [Ping timeout: 260 seconds]
wzyy2 has joined #linux-sunxi
<jelle> Putti: yup that
<jelle> nice now I can dive into making a dts file for the nanopi a64
<plaes> oh you people with nice and shiny new SoCs ;)
<jelle> plaes: hehe
* plaes plans to send out clock-ng for A20 ...;)
<plaes> and then A10
<jonkerj> I may have aggegerated a bit on my H3 dev platform: http://imgur.com/1lKLc7R
<jonkerj> "in" the MDF box is a 30W PSU, a 4-channel relay board and a 5-port switch
<jonkerj> boards are daisy-chained (relay + serial console), and the setup connects using a single mains/utp to the outside world :-)
wzyy2 has quit [Ping timeout: 260 seconds]
<KotCzarny> cute!
<Putti> jonkerj, that's almost like the torture chamber in http://noir.liw.fi/devsetup/ :D
<KotCzarny> needs more leds though
reinforce has quit [Quit: Leaving.]
jstein has quit [Remote host closed the connection]
<jelle> jonkerj: nice
<jonkerj> I'm waiting for some screws and barrel plugs, but after that I will document it on my user page
<jonkerj> the inside of the box is a bit of a mess until then
<KotCzarny> did you consider verticall mounting/
<jelle> jonkerj: we don't want to see the inside do we? :p
<KotCzarny> jelle: i want!
JohnDoe_71Rus has joined #linux-sunxi
<jonkerj> jelle: not yet
<jonkerj> KotCzarny: yes, but these are different boards (opi+, opi-pc, opi1) with different hole layouts
<jonkerj> I would have loved that, but could not think of a sensible way to do it
<KotCzarny> shucks
<jonkerj> this concept scales to multiple "storeys" of course
<KotCzarny> some kind of universal frame maybe
<KotCzarny> actually, that would be nice market idea
<KotCzarny> universal frame + mount extenders
chlorine_ has quit [Remote host closed the connection]
<wens> looks much better than my desk
IgorPec has quit [Ping timeout: 264 seconds]
chlorine has joined #linux-sunxi
r1mikey has quit [Remote host closed the connection]
r1mikey has joined #linux-sunxi
leio has quit [Remote host closed the connection]
chlorine has quit [Remote host closed the connection]
r1mikey has quit [Remote host closed the connection]
Pepe has joined #linux-sunxi
chlorine has joined #linux-sunxi
chlorine has quit [Remote host closed the connection]
r1mikey has joined #linux-sunxi
chlorine_ has joined #linux-sunxi
<Pepe> Hello guys. I know that I can find here some Armbian developers. I have issue with nightly build which I put on Pine. Here is my syslog: http://pastebin.com/K2iP4ypg and what is important I think is: NMI watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [systemd-journal:359]
phipli has joined #linux-sunxi
<rellla> Pepe: please see channel topic...
<rellla> and second, google directs me to a possible power supply issue when c&p the message.
<Pepe> I know about channel topic, but I would rather ask than create another dup/stupid thread,post on forum and I also asked on proper #armbian , but there no developers or some guys which could help me.
<Pepe> and for second yes.. but nothing related to Pine, which was working with same adapter and with same cable on Android
<Pepe> and I have on it only weechat..
nove has joined #linux-sunxi
apritzel has joined #linux-sunxi
<swabbles> apritzel: hi, I think my patches are ready for a follow up RFC, but they currently depend on your pinctrl patches.
<swabbles> So I am not sure what to do exactly.
<apritzel> Pepe: try to add "fsl,erratum-a008585;" to the timer node in the DT
<apritzel> swabbles: I posted the two patches yesterday as part of the A64 DT update series
<swabbles> Ah cool :).
<apritzel> not sure if they go anywhere, though
<apritzel> it looks like we are moving towards DM GPIO
<swabbles> I am pretty much waiting for that to happen (or not) before I can do anything.
<swabbles> Ah, I can steer towards DM GPIO as well.
<swabbles> I'd just need some pointers then.
<apritzel> swabbles: that would be the best, check out the ML, last week I think
<swabbles> Will do, thanks :).
<Pepe> apritzel thanks. I will try.
Pepes has joined #linux-sunxi
<ssvb> jemk: I have added a todo section at https://linux-sunxi.org/TOC0#ToDo
leio has joined #linux-sunxi
fl_0 has quit [Ping timeout: 255 seconds]
<apritzel> ssvb: btw: thanks for adding the TOC0 tool info to the wiki
<ssvb> jemk: if you have already done some extra tests and know more, then please share this information, so that I don't have to research it independently :-)
<apritzel> ssvb: what is the last point in your TODO list? Isn't that covered by your toc0 FEL boot image?
<ssvb> apritzel: well, we need an U-Boot image in TOC0 format and then we need to update the sunxi-fel tool to load it correctly
<apritzel> ssvb: ah, I see
<ssvb> because right now the sunxi-fel tool expects eGON.BT0 signature
<apritzel> right
<apritzel> I missed the U-Boot part in this ;-)
<MoeIcenowy> apritzel: my Problems page updated
<MoeIcenowy> with some answers from AW
<apritzel> yeah, I saw that already, many thanks for that
<apritzel> seems like they at least confirmed most of our assumptions
<apritzel> still curious about that: "show us prove that TZPC doesn't work when booting without the fuse"
<MoeIcenowy> I told then the SID test
<MoeIcenowy> s/then/them
<apritzel> MoeIcenowy: ah, cool, thanks
<MoeIcenowy> may be it's a silicon bug
<ssvb> apritzel: I'll try to check this right now
<apritzel> ssvb: yeah, sounds like a plan
<ssvb> apritzel: we can probably dump and compare all HW registers between eGON.BT0 and TOC0 boot
<apritzel> I put some money on syscon ;-)
fkluknav has quit [Ping timeout: 240 seconds]
<ssvb> apritzel: BTW, have you checked if it is possible to go back to eGON.BT0 or the secure mode bit remains set to 1 forever?
<apritzel> haven't actually tried, as I put the fuse burning code in the vault ;-)
<MoeIcenowy> P.S. is it possible to directly convert a BT0 SPL to a TOC0 one?
<MoeIcenowy> or is recompile needed?
<apritzel> MoeIcenowy: no recompile, just re-wrapping
<apritzel> actually you put the eGON wrapped SPL into one of the TOC0 sections, IIRC
Pepe has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
<apritzel> MoeIcenowy: the loading seems to be different, since TOC0 actually holds the load address of the SPL/boot0 binary
<MoeIcenowy> but the position of code may change...
<apritzel> no, since you put 0x10000 in the TOC0 description
<apritzel> and BROM takes care that your SPL ends up there
fl_0 has joined #linux-sunxi
Pepes is now known as Pepe
<MoeIcenowy> but is header length different?
Pepe has quit [Quit: WeeChat 1.4]
Pepe has joined #linux-sunxi
<apritzel> MoeIcenowy: so it differs from eGON since it only loads the beginning of the TOC0 and checks the header first
<apritzel> then it loads the actual payload to the given address
<apritzel> which could be somewhere else than SRAM A1, even
<MoeIcenowy> so is it possible to load the actual payload to an offset the make the executable code start at the same address with eGON?
<ssvb> MoeIcenowy: it looks like the BROM is loading the TOC0 into SRAM A1 and then doing memmove to the location specified in the TOC item header
f0xx has quit [Ping timeout: 268 seconds]
<ssvb> I could see the remnants of the original TOC0 data in SRAM A1
<ssvb> BTW, it is possible to set something like 0x10100 as the load address and the code is just getting moved there and executed
<MoeIcenowy> something to add: I do not agree any projects that makes TOC0 the default way to boot.
<ssvb> if we can switch back to eGON.BT0 and find a way to configure secure peripherals, then I would prefer eGON.BT0
fkluknav has joined #linux-sunxi
<apritzel> ssvb: can you try to load stuff to SRAM A2 or C?
<ssvb> I have only done some very basic tests so far
<ssvb> I guess that SRAM A2 may be just not accessible before the SMC workaround, but we can check this
<jemk> ssvb: i didn't find the boot source, it almost looks like they don't store it anywhere
<ssvb> maybe they now store it in some HW register?
<jemk> don't know about the size limit, but i think its much higher
<jemk> thought i saw a vendor image with 80kb toc0 somewhere
<ssvb> okay, we can check this
jstein_ has joined #linux-sunxi
arete74_ has quit [Ping timeout: 240 seconds]
reinforce has joined #linux-sunxi
<ssvb> KotCzarny: you can do "git clone -b 20170213_detectvm https://github.com/n1tehawk/sunxi-tools.git", then compile it and test
chlorine_ has quit [Remote host closed the connection]
jstein_ is now known as jstein
<ssvb> KotCzarny: if it works fine, then you can post a comment with your Tested-By: tag
chlorine has joined #linux-sunxi
leio has quit [Ping timeout: 260 seconds]
leio has joined #linux-sunxi
leio has quit [Remote host closed the connection]
leio has joined #linux-sunxi
<komunista> please, what is temperature of the OPi zero to start afraid about it?
quinward has joined #linux-sunxi
<komunista> for now i have on idle CPU slightly over 60 °C
chlorine has quit [Remote host closed the connection]
chlorine has joined #linux-sunxi
chlorine_ has joined #linux-sunxi
chlorine_ has quit [Read error: Connection reset by peer]
<apritzel> ssvb: but when we load via TOC0, we are secure, so SRAM A2 should be accessible
<apritzel> it's only FEL on a "fused" board that starts in non-secure state
chlorine has quit [Remote host closed the connection]
robogoat has joined #linux-sunxi
topi`_ is now known as topi`
r1mikey has quit [Remote host closed the connection]
lurchi_ is now known as lurchi__
<ssvb> apritzel: I have already asked this and I'm sorry for being persistent, but have you tried to "unfuse" your board?
<apritzel> no, not yet
<apritzel> sorry if my answer above was confusing
<ssvb> ok, we just need to check this, document the results and move on
lkcl has quit [Ping timeout: 240 seconds]
<apritzel> ssvb: yes, please, if you can easily check this?
lemonzest has quit [Quit: Leaving]
lemonzest has joined #linux-sunxi
lurchi__ is now known as lurchi_
<ssvb> apritzel: no, I can't
<ssvb> I don't have a "fused" pine64 board and don't have plans to make one yet :-)
<ssvb> as for the Jide Remix Mini device, we don't know if eFUSE is programmable there (do they have voltage supplied to the right pin?)
jstein has quit [Remote host closed the connection]
<Putti> plaes, MoeIcenowy: http://i.imgur.com/kiGDarc.jpg – I managed to get the "dmesg | grep -i usb" to the screen, does that tell what might be wrong?
<Putti> sorry for the quality..
<Putti> the "supply vcc not found, using dummy regulator" message seems suspicious
fkluknav has quit [Ping timeout: 268 seconds]
engideavr has joined #linux-sunxi
arete74 has joined #linux-sunxi
r1mikey has joined #linux-sunxi
|Jeroen| has joined #linux-sunxi
r1mikey has quit [Remote host closed the connection]
<apritzel> ssvb: ah, good point, will try to add this to my ever growing TODO list ...
engideavr has quit [Quit: Konversation terminated!]
netlynx has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has quit [Changing host]
<apritzel> ssvb: I should sell my fused Pine64 on eBay: "RARE! Secure 64-bit supercomputer, RARE!"
engideavr has joined #linux-sunxi
<Ke> apritzel: remember also to add SEX
<apritzel> Ke: you mean as in "Secure EXecution?" ;-)
<Ke> =o)
fkluknav has joined #linux-sunxi
paulk-blaze has quit [Quit: Leaving]
apritzel has left #linux-sunxi [#linux-sunxi]
r1mikey has joined #linux-sunxi
r1mikey has quit [Remote host closed the connection]
r1mikey has joined #linux-sunxi
Xalius_Ph has quit [Ping timeout: 240 seconds]
arete74 has quit [Ping timeout: 240 seconds]
engideavr has quit [Quit: Konversation terminated!]
Xalius_Ph has joined #linux-sunxi
jernej has joined #linux-sunxi
r1mikey has quit [Read error: Connection reset by peer]
r1mikey has joined #linux-sunxi
lkcl has joined #linux-sunxi
terra854 has quit [Quit: Connection closed for inactivity]
yann has quit [Ping timeout: 268 seconds]
r1mikey_ has joined #linux-sunxi
r1mikey has quit [Remote host closed the connection]
phipli has quit [Ping timeout: 260 seconds]
ErwinH has quit [Remote host closed the connection]
lkcl has quit [Ping timeout: 260 seconds]
r1mikey has joined #linux-sunxi
|Jeroen| has quit [Quit: dada]
leviathan has quit [Ping timeout: 255 seconds]
massi has quit [Remote host closed the connection]
r1mikey_ has quit [Ping timeout: 260 seconds]
leviathan has joined #linux-sunxi
Andy-D has joined #linux-sunxi
phipli has joined #linux-sunxi
Xalius_Ph has quit [Quit: Bye]
r1mikey has quit [Ping timeout: 260 seconds]
Xalius_Ph has joined #linux-sunxi
mzki has joined #linux-sunxi
wzyy2 has joined #linux-sunxi
wzyy2 has quit [Ping timeout: 255 seconds]
enrico__ has quit [Quit: Bye]
chlorine has joined #linux-sunxi
Ntemis has joined #linux-sunxi
<Putti> I tried making following dts file for the A33 tablet that didn't have power on USB bus: http://paste2.org/37ChezgI – but that didn't make the USB have power. This is the device's fex: http://paste2.org/YCe0w0Mj. What might be wrong?
ErwinH has joined #linux-sunxi
ErwinH_ has joined #linux-sunxi
ErwinH has quit [Ping timeout: 255 seconds]
paulk-collins has joined #linux-sunxi
Xal1us_Ph has joined #linux-sunxi
Xal1us_Ph has quit [Client Quit]
Xalius_Ph has quit [Read error: Connection reset by peer]
Xalius_Ph has joined #linux-sunxi
Xalius_Ph has quit [Client Quit]
ErwinH_ has quit [Ping timeout: 255 seconds]
<MoeIcenowy> ssvb: I suggest you provide some static build of cpuburn-arm programs ;-)
<MoeIcenowy> Putti: oh I remembered that you are using otg...
<MoeIcenowy> please build a gadget and load it
<Putti> MoeIcenowy, building gadget means?
<MoeIcenowy> musb won't even work in host mode if a gadget is not present
<MoeIcenowy> build one of g_* modules
yann has joined #linux-sunxi
<MoeIcenowy> build it into kernel, or make your userspace load it
<MoeIcenowy> as module
<Putti> do you think I won't then even need to tweak the dts?
<Putti> ok, trying now.
<MoeIcenowy> I remembered this problem suddenly
<MoeIcenowy> yes
<Putti> MoeIcenowy, is that enough: http://i.imgur.com/kqwUHy7.png ?
phipli has quit [Ping timeout: 240 seconds]
petr_ has quit [Remote host closed the connection]
petr has joined #linux-sunxi
<MoeIcenowy> Putti: ok
<MoeIcenowy> you can choose any gadget you like
<plaes> ok.. two more clocks to go...
<MoeIcenowy> ?
<MoeIcenowy> ccu?
<plaes> A20 ccu
<MoeIcenowy> I sent out a modified version of megous' sun8i-ths driver (modifications are prepare support multi sensor THS's (A64/H5) and support read calibration data from eFUSE
leviathan has quit [Ping timeout: 255 seconds]
<igraltist> hmm the orangepi-pc is sold out
<igraltist> how far ist the linux support for the orangepi-pc2?
<plaes> igraltist: u-boot will have it soon
<plaes> for pc2 there is patchset
<Putti> MoeIcenowy, didn't do the trick. Other ideas?
<plaes> s/pc2/linux
<igraltist> ok thx
vinimac has joined #linux-sunxi
arete74 has joined #linux-sunxi
vinimac has quit [Quit: Saindo]
vinimac has joined #linux-sunxi
chlorine has quit [Remote host closed the connection]
chlorine has joined #linux-sunxi
ErwinH has joined #linux-sunxi
chlorine has quit [Ping timeout: 260 seconds]
phipli has joined #linux-sunxi
ErwinH has quit [Ping timeout: 255 seconds]
r1mikey has joined #linux-sunxi
lemonzest has quit [Quit: Leaving]
phipli has quit [Ping timeout: 240 seconds]
phipli has joined #linux-sunxi
ErwinH has joined #linux-sunxi
florianH has quit [Quit: Connection closed for inactivity]
ErwinH has quit [Ping timeout: 255 seconds]
netlynx has quit [Quit: Ex-Chat]
BenG83 has joined #linux-sunxi
keesj has joined #linux-sunxi
phipli has quit [Ping timeout: 240 seconds]
keesj has left #linux-sunxi [#linux-sunxi]
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 255 seconds]
fkluknav has quit [Ping timeout: 268 seconds]
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 255 seconds]
phipli has joined #linux-sunxi
<FergusL> in terms of power consumption, should disabling wifi in nmcli be enough? like "nmcli radio all off"
r1mikey has quit [Ping timeout: 240 seconds]
LargePrime has quit [Ping timeout: 268 seconds]
reinforce has quit [Quit: Leaving.]
phipli has quit [Ping timeout: 240 seconds]
r1mikey has joined #linux-sunxi
r1mikey has quit [Ping timeout: 255 seconds]
LargePrime has joined #linux-sunxi
ErwinH has joined #linux-sunxi
paulk-collins has quit [Quit: Leaving]
ErwinH has quit [Ping timeout: 255 seconds]
phipli has joined #linux-sunxi
vinimac_ has joined #linux-sunxi
vinimac__ has joined #linux-sunxi
lurchi_ is now known as lurchi__
vinimac has quit [Ping timeout: 268 seconds]
dave0x6d has joined #linux-sunxi
vinimac_ has quit [Ping timeout: 260 seconds]
Net147 has quit [Ping timeout: 260 seconds]
iamfrankenstein has quit [Quit: iamfrankenstein]
Net147 has joined #linux-sunxi
vinimac__ has quit [Remote host closed the connection]
komunista has quit [Quit: Leaving.]
phipli has quit [Ping timeout: 240 seconds]
phipli has joined #linux-sunxi
nove has quit [Quit: nove]
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 255 seconds]
JohnDoe_71Rus has quit [Quit: KVIrc 4.9.2 Aria http://www.kvirc.net/]
apritzel has joined #linux-sunxi
chomwitt has quit [Ping timeout: 240 seconds]
<apritzel> ssvb: so writing 0 to efuse 0xf4 doesn't change anything, also writing 0x800 again
<apritzel> the fuse stays at 0x800 and the board stays "secure"
<ssvb> apritzel: I see, thanks
<ssvb> that's too bad
<apritzel> I don't dare to write anything else
<ssvb> yes, it's understandable
<apritzel> maybe I could try to set a bit in the ID area
<apritzel> serial number, I mean
<apritzel> ssvb: have you looked at the secure BROM?
r1mikey has joined #linux-sunxi
<jemk> apritzel: the flags sbrom uses for various things are two bit wide, if only the high bit is 1 it is enabled, if the low bit is 1 its (permanently then) disabled
<ssvb> not at the BROM, I tried to dump HW registers and compare them - https://gist.github.com/ssvb/88963c61c714068716412d828b9ff74e/revisions
<ssvb> but it does not look like anything affects it
<jemk> if the secure flag follows the same principle it could be disabled by 0xc00
<jemk> but i don't want to risk that currently
<ssvb> the SRAM A2 and SID are supposed to be secure-only, so the SPC setup should not matter
<apritzel> jemk: me neither ;-)
r1mikey has quit [Ping timeout: 255 seconds]
<ssvb> jemk: that's good to know, maybe Jide Remix Mini can be converted to use eGON.BT0 again, but I also do not want to try it yet :-)
Ntemis has quit [Remote host closed the connection]
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 255 seconds]
mzki has quit [Ping timeout: 240 seconds]