Ntemis has quit [Remote host closed the connection]
Putti has quit [Ping timeout: 245 seconds]
BenG83 has quit [Ping timeout: 240 seconds]
perr has joined #linux-sunxi
Andy-D has quit [Ping timeout: 258 seconds]
orly_owl has quit [Ping timeout: 245 seconds]
orly_owl has joined #linux-sunxi
orly_owl has quit [Client Quit]
orly_owl has joined #linux-sunxi
dave0x6d has quit [Quit: Connection closed for inactivity]
jbrown has quit [Ping timeout: 250 seconds]
bugzc has joined #linux-sunxi
apritzel has quit [Ping timeout: 258 seconds]
cnxsoft has joined #linux-sunxi
maruel has joined #linux-sunxi
<maruel>
mripard: hi, I see from the logs that you stated on 2015-04-10: 14:32 <mripard_> you can't drive the GPIOs with DMA.
<maruel>
I've wrote my own DMA driver and confirmed it to work by copying data across two physical pages
<maruel>
but reading from GPIO register range results in 0xFF (I used the DDMA)
<maruel>
I'm starting to think I'm SOL but I'd like to know where you gathered this information, as I searched for a while on the intertubes and couldn't find much
<maruel>
mripard: forgot to mention, my testing is currently on CHIP/R8. I've been testing only reading for now and suspect the DMA writes 0xFF in dst on failure, since the DMA has no register to mark that a failure occured.
BenG83 has joined #linux-sunxi
leviathanch has quit [Remote host closed the connection]
vagrantc has quit [Quit: leaving]
pg12 has quit [*.net *.split]
qschulz_ has quit [*.net *.split]
KotCzarny has quit [*.net *.split]
FergusL has quit [*.net *.split]
Mylene has quit [*.net *.split]
tyler-baker has quit [*.net *.split]
Mylene has joined #linux-sunxi
tyler-baker has joined #linux-sunxi
FergusL has joined #linux-sunxi
KotCzarny has joined #linux-sunxi
qschulz_ has joined #linux-sunxi
pg12 has joined #linux-sunxi
FergusL has quit [Excess Flood]
FergusL has joined #linux-sunxi
<apritzel>
maruel: are you talking about the Allwinner DMA controller, as in @0x01C02000
<apritzel>
?
<apritzel>
maruel: this one apparently does not cover the whole physical memory range, only selected regions
<apritzel>
maruel: DRAM, SRAM, audio, etc., as set in NDMA_DST_DRQ_TYPE and NDMA_SRC_DRQ_TYPE
<apritzel>
maruel: so as GPIOs are not listed there, they can't be targeted
muvlon has quit [Quit: Leaving]
deskwizard has joined #linux-sunxi
apritzel has quit [Ping timeout: 250 seconds]
PITYHERO122 has joined #linux-sunxi
PITYHERO122 has quit [Client Quit]
jstein_ has joined #linux-sunxi
jstein_ is now known as jstein
lemonzest has joined #linux-sunxi
specing has quit [Ping timeout: 268 seconds]
specing has joined #linux-sunxi
leviathanch has joined #linux-sunxi
cnxsoft has quit [Quit: cnxsoft]
The_Loko has joined #linux-sunxi
lkcl_ has joined #linux-sunxi
f0xx has quit [Ping timeout: 265 seconds]
lkcl has quit [Ping timeout: 260 seconds]
<maruel>
Oh too bad apritzel left already. I (naively) thought the DREQ were only to pace the I/O, not acting as an actual definition of the available address space
<maruel>
anyhow if apritzel ever look at the irc history, thanks for the insight, this may unblock me
uwe_ has quit [Ping timeout: 258 seconds]
jernej has quit [Ping timeout: 258 seconds]
Putti has quit [Quit: Leaving]
Putti has joined #linux-sunxi
jstein has quit [Remote host closed the connection]
jstein_ has joined #linux-sunxi
jstein_ is now known as jstein
apritzel has joined #linux-sunxi
Razican has joined #linux-sunxi
<Razican>
Hello there, I'm learning about sunxi-tools and I find something a little odd: The Allwinner R40 (SoC ID 0x1701) does not have a SPL address. Is this expected?
Andy-D has quit [Remote host closed the connection]
uwe_ has joined #linux-sunxi
uwe__ has joined #linux-sunxi
<MoeIcenowy>
Razican: no one ports it.
<Razican>
MoeIcenowy what do you mean by that? It's just unknown?
<apritzel>
Razican: unset fields in struct initializers are set to 0
<apritzel>
and the SPL address (=address of SRAM 1) is 0 for most SoCs except the newer ones
deskwizard has quit [Quit: Leaving]
<apritzel>
Razican: compare the other SoCs, especially the A20, they also don't specify the SPL address explicitly
<apritzel>
(that should read "(=address of SRAM A1)" above
<Razican>
apritzel oh, ok, I get it, thanks :)
<Razican>
But there is some data, such as the SID address that is not present in some SoCs, right?
<Razican>
It's not 0
<apritzel>
Razican: fel.c: if (soc_info->sid_addr) {
<apritzel>
Razican: so it's only valid if it's not 0, and thus needs to be explicitly specified to be used
<Razican>
Yes, yes, that's why I was confused. For what I understand, `mmu_tt_adr`, `sid_addr` and `rvbar_reg` are optional / some SoCs don't have them, right?
<apritzel>
Razican: yes
<Razican>
Perfect, thanks!
<dgp>
Nothing in the kernel uses the on-chip SRAM does it?
<apritzel>
dgp: not yet, but I am about to use it: for SCPI, where SRAM is used to exchange information between firmware and the kernel
<dgp>
apritzel: crypto stuff?
<dgp>
I really want to get the secure boot stuff working for SPI but looking at the source for the secure rom it looks like SPI isn't supported :(
<apritzel>
why does everyone connect "firmware" with "crypto" or "digital rights management"?
<apritzel>
it's for DVFS and sensors
<apritzel>
dgp: which source?
<dgp>
This is stuff you can't pass to the kernel from uboot?
<apritzel>
dgp: this is how SCPI works: you have some shared memory and a mailbox (both are in the DT): the rest in done on top of that
<KotCzarny>
apritzel, wouldnt that be better used for openrisc core?
<dgp>
apritzel: ok that makes sense. The reason I thought for crypto is basically that's what the onchip resources are usually for
<apritzel>
dgp: what do you mean with "secure boot stuff", exactly?
<apritzel>
dgp: I don't understand your exact problem ...
<dgp>
apritzel: You can set a bit in the e-fuse and have the boot rom check the image from the bootmedia against a certificate chain
<dgp>
and then it only boots code that is signed by a cert chain that ends with the root public key you write to the e-fuse
<apritzel>
dgp: ah, didn't know that ...
<apritzel>
but is flash.c the source code from the actual boot _ROM_?
<KotCzarny>
apritzel, wouldnt be bad to think of simple memory reservation map for srams
<apritzel>
KotCzarny: that's already there
<apritzel>
KotCzarny: you can specify regions and claim them in the DT
<dgp>
apritzel: it seems that way. I don't really want to change the e-fuse on my board to find out if SPI really doesn't work at this point
<KotCzarny>
apritzel, how would risc core access that info?
<apritzel>
KotCzarny: that would be hardcoded on that side and the DT has to match, of course
cptG_ has joined #linux-sunxi
<KotCzarny>
because right now running anything on that core might break your code
<KotCzarny>
and the whole system in fact
<apritzel>
KotCzarny: but for now I don't plan to use the OpenRISC anyway, instead using SMCs into ATF
<KotCzarny>
i have plans
<apritzel>
KotCzarny: I don't understand your point ...
<KotCzarny>
but if something from linux side is going to use sram it might break
<KotCzarny>
and as i understand sram is precious for openrisc core
<apritzel>
Linux uses what it finds in the DT
<apritzel>
KotCzarny: and there are several SRAM regions
<KotCzarny>
the more, the merrier
<KotCzarny>
:)
<dgp>
There is already a "driver" for memory mapped SRAM too..
cptG has quit [Ping timeout: 256 seconds]
<apritzel>
KotCzarny: if you have OpenRISC code using SRAM A2, you just don't expose this in the DT
<apritzel>
KotCzarny: actually Linux shouldn't be able to access that anyway, since it's secure
<apritzel>
KotCzarny: although this doesn't work for some yet unknown reason
<KotCzarny>
probably some bit toggle needed
<dgp>
maybe it's only active when the secure bit in the e-fuse is set?
<apritzel>
dgp: might be
<apritzel>
dgp: but writing e-fuse requires a special voltage on some SoC pin, right?
<apritzel>
dgp: so you can't write in on existing boards
<dgp>
apritzel: on the pi zero at least the vdd for efuse is connected to 3.3v so it looks like you can blow e-fuse there at least
<dgp>
wouldn't be surprised if it's the same for all the h3 orange boards as it looks like they use the same schematic block and just glue stuff onto the predefined ports (mmc etc)
<apritzel>
dgp: mmh, interesting, do you know which voltage is actually required?
<dgp>
I can't rememeber where I saw it but I read that it allwinner says it should be 2.5v
<dgp>
Once it get some more pi zeros I will try it out :D
<dgp>
s/it/I/
<apritzel>
dgp: brave man, tell me about it then ...
<KotCzarny>
maybe its just up to os to enable those security restrictions
deskwizard has joined #linux-sunxi
<apritzel>
KotCzarny: that would be totally stupid in terms of the ARM security extensions
<KotCzarny>
well, if it was done via first boot device, not that bad
<dgp>
KotCzarny: it might be something that can only be enable from on chip code from the secure boot rom
<apritzel>
dgp: I have a Remix Mini PC, where I see it working
<apritzel>
FEL booting works there, but is entered in non-secure
<apritzel>
32-bit
<apritzel>
so I can't use RMR to enter AArch64
<apritzel>
but it works via the eMMC boot
<dgp>
It looks like FEL works even if the secure bit is set. Which is a bit crap really
<KotCzarny>
but at least makes things unbrickable
<KotCzarny>
;)
<apritzel>
dgp: but it seems to go into non-secure SVC, at least
<apritzel>
dgp: do you know where this secure bit is in the efuse?
slapin has quit [Remote host closed the connection]
<dgp>
apritzel: one sec, I'll find the file that defines the SID stuff
<dgp>
That file defines the parts of the SID/efuse for allwinners u-boot
<dgp>
This is from the h2 sdk so might only apply to the h2/h3 but probably pretty similar
<dgp>
bit 11 in LCJS is apparently what toggles normal/secure boot
lynxis has joined #linux-sunxi
<zoobab>
Embedded Secure Bootloader System
<zoobab>
hardware fuses?
<dgp>
yes
<dgp>
some of the other files show what you need to do, but it's basically a public key in the hardware fuses and then a chain of certs starting with the one with that public key and ending with a cert that has it's first extension being the hash of the binary you want to load
<apritzel>
dgp: so it's _your_ key, that you put into the fuses at the same time when you blow that one "enable" fuse?
<dgp>
apritzel: seems that way. So you wouldn't need a cert from allwinner
<dgp>
unless there is something already in the e-fuse
<MoeIcenowy>
dgp: there's really secure boot facility in H2+/H3?!
Putti has quit [Ping timeout: 258 seconds]
<dgp>
MoeIcenowy: it seems that way. Datasheet says it has it. Source in the SDK seems to show how it works
<dgp>
Combined with signed FIT images in u-boot you could have a complete chain of trust
<MoeIcenowy>
oh I may now have the ability to brick my development board ;-)
<dgp>
FEL seems to always work for not a total brick ;)
<dgp>
s/for/so/
<MoeIcenowy>
but I won't be able to flash my devices if I lost the private key...
<dgp>
That's sort of the idea. :)
<apritzel>
dgp: ah, the Remix Mini indeed uses this!
<apritzel>
probe root certif
<apritzel>
certif valid: the root key is valid
<apritzel>
dgp: I will dump a boot log somewhere, so you can have a look ...
raknaz has joined #linux-sunxi
afaerber has joined #linux-sunxi
<dgp>
If you can dump the start of the flash you should be able to see the certs it has.
<MoeIcenowy>
apritzel: so maybe it's the SID which is the reason of different BROM behaviour in Remix Mini?
raknaz has quit [Client Quit]
dh1tw has joined #linux-sunxi
<dgp>
MoeIcenowy: h3 datasheet says it has two bootroms, one 32k and one 64k. 64k is probably needed for the certificate validation
<MoeIcenowy>
dgp: do you want english translation of the comments in the code you pointed out? ;-)
<dgp>
MoeIcenowy: Anything interesting?
<MoeIcenowy>
nothing
<dgp>
I saw that SPI says unimplemented and sort of gave up for now
<MoeIcenowy>
but it seems to be possible to have multiple keys
<MoeIcenowy>
"//以下信息重复，表示每个key的信息" means "// The following infomation will repeat, which represents each key"
<apritzel>
dgp: but thanks for pointing me to that "secure boot" feature, that probably explains the long-standing mystery of why the Remix Mini behaves differently
<dgp>
no problem. :)
<apritzel>
I just hope that this isn't the reason for the ARM security extension not working on the A64 boards...
dh1tw has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<apritzel>
because I think secure is secure on the A20, for instance
<apritzel>
even without secure boot
Ntemis has joined #linux-sunxi
yann has joined #linux-sunxi
yann-kaelig has joined #linux-sunxi
lkcl has joined #linux-sunxi
lkcl has quit [Remote host closed the connection]
lkcl has joined #linux-sunxi
lkcl has quit [Remote host closed the connection]
vagrantc has joined #linux-sunxi
dh1tw has joined #linux-sunxi
apritzel has quit [Ping timeout: 264 seconds]
lkcl has joined #linux-sunxi
tsuggs has joined #linux-sunxi
lkcl has quit [Read error: Connection reset by peer]
netlynx has quit [Quit: Ex-Chat]
leviathanch has quit [Remote host closed the connection]
leviathanch has joined #linux-sunxi
gzamboni has quit [Read error: Connection reset by peer]
<maruel>
in particular page 158 of file:///home/maruel/Downloads/micro/Allwinner%20R8%20User%20Manual%20V1.1.pdf implies it should be possible to get a dedicated DMA to do it for you
reinforce has joined #linux-sunxi
<maruel>
anyhow, I'll continue hacking around and will report if I get something to work
meridion_ is now known as meridion
reinforce has quit [Remote host closed the connection]
reinforce has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
nemunaire has quit [Quit: quit]
leviathanch has quit [Remote host closed the connection]
leviathanch has joined #linux-sunxi
lkcl has quit [Ping timeout: 240 seconds]
FrostyBytes has joined #linux-sunxi
<FrostyBytes>
hello world. I've compiled mainline u-boot v2016.11 for bananapi. when booting on my bananapi, I get "mmc0 is the current device" followed by "### ERROR ### Please RESET the board ###"
<FrostyBytes>
anyone know what is going on? is there a way to enable more debugging output for u-boot?
Keziolio has quit [Changing host]
Keziolio has joined #linux-sunxi
yann-kaelig has quit [Quit: Leaving]
fl_0 has quit [Ping timeout: 246 seconds]
fl_0 has joined #linux-sunxi
terra854 has quit [Quit: Connection closed for inactivity]
apritzel has joined #linux-sunxi
The_Loko has quit [Quit: Leaving]
<apritzel>
FrostyBytes: do you see only one U-Boot banner? The SPL one?
<apritzel>
FrostyBytes: you can enable debugging message by adding #define BE
<apritzel>
#define DEBUG
<apritzel>
in a source file _before_ the #includes
orly_owl has joined #linux-sunxi
<apritzel>
FrostyBytes: but as a start: can you dump the exact bootlog in some pastebin, also confirm whether we are talking about a BananaPi M1 here?
lkcl_ has quit [Ping timeout: 265 seconds]
jernej has quit [Ping timeout: 240 seconds]
<FrostyBytes>
yes it is M1 (the original bananapi)
<FrostyBytes>
the output is framebuffer, not uart; I don't have uart attached
<FrostyBytes>
it doesn't say spl but it's definitely the with_spl file that I used
<apritzel>
I guess the SPL doesn't print anything on the framebuffer
<apritzel>
so you are already in U-boot proper
<FrostyBytes>
for now I'm trying to emerge the crossdev compiler recommended on the wiki and try to compile it with that. will get back if it still doesn't work
<FrostyBytes>
(I compiled with stable versions instead)
paulk-collins has quit [Quit: Leaving]
fdcx has quit [Remote host closed the connection]
fdcx has joined #linux-sunxi
Turl has quit [Quit: >.<]
Turl has joined #linux-sunxi
lennyraposo has quit [Ping timeout: 250 seconds]
corecode has joined #linux-sunxi
<corecode>
hi!
<corecode>
i'm trying to use g_serial with my orangepi, but somehow my thinkpad doesn't detect the usb device. it's like there is no signal at all
deskwizard has quit [Ping timeout: 250 seconds]
<corecode>
ooh i need to set otg_role to 2
<corecode>
hum
<corecode>
i was hoping i could use it as a boot device
lennyraposo has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
<miasma>
corecode: which way? to boot the orangepi with files from the laptop?
<FrostyBytes>
well I get the same error "mmc0 is current device ; ### ERROR ### Please RESET the board ###" after compiling u-boot with buildroot toolchain
<FrostyBytes>
can bad commands in boot.scr cause this?
<FrostyBytes>
If I hit a key to disable auto boot and then do "ls mmc 0:1 /" I get the same error
<apritzel>
FrostyBytes: can you check another SD card?
<FrostyBytes>
hang on I noticed my ext2 partition is marked as FAT in the partition table maybe that is screwing things up
Ntemis has quit [Remote host closed the connection]
<FrostyBytes>
gaah same error. I think the sd card is OK though because a binary u-boot taken from Armbian works fine
<FrostyBytes>
now I have one bootable Linux ext2 partition with boot.scr on it
leviathanch has quit [Remote host closed the connection]
mzki has quit [Ping timeout: 264 seconds]
<FrostyBytes>
which file defines do_ls??
<FrostyBytes>
nvm fs.c
<apritzel>
I use "fatls" or "ext2ls"
Mr__Anderson has quit [Remote host closed the connection]
<FrostyBytes>
well it seems to be dying in ext4probe