<shadeslayer>
oh that's ok, I don't need the ethernet bits
<shadeslayer>
I will be booting via the microsd card
<shadeslayer>
just not sure which file to flash to the microsd card though and what offset
<MoeIcenowy>
ATF support is necessary now
<shadeslayer>
oh :(
<shadeslayer>
ok
<shadeslayer>
let me try that then
<shadeslayer>
MoeIcenowy: where do I need to put the bl131.bin?
<MoeIcenowy>
I think it's bl31.bin
<shadeslayer>
I get FATAL ERROR: Couldn't open "bl31.bin": No such file or directory
<shadeslayer>
right :)
<shadeslayer>
where do I need to put that in the source tree?
<MoeIcenowy>
put it right under your source code
<shadeslayer>
ok
<oliv3r>
wens: on the lime2, it turns the 3.3 and 5V power on/off
<MoeIcenowy>
oliv3r: is it an GPIO?
<oliv3r>
we ran into a problem here, that some combinations (gcc/kernel/module) not sure what it is, turns off the ext-en pin of the PMIC on reboot (it always does on power off)
<oliv3r>
MoeIcenowy: no, but yes
indy has joined #linux-sunxi
<oliv3r>
it behaves like one I guess, but only output
<MoeIcenowy>
an axp gpio?
<oliv3r>
but the axp manual calls it 'ext-en' and its in the table of dc-dc and ldo on/off
<oliv3r>
wens: My next step was to get a binary with the bug, and trace out the i2c-0 data, see how it gets powered off; via the pin itself, or via a full pmic shutdown
<shadeslayer>
MoeIcenowy: flashing without the K just gives me a CPU reset on UART
<shadeslayer>
<MoeIcenowy>
please flashing without the bonus K.
<MoeIcenowy>
flash with it just puts your binary at wrong position
<shadeslayer>
MoeIcenowy: is he even in this channel? :P
<MoeIcenowy>
oh he's not here...
<MoeIcenowy>
hope that he can see this
<shadeslayer>
:)
<oliv3r>
wens: ah, ok. well i think it's a hardware bug tbh. U-boot should always be able to bring a board up. If some OS, for whatever reason disables ext-en and reboots, u-boot can never bring the board back up, because it can't talk to the axp anymore
<oliv3r>
wens: yeah so my first thought was to properly define the ext-en switch, and not leave it completly undefined
chlorine_ has quit [Remote host closed the connection]
<wens>
oliv3r: well if you can't talk to the pmic, then you're not going to be able to bring it back anyway, even if you define exten
<MoeIcenowy>
oliv3r: maybe this situation should be reported to Olimex
<oliv3r>
wens: exactly, HW bug :p a board should have a tiny ldo to supply the 3.3v for the i2c bus
<oliv3r>
MoeIcenowy: i have :) they trying to understand the problem however :)
komunista has joined #linux-sunxi
chlorine has joined #linux-sunxi
<wens>
you should figure out why its getting disabled
<oliv3r>
but to fix it in software, which we only can do for linux really
<oliv3r>
wens: i agree
<wens>
it's bit 0 of register 0x12
<oliv3r>
but in my path to figuring it out, I figured it might as well be defined
<oliv3r>
wens: yeah, or, the power_off bit of er
<beeble>
what axp are you talking about? because most are used with RSB that is push-pull
<oliv3r>
axp209
<oliv3r>
which is still quite a common axp :)
<oliv3r>
and doesn't have rsb
<oliv3r>
but erm the other is bit7 of reg32
chomwitt has joined #linux-sunxi
<beeble>
i see
<wens>
oliv3r: that's the "power off" switch
<oliv3r>
wens: yeah, i first thought it would be in that call; but alas
<oliv3r>
anyhow, first i have to reproduce my setup for 5 weeks ago
<oliv3r>
and I don't even know if u-boot is involved in any way
cnxsoft has quit [Remote host closed the connection]
chlorine has quit [Remote host closed the connection]
<oliv3r>
before my holiday I spend most of the time pinpointing the problem (scope/multi-meter on pins to see why i was only getting a few letters of the SPL)
chlorine_ has joined #linux-sunxi
chlorine_ has quit [Remote host closed the connection]
yann-kaelig has joined #linux-sunxi
<shadeslayer>
so, another question, when booting off a microsd card, what file does uboot read? because I put a boot.cmd in the first partition
<shadeslayer>
and it doesn't seem to read that and starts poking the network
BenG83_PB has quit [Remote host closed the connection]
Pepe has quit [Read error: Connection reset by peer]
chlorine has quit []
Pepe has joined #linux-sunxi
BenG83_PB has joined #linux-sunxi
<shadeslayer>
BenG83_PB: any ideas?
<MoeIcenowy>
shadeslayer: boot.scr
<MoeIcenowy>
a translated format from boot.cmd
<shadeslayer>
oh ok
<shadeslayer>
MoeIcenowy: would it search in /boot/ ?
<MoeIcenowy>
I don't know...
<MoeIcenowy>
I usually put boot.scr directly at the root of my first VFAT partition
<shadeslayer>
ok :)
<MoeIcenowy>
mkimage -C none -A arm -T script -d boot.cmd boot.scr # the command that convert boot.cmd to boot.scr
<MoeIcenowy>
P.S. How do you finally solved the exception in SPL?
reinforce has quit [Quit: Leaving.]
JohnDoe_71Rus has joined #linux-sunxi
fl_0 has quit [Ping timeout: 240 seconds]
reinforce has joined #linux-sunxi
<shadeslayer>
MoeIcenowy: I didn't, I used the boot0 method
<shadeslayer>
boot0 + uboot 2017.03 rc
fl_0 has joined #linux-sunxi
BenG83_PB has quit [Quit: Leaving]
iamfrankenstein has joined #linux-sunxi
BenG83 has joined #linux-sunxi
matthias_bgg has quit [Quit: Leaving]
dave0x6d has joined #linux-sunxi
vinimac has joined #linux-sunxi
vishnup has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
msevwork has quit [Quit: Leaving]
LargePrime has quit [Ping timeout: 255 seconds]
<shadeslayer>
MoeIcenowy: what's the kernel from sunxi that I should use for the Pine64 ?
<shadeslayer>
for some reason booting with setenv bootargs console=ttyS0,115200 root=/dev/mmcblk0p1 rw doesn't work
Pepe has quit [Read error: Connection reset by peer]
<MoeIcenowy>
at least you should use linux-next or 4.11-rc
Pepe has joined #linux-sunxi
<ssvb>
jemk: about the TOC0 header, how many of its data structures are required by the BROM? also is the bootloader code initially started in the 32-bit mode too?
<MoeIcenowy>
jernej, mripard, wens: I think I should push some simplefb nodes dt patches for DE2 before real support landing in mainline U-Boot...
<MoeIcenowy>
as it's kind of binding of usable graphics hardware...
lemonzest has quit [Quit: Leaving]
LargePrime has joined #linux-sunxi
leviathancn has quit [Ping timeout: 240 seconds]
swiftglitch has quit [Ping timeout: 268 seconds]
leviathancn has joined #linux-sunxi
fkluknav has quit [Ping timeout: 240 seconds]
akaizen has quit [Ping timeout: 276 seconds]
<jemk>
ssvb: 32-bit mode, yes. the header field names are from debug information from their creation tool, so i don't know exactly what they mean.
<jemk>
ssvb: the main magic and the ids are what the brom is using to detect the toc0 and distinguish the code/certificate
netlynx has joined #linux-sunxi
<ssvb>
jemk: thanks, we could experiment with it a bit and update the wiki page
leviathancn has quit [Read error: Connection reset by peer]
<ssvb>
jemk: I can finally solder an UART header to my Jide Remix Mini box PCB and play with it a bit :-)
<jemk>
ssvb: offset and length are obviously used, and the run address is used to copy the code to. all other fields i don't know
IgorPec has quit [Ping timeout: 240 seconds]
<ssvb>
too bad that it is not backwards compatible with the eGON.BT0 header
<ssvb>
WTF were they thinking?
<jemk>
ssvb: the strangest thing i wonder about is, why the hell did they use non-standard asn.1 encoded certificates and then ignore everything except the crucial parts, instead of just using some fixed length binary structures? (they expect fitting lengths in asn.1 anyways)
<willmore>
beeble, FWIW as of last November sigrok supports protocol decoding for dual-SPI on FLASH.
IgorPec has joined #linux-sunxi
<ssvb>
jem: would it make sense for board manufacturers to actually blow this efuse before selling the A64 boards? is it possible to write the private key there later if needed?
fkluknav has joined #linux-sunxi
<ssvb>
if we end up having some boards in the wild booting only eGON.BT0 bootloaders, and the others booting only TOC0, then it's a freaking mess
<jemk>
ssvb: i think keys can still be written, and if there isn't any lock bit they even can be 'deletet' again by writing them to all ones
<jemk>
making it useless in terms of true secure boot
leviathancn has joined #linux-sunxi
<jemk>
ssvb: and it increases boot time before spl quite a bit, so probably not the best idea to enable it all the time
leviathancn has quit [Client Quit]
<ssvb>
how big is this boot time increase?
<ssvb>
in fact, I was actually thinking about maybe making a bootable SD card image for sunxi-tools, which could be used to blow this efuse to "fix" nonconforming boards
<ssvb>
then U-Boot could only care about supporting just TOC0
IgorPec has quit [Ping timeout: 240 seconds]
Andy-D has joined #linux-sunxi
leviathancn has joined #linux-sunxi
<jemk>
i haven't measured the time, so add a might increase ;)
<ssvb>
btw, can we maybe change the boot order via efuse (prefer SPI over MMC)? this would be a nice feature
<ssvb>
of course if they implemented something like this in the BROM
<jemk>
i don't think so, there are some efuse bits switching things (like software sha256 instead of ce), but the bootorder look fixed
fkluknav has quit [Ping timeout: 260 seconds]
<jemk>
also, fel only is non-secure, which can be switched by smc, but i didn't succeed in returning back to fel after that switch, which could make our fel uboot a bit hard
<ssvb>
so a signed bootloader is the right way to ensure booting it from eMMC/SPI and a measure to safeguard against rogue bootloaders on SD cards
<MoeIcenowy>
ssvb: I don't think keeping in secure mode a good opinion
cubietruck_user has quit [Quit: Page closed]
<ssvb>
jemk: but FEL boot still works fine if we have a 32-bit SPL running in non-secure mode, right?
<jemk>
yes, as long as spl doesn't access secure-only things
<ssvb>
64-bit SPL brings us nothing other than code size problems
<ssvb>
which secure things would that be? reading SID?
<ssvb>
can we still access PMIC and initialize DRAM?
<jemk>
sid, sram a2, smta, maybe some r_*, ...
<jemk>
dram works, since i only tried on h3 -> no idea about pmic
<MoeIcenowy>
r_rsb is defaultly non-secure
<MoeIcenowy>
but can be switch to secure
<ssvb>
FEL boot only needs DRAM to load data into it, switching to the secure mode can be done right after that
<ssvb>
but we really need to access PMIC before initializing DRAM if we care about reliability on the Pine64 board
<jemk>
we can always do a switch to secure and switch back before returning if we would need it i think
<ssvb>
but you are saying that FEL is broken after switching back?
<ssvb>
well, maybe we can try to fix/workaround this
<jemk>
not if switching back, only if returning in secure mode
<ssvb>
ok
<ssvb>
does secure peripheral access toggling only work after booting via TOC0?
f0xx has quit [Ping timeout: 240 seconds]
<jemk>
it works as soon as the secure fuse is burned, from storage and in fel, without the fuse it doesn't work
<jemk>
i haven't found anything the brom would do to make it work, so maybe it really is the fuse
akaizen has joined #linux-sunxi
<MoeIcenowy>
jemk: do you have the sBROM dump and compared with normal BROM?
<jemk>
MoeIcenowy: its completely different and much bigger (~35KiB) and doesn't contain fel code
chlorine has joined #linux-sunxi
<jemk>
the switch back to the normal brom for fel
<ssvb>
I guess, MoeIcenowy probably means that the sBROM could toggle some magic bits in some HW registers to make the secure peripherals work properly
reinforce has joined #linux-sunxi
<ssvb>
and this could make the difference that we are observing
<ssvb>
do we have a comparison of a complete dump of all HW registers between eGON.BT0 and TOC0 boot?
BenG83 has quit [Quit: Leaving]
<jemk>
they write to a lot of sysctrl bits, i tried some, but they didn't have the desired effect, most look more like some debugging, counting upwards after each step, setting bits depending on taken branches and so on
<jemk>
didn't try dumping more than sysctrl yet
vinimac has quit [Quit: Saindo]
nove has joined #linux-sunxi
LargePrime has quit [Ping timeout: 260 seconds]
jernej has joined #linux-sunxi
jernej has quit [Client Quit]
jernej has joined #linux-sunxi
jernej has quit [Read error: Connection reset by peer]
jernej has joined #linux-sunxi
jernej_ has joined #linux-sunxi
jernej has quit [Ping timeout: 268 seconds]
LargePrime has joined #linux-sunxi
swiftglitch has joined #linux-sunxi
jernej_ has quit [Quit: Konversation terminated!]
simosx has joined #linux-sunxi
jernej_ has joined #linux-sunxi
jernej has joined #linux-sunxi
<jernej>
MoeIcenowy: Why would you like to push simplefb patches? There will be no simplefb with DM video driver
jernej_ has quit [Ping timeout: 260 seconds]
jernej has quit [Quit: Konversation terminated!]
jernej has joined #linux-sunxi
<ssvb>
jernej: will efifb be used instead?
<jernej>
ssvb: I'm not really sure how everything works, but that's the idea. Is there any other platform which uses simplefb?
<jernej>
anyway, I would prefer that DE2 bits are included in DT before I write driver, but this obviously won't happen
<ssvb>
jernej: is there anything that you need from the DT that can't be derived from the SoC type? other than the LCD type and resolution.
<jernej>
ssvb: No, but there is a lot of different details for different SoCs
popolon has quit [Ping timeout: 255 seconds]
<jernej>
ssvb: For example, H5 and H3 doesn't have TCON1 gating/reset, but A64 and A83T do
<jernej>
ssvb: similary, HDMI is on TCON0 for A series, but on TCON1 for H series
<jernej>
ssvb: which leds to pretty ugly ifdefs
<jernej>
ssvb: Maybe I will try with platform data with DM, at least until DT bits land
<jernej>
ssvb: So there will be ifdefs only on one place
massi has quit [Remote host closed the connection]
f0xx has joined #linux-sunxi
BenG83_PB has joined #linux-sunxi
<ssvb>
jernej: you can avoid ugly ifdefs if you use the IS_ENABLED macro - http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/mtd/spi/sunxi_spi_spl.c;h=a24c115174177792b3bb65c1d21f30076859bf94;hb=HEAD#l165
<jernej>
yes, but invoking DM driver means either by DT or by hand with special structs which gets in special sections, so platform data doesn't add much
<jernej>
ah, how should I say it
<jernej>
DM driver can be invoked by DT or by hand
chlorine has quit [Remote host closed the connection]
<jernej>
and that "by hand" can't be done in code
<jernej>
so ifdefs are only way till DT bits land
IgorPec has joined #linux-sunxi
IgorPec has quit [Client Quit]
wzyy2 has quit [Ping timeout: 255 seconds]
IgorPec has joined #linux-sunxi
<jernej>
ssvb: by hand means using U_BOOT_DEVICE() macro
leviathancn has quit [Remote host closed the connection]
yann-kaelig has quit [Quit: Leaving]
swiftglitch has quit [Read error: Connection reset by peer]
vishnup has quit [Ping timeout: 255 seconds]
swiftglitch has joined #linux-sunxi
BenG83_PB has quit [Remote host closed the connection]
wzyy2 has joined #linux-sunxi
BenG83_PB has joined #linux-sunxi
wzyy2 has quit [Read error: Connection reset by peer]
swiftgeek2 has joined #linux-sunxi
igraltist has quit [Read error: Connection reset by peer]
igraltist has joined #linux-sunxi
swiftglitch has quit [Ping timeout: 255 seconds]
swiftgeek2 is now known as swiftglitch
Andy-D has quit [Ping timeout: 260 seconds]
afaerber has quit [Quit: Leaving]
wzyy2 has joined #linux-sunxi
igraltis1 has joined #linux-sunxi
igraltist has quit [Ping timeout: 260 seconds]
wzyy2 has quit [Read error: Connection reset by peer]
chlorine has joined #linux-sunxi
wzyy2 has joined #linux-sunxi
chlorine has quit [Ping timeout: 240 seconds]
netlynx has quit [Quit: Ex-Chat]
wzyy2 has quit [Read error: Connection reset by peer]
igraltist has joined #linux-sunxi
wzyy2 has joined #linux-sunxi
igraltis1 has quit [Ping timeout: 240 seconds]
wzyy2 has quit [Read error: Connection reset by peer]
<nove>
Why is this keeping saying with the meaning that the driver for the video engine can't be done because of not yet ready kernel driver framework? (for this type of stateless hardware)
<nove>
The base needed is only the V4L2 memory to memory codec api, and this already exists in mainline kernel even before kernel version 3.0, as it is used by the imx6 mfc(their vpu)
swiftglitch has quit [Ping timeout: 268 seconds]
<nove>
There are various ways that this could be done.
<nove>
1. There is the problem of parsing bitstreams in kernel space, but that could be ignored, it will not be accepted in mainline, but could be out-of-tree.
egbert has quit [Ping timeout: 268 seconds]
<nove>
2. Doing the parsing in userspace, and abuse of the controls to pass the parsed metadata into the kernel driver. Which has a recent example of the case for st-delta video decoder.
<nove>
Let's see what is said there, maybe will be given some information, in which will be possible to _estimate_ how long time is need for the request api to be added,
<nove>
If is something within one year, then maybe waiting is provable better, (wait some more is no difference)
<nove>
If not, then the option 2, do the same as for the st-delta video decoder
xes has quit [Read error: Connection reset by peer]
xes has joined #linux-sunxi
<rellla>
lets see, if there is told something new...
leviathan has quit [Read error: No route to host]
terra854 has quit [Quit: Connection closed for inactivity]
leviathan has joined #linux-sunxi
Nyuutwo has quit [Ping timeout: 276 seconds]
leviathan has quit [Read error: Connection reset by peer]
reinforce has quit [Quit: Leaving.]
leviathan has joined #linux-sunxi
leviathan has quit [Remote host closed the connection]
leviathan has joined #linux-sunxi
wzyy2 has joined #linux-sunxi
\\Mr_C\\ has quit [Quit: .]
wzyy2 has quit [Read error: Connection reset by peer]
Gerwin_J_ has joined #linux-sunxi
Gerwin_J has quit [Ping timeout: 260 seconds]
Gerwin_J_ is now known as Gerwin_J
phipli has joined #linux-sunxi
f0xx has quit [Ping timeout: 268 seconds]
wzyy2 has joined #linux-sunxi
nove has quit [Quit: nove]
bcruise has joined #linux-sunxi
<bcruise>
greetings
<bcruise>
does anyone know what "sayeye" is for?
<bcruise>
i see it is somekind of a service, usually found in allwinner android sources
phipli has quit [Ping timeout: 240 seconds]
apritzel has joined #linux-sunxi
IgorPec has joined #linux-sunxi
swiftgeek1 has joined #linux-sunxi
swiftgeek1 is now known as swiftglitch
wzyy2 has quit [Read error: Connection reset by peer]
egbert has joined #linux-sunxi
wzyy2 has joined #linux-sunxi
<apritzel>
shadeslayer: still around?
<shadeslayer>
yus ssup
<apritzel>
did you get the Pine64 boot sorted?
* apritzel
only made it half way through the backlog
<apritzel>
shadeslayer: and you did "make distclean" before?
<shadeslayer>
yus
<shadeslayer>
I even did a git clean -dfx
<shadeslayer>
let me try one last time
popolon has joined #linux-sunxi
<shadeslayer>
and it works now :S
<shadeslayer>
no wait
<shadeslayer>
U-Boot 2017.03-rc1-00248-g0feee04 (Feb 21 2017 - 23:09:33 +0100) Allwinner Technology < that build time looks too old
<beeble>
apritzel: just a thought. could it be a dtc issue? i remember that debian has a old dtc and there a dependecies to a newer one. does your script check the version?
<shadeslayer>
idk, seems to be working now :S
<beeble>
ok, nvm then
<apritzel>
beeble: I don't use dtc directly, that goes via mkimage
<shadeslayer>
apritzel: I think it's using the firmware you gave me
<shadeslayer>
and not the one I built
<shadeslayer>
let me zero out the card a bit
<apritzel>
yeah, that build time is from my build
<apritzel>
and my build server has a wrong time zone, as I just see ...
<shadeslayer>
and ... nothing :S
<shadeslayer>
I zero'd out the first 2 GB of the card
<shadeslayer>
and then flashed my build
<shadeslayer>
and I get nothing
wzyy2 has joined #linux-sunxi
<shadeslayer>
well anyway, for my needs I need DRM, which means spending time on the mainline uboot is a bit pointless right now :P
<shadeslayer>
which also means trying to figure out why the bsp kernel isn't giving me all of the dts files :(
Nyuutwo has joined #linux-sunxi
<apritzel>
shadeslayer: you can extract my version of bl31.bin: dd if=pine64-firmware.bin of=bl31.bin bs=1 skip=444700 count=32776
<apritzel>
then put that file into the U-Boot directory and rebuild