<bauen1>
smaeul: the SMC backdoor would still work if you could care to craft up some code, upload it with fel and run it, right ?
yoq has joined #linux-sunxi
<apritzel>
smaeul: for A64 and H6: yes, but boot0_sdcard_sun50iw9p1.bin has an eGON signature, 0xc000 in the length field and is 48 KB big
<apritzel>
dunno if this actually boots, but that's what the file says
<bauen1>
sorry i just read your text above again
<apritzel>
smaeul: and TOC0 can already be bigger on the A64 (including the code)
<bauen1>
seems like the best way to make these chips secure is still to burn the otg usb data pins :/
<smaeul>
bauen1: just to confirm, yes it will
<smaeul>
I can turn off SPL_FIT_TINY and see if it works :)
<smaeul>
and the SPC setup was all that was missing to get to U-Boot/Linux: [ 0.000000] Machine model: Pine H64 model B
<apritzel>
smaeul: so there is an SPC in the H6? How did you find it?
<apritzel>
ah, you mentioned it above, nvm
<smaeul>
apritzel: I just tested a 39936 byte SPL both inside a TOC0 and standalone on a non-secure board, and both worked fine
<smaeul>
apritzel: the base address is mentioned in one of the BSPs as well. the register layout is different than before, and it's not documented
<apritzel>
smaeul: I see, thanks. What's the reason for secure-boot on the H6? Any particular board shipped that way? Or just curiosity?
yoq has quit [Remote host closed the connection]
<smaeul>
apritzel: I don't want to do anything in crust that breaks when secure boot is enabled, like put the memory area shared with Linux in SRAM A2 (oops)
<apritzel>
I see, very noble ;-)
<smaeul>
also curiosity, of course
<apritzel>
I still have this Remix Mini, which was shipped with the secure fuse burnt (and ROTPK hash empty)
<apritzel>
so the BROM expection shows that the FEL-SMC trick would still work, even with a valid ROTPK hash?
<apritzel>
because that was my assumption: all-0-hash is some kind of secure-boot development mode
<apritzel>
s/exception/inspection/
<smaeul>
apritzel: correct, the fuses don't matter. setting up the secure monitor is always done when entering FEL, and the SMC has no permission checks
jstein has quit [Quit: quit]
Mangy_Dog has quit [Ping timeout: 260 seconds]
bauen2 has joined #linux-sunxi
bauen2 has quit [Remote host closed the connection]
<ullbeking>
now that OPi is moving to rk3399, etc, does this mean that the "linux-sunxi" era of Opi might be coming to an end soon?
<apritzel>
ullbeking: moving? They are doing boards with different SoCs, like others. And they just released a new Allwinner board a week ago
<ullbeking>
apritzel: i'm out of the loop. which was the new board with the allwinner recently?
<ullbeking>
apritzel: these OPi Zero2 sure do look sweet.... i wish i could find standoffs to stack them, or cases for them, or _something_ to house them nicely...
<apritzel>
not sure what the problem is with standoffs? Looks like they have a hole in each corner? Looks like M3 standoffs fit nicely.
mauz555 has joined #linux-sunxi
<ullbeking>
M3!!!! yes that's what i was fishing for... thanks.
<apritzel>
And for all the other boards OPi offers cases, usually, might just be a bit early
<ullbeking>
do M3 fit commonly amongly many boards?
<apritzel>
I have M2 and M3, some boards have smaller holes
<ullbeking>
apritzel: which boards are you stacking?
mauz555 has quit [Read error: Connection reset by peer]
<apritzel>
all kinds of. most have M3, but the BPi M2 Berry has smaller holes, for instance
ChriChri has quit [Ping timeout: 256 seconds]
apritzel has quit [Ping timeout: 260 seconds]
kaspter has joined #linux-sunxi
mripard has quit [Ping timeout: 264 seconds]
victhor has quit [Ping timeout: 256 seconds]
ChriChri has joined #linux-sunxi
kaspter has quit [Ping timeout: 264 seconds]
kaspter has joined #linux-sunxi
gnarface has quit [Quit: Leaving]
gnarface has joined #linux-sunxi
camus1 has joined #linux-sunxi
kaspter has quit [Ping timeout: 264 seconds]
camus1 is now known as kaspter
ChriChri has quit [Quit: bye...]
ChriChri has joined #linux-sunxi
gaston1980 has quit [Quit: Konversation terminated!]
KotCzarny has quit [Ping timeout: 256 seconds]
ChriChri has quit [Ping timeout: 258 seconds]
ChriChri has joined #linux-sunxi
sunshavi has joined #linux-sunxi
asdf28 has joined #linux-sunxi
gendevbot has joined #linux-sunxi
lurchi_ is now known as lurchi__
<ullbeking>
i never tried the BPi so far...
<ullbeking>
so far i've commited myself to OPi
<ullbeking>
and I have a few RPi, BBB, BP,
lkcl has quit [Ping timeout: 256 seconds]
apritzel has joined #linux-sunxi
[7] has quit [Disconnected by services]
TheSeven has joined #linux-sunxi
camus1 has joined #linux-sunxi
kaspter has quit [Ping timeout: 264 seconds]
camus1 is now known as kaspter
lkcl has joined #linux-sunxi
_whitelogger has joined #linux-sunxi
apritzel has quit [Ping timeout: 264 seconds]
KotCzarny has joined #linux-sunxi
lurchi_ has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 260 seconds]
reinforce has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
daregap has joined #linux-sunxi
lkcl has quit [Ping timeout: 272 seconds]
lkcl has joined #linux-sunxi
kaspter has quit [Ping timeout: 264 seconds]
camus1 has joined #linux-sunxi
camus1 is now known as kaspter
ganbold has quit [Read error: Connection reset by peer]
<e3ef13f4ff44>
i have time, i can also help with development
<bauen1>
smaeul: there should also be a SMC according to the BSP, see H6/Memory_Map
<e3ef13f4ff44>
final price 16.46 USD
<e3ef13f4ff44>
for H616, im gonna buy it now :P
<bauen1>
it also occured to me that if i find a way to (persistently) breaks the fel in some way, e.g. by messing with timings that could be used as a way of disabling it while still allowing e.g. linux to use the usb
<libv>
e3ef13f4ff44: then stick around in here
<bauen1>
but i also kind of doubt that is possible just in software
tuxillo has quit [Remote host closed the connection]
<bauen1>
why would you need another ethernet connector for a tv box ?
kaspter has quit [Ping timeout: 256 seconds]
kaspter has joined #linux-sunxi
florian_kc has joined #linux-sunxi
apritzel has joined #linux-sunxi
tuxillo has joined #linux-sunxi
<e3ef13f4ff44>
bought
<gediz0x539>
cool
florian_kc is now known as florian
<plaes>
jernej: you should bump your VP8 patchset to 2020 ;)
<linkmauve>
Oops. :-°
arete74 has joined #linux-sunxi
random_yanek has quit [Ping timeout: 264 seconds]
camus1 has joined #linux-sunxi
kaspter has quit [Ping timeout: 256 seconds]
camus1 is now known as kaspter
victhor has joined #linux-sunxi
<KotCzarny>
hmm?
<KotCzarny>
disregard, wrong window
random_yanek has joined #linux-sunxi
tuxillo has quit [Ping timeout: 260 seconds]
asdf28 has quit [Ping timeout: 260 seconds]
camus1 has joined #linux-sunxi
kaspter has quit [Ping timeout: 256 seconds]
camus1 is now known as kaspter
koty0f has joined #linux-sunxi
camus1 has joined #linux-sunxi
kaspter has quit [Ping timeout: 256 seconds]
camus1 is now known as kaspter
AneoX has quit [Ping timeout: 272 seconds]
Ixnus has joined #linux-sunxi
Mangy_Dog has joined #linux-sunxi
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft has joined #linux-sunxi
<Ixnus>
gediz0x539: thanks, I guess you already try to find the a100 ds. I wanted to fill out the wiki, and maybe ds will be hlepful for reviewing the patches for it.
Ixnus has quit [Remote host closed the connection]
JohnDoe_71Rus has joined #linux-sunxi
<gediz0x539>
yep. i've searched some terms about a100 but couldn't find anything.
<apritzel>
given that the A100 was officially upstreamed by AW, shouldn't they be able to provide a datasheet?
<apritzel>
I think traditionally they only gave datasheets to board vendors (who then leake^Wpublished them), but then they never cared about upstream Linux so far
<KotCzarny>
i think someone've said it wasnt officially upstreamed, just some guy doing it in private time
asdf28 has joined #linux-sunxi
AneoX has joined #linux-sunxi
kaspter has quit [Ping timeout: 265 seconds]
<apritzel>
ah, didn't know that
<KotCzarny>
but since it's irc, would be better to find the source/confirm
<gediz0x539>
i thought something official was finally on the way
<gediz0x539>
naive
psydread has left #linux-sunxi [#linux-sunxi]
gaston1980 has joined #linux-sunxi
Ixnus has joined #linux-sunxi
Ixnus has quit [Ping timeout: 245 seconds]
Ixnus has joined #linux-sunxi
<apritzel>
smaeul: bauen1: in case you care, I put my U-Boot mkimage TOC0 skeleton patch here. That surely needs some rework now, but should provide some base: https://github.com/apritzel/u-boot/commits/mkimage
<Ixnus>
No, no. It's actually good: there are also a few small fixes send from @allwinnertech.com email addresses.
<Ixnus>
A100 is not on the website, no public device(s), no BSP, no datasheet => this patches were madewith access to internal resources.
matthias_bgg has quit [Ping timeout: 240 seconds]
<apritzel>
Ixnus: since you seem to care about the Wiki: Is there some poster book board page, that could serve as an example?
<Ixnus>
The way IP blocks are (re)used, at some point will make life easier for both AW and linux-sunxi
mripard has joined #linux-sunxi
<apritzel>
Ixnus: I find many board pages in various states of disrepair, and was wondering what would be a desirable state to bring them to
<apritzel>
Ixnus: IP blocks reused> yes, but that also shows the problem with AW's approach: they seem to mostly ignore upstream work on this in their newer BSPs
<apritzel>
plus there is a big misalignment when it comes to the firmware interface design
<apritzel>
plus the DT ...
<Ixnus>
"poster book board page" ?
<Ixnus>
You mean a board page thats in good shape to serve as example ?
<apritzel>
yes
<Ixnus>
I don't know good board page on top of my head. But if you were thinking about improving some of the hundreds of board pages thats seems like mission imposible.
<apritzel>
Ixnus: I know, I wanted to start anyway ;-)
<bauen1>
pages that reference specific memory address / magic numbers also should mention which soc they respond to, but that's a dream far away
<Ixnus>
apritzel: you can give it a try with the boards you have maybe?
<apritzel>
yes, that was the plan
<apritzel>
(but that's surely an after-work-hours thing to do)
Ixnus has quit [Remote host closed the connection]
<libv>
i spent whole man-months in 2012-2014 giving the wiki the structure that it has
<libv>
many many man-months.
fl_0 has quit [Quit: STRG + Q]
fl_0 has joined #linux-sunxi
<willmore>
bauen1, nice work you're doing. I have one question about the "and the first 4 bytes of the keyladder must match sid[0x5c] unless sid[0x5c] is 0" part. Isn't this memory 1 when blank and 0 when programmed? Wouldn't that make it possible to program these locations and bypass that check?
lucascastro has quit [Remote host closed the connection]
lucascastro has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has quit [Changing host]
netlynx has joined #linux-sunxi
hanni76 has joined #linux-sunxi
<smaeul>
willmore: no, all of the fuses (other than the ones programmed at the factory like the serial and THS calibration data) start out as zero
<bauen1>
willmore: i haven't actually booted my h6 yet so can't really answer that, but it would be lovely if there was a fuse that disables any further writes
<bauen1>
since then you can ensure integrity (to some extend, but not confidentiality) of the code being executed even if fel is active
reinforce has quit [Quit: Leaving.]
ldevulder__ has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
ldevulder_ has quit [Ping timeout: 260 seconds]
<bauen1>
i suppose it can already be done by grounding the efuse ping, but that requires hardware modification
ganbold_ has joined #linux-sunxi
ganbold has quit [Ping timeout: 272 seconds]
<willmore>
smaeul, thank you.
<willmore>
bauen1, I assume the code in the efuse is meant to be programmed off board and the board would ground the pin preventing later modification.
jstein has joined #linux-sunxi
PPAChao has quit [Ping timeout: 264 seconds]
kaspter has joined #linux-sunxi
gnarface has quit [Remote host closed the connection]
gnarface has joined #linux-sunxi
gnarface has quit [Quit: Leaving]
dddddd has quit [Ping timeout: 240 seconds]
gnarface has joined #linux-sunxi
kaspter has quit [Quit: kaspter]
hanni76 has quit [Ping timeout: 260 seconds]
tuxillo has joined #linux-sunxi
<asdf28>
"kworker events_freezable power" constantly eating 10% cpu on a mainline kernel, anyone knows what that is?
jbrown has quit [Remote host closed the connection]
\\Mr_C\\ has quit [Quit: (Read error: Connection reset by beer)]
<jernej>
plaes: Work on it actually started in 2019, so I don't see a problem...
jbrown has joined #linux-sunxi
florian has quit [Quit: Leaving]
jpnadas has joined #linux-sunxi
<jpnadas>
good evening
<jpnadas>
how are you guys doing?
tuxillo has quit [Ping timeout: 260 seconds]
dddddd has joined #linux-sunxi
<jpnadas>
is this the proper place for discussing things about the pinephone?
tuxillo has joined #linux-sunxi
<asdf28>
hi!
<asdf28>
well about its chipset and linux kernel, probably
<jpnadas>
oh...
<gnarface>
jpnadas: it's not a bad place but there's also #pinephone on their own irc network, and some various scattered telegram, matrix, and discord channels, and the pine64.org forum
<jpnadas>
that's not exactly what I am looking for... want to know a bit about the cellular capabilities (minimum requirements to have it operating on a network)
<jpnadas>
I will check #pinephone, thanks
<gnarface>
jpnadas: this channel is however associated with the entire family of chips the pinephone is from, so it's not irrelevant to the pinephone, but probably not as good of a place for the cellular bits
<jpnadas>
makes sense, thanks anyways
<gnarface>
jpnadas: to be clear, #pinephone on irc.pine64.org, not here on freenode
<asdf28>
jpnadas do you have one? how is it?
<libv>
so they created their own irc server?
<jpnadas>
although there is a #pinephone here, but I think the one on irc.pine64.org is better indeed
<libv>
*facepalm*
<jpnadas>
asdf28 I do not have it yet, but my old phone is almost dead, so I am thinking about getting one. But need to know if it will work here in the Netherlands
<jpnadas>
specially since I have a low budget carrier
<gnarface>
asdf28: i have one. the hardware is pretty sweet. can't speak to the cell capabilities though, haven't had the guts to actually put a sim card in it.
<gnarface>
asdf28: (some people have and most distros at least work for calls and SMS, but MMS messages are still an outstanding issue)
<asdf28>
cool
<jpnadas>
I don't really use MMS
<asdf28>
it's quite big and heavy though, isn't it?
<gnarface>
asdf28: camera support is ... barely working, but working
<asdf28>
i don't care for the speed or memory
<gnarface>
asdf28: heh, well it's big compared to my old pantech link II but i think someone said it's about the same size as an iphone 4s? or something like that
<jpnadas>
what OS are you running on it?
<asdf28>
but i'd love to have one for tinkering, it's very appealing
<gnarface>
right now i'm using ubuntu touch on mine but i think pmos with phosh or mobian with phosh are more popular right now
<jpnadas>
I think it is shipping with manjaro too
<asdf28>
phosh? pmos? i haven't heard of that
<gnarface>
the desktop UI experience with ubuntu touch is really nice, but there's not a lot to do with it yet other than slide the drawers around
<jpnadas>
I am keen to try that... since my daily driver is arch too, it will be a nice match
<karlp>
is pmos postmarketos?
<gnarface>
asdf28: postmarketOS i mean,
<gnarface>
karlp: yea
<karlp>
not everyone is up on all the acronyms
<gnarface>
the pinephones have gone out in several batches, each with a different OS preinstalled but you can generally use any of them
<mru>
pmos, nmos, cmos
<gnarface>
most people would say it is NOT ready as a daily driver yet, but some people are doing it already
<jpnadas>
what would you say is lacking for a daily driver experience?
<jpnadas>
my biggest concern is banking
<gnarface>
wow i'm in the wrong country to answer that one
<gnarface>
because over here the chances of banking on Linux with cooperation from the actual banks is somewhere between 0 and negative infinity
<jpnadas>
is that country Brazil?
<jpnadas>
(sounds like Brazil)
<gnarface>
no, it's USA... but it might help you to know that the pinephone can boot android too, so in a pinch you could still get banking done on it if you have spare microsd cards
<jpnadas>
actually in Europe
<jpnadas>
all banks are required to expose an API
<gnarface>
it can boot from microsd too and people are working on multibooting from a single microsd
<jpnadas>
so I plan to do my own banking app
<gnarface>
interesting
<gnarface>
that sounds like a noble cause
<jpnadas>
yeah, if I manage to make it nice, I will open source it
<gnarface>
well ok, so the next thing that would be holding it back for you is just the carrier support
<jpnadas>
but initially it would be tailored to my needs
<gnarface>
not all cell carriers work out of the box, but if you know how to wrangle modem AT commands you can often get it working anyway
<jpnadas>
yep, if I was sure it would work with my carrier, I would get it
<jpnadas>
they are a low budget one that just got acquired by T mobile
<gnarface>
eventually it should work with most carriers but right now some people are having to send modem AT commands
<jpnadas>
I am ok fiddling with that, if I can find out what I need to do...
<gnarface>
(and for some carriers nobody knows the right AT strings, so there's some guesswork still happening)
<jpnadas>
the issue is, I am not Dutch and the documentation on carriers here is in Dutch
<mru>
which carrier do you use?
<jpnadas>
yeah, that's my main concern
<jpnadas>
simpel
<jpnadas>
simpel is the carrier I use mru
<gnarface>
jpnadas: hmm, on the plus side i would expect the laws to be much more open about preserving your fair use though, unlike here
<jpnadas>
yeah, I have lived in North America before and I remember the hell that was the telecom sector
<gnarface>
jpnadas: also, the camera is jacked up still. images come through backwards, and if you try to change resolutions off the default (lowest) setting it freezes
<jpnadas>
I am not that much of a photo guy, but I guess it would be nice to get the camera working properly
<mru>
I've dealt with simcom 3g/4g modules on various networks
<gnarface>
jpnadas: i think the issue is that it requires non-free firmware that has only been partially reverse-engineered so far
<jpnadas>
is it at all possible to get android apps running on some sort of virtualized setting? Or if you want that you need to dual boot it for sure?
<gnarface>
jpnadas: you might be able to actually load the firmware though if you don't care about the security implications
<mru>
I don't recall vodafone NL being troublesome, don't know if anyone tried simpel
<gnarface>
jpnadas: running android in linux in some sort of container or something like that? i do think i skimmed people talking about that too but i forget what it was called or if it works yet
<mru>
on most networks things just work
<jpnadas>
thanks mru
<jpnadas>
that's reassuring
<gnarface>
the movement on carrier support has been fast
<jpnadas>
gnarface yes, that was the idea.... some sort of container
<gnarface>
the movement on camera support has been ... stagnant
<mru>
occasionally you have to enter an APN
<mru>
we did recently get a weird problem report from congo...
<jpnadas>
if entering an APN is all I have to do, I am a happy man
<mru>
I have no idea what radio the pinephone uses
<jpnadas>
my idea with using android apps was for whatsapp, most of my friends use it for communication, so I am sorta forced into using it too...
<mru>
so it could require more setup
<jpnadas>
Quectel EG25-G is the radio mru
<mru>
not familiar with that one
<jpnadas>
what do yo mean by loading the fw gnarface?
<gnarface>
jpnadas: the wifi and bluetooth drivers are a little unreliable still. they need some work. (general experiences everyone is having is that bluetooth is only stable after a cold boot and wifi is only stable after a warm boot)
<jpnadas>
wifi I care about, bluetooth not so much
<jpnadas>
but good to know nonetheless
<gnarface>
jpnadas: the camera firmware you mean? it's one of those ovXXXX chips
<gnarface>
jpnadas: it's supported for the old android/legacy/BSP kernel
<gnarface>
jpnadas: just not in any open source sense
<jpnadas>
oh, I see
<gnarface>
jpnadas: probably works flawlessly on android actually
<jpnadas>
ugh, so indeed it is further behind than I would expect
<gnarface>
jpnadas: something to know about this core SBC; it was manufacturer supported up to a kernel 3.11-BSP-somethingoranother with closed-source drivers. the efforts to get current OSes on it have been all using current, post 4.x, mainline kernels and reverse-engineered firmware instead, that's why it's lagging behind
<gnarface>
jpnadas: oh, and all the manufacturer's official documentation is in Chinese
<jpnadas>
that doesn't help
<jpnadas>
hahaha
apritzel has quit [Ping timeout: 246 seconds]
<gnarface>
jpnadas: heh, yea it's not helping anyone
<gnarface>
not even the ones who are Chinese apparently
<gnarface>
jpnadas: that seems to be why the rock64 hardware they started selling more recently has surpassed it in support
netlynx has quit [Quit: Ex-Chat]
<gnarface>
jpnadas: (they can't quite fit it in a phone yet though)
<jpnadas>
perhaps there will be a move towards that before all the reverse-engineering is done
<jpnadas>
and than that work is somewhat wasted... sad times
<gnarface>
it's hard to say really
<gnarface>
but some portion of every pinephone sale gets donated to the distribution it came preloaded with, so buying pinephones isn't necessarily futile as a way to get them supported fully
<jpnadas>
true... you can also use it as something else later on, it is still a good SBC
<gnarface>
i think someone said ubuntu touch got 10$ from every pinephone sale or 10% or something like that, not sure exactly
<gnarface>
yes, and all the bolted-on parts have a real actual hardware defeat switch inside the phone... so if you do decide to keep it as a media server or a small tablet or something, you can disable the modem securely
<insep_>
10$
<jpnadas>
indeed... it can be a nice remote control for my kodi setup
<jpnadas>
if all goes south
<jpnadas>
all right man, thanks for all the insights
<jpnadas>
I gotta go work on my thesis now actually
<jpnadas>
have been procrastinating on that one for quite too long
<jpnadas>
bye guys, have a good day/evening
jpnadas has quit [Remote host closed the connection]
victhor has quit [Quit: Leaving]
victhor has joined #linux-sunxi
<bauen1>
the pinephone is a very interesting target for doing trustzone and hardware security in general e.g. something like https://www.youtube.com/watch?v=voFV1W4yyY8 or a secure pin (encryption password) entry screen
<bauen1>
it's a bit of a bummer that the FEL provides a straight backdoor
<bauen1>
an efuse bit to disable FEL is the only thing needed, maybe on a future chip ...
lucascastro has quit [Ping timeout: 240 seconds]
<insep_>
i thought implementing luks straight in the bootloader, but that would require implementing touchscreen driver in the bootloader or type your password using volume buttons, both options doesn't sound like something perfect
<bauen1>
insep_: with secure boot you can have confidence that the code asking you for the decryption keys isn't malicious
<bauen1>
insep_: what exactly reads the password, a full blown linux kernel, the bootloader ; doesn't matter too much at that point
<insep_>
is signed initfs a thing yet
<bauen1>
for UEFI Secure Boot that's already a thing
<insep_>
cool
<bauen1>
but if you control the bootloader you can implement it
<insep_>
also the link you've sent looks hella interesting, i thought about similar stuff with sel4 but those guys advanced it even further
<bauen1>
iirc u-boot does some signature checking
<bauen1>
insep_: but if you actually implement the touch screen as "secure peripheral" e.g. reserve the top 20px to secure mode (see link above) you can do a lot of fun stuff like storing your gpg keys in the secure mode
<bauen1>
actually i don't have a pinephone and can't try if you can even access FEL (without hardware modifications), but it looks like the usb data wires go into an AXP803 chip so that could prevent access to FEL without opening the device
<Ashleee>
btw -- the tftp packet loss issue -- I've seen the same issue not just on A64 and H3 but also on rk3288 as well, so it must be in u-boot, not just PHY/MAC driver issue IMHO
<apritzel>
Ashleee: ah, good observation, thanks! When I last time looked into the DM UCLASS_ETH framework, some things looked weird indeed. Might be worth having a closer look
<apritzel>
although I get reliable 9.8 MByte/s from my Pine64-LTS
<Ashleee>
the oddest thing is that it is completely random. I can do one tftp boot (~50MB for initramfs + kernel) with single lost packet and 1 minute later it loses more packets than succesffuly acks
<Ashleee>
I wonder if u-boot gets overloaded with other things on the network
<Ashleee>
(as there are 10 other Pine64 on the same network doing all kinds of traffic)
<KotCzarny>
maybe you have mac conflict? ie. 2 devices with same mac
<Ashleee>
doesn't matter if source is 1Gbit or 100Mbit, if it is on a 1Gbit or 100Mbit switch
<Ashleee>
nope
<Ashleee>
would see that on DHCP
<Ashleee>
(or for the lack of better words, I wouldn't see that on DHCP :D)