Zoran Stojsavljevic

Working on the following topics: ‒ Android HAL (Hardware Abstraction Layer), Linux Device Tree development; ‒ Debugging issues within Google’s AOSP and Linux Kernel; ‒ Working with source control tools such as Git and GitHub, and with Android command line tools such as ADB and fast boot. ‒ Embedded Linux U-Boot/kernel development and customization; ‒ BSP/Board Support Package, Android/Linux Kernel, Bootloader, Graphics and Audio Drivers; ‒ Embedded Linux device driver development (including optimizations, bug fixing, and adding new functionality); ‒ Familiarity with the Android security model (SE Linux policy) and secure boot; ‒ Ability to read and understand electrical schematics.

Providing services to wide IT Industry establishment.

Target achievement: Kernel Grey Bus deployment for the MikroE CLICK MikroBus HW. This job deals with BeagleBone Black referent development platform (based upon Texas This job deals with BeagleBone Black referent development platform (based upon Texas Instruments (TI) armv7 A8 am335x) related to the MikroE CLICK MikroBus HW and SW support design and integration. In order for the introduction to the area, lot of experiments were done with the MikroE main line of products, fitting them into the BeagleBone Black reference platform: https://www.mikroe.com/ The main line of work is captured in the following GitHub repo: https://github.com/ZoranStojsavljevic/MikroE_BeagleBone-Black_BSP-Integration The work was done NOT only for the CLICKs, but for a generic embedded solutions, applicable for all ARM A type of silicones, thus creating the very flexible and scalable solutions, namely: • U-Boot 2019.04 with added overlay patches (handling the specific platform with chosen U-Boot defconfig); • Latest kernel enhancements for the silicon (making the specific platform chosen kernel defconfig); • Completely generic initramfs/initrd, applicable for ANY ARM A series, as for very first time BSP boot; • Generic Debian Buster rootfs, applicable for ANY ARM A series, defined by defconfigs, mentioned above! The major bulk of this work is captured in the following GitHub repo: https://github.com/ZoranStojsavljevic/BBB_Workshop_Examples

Hancock project serves as embedded platform for the cars. The aim is to govern and to control complex sensor structure using CAN Fd bus. The hardware used is armv7 architecture (arm335x family member). The embedded SW system used in Hancock is YOCTO Sumo release. Creating the proprietary Hancock embedded YOCTO strategy, also using Beaglebone Black (BBB) HW as Open Source parallel platform development for DVT (Design, Verification and Testing). Lava VM is used (for both BBB and Hancock platforms) for the testing. The following are the feature set developed for Hancock: • Using proprietary meta-socketcan layer, developed for the CAN Fd platform: https://github.com/ZoranStojsavljevic/meta-socketcan (can-utils, cannelloni, socketcand) • Handling YOCTO Sumo BBB and Hancock releases on system levels • Complete control over YOCTO kernel configuration and release • Using Lava (Linaro Automation and Validation Architecture) server testing application: https://github.com/ZoranStojsavljevic/lava-server-vm • Using Lava client/dispatcher testing application as worker: https://github.com/ZoranStojsavljevic/lava-dispatcher-vm

YOCTO Project architect/implementer, navigating via YOCTO layers trying to determine the best possible YOCTO layout for the specific, stringent requirements. Used as host Fedora 26, as target ARM i.MX6 silicon with the standard Device Tree definitions. YOCTO Project is an open source collaboration project that provides templates, tools and methods to help create custom Linux systems for embedded products regardless of the HW architecture. • Adding the 3rd party layers • Making own layers • Using a .bbappend to patch the Device Tree • Using a .bbappend to work around bugs in some layers • Writing own image recipe • Making it boot and run on the target platform

Listed items are/will be in Present/Future viable time in learning progress. Crucial/Core points are relations/dependencies among different kernel parts, basics, drivers and underlying FW/multicore HW (with many HW extension support mechanisms added to underlying CPU/SoC silicon) features, such as MMU, PAE, VT-x/TLBs, VT-d/IOMMU remapping, etc. The following areas are/will be covered under such an investigation, at least, but not limited to! [1] Board Support Packages (BSPs), hammering "Run Time Services"​ as postmortem boot-loaders'​ features to be passed to Linux (GRUB2) loader phase, including Linux kernel boot as last phase of system SW bring-up. [2] Kernel relations/dependencies to own basics, as well as to another core pieces of different sub-architectures, glued to kernel: _[A] IO remapping physical to logical kernel memory; _[B] Kernel memory allocation; _[C] Kernel scheduling algorithms, prioritizing and internal and IO/external APIC handling; _[D] Real-Time kernel performance tuning; _[E] Time Slice analysis and task statistics; _[F] Kernel Power Management, ACPI handling, and S0ix states; _[G] Kthreads and related mechanisms; _[H] Understanding kernel logs: dmesg, journalctl command flavour and in-depth analysis! [3] Linux Graphic SW Stacks (wrt classic/legacy X11: XClient - XServer architecture): _[A] XClient (User Space GFX intensive APPs) and XServer architectures; _[B] DRI/DRM Direct Rendering Mechanisms; _[C] Mesa (libGL.so) as 3D GFX acceleration; _[D] FBdev and VESA generic drivers; _[E] Kernel Mode Settings (KMS) mechanism introduced since 2.6.29; _[F] Open Source GFXes related to proprietary GFX HW (mainly INTEL/Integrated GFX, AMD/ATI/Radeon and Nvidia/Open Source Noveau (nv)/proprietary Nvidia binary drivers); _[G] GFX/Xorg logs full analysis: Xorg.0.log, GFX logs as parts of dmesg logs! [4] Virtualization: _[A] KVM; _[B] VirtualBox; _[C] VMWare. [5] Strace tool mastering: _[A] mmap() physical to virtual pages mapping; _[B] FD tracking.

• Active contribution to Coreboot project, advertising Firmware Support Package for Core and ATOM CPUs. Extended IVB FSP proof-of-concept to real use cases, and was able to boot to Linux modified for Bare Metal OSes per core, using sequence: IVB FSP + Coreboot + SeaBIOS + GRUB 0.97 + Linux Bare Metal kernel adopted (per core dedicated OS). En route/in process to boot Win7 and Win8.1 using CSM mode with FSP + Coreboot + SeaBIOS. • Extended member of ISG FSP architectural team. • Learned about/adopted Bare Metal per core OS, and successfully ported three Bare Metal OSes images + kernel 3.x.y image, each bound to/executed on dedicated core. • Worked on Cache Coloring feature (SW enabling), LLC based (presently done in hypervisors). • Cache QoS (HW feature). Working with CQoS on Haswell based platforms. • Looking into comprehensive SMM/SMI use cases, INTEL CPU based feature. • BIOS (AMI and PHOENIX), in addition to Fedora Linux distribution + Yocto (INTEL proprietary). • Proponent of Wind River Eclipse Based Linux distro (Wind River owned by INTEL). • Supported whole SW (Win, Linux, Bare Metal OSes, hypervisors) + Graphics + BIOS/bootloaders with Management Engine (ME) for ISG SBD team. • Linux Professional Player (plays left and right, One Man Show and Team Player, 2 in 1).

Project experience with Adroid Linux embedded environment, architectural experience with TI OMAP4 SoC, Cortex A9 Core + Cortex M3 Core experience, Camera Feature Lead, Member of Power Management Architecture Team, Various Multi Media Applications for Android. · Understanding/handling TI OMAP4 three-stage complex booting process: X-loader, U-boot, Android 2.6.35 boot. · Closely working with TI teams in Dallas, TX and Bangalore, India to find solutions to the problems. TI OMAP4 is very complex SoC with many subsystems, 0.045 um technology. · Responsible for Camera prototype development on Blaze and on final target. Working with whole camera stack from graphic design team, via Google Camera Service, OpenCORE to OpenMAX IL, which has specific implementation on TI OMAP4 (uses Ducati SW ported on Cortex M3 core). · Member of several architecture teams, significant contributions done in Power Management Architecture team. The Power Management is the key feature for the mobile phone applicability and usability. · On-Fly helping the Application and BSP members from architecture to implementation issues (hands on tools, C coding and shell scripting).

http://www.christiedigital.com/AMEN/Corporate/AboutUs/ Project experience with Linux environment, TCP/IP, C/C++ programming experience, Applications for Linux, Cascading/nested Makefiles, Linux shell scripting, Limited Linux system administration experience, Embedded experience, Linux device drivers, multi-threading, etc. · Hands-on development of Linux BSP COLILO (COldfire Linux LOader), by configuring Coldfire 7574 systems registers. · Responsible for various board types bring-up (used Abatron BDI3000 GDB debugger). · Responsible for LTIB package management (LTIB is used by Freescale to manage kernel 2.6.xx and packages around it in order to build rootfs with all relevant linux libraries, tools and applications). · Built additions to Linux kernel 2.6.10 failsafe boot-up, as well as additions to the bash shell scripts, as well as pieces of code for Web upgrade implemented in “C”. · Designed and implemented from scratch few very complex custom designed device drivers for FPGAs, which are controlling SXGA+ and WUXGA video modes/data path (330Mbps). · Created Frame Interrupt handler driven by few FSMs in order to handle 16.66 ms and 8.33 ms Frame interrupts (to support Color Loc calculations and to feed Bright/Dark Loc user space algorithms). · Participated in extensive multithreaded real-time embedded software development (implemented in “C” and “C++”) in user space (main, communication, thermal, fan threads). · Wrote extensions to TCP based socket messaging in communication thread to achieve control plane functionalities. · Among many other testing tools for testing various applications, wrote user space mdevx (Memory DEVice eXternal) tool for mapping FPGA Physical Addresses to user space virtual addresses (using mmap() function). · Created remote mdevxd (last d stands for daemon) tool using forking and orphaning child to make it daemon; used socket server APIs to create server for debugging clients over the IP network.

Linux System Engineer. Kernel and Device Driver Engineer, porting Yellow Dog Linux on Embedded MPC8XX and MPC82XX systems, also on various Linux PC distributions (Red Hat, SUSE). Working experience on RTAI and Xenomai Real Time Linux extensions. Started R&D concept named "One Man Show". The idea behind this concept it is to provide a bigger foundation for richer and more sophisticated open source applications which are portable over Linux platform. The concept assumes achieving Linux kernel mastering and indepth knowledge of variuos kernel aspects. "One Man Show" idiom translated into "One Developer per Complex Project" idea. Developed/implemented entire software (Data Plane) for ADSL Peripheral Board card as extention to DKTS voice/data switch. The OS used on the card is Linux based on kernel 2.4.2x (Denx ppc distribution, based on Yellow Dog). Developed MPHY ATM driver for MPC8260 platform under Linux. The developed solution supports bridged and routed networking methodologies.

(Acorn Networks ceased to exist on 11/10/2001) EETimes article: http://www.eetimes.com/story/OEG20011101S0063 Octobus (8B) was (cancelled) very high performance Network Processor project where there are numbers of Processing Engines (PEs) working in parallel on the given Packet Data Units (for various protocols, including ATM, IP, FR, Flex Cells). Long PDUs such as IP and FR were to be broken to configurable by host PDUs of fixed length (by Network Input Module - NIM), which would be in paralel processed by PEs. There were three types of PDUs: Start Of Packet (SOP), End Of Packet (EOP) and neither. Wrote application programs for parallel processing for various protocols (ATM, IP) using 8B specific ISA and modified GNU "C". GenFlow 192 is highly integrated and flexible traffic management (TM) Network Coprocessor that combines in a single device all the key functions required to do TM and to interface with Switching Fabric at full OC192c wire speed. Last few months worked on GenFlow low level APIs (gF interface with host) solving low level functions (RD, WR, posted WR, DMA access, endiannes) and simulation between APIs and gF192 RTL model.

AIReach Broadband is a fiber-class wireless access system that offers high-bandwidth services to business and multidwelling residential locations. The system, part of the AIReach family, is a second generation product that integrates access for services such a switched voice, high-speed data, frame relay and asynchronous transfer mode (ATM) into the radio. AIReach Broadband can deliver capacity from a fractional T1/E1 rate in increments of DS0 up to 45 Mbps per radio link. The system will allow CLECs and other carriers to compete effectively using the broadband, last mile, wireless access solution which can be built rapidly and cost-effectively. Major Job Responsibilities · Investigate implementation of ATM services within the AIReach Broadband product · Evaluate hardware devices and make recommendations for ATM services (ATM Layer Managers and ATM Buffer Managers) · Evaluate software protocol stacks for Frame Relay to ATM interworking and make recommendations (including AAL5 devices) · Evaluate hardware devices for TDM services over ATM (AAL1 -> Transparent (193 bits) T1 service, N*DS0 (Fractional T1) Structured service) (including AAL1 devices) · Bring up to speed other engineers on the ATM technology and continue to provide ATM guidance and technical leadership · Write parts of AIReach Broadband Requirements (for CES services and FR-ATM service) · Write ATM Services part of AIReach Broadband Functional Specification Release 3 according to ITU-T I.363.1, ITU-T I.363.5, ITU-T I.610, ATM Forum Traffic Management 4.0, ATM Forum B-ICI 2.0, ATM Forum UNI 3.1, ATM Forum CES 2.0, FR Forum FRF.5 (RFC 1490 included), FR Forum FRF.8 (RFC 1483 included), ANSI T1.606 Annex A · Participate in ATM System architecture design of AIReach Broadband · Participate in ATM hardware design (especially in TC sublayer FPGA design) · Work with Mantra Communications Inc. in porting of the Frame Relay software stack to the AIReach Broadband network · Interview engineers for ATM positions.