Open Lunchbox Forums

http://retrobsd.org/wiki/doku.php

requires 512KB of flash and 128KB of ram

2 segments 0 -99 and off is 100?

> Would it not be better to have a little small little 1/4" 3 digit LCD that displays the actual battery charge percentage?

you mean 3 * 7-segment display or an actual LCD?

> Status LEDs are all good for me, just make sure they don't blind you while working at the device.

Since they would be MCU controlled, you could adjust their intensity, colour and even turn them off completely via OS and/or keyboard binds (bypass OS).

All I/O connectors optically isolated and with software enables both on data lines and
on power lines. use cases:

• charging USB devices without letting them enumerate
• communicating with mobile phones without letting them charge (if laptop is low on battery or w/e)
• providing 5V USB power to a protoboard without the chance to produce wierdness on data lines
• administrator-enable for devices with DMA access (external/internal PCI-e)
• controlled add/remove of PCI-e devices (hotplug?)

Perhaps an external wrist rest that has speakers built-in?

Are there any hardware level indicators, like there are seven-segment displays?
E.g. it has 8 LEDs built-in and you give it a 3-bit value? Possibly RGB? (see image)

Quote from: sydko on February 23, 2015, 11:50:05 PM

I would suggest some cree warm white leds.. cheap and bright

color would be warm white.. because rgb only brings pain to configure
Can have ambient light regulation, but also allow manual change

RGB is not a pain to configure, especially if it is all controlled by open source and easily modifiable
firmware.

I use redshift that adjusts my screen's colours (appears more red at night and white at day) based on
time of day and I enjoy it. It would be great if everything else that emits light could also change
accordingly.

If LiFePo4 chemistry is chosen for the external battery pack (or some other with high discharge),
there should be a way to start your car with it in emergencies.

A 3-cell 100Wh LiFePo4 battery pack with 30C discharge (max) provides
100 / 3 cells / 3.6V nominal  * 30 times-discharge provides 277 amperes of
current or 3000 watts at 3*3.6 = 10.8 V

Problem: how to block current from coming from the lead-acid battery and/or the alternator from
charging the battery (One does not simply charge li-ion)? High-power low-drop diodes?

> This is maybe not such a problem, at least from my side. I used IDE2CF in thin clients and sometimes via these cheap adapter boards that you can attach to IDE. But for just reading CF cards a normal USB solution should be fine, too. It would have been nice to have CF directly but external USB card > readers (offering all sorts of flash card formats) are available between 5 and 15 Euros (7-20 USD). This is what I normally use on the big boxes where I > do not directly boot from CF.
> I don't know about the difference in performance, though. When I chroot to a CF card to compile Gentoo for my small x86 machines (Geode LX, Transmeta) on my "big" Athlon II x4 there seems to be a bottleneck somewhere. Still it is faster than native compiling.

Probably cached entirely due to RAM size > CF card size.

> Ah, so the SB contains some ADCDAC. Yes, I think the Radeon Feature Matrix mentioned that newer chips might not offer native analog support anymore. But if there are affordable adapter chips that should be okay.

We'll see. Might even look into providing a DVI port that can carry either DVI-data or analog VGA signals.

>> There are DP to HDMI/DVI converters for everything else
> I wonder about that. I was recently looking for HDMI to something else adapters and it was sheer terror. Somehow it seems the HDMI consortium forbid adapters at least in one direction.

HDMI is evil (HDCP)

>> That is what the external PCI-express is for!
> Ex-Ternal PCI(e)? Oh, the tears of joy!
> That was new to be that you had this planned. But is there also some level of protection - against dust and stuff that daily confronts a laptop from the outside?

To be figured out.


>> southbridge has 10 USB 2.0 and 4 USB 3 with blobs (have to figure out what to do here).
> Yes, but that is a good number. I was glad that AMD was so nice to give even the older SB7xx chipsets a plethora of USB ports. I actually needed more and more over time.

Will probably need a hub.

> Ehm. Blobs?

But of course!

>> There could be an internal USB hub and a seperate USB 3.0 controller that doesen't require blobs.
> Do USB 3 controllers require blobs? I wasn't aware of that. So far I thought you did not even have specific drivers for USB controllers, regardless if the > came from VIA, Renesas (NEC?), AMD, nvidia, intel or somebody else.
> Blobs are evil.

AMD FCH xHCI controller requires it. Otherwise no USB 3.0.

>> of those 10 a few will be used internally (one per each miniPCI-e slot, ...).
> I am not a professional, how comes that PCIe and USB are correlated? I mean, attaching e.g. the trackpoint or touchpad via USB sounds reasonable (though the bandwidth is probably still overkill).

http://pinoutsguide.com/Slots/mini_pcie_pinout.shtml

> Could anybody explain me why people need 32 GB RAM? Actually, I had problems to fill my 6 GB on my main box. But maybe there are use cases where 32 GB would make sense? Does virtualisation eat much memory?

virtual machines, big games (remember the APU iGPU itself can take a lot for
itself), FPGA compiles, temporary data on tmpfs (Linux compile = 500M, full
Android builds probably over 20 GB, libreoffice compile 6 GB, ...), hundreds
of browser tabs open, tens of PDF readers, tens of terminals, ...

>> ECC RAM
> Oh really? A scarce sight. I thought they had dropped that from their memory controller and maybe only have it in server CPUs/APUs. I'd be interested in that when it comes to "real" mainboards, for file storage servers and such.

The problem is that desktop APU sockets don't support ECC RAM and using a
soldered mobile "socket" limits you to 35W TDP chips. And I would rather
have 5 GHz for compiles than ECC RAM. But YMMV.

>> Bolton
> I guess this is A88X and such. Well, but this is a desktop chipset. Or was Bolton divided into desktop and mobile variants? It offers lots of native SATA and USB but I wonder if you can easily put this in a laptop without sacrificing a lot of battery runtime. Under normal conditions for a notebook we might be using only 2 of 6, 8 or 10+ SATAs. There is SATA power management but I don't know if that really switches off power to the unused ones completely or if it just puts them to a sleep state.

I'm pretty sure it does. Wikipedia says 4W under normal usage, 8W TDP.

> Also, aren't a lot of recent APUs "complete" SOCs? I'd say Kabini, even the socketed AM1, seems to contain the equivalent to an AMD A68 chipset with some USB3, more USB2 and 2 SATAs. Wouldn't something like this still be enough but more power efficient? Of course, the more integrated the stuff is, the less modularity you have. :/

Power efficient or not, a 4W TDP chip is atleast 40 watts from being adequate
for me.

>>  "pop off" screen
>Have you seen the Always Innovating Touchbook?

Now I have.
I want a portable workstation laptop on which I can do everything that needs to be done, not
some flimsy ARM board that runs out of RAM when two vim sessions are open in parallel.

>> PCI / PCIe
> While I love PCI and slotted stuff, how could this be incorporated in a laptop? Okay, a some internal periphery is linked via PCI(e) bus. But open slots for the user? I mean, it sounds great, and I saw something like the small miniPCIe(??) in this PCengines thingy. But can a user actually put them to good use in the small enclosure of a laptop? And what cards are available in this small form factor. I admit that I have little experience with SFF PCI periphery. My experience relates mainly to ATX, miniITX and a few thin clients, the latter all with more or less proprietary non standard layouts.

See MOLEX iPASS system for an example (though it is pricy). And these are
*EXTERNAL* slots, meant for connecting to an enclosure with a
cable-to-fullsize x16 board for connecting standard desktop form factor cards.
(e.g. 300W dual-GPUs)

There will be unused internal miniPCI-e (one x1 PCI-e, one USB 2.0 and one SMBUS(i2c))
for connecting stuff such as wifi/wwan/SSD cards or FPGA boards or whatever
you make.

> Camera = no go. Privacy issue. Though I admit that a camera would already contain a sensor by itself.

When the camera becomes a privacy issue you already lost control over you OS
and as such have bigger problems than someone seeing your face.

> A shut-able cam and mic would be neat, by the way.

But yeah, a hardware (no software control) "camera on" and a "mic on" LED is a good idea.
(something you could solder off if it bothers you)

> I do have an Eizo IPS screen as of late and it has this ambient light function. I do see benefits but also drawbacks. So it has a motion (?) sensor, something that is supposed to detect "presence". It switches the screen off once it does not detect someone for ... I think it was adjustable... like 3 minutes. But I normally do this setting in KDE or xorg.conf by just blanking / DPMSing the screen after 3 minutes of inactivity. And some video players will override this, luckily.

the entire code will be open source and you will probably be able to
reprogram it on the fly, without shutting down.

> The other thing is ambient light. It works so-so. Sometimes it is too dark for me just because my head is blocking the lamp from the ceiling that is behind me. So the monitor thinks it is dark and it doesn't need to glow so much and reduces brightness to a point that is already uncomfortable.
Some other times it works nicely and doesn't blind you when the room is darker.

This is exactly where camera-based light sensing would come in handy, as the
software would know where the bright spots are and whether they are blocked.

> If the feature is not too expensive and can be switched off / overridden it should be fine to implement.

Im sure the light sensors themselves are cheap

> So interfaces to the outside world. Personally I am on the standpoint that one can never have enough interfaces.
yes

> parallel (LPT) interface (microcontroller programming, still works kind of driverless and cheap via a self soldered LPT adapter)
> serial interface (a lot of machines are still driven via RS-232)
> PS/2 kbd/mouse
> Card reader: I love compact flash. But then, it is "large" (whatsoever people call large these days) so nearly anybody ever included it in a laptop.

Yes, they are "obsolete", bulky and not needed by many. Plus they occupy a
lot of space that would better be used by adding more displayport/USB/whatever.

But some people may need them in full size so it should be provided. Either
in the form of a connector expension board (maybe a 30 pin connector that
exports them outside the case or with a board that mounts inside the laptop
instead of a battery pack or whatever).

None of them are natively supported by the chipset. The first three of them
could be provided via EC (LPT byte/bit banged), but for CF an IDE to SATA or
whatever bridge chip would have to be used, or it could be connected to an
FPGA with your controller code on it.

external (optoisolated) SPI/i2c/u(s)art should certainly be provided in
some form, preferably via a 100 mil header.

> VGA (beamers, lots of old beamers around)
> some newer digital interface. HDMI is wide spread but sucks. Okay, anything with digital restriction management sucks, but HDMI is soo limited. Resolution, no adapters allowed and so on. I was quite fond of DVI and DP is at least VESA specified so it can't be that bad?

VGA is a must and directly provided by the southbridge. If I recall correctly,
the APU desktop chipsets support 6 displays (with DP daisy chaining).
There are DP to HDMI/DVI converters for everything else

> I don't know about eSATA. Never used it. And afaik there is a version that provides also power over eSATA (which would make sense) and one that doesn't.

external SATA in one form or another is also a must. Preferably atleast 2 of them.
Addional cables will be needed in any case as connecting the HDD directly to
laptop PCB would be very prone to breaking connectors in a moment of carelessness.
Not sure if 2 powered SATA connectors would be better than 2 ordinary SATA and
one MOLEX 4-pin power as the cables for the later are easily obtainable commodity.

> Maybe something for external sound sources / output. I guess it won't be a multimedia audio recording studio notebook. And people into professional sound biz better look for a box with real sound cards with awesome SNR, I/O ports and such, that most onboard chips won't provide.

That is what the external PCI-express is for! Snap whatever card you want into
an enclosure and connect it to the laptop. With that you are not limited to
form factor or anything.

> A sane amount of USB. Especially if there is no classic port you have to do everything by USB and then you need a whole lot of them. Or carry USB hubs around and see for enough power supply. And so the problems start.

southbridge has 10 USB 2.0 and 4 USB 3 with blobs (have to figure out what to do here).
of those 10 a few will be used internally (one per each miniPCI-e slot, ...). There
could be an internal USB hub and a seperate USB 3.0 controller that doesen't require
blobs.

> Ethernet. Of course. 10/100/(1000)

Atleast one built-in gigabit+ ethernet. More with internal or external expansion cards.

As per discussion in IRC:

- RGB LED with dimming and colour adjustment (vi a EC/OS), possibly even two in stereo?
- ability to turn it on/off (and possibly adjust intensity/colour) when laptop is "off"
- colour/intensity adjustment based on time of day and/or ambient light sensor readings
- powerful enough that no-one will have to run it at 100% in normal and not totally crazy circumstances

anything else?

via light sensor, possible locations:
    - indicator board (issues? LEDs might interfere)
    - camera/mic/thinlight board on top of screen
    - near the front of base unit?
    - somewhere else?

via camera? (Probably a no-go, but keeping it here for reference)
    - Take a picture and derive amount of light shining directly onto the screen.
    - the bad: requires a coprocessor that:
        - has the required hardware interface http://mipi.org/specifications/camera-interface
        - is fast enough to pass-through video (DMA?)
        - is fast enough to run some algo on the captured image.

Offloaded to EC or some other mcu that controls the backlight.