<DocScrutinizer05>
but anyway, I guess the answe is "yes" no matter what ;-)
<DocScrutinizer05>
otherwise either you'd ask for a nonsensical feature or we had failed our own design goals :-)
<pabs3>
there are some USB cables that don't have the ability to do the data transmission part of USB, just power transmission and charging. would be nice to have the ability to do that with normal data cables and the switch between data and charging done in Neo900 hardware/software
<pabs3>
this would be useful for plugging the device into airport chargers or other folks laptops or whatever
<pabs3>
(to reduce the attack surface while doing so)
<DocScrutinizer05>
err, you ask for USB not doing any data and just charging device from VBUS? No problem
<pabs3>
right, excellent :)
<DocScrutinizer05>
simply forbid USB driver to start enumerating
<pabs3>
hmm
<DocScrutinizer05>
actually on N900 switching device into hostmode (but not clicking "enumerate") would do the trick. On Neo900 we don't need the nasty hostmode kernel hack, so it works absolutely standard like on any linux. Prolly modprobe -r ohci
<DocScrutinizer05>
or sth like that
<DocScrutinizer05>
which should tear down ULPI interface to PHY on kernel module cleanup
<DocScrutinizer05>
anyway on hw side no problem
<DocScrutinizer05>
you got zhe mentorgraphics MUSB engine in SoC and that one handles the ULPI and thus USB, and you can powerr down the complete engine
<DocScrutinizer05>
actually you better SHALL power down the MUSB engine when not in use, it's a nasty power hog
<DocScrutinizer05>
normally it gets powered up when USB port detects voltage on VBUS
<DocScrutinizer05>
which causes an IRQ in TWL4030
<timclassic>
DocScrutinizer05: Thanks for the map-related info.
<DocScrutinizer05>
afaik that IRQ is serviced in software (kernel) and thus the software powers up the MUSB engine and ULPI and stuff
<DocScrutinizer05>
timclassic: yw
<DocScrutinizer05>
however beware! on system boot all that is done by every bootloader involved (ROMBOOT, xLoader, uBoot) and all will listen for some magic incantation and then on detection enter a mode you don't want to see active in a non-secure environment
<DocScrutinizer05>
there's hardly anything we could do about that at least for ROMBOOT
<DocScrutinizer05>
ot maybe we *can* do something about that ;-) pabs3, thanks a lot for bringing this up
<kerio>
ew, don't do something about that
<kerio>
if it can be disabled, it will be disabled by mistake in the worst possible way at the worst possible time by someone
<DocScrutinizer05>
note to self: "design requirement: for entering cold flashing mode, make pressing a hw button mandatory. When said button is not pressed during early boot, the PHY shall not get enabled, or USB data otherwise blocked"
<kerio>
...fair enough
<kerio>
i suggest "u"
<bencoh>
:à
<bencoh>
:)
<DocScrutinizer05>
too complicated, since matrix
<kerio>
or "s"
<DocScrutinizer05>
prolly vol+ or vol- or... duh, camera trigger
<kerio>
for "everything went to shit and i need to reflash"
<kerio>
DocScrutinizer05: how does NOLO do it with u then=
<kerio>
?
<DocScrutinizer05>
NOLO is not ROMBOOT
<DocScrutinizer05>
for ROMBOOT we need to implement that stuff in *hw*
<DocScrutinizer05>
HAH! prolly via SYS:BOOT pins and boot sequence
<DocScrutinizer05>
since *those* are actually changing what ROMBOOT does, particularly changing if or if not it looks at USB for some xLoader data
<freemangordon_>
yep, connect some of the buttons in such a way, that sysboot got modified to enable usb boot when that button is enabled
<kerio>
"ez"
<DocScrutinizer05>
freemangordon_: exactly
<DocScrutinizer05>
pabs3: thanks again! :-D
<DocScrutinizer05>
or how about battery cover switch?
<freemangordon_>
camera focus?
<kerio>
DocScrutinizer05: if you can fix the fact that the uSD is not powered when the cover is removed
<DocScrutinizer05>
booting with batt cover removed == "I wanna boot from USB (or NAND), NOT from uSD"
<kerio>
DocScrutinizer05: awkward as fuck, tho
<kerio>
what if the battery falls off
<pabs3>
another thing is: I loved the dual bootloader thing in the gta02 (inc DFU mode), will there be something like that?
<DocScrutinizer05>
doesn't matter since Neo900 boots even without
<DocScrutinizer05>
:-P
<kerio>
OFL
<kerio>
ROFL
<pabs3>
hm?
<kerio>
pabs3: dual bootloader?
<DocScrutinizer05>
pabs3: we got arbitrary number of alternative systems you can boot from uBoot
<pabs3>
kerio: GTA02 had u-boot on NOR flash (read-only without debug board), u-boot on internal NAND flash
<DocScrutinizer05>
and the OMAP allows booting uBoot and friends from either NAND, USB, TTY, ir uSD
<kerio>
what's that useful for?
<kerio>
i mean
<pabs3>
upgrading bootloaders without fear of bricking
<kerio>
but you have DFU mode
<kerio>
or whatever
mvaenskae has joined #neo900
<DocScrutinizer05>
kerio: failsafe for those without flashing fixture. OMAP has USB instead of flashing fixture
<kerio>
coldflashing
<kerio>
oh ok
<kerio>
yeah makes sense i guess
<kerio>
oh so there's some *rom* that can boot both bootloaders
<DocScrutinizer05>
pabs3: OMAP has a thing called "cold flashing" for that
<kerio>
like dual bioses in recent pc mobos?
* pabs3
has no idea how it worked
<DocScrutinizer05>
N900 and Neo900 are not brickable like Freerunner
<pabs3>
but you pressed a button to get NOR u-boot
<pabs3>
ok cool
<kerio>
i think in most motherboards, there's a jumper to boot from the secondary bios
<DocScrutinizer05>
pabs3: ROMBL (immuatble in Soc) chcks USB, TTY, and a few other sources for "uBoot"
<DocScrutinizer05>
that's exactly what we need to "fix" for improved security, according to your previous request
<kerio>
camera key to coldflash would be nice
<pabs3>
I see
<DocScrutinizer05>
pabs3: you can bring upo a completely xray-erased OMAP via USB only
<DocScrutinizer05>
ROMBOOT will check USB for a magic "hello!" and load the next stage bootloader into RAM and execute it
<DocScrutinizer05>
...from USB
<kerio>
some dude actually did that with a n900
<kerio>
well, not xrayed
<kerio>
but he nandtested everything
<DocScrutinizer05>
LOL, our beloved NANDtester
<DocScrutinizer05>
yes
<kerio>
i wonder if he got bluetooth to work again afterwards
<DocScrutinizer05>
kerio: he could have revived BT when he didn't refuse to recover/regenerate CAL from an arbitrary image of another device's CAL
<DocScrutinizer05>
and I wonder if WLAN not as well needs MAC from CAL since MAC for sure isn't hardcoded into wl1251-firmware.bin
<DocScrutinizer05>
maybe the wl1251 chip has hardwired MAC on chip, dunno
<freemangordon_>
yep, it needs CAL
<DocScrutinizer05>
(<kerio> oh so there's some *rom* that can boot both bootloaders) well, basically either NAND or NOR was simply mapped onto CPU's POR program start address
<kerio>
ayy lmao
<DocScrutinizer05>
CPU had *some* sort of ROM that tried to copy that addr to RAM
<DocScrutinizer05>
but that's it. When first block was faulty, it tried 2nd, 3ed, 4th then you're doomed
<DocScrutinizer05>
so NOR and NAND need at least one working block in first 4 blocks
<DocScrutinizer05>
and there was no alternative way CPU could boot up, like on OMAP
<DocScrutinizer05>
so when you e.g. flashed NAND and destroyed uBoot in first 4 + following blocks, you were doomed too on Neo1973 and on Neo Freerunner you could still use the NOR alternative uBoot which you cannot destroy by flashing, since you cannot flash it (without debug board attached)
<DocScrutinizer05>
maybe I got some minor details wrong since I looked into all this last time at least 5 years ago, but the large picture is about correct
<DocScrutinizer05>
even today some smartphones still need JTAG when you managed to brick the bootloader
<DocScrutinizer05>
not OMAP though
che1 has quit [Remote host closed the connection]
che1 has joined #neo900
vakkov has quit [Remote host closed the connection]
che1 has quit [Ping timeout: 264 seconds]
<Pali>
wl1251 in n900 does not have eeprom (where can be stored mac)
<Pali>
and kernel by default generate random mac address when driver does not specify one (from hw device)
<Pali>
in case for wl1251, driver genrate random mac address from nokia allocation
<DocScrutinizer05>
I guess not on maemo where it fetches MAC from CAL
<Pali>
also on maemo with maemo kernel
<Pali>
when userspace starts, it call ifconfig something
<Pali>
which change temporary mac address
<DocScrutinizer05>
aaah ok
<Pali>
but if you ask kernel for permanent mac address you will get that random one
<DocScrutinizer05>
hehe
<Pali>
bluetooth is somehow similar
<DocScrutinizer05>
thought as much
<Pali>
whrn you do bluetooth init you can send hci command for changing mac address
<Pali>
and maemo userspace use it to set address from CAL
<Pali>
no idea what is default address (maybe some hardcoded in bluetooth chip maybe ff:ff:ff:ff:ff:ff)
<DocScrutinizer05>
would be funny
<DocScrutinizer05>
maybe it simply doesn't work before you provided a valid MAC
<Pali>
maybe, I did not tested it
<Pali>
now upstream bluetooth subsystem has support for such devices and provide atomic way to set mac address
<Pali>
hci0 is exported in kernel after userspace provide mac address
che1 has joined #neo900
<Pali>
before it is in some special state (invisible for hciconfig) and with some special tool it possible to see/set mac address and do init
<Pali>
problem is that special tool si bluez5 :-( or something which depends on glib :-(
<Pali>
gnome devs are really happy
<DocScrutinizer05>
_sigh_
<Pali>
anyway, what happened with nandtester?
<Pali>
is his n900 working (again)?
<DocScrutinizer05>
he never again shown up
paulk-collins has joined #neo900
modem has quit [Remote host closed the connection]
modem has joined #neo900
<freemangordon>
Pali: wait, can't we backport that(bluez tool)?
<Pali>
I would like to see easy and clean C code
<Pali>
so we do not need full new glib library and other fancy bluez codespace...
<freemangordon>
yep, my point, I doubt it is more complicated than a coule of ioctls
<freemangordon>
*couple
arcean has joined #neo900
illwieckz has quit [Ping timeout: 250 seconds]
illwieckz has joined #neo900
xeal has joined #neo900
xeal has quit [Remote host closed the connection]
vakkov has joined #neo900
modem has quit [Ping timeout: 245 seconds]
modem has joined #neo900
xeal has joined #neo900
xeal has quit [Ping timeout: 244 seconds]
mvaenskae has quit [Ping timeout: 256 seconds]
vakkov has quit [Ping timeout: 252 seconds]
sparetire has joined #neo900
vakkov has joined #neo900
misv_ has quit [Quit: leaving]
misv has joined #neo900
vakkov has quit [Ping timeout: 245 seconds]
che1 has quit [Remote host closed the connection]
fling has quit [Quit: Lost terminal]
fling has joined #neo900
fling has quit [Quit: leaving]
fling has joined #neo900
vakkov has joined #neo900
norly has joined #neo900
che12 has joined #neo900
che12 has quit [Ping timeout: 240 seconds]
che12 has joined #neo900
che12 has quit [Ping timeout: 250 seconds]
norly has quit [Quit: Leaving.]
che11 has joined #neo900
Pali has quit [Remote host closed the connection]
xes has joined #neo900
paulk-collins has quit [Quit: Quitte]
vakkov has quit [Ping timeout: 245 seconds]
vakkov has joined #neo900
vakkov has quit [Remote host closed the connection]
arcean has quit [Read error: Connection reset by peer]