<megi>
it will not work on older A's, because those have more limited block size
<megi>
for dma
<megi>
there's DMA_BUF_MAX_SIZE macro that's need to be changed for those to work
<KotCzarny>
uboot speed isnt that important, unless one is loading multi MB ramdisks
<KotCzarny>
still nice
<megi>
I'm planning to use this for pinephone to get past the u-boot very fast to the running kernel
<megi>
if I ever get my hands on one
<avph>
megi: nice, is it also used by the SPL?
<megi>
it could, but that uses different code paths for initialization
<megi>
so more code chnages would be needed
<megi>
and I'm not sure if SPL can allocate memory in DRAM
<megi>
or what malloc in SPL will do
<megi>
but you can probably get away with allocating just 10-20 DMA descriptors for the main u-boot to load from emmc so it may not be that memory hungry
<megi>
at least on newer socs
<megi>
anyway I specifically disabled this for SPL for now
<willmore>
KotCzarny, that vulnerability is as bad as they portray it to be. Your provider can send SMS messages that your phone will silently receive and pass to the SIM. These messages can install applications that run on the SIM itself--completely out of sight of the phone. Those applications have access to a lot of information and can also silently send SMS messages that the UI of the phone will not say anything about.
* willmore
used to work in cell phone provisioning for what is a large provider in the US.
<fALSO>
from what i've talked with a portuguese cell phone company
<fALSO>
we arent using that vuln here in portugal
<fALSO>
so they say
<fALSO>
"trust jesus - dont think" :-)
<mru>
they would say that
<fALSO>
let me check what they've said
<mru>
willmore: is there any way to tell if your sim has such features?
<fALSO>
they told that they dont use S@T
<fALSO>
whatever that is
<mru>
_they_ don't use it
<fALSO>
GSM sucks
<fALSO>
should be disabled 10 or more years ago
<willmore>
It's in the SIMs themselves. They're already using the functionality if they can provision a SIM without removing it from your phone.
<mru>
doesn't mean the sim doesn't have the feature
<fALSO>
GSM has tons of bugs
<fALSO>
uses crappy voice compression
<willmore>
mru pretty much all SIMs have it.
<fALSO>
i dont understand why we keep using that old technology
<fALSO>
with top of the line mobile phones
<fALSO>
its very weird for me :-)
<mru>
modern phones with 3g/4g support better codecs
<willmore>
the voice codec in GSM is very good, I'm not sure what you're thinking of fALSO
<fALSO>
well, the quality in voice calls is ultra crappy
<fALSO>
at least in portugal
<willmore>
The original one was okay, but the EFR codec that was released in the late 90's is very good.
<willmore>
If your landlines are bad, the cell phone won't make it better.
<fALSO>
released in the 90s? isnt that too soon for they to be using it ;-PPPPPPPPP
<willmore>
IIRC, it was mandated as baseline in the 3g specs.
* willmore
worked on EFR support at Motorola
<fALSO>
nice
lurchi__ is now known as lurchi_
tllim has quit [Read error: Connection reset by peer]
vagrantc has joined #linux-sunxi
lurchi_ has quit [Read error: Connection reset by peer]
lurchi__ has joined #linux-sunxi
<willmore>
wens, looks like my Orange Pi One Plus is taking a long time on boot before the ssh daemon is running as I'm getting network responses from it, but ssh fails to connect. So it sounds like it's the issue libv was talking about. I'll hook up a serial line to it to verify.
netlynx_ has quit [Quit: Ex-Chat]
lurchi__ has quit [Ping timeout: 240 seconds]
aloo_shu has joined #linux-sunxi
<KotCzarny>
willmore: yeah, i know, sims are tiny computers itselves, with ability to control your phone. that's why it's dangerous
<KotCzarny>
as for boot time, other apps might wait for random device too
<KotCzarny>
it's not only tied to sshd
<KotCzarny>
if you install haveged and it helps, that will be it
<willmore>
I'm okay with it taking a while to come up, I just wanted to make sure I knew why it was doing it--and it wasn't because of something going wrong.
lurchi__ has joined #linux-sunxi
warpme_ has quit [Quit: warpme_]
lurchi__ has quit [Ping timeout: 246 seconds]
vagrantc has quit [Quit: leaving]
lurchi__ has joined #linux-sunxi
gaston1980 has quit [Quit: Konversation terminated!]
florian has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 240 seconds]
<avph>
Does the H2+ BROM have a gpio to enter FEL mode? BTW is the BROM the same for all SOC variants or is that something vendors can modify?
<Mangy_Dog>
The AP6212A wifi/bt module on most of these boards.... Is there an example circuit diagram of how to hook one of these up? And to what ports on a SBC/CPU to wire them to? If i was to use a Compute Module type setup?
megi has joined #linux-sunxi
sunilmohan has quit [Read error: Connection reset by peer]
sunilmohan has joined #linux-sunxi
sunilmohan has quit [Changing host]
sunilmohan has joined #linux-sunxi
warpme_ has joined #linux-sunxi
warpme_ has quit [Quit: warpme_]
JohnDoe_71Rus has quit [Quit: KVIrc KVIrc Aria 5.0.0, revision: 5.0.0+git-7422-2fe1a3bca, build type: debug, sources date: 20160102, built on: 2019-07-01 08:27:19 UTC 5.0.0+git-7422-2fe1a3bca http://www.kvirc.net/]
<karlp>
have you tried looking at tje available schematics of those boards?
<hellsenberg>
avph: I found some orange pi zero (your board) "schanetic" (schematic, but filename says that). let me see if I can find a link
<hellsenberg>
if you want to use fel for reflashing the spi, i guess you could just put the flash chip on hold and boot, then once in fel enable it again
<avph>
looks like the FEL pin is strapped to VCC via a 47K resistor. Might be doable to add a switch to ground
<hellsenberg>
which pin is that?
lkcl has joined #linux-sunxi
<avph>
W6
<hellsenberg>
ah, UBOOT. thx
<hellsenberg>
now then, where's that R124...
<Mangy_Dog>
ohh schematics
<Mangy_Dog>
thats useful :D
* hellsenberg
prefers boardviews but those are more usual on x86 things
<Mangy_Dog>
well it does explain a little for me of how the wifi works
<Mangy_Dog>
its just i might be doing a pi4 compute module version of my game machine
<Mangy_Dog>
(if the rumours about a pi4 Cm are true)
<Mangy_Dog>
and i just watned to have a quick look to see how the wifi chip would need to be wired up
<Mangy_Dog>
So i knew what to look out for on the CM pin out
<hellsenberg>
rpi "schematics" more like pinout
<Mangy_Dog>
nods
megi has quit [Quit: WeeChat 2.6]
megi has joined #linux-sunxi
tllim has joined #linux-sunxi
atopuzov[m] has quit [Read error: Connection reset by peer]
fevv8[m] has quit [Remote host closed the connection]
romainmahoux[m] has quit [Remote host closed the connection]
davidebeatrici has quit [Write error: Connection reset by peer]
thefloweringash has quit [Write error: Connection reset by peer]
freddor has quit [Read error: Connection reset by peer]
t4h4[m] has quit [Read error: Connection reset by peer]
JuniorJPDJ has quit [Read error: Connection reset by peer]
Jeremy_Rand_Talo has quit [Write error: Connection reset by peer]
clementp[m] has quit [Read error: Connection reset by peer]
Danct12 has quit [Write error: Connection reset by peer]
k40s[m] has quit [Write error: Broken pipe]
solderfumes has quit [Write error: Connection reset by peer]
EmilKarlson has quit [Write error: Connection reset by peer]
MartijnBraam has quit [Write error: Connection reset by peer]
hpagseddy[m] has quit [Write error: Broken pipe]
z3ntu has quit [Write error: Connection reset by peer]
mic-e[m] has quit [Read error: Connection reset by peer]
marekbelisko has joined #linux-sunxi
GrimKriegor has quit [Ping timeout: 276 seconds]
k40s[m] has joined #linux-sunxi
<mru>
Mangy_Dog: cubietech provide schematics for some boards using ap62xx wifi modules
GrimKriegor has joined #linux-sunxi
GrimKriegor has joined #linux-sunxi
marekbelisko has quit [Quit: This computer has gone to sleep]
marekbelisko has joined #linux-sunxi
marekbelisko has quit [Client Quit]
warpme_ has joined #linux-sunxi
lurchi__ has joined #linux-sunxi
yann|work has joined #linux-sunxi
freddor has joined #linux-sunxi
davidebeatrici has joined #linux-sunxi
fevv8[m] has joined #linux-sunxi
JuniorJPDJ has joined #linux-sunxi
atopuzov[m] has joined #linux-sunxi
Danct12 has joined #linux-sunxi
t4h4[m] has joined #linux-sunxi
mic-e[m] has joined #linux-sunxi
romainmahoux[m] has joined #linux-sunxi
thefloweringash has joined #linux-sunxi
z3ntu has joined #linux-sunxi
hpagseddy[m] has joined #linux-sunxi
EmilKarlson has joined #linux-sunxi
MartijnBraam has joined #linux-sunxi
solderfumes has joined #linux-sunxi
Jeremy_Rand_Talo has joined #linux-sunxi
clementp[m] has joined #linux-sunxi
<megi>
looks like sunxi u-boot has useless 500ms fixed delay on many boards
<Mangy_Dog>
is it possible to configure uboot to work with a soft power button? So as soon as power is turned on the mcu and cpu start up.... Within a few MS a GPIO on the SBC is set to pull to ground. Keeping the soft power engaged... And when shutdown commands are sent by the OS uboot kills the IO which powers off the device?
<megi>
not sure I understand
<megi>
what's the purpose
<megi>
?
<Mangy_Dog>
to turn on a device
<Mangy_Dog>
and shutdown command actually power off the machine
<megi>
u-boot doesn't come into play during shutdown
<megi>
you can toggle gpio on shutdown from linux
<[TheBug]>
I think the question is can uboot manipulate a gpio to enable a device at boot time, preferably before the OS starts to boot (maybe a display?) and then when you shutdown, it powers off the whole unit so whatever is attached also turns off (display?)
<megi>
but you'd need to patch it
<[TheBug]>
if I have decoded correctly what he is saying
GrimKriegor has quit [Ping timeout: 240 seconds]
<[TheBug]>
Mangy_Dog??
warpme_ has quit [Quit: warpme_]
GrimKriegor has joined #linux-sunxi
GrimKriegor has joined #linux-sunxi
gaston1980 has joined #linux-sunxi
dev1990 has quit [Quit: Konversation terminated!]
lurchi__ has quit [Ping timeout: 250 seconds]
dev1990 has joined #linux-sunxi
ldevulder_ has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
ldevulder has quit [Ping timeout: 265 seconds]
NeuroScr has joined #linux-sunxi
<DuClare>
Anyone reverse engineered boot0 dram setup?
<DuClare>
Just wondering if there were any resources on that in case I want to go there and not waste too much time re-discovering the wheel :P
<DuClare>
I couldn't ever get good dram clocks from mainline u-boot spl so I'm loading u-boot via boot0.. which works but meh, ugly
<libv>
DuClare: can you dump the dram registers, and do you have any info on their layout for your specific soc?
<libv>
if so, it's as easy as printing out the values from uboot in code or even in command line, but you can pretty print it in code
<anarsoul>
DuClare: you should specify SoC, board and ram type
<anarsoul>
(LPDDR3 for A64 runs at 552 MHz while it should be running at 667, but unfortunately we don't have correct timings for that... boot0 also uses 552 MHz)
<hellsenberg>
anarsoul: which kind of timings are missing?
<anarsoul>
hellsenberg: see u-boot/arch/arm/mach-sunxi/dram_timings