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
vagrantc has quit [Ping timeout: 245 seconds]
vagrantc has joined #linux-sunxi
Ntemis has quit [Remote host closed the connection]
mzki has quit [Ping timeout: 265 seconds]
<igraltist> what is max temperatur for cpu on orangepi
<igraltist> when i playing in firefox a youtube video over vnc i got cpu temp to 62^C
<igraltist> on idle is from 36-40
<igraltist> <
<apritzel> igraltist: 62C is warm, but nothing to worry about
Andy-D_ has quit [Ping timeout: 245 seconds]
vagrantc has quit [Ping timeout: 250 seconds]
Da_Coynul has joined #linux-sunxi
Da_Coynul has quit [Client Quit]
jernej has quit [Ping timeout: 240 seconds]
lkcl has quit [Read error: Connection reset by peer]
lkcl has joined #linux-sunxi
lkcl has quit [Ping timeout: 256 seconds]
lkcl has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
popolon has quit [Quit: WeeChat 1.4]
ninolein has quit [Ping timeout: 258 seconds]
ninolein has joined #linux-sunxi
Da_Coynul has joined #linux-sunxi
terra854 has joined #linux-sunxi
Pepe has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
<apritzel> MoeIcenowy: since you asked for: ;-)
<apritzel> the Linux branch supports OrangePi PC2, BananaPi M64 and Pine64, with MMC, USB, Ethernet
<wens> nice
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
apritzel has quit [Ping timeout: 248 seconds]
p_rossak has quit [Ping timeout: 240 seconds]
nixdork has quit [Ping timeout: 240 seconds]
p_rossak_ has joined #linux-sunxi
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
nixdork has joined #linux-sunxi
Da_Coynul has joined #linux-sunxi
mrnuke has quit [Ping timeout: 240 seconds]
mrnuke has joined #linux-sunxi
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
vagrantc has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
IgorPec has joined #linux-sunxi
MXfive has joined #linux-sunxi
pg12 has quit [Ping timeout: 268 seconds]
pg12_ has joined #linux-sunxi
paulk-collins has quit [Ping timeout: 250 seconds]
TheSeven has quit [Ping timeout: 258 seconds]
TheSeven has joined #linux-sunxi
laj has quit [Quit: Page closed]
JohnDoe_71Rus has joined #linux-sunxi
victhor has quit [Ping timeout: 258 seconds]
JohnDoe71rus has joined #linux-sunxi
JohnDoe_71Rus has quit [Read error: Connection reset by peer]
f0xx has joined #linux-sunxi
reinforce has joined #linux-sunxi
muvlon has quit [Ping timeout: 258 seconds]
iamfrankenstein has joined #linux-sunxi
Putti has quit [Ping timeout: 240 seconds]
muvlon has joined #linux-sunxi
IgorPec has quit [Quit: Nettalk6 - www.ntalk.de]
montjoie has quit [Ping timeout: 256 seconds]
montjoie has joined #linux-sunxi
<KotCzarny> willmore: i've hooked physical switch on the power cable to save the connector and jack, my issue was that when i was testing uboot via fel mode, when resetting board via 'reset' command in uboot it didnt accept next fel uboot
<beeble> KotCzarny: i meant to introduce an additional fdt value.
tsuggs has quit [Ping timeout: 245 seconds]
<igraltist> on armbian orangepi-pc the pulseaudio often lose the audiodevice
<KotCzarny> beeble: but that still requires user action, right?
<KotCzarny> igraltist: then uninstall pa-from-hell and just use alsa
<igraltist> i think is to old
<igraltist> version 5
<igraltist> i need it vor later use
<igraltist> i try if the cpu power enough to be a remote browsing station
<beeble> KotCzarny: i was assuming you would have a specific dts per device. if you want to have a single uboot (seems a nice idea but usually doesn't work that well) you would need a detection command
<KotCzarny> beeble: yes, that's what i meant/wanted
<KotCzarny> but as i've found, its not that easy to do, since there is no config/model name to be found on clean boot
<beeble> KotCzarny: i would still go with a dedicated command and a boot.cmd script. seems easier to rebase since it's not likely something that would be merged mainline
<KotCzarny> so far i've did opipc as a default, and add per-serial# exceptions, and for a limited number of boxes (<20) its feasible and works nicely
<KotCzarny> beeble: i haven't modified uboot yet, only done it via standard uboot scripting
Putti has joined #linux-sunxi
<KotCzarny> it would be much easier if vendor simply selected one sid longword to put vendor_id+model_id there
jernej has joined #linux-sunxi
tsuggs has joined #linux-sunxi
MXfive has quit [Quit: Sleep Quit.]
DullTube has joined #linux-sunxi
lemonzest has joined #linux-sunxi
<KotCzarny> would be nice if people added more sid values to the wiki, bigger data, better guessing algo
muvlon has quit [Quit: Leaving]
jernej has quit [Ping timeout: 264 seconds]
MXfive has joined #linux-sunxi
msevwork has joined #linux-sunxi
<beeble> http://sakuraboard.net/ how to reinforce stereotypes
<KotCzarny> say what you want, people are people
<beeble> at least it's kawaii :)
vagrantc has joined #linux-sunxi
<wens> that pink is off
ErwinH has joined #linux-sunxi
leviathanch has joined #linux-sunxi
f0xx has quit [Remote host closed the connection]
vagrantc has quit [Quit: leaving]
Andy-D_ has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
|Jeroen| has joined #linux-sunxi
leviathanch has quit [Remote host closed the connection]
apritzel has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 248 seconds]
<MoeIcenowy> apritzel: thx!
f0xx has joined #linux-sunxi
<ErwinH> apritzel: thnx! :)
leviathanch has joined #linux-sunxi
muvlon has joined #linux-sunxi
<MoeIcenowy> wens: maybe it's now the time for R40 SPL? ;-)
<wens> MoeIcenowy: i'm busy atm
<MoeIcenowy> oh...
<wens> if i'm doing sunxi stuff during work hours, it means i'm slacking off :p
<wens> can't do that too often
<MoeIcenowy> yes
<MoeIcenowy> but the other ones are preparedd ;-)
<MoeIcenowy> so I mean you have the possibility to do it now ;-)
apritzel has quit [Ping timeout: 268 seconds]
<wens> i know, but i still have to pick the updated patches and rework any conflicting changes
<jelle> hmm that sakura board is very pink
massi has joined #linux-sunxi
IgorPec has joined #linux-sunxi
<KotCzarny> so pity sample count
MXfive has quit [Quit: Sleep Quit.]
IgorPec2 has joined #linux-sunxi
IgorPec has quit [Ping timeout: 252 seconds]
Leepty has joined #linux-sunxi
<MoeIcenowy> KotCzarny: I will contribute all my boards' sample, although it's also little
<KotCzarny> thanks!
<wens> i think i already did mine
<wens> on the wiki that is
<KotCzarny> maybe armbian should have info to ask for sid reporting
andoma has quit [Ping timeout: 260 seconds]
techping has joined #linux-sunxi
andoma has joined #linux-sunxi
techping has quit [Remote host closed the connection]
techping has joined #linux-sunxi
fkluknav has joined #linux-sunxi
f0xx has quit [Ping timeout: 258 seconds]
techping has quit [Remote host closed the connection]
techping has joined #linux-sunxi
<MoeIcenowy> wens: at least you didn't do you BPi M2 Ultra ;-)
<MoeIcenowy> KotCzarny: according to the H2+ BSP, H3 and H2+ can be differed by SID
cnxsoft has joined #linux-sunxi
<KotCzarny> link to code?
<MoeIcenowy> let me do a grep
<KotCzarny> maybe it will have hints to sid's field meanings
<MoeIcenowy> but, I will say something pessimistic...
<MoeIcenowy> you may be never able to differ different boards from the same vendor with the same SoC with SID
<KotCzarny> yeah, figured that much looking at oranges
hp197 has joined #linux-sunxi
leviathanch has quit [Remote host closed the connection]
<MoeIcenowy> search for "H2+" in this file
<KotCzarny> thx
<MoeIcenowy> maybe at line 138
<KotCzarny> h3d ?
<KotCzarny> some new chip?
<MoeIcenowy> maybe
<MoeIcenowy> I don't also know what H3D is
<MoeIcenowy> but something strange is that the SIDS all do not match the code
<MoeIcenowy> except the two SIDs retrieved by devmem2
<KotCzarny> most likely some blob overwrites mem during boot
<MoeIcenowy> so... more interesting
paulk-collins has joined #linux-sunxi
<MoeIcenowy> as H3 boot0 can, in fact, be built with the u-boot-2011.07 in lichee
<MoeIcenowy> with "make spl"
<KotCzarny> do you have any h3 board with mainline uboot+kernel ? or does devmem2 only works with legacy kernel?
techping has quit [Remote host closed the connection]
<MoeIcenowy> I have
techping has joined #linux-sunxi
<MoeIcenowy> In fact I have no h3 board with legacy kernel
<MoeIcenowy> how to read it with devmem2?
<KotCzarny> there is a script above table
<MoeIcenowy> ok will try with my opi pc2
<MoeIcenowy> s/pc2/one/g
f0xx has joined #linux-sunxi
<MoeIcenowy> KotCzarny: Under mainline kernel it's still 0x02004620 in the first section
<KotCzarny> then boot0 does board detection apparently, or at least some chip features
<MoeIcenowy> Value at address 0x1C14200 (0xb6f40200): 0x2004620
<KotCzarny> and i thought sids were mapped to hardware, not being able to be overriden
<MoeIcenowy> so maybe boot0 enables some magic bits that changed SID?!
<MoeIcenowy> To be honest, when I first read your two values retrieved by devmem2, I felt strange
Techping-X has joined #linux-sunxi
<KotCzarny> they are reset to default values after reboot
<KotCzarny> ie. the real sid written in hw
techping has quit [Ping timeout: 246 seconds]
apritzel has joined #linux-sunxi
Techping-X has quit [Client Quit]
Techping-X has joined #linux-sunxi
Techping-X has quit [Remote host closed the connection]
techping has joined #linux-sunxi
apritzel has quit [Client Quit]
Andy-D_ has quit [Ping timeout: 240 seconds]
<MoeIcenowy> KotCzarny: maybe furtherly it will be valuable to dump the full SID eFUSE, not also the usual 16 bytesw
<KotCzarny> wasnt efuse 128bits (16bytes) only?
Putti has quit [Ping timeout: 258 seconds]
<MoeIcenowy> I think it's of course not only 16 bytes on H3+
<KotCzarny> any proof/hint of that?
<MoeIcenowy> see ./arch/arm/cpu/armv7/sun8iw7/efuse.c ( in allwinner's u-boot-2011.09 source
<MoeIcenowy> the 16 bytes is only called "chipid" in this file
<MoeIcenowy> there's something called "oem", length 4 bytes, offset at 0x10
<MoeIcenowy> some thing called "thermal sensor" (calibration number?), length 8 bytes, offset at 0x34
<MoeIcenowy> not efuse.h, but efuse.c
<MoeIcenowy> it contains some reading code
<MoeIcenowy> and dgp reported some secure boot features on H3 implemented with eFUSE
techping has quit [Remote host closed the connection]
<KotCzarny> it looks like some hidden interface
<KotCzarny> ie. treats efuse mem space as output registers
<MoeIcenowy> yes,,, maybe eFUSEs after H3 is a really mystery
<MoeIcenowy> and we know too little
<KotCzarny> that could also explain weird thermal readings on h3
<MoeIcenowy> maybe we need a special driver for h3 sid...
<KotCzarny> imo for sid in general
<KotCzarny> because aw reuses the chip parts
<MoeIcenowy> maybe I should say sids after h3
<KotCzarny> and everything that doesnt have chipid in first sid longword uses that hidden interface
<MoeIcenowy> according to sid_read_key() in efuse.c
<MoeIcenowy> I think the first longword may be selectable
<KotCzarny> yes, that's what i meant by hidden interface/register like output
<MoeIcenowy> in ./arch/arm/include/asm/arch-sun8iw7/sid_reg.h there's some length info!
<MoeIcenowy> it shows many sections in sid
<KotCzarny> #define EFUSE_IDENTIFIC (0x5C)
<KotCzarny> wanna write userspace little app to report all available info?
<MoeIcenowy> maybe a shell script ;-)
<KotCzarny> if you can write mem from shell script easily ;)
<KotCzarny> i think it could reuse devmem2 cde
<MoeIcenowy> devmem2 ;-)
<KotCzarny> but it will be called many, many times, so better to just use c for that
<MoeIcenowy> I have been called "Overuse Shell" as I written too many things in shell ;-)
<KotCzarny> which also would have a bonus of being able to write uboot/kernel driver easily
<MoeIcenowy> at least it's prototyping
buZz has quit [Ping timeout: 248 seconds]
<MoeIcenowy> I think the author of sun8i-ths may made a H3 sid driver...
techping has joined #linux-sunxi
Worf has joined #linux-sunxi
IgorPec2 has quit [Quit: Nettalk6 - www.ntalk.de]
IgorPec has joined #linux-sunxi
<wens> i would not touch the undocumented registers in the SID with a ten-foot pole
<wens> ha, probably the wrong usage of the idiom
<wens> anyway, writing to the registers blindly might irreversibly alter the e-fuses
<MoeIcenowy> yes...
<MoeIcenowy> but reading should be ok...
<KotCzarny> does it mean anything for mainline uboot/kernel?
<KotCzarny> ie. are they used ?
<MoeIcenowy> currently in mainline kernel only the first 16B is used
florianH has joined #linux-sunxi
<MoeIcenowy> wens: the full SID is all undocumented
<MoeIcenowy> even the chipid is not documented ;-)
<MoeIcenowy> we just found where to read them ;-)
<MoeIcenowy> and according to H3 datasheet the SID is 2Kbit long
techping has quit [Remote host closed the connection]
<MoeIcenowy> KotCzarny: I thought something more pessmistic...
<MoeIcenowy> as it's called "chipid"
<MoeIcenowy> maybe we can never fully identify a board by the "chipid"
<MoeIcenowy> as it may be flashed by allwinner
<wens> MoeIcenowy: we actually asked allwinner staff how to read it :|
<KotCzarny> MoeIcenowy: there is also oem field, which might contain some vendor specific data
<MoeIcenowy> maybe a board model's chipid rule will be easily broken when they used all their stock and bought new chips
<KotCzarny> that's most likely
<KotCzarny> but at least vendor id should be there imo
<MoeIcenowy> I will try to read all them out now
<MoeIcenowy> and please pray for me not to wrongly miswrite my SID ;-)
<KotCzarny> those boards are cheap
<KotCzarny> just use the cheapest one you have
<KotCzarny> :)
f0xx has quit [Read error: Connection reset by peer]
<KotCzarny> and mark it with marker 'test subject #1'
f0xx has joined #linux-sunxi
<KotCzarny> and backup first data batch to have some comparison later
yann-kaelig has joined #linux-sunxi
techping has joined #linux-sunxi
gaby has left #linux-sunxi [#linux-sunxi]
Putti has joined #linux-sunxi
<MoeIcenowy> KotCzarny: I wrote some reading code which modelled after the u-boot code in bash
<MoeIcenowy> however, when I read in such a way
<MoeIcenowy> the longword at sid 0x0 is 0x02c00081, not 0x02004620
<MoeIcenowy> and then 0x01c14200 changed to 0x02c00081
<MoeIcenowy> INTERESTING
<MoeIcenowy> https://pastebin.anthonos.org/view/d71a8516 here's the code
<MoeIcenowy> to use it, enter a bash, and "source sid.sh", then run "sid_read_key $address"
<KotCzarny> MoeIcenowy: did it change between two reads?
<KotCzarny> without anything else done?
<MoeIcenowy> yes
<MoeIcenowy> after doing a read in such way, the *0x01c14200 changed
<KotCzarny> MoeIcenowy: fun, i'm ripping c code from sources
<MoeIcenowy> I think my bash code is easy to translate to C ;-)
<KotCzarny> using c sources already makes many defines available ;)
<KotCzarny> and functions
<MoeIcenowy> yes...
<MoeIcenowy> maybe I should soon write a sun8i-sid kernel driver
<MoeIcenowy> let me register a "Working In Progress" on wiki by me
<KotCzarny> ah, i know why you get different values
<MoeIcenowy> KotCzarny: ?
<MoeIcenowy> my opinion is that the 0x02004620 is really some uninitialized value, not the real SID
<KotCzarny> by any chance chip id is not 4 bytes but 8 ?
Putti has quit [Ping timeout: 240 seconds]
<MoeIcenowy> nope
<MoeIcenowy> I read out 0x10, it is 0xC3
<MoeIcenowy> maybe we should write a program and let apritzel run it on his Jide Remix Mini
<MoeIcenowy> the Jide Remix Mini enabled secure boot features
Putti has joined #linux-sunxi
apritzel has joined #linux-sunxi
<MoeIcenowy> could you write a SID reading userspace program in C?
<jski> can anyone explain this behaviour from my mircosd cards https://bpaste.net/show/bbfd09a13e03 I have the same problem on about 5 samsung evo U1
<apritzel> MoeIcenowy: maybe this helps? https://github.com/apritzel/peekpoke
<MoeIcenowy> apritzel: are you interested in reading all of your Jide Remix Mini's eFUSE?
<apritzel> MoeIcenowy: sure, can do, though I believe some parts (if not all?) are restricted from non-secure world
<apritzel> that's why Allwinner has some callback in ATF to read the SID
<MoeIcenowy> ah-oh...
<apritzel> and I don't believe that you can actually change the SID by writing to it
<MoeIcenowy> I read out a lot of 0 on my H3 within /dev/mem
<apritzel> you may change the current readout, but it should be reset after reboot ?
<MoeIcenowy> no
<MoeIcenowy> the readout cannot even be changed
<apritzel> OK, then I misread something above ...
<MoeIcenowy> I think the real chipid 0x0 readout on H3 is 0x02c00081
<MoeIcenowy> however
IgorPec has quit [Ping timeout: 260 seconds]
<MoeIcenowy> when something is not initialized
<MoeIcenowy> the value is not read out
<MoeIcenowy> and a random 0x02004620 is stored there
<MoeIcenowy> maybe on other chips there's also double readout ;-)
<apritzel> well, apparently you _can_ write the SID by applying a special voltage to a specific pin on the SoC and following some write sequence
<apritzel> though on most boards this pin in tied to GND
<MoeIcenowy> the special voltage is needed?
<MoeIcenowy> the SID interface give me a sense that there's a poor "bridge"
<MoeIcenowy> I write controll command to a register
<MoeIcenowy> wait the work to be done
Worf has quit [Quit: Konversation terminated!]
<MoeIcenowy> and retrieve the value from another register
<apritzel> VDD-EFUSE: it's supposed to be 3.0V
<MoeIcenowy> oh...
<MoeIcenowy> not noticed this
<apritzel> wasn't it connected on the OrangePi-One?
<apritzel> I mean -Zero ...
<MoeIcenowy> I will check it
<MoeIcenowy> yes got this pin
<MoeIcenowy> the schematics says that it's connected to "VCC3V3-EFUSE"
<MoeIcenowy> and it's connected to VCC-IO
<apritzel> yeah, so I remembered right ;-)
<MoeIcenowy> but maybe it's not the write voltage...
<apritzel> technically VCC-IO is 3.3V and not 3.0V, but that hopefully doesn't matter
<MoeIcenowy> maybe it's just the voltage to power the efuse part of the SoC
<MoeIcenowy> and some internal thing can provide the write voltage
<MoeIcenowy> (I do not know well about electronics
<apritzel> mmh, there is VDDBP-EFUSE as well...
<MoeIcenowy> yes this may be the writing voltage ;-)
techping has quit [Ping timeout: 246 seconds]
<apritzel> it would make sense to make this a separate pin with a special voltage, so a board vendor (or the SoC fab) could initialize the SID on a tester machine
<apritzel> and it's read-only on a normal board
<KotCzarny> or they come preinitialised from aw already
<KotCzarny> because programming every chip by vendors eats time and money
<KotCzarny> and would require specialized equipment
<apritzel> KotCzarny: yeah, that's what I meant with "or the SoC fab"
Da_Coynul has joined #linux-sunxi
<MoeIcenowy> but now here's a problem
<apritzel> but having a pin leaves the option for a board vendor to program the SID as well
<MoeIcenowy> what SID first byte should we use?
fkluknav has quit [Ping timeout: 245 seconds]
<MoeIcenowy> the old readout before the SID controller call
<MoeIcenowy> or the new readout after calling the SID controller?
<KotCzarny> MoeIcenowy: we shall investigate further
<MoeIcenowy> the new readout is, at least, able to differ H3 and H2+
<KotCzarny> then we can decide
<KotCzarny> right now we dont know what those values are
<KotCzarny> and we cane leave them as such before we get a working tool
apritzel has left #linux-sunxi [#linux-sunxi]
<MoeIcenowy> I think Allwinner themselves considered the new readout as their SID value
<KotCzarny> nice and cozy segmentation fault. mmm
popolon has joined #linux-sunxi
mzki has joined #linux-sunxi
<igraltist> is the orangepi setup identical to cubietruck for booting routine on mainline kernel?
<igraltist> on armbian i see a script.bin but iam not sure how to create them
<KotCzarny> you should really read wiki about mainline/legacy uboot and kernel
<igraltist> then its the same
<igraltist> and no script bin anymore
<plaes> igraltist: script.bin is legacy kernel specific
<plaes> it's basically Allwinner-specific devicetree
Putti has quit [Ping timeout: 250 seconds]
iaglium has joined #linux-sunxi
bmeneg has quit [Remote host closed the connection]
<jski> if I create a filesystem over my microsd it does not wipe it :/
<jski> all 5 of my samsung evo's
<jski> it is like they are write protected but they are not :/
<igraltist> create a filesystem does not mean nullify all
<igraltist> because its take a litle time only
<jski> am doing a full dd of zero on it now
<KotCzarny> bus error, mm
<jski> the sandisks are fine but all 5 samsung evos not
<jski> all ext4 filesystems were corrupt
<jski> no way to repair
<igraltist> for next setup i think i use the f2fs
<jski> better that btrfs?
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<igraltist> its was designed for flash
<igraltist> i cant use btrfs because i use rsbac and this is inode based and btrfs does to much others
<igraltist> i will see if the machine boots later
<jski> I was planning on trying btrfs but will read up on f2fs also
<igraltist> i just read about but never use
Putti has joined #linux-sunxi
techping has joined #linux-sunxi
<jski> just dd'ed the whole card to zero and the data is still there haha
* jski gets the hammer from the drawer
<jski> I would expect this from the cheap microsd cards not the samsungs
Da_Coynul has joined #linux-sunxi
<ErwinH> My second OPi Zero came in today, and this one came with a SPI chip presoldered!
<jelle> :o
Da_Coynul has quit [Client Quit]
ErwinH_ has joined #linux-sunxi
<ErwinH_> You'd allmost start to believe Xunlong is listening to their customers ;)
<NiteHawk> MoeIcenowy: Allwinner doesn't seem to be very consistent in handling their "chipid" - see e.g. https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/arch/arm/mach-sunxi/sun8i.c#L135-L143
<NiteHawk> maybe the difference is all about accessing the SID registers in secure mode? at least that seems to be what sunxi_smc_readl() might do differently - https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/arch/arm/mach-sunxi/include/mach/sunxi-smc.h#L50-L58
ErwinH has quit [Ping timeout: 260 seconds]
<montjoie> MoeIcenowy: sun8i-sid was already under work, just need to send patch
aballier has joined #linux-sunxi
Amit_T has joined #linux-sunxi
victhor has joined #linux-sunxi
zzeroo has quit [Ping timeout: 246 seconds]
codekipper has quit [Quit: Page closed]
Mr__Anderson has joined #linux-sunxi
ErwinH_ is now known as ErwinH
<KotCzarny> MoeIcenowy: im getting mangled first word anyway, even if using that complicated read routine
<MoeIcenowy> KotCzarny: what do you mean mangled?
<MoeIcenowy> montjoie: this sun8i-sid can only read 4 bits
<MoeIcenowy> s/bits/words
<MoeIcenowy> but sun8i efuse have really 64 words
<jonkerj> I recall megi's THS/DVFS patchset uses SID as well
<jonkerj> but he does so using without using a generic sid-driver
<MoeIcenowy> KotCzarny: I think 02c00081 is the real chip id's first word
<montjoie> MoeIcenowy: you mean you want to decode all address space ? and not only the ID
<MoeIcenowy> yes
<MoeIcenowy> my new driver is scheduled to be named sun8i-efuse, not sun8i-sid ;-)
JohnDoe71rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
<MoeIcenowy> KotCzarny: could you try to read them out in FEL?
<MoeIcenowy> apritzel says something cannot be read in secure world
<KotCzarny> static compile, works in both android and linux
<KotCzarny> and source
<KotCzarny> using devmem2 code
IgorPec has joined #linux-sunxi
<KotCzarny> might be that you've got unclobbered things because you ran in mainline
zzeroo has joined #linux-sunxi
<KotCzarny> this one uses mainline uboot, but legacy kernel
<MoeIcenowy> in mainline I think the register-based readout code is never called during boot
<MoeIcenowy> so after boot we can still read out an uninitialized value
<MoeIcenowy> but in legacy the value is properly initialized
<KotCzarny> but this is done in kernel, not uboot/boot0 apparently
<MoeIcenowy> I think they both do
<MoeIcenowy> both legacy kernel and legacy uboot have the right readout code
<MoeIcenowy> and after a full readout based on registers
<MoeIcenowy> reading directly from *(0x01c14200 + offset) is also ok
<MoeIcenowy> before doing register-based readout, the value of *0x01c14210 is 0x0; after that it's 0xc3
<MoeIcenowy> KotCzarny: OH your 0x10 in eFUSE is not equal to mine!
<MoeIcenowy> what's your board?
<KotCzarny> opipc
<MoeIcenowy> mine is opi one
<KotCzarny> care to run that sid thing on the mainline zero and pastebinning the result?
<MoeIcenowy> zero?
<MoeIcenowy> I can now just run them under sunxi-fel
<KotCzarny> whichever, h3
<MoeIcenowy> so now no kernel is needed ;-)
<KotCzarny> im interested what values will you get under linux
<MoeIcenowy> mainline linux?
<KotCzarny> yup
<MoeIcenowy> oh at first I will paste this: https://pastebin.anthonos.org/view/6b6beaee
<MoeIcenowy> this is a sid readout code based on sunxi-fel
<jski> [
<jski> I think there might be some samsung hardware lock on this microsd card
<MoeIcenowy> I currently have no sdcards flashed with system of zero...
<jski> it can be triggered by it running out of writes but I bet put with a bad psu ....
<KotCzarny> jski: yup, bad psu often results in mmc failure
<MoeIcenowy> KotCzarny: on opi zero, with fel readout, the value is 0x02c00042 0x34004620 0x5035c614 0x0439098e 0x02000067
<KotCzarny> one interesting thing is that 4620 showing on both your and mine
<KotCzarny> and in different position on sid's wiki page
<MoeIcenowy> the last byte of the first word is 0x42, identical to the code in H2+ BSP
<KotCzarny> (example: 02004620 94340508 502b0a8e 24000000 )
<MoeIcenowy> yes
<MoeIcenowy> it's interesting
<MoeIcenowy> it seems to be some shift
<MoeIcenowy> I compared my one's readout before register readout and after register readout
<MoeIcenowy> before is : 02004620 74358720 5027048e 3c0000c3 after is : 02c00081 74004620 50358720 3c27048e
<MoeIcenowy> and after got a OEM word of 0x000000c3
<MoeIcenowy> so I think without register readout we lost 3 bytes
<MoeIcenowy> which contains the H3 series chip idenfication byte
<MoeIcenowy> KotCzarnyL got it?
<MoeIcenowy> KotCzarny: ^
<KotCzarny> so you got that 02c00.. via fel twiddling? and without twiddling you get usual 02004620.. ?
<MoeIcenowy> I think the original design of Allwinner is to get the eFUSE value ready at 0x01c14200 at boot, however, their eFUSE controller has some bugs that makes the things a mess
<MoeIcenowy> KotCzarny: yes
<MoeIcenowy> I will try this code on A64
<KotCzarny> then that code should also go into sunxi-tools
<MoeIcenowy> It seems that A64 has 0x....4620 in its second byte
<MoeIcenowy> not in the first
<MoeIcenowy> maybe it's a bug only in H3
<KotCzarny> now if you could fireup mainlinux and compare
<MoeIcenowy> and the BSP did a full readout in u-boot
<KotCzarny> maybe all of that is just a bug in sunxi-tools
<MoeIcenowy> but abandoned the read value
<MoeIcenowy> maybe it's to workaround this bug
<MoeIcenowy> see arch/arm/cpu/armv7/sun8iw7/efuse.c, which abandoned the return value of sid_read_key
<MoeIcenowy> (oh I mean silicon bug
<MoeIcenowy> (not software bug
<KotCzarny> yes, it's what i based sid.c on
<KotCzarny> and why i wanted to confirm if it gets same output on mainline
<MoeIcenowy> yes I proved in A64 the register-based readout is not needed for right value
cnxsoft has quit [Quit: cnxsoft]
<MoeIcenowy> KotCzarny: could you provide a pastebin item that comes with both the bad value and the right value?
<MoeIcenowy> I want to send out a email for discussing the mainline policy to it
MXfive has joined #linux-sunxi
lemonzest has quit [Quit: Leaving]
msevwork has quit [Quit: Leaving]
<KotCzarny> MoeIcenowy: sure, in a moment
<MoeIcenowy> I will compose the email now
<MoeIcenowy> when you see it, could you reply it with your data?
<KotCzarny> i'm not on the list
deskwizard has joined #linux-sunxi
<MoeIcenowy> ok could you give me you email?
<MoeIcenowy> I will add you to "To:"
<MoeIcenowy> I think you should paticipate the discuss
leviathanch has joined #linux-sunxi
<KotCzarny> hmm
<KotCzarny> no output from your script
<MoeIcenowy> the fel version?
<KotCzarny> yes
<MoeIcenowy> oh I forgot to say
<MoeIcenowy> you should start a new bash process with root permission
<KotCzarny> im running as root
<KotCzarny> its in vm anyway
<MoeIcenowy> then use the "." or "source" to execute the script within the bash
<MoeIcenowy> then use sid_read_key function
<MoeIcenowy> the parameter is the offset in SID
<KotCzarny> syntax error
<KotCzarny> :)
<MoeIcenowy> ?!
<MoeIcenowy> Ah-oh
<MoeIcenowy> are you sure you're using bash?
<KotCzarny> bash 4.3.30
f0xx has quit [Ping timeout: 256 seconds]
<MoeIcenowy> do not execute with "sh", but "bash"
<KotCzarny> line 48
<montjoie> always use only '.', source is a bashisms
<montjoie> so . is portable:)
<MoeIcenowy> the script itself is bashism
<KotCzarny> :)
<MoeIcenowy> KotCzarny: can you run it now?
<KotCzarny> told you, syntax error
<MoeIcenowy> or you can try just add sid_read_key 0x0 after ths script
<MoeIcenowy> line 48 is a null line...
<KotCzarny> remove 2
<KotCzarny> i've added #!/bin/bash and a newline
<KotCzarny> so line 46 in your version
<MoeIcenowy> have you passed a parameter to sid_read_key?
<MoeIcenowy> it needs a number as parameter
<MoeIcenowy> (Yes I must admit my code is badly documented, no, not documented
<KotCzarny> usb error -7
<MoeIcenowy> check your usb connection, reset your board
<KotCzarny> nope, its fine with sunxi-fel ver
<MoeIcenowy> oh mysterious
<MoeIcenowy> maybe just reset the board will work...
<MoeIcenowy> FEL is easily to trap into some exception mode, which cannot be recovered without reset
<jelle> does anyone actually have their rootfs loaded with sunxi-fel?
|Jeroen| has quit [Ping timeout: 258 seconds]
<jelle> as in Linux
<MoeIcenowy> jelle: me, when debugging with A33 tablet
<jelle> MoeIcenowy: ahh, I got a bit annoying by switching my sd card all the time (with indeed an A33 tablet ;-) )
<jelle> usb OTG for serial is nice
<jelle> MoeIcenowy: was it easy to setup?
<zoobab_> +1
<MoeIcenowy> not too difficult
<zoobab_> even for uboot?
<MoeIcenowy> http://linux-sunxi.org/FEL/USBBoot#Booting_the_whole_system_over_USB_.28U-Boot_.2B_kernel_.2B_initramfs.29
<jelle> FEL boot with u-boot is easy
<KotCzarny> and after that i get error with sunxi-fel ver
<jelle> MoeIcenowy: ok hmm, only have to figure out the rootfs
<MoeIcenowy> KotCzarny: got it you still have no parameter passed into sid_read_key right?
<KotCzarny> ahm
<KotCzarny> k
<MoeIcenowy> jelle: note, the rootfs must be converted into u-boot format
<jelle> MoeIcenowy: ah ok
* jelle hopes I can fuse mount that
<MoeIcenowy> I failed for many time, just because of the reason
<KotCzarny> but i got error even when sourcing
<KotCzarny> scratch that.
<KotCzarny> got them one by one though: 0x02c00081 0x54004620 0x50354520 0x1033080e
<MoeIcenowy> KotCzarny: ok... maybe unaligned access is not allowed
<KotCzarny> and with my sid.c: EFUSE_CHIPID 02c00081 54004620 50354520 1033080e
<KotCzarny> root@debian64-t500v:~# sunxi-fel sid
<KotCzarny> 02004620:54354520:5033080e:10000000
<KotCzarny> so, definitely bug in sunxi-fel sid
<KotCzarny> bytes are funnily shifted as you see
<KotCzarny> ie 1033080e -> 33080e10
<MoeIcenowy> KotCzarny: believe me
<KotCzarny> and some are missing at the start
<MoeIcenowy> it's not a bug in sunxi-fel sid
<KotCzarny> bug as in 'missing feature'
<MoeIcenowy> in mainline kernel, if I just read 0x01c14200, I got 02004620
<KotCzarny> but to read sid on h3 and above one has to use allwinners method, not just plain read
<MoeIcenowy> and we generated a lot of MAC addresses for H3 boards with the wrongly read chipid
<KotCzarny> and that's wa bug
<MoeIcenowy> so it become a big problem
<MoeIcenowy> to fix, or not to fix, it's a question
reinforce has quit [Quit: Leaving.]
<MoeIcenowy> KotCzarny: not "above"
<MoeIcenowy> at least A64 fixed the issue
<KotCzarny> might be that only h3/h2+ suffers
<KotCzarny> and that mysterious h3d
<MoeIcenowy> we should say 0x1680 chips ;-)
<KotCzarny> a64 even has 4620 seen on h3
<KotCzarny> in the right place ;)
<MoeIcenowy> yes
<MoeIcenowy> I verified A64
<MoeIcenowy> with register access and direct memory access the value is the same
<KotCzarny> i think a33/r16 might be affected too
<KotCzarny> could you check it there?
<KotCzarny> and maybe a31s
<MoeIcenowy> their SID is at 0x01C23800
<KotCzarny> or just see in bsd if you have it unpacked if they have similar sid-read function
<KotCzarny> *bsp
<MoeIcenowy> but the values of A31s seems really strange
<MoeIcenowy> it starts with 0x1652
<MoeIcenowy> but A31 is 0x1633
<KotCzarny> scratch the a31* comment, check a33
<MoeIcenowy> but I will also show my question on A31.
<KotCzarny> also, did you add your a33 tablets to sid page?
<MoeIcenowy> yes
<MoeIcenowy> the Aoson one and the iNet one is both mine
<KotCzarny> both have 0 in 4th word
<MoeIcenowy> but NES mini have contents in the 4th word
<MoeIcenowy> naobsd reads out the value via fel
<MoeIcenowy> maybe I should get my script better now
<MoeIcenowy> and attach it to my mail
diego71_ is now known as diego71
<KotCzarny> yup, make it more error prone
<MoeIcenowy> KotCzarny: will your server be always online?
<MoeIcenowy> if not, I will try to find somewhere else to place your sid program
<KotCzarny> should be, unless power gets out for more than 4 hours
<KotCzarny> then battery backup will fail
<KotCzarny> but will restart on power back
<MoeIcenowy> I'm curious that is it an allwinner board ;-)
<KotCzarny> proudly running on bpi-r1!
<KotCzarny> ;)
<KotCzarny> i've added both sids to the wiki page, to see the funny byte shifts
<MoeIcenowy> ok I should also do it
leviathanch has quit [Remote host closed the connection]
f0xx has joined #linux-sunxi
leviathanch has joined #linux-sunxi
<KotCzarny> it's aAAA bBBB cCCC -> aBBB bCCC c000
<KotCzarny> and messed first word
<MoeIcenowy> not c000
<MoeIcenowy> on my boards the initial value of sid[4] is 3c0000c3
enrico__ has joined #linux-sunxi
<MoeIcenowy> because my "OEM value" is 0x000000c3
<MoeIcenowy> s/[4]/[3]
<KotCzarny> i should've written aAAA bBBB cCCC dDDD -> aBBB bCCC cDDD d000
<KotCzarny> and AAA is lost
<MoeIcenowy> I should've written not d000 but dEEE
<MoeIcenowy> EEE is from the "OEM value" of the eFUSE
<MoeIcenowy> on opipc you OEM value have 000 as EEE
<KotCzarny> on my opipc oem_program is 02000000
<MoeIcenowy> so this is the key
<KotCzarny> yup
<MoeIcenowy> on my opi1 it's 0x000000c3
<KotCzarny> imo it should be fixed then
techping has quit [Remote host closed the connection]
JohnDoe_71Rus has joined #linux-sunxi
<MoeIcenowy> mail written
chomwitt has joined #linux-sunxi
reinforce has joined #linux-sunxi
DullTube has quit [Quit: Leaving]
fdcx has quit [Ping timeout: 245 seconds]
apritzel has joined #linux-sunxi
<apritzel> KotCzarny: did you get the SID values via devmem2 on an aarch64 system on the Opi PC2?
<apritzel> KotCzarny: because I think that devmem2 is broken on 64-bit systems ...
<KotCzarny> i dont have opi pc2
<KotCzarny> only a20 and h3 based ones
<apritzel> KotCzarny: oh, because your Wiki commit speaks of "kc's opipc2" in the comments columns ...
<KotCzarny> that's opi+2e
<KotCzarny> :)
<KotCzarny> opi plus 2e
f0xx has quit [Ping timeout: 264 seconds]
<MoeIcenowy> apritzel: because he have two opipcs
<ErwinH> Maybe add an # ;)
<apritzel> so it should read "2nd opipc" then?
<KotCzarny> yup
<KotCzarny> sorry for the confusion, but its in h3 section anyway
<apritzel> KotCzarny: I get updates via RSS, and there is no section in this diff ;-)
<KotCzarny> anyway, sid mystery is at least partially solved for h3
<MoeIcenowy> KotCzarny: is your awdetect.php automatical?
chomwitt has quit [Quit: WeeChat 1.0.1]
<KotCzarny> if you press refresh it grabs wiki page and scraps data from it
chomwitt has joined #linux-sunxi
<KotCzarny> i mea n that link on page
<MoeIcenowy> and it seems that all your on the page is the wrong ones for H3?
<KotCzarny> thats becaudse ive added (wrongly) one override
<MoeIcenowy> you dropped the correct ones?
<KotCzarny> k, removed override. yup
<KotCzarny> even worse, change first word. but its removed now
cptG has joined #linux-sunxi
<MoeIcenowy> oh it might be interesting to test H5 ;-)
<apritzel> you guys could use my peekpoke, you can do stuff like: ./peekpoke -b 0x1c14200 r.l 0x0 r.l 0x4 r.l 0x8 r.l 0xc
<apritzel> and that works on 64-bit as well
<KotCzarny> apritzel: aw code does a lot more
<KotCzarny> and remembering all those defines is pain
<KotCzarny> with sid.c i just dump all known sid fields
fdcx has joined #linux-sunxi
<MoeIcenowy> yes H5 is also fixed
<MoeIcenowy> only H3/H2+ is found to be affected now
<KotCzarny> MoeIcenowy: if third byte in first word is 0 then its fixed probably
<KotCzarny> and that's why i was curious about a33
cptG_ has quit [Ping timeout: 260 seconds]
<MoeIcenowy> but A33 seems not to have a big eFUSE like H3...
<MoeIcenowy> I think it's still the old SID
<KotCzarny> maybe we should add more columns in sid page for newer socs, to dump oem value too
buZz has joined #linux-sunxi
buZz is now known as Guest98334
Guest98334 is now known as buZz
<KotCzarny> otoh, we can probably easily fix those wrong sids, because first word stays the same for h3 and last word is a free oem dump ;)
Christos has joined #linux-sunxi
ErwinH has quit [Remote host closed the connection]
<MoeIcenowy> KotCzarny: I'm not sure
<MoeIcenowy> the BSP lists two values for H3
<MoeIcenowy> 0x00 and 0x81
<MoeIcenowy> although all we seen is 0x81
<KotCzarny> took the wild guess and put 02c00081 for now
<KotCzarny> to see if it unmangled them at least for my opipcs
buZz has quit [Ping timeout: 260 seconds]
<KotCzarny> yup
apritzel has left #linux-sunxi [#linux-sunxi]
tucker has joined #linux-sunxi
<tucker> I see a discussion about the SID value and that it seems that it's the devmem2 method that actually gives correct values. My http://linux-sunxi.org/HYH-TBH3 gives 2C00081 4620 51900618 A058E187 by devmem2 method (with an orangepi 3.4 image on the SD card)
<KotCzarny> you shouldnt omit 0's
<KotCzarny> also, go ahead and add it to the list (with method in notes)
<MoeIcenowy> tucker: please add 0 to your sid values before the number to make it to have a width of 8
<MoeIcenowy> so 02C00081 00004620 51900618 A058E187
<KotCzarny> and i think my other opipc sid dump might be wrong, gotta redo when i have it in my hands
ErwinH has joined #linux-sunxi
buZz has joined #linux-sunxi
buZz is now known as Guest82886
Guest82886 is now known as buZz
ErwinH has quit [Ping timeout: 240 seconds]
<Christos> apritzel: (or anyone who might know) is there any info on how to use those two repos mentioned before for OPiPC2 and produce a working image? (I'm kinda new.. :-)) )
<MoeIcenowy> wrote a fixed H3 SID sunxi-fel branch
ganbold has quit [Ping timeout: 240 seconds]
netlynx has joined #linux-sunxi
yann-kaelig has quit [Quit: Leaving]
<MoeIcenowy> KotCzarny: could you do an experiment?
<MoeIcenowy> will the SID at 0x01c14200 become ok with just one read operation?
<MoeIcenowy> (one read operation by registers)
<KotCzarny> if it doesnt explode, sure
<KotCzarny> please explain exact steps
<KotCzarny> ie. boot os, then just read 0x01c14200 ?
<KotCzarny> without any locking etc ?
<MoeIcenowy> yes
<MoeIcenowy> yes
<KotCzarny> isnt that what devmem does?
<MoeIcenowy> oh no
<MoeIcenowy> I mean
<MoeIcenowy> do one read by using 0x01c14040
<MoeIcenowy> then check whether the value at 0x01c14204 is right
<KotCzarny> btw. aw code does some waiting on reading register before actually reading
<KotCzarny> so it might be some async communication iwth internal logic
<KotCzarny> and locking is there because its not safe when multiple things would set the register
<KotCzarny> so while it MIGHT work, it could be unstable
<MoeIcenowy> it seems to be waiting for the operation to be done
<MoeIcenowy> I did the wait.
<jski> is the 40pin connector on the opi+2 the same as the raspi?
<MoeIcenowy> not so same
matthias_bgg has quit [Quit: Leaving]
matthias_bgg has joined #linux-sunxi
<jski> explains why I killed the emmc XD
<wens> jski: never assume stuff about hardware, the stakes are much higher :)
<jski> I checked all the voltages and ground pins and that uart 3 worked :D
<jski> just after connecting to gpio it kinda failed :D
<tucker> KotCzarny: MoeIcenowy: Done
Andy-D_ has joined #linux-sunxi
<MoeIcenowy> wens: could you add your M2 Ultra's SID to SID_Register_Guide ?
<MoeIcenowy> KotCzarny: you should fill H2+'s SID with 0x..c00081 .
<MoeIcenowy> s/should/shouldn't/g
<jski> oh I see what I grounded now :D
<KotCzarny> MoeIcenowy: until someone can provide proper sid, hard to guess what to put there
<MoeIcenowy> I will try
<MoeIcenowy> 02c00042:34004620:5035c614:0439098e is my opi zero
<MoeIcenowy> it's also one of the zeros on the wiki page
<KotCzarny> also, doing: reg_val |= (key_index<<16) | 0x3; writel(reg_val, SID_PRCTL); reg_val = readl(SID_RDKEY);
<KotCzarny> resulted in proper value
<KotCzarny> though i should read it not form sid_rdkey, right?
<KotCzarny> *from
<MoeIcenowy> I think both is ok
<KotCzarny> humm
<MoeIcenowy> KotCzarny: my zero's sid is fixed
<KotCzarny> but i'm running it on the legacy kernel
<KotCzarny> so it was proper value anyway
<jski> works now when I actually use a gpio pin XD
<jski> why they not following the same 40pin design :(
<jski> was hoping it would be a standard
<MoeIcenowy> as they're not the same SoC.
<MoeIcenowy> oh your code do not have the lock...
<MoeIcenowy> and when I try to use the read code in U-Boot, it failed...
<MoeIcenowy> when trying to write EFUSE_OP_LOCK to SID_PRCTL
<MoeIcenowy> or I should say it blocked...
<KotCzarny> it does thje SID_OP_LOCK
<KotCzarny> in sid_read_key
<KotCzarny> because that's what aw code had
<MoeIcenowy> oh I think I met some bugs in gcc
<MoeIcenowy> the previous time when I met the bug is when testing jernej's hdmi driver
<KotCzarny> i've used gcc 4.6 i think, from bsp
Amit_T_ has joined #linux-sunxi
<KotCzarny> yeah, 4.6.3 20120201 linaro
<MoeIcenowy> my homebrew 4.9 sucks
chomwitt has quit [Ping timeout: 245 seconds]
<MoeIcenowy> and I tried with linaro 6.1, then ok
lkcl has quit [Ping timeout: 246 seconds]
<KotCzarny> there is also 'sid_security_mode()' in efuse.c
<KotCzarny> i wonder what it would change, or what would stop working
<KotCzarny> and again, there is no EFUSE_OP_LOCK in efuse.c
<MoeIcenowy> it may be the secure boot feature said by dgp
<KotCzarny> SID_OP_LOCK is 0xAC
matthias_bgg has quit [Ping timeout: 265 seconds]
<Christos> hmm.. interesting, no-one knows how to use apritzel's H5 repos..
The_Loko has joined #linux-sunxi
massi has quit [Quit: Leaving]
<libv> Christos: i tried some rockchip stuff a few weeks ago, it was amazing.
<libv> the sunxi wiki is a blessing.
<libv> but not everyone seems to think so, not everyone seems to want users.
<Christos> I'm interested in the H5 and it looks apritzel has done quite some work there, but need info on how to generate an image out of his repos, interestingly didnt saw much replies from others, so it seems I need to wait for apritzel directly to see the backlog..
Mr__Anderson has quit [Remote host closed the connection]
ErwinH has joined #linux-sunxi
<willmore> Christos, I'll be intereseted in that status in a little over a week when I get back home from travel.
ErwinH has quit [Ping timeout: 250 seconds]
<[TheLinuxBug]> libv: I constantly praise linux-sunxi and your guys work, I know that there are people out there taht do greatly appriciate all your guys work ;)
techping has joined #linux-sunxi
enrico__ has quit [Quit: Bye]
chomwitt has joined #linux-sunxi
<willmore> tkaiser, can you post higher res scans of the NAS board? I'm trying to see how signals are routed.
Pepe has joined #linux-sunxi
techping has quit [Remote host closed the connection]
techping has joined #linux-sunxi
Amit_T_ has quit [Quit: ChatZilla 0.9.93 [Firefox 46.0.1/20160511224619]]
heffer has quit [Ping timeout: 258 seconds]
heffer has joined #linux-sunxi
Ntemis has joined #linux-sunxi
techping has quit [Remote host closed the connection]
techping has joined #linux-sunxi
iamfrankenstein has quit [Read error: Connection reset by peer]
iamfrankenstein has joined #linux-sunxi
terra854 has quit [Quit: Connection closed for inactivity]
apritzel has joined #linux-sunxi
noblock has joined #linux-sunxi
noblock has quit [Client Quit]
noblock has joined #linux-sunxi
<noblock> One question - Do you know how to install the apritzel's h5 branch on a SD card? I tried: dd if=orangepi_pc2-u-boot-dtb.bin of=/dev/mmc bs=1024c seek=8; And the board don't start anymore...
<KotCzarny> wrong file?
<noblock> Do you know the right one?
<KotCzarny> usually something with spl in name
<noblock> The makefile don't generate any spl bin with the H5 config - Maybe something is missing.
<KotCzarny> also, try bs=1024
MXfive has quit [Quit: Sleep Quit.]
<noblock> OK I will try. Thanks.
<KotCzarny> also, you can try booting via fel mode
<KotCzarny> so you dont have to write sd card
<noblock> Is this a non spl bin with the FEL mode?
<KotCzarny> and most importantly, do you have uart cable?
<noblock> Yes I have the RS232 cable.
<noblock> OK.
<KotCzarny> ejecting sdcard should trigger fel mode
<KotCzarny> (assuming there is nothing on nor flash)
<noblock> To be sure - I've used: make CROSS_COMPILE=aarch64-linux-gnueabihf-; The H5 start using the aarch64 mode - Is this right?
<KotCzarny> maybe you need ARCH=something too
<noblock> And the 32 bits mode arm-linux-gnueabihf- ?
<KotCzarny> you should ask author in which mode this thing should work
<KotCzarny> or try both
<noblock> Indeed, an update of the Orange PC 2 page is welcome.
<KotCzarny> and as i've said, for 32bit mode try adding ARCH=arm
<apritzel> noblock: unfortunately it's a bit more complicated
<apritzel> noblock: you have to concatenate spl/sunxi-spl.bin and u-boot.bin
<apritzel> with the second starting at 32KB after the first
<noblock> And how to generate the sunxi-spl.bin file?
<apritzel> it should be in the spl directory?
<noblock> OK.
<noblock> Is the aarch64 mode the right one to generate the .bin file?
<apritzel> yes, for now
<apritzel> if you enable more SPL features, it grows too big
<apritzel> that's why you can combine a 32-bit SPL with a 64-bit u-boot.bin
<apritzel> oh, you have to use u-boot.img, not .bin
<apritzel> (if you concatenate)
<apritzel> but the problem is that this still doesn't give you the full glory
<apritzel> because you miss ARM Trusted Firmware
<apritzel> FEL booting works fine with this, though
<Christos> apritzel: can you please give us some info on how to generate the various needed parts of your H5 repos in order to have a bootable SD? or to update the PC2 build sunxi page?
<apritzel> Christos: yes, when I find some time ...
<Christos> ok ..
<apritzel> for FEL booting you can follow those instructions: http://lists.denx.de/pipermail/u-boot/2016-December/276361.html
<apritzel> that's for the Pine64, but works on the H5 as well
techping has quit [Remote host closed the connection]
techping has joined #linux-sunxi
<MoeIcenowy> apritzel: is ATF still needed?
<MoeIcenowy> how to insert it?
<apritzel> afk for a while ...
yann-kaelig has joined #linux-sunxi
Christos has quit [Quit: Page closed]
MXfive has joined #linux-sunxi
<noblock> An other issue - I tried to compile everyting now at the u-boot level and SOCID_H5 is not defined. Do you have the #define SOCID_H5 ?
ErwinH has joined #linux-sunxi
techping has quit [Ping timeout: 265 seconds]
ErwinH has quit [Ping timeout: 260 seconds]
<noblock> Is this right: #define SOCID_H5 0x1718 ?
JohnDoe_71Rus has quit [Quit: KVIrc 4.9.2 Aria http://www.kvirc.net/]
Mr__Anderson has joined #linux-sunxi
<apritzel> noblock: oh, is it missing?
<apritzel> yes, 0x1718 is right
<apritzel> I think I had it in the A64 patch first by mistake and removed it from there (without putting it back again)
<noblock> Yes, indeed.
iamtl has joined #linux-sunxi
<apritzel> yeah, right, sorry for that ...
<apritzel> MoeIcenowy: so why do you say "still"?
<beeble> something new und unfamiliar, it should go away!
<beeble> >(
<beeble> :)
<beeble> damn it wrong keyboard layout
iamtl has quit [Client Quit]
<apritzel> noblock: fix is pushed
<apritzel> beeble: I suspect it's because it says "firmware", which for some reason makes people scream and run away
<apritzel> also unfortunately ARM chose to call it "Trusted", which according to common belief means the opposite
reinforce has quit [Quit: Leaving.]
<beeble> apritzel: you should tell this your marketing guys :)
<beeble> but they probably have another market share in mind while defining it
<apritzel> it's just marketing guys, they can't help coming up with those term
<beeble> TPM didn't help with the trusted term in computing
<beeble> scorched earth left behind
<apritzel> although even TPM is better than its reputation
<beeble> totally with you
<beeble> but since i have implemented secure boot on devices running linux i shouldn't talking maybe. this would fall in the category tivoization
<apritzel> beeble: you even dared to say that other bad word: "secure" ;-)
<beeble> the marketing term is therefore high assurance boot
<apritzel> MoeIcenowy: so what is your problem with ATF? The only thing I can go with is that's another piece of software
<apritzel> beeble: which will spoil the term "assurance" as well ...
netlynx has quit [Quit: Ex-Chat]
Mr__Anderson has quit [Ping timeout: 240 seconds]
<beeble> apritzel: you run everything in el3 for now, right?
<apritzel> beeble: ATF? yes
<apritzel> in fact it's only bl31 that's used
<beeble> but uboot in el2?
<apritzel> theoretically one could implement the SPL functionality in ATF as well
<apritzel> bl31 drops into the bootloader payload in EL2, yes
<apritzel> because U-Boot is only a boot loader
<apritzel> and as such has no need to run in any kind of secure mode
<beeble> since it's fully replaced afterwards i don't see a reason either
<apritzel> and actually U-Boot is only one of the possible bootloaders
<apritzel> serious machines have UEFI instead, for instance
heffer has quit [Ping timeout: 240 seconds]
<apritzel> or EDK2, actually
<apritzel> but this has its own set of problems, so U-Boot is fine, especially since it now starts to support EFI
heffer has joined #linux-sunxi
<beeble> i'm still not sure about the benefits of tianocore on armv8. but i haven't looked any deeper into it
<beeble> first of all it's something new for me and therefore i don't like it :)
Mr__Anderson has joined #linux-sunxi
<beeble> no serious, i have to read up to have a opinion
<MoeIcenowy> apritzel: how to inject ATF into the u-boot-spl then u-boot chain?
<MoeIcenowy> to be honest, I want the functions of ATF to be merged into u-boot
<MoeIcenowy> just like what happened on PSCI on sun8i
<apritzel> argh, that's the wrong branch
<apritzel> MoeIcenowy: why?
<MoeIcenowy> to simplfy the boot chain
<apritzel> MoeIcenowy: ATF is the reference implementation of PSCI
lkcl has joined #linux-sunxi
<apritzel> and ATF provides more than just PSCI
<MoeIcenowy> and keeps u-boot-sunxi-with-spl.bin generatable
<apritzel> it has errata workarounds, for instance
<apritzel> MoeIcenowy: well, this is not Kansas anymore, I guess
<apritzel> if that helps, I can provide a binary version of bl31.bin for download
<apritzel> so you can easily integrate it
<apritzel> in some build instructions
<apritzel> or rather build scripts / Makefile rules
<apritzel> seriously I don't understand why people want desperately to rebuild everything every time, but then complain about the complexity
<apritzel> and frankly: ATF is easy and very quick to build
<apritzel> it lives on github, so it's easily available
<apritzel> and it's Open Source as well
<MoeIcenowy> does ATF have a mainlining community just like u-boot or linux?
<apritzel> also it's maintained and tested
florianH has quit [Quit: Connection closed for inactivity]
<apritzel> MoeIcenowy: as in: "it takes one year to get things upstream"?
<MoeIcenowy> what we are doing is trying to get things upstream.
<apritzel> so?
<apritzel> if my day would have 28 hours, I'd upstream ATF as well
<MoeIcenowy> I do not want something critical to be kept out-of-upstream
<apritzel> actually this is getting higher priority on my list
Ntemis has quit [Remote host closed the connection]
<apritzel> MoeIcenowy: be my guest ...
<MoeIcenowy> can a BL31-only implementation be really upstreamed?
<apritzel> sure
<apritzel> it's an officially supported model, AFAIK
<apritzel> and there is another vendor doing so
<MoeIcenowy> which vendor?
<apritzel> forgot, but I think it was Mediatek
lkcl has quit [Ping timeout: 250 seconds]
lkcl has joined #linux-sunxi
<apritzel> MoeIcenowy: you do have a R40 board, don't you?
<apritzel> and there is no blob-free DRAM support yet?
florianH has joined #linux-sunxi
<MoeIcenowy> apritzel: I do.
<MoeIcenowy> there's code, but dirty license
Mr__Anderson has quit [Remote host closed the connection]
<apritzel> well, if you send me a dump of the DRAM registers after boot0 (from the U-Boot prompt), I can try to create something
<MoeIcenowy> do you mean that it's now the time for me to learn some DRAM knowledge? ;-)
<apritzel> save your time, we lost already too many people to it ...
<MoeIcenowy> maybe not now...
<apritzel> do we know if the DRAM controller is close to the A20 one or to the newer ones (H3 & friends)
<apritzel> ?
<MoeIcenowy> to the newer ones
<MoeIcenowy> I said there's dirty licensed code
<apritzel> which I don't look at
<apritzel> for exactly that reason
<apritzel> but the H3/A64 DRAM stuff is still in my "cache"
<apritzel> so I could compare register dumps and do something along the lines of the H5 support patch, for instance
<MoeIcenowy> at what address should I dump?
<apritzel> just a sec ...
<MoeIcenowy> wens did something, but he failed to enable full 2G dram
phipli has joined #linux-sunxi
<MoeIcenowy> only 1G is recognized
<MoeIcenowy> and I think there's something interesting about SID now...
<MoeIcenowy> AXP221 seems to have a SID
<MoeIcenowy> and R40 have also a SID
<apritzel> jemk: yeah, or do it like this ;-)
Pepe has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
<phipli> tinytinytiny
<apritzel> phipli: tiny usually translates into noisy ...
<phipli> heh
<phipli> haven't tried them yet
<phipli> I'll see if I can see something with 5v out...
<noblock> apritzel: Now u-boot seems to start, but the rs232 output is not at 115200n1. A clock issue?
<apritzel> noblock: just a sec, testing this on my board
MXfive has quit [Quit: Sleep Quit.]
MXfive has joined #linux-sunxi
Pepe has joined #linux-sunxi
<phipli> you wouldn't hear it across the room, but it would be irritating if you were sat next to it
<phipli> mostly mechanical noise
<phipli> rather than air
<apritzel> noblock: works for me with FEL booting
<apritzel> noblock: going to test SD card now
deskwizard has quit [Ping timeout: 258 seconds]
<apritzel> yeah, SD card is weird, probably really missing some clock setup without ATF
ErwinH has joined #linux-sunxi
leviathanch has quit [Remote host closed the connection]
ErwinH has quit [Ping timeout: 265 seconds]
lkcl has quit [Ping timeout: 250 seconds]
tucker has quit [Quit: -]
<apritzel> noblock: so what is your setup, exactly? SD card with a pure 64-bit build?
jernej has joined #linux-sunxi
Da_Coynul has joined #linux-sunxi
Pepe has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
phipli has quit [Remote host closed the connection]
[TheLinuxBug] has quit [Ping timeout: 248 seconds]
TheLinuxBug has joined #linux-sunxi
The_Loko has quit [Quit: Leaving]
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
cptG_ has joined #linux-sunxi
cptG has quit [Ping timeout: 264 seconds]
Da_Coynul has joined #linux-sunxi
jernej has quit [Ping timeout: 265 seconds]
<noblock> apritzel: Now I'm cross-compiling on a x86_64. I have both cross-compiler: arm-linux-gnueabihf-gcc and aarch64-linux-gnueabihf-gcc ready.