Comment 1 by Joerg Reisenweber, Feb 10, 2015

for SYS_BOOT:
sys_boot5=0:  sys_boot[4:0]=0b10000 --> OneNAND USB UART3 MMC1
sys_boot5=1:  sys_boot[4:0]=0b10000 --> USB UART3 MMC1 OneNAND

For Neo900 SYS_BOOT5 should be default=0, and 1 when some hw-button 
gets pressed (TBD)

Comment 2 by Nikolaus Schaller, Feb 13, 2015

1. I2C2 hang w/o external pull-ups:
is solved. Issue was that DM3730 ignores the PULLUP pinmux 
definitions (while the OMAP3530 doesn't). Setting a register bit in 
some control register (which is also different from OMAP3530) fixes 
this.

2. Kernel RAM size:
in a discussion about device trees for the OpenPandora specifying 
the memory size in the Device Tree, it turned out that the DT entry 
is simply ignored. Rather, the real memory size is passed as ATAG 
information by U-Boot to the Kernel and explicitly overwrites the 
/memory property of the device tree blob - after loading into RAM. 
This can be seen by 'xxd /proc/device-tree/memory'.

So the RAM size is solved for the kernel as soon as we have fixed it 
for U-Boot (which also reports only 512 MByte RAM).

3. SYSBOOT HW button:
GTA04 has a similar function - by pressing the AUX button during 
power-on, the boot order is swapped. This allows to enforce booting 
from MMC/SD even if NAND is completely bricked.

On Neo900, maybe we can (re)use the camera shutter button. 
Alternatively one of the volume control buttons, but there we 
thought about adding them to the keyboard scan matrix - which 
prohibits a parallel function to change sys_boot5.

Especially, using sys_boot5 allows to "save" one dedicated 
GPIO since sys_boot5 can also be reprogrammed as a button gpio after 
boot (or by the kernel) so that it gets this dual-role.

Comment 3 by Joerg Reisenweber, Feb 13, 2015

3. SYS_BOOT5: Please use IR-proxy-sensor for battery lid. 
ToBeChecked: V28 VDD hall switch supply stable before CPU comes out 
of POR reset state and samples the SYS_BOOT pins

Comment 4 by Nikolaus Schaller, Feb 13, 2015

Well, I would not choose the IR lid.

It requires the user to remove the battery lid to unbrick. This does 
not allow to boot normally with open battery lid.

Please also think about us developers who want to debug/test a naked 
board where we just connect a battery. Even then, this emergency 
boot should be easily accessible. 

If V28 VDD is supplied by some VAUX (have not looked into current 
schematics) is is not stable at power-on-reset since X-Loader/Kernel 
sets the right voltage.

And, one more thing to check: is the polarity of the sensor correct 
or inverted?

That is why I propose the camera button, but it might still be the 
wrong thing.

Comment 5 by Joerg Reisenweber, Feb 13, 2015

Device will boot from MMC1 anyway when OneNAND xLoader is defect:
sys_boot5=0:  sys_boot[4:0]=0b10000 --> OneNAND USB UART3 MMC1
The SYS_BOOT5 switch is only needed when xLoader looks good to 
ROMBOOT but actually hangs.
Batt lid is Hall switch, sorry when I said IR somewhere. In lab it's 
simple enough run device without battery lid. In usual in-the-field 
every day usage the batt lid removal seems the right and most secure 
thing to use for this security-related feature *) since you never 
will want to boot from USB to override xLoader in OneNAND in a pub. 
The other options (cam switch etc) are "reserved" for more 
common useful usecases that regular users are interested in, like 
bringing up uBoot menu.

*) main purpose being to avoid rogue "USB chargers" in 
pubs or wherever hijacking the device via coldflashing (ROMBOOT 
-> USB xLoader) attack vector.

The V28 early stability is a concern, we need to work that out 
properly. When VAUX of TWL4030 starts up to a sufficient voltage 
before CPU configures it, then we're fine. Hall switch VDD_min might 
be <2V8, maybe it's sufficiently low for what VAUX comes up with. 
Polarity is also ToBeChecked and a inverter (or inverted logic Hall 
switch) added/chosen if needed.

Comment 6 by Joerg Reisenweber, Feb 13, 2015

Note that developers who want to regularly boot xLoader from MMC1 
are free to simply nuke the OneNAND xLoader and the boot sequence 
will eventually fall through to MMC1 no matter if battery lid 
removed or not.
Likewise even with battery lid removed the device will boot from 
OneNAND xLoader when no xLoader found on MMC1.

Actually we need an addirional 0R "jumper" for SYS_BOOT5 
that allows users to solder-hardwire the "OneNAND USB UART3 
MMC1" sequence so they can completely protect their device 
against any threat from attackers that have 5 min access to device 
(the "left device on table in pub" scenario, also known as 
"cleaning woman" scenario).

Comment 7 by Nikolaus Schaller, Feb 13, 2015

There is a situation where boot loader in NAND is partially broken 
and does not look for U-Boot. Then, there is no automatic 
fall-through. Fall-though is only if it is not found.

But I have to admit that it is a rare situation.

Mixing boot order and bringing up u-boot menu on a single button is 
no problem on the GTA04.

Polarity: hall switch is active if magnet found (lid closed). Has an 
open collector output.
lid closed => pulled down => 0 => OneNAND USB UART3 MMC1

Looks ok. Maybe the hall switch can run from 1.8V? 1.8V is 
definitively stable. The one used in the OpenPandora/Pyra does.

Comment 8 by Nikolaus Schaller, Feb 13, 2015

0R solution needs two alternatively installed 0R (hall <-0R-> 
sysboot5 <-0R-> GND. Since otherwise it would short the hall 
sensor output.
And note, that we have two GPIOs with the same value (hall sensor + 
sysboot5 gpio) in normal state (resistors not swapped).

Comment 9 by Joerg Reisenweber, Feb 13, 2015

shorting hall sensor out doesn't sound like a problem in itself, 
given it's OpenCollector.

In N900 the N5210 hall switch is connected to CardDetect GPIO160. In 
Neo900 we conect card tray integrated switch to GPIO160, and we move 
the Hall to SYS_BOOT5. No parallel second GPIO input when we can't 
spare one. When user wants to hardwire their device to highest 
security config by shorting the Hall switch to forbid skipping 
OneNAND xLoader, they will have to live with no battery lid removal 
detector then - maybe.

Comment 10 by Nikolaus Schaller, Feb 13, 2015

The problem is not shorting the hall sensor output but reading which 
state it would have wanted to tell the world :)

Therefore I suggest this 2xR0 approach.

Either connect the hall sensor to sys-boot or ground sys-boot. And 
always connect the hall switch to gpio160.

You can even place the resitor footprints so that they overlap and 
you can either install the single 0R it to the left or to the right.

Comment 11 by Joerg Reisenweber, Feb 13, 2015

GPIO160 goes to mem card tray switch. For Hall switch we need to 
find one or two new GPIO anyway, one of them being SYS_BOOT5

Comment 12 by Joerg Reisenweber, Mar 11, 2015

just a reference to the SYSBOOT resistors (and user switch, to 
switch between SYSBOOT=1 and SYSBOOT=0)
http://wstaw.org/m/2015/03/10/plasma-desktopuR1893.png