Hi all,
This is my progress so far:
=== Week 1 ===
* Read U-Boot SPL code for AM335x to figure how it could be used to load
custom
binaries.
* Set up the BeagleBone Black, experiment with U-Boot command line.
* Started reading the available ARM Packages in edk2 to see what all can be
reused.
=== Week 2 ===
* Saw portions of the StarterWare code to see how it does things.
* Wrote a bare metal application to print a character stream over UART as
per the
TRM [1], facing some problems with initialization.
=== Next ===
* Debug the bare-metal binary, otherwise load it from U-Boot instead of MLO
* Study the HisiPkg code and start implementing features for AM335x
according to UEFI specs.
[1] http://fpaste.org/106566/32870140/
Hi Team,
My status update of last two weeks.
WEEK1 (May, 19-23)
Tasks assigned:
1 - Setup and document the development environment to compile and run the linux kernel using device tree on QEMU - CO
2 - Study related code and documents to understand device tree - CO
WEEK2 (May, 26-30)
Tasks assigned
1 - Build the testcase data into a separate .dtb file (instead of including it into the platform dtb) - CO
2 - Link the testcase data into the kernel using the %.dtb.S rule - CO
3 - At selftest init time, obtain the pointer to the selftest dtb and use printk to dump out some of the header information - CO
4 - Send Grant a patch file using git send-email that covers the above. - CO
CO - Completed; IP - In Process; NP - Not started
Note: It is also available on GSOC tracking document
Please let me know if I'm missing something.
--
Regards
Gaurav Minocha
Hi folks,
Just a quick reminder - mid-term evaluations are due this
week. Deadline is 19:00 UTC Friday. If you need help, please shout...
Cheers,
--
Steve McIntyre steve.mcintyre(a)linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs
Hello all,
Here is the report for the first two weeks of the "Lightweight IP Stack on top of OpenDataPlane" project. Fortunately no blocking issues were found for now, and I believe the work is progressing well (on schedule). I have written the progress on a per-week basis, and included the current plans for this week as well.
=== Week 1 Progress ===
Worked Hours: 44
-> Set up the development environment for the project, including necessary dependencies and documentation / testing tools.
-> Started porting LwIP from a bottom up approach, using the ODP API as adequate.
-> Started porting the sys_arch / netif layer to use ODP as a platform. This layer abstracts low level I/O operations and other platform-specific behavior from the userspace IP stack itself. I believe ODP fits well in terms of architecture and functionality here. It is important to note that the linux-generic implementation is used as a basis for this project.
=== Week 2 Progress ===
Worked Hours: 40
-> Finished porting the LwIP sys_arch / netif layers. Now all platform-specific behavior and low-level I/O operations is based on OpenDataPlane; for now only the linux-generic implementation was considered, but after this initial work other ports should be relatively straightforward.
-> Fixed (hopefuly) a buffer usage issue that blocked me from testing what was already implemented. It was actually a programming mistake on my part that went unnoticed, so I did not report it earlier.
-> A set of LwIP examples were tested using ODP as a platform, to test current functionality.
-> Generated a call-graph diagram from LwIP. This should assist the porting and optimization of the next layers in the stack.
=== Plans for Week 3 ===
-> Start porting the IP Layer to use ODP platform-independent features (Milestone 2 of the project proposal). Now the fun part starts :)
-> Post available project information/documentation (both past and current) to the gsoc.linaro.org wiki, organized into sub-sections. [High priority]
-> Create a git repository and make available the first version of LwIP-ODP on it.
=== Issues ===
-> During the Community Bonding phase, it was suggested that I could study the QNX networking code and see how it applies to this project and ODP in general. However, it seems the QNX source code is not really open, or at least not easily acessible [1]. I really don't know how to proceed on this front, or how to fit it in the GSOC project scope... [Non-blocker; low priority?]
[1] http://community.qnx.com/sf/wiki/do/viewPage/projects.core_os/wiki/Os_sourc…
[2] http://community.qnx.com/sf/wiki/do/viewPage/projects.community/wiki/Update…
---
Ricardo de Freitas Gesuatto
