<apritzel>
VBUS on that port would come from the AXP, so it might not be driven at boot time, so it might be fine
Schimsalabim has joined #linux-sunxi
<apritzel>
in practice I never had problems with those cables, I think most PC/laptop USB ports are quite resilient
dliviu has quit [Quit: Going away]
dliviu has joined #linux-sunxi
<KREYREN_oftc>
hmm doesn't seem that i can get it in the FEL mode with the FEL button
<apritzel>
you have to press that either when the board powers up or when it resets
<apritzel>
the former is somewhat tricky to achieve on a laptop, though the power button might work
<KREYREN_oftc>
hmm when i press the FEL button i get a LED reacting to it
<apritzel>
if you have a reset *button*, that's the most reliable: press FEL, press reset, release reset, release FEL
<KREYREN_oftc>
it doesn't have a reset :D
<acmeplus>
Does it have autofel?
<KREYREN_oftc>
acmeplus, none i am aware of
<KREYREN_oftc>
nothing in dmesg
<apritzel>
you can also "dd" fel-sdboot.sunxi to an SD card, that enters FEL mode
<apritzel>
but you do have a power button, don't you?
<KREYREN_oftc>
i have power button ye
<KREYREN_oftc>
and a hole on the back of teres that says RESET and has uboot on the mainboard
<apritzel>
then power off, press FEL, power on, release FEL (after a second or so)
<KREYREN_oftc>
that has a button
<KREYREN_oftc>
apritzel, i am doing that and it doesn't seem to want to do FEL
<KREYREN_oftc>
the LED starts to blink when i do the release FEL step though
<KREYREN_oftc>
maybe it's not wired correctly on the mainboard
<apritzel>
which LED?
<apritzel>
the schematics shows a reset switch, and just some pads or so for the FEL button
<KREYREN_oftc>
apritzel, it seems to be an LED for battery
<apritzel>
the charge LED, connected to the AXP?
<KREYREN_oftc>
actually it seems to be the LED that has a lock symbol with a number 1 in it
<KREYREN_oftc>
the LEDS are as: power battery 1 A
<KREYREN_oftc>
1 lights up when i release FEL or press it
<apritzel>
a green one, CAPS lock?
<apritzel>
that's connected to PC4, which might be activated by the BROM
<apritzel>
when it tries to boot from NAND, since PC4 is the NAND chip select, it seems
<KREYREN_oftc>
LED_NUML in schematics
<KREYREN_oftc>
not LED_CAPS
<KREYREN_oftc>
going to R56 and then GND
<apritzel>
similar, though, PC7 and NAND-RB1
<KREYREN_oftc>
the LED_NUML gets lid up on boot maybe it's resetting it?
<KREYREN_oftc>
-> the button is actually reset button and not FEL?
<apritzel>
that's unclear, normally a "uboot" label means FEL, but reset is reset
<KREYREN_oftc>
nope it's connected to F12 which is FEL/UBOOT
<KREYREN_oftc>
RESET on the case and UBOOT on the mainboard
<apritzel>
well, what happens when you power the board on with that button pressed?
<apritzel>
apart from that LED flashing?
<KREYREN_oftc>
nothing just black screen
<apritzel>
that's absolutely expected
<apritzel>
do you have the right USB port, the one labelled OTG?
<KREYREN_oftc>
The USB-OTG port is on a separate IO board that is connected across the case with FFC connector maybe the impedance for the FEL signal is too high?
<KREYREN_oftc>
apritzel, yes
<apritzel>
impedance? FEL signal? That's normal USB-OTG, so USB cable rules apply. Not being twisted is not nice, I guess, but it surely works as a USB host, normally?
<KREYREN_oftc>
hmm i think it's getting in the FEL bcs if i hold the FEL button the 1 LED won't light up until it's released
<KREYREN_oftc>
apritzel, it works normally yes
<KREYREN_oftc>
tried the other USB too just in case
<apritzel>
try to disconnect the USB cable during the power process, and connect it only afterwards
<KREYREN_oftc>
same
<KREYREN_oftc>
it should show up in dmesg right?
<apritzel>
lsusb should list it
<KREYREN_oftc>
doesn't
<apritzel>
but yeah: [6313743.771984] usb 1-2.2.4.4.4: New USB device found, idVendor=1f3a, idProduct=efe8, bcdDevice= 2.b3
<KREYREN_oftc>
USB cable's fine too i just checked it wil multimeter
<apritzel>
do you have the +5V line connected?
<KREYREN_oftc>
yep
<apritzel>
if you can easily, try to open that. You don't need that, unless you power the board via USB
<apritzel>
(which I think wouldn't work on the Teres anyway)
acmeplus has quit [Quit: This computer has gone to sleep]
<KREYREN_oftc>
i have the cable kinda open i cut them off and connected them with WAGO
* KREYREN_oftc
was checking resistance and the cable seems fine
ftg has quit [Read error: Connection reset by peer]
<apritzel>
do you have serial connected? that sometimes spoils FEL mode
<KREYREN_oftc>
i don't
<KREYREN_oftc>
I think that is a hardware bug, it's weird that the USB-OTG would be on the IO board instead of on the mainboard so tsvetan probably knew that it didn't work and put that on the IO board so that i can be easily fixed in the future?
<KREYREN_oftc>
CC diego71 were you able to get FEL on your teres?
<apritzel>
I don't think it's a hardware bug, it's just that FEL is sometimes touchy, especially if the power situation is unclear
<KREYREN_oftc>
apritzel, tries connecting it to the external power and it has same issue, uses USB 3.0 connector on host
<KREYREN_oftc>
*tried
<KREYREN_oftc>
apritzel, like it seems to be in FEL, but it won't get enumerated on the host
Daanct12 has joined #linux-sunxi
KREYREN_oftc has quit [Remote host closed the connection]
acmeplus has joined #linux-sunxi
<acmeplus>
hexdump0815: tested kms, but while panfrost is loading, there are no /dev/dri so the only way to run kmscube is with vkms module that does not use the GPU and of course reports 7fps.
acmeplus has quit []
acmeplus has joined #linux-sunxi
montjoie has joined #linux-sunxi
<apritzel>
acmeplus: yeah, it looks like kmscube still requires a display driver - though no X server
montjoie_ has quit [Ping timeout: 480 seconds]
<acmeplus>
At least I'm not getting any errors loading the module
<acmeplus>
And I can confirm what macromorgan mentioned before that increasing the CONFIG_SPL_STACK_R_ADDR to 0x50000000 get it passed the calloc error
<acmeplus>
Also that I'm also using uboot from FEL and kernel + rootfs from SDCARD
<diego71>
KREYREN_oftc: tbh I never needed to use FEL on the Olimex Teres
<KREYREN_oftc>
diego71, hmm O.o
<KREYREN_oftc>
diego71, could you check if it works? I am trying to exclude a manufacturing error on my board
vagrantc has quit [Quit: leaving]
<diego71>
not today sorry
<KREYREN_oftc>
diego71, np take your time any data on the subject is appreciated
hexdump01 has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
chewitt has joined #linux-sunxi
tolthoff has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
warpme has joined #linux-sunxi
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
warpme has quit []
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
mripard has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
Daanct12 has quit [Quit: WeeChat 4.2.1]
warpme has joined #linux-sunxi
Daanct12 has joined #linux-sunxi
apritzel has joined #linux-sunxi
sunshavi has quit [Remote host closed the connection]
sunshavi has joined #linux-sunxi
thecheofusi has joined #linux-sunxi
<gamiee>
I have some good news for people interested in Allwinner A523/A527/T527, PINE64 partnered with YuzukiHD, and they will produce and sell YuzukiHD's SBC with this SoC. Also they will sell YuzukiHD's SBC with H618. :)
warpme has quit []
warpme has joined #linux-sunxi
asriel has quit [Quit: Don't drink the water. They put something in it to make you forget.]
<libv>
so nice, first oshw devices (that i know of) which are mass purchaseable with those socs
<libv>
hrm, no english translation for oshwhub it seems
thecheofusi has joined #linux-sunxi
dsimic is now known as Guest2737
dsimic has joined #linux-sunxi
thecheofusi_ has joined #linux-sunxi
Guest2737 has quit [Ping timeout: 480 seconds]
thecheofusi has quit [Ping timeout: 480 seconds]
tolthoff_ has joined #linux-sunxi
tolthoff has quit []
tolthoff_ has left #linux-sunxi [#linux-sunxi]
tolthoff_ has joined #linux-sunxi
<tolthoff_>
Hey, due to a Uni Project I came into contact with the i2c. My question is: Why is there no information on what went wrong when the bus is locked? Cant we extend the marvell dreiver to output the current linestate (sda/scl) if it locks? And also who may I contact in case it is usable?
Net147 has quit [Quit: Quit]
Net147 has joined #linux-sunxi
thecheofusi has joined #linux-sunxi
thecheofusi_ has quit [Ping timeout: 480 seconds]
colinsane has quit []
colinsane has joined #linux-sunxi
Schimsalabim has quit [Read error: No route to host]
Schimsalabim has joined #linux-sunxi
acmeplus has joined #linux-sunxi
<libv>
tolthoff_: how does an i2c bus lock up? Some device is pulling SCL or SDA low, there is no way to know who is doing it from the host pov
<tolthoff_>
if you add the Line Control Register you can see what line is pulled to low depending on the register contents
<gamiee>
tolthoff_: well, you can still switch pins to GPIO and read their state (not sure how much Linux allows/likes that)
<tolthoff_>
gaimee: of cause you could but having the output already available might be better eg if you have a broken cable that pulls low
<tolthoff_>
At least that would be my expectation
<libv>
tolthoff_: ~300EUR scopes do i2c decoding for you btw
<libv>
also, a multimeter should be able to tell you which line is pulled low
<gamiee>
libv: (re a523) not sure what license will be there for hw stuff :/
<Jookia>
those $8 ebay sigrok logic analyzers work well for i2c
<tolthoff_>
Of cause they do. But my point is that you might not always have one around when you need it.
<libv>
for the via unichrome (20+ys ago) i just bought a solderable vga connector and used a multimeter to do the basics
<libv>
i re-used it when poking at s3 and tseng hw (which came into existence just after the time VESA specified the DDC bus) a decade or so later
<libv>
tolthoff_: as said, poke the gpio pins directly
<libv>
if not, go it's gpled, go fiddle with timers and such
<tolthoff_>
For now I just added the code to the dev_err of the mv64xxx device driver when it locks up
<tolthoff_>
Works like a charm
<libv>
patches welcome?
<Jookia>
is there a i2c recovery gpios thing for sunxi socs?
<tolthoff_>
I am totally new to the topic of patches thats why I came here first
<Jookia>
one thing you could do is use kernel tracing to see the i2c transactions and see the one that locks up
<tolthoff_>
recovery exists and also works pretty good. But being able to find out whats happening by just taking a look into dmesg is pretty neat I think
Daanct12 has quit [Quit: WeeChat 4.2.1]
warpme has quit [Read error: Connection reset by peer]
tolthoff_ has quit [Remote host closed the connection]
<apritzel>
tolthoff_: if the patch is not too big, I'd say there are good chances that it could go upstream
<apritzel>
debug and error patches are typically not a big problem, since they don't annoy normal users too much, but help developers
KREYREN_ has joined #linux-sunxi
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_ has quit [Remote host closed the connection]
KREYREN_ has joined #linux-sunxi
<acmeplus>
I've been tracing the boot from MMC, and it seems it has issues trying to read the spl info at sector: 514, buffer: 0x4ff001c0, and size: 0xa27a0
<acmeplus>
It seems it stops in spl_simple_fit_read
<macromorgan>
I discovered now I am able to read the full image but it's choking at the handoff... basically at image_entry()
<acmeplus>
So you got pass the BL31 and then it died?
<apritzel>
I guess he means the SPL wants to hand off to the first payload, which would be BL31 at 0x40000000
<macromorgan>
right, I can't get it to get to BL31
<macromorgan>
I see `image entry point: 0x4a000000` which tells me it's trying to jump straight to U-Boot anyway it seems
<macromorgan>
I'm also trying to figure out if it's using FIT or raw or something
<apritzel>
it must be FIT: every arm64 board uses that
<macromorgan>
right, I figured
<macromorgan>
so looking at the FIT the load address of the A-TF is 0x40000000 as you say
<apritzel>
and yeah, 0x4a000000 sounds wrong, although it should at least work (just no PSCI), as in: you should see U-Boot proper booting
<apritzel>
what is your U-Boot base tree? Are you using tokyovigilante's branch?
<macromorgan>
I'm using pure mainline with tokyov's AXP patches on top
<macromorgan>
stumbling along as I go
<macromorgan>
and the RAM stuff too from tokyo's branch
Schimsalabim has quit [Read error: Connection reset by peer]
<apritzel>
OK, that should be fine, just wanted to check if that's some older branch
Schimsalabim has joined #linux-sunxi
<macromorgan>
so far RAM and AXP bits are working without error. Changing the address for the malloc stack got me here. I'm wondering if I put the image in the wrong location?
<apritzel>
you should not need to worry about any of that: every details of load addresses and such is handled internally
<apritzel>
those addresses are SoC specific, not board dependent, so it should all just work
<apritzel>
you just either load u-boot-sunxi-with-spl.bin via FEL, or put it on an SD card at either 8K or 128K, and the rest should come along automatically
<apritzel>
fiddling with load addresses and stack locations can just contribute data points to isolate the actual root cause
<apritzel>
macromorgan: you can think of the SPL as the continuation of the BROM, which is board agnostic. The SPL just knows about the DRAM details, but the rest is fairly generic
<macromorgan>
right
<apritzel>
and the only assumption we have for arm64 boards is that they have at least 256MB of DRAM, so we try to use addresses below that, for the core parts
warpme has quit []
<macromorgan>
mkimage signature not found
Schimsalabim has quit [Ping timeout: 480 seconds]
<macromorgan>
regardless of setting u-boot.bin or u-boot.img
<apritzel>
which mkimage signature are you looking for? the legacy U-Boot image one?
Schimsalabim has joined #linux-sunxi
<apritzel>
u-boot.bin is a pure binary, you just load that to the fixed 0x4a000000 load address, and execute the first instruction in there
<apritzel>
u-boot.img is a FIT image, which means it looks like a DTB (since it uses a DT data structure to describe the image)
<macromorgan>
gotcha
<macromorgan>
should I set CONFIG_SPL_LOAD_FIT_ADDRESS to 4a...?
<apritzel>
again, changing any of those addresses will just make things more broken :-(
<apritzel>
this is a quite a delicate construction, and some addresses depend on each other, or rely on other assumptions
<apritzel>
with FEL loading you can break the image down, and load the SPL, BL31, and U-Boot proper separately, but this is basically the same what sunxi-fel already does, when it parses the FIT image
<macromorgan>
right :-(
<apritzel>
if changing some addresses makes it work for you, that points more that some parts of DRAM work better than others, with might mean there is something fishy with the addrmap settings
<apritzel>
or some timings affects some banks and not others
<acmeplus>
But why would that affect MMC only?
<macromorgan>
Unsupported OS image.. Jumping nevertheless..
<acmeplus>
I'm not disagreeing, just curious if there may be a reason why with FEL is working
<apritzel>
that's a good question! It could be power related: MMC accesses require more juice than FEL
<macromorgan>
yeah... could be reading a corrupt image for all we know
<acmeplus>
That's true...
<acmeplus>
macromorgan: did sunxi-fel uboot work for you or not at all?
<apritzel>
in general the SPL returns pretty quickly to FEL after the DRAM is ready, whereas for MMC there is quite some more code to execute or more buffers and stacks and heaps to access
<apritzel>
what puzzles me though is that DRAM seems to be pretty stable with FEL, with TF-A, U-Boot and the kernel executing happily
<acmeplus>
Yeah, using FEL to load uboot and then reading the kernel + rootfs from sdcard works well
<macromorgan>
pre-relocation the stack usage is 0, post relocation it's using about 1MB (432 bytes for the calloc function in the mmc driver, and 1MB malloc for the u-boot image read from the mmc)
<apritzel>
typically moderate DRAM weaknesses show up early in the kernel boot process (even with U-Boot proper seems happy)
<apritzel>
my money is on some timing related issues: either the DRAM parameters are not quite right, or there is something fishy in the DRAM init code
<apritzel>
I also see the occasional RAM "doubling", and we assume it's either some missing barriers or missing timings, though jernej compared that to the BSP code already multiple times now
<macromorgan>
yeah
<apritzel>
with "missing timings" I mean missing delay during the setup process
<gamiee>
jernej: just one of them, and it seems it will be T527
<apritzel>
which is also something you wouldn't see when comparing register dumps
<macromorgan>
I get weird random ram doubling on the H700
<jernej>
apritzel: I think that unexplained barrier fix for H6 DRAM might also work here.
<apritzel>
yeah, I am ready to accept that now
<jernej>
gamiee: do you know about timeline?
<apritzel>
jernej: you mean adding that dsb() in mctl_mem_matches(), right?
<jernej>
correct
<gamiee>
jernej : not known yet, hopefully soon
<apritzel>
macromorgan: you can try that: add another dsb() call *before* the "writel(0xaa55aa55 ..." in mctl_mem_matches_base()
<macromorgan>
so call dsb() twice?
warpme has joined #linux-sunxi
<macromorgan>
ohh before
<macromorgan>
sorry
<macromorgan>
I'll see if that makes the mystery 2GB problem go away
<macromorgan>
but it's intermittant so it will take time
<acmeplus>
To me it happens once every 4-5 reboots
<macromorgan>
I got it once in my last 16 tries
<macromorgan>
so it happens, just very very rarely
<acmeplus>
DRAM: 2048 MiB just now :)
<macromorgan>
last 30 tries (without the extra dsb() so it's a control test) and none of them had 2GB...
apritzel has quit [Ping timeout: 480 seconds]
<jernej>
do you have feeling if this happens more commonly after cold boot or reboot?
<acmeplus>
I've seen it very frequently with FEL that is cold boot
<acmeplus>
I've just tested about 20 times now with MMC, and it has not happened. But with FEL I got it 3 times in a 15 FEL sequence
<acmeplus>
I need to try to FEL + the extra dsb
<acmeplus>
I'm using two different uboots, one is the one from tokyovigilante as is, other one is your okt507 with the dts and config from tokyo
<acmeplus>
Of course, murphy's law, now I cannot get it reproduced with any version (with or without the extra dsb). Will try again later
warpme has quit []
<macromorgan>
hmm... put some printfs to try and get info about the image it wants to boot. It shows load_addr and entry_point as 0x40000000 (seems reasonable)
<macromorgan>
but offset is 0 and size is 607760
<macromorgan>
that actually matches the ATF binary
<tokyovigilante>
to be fair I have seen a relatively frequent (maybe 1 in 5) DRAM doubling (or even quadrupling the odd time) and was also assuming DRAM params not quite right, I did basically flail about trying random combinations and initially came up with numbers that allowed SPL to start, but then the copy and readback of the full u-boot image failed, then more flailing till I arrived at the current ones,
<tokyovigilante>
I have no idea what any of the params actually mean
<tokyovigilante>
good to see progress on SD-boot too
<macromorgan>
I still need to conclude that I'm reading the image back correctly. I haven't done that yet but should probably next (maybe throw an md5sum calculation in there somehow)
gamiee has quit [Remote host closed the connection]
<KREYREN_oftc>
the kernel version section should probably be removed now tbh as the code quality issues were handled already which was the motivation to add it bcs it was breaking teres too much
juri_ has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
warpme has joined #linux-sunxi
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
warpme has quit []
<apritzel>
KREYREN_oftc: SD card is always first priority in the AW BROM
<apritzel>
that's what I meant yesterday with "hard to brick"
<KREYREN_oftc>
apritzel, i see.. is there a way to change that?
<KREYREN_oftc>
bcs it doesn't have secureboot afaik
<apritzel>
SPI flash is last, actually, so eMMC is in between
<apritzel>
AW secureboot is not what you think it is
<apritzel>
it's more for box tickers ;-)
<KREYREN_oftc>
like the idea is to prevent the attacker from deploying payload on the device
<apritzel>
honestly: use another SoC vendor
<apritzel>
I mean I am afraid you have to decide between a hackable device, where you recommend people to swap the SoC, and something that's locked up so that you cannot load your own code
<KREYREN_oftc>
hmm i am not aware of any other arm vendor that doesn't suck
yang_ is now known as yang
<Jookia>
STelectronics is pretty good
Schimsalabim has quit [Read error: Connection reset by peer]
<KREYREN_oftc>
Jookia, what's the open-source situation with them?
<Jookia>
it's pretty good, their cod eis open source and they contribute to mainline
Schimsalabim has joined #linux-sunxi
<Jookia>
their datasheets and schematics and BSPs are all available publicly
<KREYREN_oftc>
or i guess the sdcard doesn't have to be wired this way and just making it as a separate thing that goes through the USB bus
<apritzel>
KREYREN_oftc: that's a quite unreflected statement, isn't it? what do you mean with "suck"? AW is pretty high on any "sucks" list, I'd say
<apritzel>
but they are cheap and hackable
<KREYREN_oftc>
apritzel, i meant in terms of open-source and chip bugs though economy is also important
<apritzel>
you can burn fuses in the SoC, so that the BROM only accepts a signed SPL
<Jookia>
there's always chip bugs
<apritzel>
for instance the A64 has a horrible timer bug
<KREYREN_oftc>
Jookia, yes but the A64 doesn't have known CPU vulnerabilities which is one of the main reasons for me to use it
<KREYREN_oftc>
apritzel, timer bug?
<apritzel>
yes, we have a workaround in the kernel that works about 99.9% of the time ;-)
<Jookia>
KREYREN_oftc: i think basing purchasing decision on CPU vulns is a bit of a bad move. a lot can be worked around, and there will always be new vulns popping up
<Jookia>
we can't audit the hardware and prove there aren't vulns
<apritzel>
it's the *Cortex-A53* that is not affected (more by nature than by clever design) by Spectre/Meltdown
<apritzel>
the same applies to the Cortex-A55
<KREYREN_oftc>
Jookia, it's kinda an attack vector thing where if you know that CPU A has vulnerabilities you can make an observation that due to the design decision these could get worse over the time vs CPU B that doesn't suffer from these
<apritzel>
so *any* SoC with those cores is also not affected
<apritzel>
so every other later Allwinner SoC, and many Rockchip SoCs (like the RK3566/3568), and numerous others from better vendors
<Jookia>
KREYREN_oftc: i'm not sure that observation always holds true
<KREYREN_oftc>
apritzel, i know but in reality allwinner is like the only vendor that gets me all docs needed for me to make OSHW designs wihout having to sign an NDAs and sacrifice the first born
<KREYREN_oftc>
> we can't audit the hardware and prove there aren't vulns < -- The requirement i have for this is ~5 year old hardware that is popular enough so that sufficient amount of eyeballs looked through them and didn't find anything meaningful atm
<apritzel>
you mean those docs that have been leaked and have "CONFIDENTIAL" written all over every page?
<KREYREN_oftc>
apritzel, yep.. practically among the best thing i can get in terms of OSHW designs
juri_ has quit [Read error: Connection reset by peer]
<Jookia>
KREYREN_oftc: that requirements sounds more like a feeling rather than something hard or concrete
<apritzel>
A64 is almost 10 years old by now, and it shows
<KREYREN_oftc>
like NXP is there too which might give me some docs but they will be very annoyed by it
<KREYREN_oftc>
apritzel, i prefer older chips they are almost always without hidden surprices tbh
<KREYREN_oftc>
So the A64 is great for CNCs and drones atm
<Jookia>
the other issue is that you'll end up just throwing away machines once vulns are reported
<KREYREN_oftc>
Jookia, yep that's why i want to make teres-2 a SOM design
<Jookia>
i think focusing on CPU vulns is the wrong approach when there are bigger problems in the hardware that tend to be more exploitable, such as boot ROM
<KREYREN_oftc>
so i can do riscv.. if issue shows up -> just replace the module board for reliable hardware
<Jookia>
issues don't show up, they are always there. your knowledge just changes
<KREYREN_oftc>
Jookia, BootROM is what i wanted to address with physically WP-protected SPI tbh
<Jookia>
the boot ROM is in the chip itself
<Jookia>
usually used for secure boot
<KREYREN_oftc>
Jookia, and like ye but it's also about people behing aware of them and having the resources to utilize them
<apritzel>
we know that at least the H6 has a BROM bug that allows circumventing secure boot
<KREYREN_oftc>
Jookia, why is that a concern if none can inject bootloader code to the device?
<Jookia>
a lot of imx6 cpus do too :(
<Jookia>
KREYREN_oftc: physical security is important
<Jookia>
but if you don't care about that then i guess it doesn't matter
<KREYREN_oftc>
i care about that, but i can manage physical security what i can't manage is software and remote vulnerabilities
<apritzel>
I'd say that no one cares too much about security on AW chips, that's why you don't know what's out there
juri_ has joined #linux-sunxi
<Jookia>
would allwinner tell us if they found a vulnerability? do they release errata sheets?
<apritzel>
Jookia: they definitely don't: CONFIG_SUN50I_ERRATUM_UNKNOWN1=y
<KREYREN_oftc>
i am not aware of better alternative and i don't consider A64 being the optimal solution.. rather the least terrible tbh
<apritzel>
(we tried to get an errata number out of them for this A64 timer bug)
<Jookia>
KREYREN_oftc: if you wait 5 years, probably ST's chips then
smaeul has quit [Ping timeout: 480 seconds]
<KREYREN_oftc>
in the next 3 years there will probably be sufficient riscv chips though and i kinda need something now
<KREYREN_oftc>
bcs teres for me is a hardened system that is the highest authority in the whole infra
<Jookia>
im not sure if riscv will be any better than ARM for this
<apritzel>
a hardened system where anyone can just put in an SD card and boot whatever they want?
<KREYREN_oftc>
apritzel, my sdcard is sealed from the inside atm and ye that's kinda a problem i am trying to figure out atm.. the idea is better eMMC and removing sdcard from the mainboard
<apritzel>
just look at how much better the D1 was ;-)
<KREYREN_oftc>
apritzel, like riscv at least gives me more insight into how the chip works.. on arm i would have to be a paying member to have access to all the things
<KREYREN_oftc>
so that's kinda why it's preferred
<Jookia>
idk i don't want to dunk too hard on risc-v or friends i just think focusing soley on the CPU at the expense of having vendors that tell you if there's exploits is a bit of a bad move
<Jookia>
that said, more OSHW is good :D
<apritzel>
you still don't know what AW added, and typically the actual cores are the least of your problems (for instance in respect to documentation)
<Jookia>
if you can make something that works for you and for others that's a pretty cool thing
<KREYREN_oftc>
like yea it's an uphill battle "least terrible" is not great but it seems to fit the purpose
<KREYREN_oftc>
bcs like what other options i have? practically none
<macromorgan>
okay, I'm getting now to the handoff between SPL and A-TF and it's dying. Do you by chance know if bl31_main() is the first (non assembly) function executed by A-TF? I want to drop some printfs and see if we're at least starting A-TF and that's where it's choking.
wingrime1 has joined #linux-sunxi
<apritzel>
you can do that in assembly as well: mov x1, #0x5000000; mov w0, #'1'; str w0, [x1]
<apritzel>
even before the console is initialised
<apritzel>
you can output up to 16 characters this way (before the FIFO fills up), to put beacons in the code
wingrime-ww has quit [Ping timeout: 480 seconds]
<apritzel>
macromorgan: btw: that only works because the SPL already initialised the UART (clock gate, reset, pinmux), and TF-A relies on that
smaeul has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]